chroju.dev/blog

the world as code

AWS Organization 等、マルチアカウント管理サービスをどう使うか

AWS マルチアカウントの管理を Toil にしないために - Qiita
この記事は GLOBIS Advent Calendar 2019 - Qiita の9日目です。 7月に GLOBIS へ SRE として参画してから、集中的に取り組んできたことの1つである「AWSマルチアカウントの構成や運用効率...
AWS マルチアカウントの管理を Toil にしないために - Qiita favicon https://qiita.com/chroju/items/ddf6266b704fe26b5d7c
AWS マルチアカウントの管理を Toil にしないために - Qiita

昨年末に Qiita のほうでこのようなエントリーを出した。このときは Organizations には触れていなかったのだが、その後年明けから Organizations はじめ「マルチアカウント管理のためのサービス」に触れてきたので、改めてまとめたい次第。

率直に言ってマルチアカウント管理のためのサービスは多すぎると感じている。 Organizations が代表的だが、その他にも Control Tower が近年出てきたり、 AWS SSO は使えるのかどうなのかとか。あとはサービスによってマルチアカウント制御の仕組みを独自で持っているものもあったりする。そんな中で何をどう使えばいいかがまったくもってわからんので、一旦自分なりの考えをまとめておく。あくまで自分なりの答えなのでベストプラクティスなどと呼ぶつもりはないが、一つの指針として参考になったらよいなと考えている。

なお、本記事は2020年2月時点の情報に基づく。1年も経てば状況はまたガラリと変わっているだろう。現時点で「マルチアカウント管理のためのサービス」としては、以下のものがある、という状態である。

  • AWS Organizations
  • Control Tower
  • AWS Single Sign-On
  • CloudFormation StackSets

だいぶ長いしまとまっていないので、時間がなければ最後までスクロールして Conclusion を見たほうがはやい。

マルチアカウント管理とはつまるところ何がしたいのか

そもそも「マルチアカウント管理」とは具体的に何を欲しているのか。自分の場合、まとめると以下4点になる。

  • 権限管理 : IAM User を個別に作ると面倒なのでログイン管理を集約したい
  • 設定管理 : 各アカウントの基本的な設定は一括で統一的に適用したい
  • 監査 : マルチアカウントの利用状況を効率的に監査してガバナンスを効かせたい
  • 集約化 : ログなどをアカウントごとに蓄積すると閲覧しづらいので集約管理したい

混乱が生じやすいのは、これらの目的を魔法のように解決してくれるサービスがあるわけではない点だろう。まぁ「それはそうだろ」という話でもあるのだが、それにしてもマルチアカウント管理のサービスが Organization 1つに統一されているわけでもなく、各種サービスでできることが重なっていたり微妙に違っていたりもする中、様々組み合わせなければ「やりたいこと」が実現できないので見通しづらい。

以下では、これら目的視点で各サービスを見ていく。

AWS Organizations はほぼ必須

AWS Organizations(AWS アカウント全体の一元管理)| AWS
アマゾン ウェブ サービス (AWS) の AWS Organizations
AWS Organizations(AWS アカウント全体の一元管理)| AWS favicon https://aws.amazon.com/jp/organizations/
AWS Organizations(AWS アカウント全体の一元管理)| AWS

Organizations はどんな場合であれ、マルチアカウントを使うのであれば有効化してよい。というのはコストメリットが大きくなるため。1つには Reserved Instance を複数アカウントで共有する機能を利用できるようになるので、柔軟な RI 購入が実現できるようになる。もう1つは「ボリューム割引」の考え方があり、複数アカウントを Organizations で一括請求にまとめることで、価格が低くなる可能性が高まる。

また、この後で触れていくが、一部サービスについては Organizations を活用して管理を効率化できるものがある。そのため「何はなくてもとりあえず Organizations に契約アカウントはまとめておく」ようにすると、恩恵を受けられる機会は多くなる。 Organizations には、実行可能な API をアカウント単位で制御する SCP といった機能などもあるが、こういった付随機能がよくわからなくても、極論とりあえず Organizations を有効化しておくだけでもいい。

Control Tower を使う場面はかなり限られる

AWS Control Tower(複数アカウント環境をセキュアに設定、管理)| AWS
AWS Control Tower は、セキュリティ、オペレーション、およびコンプライアンスのルールを使用して AWS ワークロードを管理する、優れた設計のマルチアカウント環境を設定するための単一の場所を提供します。本日のプレビューにサインアップしてください!
AWS Control Tower(複数アカウント環境をセキュアに設定、管理)| AWS favicon https://aws.amazon.com/jp/controltower/
AWS Control Tower(複数アカウント環境をセキュアに設定、管理)| AWS

Control Tower はそもそも何者なのかすごくわかりにくいのだが、以下の機能を持つ Organizations のメタ管理サービスみたいなものと捉えている。

  • Landing Zone
  • Account Factory
  • ガードレール
  • SSO

Landing Zone とは AWS が提唱するマルチアカウント構成のベストプラクティスを指す。以下のページに構成図が載っているので、あわせて見てもらうとわかりやすいのだが、つまるところ監査専用アカウント、ログ集約専用アカウントを設けて、それらの間を AWS SSO を使って行き来するというようなものである。 Control Tower はボタン1つでこの構成を用意してくれるというものだ。

Landing Zone | Implementations | AWS Solutions
AWS Landing Zone helps customers quickly set up a secure, multi-account AWS environment based on AWS best practices.
Landing Zone | Implementations | AWS Solutions favicon https://aws.amazon.com/solutions/aws-landing-zone/
Landing Zone | Implementations | AWS Solutions

自動でいい感じにやってくれるなら最高じゃないか、と思いたくなるところなのだが、曲者なのがこれに付随する Account Factory という機能である。 Landing Zone で生成されたログ集約用アカウントや監査用アカウントで管理してくれるのは、この Account Factory を使って新規作成したアカウントに限られる。したがってすでに Organizations を利用済みだったり、 AWS アカウントを準備している場合に、それを Landing Zone へ組み込むということができない。そのため Control Tower を有効活用できるのは、これから AWS を使い始るような場合に限られる。

なお、ガードレールは Config Rules 等を使って Landing Zone 内の各アカウントを監査する機能であり、 SSO は先に言及した通りである。これらも自動的にセットアップしてくれるのだが、 Account Factory で作成していないアカウントはやはり制御下に追加できない。今後このあたり改善されないだろうかと期待している。

SSO vs switch role

権限管理については IAM User と switch role の仕組みを使うか、 AWS SSO を使うかの2択だろう。 switch role は、あるアカウントの IAM User から別アカウントの IAM role へ権限の切り替えを行う方法で、詳しくは ロールの切り替え (コンソール) - AWS Identity and Access Management に掲載されている。 AWS SSO は読んで字の如く、マルチアカウントでシングルサインオンを実現するサービスである。

基本的には Active Directory (AD) をすでに有している、あるいはその管理を厭わないのであれば SSO を使えばよいし、そうでなければ switch role という考え方をしている。 AWS SSO は非常に便利な機能ではあるのだが、ID ソースとして利用できるのが AD か SSO 自身の ID ストアのいずれかに限られている。そして後者は API が存在せず、 GUI 上で管理しなくてはならないので手間が大きい。そのため AD ほぼ一択という状況なのである。

switch role であれば単なる IAM の活用に過ぎないので、 Terraform 等を利用した管理が実現できる。マルチアカウントの ID 管理を Terraform に落とし込むのは若干面倒ではあるものの、一度セットアップしてしまえば難しくはない。エムスリーさんのブログに非常にわかりやすくまとめられていたので貼っておく。

ちなみに、 AWS はサードパーティの SAML IdP にも対応しているので、 G Suite などを持っているのであれば、それを活用するのも手である。

設定管理の集約化における銀の弾丸はない

マルチアカウントを管理していると、各アカウントで設定を揃えたい部分が出てくる。例えばよく使う IAM Policy を全アカウント作っておきたいとか、そういうもの。これに関しては残念ながら万能な解決策は今のところ存在しない。

新機能: AWS CloudFormation StackSets が AWS Organization のマルチアカウントで利用可能に | Amazon Web Services
 Infrastructure-as-code とは、JSON 形式や YAML 形式などの機械可読テキストファイル、または Java、Python、TypeScript に代表される一般的なプログラミング言語などを使用した IT インフラストラクチャの作成および管理のプロセスを指します。AWS では、AWS CloudFormation または AWS Cloud Development Kit を使用して、クラウドインフラストラクチャの作成、管理を自動化しているお客様が多数見られます。 CloudFormation StackSets を利用すると、わずか数回のクリックで複数のリージョンにある複数の AWS アカウントにわたって CloudFormation スタックをロールアウトできるようになります。StackSets をローンチした当時は、アカウントのグループ化の目的はまずビリングプロセスにありました。お客様は AWS Organizations のサービス開始以降、ビリング、アクセス制御、コンプライアンス、セキュリティ、リソース共有などさまざまなビジネスニーズにわたって複数の AWS アカウントを集中管理できるようになっています。 Organizations で CloudFormation StackSets を使用する 本日より、お客様が AWS Organizations で、複数アカウントを管理するための CloudFormation StackSets の使用法がシンプルになります。 これで、複数のリージョン、複数の AWS アカウントにわたって、いかなる AWS CloudFormation 対応サービスであっても一元的にオーケストレーションできるようになります。たとえば、組織内で複数のリージョン、複数の AWS アカウントにわたって、AWS Identity and Access Management […]
新機能: AWS CloudFormation StackSets が AWS Organization のマルチアカウントで利用可能に | Amazon Web Services favicon https://aws.amazon.com/jp/blogs/news/new-use-aws-cloudformation-stacksets-for-multiple-accounts-in-an-aws-organization/
新機能: AWS CloudFormation StackSets が AWS Organization のマルチアカウントで利用可能に | Amazon Web Services

最も「万能な解決策」に近いのが CloudFormation StackSets だろう。もともとマルチアカウントに設定展開する機能を持っていた StackSets だが、先日 Organizations と連携して、新たに Organization へ追加されたアカウントへ自動展開が可能になった。アカウント作成時の初期設定をこれに全部任せてしまえるわけである。

しかし API の公開がまだなので、 StackSets for Organizations の設定は手作業となってしまう。まぁ、そこにこだわらなければこれが万能解に近い。すべて完全なコード化を行いたいのであれば、 Terraform を先のマルチアカウント展開させる方式で活用することになる。個人的には現時点ではこっちを選んでいる。

Organizations による一括設定

Image from Gyazo

Organizations には「信頼されたアクセス」と呼ばれる機能がある。この画像のようにサービスごとに「アクセスの有効化」ボタンが用意されており、これを押すことで有効となる機能だ。

これは何なのかという話だが、サービスごとに意味するところが異なるので、それぞれ調べて使う必要がある。そして一部サービスについては(具体的には CloudTrail)、これを有効化することで Organization 内の全アカウントで機能を有効化することができる。一方、例えば Config は全アカウントの状況を集約したダッシュボードを作れるようになるだけであり、機能の有効化までは賄われていない。

これもまた直感に反しているというか、わかりにくいなと思う機能の1つではある。

自動監査系のサービスはお好みで

各種ログであったり、 AWS の使用状況であったりを AWS が自動的に監査してセキュリティ上の懸念を通知してくれるというサービスは様々ある。 GuardDuty, Config Rules, Amazon Detective, Security Hub などなどが該当するだろう。これらもマルチアカウント集約が可能であったりはする。

しかし何分サービスの数も多いので、とにかく全部使っておけばよいというものでもなくなってきている。もちろん「やるべきか否か」で言えば「やるべき」になるのだろうが、監査をすべて有効化したところで、その通知をさばいて対処するのは人間である。結局通知がさばけないのであれば通知だけされても意味はない。セキュリティ上、何を優先的に確認しなければならないのか、チームなり会社なりで方針を決めた上で活用していかなくてはならない。

各種監査系サービスのマルチアカウント管理について、調べた範囲で対応状況を記載しておく。

AWS Config

  • Config Aggregater という集約機能がある
  • Organization 内のアカウントからデータ集約させることができる

Amazon GuardDuty

  • Organization には連携しない
  • マスターアカウントとして任意のアカウントを決めて、そのアカウントから集約したいアカウントを「招待」する形で集約化できる

AWS Security Hub

  • GuardDuty と同様

Amazon Detective

  • GuardDuty と同様

まぁ、正直全部 Organizations と連動してほしい。

Conclusion

何もまとまらないのだが、あえてまとめるとこんな感じかと。

  • Organizations をまず有効化して、 Organizations を基軸に集約化を考える
  • Control Tower, SSO は最悪一旦無視してもいい
  • Infrastructure as Code 過激派じゃなければ CFn StackSets は便利
  • マルチアカウントを一括設定する Terraform の使い方は習熟しておくとよい
  • 監査、管理系の各サービスは、個別にマルチアカウント管理の方法が異なるのでそれぞれ調べる必要がある

僕としては Organizations を中心に、もう少しシュッとした感じになってくれることを期待している。