SEC02-BP06 ユーザーグループと属性を採用する - セキュリティの柱
実装のガイダンスリソース

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

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

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

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

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

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

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

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

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

  • AWS IAM アイデンティティセンターセッションを使用する際のロールチェーンの使用

このベストプラクティスを活用しない場合のリスクレベル: 中

実装のガイダンス

AWS アクセス許可は、ユーザー、グループ、ロール、リソースなどのプリンシパルに関連付けられている、ポリシーと呼ばれるドキュメントで定義されます。職務、ワークロード、および SDLC 環境に基づいてアクセス許可の割り当て (グループ、アクセス許可、アカウント) を整理することにより、アクセス許可管理をスケールすることができます。従業員に対しては、アクセス対象のリソースではなく、ユーザーが組織で果たす職務に基づいてグループを定義できます。例えば、WebAppDeveloper グループには、開発アカウント内で Amazon CloudFront などのサービスを設定するためのポリシーがアタッチされている場合があります。AutomationDeveloper グループには、WebAppDeveloper グループと重複するアクセス許可が付与されている場合があります。これらの共通のアクセス許可は、両方の職務のユーザーを CloudFrontAccess グループに所属させるのではなく、別々のポリシーで取得して両方のグループに関連付けることができます。

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

実装手順

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

    1. SEC02-BP04 一元化された ID プロバイダーを利用するのガイダンスに従って、ID プロバイダー内、IAM アイデンティティセンター内、または特定のアカウント内の IAM ユーザーグループを使用し、グループと属性を定義する必要があるかどうかを判断します。

  2. グループの定義:

    1. 必要な職務とアクセス範囲に基づいてグループを決定します。グループを効果的に整理するために、階層構造や命名規則を使用することを検討してください。

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

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

  3. 属性の定義:

    1. 外部の ID プロバイダーを使用する場合、SCIM プロトコルと SAML 2.0 プロトコルは両方とも一部の属性をデフォルトで提供します。追加の属性は、https://aws.amazon.com/SAML/Attributes/PrincipalTag 属性名と SAML アサーションを使用して定義し、渡すことができます。カスタム属性の定義と設定に関するガイダンスについては、ID プロバイダーのドキュメントを参照してください。

    2. IAM アイデンティティセンター内でロールを定義する場合は、属性ベースのアクセス制御 (ABAC) 機能を有効にし、必要に応じて属性を定義します。組織の構造またはリソースのタグ付け方法に沿った属性を検討してください。

IAM アイデンティティセンターで割り当てられた IAM ロールから IAM ロールチェーンが必要な場合は、source-identity や principal-tags などの値は反映されません。詳細については、「アクセスコントロールのための属性の有効化と設定」を参照してください。

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

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

    2. ABAC ポリシーを定義する場合は、ABAC 認可のベストプラクティスと例のガイダンスに従ってください。

    3. 組織のニーズの変化に応じてグループと属性の構造を定期的に確認し、更新して、最適な権限管理を確保します。

リソース

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

関連ドキュメント:

関連動画: