AWS マルチアカウント管理を実現するベストプラクティスとは ? 第 2 回 ~ Landing Zoneの実現方法
Author : 柳 嘉起
みなさんこんにちは。builders.flash ビジネス×クラウド担当 ソリューションアーキテクトの柳です。
前回は、「AWS アカウント管理」のベストプラクティスについてお話しして、以下のようにまとめました。
- Landing Zone は AWS のベストプラクティスに基づいて構成したアカウントを、スケーラブルに展開していくための仕組みで、マルチアカウント戦略を実現するものです。
- Landing Zone の実現方式として、AWS Control Tower を使用するか、独自実装するかの 2 つの選択肢があります。
前回に引き続き、今回は Landing Zone を実現するための具体的な方法をお話します。なお、本記事では「AWS アカウント管理」におけるベストプラクティスの全体像を掴んでいただくことを主眼に置いています。本記事で全体を理解していただいたのちに、個々の詳しい説明 / 設定については記載したリンク先の資料やドキュメントを参照してください。最初に Landing Zone について振り返ります。
Landing Zone について
Landing Zoneは、ベストプラクティスに基づいたマルチアカウント環境のセットアップをサポートする仕組みです。これは下記機能から構成されます。
- アカウントの発行
・必要な初期設定の済んだアカウントを作成 - 管理用権限の発行
・対象アカウントを管理するための権限を作成 - 共有サービスへのアクセス (ユーザ環境に合わせて個別に実装する)
・AD やファイルサーバ等の共有サービスと、オンプレミスへの接続経路の確保 - AWS ログの集約
・監査用ログをセキュアに一元保存 - ガードレールの設置
・実施してはいけない操作の禁止 (必須のガードレール)
・危険な設定の監視 (強く推奨されるガードレール、推奨のガードレール)
Landing Zone の構成機能についてこれからひとつひとつご説明していくのですが、その前に重要なことがあります。Landing Zone の適用先である Organizations のアカウント構成はどのような構成がよいのでしょうか。ここでマルチアカウント管理のフレームワークをご紹介します。
マルチアカウント管理のフレームワーク
マルチアカウント管理のフレームワークは、AWS のこれまでの経験に基づく Organization Unit 構成のベストプラクティスです。必ずしもすべてこの通りに構成する必要はありませんので、参考にして頂きながら皆様の利用状況や組織の実態に合わせて設計してください。
マルチアカウント管理のフレームワークでは、特にセキュリティ・インフラ・サンドボックスワークロードで構成される部分を、ビジネスのために設計された OU の基本構成 (Starting framework) と位置付けています。中身を見ていきましょう。
フレームワークでは、OU をまず大きく基盤 OU (Foundational OU) と 追加 OU (Additional OU) の 2 つに分割します。
そして基盤 OU と追加 OU 内の OU は、さらに Prod と SDLC (ソフトウェア開発サイクル）の 2 つの OU で分割します。これは本番用と開発用とを明確に区別するためです。
Prod OU のメンバーアカウントには、本番ワークロード用のアプリケーションをホストします。SDLC OU のメンバーアカウントには、本番以外のアプリケーション開発環境 (開発、テスト、本番前検証など) をホストします。SDLC OU 内のアカウントは成果物のステージングを目的としており、本番環境と切り離された環境にすることがポイントです。基盤 OU と追加 OU の中身を見ていきます。
基盤 OU
基盤 OU にはお客様の組織全体で共有される機能 (例えばセキュリティ、ネットワーク、ログ) を設置します。基盤 OU の管理は一般的に専門チームが担当するのがよいでしょう。多くの企業は、インフラチームとは別にセキュリティチームが存在するため、インフラ OU (Infrastructure OU) とセキュリティ OU (Security OU) に分割することをベストプラクティスとしています。またこれらは先に述べたように、Prod と SDLC で別環境をそれぞれ作成します。
セキュリティ OU は、セキュリティ関連のアカウントで使用します。作成を推奨するアカウントは以下の通りです。
- ログアーカイブ (Log Archive) :
組織内の全アカウントにおけるガバナンスやセキュリティに関わるログ (AWS CloudTrail や AWS Config Logs など) を集約 / 保存するアカウント。信頼できる情報を集める場所 (いわゆる Single source of truth) なので、S3 に MFA delete 設定やバージョニング設定を行ったうえで、アクセス権限を最小限に絞るようにします。 - Security ReadOnlyAccess :
セキュリティチームメンバーが読み取り専用のアクセス許可で AWS 環境の他の AWS アカウントにアクセスできるようにするためのアカウントです。本アカウントは監査やセキュリティテスト、および調査をサポートするために設置します。例えばセキュリティインシデントの調査を行う際に、セキュリティチームメンバーはまずこの AWS アカウントにアクセスし、読み取り専用の IAM クロスアカウントロールを使用してから、他の AWS アカウントにアクセスしてリソースの状態を確認します。 - Security Breakglass :
セキュリティインシデント中にセキュリティチームのメンバーが使う、特殊な位置づけのアカウントです。Security ReadOnlyAccess と同じくセキュリティチームが用いるアカウントですが、書き込みアクセス権限を持っているという点が異なります。インシデント発生時に適切な承認を経てアクセスできるようにし、インシデントが解決された時点でアクセスできないようにします。また、すべてのアクセスを詳細に記録するように設定します。 - セキュリティツール (Security Tooling) :
セキュリティ関連のツールやサービスをホストする 1 つ以上の AWS アカウントです。例えば Amazon GuardDuty マスターアカウント、AWS Security Hub マスターアカウント、Amazon Detective マスターアカウント、およびサードパーティのクラウドセキュリティ監視サービスなどをホストします。
インフラ OU は、ネットワークサービスや共有サービスで使用します。
ネットワークサービスはインフラ (ネットワーク) チームによって管理される、オンプレミスとの接続経路や、アカウント間の通信など、組織全体で利用するネットワークサービスです。AWS Direct Connect / AWS Connect Gateway / AWS Transit Gateway / SharedVPC などをホストします。
共有サービスは、AD や DNS、開発ツール (ゴールデン AMI やパイプライン)、統合監視のしくみなど、同じように組織全体で利用するサービスをホストします。
追加 OU
- サンドボックス (sandbox) :
技術者や従業員一人一人に割り当て、AWS サービスを用いた実験を行うためのアカウントです。お客様の社内ネットワークとは接続せず、またインターネットへのアクセスも制限します。 - ワークロード (Workloads) :
ソフトウェアの開発や本番環境に用いるアカウントです。アカウントはチームや組織単位で作成するのではなく、ソフトウェアサービス単位で作成することを推奨します。
ここまでが、Starting framework を構成するアカウントです。改めて整理します。
マルチアカウント管理のフレームワークでは、メンテナンスと継続的な拡張のために、Starting framework から必要に応じて OU を追加することを提案しています。追加例として挙げられているのは以下の OU となります。
- Policy Staging OU
- Suspended OU
- Exceptions OU
- Individual Business Units OU
- Deployments OU
詳細は下記の記事をご確認ください。
Best Practices for Organizational Units with AWS Organizations (英語) »
マルチアカウントの構成には AWS Organizations を使用します。機能の詳細はこちらのユーザガイドをご確認ください。
Landing Zone の各機能を構成する
1. アカウントの発行
アカウントの発行機能では、AWS アカウントの作成と必要な初期設定を行うしくみを構築します。
アカウントの作成
現時点 (2020 年 8 月 1 日) において、AWS CloudFormation では AWS アカウントを作成できないため、アカウントの作成機能は、スクリプト (AWS CLI) やプログラムで実装することを推奨します。もちろん AWS Organization のマスターアカウントから GUI を実行してもよいですが、コード化することでオペレーションミスを防止できることと、よりスケーラブルな仕組みにできるというメリットがあります。
AWS Organizations を利用したアカウント作成の自動化 »
※ブログ中には Organizations で作成したメンバーアカウントは削除できないという記載がありますが、現在は削除可能です。
アカウントの初期設定
作成したアカウントに対する初期設定 (IAM Role の設定、AWS Config Rules の設定、標準 VPC の作成など) は、AWS CloudFormation StackSets を使って自動化するのがよいでしょう。 AWS CloudFormation StackSets とは、複数のアカウントおよびリージョンに対して AWS CloudFormation スタックを作成するサービスです。AWS CloudFormation StackSets は AWS Organizations と連携してスタックの展開を容易にする機能を持っています。詳細は下記をご参照下さい。
新機能: AWS CloudFormation StackSets が AWS Organization のマルチアカウントで利用可能に »
2. 管理用権限の設定
管理用権限の設定では、LandingZone 管理者あるいは各アカウントの管理者が、管理対象アカウントを操作するための権限を設定します。
管理用権限の設定における推奨は、ユーザの認証にシングルサインオン (SSO) を用いることです。そして、各アカウントにロールを作成し、ユーザに与える権限を設定します。これにより、複数のアカウントにまたがったアクセス権の管理を、一元的に行うことができます。AWS では AWS Single Sign-On というマネージドサービスがありますが、パートナーサービスをご利用頂いても問題ありません。
【AWS Black Belt Online Seminar】AWSアカウント シングルサインオンの設計と運用 (動画) »
3. 共有サービスへのアクセス
各アカウントと共有サービスとのアクセス経路と、オンプレミス環境とのアクセス経路を用意し、ネットワーク的に利用可能な状態にします。ここでは Transit Gateway をネットワークアカウントに設置し、それぞれの経路を確立したうえで制御する方法を例にご説明します。
まず各アカウントの VPC 及び共有サービスを Transit Gateway で接続し、ルーティングを管理します。そして、必要に応じてオンプレミス拠点と接続している AWS Direct Connect も接続し経路を確立します。
DNS 機能については Amazon Route53 Resolver Endpoint を共有サービスアカウントに設置し、Route53 Private Hosting を使うことで共通的な名前解決機能を提供します。また、こうすることで共有サービス内アカウント内に作成した PrivateLink の名前解決が可能になり、各環境から利用できます。
Transit Gateway が使えない場合は、VPC Peering や PrivateLink、SharedVPC を用いる方法も考えられます。
なお、ここで述べている構成はあくまで共有サービスへのアクセスを実現する例のひとつであり、お客様の状況によって適切なネットワーク構成やコンポーネントの設置個所は変わります。詳細は下記の資料ならびにブログをご確認下さい。
4. AWS ログの集約
操作履歴の追跡調査や監査に備えるために、CloudTrail と AWS Config のログをログアーカイブアカウントのバケットに集約します。
個別アカウントとは別の権限が設定されているアカウントにログを集めることで、改ざんなどから保護された、信頼できる情報を蓄積することができます。設定自体はシンプルですが、各アカウントで勝手に出力先を変えたり停止したりされないよう、SCP による制限を入れると良いでしょう (後述)。
5. ガードレールの設置
ガードレールは、ビジネスにおけるスピード感と、ガバナンスコントロールの両立を実現する上でカギとなる考え方です。
中央集権的なゲートによる管理では、許可を得るために時間がかかったり、許可を与える作業がボトルネックになったりすることがあります。これに対して AWS では、スケーラブルな管理には分散型のガバナンスが必要で、そのための実装としてガードレールという考え方を推奨しています。
ガードレールでは、実施してはいけない操作のみ禁止 (予防的ガードレール) し、危険な設定操作や、行われたことを把握したい操作については、禁止するのではなく発見 (発見的ガードレール) するようにします。Landing Zone ではこれら 2 種類のガードレールを AWS Organizations 管理下のアカウントに適用することで、セキュリティとガバナンスのコントロールを実現します。
予防的ガードレールは、AWS Organizations の SCP で実装します。SCP の権限制御はルートアカウントにも適用されるなど非常に強力ですので、十分なテストを行ったうえで適用しなければなりません。また、あまりにも厳しい制限はビジネスのスピードを損なうことにもなるため、本当に禁止したい部分に留めておくとよいでしょう。
そして発見的ガードレールは、AWS Config Rules で実装します。これらの予防的ガードレール、発見的ガードレールの具体的な設定は、ControlTower のドキュメントに記載されているので、参照することで、独自実装で AWS Cotrol Tower と全く同じ設定を導入することもできます。予防的ガードレール (SCP) にはログアーカイブの削除禁止や、CloudTrail の設定変更禁止があり、発見的ガードレール (AWS Config Rules) には root ユーザーに対して MFA を有効することや、Amazon S3 バケットへのパブリックアクセスを禁止することなどがあります。
また、発見的ガードレールにつきましては、AWS Config 適合パック (コンフォーマンスパック) をご利用頂くことで、迅速に導入・適用・評価を行えるようになりました。ガードレールを実装する際は、こちらのご利用をご検討ください。
まとめ
「AWS アカウント管理」のベストプラクティスと題しまして、2 回に渡り掲載をさせて頂きましたが、いかがだったでしょうか。多くのシステムや AWS アカウントをシンプルかつスケーラブルに管理したいというご要件に対するソリューションが、Landing Zone の導入です。マルチアカウント環境を整備する際には本記事に記載した手順に従って、実装をぜひ検討してみて下さい。また、まずはクイックスタートしてみたい方には AWS Control Tower を使うこともできます (2020 年 8 月 1 日時点では東京リージョンは対象外)。
最後になりますが、お客様の組織や環境によっては、アカウントをどのように構成し、Landing Zone をどのように適用するのが良いのか、迷われることもあるかと思います。その時はぜひ私たち AWS のソリューションアーキテクトにご相談下さい。Landing Zone をご活用頂くことで、皆様のビジネス発展に寄与できればうれしいです！
この記事の連載はこちら
筆者プロフィール
柳 嘉起 (やなぎ よしき)
アマゾン ウェブ サービス ジャパン合同会社
ソリューションアーキテクト
AWS 入社前は IT アーキテクトとして、システムのインフラ全体について、方針策定や最適化、設計を行っていました。開発と運用を同じくらいの期間、何度も繰り返し経験してきたため、上流工程から実運用を意識して開発を行うこと、また運用で得たことを確実に開発にインプットとしていくことを大切にしています。
好きな AWS サービスは マネジメント & ガバナンスサービス全般。好きな言語はPython。趣味はボウリングと庭いじり (ビオトープの構築 / 運用含む) です。
AWS を無料でお試しいただけます