【AWS Organizationsアップデート!】SCPで柔軟な設定が可能に!- Conditionを設定して「特定のロールのみEC2の操作ができる」ようにしてみた –

AWS運用自動化サービス「Cloud Automator」

http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_top.png
 こんにちは、サーバーワークスのこけしの人、坂本(@t_sakam)です。本日、Organizationsの機能アップデートが発表されました。このアップデートで、いままでざっくりとした設定しかできなかったSCP(サービスコントロールポリシー)で「Resource」や「Condition」の設定ができるようになり、柔軟な指定ができるようになった模様です。いままでは細かい設定ができなかったので、嬉しいアップデートですね!
 早速、どういったことが可能になったのか、簡単に確認してみたいと思います。

構成

 今回は、親アカウントのOrganizationsで管理している子アカウントが1つだけ、というシンプルな構成です。OU(Organizational Units)も1つだけです。親アカウントと子アカウントの間に「BasicChildOU」というOUを置きました。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_top.png
 まずは、このOUに「EC2DenyPolicy」というEC2の操作をすべてDeny(拒否)に設定したSCPをアタッチして、子アカウントのEC2が操作できないようにします。
 上記の設定に加えて今回はOrganizationsのアップデートで「Condition」が設定できるようになっているので、「Condition」を設定して踏み台アカウントから「PowerUserLoginRole」で子アカウントにログインした場合のみ、EC2の操作ができる状態にしたいと思います。子アカウントにrootでログインしたときは、EC2が使えないようになっているかも手順の中で確認していきます。
 
※アップデートで「Resource」も柔軟に設定できるようになりましたが、今回はすべてのリソースに適用したいので、「Resource」は「*」で設定しています。

親アカウントにログイン

 まずは、親アカウントにログインしてOrganizationsの画面で「ポリシーの作成」ボタンを押します。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_01.png

新しいポリシーの作成

 以下は、アップデート後のSCP作成画面です。UIがかなり変わりましたね。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_02.png
 ちなみに、アップデート前の画面は以下のようなUIでした。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_03.png

「EC2DenyPolicy」を作成

 まずは、ポリシー名と説明を入力します。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_04.png

サービスの選択

 左のメニューの検索ボックスで「EC2」と入力し、検索後「EC2」を選択します。すると、アクションが表示されます。
 今回はすべての操作を「Deny」にするので、一番上の「All actions (ec2:*)」にチェックを入れます。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_05.png

リソースを追加する

 次は、その下の「2. リソースを追加する」リンクを押します。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_06.png
 今回は「All Resources」を選び、リソース ARNは「*」にして、「リソースの追加」を押します。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_07.png

条件を追加する

 最後に、その下の「3. 条件を追加する」リンクを押します。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_08.png
 条件キーを「aws:PrincipalArn」、演算子を「StringNotEquals」にします。値は今回EC2の操作を制限したくないロール(「PowerUserLoginRole」)のARNである「arn:aws:iam::XXXXXXXXX376:role/PowerUserLoginRole」を入力します。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_09.png

ポリシーの作成

 最後に右下の「ポリシーの作成」ボタンを押して、SCPの作成は完了です。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_10.png

子アカウントにrootでログイン

 SCPをアタッチする前に子アカウントにrootでログインしてみます。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_19.png
 いまはまだ、EC2が操作できる状態であることが確認できます。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_11.png

親アカウントのOrganizationsでSCPをアタッチ

 再び親アカウントのOrganizationsを操作します。「BasicChildOU」に先程作成した「EC2DenyPolicy」をアタッチします。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_00.png
 アタッチできました。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_12.png

子アカウントで再確認

 再び子アカウントにrootで入り、EC2の画面を確認します。エラーがでてEC2が操作できなくなっていることがわかります。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_13.png

PowerUserLoginRoleの確認

 子アカウントのIAMの画面で「PowerUserLoginRole」を確認してみます。信頼されたエンティティに末尾3桁が「126」となっているアカウントが設定されていることを確認できます。これは、踏み台アカウントのアカウントIDです。踏み台アカウントから「PowerUserLoginRole」でスイッチロールすれば、EC2が使えるはずです。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_14.png

踏み台アカウントにログイン

 踏み台アカウントにログイン後、スイッチロールして子アカウントに入りたいと思います。末尾「126」のアカウントなので、踏み台アカウントであることも画面から確認できます。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_15.png

子アカウントにスイッチロール

 子アカウントのアカウントIDは、末尾「376」です。下の画面は、これから子アカウントに「PowerUserLoginRole」でスイッチロールするところです。アカウントIDとロール名を入力して、好きな色を選びます。最後に「ロールの切り替え」ボタンを押します。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_16.png
 子アカウントに入れました。最後にEC2の画面に移動しましょう。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_17.png

子アカウントのEC2が操作できるかを確認

 子アカウントのEC2の画面です。先程rootでログインしたときと違い、エラーがでていません。これで、踏み台アカウントから「PowerUserLoginRole」に子アカウントにスイッチロールした場合、ちゃんとEC2が使える状態になっていることを確認できました。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2019/03/organizations_blog_18.png

まとめ

 今回は、アップデートで便利になったOrganizationsのSCPを試してみました!
 SCPで柔軟な設定ができるようになったことが確認できましたね。これで今後は「特定のロール権限のみ、サービスを使えるようにする」など、便利な設定ができそうです!

 いや〜、「AWS Organizations 」って本当にいいものですね!

AWS運用自動化サービス「Cloud Automator」