type
status
date
slug
summary
tags
category
icon
password
理論
実践
一問道場
ある企業が、AWS Organizations を実装して、開発者が Amazon EC2、Amazon S3、Amazon DynamoDB のみを使用するよう制約を設けようとしています。開発者アカウントは専用の組織単位(OU)に所属しています。ソリューションアーキテクトは、以下の SCP(サービスコントロールポリシー)を開発者アカウントに実装しました。
しかし、このポリシーを適用した後も、開発者アカウント内の IAM ユーザーは、このポリシーに記載されていない AWS サービスを利用できています。
ソリューションアーキテクトは、開発者がポリシーの範囲外のサービスを利用できないようにするために、どのように対処すべきでしょうか?
選択肢:
A. 制約する必要がある各 AWS サービスについて、明示的な拒否(Deny)ステートメントを作成する。
B. 開発者アカウントの OU から FullAWSAccess SCP を削除する。
C. FullAWSAccess SCP を変更して、すべてのサービスを明示的に拒否する。
D. SCP の末尾にワイルドカード(
*
)を使用した明示的な拒否ステートメントを追加する。解説
以下に、選択肢A、B、C、Dにおける 実際例 とその問題点を挙げて、説明します。
A. 制約する必要がある各 AWS サービスについて、明示的な拒否(Deny)ステートメントを作成する。
実際例:
問題点:
- 手間がかかる: 上記の例では、
ec2
,dynamodb
,s3
以外の各サービスを個別に拒否していますが、新しいAWSサービスが追加される度に、拒否ステートメントを追加しなければならないため、管理が煩雑です。
- 漏れのリスク: 新たに追加されたサービスに対して、拒否設定を忘れてしまう可能性があります。
BC は OU 全体 に影響を与える可能性があるため避けた方がよいです。
D. SCP の末尾にワイルドカード(
)を使用した明示的な拒否ステートメントを追加する。
実際例:
問題点:
- 過剰な拒否設定:
を使用して全サービスを拒否する場合、
ec2
,dynamodb
,s3
以外のサービスを拒否することは確かですが、他の依存関係を持つリソースが許可されない可能性があり、問題が発生する可能性もあります。たとえば、s3
を利用するLambda関数やEC2インスタンスなどが問題に直面するかもしれません。
総括と改善案
- A: 手動で個別に拒否を追加する方法は、サービスの追加に対応できるものの、管理が煩雑になり、漏れのリスクが高いです。
- BC は OU 全体 に影響を与える可能性があるため避けた方がよいです。
- D は他のアカウントに影響を与えることなく、特定のアカウントに対して明示的な制限を加える方法として最適です。
- D: ワイルドカードを使用して拒否する方法は簡潔で効果的ですが、他のサービスの依存関係に注意が必要です。
最もバランスの取れた方法は、D(ワイルドカードを使用してすべてを拒否する)です。
- 作者:みなみ
- 链接:https://tangly1024.com/資格勉強/165d7ae8-88e2-80ef-b503-d4631690acb9
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议,转载请注明出处。
相关文章