Amazon Verified Permissions によるビジネスアプリケーションにおけるエンタイトルメントサービスの構築

Amazon Verified Permissionsは、アプリケーション内の承認管理のプロセスを簡素化するために設計されています。本ブログでは、このサービスが様々なビジネスケースにどのように適用できるか理解いただくことを目的としています。

通常、企業はビジネスアプリケーション内に埋め込まれたカスタム権限ロジックを使用しています。これは最も一般的なアプローチで、ユーザのアクセス承認を管理するためのカスタムコードを記述する必要があります。これから、アプリケーション開発者とアクセス管理者がアプリケーション内でユーザのアクセス承認を取り扱う際に直面する一般的な課題と、Amazon Verified Permissionsがこれらの課題を解決する方法について説明します。そして、支払管理などのユースケースにVerified Permissions を組み込むための統合ガイドを提供します。最後に、きめ細かく、様々なケースに適応でき、アプリケーションの外部から管理されるアクセス制御システムの利点について議論します。

このブログ記事は、アクセスポリシーの管理を包括的かつ集約的なアプローチで行い、管理上のオーバーヘッドを軽減し、LoB (Line of Business) のユーザーがアプリケーション権限ポリシーを定義、管理、適用できるようにすることを目的としています。

エンタイトルメントシステムの構築に伴う課題

エンタイトルメントとは、アプリケーション内で各ユーザが何ができて何ができないかを決定するルールのことです。図1は、アプリケーションに組み込まれたコンポーネントと複数のデータストアに格納された、一般的なエンタイトルメントシステムのアーキテクチャを示しています。

図1: 典型的なエンタイトルメントシステム

独自の承認管理システムを作成することは、その有用性を確認するにあたって時間や専門知識が必要な、多くのリソースがかかる作業となります。企業は独自のエンタイトルメント管理システムを構築する際に、複雑性、セキュリティリスク、パフォーマンス、スケーラビリティ不足など多くの課題に直面します。これらの課題について詳しく見ていきましょう。

データの複雑性 – エンタイトルメントの決定は、ユーザーのロール、グループとの紐付き、プロダクトをどのように操作できるかなど、複雑なデータ関係に基づいて行われます。この複雑性の管理は困難で、特に多くのユーザー、グループ、プロダクトを持つ大規模な組織ではその管理はさらに難しくなります。
コンプライアンスとセキュリティ – エンタイトルメントシステムの構築には、コンプライアンス規制とセキュリティベストプラクティスの両方を慎重に考慮する必要があります。お客様のデータを保護し、セキュアな通信プロトコルを実装し、潜在的なセキュリティ上の脆弱性に対処する必要があります。
スケーラビリティ – 権限管理システムは、多数のユーザーとトランザクションを処理できるようスケールする必要があります。特に、サービスが重要なリソースへのアクセスを制御するために使用される場合は、この点が課題となります。
パフォーマンスと可用性 – エンタイトルメントサービスは、リアルタイムな判断を下すために頻繁に使用されるため、高性能である必要があります。加えて、お客様が自組織のエンタイトルメントが正しいと自信を持てるよう、信頼性や一貫性を備える必要があります。

Amazon Verified Permissionsを使用したエンタイトルメントサービスのアーキテクチャ設計

Amazon Verified Permissionsは、スケーラブルな権限管理ときめ細かな認可を提供するサービスであり、アプリケーションのコードに埋め込まれた認可の実装に大きく依存することなく、アプリケーションの構築とモダナイゼーションを支援します。Verified Permissionsを使用して、エンタイトルメントの管理方法について言及します。

ポリシーの作成と運用

Verified Permissionsは、ユーザーが特定のタスクを承認されるか禁止される権限をポリシーとして開発者が表現できるポリシー言語であるCedarを使用しています。一元的なポリシーベースの認証システムにより、開発者はアプリケーション間で一貫した方法できめ細かな認証を定義および管理でき、コードを変更する必要なく権限ルールを変更でき、権限をコードから外に移動することで可視性が向上します。

Verified Permissionsを使用することで、ロールベースアクセスコントロール(RBAC)と属性ベースアクセスコントロール(ABAC)の特徴を取り入れた特定の権限ポリシーを作成できます。このアプローチにより、最小権限の原則を優先しながらきめ細かなコントロールを実装できます。

ユースケース1:メアリーは事務員として働いており、支払いの提出と閲覧ができます。彼女の支払い管理システム内のロールは複数のアクションを許可しており、この役割のポリシーは以下の通り定義できます。

permit (
    principal,
    action in [
        PaymentManager::Action::"SubmitPayment",
        PaymentManager::Action::"UpdatePayment",
        PaymentManager::Action::"ListPayment"
    ],
    resource
)
when { principal.role == "clerk" };

反対に、シャーリーは監査役で、支払いのリストアップのみが許可されています。この役割のポリシーは以下の通りです。

permit (
    principal,
    action in [PaymentManager::Action::"ListPayment"],
    resource
)
when { principal.role == "auditor" };

支払いシステムは、主体、アクション、リソース、およびエンティティデータをVerified Permissionsに渡します。ユーザ情報がアプリケーション内で明示的に定義されていない場合は、支払いシステムはアイデンティティプロバイダやデータベースなどのデータストアからそれを取得する必要があります。

次に、Verified Permissionsは呼び出し元と対象となるリソースに影響するポリシーを組み立て、アクションを承認するか拒否するかの決定を下します。決定が下されると、それはアプリケーションに伝えられ、アプリケーションはその決定を強制できるようになります。

図2から分かるように、メアリーは「事務員」の役割を持ち、前述のポリシーがこのアクションを承認しているため、支払いの提出にアクセスできます。

図 2: テストベンチを使用した、メアリーが支払いを提出できるかどうかのテスト

シャーリーは「監査人」という役割で支払いを提出できず、図3で示されるようにアクションが拒否されました。

図3:テストベンチを使用した、シャーリーが支払いを提出できるかのテスト

ただし、図4に示すように、前述のポリシーではこのアクションが承認されているため、支払いを一覧表示することはできます。

図 4: テストベンチを使用した、シャーリーが支払いを一覧表示できるかどうかのテスト

ユースケース2:財務部長のジェーンが休暇中、支払システムアプリケーションを使用して、111222333という高額利用のアカウントにおけるアクセス権限を、財務部長代理のジョンに委任します。テンプレートからポリシーを作成することで、ジェーンの直接的な立会いなしにも関わらず、ジョンに支払いの承認権限を付与します。

支払いの承認ポリシーテンプレート:図5は、支払いを承認するためのサンプルポリシーテンプレートを示しています。このテンプレートを使用して作成されたポリシーを用い、以下のとおり、リソースの支払い承認権限をプリンシパルに提供します。

permit (
    principal == ?principal,
    action in [PaymentManager::Action::"ApprovePayment"],
    resource == ?resource
);

図 5: ポリシーテンプレートの作成

テンプレートからポリシーを作成:図6は、前述のテンプレートを使用して作成されたポリシーを示しています。渡す必要があるパラメータは、プリンシパルとリソース情報です。このユースケースの場合、プリンシパルは「ジョン」で、リソースはアカウント「111222333」となっており、ジョンがそのアカウントの支払い承認を可能にしています。(AWSでは、プリンシパルとして統合的で一意な識別子(Universally Unique Identifier, UUID)の使用を推奨していますが、このブログ記事では読みやすさのため「ジョン」が使用されています。)

図 6: テンプレートからのポリシーの作成

ポリシーを評価:想定どおり、ジョンにはアカウント 111222333 の支払いを承認するためのアクセス権限が付与されます (図 7 を参照)。

図 7: テストベンチを使用した、ジョンが支払いを承認できるかどうかのテスト

Verified Permissions を用いたエンタイトルメントサービスの構築

Verified Permissions では、認可機能を外部化し、ポリシーの管理と運用を中央集権化したエンタイトルメントサービスを構築できます。これにより、Verified Permissionsが提供する基盤となる権限管理を活用しながら、特定のアプリケーション要件に合わせてアクセス制御を調整することができます。

既存のエンタイトルメントサービスをVerified Permissionsと統合する

既存のエンタイトルメントサービスをVerified Permissionsと統合する方法が図8に示されています。エンタイトルメントサービスの基盤の実装においては、標準的なエンタープライズテクノロジースタックが使用されています。ユーザーとロール情報を格納するためにAmazon DynamoDBが使用されています。

図 8: エンタイトルメントサービスとVerified Permissionsの統合

既存のエンタイトルメントサービスをVerfied Permissionsとスムーズに統合するためのアプローチがこちらです:

承認の識別: まずは既存のエンタイトルメントサービスを評価し、現在使用している権限、様々な役割、アクション、リソースを特定することから始めます。権限の詳細なリストと、それぞれの目的をまとめてください。
ポリシーの構築: 前のステップで各ユースケースに対して特定した承認ルールをポリシーにマッピングします。インラインポリシーとポリシーテンプレートの両方を使用できます。AWS マネジメントコンソールのVerified Permissionsテストベンチを使用して作成したポリシーを評価します。
ポリシーの作成: ビジネスニーズに応じて、Verified Permissions内に1つまたは複数のポリシーストアを作成します。これらのポリシーストア内にポリシーを作成します。これは1回限りのタスクで、自動化を使用することをお勧めします。
エンタイトルメントサービスの更新: 既存のインターフェイスを使用して、現在のリクエストペイロードをVerified Permissionsの認可リクエストが期待する形式に変換するロジックを作成します。必要なパラメータを既存のインターフェイスに追加する必要があるかもしれません。この同じ変換ロジックをレスポンスペイロードにも適用します。Verified Permissionsの認可リクエストとレスポンス形式についてはこちらのドキュメントを参照してください。
Verified Permissionsとの統合: Verified Permissions APIまたはAWS SDKを使用して、エンタイトルメントサービスをVerified Permissionsと統合します。Amazon DynamoDBからユーザーロールを取得する、Verified Permissionsへの認可リクエストを行う、レスポンスを処理する、などのタスクが含まれます。
テスト: 権限変更後にサービス全体を徹底的にテストします。すべての機能が予期どおり動作し、Verified Permissionsのポリシーが正しく利用されていることを確認します。
デプロイ: サービスがレビュープロセスを通過したら、更新されたエンタイトルメントサービスと統合されたVerified Permissionsをロールアウトします。
モニタリングとメンテナンス: デプロイ後は、継続的にパフォーマンスをモニタリングし、フィードバックを収集します。状況に応じて、エンタイトルメントサービスのさらなる調整を実施します。
ドキュメントとサポート: エンタイトルメントサービスを使用する開発者向けに包括的なドキュメントを提供します。利用可能なエンドポイント、リクエストとレスポンスの形式、認可の要件について明確に説明します。

既存の権限サービスをサードパーティのエンタイトルメント管理システムと統合する場合においても、同様のアプローチをとることができます。

Amazon Verified Permissions を使用した AWS 上での新しいエンタイトルメントサービスの構築

図9の参考アーキテクチャは、Verified Permissionsを使用して新しいエンタイトルメントサービスを構築する方法を示しています。AWSのお客様はすでにAmazon Cognitoを簡易で高速な認証のために使用しています。Amazon Verified Permissionsにより、お客様はAmazon Cognitoが生成したID Tokenにユーザープロファイル属性を追加することで、既存のアプリケーションに簡易で高速な認可を追加できるようになります。

図9:Verified Permissionsを使用したエンタイトルメントサービス

図に示されているワークフローは以下の通りです:

お客様はAmazon Cognitoを使用してアプリケーションにサインインします。
認証が成功した場合、トークン生成前のLambda関数が起動します。
トークン生成前のLambda関数を使用して、Amazon Cognitoが生成するアイデンティティトークンをカスタマイズする前に、アイデンティティトークンに新しいクレームとしてユーザープロファイル属性を追加できます。この場合、トリガーはユーザープロファイル属性をアイデンティティトークンに新しいクレームとして追加するために使用されます。
- ユーザープロファイル属性はAmazon DynamoDBから取得されます。
- 属性はその後アイデンティティトークンに新しい主張として追加されます。
ユーザーはサインインした後、Amazon API Gateway を介してアプリケーション内の保護されたリソースへのアクセスをリクエストします。
Amazon API Gatewayは、Lambdaオーソライザーを使用して認可チェックを開始します。Lambdaオーソライザーは、Amazon Cognitoによって生成されたアイデンティティトークンを使用してカスタム認可スキームを実装できるAPI Gatewayの機能です。
Lambdaオーソライザーは、アイデンティティトークンから検証、デコード、ユーザープロファイル属性の取得を行います。
Lambda認可機能は、プリンシパル、アクション、リソース、ユーザープロファイル属性をエンティティとしてVerified Permissionsの認可APIに渡します。
Verified Permissionsによって返された判断に基づいて、リソースへのアクセスが承認または拒否されます。

エンタイトルメントサービスの一般的な落とし穴

エンタイトルメントサービスは複雑な場合がありますが、いくつかの共通のミスを避ければ、よりセキュアで使いやすいようにすることができます。

エンタイトルメントサービスの設定ミスはセキュリティ上の脆弱性を生み、データ漏洩を引き起こす可能性があります。エンタイトルメントサービスを慎重に設定し、ポリシーを定期的に見直して正しく最新の情報に更新されているか確認することが重要です。
ビジネスアプリケーションを初めて使用する時、ユーザーに過剰な承認を与えがちです。これはアプリケーションのセキュリティを低下させ管理を難しくします。ユーザーに必要最小限の承認のみを与えることが重要です。
特に承認の申請と管理に関わる場合には、ユーザーはエンタイトルメントサービスの正しい利用方法についてトレーニングを受ける必要があります。もしユーザーがこれらの作業を適切に行えない場合、システムの脆弱性の原因になる可能性があります。

結論

Amazon Verified Permissionsは、きめ細かなアクセス制御、柔軟な認可、アプリケーション外部で一元化されたアクセス制御を管理したい企業向けの包括的なソリューションです。このサービスにより、組織は新しいポリシーを環境全体に迅速かつ便利に適用できるため、ユーザー管理プロセスが合理化され、全体的なセキュリティが向上します。この記事では、アプリケーション内の権限管理に Verified Permissions を使用することの多くの利点が強調されています。このサービスをビジネスユースケースにどのように適用できるかを理解するうえで参考になれば幸いです。

AWS セキュリティに関するニュースをもっと知りたいですか？Xでフォローしてください。

翻訳はソリューションアーキテクトの高野が担当しました。原文はこちらです。

Amazon Web Services ブログ