re:Invent 2024: Workdayに学ぶAWS Organizations活用とガバナンス実践
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Achieving governance at scale (COP383)
この動画では、AWS Organizationsを中心としたマルチアカウント環境におけるクラウドガバナンスの実践について解説しています。Service Control Policies、Resource Control Policies、AWS GuardDuty、AWS Security Hubなど、具体的なガバナンスツールの活用方法が紹介され、特にWorkdayのCybersecurity EngineeringのシニアマネージャーであるColm Usherによる実践事例では、2年間で175から300アカウントに拡大した環境でのガバナンス管理の経験が共有されています。また、AWS Control TowerやAWS IAM Identity Centerを活用したアカウント管理の自動化や、AWS CloudTrail、AWS Configによるセキュリティ監視の具体的な実装方法など、大規模環境での実践的なガバナンスの知見が詳しく説明されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
クラウドガバナンスの基礎：定義と重要性
みなさん、こんにちは。私はAndrew Blackhamです。これからCO 383「大規模なガバナンスの実現」についてお話しします。私はWorldwide Cloud Governanceチームの一員として、ガバナンスサービスに関するコンテンツの提供と、お客様へのガイダンスを行っています。私はNivas Durairajです。AWS Organizationsチームのプロダクトマネージャーとして4年間チームに所属しており、本日は、ガバナンスのベストプラクティスについてお話しいただけるお客様をお迎えできることを大変嬉しく思います。では、自己紹介をお願いします。みなさん、こんにちは。私はColm Usherと申します。アイルランドのダブリンを拠点としており、WorkdayのCybersecurity Engineeringのシニアマネージャーを務めています。
私たちは毎年、サービスの活用方法やベストプラクティスに関する同様のセッションを開催していますが、毎年内容が異なります。ガバナンスは私たちの組織すべてにとって重要ですが、そのアプローチは変化し続けています。新機能や新しい機能を継続的にリリースすることで、ベストプラクティスも進化していきます。また、お客様からのフィードバックを通じて、私たちのガイダンスも改善されています。このセッションでは、クラウドガバナンスの基礎と、ガバナンスサービスの最新機能をどのように活用できるかについてお話しします。
アジェンダとして、まずガバナンスの核となる要素について説明し、次にマルチアカウントの統合について話します。ガバナンスの多くはAWS Organizationsを中心としたマルチアカウント環境に関するもので、ガバナンスの目標を達成するために多くのAWSサービスと統合する必要があります。そして、ColmにWorkdayでのガバナンスの事例を共有していただけることを大変嬉しく思います。では、まずクラウドガバナンスの基本的な定義から始めましょう。ガバナンスという言葉は非常に広い意味を持ち、話す相手によって様々な解釈があります。ある人にとってはボードルームガバナンス、また別の人にとっては企業統治を意味します。今朝、タクシーの運転手に今日のセッションの内容を聞かれ、ガバナンスとコンプライアンスについて話すと伝えたところ、残念ながら政府の話だと思われてしまいました。
このように、私たちが何について話しているのかを具体的に示す必要があることがわかります。AWSには独自のクラウドガバナンスの定義があります。それは、お客様のビジネス目標とガバナンスに従ってベストプラクティスを実装できるようにするためのルール、プロセス、レポートのことです。こちらのQRコードをスキャンすると、ガバナンスサービスの概要とユースケースが掲載された私たちのクラウドガバナンスのウェブサイトにアクセスできます。
ガバナンスの3つの主要ユースケースと規模
私たちには3つの主要なユースケースがあります：規制、運用、そして管理です。規制に関して、ここにいる皆さんは異なる業界、おそらく異なる分野、さらには異なる地理的地域から来られていると思いますが、これは異なるセキュリティフレームワークに対応する必要があることを意味します。PCIコンプライアンス、HIPAAコンプライアンス、あるいは地域特有のセキュリティフレームワークに対応する必要があるかもしれません。次に運用については、M&Aを実行して別の環境を既存の環境に統合したり、開発チームの速度と俊敏性を向上させる方法を模索したりする場合があります。これは、Well-Architectedな構成の構築や、モニタリング、チームの活動の可視化を通じて実現できるかもしれません。
マネジメントに関して言えば、コスト最適化や効率性の向上が重要です。これらを実現するには、マルチアカウント環境で実行されているリソースを十分に理解する必要があり、そこで私たちのガバナンスサービスが役立ちます。また、AWS Organizationsにおけるガバナンスサービスの規模についても少しお話ししたいと思います。一般的な顧客環境では、数十から数百、場合によっては数千のアカウントを運用しています。しかし、AWS Organizationsは実際には顧客のために数百万のアカウントを管理しており、Identity and Access Managementは世界中で1秒あたり10億以上のAPIコールを処理しています。
この規模を分かりやすく説明すると、主要なWebサイトでも月間数百万のアクセスを処理する程度です。これを比較すると、これらのサービスが提供する規模と効率性がよく分かると思います。
マルチアカウント環境の構築：ビルディングアナロジー
私は頻繁に顧客と、彼らが管理している環境やガバナンスの構築について話をしています。その際、まずは基本的な理解から始める必要があります。つまり、組織構造がどうなっているのか、ガバナンスのベストプラクティスを構築する環境の重要な要素は何かということです。今でも大手顧客や長年AWSを利用している顧客から、「全員が1つの大きなアカウントを使用していて、これを複数のアカウントに分割する方法を考える必要がある」という話を聞くので、これらの基本原則から始めることが重要なのです。
スケーリングの重要な要素は、その構造を構築することです。通常、単一のアカウントではなく、複数のアカウントで構築します。この構造を理解する最も簡単な方法は、環境をビルディングに例えて考えることです。効果的に管理するためには、ビルディングにいくつかの要素を配置する必要があります。ビルディングには通常、目的に応じて異なる部屋があります。設計図や構造があり、部屋をどこに配置し、何に使用するかを把握する必要があります。そして当然、優れたセキュリティシステムを設置して、ビルディング内で何が起きているかを把握し、部屋やビルディング自体へのアクセスパターンを管理したいと考えます。
環境のために作成するこのビルディングの部屋について考えると、AWS アカウントがそれらの部屋に相当します。環境を構築する際は、通常、複数のアカウントを通じて行われます。アカウントを作成することで自然な分離境界が生まれ、ユーザーやアプリケーション、サービスを追加する際に、互いに影響を及ぼし合わない isolated な環境で構築できます。あるアカウントでセキュリティインシデントが発生しても、自然に他のアカウントに影響が及ぶことはありません。単一のアカウントへのアクセスを提供しても、他のアカウントへのアクセスは許可されません。
部屋を適切な場所に配置する際に重要となるのが、Organizational Unitsの活用です。組織内では、アカウントに構造を与えるためのOrganizational Unitsを作成することができます。これらは特定の目的のために構築され、アカウントはそれらのOrganizational Unitsに関連付けられます。Organizational Unitレベルでは、通常、組織内で管理している全アカウントに対してポリシーやコントロールを適用し、環境をカスタマイズします。
SecurityのOrganizational Unit内には、セキュリティチームがセキュリティサービスを管理するためのアカウントが配置されます。Infrastructure のOrganizational Unitには、ネットワークサービスや環境全体で共有されるサービス用のアカウントが配置されます。Sandbox Organizational Unitでは、予算制限を設けつつも、開発者が本番環境に影響を与えることなく新しいソリューションを試せるよう、ポリシーを少なめに設定します。WorkloadsのOrganizational Unitsには、通常、最も多くのアカウントが配置されます。新しいアプリケーションやサービスのために環境が拡大する際には、そこに新しいアカウントを追加していき、開発環境と本番環境を分けるためのサブOUを設けることになります。
AWS Organizationsの活用とベストプラクティス
まだマルチアカウントに移行していない方のために、ベストなアプローチをご紹介しましょう。まず、Workloadsを含むManagement Accountをお持ちの場合、可能な限りそのアカウントでWorkloadsを運用しないことをお勧めします。組織内にアカウントが少数しかなく、Management AccountがAWSで最初に作成したアカウントで、レガシーなWorkloadsがある場合、最も簡単な解決策は、組織外に新しいアカウントを作成し、そのアカウントで組織を作り、既存の全アカウントをメンバーアカウントとしてその組織に移行することです。これにより、Management Accountは管理目的のみに使用され、すべてのユーザー、開発者、Workloadsは別の場所に配置されることになります。
新しいWorkloadsを新しいアカウントで始める習慣がまだない場合は、どこからでも始めることをお勧めします。単一のレガシーアカウント内で追加のアプリケーションやサービスを構築し続けているのであれば、新しいアプリケーションやサービスのために新しいアカウントを作成する習慣を身につけましょう。そのような基盤やパターンを構築することで、あなたとユーザーがその考え方に慣れていくことができます。
新しいアプリケーションを構築する際には、成長のための新しい部屋、新しいスペースが必要です。それは別のアカウント内で行い、独自のスペースを確保できるようにすべきです。そうすることで、新しいアカウントを採用する際に生じるマルチアカウント管理の感覚に慣れていくことができます。繰り返しになりますが、Management Accountのユーザーは制限すべきです。これを実現するためのツール、機能、サービスについては後ほど説明します。
RAMやその他のリソース共有機能をご存知の方は、他のアカウントを入口ポイントとして活用できます。例えば、すべてをホストする大規模なレガシーアカウントがある場合、RAMやその他のリソース共有機能を使用して、そのアカウント内の必要なリソースへのアクセスポイントとして他のアカウントを活用できます。そのため、RAMやその他のリソース共有機能に慣れ親しんでおくことで、大規模なレガシーアカウントに手を加えることなく、複数のアカウントを効果的に活用することが可能になります。
AWS Organizationsの使用に関しては、単一のプロダクション組織を持つことをお勧めしています。これは、実装するガバナンスや可視性のすべてが組織レベルで行われるためです。変更をテストしたり、本番環境の組織で何が起こるかを確認するために、高レベルのポリシーをテストするための別のテスト用組織を持つことはあるでしょう。ただし、様々な理由で複数の組織にまたがって運用する場合、組織自体が強力なセキュリティ境界となるため、ポリシーを効果的に管理したり、セキュリティ上の発見事項を一元的に把握したりする能力が失われてしまいます。
AWSには、組織を認識するように構築されたサービスが多数存在します。今日はそれらの多くについて説明していきます。30や40のサービスすべてを列挙することはしませんが、アカウントとリソースの管理、セキュリティ発見事項の一元化、コストの最適化といったカテゴリーにわたって、多くの異なるサービスが存在します。これらは組織を認識するように構築されており、組織全体でサービスをカスタマイズすることができます。
組織内でサービスを管理する際は、通常、特定のサービスに対して組織の設定を有効にする必要があります。これは管理アカウントで行われ、委任管理者アカウントを登録することをお勧めします。これは組織内のメンバーアカウントで、セキュリティチーム、運用チーム、あるいは特定のサービスを管理する担当者が使用できます。管理アカウントへのアクセス権を持たなくても、組織に関する情報を確認し、管理アカウントに代わってそのサービスを管理することができます。
セキュリティシステムの実装：アクセス管理から予防的コントロールまで
これまでの内容を振り返ってみましょう。アカウントという部屋の構築について話し、設計図である構造とその重要性について説明してきました。ここからは、セキュリティシステムについてより深く掘り下げ、ガバナンス環境にどのように組み込むことができるかについて説明していきます。セキュリティは、AWSにおいて常にトッププライオリティであり、私たちの行うすべての活動の一部となっています。マルチアカウント環境でも同様で、アクセス管理、可視性とモニタリング、そしてコントロールという3つの領域に分類しています。
組織内では、Startupであれ大企業であれ、複数のユーザーや複数のチームが存在し、それぞれのチームやユーザーは、その活動内容や取り扱うWorkloadやデータに応じて、異なる種類の権限を持つことになります。マルチアカウント環境で作業する場合、ユーザーやグループは異なるアカウントへのアクセスが必要になります。また、ユーザーやチームの変更、ユーザーの他チームへの異動、アプリケーションの更新により特定のデータセットへのアクセスが不要になるなど、状況は変化するため、ユーザーやグループに対する権限の適用状況を継続的に監査することが非常に重要です。
これを管理するために、AWS IAM Identity Centerがあります。これにより、1つの中央管理された場所からアカウントやアプリケーションへのアクセスが可能になります。既存のIdentityソースと統合することも可能です。多くのお客様が、Okta、JumpCloud、CyberArkなどをIdentity Centerと統合して使用しているのを見かけます。これは、既存のユーザーやグループがある場合、現在のシステムでそれらを維持できるため便利です。
これらの既存のユーザーやグループはIAM Identity Centerと同期でき、ユーザーがAWSにログインすると、単一のAWSインターフェースを通じて、特定のアカウントにアクセスできます。 Identity Centerを見ると、複数のアカウントを選択して個人やグループに適用することが非常に簡単にできることがわかります。また、独自のCustomer Managed Policyを追加することもできます。 AWSとCustomer Managed Policyを合わせて10個までという制限があります。
これまで、多くのお客様は規制やポリシーにより、アカウントを作成する際にRoot Userに対してMFAを実装する必要がありました。これは新しいアカウントのRoot User認証情報を手動で取得し、MFAを適用する必要があったため、時間のかかる作業でした。しかし、最近Root Access Managementが発表されました。この機能により、IAMから有効化し、マルチアカウント環境全体でRoot Userの状態を確認できます。Root User認証情報が不要な場合は、削除することができます。また、Root User Access Management Consoleには、S3ポリシーやSQSポリシーに対する特権アクションを実行できる追加機能もあります。
先ほど述べたように、Root Access Managementにも委任管理者アカウントを使用することをお勧めします。 メンバーアカウントで特権アクションを実行する場合、S3ポリシー用とSQSポリシー用の2つのアクションがあることがわかります。そこからRoot User認証情報を削除することもできます。これは非常に強力な機能となり、Root User認証情報を取得してMFAを適用する必要があった過去と比べて、時間を節約できるはずです。
アクセス管理の最後のポイントとして、ユーザーやロールの権限を継続的に監査することを推奨しています。これにより、使用されていないパスワードやアクセスキー、ロール、そしてサービスを特定することができます。特に本番環境のアカウントで複数のチームやユーザーが存在する場合、過剰な権限を避けるというベストプラクティスの観点から、これは特に重要です。
可視性とモニタリングについて、次のポイントをご説明します。 ベストプラクティスとして、ログの一元管理を推奨しています。これにより、アプリケーションや他のアカウントなど、様々なソースからのログを集約できるようになり、アカウント内のデータに対する権限の確認も可能になります。これは私たちのお客様の中でも重要な活動として認識されており、特定のデータセットへのアクセス権を持つユーザーを常に確認しています。ログを一元管理することで、組織全体でログの受信方法を標準化し、一貫性を確保でき、適切な保持ポリシーと不変性を確実にすることができます。
AWS CloudTrailについては、AWS Organizationsと併用することを推奨しています。新しいアカウントを作成した際に、CloudTrailが自動的に有効化されるためです。Control Tower環境では、ログは一元管理された集中ログバケットに送られます。実際には2つのオプションがありますが、デフォルトではAWS Organizationsと連携したCloudTrailの使用が推奨され、Control Towerではすべてのログがログアーカイブバケットに一元化されます。
そこから、発見事項の分析を行うことができます。 セキュリティモニタリングツールについては、マルチアカウント環境全体での発見事項、リスク、アセスメントの可視性を確保することが重要です。継続的なモニタリングを支援するツールが必要で、特に重要な2つのツールがAWS Security HubとAWS GuardDutyです。
AWS Security Hubは、クラウドセキュリティポスチャー管理ツールとして考えることができます。すべての発見事項とレポートを一元的なダッシュボードに集約します。特定のセキュリティフレームワークを有効にすることができ、これらのセキュリティフレームワークコントロールはAWSによって管理され、その多くはAWS Configをベースにしています。Security Hubの利点は、CrowdStrikeやAlert Logicなどのサードパーティセキュリティツールを使用している場合、それらの発見事項をこのツールに統合できることです。マルチアカウント環境全体で実装を推奨する2つ目のセキュリティツールは、AWS GuardDutyです。GuardDutyは、CloudTrail、VPC Flow Logs、Route 53 DNSクエリエントリという3つの主要なデータソースからデータを確認します。AWS Organizationsとの統合も優れています。
こちらも Security Hub の画面です。ご覧のように、リソース、アカウント、アプリケーションのダッシュボードが表示されており、検出結果とコントロールの集約ビューを便利に確認することができます。 セキュリティシステム内での可視性について説明しましたが、これは非常に重要な要素です。次は、環境内でコントロールを実装するためにどのようなアクションが取れるのか、ユーザーの行動をどのように制御し、正しい行動を学んでもらうか、そして潜在的な問題をどのように特定して修正するかについて説明していきましょう。
インベントリ管理とコスト最適化：AWS Resource ExplorerとAWS Config
コントロールについて考える際は、これらのコントロールを配置する組織の構造を考慮する必要があります。この例では、複数の Organizational Unit（OU）があり、その中でもワークロードの OU について説明します。これらは、環境をカスタマイズし、承認されたアクションとアクセスポリシーを定義するための広範なルールです。 組織の上位レベルで適用されたコントロールは、その下にネストされたすべての OU に継承されるため、常に広い範囲から始めて、組織の下位レベルに進むにつれて詳細化していくことが重要です。
ワークロード OU レベルで広範なコントロールを設定すると、開発環境でも本番環境でも、すべてのアカウントに影響を与えることができます。そして本番環境内では、ポリシーを変更、調整、追加することで、より具体的なロックダウンプロトコルを実装できます。例えば、バックアップの頻度を指定するバックアップポリシーがあります。組織内では頻繁なバックアップが必要ない場合でも、データが常に変更される本番環境では、より頻繁なバックアップが必要になる可能性があります。
組織ポリシーには大きく2つのタイプがあり、この1ヶ月以内にリリースされた2つの新しいポリシーについても説明します。まず、認可ポリシーがあります。IAM（Identity and Access Management）をご存知の方は、長年使用されている Service Control Policy（SCP）と、最近導入された Resource Control Policy（RCP）がこれに含まれます。 次に、組織内のサービスの動作を規定する管理ポリシーがあります。先ほど例として挙げたバックアップポリシーの他に、タグポリシー、AI オプトアウトポリシー、そして10月に新しくリリースされた Slack などのチャットアプリケーションでアカウントを管理するためのチャットボットポリシーがあります。さらに、EC2 サービスの設定を大規模に管理するための宣言的ポリシーもあります。
次に説明するコントロールのタイプは、検出的コントロールです。AWS Config をご存知の方は、これを使用して組織、アカウント、環境内のリソースを特定できることをご存知でしょう。特定のリソース設定がルールに違反した場合にアラートを発する特定のルールを設定できます。パブリックアクセスに関するルールは非常に一般的です。これらのルールは定期的に、または操作が実行されるたびに実行され、リソース設定が正確であることを確認します。
問題を検出すると、自動修復を設定して特定の問題を自動的に解決することができます。 AWS Configのルールがトリガーされ、AWS Systems Managerを使用して特定の設定を修正するための自動化を構築できます。 この例では、自動化を実行した後、EC2インスタンスにパブリックIPの関連付けがなくなります。
Configルールについて説明すると、お客様からよく「それは素晴らしいけれど、そもそもそのような動作を最初から防ぐことはできないのか」という質問を受けます。変更を促して対応を促すルールは必要なく、そのようなアクションが最初からプロダクション環境に入り込まないようにしたいと考えているのです。 ここで重要になってくるのが、特定のサービスで常に設定を維持するための宣言的ポリシー（Declarative Policies）です。 組織全体にポリシーを適用できるのと同様に、特定のカスタム宣言的ポリシーを作成して組織全体に適用することができます。
具体的な例を見てみましょう。組織内でスナップショットのパブリック共有をブロックしたい場合、最初からそれを作成できないようにする宣言的ポリシーを作成できます。EC2では、EBSスナップショットのすべてのパブリック共有をブロックする設定を作成できます。 これを組織単位（Organizational Units）に適用すると、その配下のすべてのアカウントでそれらの設定を持つインスタンスを作成することができなくなります。 これらは、宣言的ポリシーのローンチ時にサポートされているアクションです。このリストは時間とともに拡大していきますが、環境内でテストする必要があるものです。その多くは、リソースやサービスの設定に関して、開発者や組織で一般的に見られるユースケースです。
Service Control Policies（SCPs）をご存知の方も多いと思います。SCPsは長年存在し、特定の環境内でユーザーが使用できるアクションやAPIを具体的に規定します。組織全体に適用し、アカウントレベルまで細かく調整することができます。この例では、S3バケットのパブリックアクセス設定を変更する機能をブロックしています。 AWS Control Towerでは、これらは予防的ガードレール（Preventative Guardrails）と呼ばれています。
ここでリソースのパーミッション側について話したいと思います。AWSからはSCPのアクセスパターンに関する推奨事項について広範な文献やガイダンスが提供されていますが、ここではリソースに焦点を当てましょう。これはIAMのもう一つの側面で、作成されたリソースに対して適切な人だけがアクセスできるようにすることが重要です。これまでは、開発者が適切なリソースパーミッションを使用することを意図して、作成されるバケットのリソースポリシーに特定のコード行を必要とするようにしてきました。
現代では、Resource Control Policiesがより良い方法を提供しています。SCPsがAPIやユーザーが実行できるアクションの権限を具体的に規定するのに対し、Resource Control Policiesは環境内のリソースポリシーに対して機能します。これらのResource Control Policiesは、Organization レベルまたはOrganizational Unit レベルで設定され、ユーザーが作成したリソースポリシーのアクセス設定に関係なく、それらを上書きして組織全体のコントロールとして機能することを保証します。 これは他のセッションでより詳しく掘り下げられる分野であり、ぜひご覧いただくことをお勧めします。 リリース時点でRCPsをサポートするサービスについて把握しておくことが重要です。このリストは時間とともに拡大していくでしょう。
すべてのポリシーを整理すると次のようになります：Service Control Policiesはアクションを実行しようとするプリンシパルまたはユーザーに対して適用され、Resource Control Policiesは大規模にリソースへの一貫したアクセス制御を作成し、Declarative Policiesは組織内で大規模にカスタマイズして設定できるサービス構成です。 AWS Control Towerを使用している場合は理想的です。なぜなら、これらのガードレールが組み込まれており、これらの新しいコントロールをその場で適用できるからです。過去1、2ヶ月の間に、これらの新しいポリシータイプに基づいて、Control Towerに数多くの新しいコントロールが追加されています。
Workdayのガバナンスジャーニー：2019年から現在まで
Control Towerを使用していない場合でも、どのようなコントロールが使用されているかを説明するドキュメントを通じて、そのガイダンスを参考にすることができ、独自の環境内でそれらのコントロールを再作成することができます。AWS Control Towerとそのドキュメントを確認し、どのような例があるか、そしてそれらを自分の環境に適用できるかどうかを検討することをお勧めします。ここで、いくつかの異なる点をまとめましょう。マルチアカウント、セキュリティについて説明してきましたが、次はインベントリ管理について説明します。これは、マルチアカウント環境内で実行しているリソースを理解することに関するものです。
お客様からよく聞かれる質問として、「約6ヶ月前か8ヶ月前にインスタンスを起動したのですが、どのリージョンにあるか覚えていません」というものがあります。時には、コンプライアンスや監査の要請が発生することもあります。セキュリティチームは、数ヶ月前にインスタンスから奇妙なリクエストがあったためIPアドレスを追跡する必要があり、それがいつ、なぜ発生したのかを理解する必要があることがよくあります。また、 リソースにタグが付いているかどうかを理解することも重要で、これは環境内に多数のアカウントがあり、それらのアカウントが増え続けると非常に複雑になります。
もう一つの課題は、お客様がアプリケーション内のリソース間の関係を理解することに非常に関心を持っているということです。例えば、VPCセキュリティグループなどのネットワークリソースに接続する必要がある2つのインスタンスがあり、そのアプリケーションにどのようなセキュリティコントロールが適用されているかを理解する必要があります。問題は、これを集約的な視点からどのように行うかということです。 これを支援する2つのサービスが、AWS Resource ExplorerとAWS Configです。Andrewが AWS Configについて話したのを覚えているかもしれませんが、彼はルールの観点から話しました。この場合、実際にはConfigをインベントリ管理に使用します。Amazon Resource Explorerは非常に良い最初のステップで、アカウントやリージョン全体のリソースを簡素化したダッシュボードで提供します。タグ付けされたリソースやタグなしのリソースを理解したり、特定のリソースのARNを検索したりするのに使用できます。Configはさらに一歩進んで、リソースの設定の詳細を提供し、リソースの関係を示し、詳細な設定履歴を保存することで、強力なコンプライアンスツールとなっています。
お客様からよく、環境全体のリソースとその設定のリストを取得する方法について質問を受けます。AWS Configでは、設定のポイントインタイムキャプチャを取得してS3バケットに送信できるAPIをサポートしています。AWS Configの注目すべき点として、Config データに対してクエリを実行できることが挙げられます。自然言語でのクエリをサポートしていますが、より高度な処理が必要な場合は、PythonやAPI機能を使用してSQLの結合クエリを実行することができます。 こちらはResource Explorerの画面で、様々なクエリテンプレートが用意されています。タグ付けされていないリソースや、アプリケーションオブジェクトに含まれていないリソースを一覧表示することができます。
AWS Configではダッシュボードと適切なモニタリング機能を提供しており、環境全体における準拠リソースと非準拠リソースの概要情報を確認できます。必要に応じてConfig Aggregatorを使用することもできます。では次に、コスト管理について説明しましょう。これが最後のトピックとなり、その後、Colmが自身の環境でのガバナンス管理についてお話しする予定です。 アカウントを追加し、セキュリティプロトコルを導入し、アクセス管理を確実に行っている環境が拡大していく中で、次に考慮すべき課題となるのが、成長する環境のコスト管理です。私たちは多くのお客様とこの話題について話し合っており、コスト管理を試みるお客様にとって役立つ3つの重要な原則があると考えています：コストの可視性を確保すること、コストの増減の理由を把握し、その詳細情報をすぐに確認できるようにすること、そしてチームにもその可視性を提供し、コストに対する責任を持たせ、効率化できる部分を特定するためのコストレポートを生成することです。
可視性が確保できれば、既存のコストを最適化することができます。環境全体でコストを最適化したい領域を特定したり、チームに最適化を促したりすることができます。さらに、これまで説明してきたコントロールを活用して、高コストのアクションが環境内で実行されないようにする予防的なメカニズムを作成したり、監査やレビューを行う特定の部分でのみ実行されるようにしたりすることもできます。
Cost and Usage ReportとAmazon QuickSightを使用した自動インサイト付きのコストダッシュボードの作成が、 重要なツールとなります。チームに必要なコストレポートを作成するにはカスタマイズが必要になりますが、これらのツールを活用してレポートを作成し、チームが自分たちのコストを把握し、最適化にも貢献できるようにすることができます。
組織全体で機能し、コスト最適化を支援する3つの特定のサービスがあります。 コンピューティング向けのAWS Compute Optimizer、ストレージ向けのAmazon S3 Storage Lens、そして一般的なコスト最適化要件向けのAWS Cost Optimization Hubです。こちらはCompute Optimizerでの表示例です。 組織内の多くのアカウントでリソースを使用している場合、オーバープロビジョニングやアンダープロビジョニングされているインスタンスがあるかもしれません。これにより、コストとコンピューティングインスタンスの使用率を改善するために、どこに時間を費やすべきかのガイダンスを得ることができます。
Amazon S3 Storage Lensを使用している場合、このようなツールの画面が表示されます。組織全体で使用されているS3リソースを確認することができ、ストレージが効果的に活用されていない場所で、異なるストレージタイプに移行することでコスト最適化の機会を見つけるヒントを得ることができます。Cost Optimization Hubでは、Compute OptimizerとS3 Storage Lensからの分析結果を取り込み、Reserved Instanceの共有や作成、集約、あるいは利用可能なサービスについての追加のインサイトやレコメンデーションを提供します。
AWS Control Towerの導入とWorkdayの成長
ここでColmに話を譲りたいと思います。皆さん、聞こえていますでしょうか？改めて自己紹介させていただきます。私はColm Usherと申します。Workdayのパブリッククラウドセキュリティチームを率いています。少し背景をご説明しますと、Workdayは財務管理、人事、分析のためのクラウドベースのエンタープライズアプリケーションを提供する主要企業です。これから15分ほどかけて、数年前のWorkdayのインフラ環境から、現在の状況に至るまでの道のりをご紹介したいと思います。
2019年当時、Workdayは単一のAWS Organizationを持っていました。私たちはTierによって分類された組織単位（Organizational Unit）を持っており、Tierは開発環境なのか、本番環境なのか、非本番環境なのかといった、その環境で実行されているワークロードのタイプを判断する基準となっていました。アカウントが優れた境界として機能すると考えているため、私たちはマルチアカウントモデルを採用しています。基本的に、サービスは個別に設定されていました。これは2019年の状況で、AWS CloudTrailとAWS Configは、Organizations対応以前からあったため、アカウントのプロビジョニング時に設定されていました。この時点で、約175のメンバーアカウントを運用していました。
その後2021年までの2年間で、全体的なセキュリティ態勢を改善するためにネイティブサービスを追加し始めました。まずService Control Policiesから始めました。私たちは、拒否するもの以外はすべて許可するという実施モデルを採用し、チームに大規模な影響を与えそうにないポリシーから小規模に始めました。これには、CloudTrailの無効化の防止、AWS Configの変更の防止、アカウントがOrganizationから離脱することの防止、そしてコアとなるセキュリティロールとポリシーの保護が含まれていました。
2021年のLog4jの件のように、時には変更を強いられることもあります。私たちは素早く適応する必要があったため、Amazon GuardDutyとIAM Access Analyzerのイベントログ収集を一元化し、AWS Security Hubにパイプで送信し始めました。これにより、セキュリティ情報イベント管理システムに検出結果をストリーミングするための中央集約ポイントが得られました。また、AWS Organizationsをより具体的に活用し始め、特にDelegated Administratorを使用することで、支払いアカウントの外部でサービス管理を行う機能を得ました。この時点でも私たちは単一のOrganizationを持ち、Tier分類でグループ化されたメンバーアカウントを持っていましたが、セキュリティサービスを拡張していました。
それでは、私たちが実際に使用している Security Hub の構成についてご説明します。まず、中央のセキュリティ監視アカウントに対して Delegated Administrator を設定します 。 次に、GuardDuty、AWS Firewall Manager、Amazon Inspector、IAM など、ネイティブのサービス統合を Security Hub に設定し、 これらの結果を単一のリージョンに集約します。その後、Amazon EventBridge と Amazon Kinesis Data Firehose（以前の KIS）の活用を開始しました。
私たちは結果を集約するための単一リージョンを確立し、Amazon EventBridge と Data Firehose（以前の KIS）を活用して、 セキュリティ情報イベント管理システムへのストリームを実現しました。この時点で、メンバーアカウント数は300に達し、計算すると2年間で125アカウント増加したことになります 。
企業が成熟するにつれて、リスク許容度が変化し、より厳格な変更管理手順が発展していきます 。本番環境の組織で何らかの変更を慎重にテストするためには、その変更がすでにレプリカ組織でテストされていることが望ましいと私たちは認識しました。そこで、本番環境のAWS Organizationごとに、全く同じ構成のレプリカを維持することを決定しました。これは、 Service Control Policies、GuardDuty、Security Hub、AWS Shield Advanced保護プラン、AWS CloudFormationスタックセット、あるいは通常は組織レベルで適用されるものすべての変更が、まずレプリカ組織を通過する必要があることを意味します。本番環境のOrganization内に開発環境があったとしても、それは依然として本番サービスへの変更となります。
また、Service Control Policiesの数も増やし始め、請求の変更を防止し、rootアクセスの代替認証方法を保護し、Terraformバックエンドを保護し、rootユーザーアクセスを拒否し、それらのAPIエンドポイントを保護するようになりました 。変更はまずレプリカ組織で実装され、そこで標準的な機能テストが行われます 。その後、本番環境に移行されますが、本番環境に移行するということは、本番のOrganization内の開発ティアに移行するということです。その変更が開発ティアに入ると、 同じ機能テストのプロセスを経て、より上位の分類ティアへと段階的に進んでいきます 。
これで昨年の時点に到達し、メンバーアカウント数は470に達しました 。その時、特定のチームが必要に応じて動的にAWSアカウントを作成できるようにするというビジネスニーズが発生しました。複数のアカウントを事前にプロビジョニングしておいても、このユースケースは満たせませんでした。既存のアカウント作成プロセスは非常によく定義されていましたが、アカウントのプロビジョニングが完了し、財務とセキュリティの承認を得るまでに数日から数週間かかる、比較的遅いプロセスでした。インフラストラクチャー、セキュリティ、財務、開発の各チーム間で、それぞれのリスクと要件を満たすソリューションを設計する必要がありました 。
AWS Solutions Architectsと直接協力する中で、最初の要件として、これは独自のOrganizationに分離する方が良いということが分かりました。既存のプロダクション環境のOrganizationから、Service Control PoliciesやGuardDutyなどの優れた機能を取り入れたいと考えていました。CloudTrailやConfigについては、既存のOrganizationへの統合が難しい新しいサービスの活用も検討していました。そこで、環境を確実に分離するための境界として、専用のAWS Organizationから始めることにしました。
AWS Control Towerで環境を管理することで、Landing Zoneのセットアップ、マルチアカウントのベストプラクティス、そして集中的なアイデンティティとアクセス管理を実現しました。また、集中ログ管理とセキュリティ監査のための専用の管理アカウントも設定されました。Account Factoryを活用し、AWS CloudFormation を使用してメンバーアカウントにセキュアなベースラインを展開しました。複数のアカウントにわたるアクセス権限の一元管理が必要だと分かっていたので、AWS IAM Identity Centerを通じてこれを実現し、一貫したセキュリティポリシーの適用を容易にし、管理の手間を削減しました。これが完了した後、最初に行ったのは、本番環境のOrganizationを反映したレプリカ組織を作成し、同じライフサイクルで変更を管理できるようにすることでした。
現在では約800アカウントを抱え、2025年には1000アカウントを超える見込みです。ここで、私のチームと私が経験から学んだ実践的なヒントをいくつか共有したいと思います。セキュリティ面とコスト面の両方についてです。まずAWS CloudTrailについて、集中管理されたセキュリティトレイルを利用している場合、そのリージョンでの管理イベントの最初のコピーは無料で提供されます。同じ管理イベントに対して追加のトレイルを作成すると、CloudTrailのコストが発生します。
実践的なヒントとベストプラクティス：セキュリティからコスト管理まで
Amazon S3の読み取りと書き込みイベントについて、GetObject、DeleteObject、PutObject APIコールに注意を払うことをお勧めします。過去の経験から、S3を頻繁に利用するチームでは、CloudTrailの支出が大きくなる可能性があることが分かっています。また、カスタマー管理の暗号化キーを使用した暗号化についても、CloudTrailを使用する際は重要な考慮事項があります。
中央のS3バケットでCloudTrailログを使用する場合、メンバーアカウントはローカルで90日間のアクティビティにしかアクセスできません。チームがそれ以上の期間のCloudTrailイベントにアクセスする必要がある場合、特にCloudTrailイベントに基づいてIAMポリシーを生成する場合は、クロスアカウントアクセスのためにKMSリソースポリシーを変更できるカスタマー管理の暗号化キーを使用する方が良いでしょう。
AWS Configについて、もしまだご利用になっていない方は、AggregatorとAdvanced Queriesは素晴らしいサービスです。以前はLambdaを使って各アカウントからリソースを取得する必要があり、タイムアウトに悩まされていましたが、このサービスを使えば組織全体のリソースを数秒で検索できます。いくつか制限事項がありますが、Advanced Queryセクションに入ると、上部に制限事項が詳しく記載されたURL があります。コストに関して、Config Recorderを使用している場合、AggregatorとAdvanced Queriesは追加コストが発生しません。
AWS Organizationsについて、商用とガバメントの組織が混在している場合や、その予定がある場合は、 サービスの境界管理が容易になるため、別々の組織を検討することを強くお勧めします。ただし、Replica Organizationを作成する場合、その組織で運用されているリソースに対してEnterprise Discount ProgramやSavings Plansの恩恵を受けられない可能性があることにご注意ください。また、Delegated Adminアカウントには強力な管理を忘れずに設定してください。
Service Control Policies（SCPs）に関して、SCPドキュメントの最大サイズは5,000文字強です。類似のブロックをグループ化するか、別々のポリシーを作成することを検討できます。AWS Full Accessポリシーを削除する際は注意が必要です。これは組織単位内で継承され直接適用されているように見えますが、削除すると、許可したもの以外すべてを拒否する動作モードに切り替わります。SCPが適用されている場所でのアクセス拒否APIイベントをモニタリングすることをお勧めします。これはアカウントが侵害された可能性や、単に自動化の設定ミスを示している可能性があります。
AWS Security Hubについては、Delegated Administratorと クロスリージョン集約を設定し、GuardDutyやFirewall Managerなどのサービスからの統合を構成することで、すべての検出結果を1つのパイプラインにまとめることができます。 Security Hubには、事前定義された対応で自動的にセキュリティ脅威に対処する機能がありますが、これを採用し始めると、サービスチームがTerraformでインフラストラクチャを管理している場合に設定のずれが生じる可能性があります。
非常に優れたスケーリング機能として、新しいリージョンの自動有効化と新しいアカウントの自動有効化があります。GuardDutyのランタイムモニタリングについて、 これは優れた保護を提供しますが、Security Hubと同様に、メンバーアカウントが状態を管理している場合、VPCエンドポイントとトラックリストを作成するため、設定のずれが生じる可能性があります。GuardDutyは、アカウントごと、リージョンごとに最大6つの外部サードパーティソースからの脅威リストで補完できます。
Amazon S3に関して、Storage Lens機能は、S3全体の可視性を組織全体に提供し、暗号化の使用状況やストレージの使用状況を示してくれます。私たちの調査では、最も高価な階層であるにもかかわらず、チームが好んで使用する傾向にある標準階層が圧倒的に高い割合を占めていることが分かりました。S3のアカウントレベルのブロッキングは非常に優れた機能で、もしこれを使用する場合は、特定のプリンシパルのみが変更を加えられるようSCPで保護することをお勧めします。サーバーアクセスログについては、コンプライアンスの観点から重要ですが、サーバーアクセスログを有効にする場合は、無限ループのログが発生してしまうため、送信先バケットでは有効にしないようにしてください。
Control Towerに関しては、すべての変更はControl Towerを通して行う必要があることを覚えておいてください。そうしないと、Landing Zoneがドリフトを検出し、修復されるまで機能しなくなります。Landing Zoneの計画については、アカウントやOrganizational Unitsの構造と組織を十分に検討せずにセットアッププロセスを急いではいけません。Control Towerには多くの事前構築されたガードレールがあるので、それぞれについて組織内での影響を慎重に検討してください。次にAWS IAMとRoot管理についてですが、AndrewさんかNivasさんがRoot管理に関する最近の新機能について説明したと思います。これは認証の代替手段を保護することに関する別の領域です。Rootの認証情報を失ってパスワードのリセットが必要になった場合、基本的にはアカウントのメールアドレスへのアクセスと、電話番号の変更や通話を受けることができる能力に依存します。
このSCPは、アカウントの電話番号を変更できる人を制限します。
アカウントの帰属関係を把握し、正確なデータベースインベントリを維持することは非常に重要です。これには、アカウントの管理者、支出の承認者、アラートの送信先などの追跡が含まれます。目標は、アカウントのプロビジョニングとオフボーディング時にそのデータベースを動的に更新することです。AWS Organizations自体のアカウントレベルでタグを活用することができます。
最後に、よりセキュリティに焦点を当てたトピックとして、Confused Deputy Attackについてお話しします。多くの人が経験したことはないかもしれませんが、もし経験がない場合、これはアイデンティティベースのポリシーとリソースベースのポリシーの両方に影響を与える可能性のある脆弱性で、クロスアカウントやクロスサービスのロールで最も一般的に発生します。以上で私の発表を終わります。ありがとうございました。
これまでのヒントやアドバイスについて、とても参考になりましたね。では、本日お話しした内容をまとめて締めくくりたいと思います。組織構造の強化は、マルチアカウント環境の構築から始まります。アカウント、ポリシー、共通のポリシーグループについて検討し、AWS CloudTrail、AWS GuardDuty、AWS Security Hubなどの統合サービスを活用し、各種コントロールを導入していきましょう。新しいRCP（Resource Control Policies）や宣言的なポリシー、予防的コントロール、そしてAWS Configを使用した検知的コントロールについても考慮してください。また、Resource ExplorerやAWS Configなどのツールを使用して、マルチアカウント環境全体のリソースを確認することができます。そして本日は、WorkdayのガバナンスジャーニーについてColmさんにお話しいただき、大変貴重なお時間となりました。皆様、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion