API オペレーション以外のリソースに集中する - Amazon Verified Permissions

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

API オペレーション以外のリソースに集中する

消費者向けのほとんどのアプリケーションでは、権限はアプリケーションがサポートするリソースをモデルにしています。たとえば、ファイル共有アプリケーションでは、権限をファイルまたはフォルダに対して実行できるアクションとして表現する場合があります。これは、基礎となる実装とバックエンド API 操作を抽象化した、優れた、シンプルなモデルです。

これとは対照的に、他の種類のアプリケーション、特にウェブサービスでは、API 操作自体を中心に権限を設計することがよくあります。たとえば、Web サービスが createThing() という名前の API を提供する場合、認可モデルは対応する権限、または Cedar の createThing という名前の action を定義する可能性があります。これは多くの状況に当てはまり、権限を理解しやすくなります。createThingオペレーションを呼び出すには、createThingアクション権限が必要です。簡単でしょう?

Verified Permissions コンソールの開始Verified Permissions の開始方法プロセスには、API から直接リソースとアクションを構築するオプションが含まれています。これは便利なベースラインです。ポリシーストアとポリシーストアが承認する API 間の直接マッピングです。

しかし、この API に焦点を当てたアプローチは最適とは言えません。API は、顧客が本当に保護しようとしているもの、つまり基盤となるデータやリソースの代用にすぎないからです。複数の API が同じリソースへのアクセスを制御している場合、管理者がそれらのリソースへのパスを判断し、それに応じてアクセスを管理することが難しくなる可能性があります。

たとえば、組織のメンバーを含むユーザーディレクトリを考えてみましょう。ユーザーはグループにまとめられますが、セキュリティ上の目標の 1 つは、権限のない第三者によるグループメンバーの発見を禁止することです。このユーザーディレクトリを管理するサービスには、次の 2 つの API オペレーションがあります。

  • listMembersOfGroup

  • listGroupMembershipsForUser

顧客は、これらの操作のいずれかを使用してグループメンバーシップを確認できます。そのため、権限管理者は両方の操作へのアクセスを調整することを忘れないようにする必要があります。次のような他のユースケースに対応するために後から新しい API オペレーションを追加することになった場合、これはさらに複雑になります。

  • isUserInGroups(ユーザーが 1 つ以上のグループに属しているかどうかをすばやくテストするための新しい API)

セキュリティの観点から見ると、この API はグループメンバーシップを発見するための 3 つ目の方法となり、管理者が巧妙に作り上げた権限を妨害することになります。

API のセマンティクスは無視して、基礎となるデータやリソース、およびそれらの関連付け操作に集中することをおすすめします。この方法をグループメンバーシップの例に適用すると、3 つの API オペレーションがそれぞれ参照しなければならないようなviewGroupMembership、抽象的な権限になってしまいます。

API 名 アクセス許可
listMembersOfGroup グループにviewGroupMembership権限が必要です。
listGroupMembershipsForUser ユーザーにviewGroupMembership権限が必要です。
isUserInGroups ユーザーにviewGroupMembership権限が必要です。

この 1 つの権限を定義することで、管理者はグループメンバーシップを検索するためのアクセスを現在および永久に正常に制御できます。トレードオフとして、各 API 操作で必要になる可能性のある複数の権限を文書化する必要があります。管理者は権限を作成する際にこのドキュメントを参照する必要があります。セキュリティ要件を満たすために必要がある場合、これは有効なトレードオフになります。