SEC02-BP06 ユーザーグループと属性を採用する - AWS Well-Architected Framework
実装のガイダンスリソース

SEC02-BP06 ユーザーグループと属性を採用する

ユーザーグループと属性に従ってアクセス許可を定義すると、ポリシーの数と複雑度が軽減され、最小特権の原則を簡単に遵守できます。 ユーザーグループを使用して、多数のユーザーのアクセス許可をそれぞれが組織内で果たす職務に基づいて 1 か所で管理できます。 部門や場所などの属性は、ユーザーが同じような職務を果たすが、対象となるリソースのサブセットが異なる場合に、アクセス許可の範囲をさらに限定することができます。

期待される成果: 職務に基づくアクセス許可の変更を、その職務を果たすユーザー全員に適用できます。 グループのメンバーシップと属性によってユーザーのアクセス許可が管理されるため、個々のユーザーレベルでアクセス許可を管理する必要がなくなります。 ID プロバイダー (IdP) で定義したグループと属性が、AWS 環境に自動的に反映されます。

一般的なアンチパターン:

  • 個々のユーザーのアクセス許可を管理し、複数のユーザーで重複作業をしている。

  • グループの定義が大まか過ぎるため、アクセス許可の付与範囲が広過ぎる。

  • グループの定義が細か過ぎるため、メンバーシップに関する重複や混乱が生じている。

  • 代わりに属性を使用できる場面でグループを使用し、リソースの複数のサブセットに対してグループが持つアクセス許可が重複している。

  • 標準に準拠した ID プロバイダーの AWS 環境への統合によるグループ、属性、メンバーシップの管理を行っていない。

このベストプラクティスが確立されていない場合のリスクレベル: 中

実装のガイダンス

AWS のアクセス許可は、ユーザー、グループ、ロール、リソースなどのプリンシパルに関連付けられた、ポリシーと呼ばれるドキュメントで定義されます。 従業員に対しては、アクセス対象のリソースではなく、ユーザーが組織で果たす職務に基づいてグループを定義できます。例えば、WebAppDeveloper グループに、開発アカウント内で Amazon CloudFront などのサービスを設定するためのポリシーをアタッチできます。 AutomationDeveloper グループが持つ一部の CloudFront アクセス許可が、WebAppDeveloper グループと共通しているとしましょう。この場合、両方の職務を担うユーザーを CloudFrontAccess グループに所属させるのではなく、共通のアクセス許可を個別のポリシーで定義し、両方のグループに関連付けることができます。

グループに加えて、属性を使用してアクセス権限をさらに限定できます。例えば、WebAppDeveloper グループのユーザーに Project 属性を適用し、担当するプロジェクトに固有のリソースにアクセスを限定できます。 この手法を使用すれば、異なるプロジェクトで作業するアプリケーション開発者に対して、それ以外の点ではアクセス許可が同じ場合、別々のグループを用意する必要がなくなります。 アクセス許可ポリシーで属性を参照する方法は、そのソースによって異なります (フェデレーションプロトコル (SAML、OIDC、SCIM など) の一部として定義されているのか、カスタム SAML アサーションとして定義されているのか、または IAM Identity Center 内で設定されているのか)。

実装手順

  1. グループと属性を定義する場所を確保します。

    1. SEC02-BP04 一元化された ID プロバイダーを利用する のガイダンスに従って、グループと属性を ID プロバイダー内で定義する必要があるのか、IAM Identity Center 内で定義する必要があるのか、または特定のアカウント内の IAM user グループを使用する必要があるのかを判断できます。

  2. グループを定義します。

    1. 必要な職務とアクセス範囲に基づいてグループを決定します。 

    2. IAM Identity Center 内で定義する場合は、グループを作成し、アクセス許可セットを使用して、目的とするレベルのアクセス許可を関連付けます。

    3. 外部の ID プロバイダー内で定義する場合は、プロバイダーが SCIM プロトコルをサポートしているかどうかを確認し、IAM Identity Center 内で自動プロビジョニングを有効にすることを検討してください。 この機能は、プロバイダーと IAM Identity Center との間でグループの作成、メンバーシップ、削除を同期します。

  3. 属性を定義します。

    1. 外部の ID プロバイダーを使用する場合、SCIM プロトコルと SAML 2.0 プロトコルは両方とも一部の属性をデフォルトで提供します。 SAML アサーションで https://aws.amazon.com/SAML/Attributes/PrincipalTag 属性名を指定して、追加の属性を定義して渡すことができます。

    2. IAM Identity Center 内で定義する場合は、属性ベースのアクセス制御 (ABAC) 機能を有効にし、必要に応じて属性を定義します。

  4. グループと属性に基づいてアクセス許可の範囲を設定します。

    1. プリンシパルの属性と、アクセス対象のリソースの属性を比較する条件をアクセス許可ポリシーに含めることを検討してください。 例えば、PrincipalTag 条件キーの値が、同じ名前の ResourceTag キーの値と一致する場合にのみ、リソースへのアクセスを許可する条件を定義できます。

リソース

関連するベストプラクティス:

関連するドキュメント:

関連動画: