モデルではきめ細かな権限を、ユーザーインターフェースでは集約した権限を優先します - Amazon Verified Permissions

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

モデルではきめ細かな権限を、ユーザーインターフェースでは集約した権限を優先します

設計者が後で後悔することが多い戦略の 1 つは、ReadWrite などの非常に広範なアクションを含む認可モデルを設計し、後でより詳細なアクションが必要であることに気づくことです。より細かい詳細度の必要性は、よりきめ細かいアクセス制御を求める顧客のフィードバックによって、または最小権限のアクセス許可を奨励するコンプライアンスおよびセキュリティ監査によって促進される可能性があります。

きめ細かい権限があらかじめ定義されていないと、アプリケーションコードやポリシーステートメントをユーザーによりきめ細かく設定した権限に変更するために、複雑な変換が必要になる可能性があります。たとえば、以前にコースベースのアクションに対して承認されたアプリケーションコードを、詳細なアクションを使用するように変更する必要があります。さらに、移行を反映するようにポリシーを更新する必要があります。

permit ( principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d", // action == Action::"read", -- coarse-grained permission -- commented out action in [ // -- finer grained permissions Action::"listFolderContents", Action::"viewFile" ], resource in Account::"c863f89b-461f-4fc2-b638-e5fa5f79a48b" );

このようなコストのかかる移行を回避するには、事前にきめ細かい権限を定義したほうがよいでしょう。ただし、後でエンドユーザーが多数のきめ細かい権限を理解せざるを得なくなった場合、特にほとんどの顧客がReadWriteなどのきめ細かな制御に満足している場合、これはトレードオフにつながる可能性があります。両方の利点を最大限に活用するには、ポリシー テンプレートやアクション グループなどのメカニズムを使用して、きめ細かいアクセス許可を ReadWrite などの事前定義されたコレクションにグループ化できます。このアプローチを使用すると、顧客にはコースベースの権限のみが表示されます。しかし、舞台裏では、きめ細かなアクセス許可を粒度の細かいアクションの集合としてモデル化することで、アプリケーションの将来性を確保しています。顧客または監査人のどちらかが要求すると、きめ細かい権限が公開される可能性があります。