SEC03-BP05 組織のアクセス許可ガードレールを定義する - AWS Well-Architected Framework
実装のガイダンス実装手順リソース

SEC03-BP05 組織のアクセス許可ガードレールを定義する

アクセス許可ガードレールを使用して、プリンシパルに付与できるアクセス許可の範囲を縮小します。アクセス許可ポリシーの評価チェーンにガードレールを組み込み、承認の決定を下す際に、プリンシパルの有効なアクセス許可を判断します。 ガードレールは階層型のアプローチで定義できます。一部のガードレールは組織全体に広く適用し、他のガードレールはきめ細かく一時的なアクセスセッションに適用します。

期待される成果: 複数の環境が別々の AWS アカウント で明確に分離されています。  サービスコントロールポリシー (SCP) を使用して、組織全体のアクセス許可ガードレールを定義します。比較的広範なガードレールは組織のルートに近い階層に設定し、比較的厳格なガードレールは各アカウントのレベルの近くで設定します。 リソースポリシー (サポートされている場合) で、プリンシパルがリソースにアクセスするために満たす必要がある条件を定義します。リソースポリシーは、許可される一連のアクションも適宜限定します。 ワークロードのアクセス許可を管理するプリンシパルにアクセス許可境界を設けたうえで、アクセス許可管理が個々のワークロード所有者に委任されています。

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

  • AWS Organization 内にメンバー AWS アカウント を作成しているが、ルート認証情報に対する使用やアクセス許可を制限するために SCP を使用していない。

  • 最小特権に基づいてアクセス許可を割り当てているが、付与できるアクセス許可一式に上限を設けるガードレールが敷かれていない。

  • AWS IAM の暗黙的な拒否の原則に基づいてアクセス許可を制限しており、明示的に許可された望ましくないアクセス許可をポリシーが付与することはないと安心している。

  • 同じ AWS アカウント 内で複数のワークロード環境を実行していて、アクセス許可境界の設定は VPC、タグ、リソースポリシーなどのメカニズム頼みである。

このベストプラクティスを活用するメリット: アクセス許可ガードレールを設けると、望ましくないアクセス許可をアクセス許可ポリシーが付与しようとした場合でも、実際には付与されないという信頼感が得られます。 考慮する必要があるアクセス許可の最大範囲が縮小されるため、アクセス許可の定義と管理が簡単になります。

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

実装のガイダンス

組織のアクセス許可ガードレールは、階層型のアプローチで定義することを推奨します。このアプローチでは、層を重ねるに従い、付与できるアクセス許可一式の上限が体系的に引き下げられます。最小特権の原則に基づいてアクセス権を付与できるため、ポリシーの設定ミスによる意図しないアクセスが起きるリスクが軽減されます。

アクセス許可ガードレールを敷くには、まず、ワークロードと環境を個別の AWS アカウント に分離します。 あるアカウントのプリンシパルは、別のアカウントのリソースにアクセスできません。両方のアカウントが同じ AWS 組織や同じ 組織単位 (OU) に属している場合でも、明示的に許可されていない限りはアクセスできません。 OU を使用して、管理対象の複数のアカウントを 1 つのユニットとしてグループ化できます。  

次に、組織のメンバーアカウント内のプリンシパルに付与できるアクセス許可一式の上限を引き下げます。 サービスコントロールポリシー (SCP) をこの用途で使い、OU またはアカウントに適用できます。 SCP では、特定の AWS リージョン へのアクセスを制限する、リソースが削除されないように防ぐ、リスクが懸念されるサービスアクションを無効にするなど、一般的なアクセス制御を適用できます。  組織のルートに適用する SCP は、そのメンバーアカウントにのみ影響し、管理アカウントには影響しません。 SCP は組織内のプリンシパルにのみ適用されます。組織の外部からリソースにアクセスするプリンシパルは対象外です。

さらに、IAM リソースポリシーを使用して、適用対象のリソースに対して実行できるアクションの範囲と、アクションを実行するプリンシパルが満たす必要のある条件を指定します。 範囲を広くして、プリンシパルが組織の一員である限り (PrincipalOrgId 条件キーを使用して) すべてのアクションを許可することも、範囲を絞って、特定の IAM ロールによる特定のアクションだけを許可することもできます。 IAM ロールの信頼ポリシーの条件でも、同様のアプローチをとることができます。 リソースまたはロールの信頼ポリシーで、適用対象のロールまたはリソースと同じアカウントのプリンシパルの名前が明示的に指定されている場合、そのプリンシパルには同じアクセス許可を付与する IAM ポリシーをアタッチする必要はありません。 プリンシパルがリソースとは異なるアカウントにある場合は、該当するアクセス許可を付与する IAM ポリシーをプリンシパルにアタッチする必要があります。

多くの場合、ワークロードチームが担当ワークロードに必要なアクセス許可を管理することを望みます。 その場合は、そのチームが新しい IAM ロールとアクセス許可のポリシーを適宜作成する必要があります。 チームが IAM アクセス許可境界内で付与できるアクセス許可の最大範囲を定義し、このドキュメントを IAM ロールに関連付けます。チームはそのロールを使用して、各自の IAM ロールとアクセス許可を管理できるようになります。 このアプローチにより、業務の完遂に必要な自由をチームに与えつつ、IAM の管理権限を持つことのリスクを軽減できます。

さらに細かく管理するには、特権アクセス管理 (PAM) と一時的な昇格アクセス管理 (TEAM) の手法を実装します。 PAM の一例としては、特権が必要なアクションの実行前にプリンシパルに多要素認証の実行を要求します。 詳細については、「MFA 保護 API アクセスの設定」を参照してください。TEAM では、プリンシパルへの昇格アクセスの承認とそのアクセス権を持っていられる期間を管理するソリューションが必要です。 1 つの方法は、昇格アクセス権を持つ IAM ロールのロール信頼ポリシーにプリンシパルを一時的に追加することです。 別の方法としては、通常の運用では、IAM ロールによってプリンシパルに付与されるアクセス許可の範囲をセッションポリシーを使用して制限し、承認された時間枠ではこの制限を一時的に解除します。AWS と一部のパートナーによる検証済みのソリューションの詳細については、「Temporary elevated access」を参照してください。

実装手順

  1. ワークロードと環境を個別の AWS アカウント に分離します。

  2. SCP を使用して、組織のメンバーアカウント内のプリンシパルに付与できるアクセス許可一式の上限を引き下げます。

    1. SCP の作成には、許可リスト方式を採用することをお勧めします。許可したアクションを所定の条件下でのみ認め、それ以外のアクションはすべて拒否します。まず、制御したいリソース (Resources) を定義し、Effect を Deny に設定します。NotAction 要素を使用して、指定したアクション以外のすべてのアクションを拒否します。これを NotLike 条件と組み合わせて、指定したアクションを許可する状況を適宜定義します (StringNotLike や ArnNotLike など)。

    2. サービスコントロールポリシーの例を参照してください。

  3. IAM リソースポリシーを使用して、リソースに対して許可されるアクションの範囲を限定し、その条件を指定します。 IAM ロールの信頼ポリシーで条件を指定して、ロールを引き受けた場合の制限を設けます。

  4. IAM アクセス許可境界を IAM ロールに割り当てます。ワークロードチームがこのロールを使用して、各自のワークロードの IAM ロールとアクセス許可を管理できるようになります。

  5. ニーズに基づいて PAM ソリューションや TEAM ソリューションを評価します。

リソース

関連するドキュメント:

関連する例:

関連ツール: