Amazon Web Services ブログ
Amazon Verified Permissions によりアプリケーションの認証を管理する方法を簡素化 — 一般に利用できるようになりました
新しいアプリケーションを開発したり、既存のアプリケーションを新しい環境に統合したりする場合、ユーザーの認証と承認を正しく実装するには多大な労力が必要です。以前は独自の認証システムを構築していましたが、現在では Amazon Cognito などの外部 ID プロバイダーを使用できます。しかし、承認ロジックは通常、コードで実装されます。
これは、すべてのユーザーが職務のロールが割り当てられた状態から始めるだけで十分である可能性があります。ただし、時間が経つにつれて、これらのアクセス許可はますます複雑になります。アクセス許可がよりきめ細かくなるにつれて、ロールの数も増えます。新しいユースケースにより、カスタムアクセス許可の必要性が高まっています。例えば、1 人のユーザーが別のロールを持つ別のユーザーとドキュメントを共有したり、サポートエージェントが問題を解決するために顧客アカウントへの一時的なアクセスを必要としたりする場合があります。コード内でアクセス許可を管理するとエラーが発生しやすくなり、アクセス許可を監査したり、誰が何にアクセスできるかを決定したりする際に大きな問題が生じます。特に、これらのアクセス許可がさまざまなアプリケーションで明示されていて、複数のプログラミング言語を使用している場合などです。
re:Invent 2022 では、あらゆる規模で使用できるアプリケーションのためのきめ細かなアクセス許可および承認サービスである Amazon Verified Permissions のプレビューを紹介しました。Amazon Verified Permissions は、アクセス許可をポリシーストアに一元化し、デベロッパーがそれらのアクセス許可を使用してアプリケーション内のユーザーアクションを承認できるようにします。ID プロバイダーが認証を簡素化する方法と同様に、ポリシーストアでは一貫性のあるスケーラブルな方法で承認を管理できます。
きめ細かなアクセス許可を定義するために、Amazon Verified Permissions では、アクセス制御用のオープンソースのポリシー言語および Software Development Kit (SDK) である Cedar を使用しています。プリンシパルタイプ、リソースタイプ、および有効なアクションの観点から承認モデルのスキーマを定義できます。このようにして、ポリシーが作成されると、そのポリシーが承認モデルと照らし合わせて検証されます。テンプレートを使用して、同様のポリシーの作成を簡素化できます。ポリシーストアへの変更は監査されるため、誰がいつ変更したかを確認できます。
その後、AWS SDK を介してアプリケーションを Amazon Verified Permissions に接続し、アクセスリクエストを承認できます。承認リクエストごとに、関連するポリシーが取得および評価され、アクションが許可されるかどうかが決定されます。これらの承認リクエストを再現して、アクセス許可が目的どおりに機能することを確認できます。
本日は、Amazon Verified Permissions が、新しい機能とシンプルなユーザーエクスペリエンスを備えて AWS マネジメントコンソールで一般に利用できるようになったことをお伝えでき、嬉しく思います。
実際にどのように使用できるか見てみましょう。
Amazon Verified Permissions によるポリシーストアの作成
Amazon Verified Permissions コンソールで、[ポリシーストアを作成] を選択します。ポリシーストアは、ポリシーとスキーマを保存する論理コンテナです。承認の決定は、ポリシーストアに存在するすべてのポリシーに基づいて行われます。
新しいポリシーストアを設定するには、さまざまな方法を使用できます。ガイド付きセットアップ、サンプルポリシーストア (写真共有アプリ、オンラインストア、タスクマネージャーなど)、または空のポリシーストア (上級ユーザーにお勧め) から始めることができます。[ガイド付きセットアップ] を選択し、スキーマ (MyApp
) の名前空間を入力して [次へ] を選択します。
リソースは、プリンシパルが処理できるオブジェクトです。私のアプリケーションには、ドキュメント
(リソース) の作成、読み取り、更新、削除ができるユーザー
(プリンシパル) があります。ドキュメント
リソースタイプの定義を開始します。
リソースタイプの名前を入力し、次の 2 つの必須属性を追加します。
owner
(文字列) では、ドキュメントの所有者を指定します。isPublic
(ブール値) では、誰でも読める公開ドキュメントにフラグを付けます。
ドキュメント
リソースタイプには、次の 4 つのアクションを指定します。
DocumentCreate
DocumentRead
DocumentUpdate
DocumentDelete
ドキュメント
でこれらのアクションを使用するプリンシパルタイプの名前として [ユーザー
] を入力します。次に、[次へ] を選択します。
次に、ユーザー
プリンシパルタイプを設定します。カスタム設定を使用して外部 ID ソースを統合することもできますが、今回は、以前に作成した Amazon Cognito ユーザープールを使用します。[ユーザープールを接続] を選択します。
ダイアログで、ユーザープールが配置されている [ AWS リージョン] を選択して、ユーザープール ID を入力し、[接続] を選択します。
Amazon Cognito ユーザープールが接続されたので、クライアントアプリケーション ID を検証することで別のレベルの保護を追加できます。今のところ、このオプションは使用しないことを選択します。
[プリンシパル属性] セクションで、ポリシー内の属性ベースのアクセス制御に使用する予定である属性を選択します。OpenID Connect 仕様に従ってエンドユーザーを識別するために使用される sub
(サブジェクト ) を選択します。さらに多くの属性を選択できます。例えば、ポリシーで email_verified
を使用して、E メールが検証された Amazon Cognito ユーザーのみにアクセス許可を付与できます。
ポリシーストアの作成の一環として、ユーザー danilop
に doc.txt
ドキュメントへの読み取りアクセス権を付与する最初のポリシーを作成します。
次のコードでは、コンソールに Cedar 言語を使用して作成されたポリシーのプレビューが表示されます。
最後に、[ポリシーストアを作成] を選択します。
ポリシーストアへのアクセス許可の追加
ポリシーストアが作成されたので、ナビゲーションペインで [ポリシー] を選択します。[ポリシーを作成] ドロップダウンで、[静的ポリシーを作成] を選択します。静的ポリシーには、評価に必要なすべての情報が含まれています。2 番目のポリシーでは、すべてのユーザーが公開ドキュメントを読むことを許可します。デフォルトではすべてが禁止されているので、[ポリシー効果] で [許可] を選択します。
[ポリシー範囲] で、[すべてのプリンシパル] と [すべてのリソース ] を選択したままにして、[DocumentRead
] アクションを選択します。[ポリシー] セクションで、isPublic
が true
と等しいリソースにアクセス許可を制限するように、when
条件句を変更します。
ポリシーの説明を入力し、[ポリシーを作成] を選択します。
3 番目のポリシーでは、ドキュメントの所有者へのフルアクセスを許可する静的ポリシーをもう 1 つ作成します。ここでも、[ポリシー効果] で [許可] を選択し、[ポリシー範囲] で、[すべてのプリンシパル] と [すべてのリソース] を選択したままにします。今回も、[すべてのアクション] を選択したままにします。
[ポリシー] セクションで、所有者
がプリンシパルの sub
と等しいリソースにアクセス許可を制限するように、when
条件句を変更します。
私のアプリケーションでは、ドキュメントの所有者ではない特定のユーザーに読み取りアクセスを許可する必要があります。これを簡素化するために、ポリシーテンプレートを作成します。ポリシーテンプレートを使用すると、プリンシパルやリソースなどの一部の値にプレースホルダーを使用するテンプレートからポリシーを作成できます。テンプレートのプレースホルダーは、?
文字で始まるキーワードです。
ナビゲーションペインで、[ポリシーテンプレート] を選択し、次に [ポリシーテンプレートを作成] を選択します。説明を入力して、次のポリシーテンプレート本体を使用します。このテンプレートを使用する場合、?principal
と ?resource
プレースホルダーの値を指定できます。
ポリシーテンプレートの作成を完了します。今は、このテンプレートを使用してポリシーの作成を簡素化しています。ナビゲーションペインで [ポリシー] を選択し、次に [ポリシーを作成] ドロップダウンで [テンプレートにリンクされたポリシーを作成] を選択します。作成したポリシーテンプレートを選択し、[次へ] を選択します。
ユーザー (danilop
) に特定のドキュメント (new-doc.txt
) へのアクセス権を付与するには、次の値を渡すだけです (MyApp
はポリシーストアの名前空間であることに注意してください)。
- プリンシパルの場合:
MyApp::User::"danilop"
- リソースの場合:
MyApp::Document::"new-doc.txt"
ポリシーの作成が完了しました。今が、ポリシーが期待どおりに機能するかどうかをテストするときです。
コンソールでのポリシーのテスト
私のアプリケーションでは、AWS SDK を使用して承認リクエストを実行できます。コンソールでは、アプリケーションの動作をシミュレートする方法が提供されます。ナビゲーションペインで [テストベンチ] を選択します。テストを簡素化するために、[ビジュアルモード] を使用します。別の方法として、SDK と同じ JSON 構文を使用するオプションもあります。
プリンシパルとして、janedoe
ユーザーを渡します。リソースとして、requirements.txt
を使用しています。これは公開ドキュメント (isPublic
が false
) ではなく、所有者
属性は janedoe
のsub
と等しくなります。アクションでは、 MyApp::Action::"DocumentUpdate"
を選択します。
承認リクエストを実行すると、リクエストに関連付けられたプリンシパルとリソースに関する詳細情報を追加のエンティティに渡すことができます。今のところ、この部分は空のままにします。
現在のポリシーに基づく決定を確認するには、上部の [承認リクエストを実行] を選択します。予想どおり、決定は許可になります。ここでは、承認リクエストによってどのポリシーが満たされたかを確認することもできます。この場合、ドキュメントの所有者へのフルアクセスを許可することがポリシーです。
他の値をテストできます。ドキュメントの所有者とアクションを DocumentRead
に変更すると、決定は拒否になります。次に、リソース属性の isPublic
を true
に設定すると、すべてのユーザーに公開ドキュメントの読み取りを許可するポリシーがあるため、決定は許可になります。
アクセス許可でのグループの処理
私のアプリケーションの管理ユーザーは、どのドキュメントも削除できる必要があります。そのために、管理者ユーザー用のロールを作成します。まず、ナビゲーションペインで [スキーマ] を選択し、次に [スキーマを編集] を選択します。エンティティタイプのリストから、新しいエンティティタイプを追加することを選択します。[タイプ名] として [ロール
] を使用して追加します。次に、エンティティタイプで [ユーザー
] を選択して編集し、親としてロール
を追加します。変更を保存して、次のポリシーを作成します。
テストベンチで、認証リクエストを実行して、ユーザー jeffbarr
が (DocumentDelete
) リソース doc.txt
を削除できるかどうかを確認しています。彼はリソースの所有者ではないため、リクエストは拒否されます。
次に、追加エンティティに、jeffbarr
を識別子として MyApp::User
エンティティを追加します。親として、admin
を識別子として MyApp::Role
エンティティを追加して確認します。コンソールに、MyApp::Role::"admin"
というエンティティが参照されているけれども、追加のエンティティデータには含まれていないという警告が表示されます。これを追加して、この問題を修正することを選択します。
認証リクエストを再度実行し、追加されたエンティティに従って、プリンシパル (jeffbarr
) が管理者
であるため、リクエストが許可されました。
アプリケーションでの Amazon Verified Permissions の使用
私のアプリケーションでは、isAuthorized
API アクション (または、プリンシパルが外部のアイデンティティソースからのものである場合は isAuthrizedWithToken
) を使用して承認リクエストを実行できます。
例えば、次の Python コードでは、AWS SDK for Python (Boto3) を使用して、ユーザーがドキュメントへの読み取りアクセス権を持っているかどうかを確認します。承認リクエストでは、先ほど作成したポリシーストアを使用します。
import boto3
import time
verifiedpermissions_client = boto3.client("verifiedpermissions")
POLICY_STORE_ID = "XAFTHeCQVKkZhsQxmAYXo8"
def is_authorized_to_read(user, resource):
authorization_result = verifiedpermissions_client.is_authorized(
policyStoreId=POLICY_STORE_ID,
principal={"entityType": "MyApp::User", "entityId": user},
action={"actionType": "MyApp::Action", "actionId": "DocumentRead"},
resource={"entityType": "MyApp::Document", "entityId": resource}
)
print('Can {} read {} ?'.format(user, resource))
decision = authorization_result["decision"]
if decision == "ALLOW":
print("Request allowed")
return True
else:
print("Request denied")
return False
if is_authorized_to_read('janedoe', 'doc.txt'):
print("Here's the doc...")
if is_authorized_to_read('danilop', 'doc.txt'):
print("Here's the doc...")
このコードを実行すると、予想するとおり、出力は以前に実行したテストと一致しています。
利用可能なリージョンと料金
Amazon Verified Permissions は、現在、中国に拠点を置くものを除くすべての商用 [AWS リージョン] でご利用いただけます。
Amazon Verified Permissions では、サービスに対して行われた承認リクエストと API 呼び出しの数に基づいて、使用した分のみお支払いいただきます。詳細については、[Amazon Verified Permissions の料金] を参照してください。
Amazon Verified Permissions を使用すると、Cedar ポリシー言語を使用してきめ細かなアクセス許可を設定し、アプリケーションのコードを簡素化できます。このように、アクセス許可は一元化されたストアで管理され、監査が容易になります。ここでは、自動推論と差分テストを使用して Cedar を構築した方法について詳しく読むことができます。
Amazon Verified Permissions を使用してアプリケーションの認証を管理します。
– Danilo
原文はこちらです。