AWS Control Tower導入時に行ったこと
こんにちは。エンジニアの佐々木です。
「北欧、暮らしの道具店」を運営しているクラシコムでは、AWS(Amazon Web Services)をメインのクラウドとして使用しています。
今回は、AWS全体のセキュリティ・ガバナンスを強化させたいと考え、AWS Control Tower導入やSecurity Hub、GuardDutyなどの整備を行ったのでその取り組みに関して紹介します。
ボリュームが大きいため、ブログ2本立てでお送りします。この記事ではAWS Control Tower導入時に行ったことを中心にご紹介します。
背景
3年ほど前からAWSでマルチアカウント運用を行っていますが、サービスの成長やエンジニアの増加に伴いAWS Organizations単位でのセキュリティ・ガバナンスの重要性が増してきていました。
具体的なリスクとしては、新しく追加したAWSアカウントにて脅威検知サービスであるGuardDutyの設定が漏れてしまうなど、主にセキュリティ面で統制が取れなくなってしまう場合が挙げられます。
そういった事が起きないよう予防したり、起きても早急に検知し対応できるよう、良い仕組みを作りガバナンスを効かせることが重要であると考えています。
方針
AWSにはOrganizationsやアカウント単位で包括的にセキュアな状態を保つため予防・検知してくれる便利なサービスが多数存在します。そういったサービスの中から、AWS Control TowerとSecurity Hubの導入、そして導入済みだったGuardDutyの設定の見直しを行いました。
それぞれのサービスの簡単な説明は以下になります。
AWS Control Tower
Organizations内のマルチアカウント環境の自動セットアップ
Security Hub
セキュリティのベストプラクティスのチェック、アラートの集約
GuardDuty
悪意のあるアクティビティ、潜在的な脅威の検出
これらの利用に関するAWS公式の資料があるので、各サービスの詳細に関してはそちらを参照いただき、当ブログでは実際にどんなことに注意し導入を進めたかを紹介したいと思います。
参考: AWS ControlTowerでマルチアカウント管理しませんか
なお、クラシコムではAWSリソースの管理でTerraformを導入しており、リソースがセキュアかどうかを静的解析してくれるAqua Security社のtfsecというツールをCI上で稼働させています。
しかし、記述されたリソース単位でのスキャンになるため、先述したGuardDutyの設定がされていないなどの検知を行うことはできません。また、Terraformでは管理ができていないリソースもいくつか存在している状態です。
tfsecは追加直前の新規リソースに対して、AWSのサービスは作成後のリソースや漏れ、未知に対してのソリューションとして使い分けを行います。
AWS Control Towerの導入
AWS Control Towerの導入について紹介していきます。
AWS Control TowerはAWS Configなど複数のAWSサービスを同時に有効化しマルチアカウント環境を管理できるようにしてくれるサービスです。そのため、既存の環境に対して影響が出ないか仕様を把握しつつ進め方を整理しました。
すでにマルチアカウントで運用している状態であれば、実際の導入方法や注意すべき点などに関しては以下の記事が非常に参考になります。
上記記事やAWS公式のドキュメントを参考にした結果、OU(Organization Unit)やCloudTrailなどの整理は必要になるものの、私達の場合既存の環境に影響を与えることはほぼなく、AWSアカウントの登録・登録解除も容易であることがわかりました。
OUの整理
AWS Control Towerにはコントロール（ガードレール）という機能があり、AWSのリソースを管理する上でのルールがたくさん登録されています。例えば Amazon S3 バケットへのパブリック読み取りアクセスが許可されているかどうかを検出する などです。
デフォルトでは無効化されているルールがほとんどで、必要に応じて有効化し、ルールに違反しているリソースがないかを検出可能な状態にできます。ここでOUが関わってきます。
OUはAWS Organizations内のアカウントを束ねるフォルダのようなもので、AWS Control Towerで管理をするかどうか、ルールを適用するかどうかがOU単位になります。そのためOUの整理がまずは必要でした。
以下の記事を参考に、SDLCなど馴染みのない言葉はDevelopmentに置き換えたうえで、ローカル環境で試しにディレクトリを掘ってモックをつくりtreeコマンドで確認して進めました。
# ローカルで作ったOUモック
.
└── Root
├── Infrastructure
│ └── Users
├── Admin(Organizationsの管理アカウント)
├── Sandbox
│ └── Sandbox
├── Security
│ ├── Audit(Control Towerが自動作成)
│ └── LogArchive(Control Towerが自動作成)
└── Services
└── ServiceA
├── Development
│ └── ServiceA
└── Production
└── ServiceAポリシーステートメントや例外といった、より細かいOUや役割を持ったアカウントの作成は現時点では不要と判断し、今後必要あれば整理する想定です。
CloudTrailの注意点
AWS Control Towerでアカウントの管理を開始すると、CloudTrailやAWS Config、IAM Identity Center(旧AWS SSO)などといったサービスが同時に有効になります。
今回は既存のCloudTrailの証跡がすでにあったため、AWS Control Tower導入に伴いそちらも整理しました。ここで注意したいのは以下の点です。
証跡が２つ以上になると料金がかさばる
AWS Control Tower作成の証跡は消さないほうが良い
AWS Control Tower作成の証跡でデータイベントを取得
するようにするしない（後述しますが訂正がありました）
証跡の重複への対応
既存のCloudTrailの証跡があっても、AWS Control Towerは問答無用で新たな証跡を追加してきます。証跡が２つ以上になった時の料金はグッと大きくなる可能性があるので、まずはここに注意が必要でした。
AWS AWS Control Tower にアカウントを登録すると、そのアカウントは新しい組織の AWS CloudTrail 追跡によって管理されます。CloudTrail 追跡の既存のデプロイがある場合、AWS AWS Control Tower にアカウントを登録する前にアカウントの既存の追跡を削除しない限り、料金が重複して発生する可能性があります。
日本語のドキュメントには上記のように記載されていますが、基本的にCloudTrailは無料で、2つめ以降の証跡に関しては100,000イベントあたり 2.00 USDが発生します。
そのため既存の証跡が一つだけだった場合、課金額が2倍になるのではなく、新しく課金され始めるようになるため金額が倍以上に膨らむ可能性があります。
Organization単位で2つ証跡は不要だったので、既存の証跡は停止し、AWS Control Towerが有効化した証跡のみが有効となるようにしました。AWS Control Tower側の証跡を使うようにしたのは、AWS Control TowerがCloudFormation StackSetsで展開されているからです。AWS Control Towerが作成するリソースを削除するなど下手に直接いじると、CloudFormationがうまく動作しなくなるリスクがあります。
（別サービスですが過去にElastic Beanstalkでできたリソースを直接消してしまいElastic Beanstalkが消せなくなったことがありAWSサポートに相談したことがありました）
データイベントの取得
AWS Control Towerが有効化した証跡はデフォルトではデータイベントの取得がされません。そのため、必要に応じて追加でデータイベントの取得を設定する必要があります。
この点に関してはAWSサポートに確認し、現状AWS CloudFormation StackSetsでは管理されていないため追加で有効にしても問題ないとの回答をいただき有効化しました。 （※ こちらの記述は誤りであり、データイベントや Insights イベント記録用の証跡は別途作成するのが推奨とのことでしたので訂正致します。）
AWS Control Towerのバージョンによっては今後管理される可能性もありうると思うので、有効化したい場合ドキュメントの確認やAWSサポートへの相談を行うのが良いと思います。
ログの参照
AWS Control Towerを有効化し、新しくできたCloudTrailの証跡を使用することになりました。
これで管理アカウントのCloudWatch Logsで2週間分、またはLog ArchiveアカウントのS3に格納されたCloudTrailのログを確認することができるようになります。S3に格納したログのほうが長期で保存されています。
しかし、AWS Control TowerでKMSを設定していた場合、KMSによって暗号化がなされるためS3に格納したログの参照にはクロスアカウントでのKMSへの権限が必要になります。
また、CloudTrail Lakeの使用は管理アカウント以外ではサポートされていないため、Athenaというサービスを使用しログ検索をし易い状態にするのが望ましいです。
公式のドキュメントに組織全体の証跡用のテーブル作成の記事があるので、その記事を参考にLog ArchiveアカウントにてAthenaでテーブルを作成しました。
テーブル作成のクエリは、万が一削除された場合や更新が必要になった場合のために、Terraform管理しつつAthena上に保存するようにしています。
リージョン拒否設定
AWS Control Towerは比較的新しいサービスで、東京リージョンは2021年4月から使えるようになりました。そして2023年4月に大阪リージョンも使用できるようになりました。
AWS Control Towerは管理リージョンを選択することができ、管理リージョン以外に関するアクセスを拒否するよう設定する機能があります。この機能はリージョン拒否設定と呼ばれています。これは特定のOUではなく、ランディングゾーン全体に適用されるものです。
元々、AWS OrganizationsのSCP(サービスコントロールポリシー)で拒否設定することができ、AWS Control Towerを通してもSCPの設定を行えるという仕組みになっています。
一部のリソースで大阪リージョンを使用していたため、ちょうど良いタイミングでAWS Control Towerを通じてリージョン管理ができるようになりました。
まとめ
AWS Control Towerを使うことでマルチアカウント・リージョンを一元的に管理しやすい状態を作ることができました。
すでにアカウントがあっても停止するような心配なく導入することができ、さらに他のサービスを組み合わせることでさらに管理しやすくできるので、検討している方は作られるリソースや料金に注意して試してみても良いのではと思います。
次の記事では、Security HubとGuardDutyについて紹介できればと思います。
最後に
ユーザー体験をより良くし、セキュアな状態を保ち信頼を積み重ねるプロダクト開発に興味があるエンジニアの方、いらっしゃればぜひお声がけください！
