AWS で環境を構築する際はマルチアカウントになることが多い、これは理解していたつもりでした。 stg 環境と prod 環境は AWS アカウントごと分ける。dev 環境も分ける。
しかし、世の中のベストプラクティスはもっと先を行っていました。
なぜアカウントを分けるのか
AWS アカウントを分ける理由は 3 つあります。
- isolation
- authz & anthn
- auditing and reporting
isolation
そもそもとして、環境は分離しないと、というものです。 stg 環境での構成変更が prod 環境へ影響することはあってはなりません。dev 環境の脆弱性が prod 環境の情報漏えいに繋がることもあってはならない。 また、API の rate limit が各環境で共有されてしまった結果、qa 環境でのラッシュテストによって prod 環境のスケールアウトができなくなることもあってはならない。
そう考えると、まず workload を担う各環境については AWS アカウントを分離すべきです。
authz & authn
各環境で AWS アカウントを分離する場合、次に問題となるのがユーザアカウントです。 たくさんの環境があれば、たくさんの AWS アカウントができます。個々の AWS アカウントごとにユーザアカウントを作成してしまうと、管理側、そしてユーザ側の管理負荷も重くなります。 これを何とかするためには AWS 上のユーザアカウントを統合管理するための AWS アカウントを構築することが必要になります。 この手の AWS アカウントは踏み台アカウントや Custodian アカウントと呼ばれます。
ユーザはまず Custodian アカウントにログインし、そこから prod 環境等の Workload を担当するアカウントへ assume-role する構成になります。
auditing and reporting
次に問題になるのは監査です。多数の環境ができたことを前提にすると、それぞれの AWS アカウントで監査の仕組みを整えるのは非効率です。 これを実現するためには、各 AWS アカウントの監査記録を集約・分析する AWS アカウントが必要になるでしょう。
世の中のマルチアカウント構成
このように、AWS アカウントはもはやどんどん分割することが多いようです。
各企業の事例
クラウドワークスはまさに Custodian アカウントや Audit アカウントを分割していますし、KDDI も管理用アカウント郡とユーザアカウント郡を明確に分離しています。 DeNA、NRI も「踏み台アカウント」とともにマルチアカウントを採用していることがわかります。
- AWS Organizationsによるマルチアカウント戦略とその実装 - クラウドワークス エンジニアブログ (クラウドワークス)
- ぼくらのアカウント戦略〜マルチアカウントでのガバナンスと権限管理の全て〜 (KDDI)
- DeNA の AWS アカウント管理とセキュリティ監査自動化 (DeNA)
- 金融サービス向けに理想のCI/CDを追い求めたお話 - Speaker Deck (NRI)
- 「これ危ない設定じゃないでしょうか」とヒアリングするための仕組み @AWS Summit Tokyo 2018 (CyberAgent)
- AWS Multi-Account Architecture with Terraform, Yeoman, and Jenkins | by Paul Bourdel | Slalom Build | Medium (Slalom Build)
AWS が提供するベストプラクティス
このように、世の中のベストプラクティスは既にマルチアカウント制に移行しています。 AWS はそのベストプラクティスを構成するソリューションを AWS Landing Zone として展開しています。
上記画像は Landing Zone | 実装 | AWS ソリューション より引用。
AWS アカウントは AWS Organizations によって管理されますが、ログアーカイブアカウント、セキュリティアカウント、共用サービスアカウントがまず構成されます。 ログアーカイブアカウントは CloudTrail や AWS Config 等のログが AWS アカウント横断で蓄積されます。 セキュリティアカウントは監査者が使用・実行するためのアカウントです。 また、共用サービスアカウントはなかなか正体がつかめませんが、以下の事例では Jenkins や Terraform Enterprise といったサービスを構成していることが挙げられていました。 つまりは AWS アカウント横断で管理するものは、専用の AWS アカウントを作りましょう、という考え方です。
さらに、ベストプラクティスをソリューションではなくサービスとして展開するのが AWS Control Towerです。
Gruntwork から見た AWS ベストプラクティス
Terragrunt 等で有名な Gruntwork 社は、Landing Zone はまだ不十分だという見解を述べています。
もちろん Gruntwork 社のビジネスモデルを考えるとポジショントーク的な面は否めませんが、 カスタマイズが難しい、自動化が不十分といった点は傾聴に値すると考えています。
各社のプラクティスから読み取れること
基本的にマルチアカウント構成を取るという観点では AWS Organizations の利用は鉄板だと感じました。 私も使って感じましたが、面倒な AWS アカウントの作成をほぼ自動化できるのは非常に便利です。
そのうえで、AWS CloudTrail、Config、GuardDuty を使ってセキュリティ・監査面で各 AWS アカウントを統合管理するのはもはや当たり前のように実現されています。 これらサービスが AWS Organizations と統合されてきているのも、よくわかります。KDDI の事例では、さらにこのあたりの仕組みを自前で構成していました。
また、このようなサービスを駆使して実現している思想を AWS では「ガードレール」と読んでいます。 - AWS Control Tower のガードレール - AWS Control Tower
今呼んでいる「AWS の薄い本Ⅱ アカウントセキュリティのベーシックセオリー」ではガードレール思想を以下のように説明しています。
ガードレール思想とは、従来のゲートキーパー(関所)のようにセキュリティのためにビジネスを一旦止めて一つ一つチェックするのではなく、 ガードレールのように横道がそれないように支えていくという考え方です。
早いフィードバックを与えることが DevOps においては非常に重要だとは言われます。 AWS Config や GuardDuty でこっちに進んではダメと発信し、 それでも進み続けたら警告するというのもその 1 つなのでしょう。
