始まり
直近、今まで単独で管理していたAWSアカウントをOrganizations移行を実施したため、主な施策となぜ必要かを記載します。
背景
- リセラー経由で契約したAWSアカウントが100個以上存在
- 受託開発、自社、社内システムなど色んな用途で使われて、運用基準も明確の差がある
Organizationsないと困ること
- IAM管理が不透明
GoogleWorkspaceのIdP経由でAWSアクセス権限を付与しているため、アカウントごとにIdPの管理が必要なり(metadataファイル期限切れの場合、アカウント数の分の作業が発生する)、またアクセス権限はGoogleWorkspace側でユーザーごとに設定しているため、統制管理ができない - 継続的に適用する設定ができなくなる
Organizationsに対応しているサービスによくある、同じ設定を後から追加したアカウントにも自動適用のメリットを享受できなくなり、都度の手動作業になります。 - マルチアカウント操作の効率が悪い
Organizationsなし状態で複数アカウントを操作しようとする場合、アカウントごとにIAMアクセスキー発行するか、集約可能のサービスに手動でアカウントを登録などの作業が必要になり、アカウント数が増えれば増えるほど、作業量が膨らみます。
OU構成
| OU名 | 役割 |
|---|---|
| Exceptions OU | 共通SCP適用対象にしたい場合の配置先 |
| Policy Staging OU | SCP検証用OU |
| Sandbox OU | 検証用アカウント配置用OU |
| Security OU | SecurityHub、GuardDuty中央管理、証跡集約アカウント配置用OU |
| Suspended OU | 一時的に運用を停止したいアカウント用OU |
| Workload OU | 各開発案件、社内システム用OU※アカウントはさらに下のOUに配置 |
| Production OU | 本番環境アカウント用OU |
| SDLC OU | 開発、検証環境アカウント用OU |
基本はAWS規範ガイダンスで定義した内容をベースに運用しているが、実際の運用背景に合わせて以下の違いがある
適用していない内容
Infrastructure OU
ネットワークアカウントや共有サービスアカウントを集約する OU だが、現時点では社内ネットワークと AWS の接続（Direct Connect / VPN）や、VPC Endpoint の集約などの具体的なユースケースがないため
追加の内容
Suspended OU
アカウントのクローズには最大 90 日かかる場合があり、また一部の案件ではアカウントを維持したまま、一定期間利用停止の用途もあるため
SCP
導入初期は汎用性が高い、誤作動可能性が低いものを中心に設定している
・ControlTowerの強制有効内容
諸事情によってControlTowerを採用していないが、ControlTowerの一部強制有効SCPにOrganizations管理に共通するものを採用している
Organizations導入前後比較
証跡管理
| 項目 | 個別証跡 | 組織証跡 |
|---|---|---|
| 設定頻度 | アカウントごとに必要 | 管理アカウントのみ |
| 保存先 | アカウントごと指定 | 指定S3バケットのみ |
| 横断管理 | 対応していない | 既存、新規アカウントどちらも自動で対象になる |
| 改ざん耐性 | 権限があれば変更可能 | メンバーアカウントは変更不可 |
IAM権限管理
| 項目 | (アカウントごとに)IDプロバイダ | IAM Identity Center |
|---|---|---|
| 設定頻度 | アカウントごとに作業が必要 | ユーザー・許可セット作成済みであれば省略可能 |
| 複数対応 | プロバイダによるが、GoogleWorkspaceの場合はユーザー単体操作のみ | 一括変更可能 |
| 横断管理 | プロバイダによるが、GoogleWorkspaceの場合は対応していない | ユーザー・アカウントベースで確認可能 |
Organizations導入で個人的によかったと思う点
アクセスポータルが使える
従来のロール選択画面ではアカウントIDとロール名しか表示されないが、
ポータルだとUIの向上、検索機能、一時アクセスキー発行などいいところがたくさんあって、全ての管理対象アカウントにアクセス権限(場合によって1個のアカウントに複数の権限も)を持つ管理者としてはすごく助かる
アカウントのカテゴリ化
OU設計段階で本番と本番以外のアカウントを分け、さらにアカウント名の命名規則を設けることで、従来別途アカウント一覧など資料を管理している内容を素早く確認できるようになる
中央管理
SecurityHub CSPM、GuardDutyの中央管理機能は一括で適用できるだけでなく、適用したものはメンバーアカウント側から変更できるないのが継続的に監視することを保証できる
メンバーアカウントの設定画面(AdministratorAccess権限を持つIAMユーザー)
異なる部署のAWSアカウント運用基準にも差があるため、最低限設定すべきもの、セキュリティを強化するものをpolicy経由で実現可能になった
OU単位でStacksetsを実施できるように
Organizations導入のメリットというより、Stacksetsは元々Organizationsと合わせて使う認識で、従来のスタンドアロン環境では、全リージョン共通設定があるため、各アカウント単位でStacksetsを設定、実施しましたが、Organizations管理になると、OU単位で指定できるようになる、またOU指定しても、一律適用ではなく、指定OUに特定アカウントを追加・除外の柔軟対応もできる
参考資料
OU構成
セキュリティOU
https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/security-reference-architecture/security-tooling.html
https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/security-reference-architecture/log-archive.html
SCP-Mandatory controls
SCP-Strongly recommended controls
SCP-Elective preventive controls
SecurityHub CSPM中央管理
GuardDuty中央管理
CloudTrail中央管理