属性内に権限を埋め込まないでください - Amazon Verified Permissions

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

属性内に権限を埋め込まないでください

属性は承認決定の入力として使用するのがベストです。ユーザーに「PermittedFolders」という名前の属性を宣言するなどして、権限そのものを表すために属性を使用しないでください。

// ANTI-PATTERN: comingling permissions into user attributes { "id": "df82e4ad-949e-44cb-8acf-2d1acda71798", "name": "alice", "email": "alice@example.com", "permittedFolders": [ "Folder::\"c943927f-d803-4f40-9a53-7740272cb969\"", "Folder::\"661817a9-d478-4096-943d-4ef1e082d19a\"", "Folder::\"b8ee140c-fa09-46c3-992e-099438930894\"" ] }

そして、その後にポリシー内でその属性を使用する:

// ANTI-PATTERN permit ( principal, action == Action::"readFile", resource ) when { resource in principal.permittedFolders };

このアプローチは、特定のプリンシパルが特定のフォルダにアクセスできる単純な承認モデルを、トレードオフを伴う属性ベースのアクセス制御 (ABAC) モデルに変えます。そのトレードオフの 1 つは、リソースに対する権限を誰が持っているかをすばやく判断するのが難しくなることです。前述の例では、特定のフォルダーに誰がアクセスできるかを判断するには、そのフォルダーが各自の属性にリストされているかどうかをすべてのユーザーに繰り返し確認する必要があります。そのためには、ユーザーがアクセス権限を持つ場合にアクセスを許可するポリシーがあることを特に認識した上で行う必要があります。

このアプローチのもう 1 つのリスクは、権限が 1 つのUserレコードにまとめられている場合のスケーリング要因です。ユーザーが多くのものにアクセスできると、Userレコードの累積サイズが大きくなり、データを保存しているシステムの上限に達する可能性があります。

代わりに、複数の個別のポリシーを使用してこのシナリオを表現し、繰り返しを最小限に抑えるためにポリシーテンプレートを使用することをおすすめします。

//BETTER PATTERN permit ( principal == User::"df82e4ad-949e-44cb-8acf-2d1acda71798", action == Action::"readFile", resource in Folder::"c943927f-d803-4f40-9a53-7740272cb969" ); permit ( principal == User::"df82e4ad-949e-44cb-8acf-2d1acda71798", action == Action::"readFile", resource in Folder::"661817a9-d478-4096-943d-4ef1e082d19a" ); permit ( principal == User::"df82e4ad-949e-44cb-8acf-2d1acda71798", action == Action::"readFile", resource in Folder::"b8ee140c-fa09-46c3-992e-099438930894" );

Verified Permissionsは、権限評価中に多数の個別のきめ細かいポリシーを効率的に処理できます。このような方法でモデル化すると、時間が経つにつれて管理しやすくなり、監査しやすくなります。