AWSのマルチアカウント環境について考えてみた

AWSでのマルチアカウントについて調べてみたのでまとめてみました。
誰かの参考になれば幸いです。

対象読者

AWSで実際に開発していく時にはマルチアカウントでやっていくんでしょ？
でもよくわからないんだよなぁ
マルチアカウントだとどうやって認証とかするんや？
そもそもどうやって管理・運用してるんや？
よくわからん…

この記事でやること

AWSでのアカウント運用のベストプラクティスを自分なりにまとめてみる
マルチアカウント運用についてまとめる
セキュリティとしてガードレールを設置する場合に使用するサービスと内容をまとめる

結論
AWS アカウントの管理と分離
シングルサインオン
まとめ
参考サイト

結論

AWS Control Towerを使おう！

Control Towerで作成できるLanding Zoneは、ベストプラクティスに基づいたマルチアカウント環境のセットアップを行ってくれます！
しかも６０分待つだけでできるとのこと！

参考⇒AWS マルチアカウント管理を実現するベストプラクティスとは ?、スタートアップにおけるマルチアカウントの考え方と AWS Control Tower のすゝめ

とはいっても、何がベストプラクティスで具体的にどんな設定がされるのかは把握しておいた方が良いのでそれをまとめてみます！

AWS アカウントの管理と分離

まずは、AWSのWell-Architectedフレームワークを参照してアカウント管理のベストプラクティスを確認してみます。

セキュリティの柱のAWSアカウントの管理と分離では以下の５項目が挙げられています。
この５項目から必要な要素を考えていきます。

アカウントを使用してワークロードを分ける
AWSアカウントを保護する
アカウントを一元的に管理する
制御を一括設定する
サービスとリソースを一括設定する

アカウントを使用してワークロードを分ける

Well-Architentedフレームワークでは、環境ごとにアカウントレベルで分離を強く推奨しています。

アカウントの分離をおこなうということは、いわゆるマルチアカウントで運用するということを意味します。

いったいなぜマルチアカウントを推奨しているのでしょうか？

メリット・デメリットを自分なりにまとめてみました

マルチアカウントで得られるメリット

メリットは以下の点です。

マルチアカウントによるメリット

環境の分離
コストの明確化
制約の緩和

環境の分離

環境をアカウントで分けることで、操作ミスなどによってサービスに影響が出ることを防ぐことができます！！

例えば、提供するサービスや、開発用・検証環境用・本番環境用毎にアカウントを分けるということです。

また、開発環境と本番環境では要求されるセキュリティや認証などが異なるはずです。
開発環境は開発者であれば気軽にアクセスできるようにするが、本番環境は認証が複数必須かつ読み取りアクセスのみなどです。

もそ、１つのアカウント内で複数の環境が混在してしまうと、設定が煩雑になり運用コストが増加することが予想できます。

権限の面で見ると、IAMの設定が楽になりますね。
１アカウント内だと、どのリソースを操作できるか明示していくことになりますが、サービスに機能が追加されたりするたびに見直す必要がでてくるので面倒くさいですよね。

このアカウントはこのサービスのリソースしかない！というのであれば、考慮する点が減少するので管理が楽になります！

コストの明確化

サービスAはアカウントA、サービスBはアカウントBと分けていると、アカウントの単位がサービスの単位になります！

コスト配分タグを利用することでコストを見ることができますが、タグの運用・管理戦略を厳密に定めないとぐちゃぐちゃになることが容易に想像できます。
アカウントを分離してしまえば、そのアカウント内でのタグ戦略だけになるので運用コストが下がることが予想されます。

制約の緩和

AWSでは、１つのアカウントで作成できるリソースの上限（サービスクォータ）が存在します。

緩和申請はできますが、環境を複数のアカウントで分けておけば上限に達する可能性が低くなります。

マルチアカウントでの課題

マルチアカウントを使えば課題は何もなくなるのか？

いいえ。
もちろん課題はあります。

マルチアカウントによる課題

複数のアカウントの維持・管理コスト
社内のコンプライアンスに則った設定でアカウントの発行コスト

複数のアカウントの維持・管理コスト

複数のアカウントを利用する場合、それぞれのアカウントを適切に運用・管理していく必要があります。

１つのアカウントであれば１つのアカウント内で完結するものが、マルチアカウントでは全アカウントに展開する必要がでてきます。

しかし、これはAWS Organizationsで解決することができます。
AWS OrganizationsではAWSアカウントの作成と管理、作成後の制御を自動化することができるためです。

社内のコンプライアンスに則った設定でアカウントの発行コスト

アカウントはただ発行すれば良いものではありません。

操作ログをちゃんと記録するようにしたり、認証を追加したり、請求情報をまとめたりなど設定しなければならないことが多く存在します。

これらの設定にはコストがかかります。

しかし、これもAWS Organizationsで解決することができます。
AWS OrganizationsではAWＳアカウント作成後の制御も自動化することができるためです。

具体的には、SCP(サービスコントロールポリシー)を利用することでアカウントやグループごとに制限を課したり、認証にMFAを強制したりすることが可能です。

AWSアカウントを保護する

AWSのアカウントを保護するとは具体的に以下のことになります。

ルートユーザの保護と使用の回避
連絡先情報の最新化
MFAの有効化
認証情報へのアクセスをモニタリング

これらについては、AWS Organizationsの管理アカウントのベストプラクティスとメンバーアカウントのベストプラクティスがより参考になります。

AWSアカウントの保護にに必要な要素

管理アカウントは必要とするタスクにのみ使用する
複雑なパスワードを使用する
MFAを有効にする
連絡先情報に電話番号を追加する
誰がアクセスできるかを確認、追跡する
ルートユーザーの認証情報の使用プロセスをドキュメント化する
ルートユーザーへの認証情報へのアクセスをモニタリングする
SCPを使用して、メンバーアカウントのルートユーザーで行えることを制限する

複雑なパスワードや、MFAを使用するなど当たり前の内容が多いですね。

注目すべきは、管理アカウントは必要とするタスクにのみ使用するです。

管理アカウントは必要とするタスクにのみ使用する

AWSリソースCloudTrailの追跡とログを保持すること以外は、全て他のAWSアカウントで行うべきです。

管理アカウントはOrganizationsのSCPが使えないため、SCPが適用できる他のAWSアカウントで保持すべきというのがベストプラクティスです。

アカウントを一元的に管理する

アカウントはAWS Organizationsで一元的に管理しましょうということですね。

OrganizationsでAWSアカウントの作成と管理、作成後の制御を自動化できるからです。

OU(Organizational Units:組織単位)で一元的に権限を管理することが可能なため、権限のについては低いコストで変更可能です。
確認する箇所が１か所になるので、ヒューマンエラーを最小限にできます。

制御を一括設定する

アカウントを個別で設定するのではなくて、Organizationsなどで一括して設定しましょうということです。

OrganizaionsではOU(組織単位)でアカウントをグループ化でき、SCP（サービスコントロールポリシー）でサービス・リージョン・アクションの制御をすることが可能です。

OUについても、ベストプラクティスがありますので見てみましょう。

OUのベストプラクティス

このサイト：AWS Organizations における組織単位のベストプラクティスがまとまっていてわかりやすいです。

10個以上のOUが解説されていますが、全てを作る必要はなくて、必要に応じて作っていけばいいという感じですね。

ここでは細かくは見ませんが、興味があれば上述のサイトから見てみてください！

制限とは？

そもそも一括で設定する制御とはなんでしょうか？

簡単に言うと、適切なレベルでできることを制限するとのことでした。

今までのやり方ですと、基本的には全てできないようにして、必要な時にだけ許可するというものです。

しかし、ビジネスのスピードに付いて行くためにリリースを頻繁に行って改善をしていくには、毎回許可を得るのというのが遅すぎる！

そこで、ガードレールという新しい(2019年には出てたから新しくはないかも…)考え方があります。

簡単に言うと、「アカウントに対して厳しすぎる制限を設けるのではなく、できるだけ自由を確保しつつ望ましくない領域のみ制限、または発見する」とのことでした。
必要な場合に許可するのではく、そもそも問題のあることはできないようにして、どんなにスピードを出しても問題ないようにする考え方です。

セキュリティと便利さのトレードオフではなく、どっちも大事だからどっちも良くするって感じます。

そもそも危ないことをガードレールで防いでくれているなら、その制限の中で安心してスピード高く様々なことができますね！
管理・運用側としても、危ないことはできないようにしているなら安心して寝ることができます。
ただ、実際に取り入れるとなると組織構造やワークフローにも手を入れないといけない気が…

一応、従来行われてきた方法はゲートキーパー方式と呼ぶことができて、ガードレール方式ではそもそも事故を防ぐようにしているイメージです。

ガードレール的なセキュリティでは、以下の内容を自動で横断的に設定できるようにする考え方です。

予防的ガードレール (制限) : 対象の操作を実施できないようにするガードレール
発見的ガードレール (検知) : 望ましくない操作を行った場合にそれを発見する、またはリスクのある状態を発見するガードレール

このガードレールが、AWSのどういった機能で実現できるかを考えてみます。

予防的ガードレール (制限)

AWSのサービスとしては、OrganizationsのSCPが該当します。

SCPはOUに割り当てることができ、そのOUはアカウントをグループ化することができます。
OU内のアカウントには割り当てたSCPが適用されるため、一括して実行できることの制御が可能です。

SCPで危ないことは実行できないようにしておけば、許可を出さずとも自動的に安全を担保することが可能です！

発見的ガードレール(検知)

AWSのサービスとしては、以下のものが該当します。

発見的ガードレールに該当するサービス

AWS Config Rules
AWS Security Hub
Config Conformance Packs

その他、AWSではないSaaSとしてDome9などのクラウドセキュリティ設定チェックも発見的ガードレールとしての役割が期待できます。

AWSが考えているガードレール

ベストプラクティスに基づいたマルチアカウント環境のセットアップを行ってくれるAWS Control Towerではガードレールを設定することができます！
AWS上で必須・強く推奨・選択的な予防的ガードレール・発見的ガードレールが定義されているので、AWS上ではどんなガードレール必要なのかを理解するのに役立ちます！

AWS Control Tower ユーザーガイド

量が多いのでここでは細かく見ていきませんが、ざっと見た感じではどれも設定した方がよさそうなものばかりです。
ガードレールは別記事でまとめてみたいと考えてます