【ITニュース解説】Tenant membership is not resource permission

システムを開発する上で、ユーザーがどのような操作をどこまで行えるかを制御することは非常に重要である。これを「アクセス制御」と呼ぶ。このアクセス制御を設計する際、特に初心者が陥りやすい誤解の一つに、「テナントメンバーシップ」と「リソースパーミッション」の混同がある。この二つの概念は似ているようで全く異なるものであり、正しく理解することがセキュアなシステム構築の第一歩となる。

まず、「テナントメンバーシップ」とは何か。これは、ユーザーが特定の組織やグループ、あるいはサービスが提供する共有の作業空間（これを「テナント」や「ワークスペース」と呼ぶことが多い）に「所属していること」を意味する。例えば、ある会社の従業員として会社のシステムにログインしたり、特定のオンラインプロジェクトチームの一員としてそのプロジェクトの空間に参加したりする状況がこれに該当する。ユーザーがテナントのメンバーであると認証されると、そのテナントが提供する多くの機能（APIと呼ばれる、プログラムから利用できる機能群）へのアクセスが一般的に許可される。これは、そのユーザーが「この組織に属している正規のメンバーである」ことを証明するものであり、言わばその組織の敷地に入るための許可のようなものである。この許可があれば、その組織の建物の中には入れるかもしれないが、建物の中のどの部屋に入れるか、どの道具を使えるか、何をできるかは別の話である。

次に、「リソースパーミッション」について説明する。こちらは所属の許可とは異なり、より具体的な「操作許可」を意味する。例えば、「このプロジェクトを削除する」「あのデータベースからデータをエクスポートする」「他の人のパスワードを変更する鍵を更新する」といった、特定の「アクション」（操作）を特定の「リソース」（対象となる情報や機能、例えばプロジェクト、データセット、鍵など）に対して実行することを許可するかどうかを判断するのがリソースパーミッションである。これは、組織の建物の中で「この部屋に入ってこの資料を閲覧してもよい」「あの機械を操作して新しい製品を作ってもよい」といった、非常に具体的な権限を指す。テナントメンバーシップが「あなたはここに所属していますか？」という質問に答えるものだとすれば、リソースパーミッションは「あなたはこれに対してこの操作を行ってもよいですか？」という、より詳細な質問に答えるものである。

システム開発において頻繁に見られる危険なバグの一つに、この二つの概念を混同してしまうケースがある。具体的には、「ユーザーが所属するテナントIDと、操作対象のリソースが所属するテナントIDが一致すれば、その操作を許可する」という判断ロジックを組んでしまうことだ。コードで表現すると、もしユーザーのテナントIDとリソースのテナントIDが同じであれば、その操作を許可するというような記述になる。確かに、ユーザーとリソースが同じテナントに属していることは、その操作が適切な範囲内で行われようとしているかを確認するための重要な「スコープチェック」（範囲確認）の一つである。しかし、これはあくまで「同じ組織内での話である」という事実を確かめているだけであり、そのユーザーがそのリソースに対して具体的な操作を行う「認可決定」（操作許可の判断）ではない。

考えてみてほしい。同じ会社に所属する従業員全員が、会社が所有する全ての機密情報を閲覧したり、会社の重要なシステム設定を自由に変更したり、他の従業員の給与情報を削除したりできるわけではないだろう。部署や役職によって、アクセスできる情報や実行できる操作は厳しく制限されているはずだ。この制限が「リソースパーミッション」に他ならない。にもかかわらず、単に「同じ会社の人だから」という理由だけで全てを許可してしまうのは、セキュリティ上の大きな欠陥を生む。例えば、同じテナントに属する一介のメンバーが、本来であれば管理者しかできないはずの「全ユーザーデータ削除」のような危険な操作を行えてしまう可能性があるのだ。

したがって、システムは常に、この二つの質問を明確に分けて処理する必要がある。「このユーザーはこの組織のメンバーであるか？」というメンバーシップの確認は、最初に通過すべき「組織への所属確認」の段階であり、これによってそのユーザーがサービスを利用する基本的な資格があることを証明する。しかし、これは具体的な操作の許可を意味しない。その次に、「このユーザーはこの特定のリソースに対して、この特定のアクション（操作）を実行する権限を持っているか？」という、より詳細で具体的な「リソースパーミッション」の確認を必ず行わなければならない。この二段階のチェックを徹底することで、ユーザーが自身の所属範囲内で、かつ与えられた具体的な権限の範囲内でのみ操作を行えるようになり、システム全体のセキュリティと整合性が保たれる。安全で堅牢なシステムを構築するためには、テナントメンバーシップがリソースパーミッションではないという原則を深く理解し、常にその原則に基づいてアクセス制御を設計することが不可欠である。