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

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

期待される成果: 個別の AWS アカウントを使用して環境を明確に分離できます。  サービスコントロールポリシー (SCP) を使用して、組織全体のアクセス許可ガードレールを定義します。比較的広範なガードレールは組織のルートに近い階層に設定し、比較的厳格なガードレールは各アカウントのレベルの近くで設定します。

リソースポリシー (サポートされている場合) で、プリンシパルがリソースにアクセスするために満たす必要がある条件を定義します。リソースポリシーは、許可される一連のアクションも適宜限定します。ワークロードのアクセス許可を管理するプリンシパルにアクセス許可境界を設けたうえで、アクセス許可管理が個々のワークロード所有者に委任されています。

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

このベストプラクティスを活用するメリット: アクセス許可ガードレールは、アクセス許可ポリシーが付与しようとしても、望ましくないアクセス許可を付与できないという確信を持つために役立ちます。 考慮する必要があるアクセス許可の最大範囲が縮小されるため、アクセス許可の定義と管理が簡単になります。

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

実装のガイダンス

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

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

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

AWS Control Tower を使用している場合は、アクセス許可ガードレールとマルチアカウント環境の基盤として、コントロールとランディングゾーンを活用できます。ランディングゾーンは、事前設定済みの安全なベースライン環境と、さまざまなワークロードやアプリケーション向け個別のアカウントを提供します。ガードレールは、サービスコントロールポリシー (SCP)、AWS Config ルール、およびその他の設定を組み合わせて、セキュリティ、オペレーション、コンプライアンスに関する必須のコントロールを適用します。しかし、Control Tower のガードレールとランディングゾーンを組織独自の SCP と併用する場合は、競合を回避し、適切なガバナンスを確保するため、AWS のドキュメントに記載されているベストプラクティスに従うことが非常に重要です。Control Tower 環境内の SCP、アカウント、組織単位 (OU) の管理に関する詳細な推奨事項については、「AWS Organizations の AWS Control Tower ガイダンス」を参照してください。

これらのガイドラインに従うことにより、Control Tower のガードレール、ランディングゾーン、カスタム SCP を効果的に活用しながら、競合を防止し、マルチアカウント AWS 環境の適切なガバナンスと管理を確保できます。

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

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

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

実装手順

リソース

関連ドキュメント:

関連する例:

関連ツール: