AWS Control Tower で個人的につまづいたポイント
はじめに
AWS Control Towerを導入するにあたって個人的につまづいたポイントをまとめます。
あと、本記事ではIAM Identity Centerを長ったらしいのでAWS SSOと表現します。
AWS SSO関連
アクセス許可セットとユーザーグループ is 何？
ランディングゾーンをセットアップするとアクセス許可セットが6つ、ユーザーグループが8つ自動的に作成されます。ですが、それぞれ何に関わっているのか導入当初はイマイチ分かりにくかったです。そこで図として表現してみます。
- アクセス許可セット = AWS SSOで各アカウントにアクセスする際のリンク。(文字通りの権限でアクセス)
- ユーザーグループ = AWS SSOを使用するユーザが加入するグループ。(文字通りの権限が割り振られる)
特にアクセス許可セットとユーザーグループ(またはユーザー)をペアにしてアカウントにアタッチしているというところが最初分かりにくかったポイントです。(特定のペアがアカウント毎に作られたり作られてなかったりしてるのも分かりづらい...)
その一因として、ユーザーグループの画面からは参加しているユーザーしか確認できないのが理解の阻害に繋がっているのかなと思います。今後のアップデートで追加で割り当てられているアカウントとペアのアクセス許可セットが確認できればいいなと思います。
セッションがすぐ切れる&アクセス毎にリージョンが変わる
Control Towerに登録したAWSアカウントにAWS SSOでアクセスする際、アクセス毎にリージョンが変わっていたり、セッションがすぐに切れてしまったりと使い勝手が悪いと感じていました。
ですが後にアクセス許可セットの設定変更にてこれらを解決することが可能だと知りました。
アクセス許可セットの詳細はIAM Identity Centerで確認可能です。
ここで、デフォルトの設定のままだと使い勝手が悪いので各許可セットのページを開き「編集」ボタンをクリックします。
そして以下の項目について設定するとAWS SSOの使い勝手が良くなります。
- セッション時間 (各アカウントのWebコンソールへアクセスする際の)
- 1時間 → 8時間 (AWS SSOサインオンのデフォルトセッション時間と同じ)
- リレー状態
- https://ap-northeast-1.console.aws.amazon.com/console/home (東京リージョンのホーム画面)
多要素認証(MFA)の設定
大抵はこのような設定になるのではないかと思います。
「登録されたMFAデバイスをユーザーが持っていない場合」という設定を「サインインをブロックする」にすると無限にログイン拒否された (AWS SSOの管理画面からしかMFAデバイスを登録できない) のでこの設定使う人いるのかな？と思います...
余計なAWS SSOのユーザーを作らないようにする方法
Account FactoryでAWSアカウント作成時に入力する「アクセス設定」という項目があります。
ここにAWS SSOユーザーで使用されていないメールアドレスを入力しAWSアカウント作成すると、そのメールアドレスでAWS SSOユーザーが新規作成されてしまいます。ですが、既存のAWS SSOユーザーの情報を入力することで新規にAWS SSOユーザーが作られないようにすることが可能です。(メールアドレスさえちゃんと入力していれば、ユーザー名は適当で大丈夫です)
設定統一のために、Control Towerのランディングゾーンセットアップ時に自動的に作成されるAWS SSOルートユーザーのメールアドレスを使用すると統一感が出て良いと思います。
ちなみに、Control Towerに未登録の既存AWSアカウントをControl Towerに登録する際に自動作成されるAWS SSOユーザー (AWSアカウントのメールアドレスで作成される) は作成を避ける方法が現状無さそうです...
ガードレール(コントロール)関連
まず何のガードレールから適用していくか問題
最初ランディングゾーンに必須のガードレールがデフォルトで有効化されているところから、では手動で何のガードレールを有効化しようかと迷いました。ガードレールにはそれぞれ以下の項目が設定されています。
- ガイダンス
- 必須
- 強く推奨
- 選択的
- 重大度
- 重大
- 高
- 中
- 低
以上の項目とガードレールの内容などを吟味した結果、適用は以下の優先順位で考えるといいと思います。
ガイダンス：強く推奨 > 重大度：重大 > あとは重大度順...
私が管理する環境では、ガイダンス：強く推奨をほぼすべて適用 (これだけ未適用) しています。
ガードレール別OU継承されるされないの違い
ガードレールの動作という観点だと以下の3種類に大別されます。
- 予防 (操作を禁止) = 33種類
- 実装はAWS OrganizationsのSCP (無料)
- OU継承あり
- 検出 (検出＆通知) = 195種類
- 実装はAWS Config rules (AWS Configの料金表)
- OU継承なし
- プロアクティブ (プロビジョニングを禁止) = 134種類
- 実装はAWS CloudFormation hooks (実質AWS Configと同じ料金)
- OU継承不明
ネストを持っているOUに予防ガードレールを適用すると自動でその配下にも適用してくれるのに対し、検出ガードレールは自動で適用してないことに注意です。(プロアクティブは実装したてでドキュメントがない？)
コントロールオーナーによる違い
各ガードレールにはコントロールオーナーがおり、AWS Control TowerとAWS Security Hubのどちらかがオーナーとなっています。ここで注意すべきポイントとしてAWS Security Hubがオーナーのガードレールは、違反したとしてもControl Towerでは何も通知されません。
このコンプライアンスステータスを確認するには以下を使用する必要があります。
- Security Hubコンソール
- Security Hub API
- AWS CLI
コントロールライブラリのオススメソート設定
以下のようなソート設定にするとガードレールが探しやすくなるかと思います。
その他
OU設計について
AWSホワイトペーパーをベースに組織の規模感で必要なOUを選定していくのが基本だと思います。
具体例として私が管理しているOU設計を以下に示します。
Account Factoryのネットワーク設定の罠？
Account FactoryでAWSアカウントをプロビジョニングする際に、自動的にVPCもプロビジョニングしてくれる設定があります。
ここの「プライベートサブネットの最大数」が0と1の場合について比較検証してみた結果、1の場合にランディングゾーンが適用されているリージョンに対してエンドポイントが作成されていました。公式ドキュメントを見ても特にエンドポイントに関わる記載がなかったので謎です...
AWSアカウントの閉鎖に関わる制限
Control TowerのメンバーAWSアカウントを閉鎖したいとき、
- Control Towerの各アカウントページから「アカウントの管理を解除」ボタンをクリック
(Service Catalogから「プロビジョニングされた製品」の終了でもよい) - Organizationsの各アカウントページから「閉じる」ボタンをクリック
という手順で行うことが可能ですが、AWSアカウントの閉鎖には総アクティブメンバーアカウント数の10％しか30日以内に閉鎖できないという制限があります。
ですので、無計画にAWSアカウントを作成しないように注意しましょう。(1敗)
もし制限に引っかかってしまったアカウントは「Suspended」OUに突っ込んでおきましょう。
Discussion