https://docs.aws.amazon.com/whitepapers/latest/saas-tenant-isolation-strategies/scaling-and-managing-pool-isolation-policies.html
Implementing pool isolation - Scaling and managing pool isolation policies
- IAM ポリシーは強力な分離構造を提供する一方で、SaaS プロバイダにスケーリング上の課題を突きつけることもある
- システム上に多数のテナントがあり、ポリシーの母数が多い場合、 IAM サービスの限界を超える可能性がある
- テナントの数やポリシーの複雑さが増すにつて、これらのポリシー管理が難しくなる可能性もある
- こういった場合、一部の SaaS プロバイダは実行jIに IAM ポリシーを生成して管理する方法について、別のアプローチを試みる
- この課題へのアプローチの一つは、IAM ポリシーをランタイムに生成するモデルへの移行である
- 現在の呼び出しコンテキストを調べ、必要な IAM ポリシーをその場で生成する仕組みをシステムに実装する、というアイデア
- これにより、ポリシーは IAM から移動し(一過性であるため)、すべてのテナントをサポートするのに必要なポリシー数の潜在的な制限に対処できるようになる
- 図15(元サイト参照のこと)は、このポリシー動的生成機構の概要を示している
- このフローは、先程の例と同じ分離マネージャから始まる
- しかし直接 IAM にアクセスし、アクセス・スコープの制限に必要なポリシーを取得するのではなく、一連のステップを踏んでポリシーを生成する
- 分離マネージャはまず、トークン自動販売機にリクエストを行い、テナント・スコープのトークンを取得する(step 1)
- テナント分離モデル用に事前に定義したテンプレートにアクセスするのはトークン自動販売機の責務(step 2)
- これらは従来の IAM ポリシーの動的な部分を設定できるテンプレートファイルだと考えられる
- ファイルの重要な要素(テナントのコンテキストを表す要素)は記入されていない
- たとえば、DynamoDB のテーブル名やテーブルのキー条件をテナント識別子で埋めることができる
- 必要なテンプレートが取得できたら、次はトークン生成機にトークンをリクエストする(step 3)
- このステップでは、テナント・コンテキストを渡す
- トークン生成機はテナントの詳細情報をテンプレートに埋め込み、完全に hydrated な IAM ポリシーを作成する(step 4-5)
- 最後にトークン生成機はこのポリシーを利用して、ポリシーに則ったスコープを付与されたトークンを生成する
- トークンは分離マネージャに戻され、各テナントのリソースにアクセス可能になる(step 6-7)
- これらのポリシーをテンプレートに移行することで、これらのポリシーがテナント分離要件を実施することを保証する責任を、あなたが負うことになる
- 理想的には、このメカニズムの詳細は開発者の視界にほとんど入らないため、何か問題が発生する可能性は低くなる
- このモデルの利点の一つは管理面
- 各テナントごとに個別のポリシーを作成する必要がないため、隔離ポリシーを変更する場合、その変更を適用するための経路がより簡単になる
- また、これらのポリシー・テンプレートのコンテンツ・ライフサイクル（独自のパイプラインを通じたバージョン管理とデプロイ）を管理することができる