目的
この記事では以下について記載する。
- AWS Organizationsを利用し、AWSアカウントを追加する方法
- 追加したAWSアカウント(メンバーアカウント)へのログイン方法
- サービスコントロールポリシー(SCP)によりAWSアカウントの操作を制限する方法
- SCPの継承の仕組みについて
想定読者
- AWS Organizationsについて勉強している方
- SCPについてのイメージが掴めない方
手順
手順としては以下を想定しております。
- AWSアカウントの追加
- メンバーアカウントへのログイン
- SCPの有効化、アタッチ
- SCPの継承の仕組み
1. AWSアカウントの追加
「AWSアカウントを作成」を選択します。
既存のAWSアカウントがある場合は、「既存のAWSアカウントを招待」を選択します。
しばらく待つと作成されます。
「AWSアカウントを作成」の「アカウント所有者のEメールアドレス」に入力したメールアドレスに以下の内容が送信されれば登録完了となります。
Root配下にAWSアカウントが追加されました。
2. メンバーアカウントへのログイン方法
メンバーアカウントへのログイン方法は2通りあります。
1つ目は、作成したAWSアカウントにIAMロール名「OrganizationsAccountAccessRole」にてスイッチロールする方法です。
2つ目は、作成したAWSアカウントにルートユーザでログインする方法です。
ルートユーザのパスワードは取得できませんので、一度パスワードを初期化する必要があります。
但し、実運用を考えると、スイッチロールした上でIAMユーザを作成し、利用ユーザに連絡する方が良いと思われます。
参考
3. SCPの有効化、アタッチ
SCPを有効化します。
SCPにより、追加したAWSアカウントの制限が可能となります。
ルートにはデフォルトで「FullAWSAccess」ポリシーが適用されています。
追加したAWSアカウントにSCPをアタッチします。
この時、例えば、追加AWSアカウントでは開発者がEC2とCloudWatchしか利用しないと想定します。
「ポリシーを作成」を選択し、EC2とCloudWatchのみ許可するポリシーを作成します。
4. SCPの継承の仕組み
SCPには継承という仕組みがあります。
これは文字通り、親のポリシーを引き継ぐことを意味します。
但し、「継承」というよりは「フィルタ」というイメージが近いです。
例えば、追加したAWSアカウント「company_busho_user1」の親の「Root」で全てのAWSリソースへのアクセスを拒否にするポリシーを設定します。子の「company_busho_user1」では全てのAWSリソースへのアクセスを許可にするポリシーを設定します。
私の当初のイメージとしては、親のポリシーで拒否しても子のポリシーで許可することが可能かと思っておりましたが、親のポリシーで拒否した場合、子のポリシーで許可することは出来ません。
スイッチロールしても権限がないことでエラーが表示されます。
また、親のポリシーで許可した場合、親のポリシーのみを子でも使うことが可能かと思っておりましたが、子では継承されているポリシー以外のポリシーをアタッチする必要がございました。
この時、明示的に使用可能なリソースを指定した場合、許可したリソース以外は黙示的に拒否されます。
例えば、以下の場合、「AccountControl」ポリシーにて、EC2、CloudWatchのみを許可していますので、EC2、CloudWatchはアクセス可能です。
それ以外のサービスは利用できません。
参考情報
SCP継承については以下のサイトが凄く分かりやすいです。
https://dev.classmethod.jp/articles/organizations-scp-inheritance/