SEC03-BP05 組織のアクセス許可ガードレールを定義する - セキュリティの柱
実装のガイダンス実装手順リソース

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

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

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

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

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

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

  • AWS IAM の暗黙的な拒否基盤に依存してアクセス許可を制限し、ポリシーが望ましくない明示的な許可のアクセス許可を付与しないことに頼る。

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

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

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

実装のガイダンス

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

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

次に、組織のメンバーアカウント内のプリンシパルに付与できるアクセス許可一式の上限を引き下げます。 これにはサービスコントロールポリシー (SCP) を使用できます。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 ロールのロール信頼ポリシーにプリンシパルを一時的に追加することです。 もう 1 つの方法は、通常のオペレーションでは、セッションポリシーを使用して IAM ロールによってプリンシパルに付与されたアクセス許可の範囲を絞り込み、承認された時間枠内にこの制限を一時的に解除することです。AWS と特定のパートナーが検証したソリューションの詳細については、「一時的な昇格アクセス」を参照してください。

実装手順

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

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

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

    2. 「サービスコントロールポリシーの例」を参照します。

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

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

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

リソース

関連ドキュメント:

関連する例:

関連ツール: