翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
例 1: Verified Permissions と Cedar を使用した基本的な ABAC
このシナリオ例では、Amazon Verified Permissions を使用して、架空のペイロールマイクロサービス内の情報にアクセスできるユーザーを決定します。このセクションでは、Cedar を使用してアクセスコントロールの決定をレンダリングする方法を示す Cedar コードスニペットについて説明します。これらの例は、Cedar および Verified Permissions が提供する機能を完全に探索することを目的としたものではありません。Cedar の詳細な概要については、Cedar のドキュメント
次の図では、 viewSalaryGETメソッドに関連付けられた 2 つの一般的なビジネスルールを適用します。従業員は自分の給与を表示でき、従業員は自分の直属の従業員の給与を表示できます。Verified Permissions ポリシーを使用して、これらのビジネスルールを適用できます。
従業員は自分の給与を表示できます。
Cedar では、基本的なコンストラクトは、プリンシパル、アクション、またはリソースを表すエンティティです。認可リクエストを行い、Verified Permissions ポリシーを使用して評価を開始するには、プリンシパル、アクション、リソース、エンティティのリストを指定する必要があります。
-
プリンシパル (
principal) は、ログインしているユーザーまたはロールです。 -
アクション (
action) は、リクエストによって評価されるオペレーションです。 -
リソース (
resource) は、アクションがアクセスするコンポーネントです。 -
エンティティのリスト (
entityList) には、リクエストの評価に必要なすべてのエンティティが含まれます。
従業員が自分の給与を表示できるビジネスルールを満たすために、次のような Verified Permissions ポリシーを指定できます。
permit ( principal, action == Action::"viewSalary", resource ) when { principal == resource.owner };
このポリシーは、 Actionが ALLOWでありviewSalary、リクエスト内のリソースにプリンシパルと等しい属性所有者があるかどうかを に評価します。たとえば、Bob が給与レポートをリクエストしたログインユーザーであり、給与レポートの所有者でもある場合、ポリシーは に評価されますALLOW。
次の認可リクエストが Verified Permissions に送信され、サンプルポリシーによって評価されます。この例では、Bob はviewSalaryリクエストを行うログインユーザーです。したがって、Bob はエンティティタイプ のプリンシパルですEmployee。Bob が実行しようとしているアクションは viewSalary,でviewSalary、表示されるリソースはタイプ Salary-BobですSalary。Bob がSalary-Bobリソースを表示できるかどうかを評価するには、 タイプを の値 Bob (プリンシパル) Employee と タイプを持つリソースの所有者属性にリンクするエンティティ構造を指定する必要がありますSalary。この構造は で指定します。ここでentityList、 に関連付けられた属性Salaryには、タイプ Employeeと値 entityIdentifierを含む を指定する所有者が含まれますBob。Verified Permissions は、認可リクエストでprincipal提供された を、決定を行うためにSalaryリソースに関連付けられているowner属性と比較します。
{ "policyStoreId": "PAYROLLAPP_POLICYSTOREID", "principal": { "entityType": "PayrollApp::Employee", "entityId": "Bob" }, "action": { "actionType": "PayrollApp::Action", "actionId": "viewSalary" }, "resource": { "entityType": "PayrollApp::Salary", "entityId": "Salary-Bob" }, "entities": { "entityList": [ { "identifier": { "entityType": "PayrollApp::Salary", "entityId": "Salary-Bob" }, "attributes": { "owner": { "entityIdentifier": { "entityType": "PayrollApp::Employee", "entityId": "Bob" } } } }, { "identifier": { "entityType": "PayrollApp::Employee", "entityId": "Bob" }, "attributes": {} } ] } }
Verified Permissions への認可リクエストは出力として以下を返します。 属性decisionは ALLOWまたは ですDENY。
{ "determiningPolicies": [ { "determiningPolicyId": "PAYROLLAPP_POLICYSTOREID" } ], "decision": "ALLOW", "errors": [] }
この場合、Bob は自分の給与を表示しようとしていたため、Verified Permissions に送信された認可リクエストは に評価されますALLOW。ただし、目的は Verified Permissions を使用して 2 つのビジネスルールを適用することでした。以下を示すビジネスルールも当てはまります。
従業員は、自分の部下の給与を表示できます。
このビジネスルールを満たすには、別のポリシーを指定できます。次のポリシーは、アクションが ALLOWでありviewSalary、リクエストのリソースにプリンシパルとowner.manager等しい属性があるかどうかを に評価します。たとえば、Alice が給与レポートをリクエストしたログインユーザーで、Alice がレポートの所有者のマネージャーである場合、ポリシーは に評価されますALLOW。
permit ( principal, action == Action::"viewSalary", resource ) when { principal == resource.owner.manager };
次の認可リクエストが Verified Permissions に送信され、サンプルポリシーによって評価されます。この例では、Alice はviewSalaryリクエストを行うログインユーザーです。したがって、Alice はプリンシパルであり、エンティティはタイプ ですEmployee。Alice が実行しようとしているアクションは でviewSalary、viewSalary表示されるリソースは の値Salaryを持つ タイプですSalary-Bob。Alice がSalary-Bobリソースを表示できるかどうかを評価するには、 型のEmployee値を Alice manager 属性にリンクするエンティティ構造を指定する必要があります。このエンティティ構造は、 型の owner 属性を の値Salaryに関連付ける必要がありますSalary-Bob。この構造を で指定します。ここでentityList、 に関連付けられた属性Salaryには、タイプ Employeeと値 entityIdentifierを含む を指定する所有者が含まれますBob。Verified Permissions はまず owner 属性をチェックし、 属性は タイプEmployeeと値 に評価されますBob。次に、Verified Permissions は、関連付けられたmanager属性を評価しEmployee、提供されたプリンシパルと比較して認可の決定を行います。この場合、 principal と resource.owner.manager 属性は同等ALLOWであるため、決定は です。
{ "policyStoreId": "PAYROLLAPP_POLICYSTOREID", "principal": { "entityType": "PayrollApp::Employee", "entityId": "Alice" }, "action": { "actionType": "PayrollApp::Action", "actionId": "viewSalary" }, "resource": { "entityType": "PayrollApp::Salary", "entityId": "Salary-Bob" }, "entities": { "entityList": [ { "identifier": { "entityType": "PayrollApp::Employee", "entityId": "Alice" }, "attributes": { "manager": { "entityIdentifier": { "entityType": "PayrollApp::Employee", "entityId": "None" } } }, "parents": [] }, { "identifier": { "entityType": "PayrollApp::Salary", "entityId": "Salary-Bob" }, "attributes": { "owner": { "entityIdentifier": { "entityType": "PayrollApp::Employee", "entityId": "Bob" } } }, "parents": [] }, { "identifier": { "entityType": "PayrollApp::Employee", "entityId": "Bob" }, "attributes": { "manager": { "entityIdentifier": { "entityType": "PayrollApp::Employee", "entityId": "Alice" } } }, "parents": [] } ] } }
この例のこれまでのところ、 viewSalaryメソッドに関連する 2 つのビジネスルールが提供されました。従業員は自分の給与を表示でき、従業員は自分の部下の給与を表示でき、Verified Permissions は各ビジネスルールの条件を個別に満たすポリシーとして確認できます。単一の Verified Permissions ポリシーを使用して、両方のビジネスルールの条件を満たすこともできます。
従業員は、自分の給与と、自分の部下の給与を表示できます。
前の認可リクエストを使用する場合、次のポリシーは、アクションALLOWが viewSalaryであり、リクエスト内のリソースに owner.managerと等しい属性があるかprincipal、 とowner等しい属性があるかを に評価しますprincipal。
permit ( principal, action == PayrollApp::Action::"viewSalary", resource ) when { principal == resource.owner.manager || principal == resource.owner };
たとえば、Alice が給与レポートをリクエストするログインユーザーであり、Alice が所有者のマネージャーまたはレポートの所有者である場合、ポリシーは に評価されますALLOW。
Cedar ポリシーで論理演算子を使用する方法の詳細については、Cedar ドキュメント