こんにちは、上野です。
前回は、AWS Control Towerを触ってセットアップするところまで紹介しました。今回はセットアップ後の運用操作について見ていきます。
AWSアカウントの新規追加（プロビジョニング）
前回の状態では、利用者独自のAWSアカウントを追加できるCustom OUは空の状態でした。
ここにアカウントを追加します。アカウントの追加は、AWS Service Catalogというサービスが使用されます。AWS Service Catalogは、各アカウントの設定やネットワーク設定をテンプレート化して展開するサービスです。
※追加アカウント用の新規メールアドレスが必要です。
AWS SSOのログインを行い、今回はAdministratorAccess権限でアクセスします。
※アカウント追加用のAWSServiceCatalogEndUserAccess権限でも、AWS Service Catalog経由でアカウント作成できるようですが、公式ドキュメントによるとAWS Control Tower経由が推奨なようです。
可能な限り [Enroll account (アカウントの登録)] 機能を使用することをお勧めします。
同ドキュメントによれば、AWS Control Tower経由の場合は、AWSServiceCatalogEndUserFullAccess ポリシー以上の権限が付与されていればOKなようです。
AWS Control Towerの画面に遷移し、Account Factory＞アカウントの登録を選択します。
次のように項目を入力します。
- アカウントEメール：新規追加AWSアカウント用メールアドレス
- 表示名：任意のアカウント表示名（今回はCTSystem01としました）
- AWS SSO Eメール：既存でも新規ユーザーでも良いようですが、今回はセットアップ時に作成されたユーザーを指定しました
- AWS SSO ユーザー名：作成されていた既存のユーザー名を入力します
- 組織単位：現状は作成できる組織単位（OU）はCustomのみなのでそれを選択します
※既存のSSOユーザーであれば選択式にできると良いですね。今後に期待です。
アカウントの登録を押すと、そのまま登録プロセスに入ります。確認画面がないので注意です。
「AWS Service Catalogで詳細を確認」と書いてあるのでそちらで見てみると、ステータスが変更中となっていました。しばらく待ちます。
20分ほどで使用可能状態になりました。
AWS SSOの画面にもログイン画面が表示されます。AWSOrganizationsFullAccessという権限も付与されるようです。Administratorのほうでアクセスしてみます。
CloudTrailの証跡が自動設定されていました。
また、VPCもAWS Control Tower経由で自動作成されていました。VPCの設計については、アカウントごとに異なることが多いので、ここはAWS Control Tower経由ではなく個別作成でも良いかなと思っています。
VPC自動追加を行わない場合は、Account Factoryの設定からVPC作成のリージョンのチェックを抜いておけば大丈夫です。
AWS Control Towerから見ると、必須のガードレールが有効になっていることもわかります。
新規アカウント追加はここまです。前回の構成図にこのアカウントを追加しておきます。
組織単位（OU）の追加と既存のAWSアカウントをAWS Control Tower配下へ追加
1つ前の手順では新規のAWSアカウントを追加する手順でしたが、既存のアカウントをAWS Control Towerへ追加する手順も試してみます。
実はAWS Control Tower作成時に、Log ArchiveでもAuditでもないAWSアカウントがOrganizations組織配下に存在していました。
アカウント一覧上は「未登録」状態となっています。
今回はsystem01アカウントを、新たな組織単位（OU）に追加し、AWS Control Tower管理化にします。
組織単位の画面から、OUの追加を選択します。
System01というOUを追加します。
しばらくすると登録が完了します。
追加した構成は次のとおりです。
アカウントのOUを移動させたいのですが、AWS Control Tower上からはできなかったので、AWS Organizationsの画面から移動させます。
System01というOUへ。
再びAWS Control Towerの画面に戻り、組織単位＞System01を確認すると、登録済みアカウントが0/1（1個見えるけど未登録）となっているので、OUを再登録ボタンを押して反映させます。
次のように表示されます。IAMロールやガードレールの設定が更新されます。
しばらく待ちます。
失敗しました・・
AWS Configが対象のアカウントで有効になっているとエラーになるようです。
ドキュメントに前提の記載がありました。
ガードレールでConfigの無効化が拒否されていますが、AWSControlTowerExecutionというRoleであれば無効化できるようなのでそのRoleでログインします。ドキュメントのとおり、画面からの無効だけではなくCLIの操作が必要になります。
system01アカウントにAWSControlTowerExecutionでスイッチし、CloudShellで以下の無効コマンドを実行します。
※「default」の部分は環境によって変わる可能性があります、ドキュメントにある確認コマンドで確認してください。
aws configservice stop-configuration-recorder --configuration-recorder-name default aws configservice delete-delivery-channel --delivery-channel-name default aws configservice delete-configuration-recorder --configuration-recorder-name default
無効化ができたら、ManagementアカウントのAWS Control Tower画面に戻りOUを登録します。
最下部のチェックをいれて登録。
また待ちます。
30分ほどで登録完了しました。
AWS SSOの画面を見ると、AWSOrganizationsFullAccessのみ存在しました。権限セットは個別で設定してあげる必要がありそうです。
設定される内容（CloudTrailの証跡有効など）は新規アカウント追加時と同様です。
追加した構成は以下のとおりです。既存アカウントの場合、AWS Control TowerでVPCは作成されません。
ガードレールの追加
デフォルトでは必須のガードレールのみ有効となるため、追加で「強く推奨」のガードレールを1つ有効にしてみます。
今回は「SSH を介したインターネット接続を許可しない」を有効にします。
ガードレール一覧から対象のガードレールを選択して詳細画面へ遷移し、「OUでガードレールを有効にする」を押します。
追加したSystem01というOUで有効にします。複数同時チェックはできませんでした。
しばらくすると有効になります。
せっかくなので非準拠のものを作成して検知させてみます。system01アカウントにログインし、SSHフルオープンのセキュリティグループを作成します。（良い子はマネしちゃダメ）
しばらくすると、次のようなConfigルール非準拠のメールが飛んできます。JSONなので少しわかりにくいですね。ここは改善の余地があるかもしれません。
AWS Control Tower画面からアカウントの内容を見ると、非準拠のリソースが表示されます。ここからリソースの修正はできないため、system01アカウント側で手動修正する必要があります。
ガードレール追加検証はここまでです。
バージョンUP
ランディングゾーン設定画面から、AWS Control TowerのバージョンUPができそうです。私の場合はまだ作成したばかりなので最新でありできませんが、今後新しいバージョンがでてきたらやってみようと思います。また、この画面から対象リージョンの追加や、廃止もできるようです。
まとめ
検証はここまでとします。いくつか気になるところもまとめておきます。
AWS Control Towerに含まれないセキュリティサービス
AWS Security Hub、Amazon GuardDuty、Amazon Detectiveといったセキュリティ系のサービスは、AWS Control Tower管理外で、自動有効となりませんでした。
AWS Service Catalog側を修正して追加もできるかもしれません（推測です）。ただ、AWSマネージドな部分を変更することになるので、 Organizations側の機能（AWS Control Tower外）で自動有効を検討しても良いと思います。
一例ですが、GuardDutyであれば以下の記事を参考にしてください。
Control Tower lifecycle Eventsを使用したAWS SecurityHubの有効方法は以下の記事で紹介されていました。
AWS SSOの権限検討
今回は検証目的のため、Administrator権限を使用してアクセスしていました。本番運用を行う場合は、最小権限の原則に従って付与する権限セットを設計する必要があります。ここはAWS SSO側で考えていく必要があります。既存の運用でAWS SSOの利用が無い場合は、移行方針やAWS SSOを使わないという選択肢も考慮にいれることもあるでしょう。
検知の運用
デフォルトでは、すべてのアカウントの状況が1つのSNSトピックに通知されるので、OU単位で検知したい場合など、個別の通知を行う場合は設定変更が必要になります。今回の検証では試していませんので、ここはまた機会があればやってみたいです。
以上です！実際に本番運用していくと、ほかにも色々と出てきそうです。今回の検証がマルチアカウント運用を始める参考になれば幸いです！
