ベストプラクティス

このセクションでは、このガイドの要点をいくつか示します。各ポイントの詳細な説明については、対応するセクションへのリンクに従ってください。

アプリケーションに適したアクセスコントロールモデルを選択する

このガイドでは、いくつかのアクセスコントロールモデルについて説明します。アプリケーションとビジネス要件に応じて、自分に合ったモデルを選択する必要があります。これらのモデルを使用してアクセスコントロールのニーズを満たす方法と、選択したアプローチを変更する必要があるアクセスコントロールのニーズがどのように変化するかを検討してください。

PDP の実装

ポリシー決定ポイント (PDP) は、ポリシーまたはルールエンジンとして特徴付けることができます。このコンポーネントは、ポリシーまたはルールを適用し、特定のアクセスを許可するかどうかの決定を返す責任があります。PDP を使用すると、アプリケーションコードの認可ロジックを別のシステムにオフロードできます。これにより、アプリケーションコードを簡素化できます。また、APIs、マイクロサービス、バックエンド for Frontend (BFF) レイヤー、またはその他のアプリケーションコンポーネントの承認を決定するためのeasy-to-useべき等インターフェイスも提供します。PDP を使用すると、アプリケーション全体でテナンシー要件を一貫して適用できます。

アプリケーション内のすべての API に PEPsを実装する

ポリシー適用ポイント (PEP) を実装するには、アプリケーションでアクセスコントロールの適用を行う場所を決定する必要があります。最初のステップとして、PEPs。PEPs。

アプリケーションが API を公開する場合は、その API に対する認可とアクセスコントロールが必要です。

PDP のポリシーエンジンとして Amazon Verified Permissions または OPA を使用することを検討してください。

Amazon Verified Permissions には、カスタムポリシーエンジンよりも利点があります。これは、構築するアプリケーションのスケーラブルできめ細かなアクセス許可管理および認可サービスです。高レベルの宣言型オープンソース言語 Cedar でのポリシーの記述をサポートしています。その結果、Verified Permissions を使用してポリシーエンジンを実装する場合、独自のソリューションを実装するよりも開発作業が少なくて済みます。さらに、Verified Permissions はフルマネージド型であるため、基盤となるインフラストラクチャを管理する必要はありません。

Open Policy Agent (OPA) には、カスタムポリシーエンジンよりも利点があります。Rego による OPA とそのポリシー評価は、高レベルの宣言言語でのポリシーの記述をサポートする、柔軟で構築済みのポリシーエンジンを提供します。これにより、ポリシーエンジンの実装に必要な労力のレベルは、独自のソリューションを構築するよりも大幅に少なくなります。さらに、OPA はすぐに十分にサポートされている認可標準になりつつあります。

DevOps、モニタリング、ログ記録用の OPA のコントロールプレーンを実装する

OPA はソース管理を通じて認可ロジックの変更を更新および追跡する手段を提供しないため、これらの機能を実行するコントロールプレーンを実装することをお勧めします。これにより、特に OPA が分散システムで動作している場合に、更新をより簡単に OPA エージェントに分散できるため、OPA を使用する管理上の負担が軽減されます。さらに、コントロールプレーンを使用して、集計用のログを収集し、OPA エージェントのステータスをモニタリングできます。

Verified Permissions でログ記録とオブザーバビリティ機能を設定する

Verified Permissions では、オブザーバビリティ機能に簡単にアクセスできます。セキュリティインシデントや監査リクエストにすばやく対応できるように AWS CloudTrail、、、Amazon CloudWatch ロググループ、S3 バケット、または Amazon Data Firehose 配信ストリームに対するすべてのアクセス試行を記録するようにサービスを設定できます。さらに、 を通じてサービスの正常性をモニタリングできます AWS Health Dashboard。Verified Permissions はマネージドサービスであるため、そのヘルスは によって維持され AWS、他の AWS マネージドサービスを使用してオブザーバビリティ機能を設定できます。

CI/CD パイプラインを使用して、Verified Permissions でポリシーストアとポリシーをプロビジョニングおよび更新する

Verified Permissions はマネージドサービスであるため、更新を実行するためにコントロールプレーンやエージェントを管理、設定、または維持する必要はありません。ただし、継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインを使用して、 AWS SDK を使用して Verified Permissions ポリシーストアとポリシー更新のデプロイを管理することをお勧めします。この作業により、Verified Permissions リソースに変更を加えると、手動作業がなくなり、オペレーターエラーが発生する可能性が低くなります。

承認の決定に外部データが必要かどうかを判断し、それに対応するモデルを選択する

PDP が JSON ウェブトークン (JWT) に含まれるデータのみに基づいて承認の決定を行うことができる場合、通常、これらの決定を支援するために外部データをインポートする必要はありません。Verified Permissions または OPA を PDP として使用している場合、このデータが JWT に含まれていなくても、リクエストの一部として渡される追加の入力を受け入れることもできます。Verified Permissions では、追加データにコンテキストパラメータを使用できます。OPA では、JSON データをオーバーロード入力として使用できます。JWT を使用する場合、コンテキストまたはオーバーロードの入力メソッドは、通常、別のソースで外部データを維持するよりもはるかに簡単です。認可の決定を行うためにより複雑な外部データが必要な場合、OPA は外部データを取得するためのいくつかのモデルを提供し、Verified Permissions は認可サービスで外部ソースを参照することで、認可リクエストのデータを補完できます。