AWS Organizationsを使ってみる
AWS Organizationsを使ってみる。
AWS Organizationsとは、ザックリいうと通常使っているアカウントに紐づけるサブアカウントを作成、管理する仕組みです。
これを使うと何が嬉しいかというと、一つのAWSアカウントにいろいろなリソース（開発環境、本番環境、異なる部署の環境etc...）
を突っ込んていると、EC2の台数が100を超えてきたり、IAMが50個もあるとか、サブネットがカオスとか管理が煩雑になります。
かといって、部署ごとにAWSアカウントを取得するとなると、クレカが必要だったり、請求が一本化できなかったりと面倒です。
Organizationsを使えば、一つのマスタアカウントに請求を紐づけつつ、独立したAWSアカウントを作成することができます。
その際クレカは必要なく、ユニークなメールアドレスがあればOKです。
また、サブアカウントが沢山できると管理が煩雑ですので、それらをグループ化して管理することができます。
さらに、既にある既存のAWSアカウントをサブアカウントとして紐づけることも可能です。
そして何より便利なのが、APIでアカウント作成することができるんですね。つまり、
AWSアカウント作成からポリシーの適用まで自動化できる訳です。こんな感じです。
ここに説明がありますので、これに従って構築してみると分かると思いますが、注意があります。
- 作成したサブアカウントのパスワードは初回リセットする必要があります。
- 作成したサブアカウントは、今のところ削除することができません！。サポートに問い合わせて特別な操作をする必要があります。
- アカウントを作成する際、メールアドレスは確実に届くアドレスかつ有効なAWSアカウントで使用されていないものでないといけません。 メールアドレスを間違えると削除はできないし、変更することもできません。サポート行きになります。
組織ユニット（OU）ポリシーによるアクセス制御
上記ブログにも記載があるのですが、OUにポリシーを割り当てることができます。IAMのグループポリシーのようなものです。
ちょっとイメージがつきづらいので、試してみます。
- ここでは、OUとして、Prod、Devを作成しました。
- 次に適用するポリシーを作成します。
PolicesタブからCreate policyをクリックします。
- Policy generatorをクリックし、Policy nameやDescriptionを適当に設定します。
Choose effectはここでは許可ルールを設定するのでAllowを選択します。
- ポリシーを設定します。ここではサンプルとしてEC2関連のみフルコントロールとします。
ポリシーが作成できました。
- 次にこのポリシーをOUに適用します。
まずはSCPを有効化します。
Organize accountsタブより、Rootをクリックします。画面右下にひっそりとある、Service control policiesのEnableをクリックします。
これで、SCPが有効になります。
- では実際にOUにポリシーを適用します。
左のツリーより、適用したいOU（ここではProd)をクリックし、右のService control policiesをクリックします。
- 有効にしたいポリシーをAttachします。
その後、FullAWSAccessはDetachしておきます。これで、OUにポリシーを適用できました。
では実際に試してみましょう。
まずは作成したアカウントをDevに所属させた後、作成したアカウントで
コンソールにログインしてみます。
まぁフル権限なので普通に全リソースにアクセスできます。
ではこの状態（ログインしている）で、別ブラウザからrootアカウントでコンパネに入り、
所属OUをProdに移動させてみます。
OUはあくまでアカウントを束ねて管理するだけなので、同一アカウントは複数のOUに所属することはできません。
この状態で先ほどのアカウントでログインしたコンパネを再読み込みしてみます。
EC2しか許可していないので、アクセスエラーになりました。
もちろん許可したEC2は問題ありません。
このように、OUにポリシーを作成、適用することにより、
複数のAWSアカウントに対しまとめてポリシーを適用することができます。
なお、もちろん作成したアカウント単位でポリシーを適用することも可能です。
余談
ここで、アカウントにつけたポリシーとOUのポリシーの制御はどうなっているのか？
と思ったので、試してみました。
先ほどのEC2 OnlyなOUに所属しているアカウントにS3 Onlyな権限を振りました。
結果はOUが許可していないものは配下のユーザは使用できない。ということになりました。
では、OUが許可しているものをアカウントが拒否の場合はどうでしょうか？
まぁ予想通り拒否できました。
同一リソースに許可ポリシーと拒否ポリシーを同時に設定した場合は拒否ポリシーが優先されます。
つまり、FullAWSAccessポリシーとDeny EC2ポリシーを同時設定した場合は、
EC2だけが使えなくなります。
まとめますと、
- 所属しているOUが拒否しているものは、所属しているアカウントはすべて拒否されます。
- OUが許可しているものは、アカウントポリシーで拒否することができます。
- OUが許可している範囲以上の権限を所属しているアカウントは所持できません（当然か）
ちなみに、ポリシーはOUだけではなく、Root（つまり組織全体）にも設定できます。
請求情報とか見せたくないとか設定ができます。（ただしマスターアカウントは除く）
- しかし、SCPのポリシー選択画面のUIがAmazonらしからぬ醜悪さですね。
これだと、今の状態（Detach）なのか、変更後の状態（Detachになる）なのかさっぱりわかりません。
このページの参照回数は、897です。