👋
【AWS】AWS OrganizationsとIAM Identity Centerでマルチアカウント管理
1. AWS Organizationsの基礎
Organizationsの特徴
- 複数アカウントを組織単位で管理するAWSサービス。
- 管理アカウント: 組織全体を管理する特別なアカウント。
- メンバーアカウント: 管理されるアカウント。
主な機能
-
OU(Organizational Unit):
- アカウントをグループ化し、一括管理。
-
SCP(サービスコントロールポリシー):
- アカウントやOU単位で操作制限を設定。
-
請求管理:
- 請求を一本化しつつ、各アカウントのコストを明確化。
2. ハンズオン手順
ステップ1: AWS Organizationsを有効化
-
管理アカウントでログイン:
- 検索バーに「AWS Organizations」と入力。
- 「組織を作成」をクリックし、Organizationsを有効化。
-
OU(Organizational Unit)の作成:
- 例:
-
ワークロードOU
: 開発・本番用の環境をまとめるグループ。 -
サンドボックスOU
: テスト用アカウントをまとめるグループ。
-
- ルートユニットを選択し、「新規作成」でOUを作成。
- 例:
-
アカウントの追加:
- 「AWSアカウントを追加」をクリック。
- 例:
-
サービスA-開発
(開発用アカウント) -
サービスA-本番
(本番用アカウント) -
サンドボックスA
(検証用アカウント)
-
- 作成後、それぞれのOUにアカウントを移動。
ステップ2: SCP(サービスコントロールポリシー)の適用
-
SCPの有効化:
- 左ペインの「ポリシー」→「サービスコントロールポリシー」→「有効化」をクリック。
-
ポリシー作成:
- 例: EC2の操作を禁止するSCP
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "ec2:*", "Resource": "*" } ] }
- 例: S3の操作を禁止するSCP
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "s3:*", "Resource": "*" } ] }
- 例: EC2の操作を禁止するSCP
-
ポリシーの適用:
- SCPを該当するアカウントやOUにアタッチ。
- 例: 開発環境にはS3禁止ポリシー、本番環境にはEC2禁止ポリシーを適用。
SCPって基本的に許可するものではなく、何かを禁止するもの?
はい、基本的に SCP(サービスコントロールポリシー) は「禁止する操作を指定する」ために使われることが多いです。ただし、詳細な仕組みを理解することで柔軟に運用できます。
SCPの基本的な仕組み
- SCPは AWS Organizations 内で適用されるポリシーです。
- SCPは IAMポリシー とは異なり、直接権限を「付与」するものではなく、「制限」を設定します。
- IAMポリシーやロールで許可されている操作があっても、SCPで禁止されている場合、その操作は実行できません。
SCPの主な使い方
-
禁止ポリシー(Deny): 特定の操作を明示的に禁止する。
- 例: 「全アカウントでS3バケットの公開設定を禁止する」
- 使用例:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "s3:PutBucketAcl", "Resource": "*" } ] }
-
許可ポリシー(Allow): 特定の操作のみを許可する。
- SCPに「Allow」のルールを記述した場合、それ以外の操作はすべて暗黙的に禁止されます。
- 使用例:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:Describe*", "ec2:StartInstances", "ec2:StopInstances" ], "Resource": "*" } ] }
SCPの動作の仕組み
- SCPが適用されていない場合:
- IAMポリシーやロールで許可されている操作がそのまま実行可能。
- SCPが適用されている場合:
- SCPで禁止されている操作は、IAMポリシーで許可されていても実行できない。
- SCPに許可ポリシーのみを記述した場合、その許可以外の操作はすべて暗黙的に拒否される。
よくあるSCPの使い方
-
禁止系の設定:
- 「特定リージョンでのリソース作成を禁止」
- 「特定のサービス利用を禁止」
- 「ルートユーザーの使用を禁止」
-
許可系の設定:
- 特定アカウントの操作を明示的に制限する。
- 特定のサービスやアクションのみに絞り込む。
結論
- SCPは基本的に「禁止」を定義するものとして設計されています。
- 特定の操作を制限することで、セキュリティを強化する役割がメインです。
- 必要に応じて「許可ポリシー」を定義し、特定の操作のみを許可することもできます。
もし具体的な例やシナリオについて知りたい場合は教えてください!詳細をお伝えします 😊
ステップ3: IAM Identity Centerの設定
-
Identity Centerの有効化:
- 検索バーで「IAM Identity Center」を検索し、有効化。
-
ユーザーの作成:
- ユーザー名を設定し、ユーザー情報を入力。
- グループを作成し、ユーザーをグループに追加。
-
許可セットの作成:
- 事前定義されたポリシーから「AdministratorAccess」を選択。
- 許可セットを作成。
-
アカウントに許可セットを割り当て:
- SSOユーザーグループを各アカウントに割り当て、許可セットを適用。
3. 動作確認
-
本番環境の検証:
- サインイン後、EC2操作を試みる。
- SCPで操作が拒否され、エラーが表示されることを確認。
-
開発環境の検証:
- サインイン後、S3操作を試みる。
- SCPで操作が拒否され、エラーが表示されることを確認。
-
シングルサインオンの便利さ:
- 一度のログインで複数アカウントにアクセス可能。
- SSOの画面で選択したアカウントの管理画面に遷移できる。
4. SCPと許可セットの関係
-
SCPの効果:
- SCPで明示的に拒否された操作は、許可セットやIAMポリシーで許可されていても実行できない。
-
優先順位のポイント:
- 許可セットとSCPの両方で許可されている操作のみが実行可能。
- SCPで拒否された操作は、最終的に「拒否」となる。
5. 活用例
-
プロジェクトごとの分離:
- Webアプリ開発チームとモバイルアプリ開発チームでアカウントを分離。
- SCPを使い、不要なリソースの操作を制限。
-
テスト環境の保護:
- テストアカウントで本番データベースへの接続をSCPで拒否。
-
シンプルなログイン:
- 開発者はIAM Identity Centerで一度ログインし、テスト・本番環境を簡単に切り替え可能。
6. まとめ
- AWS OrganizationsとIAM Identity Centerを組み合わせると、複数アカウントを効率的に管理可能。
- SCPを使い、リスクの高い操作を組織全体で禁止することでセキュリティを強化。
- IAM Identity Centerを活用し、ユーザーのアクセス管理を簡略化。
Discussion