re:Invent 2024: AWSのクラウドガバナンス実装 - Control Tower活用と多層的コントロール
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Dive deep on AWS cloud governance (COP402)
この動画では、AWS環境におけるCloud Governanceの重要性と実装方法について解説しています。AWS Control TowerやAWS Organizationsを活用したマルチアカウント戦略の構築方法や、Service Control Policies、Resource Control Policiesなどの予防的コントロール、AWS CloudFormation Guardsによる事前対策的コントロール、AWS Configによる検知的コントロールの実装方法を詳しく説明しています。また、AWS CloudTrailを用いた監査証跡の管理や、最近リリースされたCloudTrail Lakeの拡張イベントフィルタリング機能、事前構築された14のダッシュボードなど、監査のための具体的なツールと手法についても紹介しています。AWS環境でのガバナンス実装に必要な要素を包括的に網羅した内容となっています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Cloud Governanceの重要性と本セッションの概要
ここはCOP 402、Cloud Governanceについてのセッションです。ご参加いただき、ありがとうございます。セッション終了時にはアンケートへのご協力をお願いいたします。それでは、あるシナリオからお話を始めましょう。CFOから電話があり、ここ数ヶ月でコストが急騰しているが、その理由が誰にもわからないと言われたとします。さらに、セキュリティチームからは、暗号化されていないS3 Bucketによって機密データが露出してしまったという連絡も入ります。このような状況は皆さんにも心当たりがあるのではないでしょうか。残念ながら、これはCloud戦略にガバナンスを組み込んでいない多くの組織で起きている現実です。
今日のダイナミックな環境では、何を構築できるかということだけでなく、AWSを選択した理由であるアジリティを失うことなく、いかにそれらの環境を管理していくかが重要になってきています。このセッションを通じて、コンプライアンスを自動化し、環境のセキュリティを確保し、AWS リソースを適切に管理するためのツールとプロセスについて理解を深めていただけます。最後にCloudについての詳細な説明もご覧いただきます。私はPrincipal WW CloudOps SAのRodolfo Brenesです。本日は、Senior WW CloudOps SAのMatheus Arraisと共同で発表させていただきます。
Cloud Governanceの定義と主要課題
さて、Cloud Governanceとは何でしょうか？これは誰に聞くかによって異なる答えが返ってくるでしょう。セキュリティだと考える人もいれば、コスト管理や運用面だと考える人もいます。 しかし結局のところ、Cloud Governanceとは、AWSの利用をビジネス目標に合わせるためのルールとプロセスのフレームワークなのです。これは単なる静的なルールの集まりではなく、クラウドリソースを効果的かつ安全に管理するための戦略的なアプローチです。
では、お客様が最も重視している、あるいは初期段階で直面する課題について見ていきましょう。1つ目はスケーラビリティです。AWSインフラストラクチャの成長に合わせて、ガバナンスポリシーと実践をどのように確実に拡大していくか、そしてコストとリソースをスケールに応じてどのように効率的に管理していくかということです。2つ目はセキュリティです。組織の機密データとインフラストラクチャをどのように保護し、AWS環境で業界規制にどのように準拠していくかということです。3つ目は自動化と統合です。人的エラーを減らしながら、どのようにしてそれらのコントロールをスケールさせて実施していくか、また必要に応じてアラートや是正措置をどのように実装していくかということです。
これらすべてを考慮に入れると、まずはビジネス目標とAWSリソースのマッピングから始める必要があります。技術的な観点から最初に推奨するのは、アカウント戦略の策定です。これにより、マルチアカウントのセットアップを実装し、ワークロードの分離、制限の管理、アクセス管理の分離、請求の最適化を効果的に行うことができます。また、組織全体で一貫したポリシーを有効にすることも可能です。2つ目はコントロールです。セキュアで効率的な運用を維持するためのガードレールとガバナンスのプラクティスをどのように確立するか、コンプライアンスの要件とセキュリティ基準にどのように従うか、そして強力なアイデンティティ管理をどのように実現するかということです。3つ目は監査です。すべてのコントロールが適切に適用されていることをどのように保証し、必要に応じて自動的に是正措置を講じるか、フォレンジック調査をサポートし、ほぼリアルタイムのモニタリングをどのように実現するかということです。
AWS Organizationsを活用したアカウント戦略
それでは、アカウント戦略について説明していきましょう。まず取り上げたいのが、AWS Organizations の統合機能です。これは非常に重要な機能で、特定のAWSアカウントで既に活用している主要機能を、スケールメリットを活かして展開できるようになります。ここでは、Organizations が提供する4つの統合の柱について見ていきます。例えば、お客様が単一のアカウントで特定のセキュリティ基準に従ってセキュリティチェックを行うために AWS Security Hub を使用している場合、AWS Organizations の統合機能を使えば、一元的な管理パネルで運用できるようになります。これは一例です。
では、一般的なシナリオがどのように展開されるか、順を追って見ていきましょう。まず、スタンドアロンのアカウントを持つユーザーがいるとします。リソースのデプロイを始め、順調にビジネス目標を達成していきます。そして、コスト管理の実装を決定します。そこで Cost Optimization Hub を見つけます。これは、Savings Plans や Reserved Instances、より費用対効果の高い新世代のコンピューティングオプションなど、最適化に関する推奨事項を提供するサービスです。
推奨事項に従ってコストを削減し、効率化に成功します。最適化を進めるにつれて、AWS の利用規模は拡大していきます。今や同じエンドユーザーが3つのアカウントを持つようになり、Cost Optimization Hub の推奨事項にアクセスするために、それぞれのアカウントで異なるロールを引き受ける必要があります。そして、その価値を実感し続けています。しかし、規模が拡大するにつれて、これが3アカウント、6アカウント、9アカウント、数百アカウント、さらには数千アカウントにまで増える可能性があり、管理はますます複雑になっていきます。
複数のアカウントへのログインが必要な状況は変わりませんが、これは現実的ではなくなってきます。ここで AWS Organizations が規模拡大をサポートします。これらの統合機能を活用することで、同じ機能を利用しながら、管理アカウントから組織全体を一元的に把握できるようになります。ベストプラクティスに従えば、委任管理者アカウントを活用することで、エンドユーザーに管理アカウントへのアクセス権を与える必要がなくなります。これにより、職務の分離が確保され、権限が適切に管理され、委任管理者アカウントを通じてコスト管理のためのアカウントにログインできるようになります。
このような流れがアカウント戦略の進化を示しています。アカウント戦略は、一度設定して終わりではなく、継続的な取り組みであることを理解することが重要です。推奨事項やベストプラクティス、組織単位の設計パターンを含むホワイトペーパーをぜひご確認ください。このホワイトペーパーは絶対的なものではありません。各お客様や企業には独自の設計があるからです。しかし、長年にわたって AWS Organizations を効果的に活用してきた成功事例からの推奨事項が含まれています。
基本的なOU（Organization Unit）構造には、ログ記録、監査、バックアップアカウント用のセキュリティOUが含まれています。インフラストラクチャOUには、ネットワークとIdentity管理用のアカウントが含まれています。また、AWSが日々リリースする新機能をテストするためのSandbox OUもあり、これによってスコープを制限し、オンプレミスシステムとの接続を制限することができます。アプリケーションについては、Service Control Policies（SCPs）やResource Control Policies（RCPs）などのAWS Organizationsのサービスを活用するため、非本番環境と本番環境のOUを持つ親ワークロードOUを設けることをお勧めします。この親子構造により、ポリシーを下位のすべてのOrganization Unitに継承させることができます。
進化が続くにつれて、suspended OUやtransitional OUを追加することもあるでしょう。suspended OUは、クローズを予定しているアカウントの管理に重要です。AWSアカウントは90日後にしかクローズされないためです。アカウントをsuspended OUに配置することで、誰もそれを再開できないようにし、適切なセキュリティ境界を維持することができます。また、transitional OUを実装して、セキュリティ境界を確保し、アカウントの再開を防ぐこともできます。
transitional OUは、特に企業買収の際に役立ちます。Organization間でアカウントを移行する際、最終的にアカウントがどこに配置されるか確定していない場合に使用します。これにより、まずデフォルト設定で安全な境界を確立し、その後で移行を処理することができ、M&Aの際に特に有用です。
規模が拡大してアカウントが増えるにつれて、追加のOUが必要になる場合があります。セキュリティ基準を下げる必要があるアカウントには、exceptional OUを慎重に使用できます。これらの例外は一時的なものであるべきで、限られた数のアカウントと定められた期間を伴うものです。ネイティブなテスト機能を持たない強力なService Control Policies（SCPs）をテストするために、policy staging OUをお勧めします。これにより、ポリシーを対象のOUに適用する前にテストを行い、設定ミスによる潜在的な混乱を防ぐことができます。Business continuity OUは災害復旧に役立ち、災害復旧業務を担当する担当者のみにIAMロールが割り当てられるようにします。
AWS Control TowerとCloudFormation Hooksによる予防的コントロール
このインフラストラクチャを構築するための推奨サービスは、AWS Control Towerです。このマネージドサービスは、ベストプラクティスに従ってマルチアカウントのセットアップを支援し、Landing Zoneをデプロイします。AWS Organizations、Identity Center、AWS Configを含む14以上の基盤サービスと統合されています。セキュリティOU配下にCloudTrailとConfigログを一元管理するためのS3バケットを持つログアーカイブアカウントと、すべてのアカウントでConfigを有効にした監査アカウントをデプロイします。すでにマルチアカウント戦略を実装している場合でも、コントロールを一元管理するためにAWS Control Towerの導入をお勧めします。
Account Factoryを使用してアカウントを作成することができ、このプロセスを通じて作成されたすべてのアカウントは、デプロイされた標準、アカウントベースライン、およびコントロールを自動的に継承します。AWS Control Towerは現在、Organization Unit レベルでデプロイできる500以上のマネージドコントロールを提供しています。最近では、AWS Backupとの統合を発表し、バックアップ用の中央バックアップアカウントと、AWS Backupポリシーと監査マネージャーを監督するバックアップ管理者アカウントが作成されるようになりました。
AWS Control Towerが完全にニーズを満たさず、効率的なアカウント提供を確実にしたい場合は、ライフサイクルイベントの使用を検討してください。 管理アカウントでAWS Control Towerを通じてベストプラクティスを全てデプロイしたアカウントを作成する際、 Amazon EventBridgeを使用してそのイベントをキャプチャすることができます。これにより、Lambda関数やCloudFormation StackSets をトリガーして、新しく提供されたアカウントにIAMロールなどのアカウントカスタマイズを実装することができます。
このアプローチを使用することで、VPC Flow Logsのようなカスタマイズをロールアウトしたり、この新しく提供されたアカウントで直接AWS Lambdaをトリガーしたりすることができます。これには、Amazon GuardDutyの有効化、AWS Security Hubが 全体で有効になっていることの確認、そしてRodolfoが先ほど言及した委任アカウントへの承認送信が含まれます。これはライフサイクルイベントを使用して全体的に活用できるものです。新しく提供されるすべてのアカウントに、セキュリティとガバナンスのニーズに関する同じ標準的なブループリントを持たせることができます。
AWS Security Reference Architecture（AWS SRA）をご確認いただくことをお勧めします。 これは、私たちが持っているセキュリティサービス統合のための規範的なガイダンスです。AWS Control Towerと統合されており、そのテンプレートをデプロイして、これまで説明したすべてのサービスのログ記録などをSRAで有効にすることが非常に簡単になっています。
アカウント戦略について説明したところで、次はコントロールについて説明しましょう。 Rodolfoが述べたように、コントロールはガバナンスの重要な要素です。すべては、特定の規制 状況に関する企業や顧客の期待を述べたドキュメントであるポリシーから始まります。次に、そのポリシーに向けた目標となるコントロール目標があります。その次に、 PCIコンプライアンスのようなコンプライアンス要件を確実にするための標準があります。これらはコントロール目標のための正式な要件です。 最後に重要なのはセキュリティコントロール自体で、ここで標準を実装するメカニズムを持ちます。コントロールは標準にマッピングされ、次に目標に、最後にポリシーの意図にマッピングされます。これがガバナンス全体のピラミッドです。
Resource Control PoliciesとDeclarative Policiesの実装
AWSには、Preventive（予防的）、Proactive（事前対策的）、Detective（検知的）の3種類のコントロールを実装することができます。まず、Preventiveコントロールから見ていきましょう。Preventiveコントロールは、イベントが発生する前にそれを防ぐように設計されたセキュリティコントロールです。これは、ネットワークへの不正アクセスを防ぐための第一防衛線として広く知られているコントロールです。AWS Organizationsでは、具体的にはService Control Policies（SCPs）という認可ポリシーを通じてこれを実現します。最新情報をお伝えしますと、数週間前にResource Control Policies（RCPs）をリリースしました。これらのポリシーとコントロールは権限を付与するものではなく、アイデンティティやリソースに対する最大権限を設定するものです。
では、この最近のローンチ以前のRCPsの仕組みを見てみましょう。RCPsは実は全く新しいものではありません。皆さんは恐らく日々リソースポリシーを実装されているはずです。例えば、S3バケットポリシー、SQSポリシー、KMSポリシーなど、これらはすべてリソースポリシーです。RCPsは、このコントロールを一段上のレベルに引き上げる機能を提供します。RCPs導入以前は、組織外の誰かやAWSサービス以外のプリンシパルに対するアクションを拒否するバケットポリシーを実装したい場合、すべてのリージョンとアカウントの各S3バケットポリシーでこれを実装する必要がありました。しかし今ではRCPsにより、同じポリシーをより上位のレベルで適用できます。これは、S3バケットを含むすべてのアカウントとリージョンに影響を与え、組織レベルで適用された場合のSCPと同様に機能します。
この場合、組織レベルのResource Control Policyがすべてのアカウントで必須となります。たとえS3バケットポリシーを変更する権限を持つ管理者であっても、上位レベルの権限がアクセスを拒否するため、外部の脅威アクターは3つのバケットのいずれにもアクセスできなくなります。
Service Control Policies（SCPs）とResource Control Policies（RCPs）がどのように連携するのか、まだ十分に理解できていない方もいらっしゃるかもしれません。まず、SCPsとRCPsは独立したコントロールですが、連携して機能することができます。これらは、ルートレベルの組織、Organizational Unitレベル、あるいは個別のアカウントに適用できます。RCPsはリソースへの一貫したアクセスを強制し、一方SCPsはプリンシパル自体の一貫したアクセスに焦点を当てています。ユースケースは異なりますが、相互に補完的な関係にあります。
RCPsはリソースへの外部アクセスを防ぎ、Confused Deputyコントロールを強制することができます。これらは、アイデンティティが外部リソースにアクセスすることを防ぎます。組織内でアクセスを制限したい場合や、ビジネスを展開していないリージョンへのアクセスを防ぎたい場合は、SCPが適切な方法です。データペリメーターについて話す際、RCPsは非常に説得力があります。なぜなら、非企業または外部のアイデンティティが企業のリソースにアクセスすることを防ぐからです。これはアイデンティティペリメーターとして知られています。SCPsでは、企業のアイデンティティが非企業または外部のリソースにアクセスすることを防ぎます。これはリソースペリメーターとして知られています。例に示されているように、特にデータペリメーター防御の追加層が必要な場合は、両方を同時に実装することができます。
AWS Organizationsには管理ポリシーも用意されています。Tag Policy、Backup Policy、AI Service Opt-out Policy、そして数週間前に発表されたChatbot Policyについてはすでにご存じかと思います。 最新のアップデートについて補足させていただくと、昨日、Declarative Policyと呼ばれる新機能をリリースしました。 このDeclarative Policyは、EC2およびEBSやVPCなどのEC2関連の属性をサポートしてリリースされました。 これらの属性は、AWS Organizationsレベルで管理できるようになりました。例えば、Organizational Unitにポリシーをアタッチすることで、すべてのアカウントとリージョンにわたってEBSスナップショットのパブリック共有をブロックすることができます。これがDeclarativeと呼ばれる理由は、特定の属性の状態を宣言的に定義するからです。この場合、EBSスナップショットの共有をブロックするのは、将来作成されるものだけでなく、既存のスナップショットも対象となります。
これらの新しいポリシーと予防的なコントロールが実際にどのように機能するのか、見ていきましょう。まずはResource Control Policyから始めます。Matheusが説明したように、これはSCPを使用せずにAWSリソースのペリメーターコントロールとデータペリメーターを実現する方法です。今回は、AWS Secrets Managerを使用した例を見ていきましょう。 ご存知の方も多いと思いますが、Secrets Managerは、パスワードやアクセスキーなどのシークレットを安全に保存できるサービスです。デモのために、1つのシークレットをお見せしましょう。
AWS Configを活用した検出的コントロールと自動修復
これが私のシークレットです。今皆さんに見えているので、あまりシークレットとは言えませんが。この特定のシークレットには、このユーザーがアクセスできる暗号化キーと、シークレットIDとなるリソース名が含まれています。シークレットの値を取得すると、シークレットキーは「my secret」で、値は「very very secret」であることがわかります。
ここにあるのは、皆さんがおそらくすでに適用したことのあるようなリソースポリシーです。このポリシーは、この特定のシークレットに対して、1つの特定のアカウントからアクセスできることを示しています。この場合、このアカウントは私のOrganizationの外部にあります。開発者がセキュリティをあまり気にしていなかったか、テスト中でリソースポリシーの削除を忘れてしまった可能性があります。このポリシーは、私たちのアカウントの別のロールにシークレットを取得する権限を与えています。
私が引き受けているロールのIDを確認してみましょう。このシークレットを取得する必要がある場合、AWS CLIを使用してUS Eastリージョンにある特定のシークレットIDのSecrets Manager値を取得していることがわかります。このシークレットを取得すると、その値が表示されます。Organization外部のアカウントからアクセスできたということは、データペリメーターを確立する必要があることを示しています。ここでResource Control Policyが活躍するわけです。
実際の組織のアカウントに切り替えてみましょう。これが私の組織の管理アカウントです。Organizations に移動し、次にPolicies に進むと、後ほど確認する現在のポリシーの他に、Resource Control Policiesに2つのポリシーがあることがわかります。1つ目はRCP Full AWS Accessで、これによってアクションを実行することができます。これはService Control Policiesとまったく同じように動作し、Organizational UnitsやAWSアカウントにアタッチすることができます。
Secrets RCPポリシーを見てみましょう。これは皆さんがご存じの構文に従っています。この場合、すべてのアクションに対してDeny効果があるので、先ほど見たキーに対してアクションを実行することができません。条件では組織にペリメーターを設定しています - リクエストが現在の組織ID以外から来ている場合、または組織外部の特定のサービスからでない場合は、拒否されます。ターゲットを見ると、まだターゲットが設定されていないことがわかります。これを私のセカンダリーアカウントにアタッチしようと思います。
これで、他のアカウントで見たリソースポリシーに関係なく、このポリシーを強制することができます。ターミナルに戻って、同じアカウントのままですが、今度は値を取得しようとすると、Resource Control Policyで明示的に拒否されているため、アクセスが拒否されます。これにより、開発者は必要なインフラストラクチャをデプロイできると同時に、セキュリティを中央で管理することができ、不適切な運用を心配することなくイノベーションに集中できます。次は宣言的なポリシーに移りましょう。別のアカウントに切り替えて、EC2を見てみましょう。昨日お話ししたように、起動時のポリシーがEC2の属性をサポートするようになりました。これがLaunchがサポートしているサービスで、私たちはすべてのリソースに従ってほしい特定のベースラインを強制しようとしています。
では、スナップショットを確認してみましょう。ここにすでにスナップショットを作成してあります。権限の変更に進むと、この特定のスナップショットがプライベートであることがわかります。権限にアクセスすると、パブリックに設定することができます。それを妨げるものは何もありません。単純に権限を変更できます。しかし、管理とガバナンスの観点から、Service Control Policiesのようにアイデンティティの観点からアクションを強制して制限するのではなく、どうすれば中央でこれを防ぐことができるでしょうか？宣言的なポリシーを使用してこれを実現するにはどうすればよいでしょうか？
管理アカウントに戻り、AWS Organizationsにもう一度アクセスしましょう。Policiesに移動すると、EC2用の新しい宣言的なポリシーが表示されます。すでに作成済みのものを確認してみましょう。このポリシーは、メンバーやユーザーがスナップショットをパブリックにすることを防ぎます。ポリシーの作成方法を見てみましょう。名前を設定し、説明を追加し、ポリシーエディターを使用します。これらが起動時にサポートする属性です。EC2では、スナップショットへのパブリックアクセスのブロックや特定のアクセス制御の確立などの機能をサポートしています。例えば、VPCパブリックアクセスの場合、VPCにInternet Gatewayが作成されているかどうかに関係なく、宣言的なポリシーの観点からパブリックアクセスを許可しない設定にしていれば、リソースは外部と通信できません。
例えば、Instance Metadataのデフォルトについて見てみましょう。EC2インスタンスに対してIMDSv2で特定のトークン認証を強制したい場合、Instance Metadataバージョン2でトークンを必須とすることで強制できます。オプショナルに設定すると、バージョン1も使用可能になりますが、この場合はバージョン2を必須としています。アクセスを試みるユーザーに対してエラーメッセージを追加したい場合も可能です。例えば、「これはテスト」というメッセージを設定したり、同じポリシー内で必要に応じて他の属性を設定したりできます。
既存のポリシーを確認してみましょう。このポリシーは、すべてのリソースにおいてスナップショットへのパブリックアクセスをブロックしています。現在のポリシーの利点は、新規リソースまたは既存のすべてのリソースに対して強制できることです。また、コントロールが意図せずリソースに影響を与えないよう、リソースのステータスレポートを生成してS3バケットに保存する機能もあります。これは現在、宣言的ポリシーで利用可能です。
では、ターゲットを見て、同じ作業を行ってみましょう。このポリシーを同じアカウントにアタッチします。そして、スナップショットがある別のアカウントに戻り、EC2とスナップショットに移動して、同じユーザーとして再度権限を変更しようとすると、このオプションがアカウントの管理者によって無効化されていることがわかります。これは、これらのガードレールを一元的に強制できることがいかに有用かを示しています。
予防的コントロールについて説明してきましたが、次はプロアクティブコントロールについて説明しましょう。プロアクティブコントロールは、リソースが実際にデプロイされる前にコンプライアンスをチェックします。これにより、新しいリソースがセキュリティ監視ニーズに対して設定したコントロールに準拠しているかどうかを判断します。これはAWS CloudFormation Hooksを使用して実装します。CloudFormation Hooksは、CloudFormationテンプレートの途中で処理を介入させる方法を提供します。ここで例を見てみましょう。これは単純なバケットだけの、プロパティを全く持たないごく基本的なCloudFormationテンプレートです。
いくつかのHooksを実装したいと考えていますが、これらのHooksはCloudFormation Guardと呼ばれるものを使用して実装されています。CloudFormation Guardは、GitHubでオープンソースツールとして提供されているPolicy-as-Codeソリューションです。プロアクティブコントロールを合理化するためのルールを作成することができます。
この私が持っているHookは、この場合S3の暗号化を探しています。何も設定していないため、このHookが発動することになります。この特定のHookが探しているものがあるため、暗号化が全くないことからFailすることになります。これはCloudFormationでも実現できます。私の会社ではTerraformを導入していて、私自身もTerraformの方が得意なのですが、Cloud Control APIと呼ばれるものを使用して、Terraformでもプロアクティブなコントロールを実装できます。これは、すべてのサービスを直感的に管理するための標準化されたCreate、Read、Update、Delete、ListのAPIです。
これを実装するには、AWS CCまたはAWS Cloud Control APIと呼ばれる新しいバージョンのTerraform Providerを使用します。では、例を見てみましょう。ここにTerraformのコードがありますが、非常にシンプルなコードです。AWS CCをProviderとして使用し、S3 Bucketをデプロイしようとしています。この場合、バージョニングを探すHookがあります。AWSはTerraformをGoのSDKを使用してCloud Control APIを呼び出すように変換します。
Cloud Control APIは、CloudFormation Hookを使用して連携できます。Hookが登録されているため、PassかFailのどちらかになります。つまり、AWS CCとAWSが実装したプロアクティブコントロールを使用してTerraformを利用できるようになったわけです。実際の動作を見てみましょう。設定を変更していきます。すでにいくつかの設定があり、最初に共有したいのは実際のGuardルールです。これはDSL（Domain Specific Language）タイプのサービスやツールとしてとても分かりやすいものです。
この場合、すべてのS3 Bucketでバージョニングを有効にする必要があると宣言または規定しています。これがGuardルール自体です。Terraformテンプレートを見てみると、これが私が持っているとてもシンプルなテンプレートです。CloudFormationでHookをどのように設定できるか見てみましょう。Hookを作成します。GuardまたはLambdaを直接使用してHookを作成できます。より細かい制御が必要な場合は、Lambdaの方が適していますが、Guardも使用できます。
先ほど見ていただいたS3 Bucketにすでにアップロードしてあります。出力レポートについては、同じBucketまたは別のBucketに送ることができ、この場合S3 Hooksという名前のHook自体の名前を指定します。ターゲットはCloud Control APIとデプロイするリソースになります。これを作成時と更新時に実行したいと考えています。そしてHookモードは非常に重要で、この場合はFailingに設定します。なぜなら、次のアクションに進む前に停止させたいからです。
新しいロールを作成していきます。必要に応じて、StacksやRolesによるフィルターを実装することもできます。今回はデフォルトのままにして、Hookを有効化します。では、ターミナルに戻りましょう。まず最初に、これを消去します。初期化を行って、実際に実行してみようと思います。
Hookの作成に同意すると、予想通り失敗します。ここに表示されている情報を使って、詳細な結果を確認できます。ターゲットタイプがCloud Controlで、上記のターゲットIDを見ると、完全なレポートは先ほど共有したS3バケットに保存されていることがわかります。この場合、バージョニングが有効になっていなかったために失敗したのですが、これは私が実際に示したかったことです。このように、CloudFormationだけでなく、リソースに対してもAWS CloudFormation Guardのプロアクティブなコントロールを実装できます。
Rodolfoにバトンを渡す前に、多くのGuardルールを含むリポジトリへのQRコードをご紹介したいと思います。先ほどの例は一つのケースでしたが、このQRコードのリポジトリには、さまざまなタイプのリソースに適用される多くのルールが含まれています。ありがとうございました、Matias。
AWS CloudTrailとAudit Managerによる監査と可視性の向上
予防的または事前対策的な観点からコントロールを実施するためのメカニズムについて説明してきましたが、それでも問題が発生する可能性があります。コンプライアンス違反のリソースがデプロイされてしまうこともあり得ます。そのような事態が発生した場合でも適切な可視性を維持するためのメカニズムが必要です。そのため、リソースの検出と修復のための保護機能を持つことが重要です。
皆さんもよくご存じのAWS Configを活用して、検出メカニズムとコントロールを実装できます。最初の機能は、2つの方法でリソースの設定履歴を追跡できることです。1つ目はイベントベースで、リソースタイプに変更があるたびにConfiguration Itemと呼ばれるものが生成され、それに基づいて特定の評価を実行できます。もう1つは定期的な記録で、例えば24時間ごとにリソースの特定の設定状態をチェックします。
すべての情報は、Configuration Recordと呼ばれるものに集約されます。これは本質的に、 AWS Configがすべてのリソースを可視化し、その変更を追跡する仕組みです。これが整うと、リソースの望ましい状態を評価する評価機能を実行できるようになります。これには様々な要素が含まれますが、詳しく見ていきましょう。Config Ruleを実行すると、Matiasが説明していたプロアクティブコントロールでのバージョニングのチェックのように、それらが実際に適用されているかを確認できます。
過去数ヶ月間などの構成履歴を確認したい場合、Config Rulesを使用してこの評価を実行し、コンプライアンスステータスを取得して評価することができます。これにより、望ましい状態と、自社のポリシーに準拠しているかどうかが分かります。これによって検知メカニズムを実装する機能が提供されます。コンプライアンス違反が発生した場合、報告を受けて手動で修正することもできますが、自動化を実行することも可能です。AWS Systems Managerのドキュメントを活用して独自の自動化を構築したり、マネージド型のConfig自動修復機能を使用してリソースを望ましい状態に復元したりできます。
これは非常に強力な機能なので、実際にどのように機能するのか見ていきましょう。AWS Configはリソースの状態を維持し、Configuration Itemと呼ばれるリソースのJSON表現を提供することを覚えておいてください。これはリソースのメタデータです。この例では、EC2インスタンスの例を見ています。このJSONファイルには、アベイラビリティーゾーン、リージョン、リソースIDなど、リソースのメタデータのキーと値のペアが含まれています。さらにスクロールしてこのEC2インスタンスの設定を詳しく見ていくと、検知ポリシーに関して議論していたインスタンスメタデータが表示されます。
HTTPトークンが必要であることを示しています。これは、EC2インスタンスの設定ファイルのメタデータオプション内にあります。これが必要で、これが今AWS Config Rulesで期待している状態です。この例では、Matheusがプロアクティブな観点から説明したGuardドメイン固有言語の例を示しています。AWS CloudFormation Guardフックを使用してプロアクティブに強制することもできますが、同じドメイン固有言語をConfig Rulesから活用して独自のルールを作成することもできます。
AWS Configには500近くのマネージドルールのリストが用意されており、様々なユースケースで活用できます。特定のものを作成したい場合は、Guard言語を活用してそれらのルールを作成できます。AWS Lambdaを活用してPythonで実行することもできますが、その場合はLambdaの保守や追加の管理責任が必要になります。AWS Config内でGuardを活用すれば、そういった種類の管理はAWS Configが担当してくれます。
これは、JSONファイルのValue Keepersで確認したように、特定のEC2インスタンスのメタデータバージョンを確認する簡単な例です。私は、設定内のMetadata Optionsの下にあるHTTPトークンを調べていました。この場合、Requiredという値を期待しており、つまりインスタンスメタデータのバージョン2を強制しています。そうでない場合は、カスタムエラーメッセージを設定できます。Guardを活用したこれらのカスタムルールの重要な機能の1つは、トラブルシューティング用のAmazon CloudWatchロググループを作成できることです。ルールを作成して期待通りに動作しない場合にデバッグしたい時は、この特定のカスタムルール用の専用ロググループを作成できます。
この例では、コントロールが実行する評価チェックにより、Requiredという値を期待していたのに、Optionalという値を取得していることがわかります。つまり、適切なバージョンを実行していないため、ポリシーに従っておらず、対処が必要だということです。 アカウントの進化とアカウント戦略で見たように、AWS Control Towerは始めるためのマネージドサービスでした。コントロールについても同じことが言えます。Control Towerには、先ほど見た3つのケースすべてをカバーするコントロールのライブラリが用意されています。予防的なユースケース、検出的なユースケース、そして事前対応的なユースケースがあります。
最初に、ビジネス目標への整合性を目指していると述べたことを覚えておいてください。業界標準に従い、独自のガバナンスポリシーや戦略に従っているわけです。コントロールを見るのではなく、達成したいことから考え始めることができます。この場合、EC2というサービスに焦点を当てています。私の目的はネットワークアクセスを制限することです。これは、例えばVPCへのアクセスなど、関連するユースケースから実現できます。事前対応的なコントロールを使用してセキュリティグループが期待以上のアクセスを提供していないことを確認し、さらに検出的なコントロールを使用してそれらが適用されていることを確認することもできます。
技術的な観点から最初に話した3つ目のカテゴリは監査でした。これらのメカニズム、マルチアカウント戦略、これらすべてのものを整備し、これらすべてのコントロールを持っていても、実際にこれらを適用していることを保証する必要があります。 まず最初に、皆さんがよくご存知のAWS CloudTrailというサービスがあります。これは監査証跡を管理する機能を提供します。この場合、Trailsでサポートされているイベントのタイプを見ています。これにより、これらのイベントをすべて集約できる組織レベルのTrailを作成する機能が提供されます。
Management Eventsを見ると、これらはコントロールプレーンのイベントです。例えば、Amazon S3バケットの観点から、新しいバケットを作成したり削除したりする場合、それらはManagement Eventタイプで追跡されるコントロールプレーンイベントです。もう1つのタイプはData Eventsです。実際のリソースで発生するイベントを見ている場合、同じ例を使用すると、S3バケット内のオブジェクトを削除する場合、それはData Eventのタイプです。これらはデフォルトでは存在しないため作成する必要があり、また料金も発生します。注意が必要で、追跡したいものを選択する方法があります。
3番目のタイプはネットワークアクティビティイベントで、VPC内を流れるAPIを追跡する機能を提供します。この機能は数ヶ月前にリリースされ、VPCから発信される実際のAPIコールを追跡することができます。より詳細なアプローチを提供し、監査証跡をより深く掘り下げることができます。CloudTrailイベントが重要なのは、何が起きているのかを理解するためのフォレンジック機能を提供し、監査ニーズを満たすからです。
イベントフィールドは、アクティビティのさまざまな側面を理解する上で重要です。まず、userIdentity.arn、User Agent、そのような識別子などのイベントを通じて、誰がそのコールを行ったのかを知る必要があります。誰が行ったかを特定したら、何が起きたのかを把握する必要があります。これには、アカウントID、アクセス元、指定されたイベント名、そのリクエストに付随するリクエストパラメータなどの詳細が含まれます。また、時間とリージョン情報も追跡する必要があります。アクションがどのように実行されたかを理解するために、イベントタイプや使用されたアクセスキー、コンソールを通じてログインしていたかどうかなどの詳細を確認できます。アクションの結果を理解することも重要です。失敗や拒否された場合はそれほど懸念する必要はありませんが、成功した場合は、これらの基本的な機能として必要な監査証跡を理解する必要があります。
では、これらのアクションを最適化して監視する方法について説明しましょう。最適化に関して、先週、マネジメントイベントとデータイベントの拡張イベントフィルタリング機能をリリースしました。これにより、特定のCloudTrail Lakeからノイズの多いAPIコールを除外できます。CloudTrail Lakeは、CloudTrailイベントのデータレイクを持ち、管理する方法です。CloudTrail Lakeがない場合、すべてのログを含む独自のS3バケットを作成してAthenaクエリを実行することもできますが、そのレイクを自分で管理する必要があります。CloudTrail Lakeを活用して、特定のリソースからのノイズを避けたり、特定のタイプのAPIコールをフィルタリングしたりして最適化できます。組織全体のビューを得るために活用できるハイライトやカスタムダッシュボードも用意されています。
これらの新しい高度なイベント収集フィルタリング機能がどのように機能するか見てみましょう。独自のリンクを作成し、すべてを追跡するが、特定のユースケースで不要なノイズの多いサービスの代わりにコールを行う特定のロールを除外するように指定できます。CloudTrail Lakeで除外したい特定のサービスイベントがある場合、拡張イベントフィルターを使用して今すぐ設定できます。監査の観点からの可視性とより良い観測性機能に関して、先週リリースしたダッシュボードを活用できます。Highlightsダッシュボードでは、利用しているアカウント数、それらのアカウントでのアクティビティ、発生した破壊的なアクション、監査証跡に関連するリージョンを示すアクティビティの概要を提供します。また、過去24時間のスロットリングエラーの数やアカウントでのアクティビティの種類など、生成AIを活用した要約を提供する機能も備えています。
また、14の事前構築されたダッシュボードも用意されています。ガバナンスに焦点を当てているため、組織全体で最も使用されているサービス、関連するアカウント数、それらの特定のアカウントでカウントされたイベント数を理解するのに役立つ組織ビューがあります。日付でフィルタリングでき、さまざまなタイプのダッシュボードが利用可能です。これらのオプションで十分でない場合は、独自のダッシュボードを作成できます。例えば、利用されている主要なIAM APIを分析したり、ダッシュボードでトップ10を表示したり、S3エラーを確認したり、エラー分析を実行したりできます。独自のカスタムダッシュボードを作成して可視性を高めるために活用できるウィジェットが多数用意されています。
この全体像を完成させるために、保証を提供し、冒頭で触れた業界標準や規制への準拠、そして内部・外部監査への準備について考えてみましょう。AWS Audit Managerはその自動化を支援します。AWS CloudTrail、ユーザーアクティビティログ、外部エビデンスなど、複数のソースから自動的に証拠を収集することができます。
AWSに存在しないポリシードキュメントなどの特定のアイテムをアップロードすることができます。AWS Configのチェックやサービス間のAPI呼び出しなど、複数のサービスを集約し、特定のリソースのスナップショットを取得して、その設定を確認し、評価のエビデンスの一部として含めることができます。これらを外部監査チームや社内チーム、サードパーティツールと共有することができ、さらにCloudTrailと連携してクエリによる迅速なエビデンスチェックを実行することも可能です。
Cloud Governanceの実践に向けたまとめと追加リソース
このセッションのまとめとして、重要なポイントをご紹介します。まず、アカウント戦略を定義することが重要です。マルチアカウント戦略はガバナンスにとって極めて重要です。AWS Control Towerを活用し、Control Towerをデプロイして、先ほど説明した管理されたコントロールのライブラリを利用してください。次に、ガバナンスの目的を支援するコントロールを活用してください。Control Towerには500以上のコントロールがあり、AWS Configにも数多くのコントロールがあるので、これらを十分に活用してください。AWS Organizationsには、管理アカウントへの不要なアクセスを防ぐための委任管理者機能があるので、この委任管理者機能を使用してください。
ここで、いくつかの追加リソースをご紹介させていただきます。まず一つ目はCloud Adoption Frameworkです。また、AWS Cloud Governanceサービスを活用した移行プロジェクトについて、世界中の8つのお客様にインタビューを行ったIDC調査もご用意しています。三つ目のリソースは、利用可能なすべてのリソースが含まれているAWS Cloud Governanceの原則に関するページです。
これらは、イベントを通して見つけることができる関連セッションです。COP326では、AWS Configについて再び発表する予定です。ガバナンスに関する他のセッションもご覧いただけます。セッションに参加できない場合は、AWS Villageの私たちのキオスクにお立ち寄りください。私たちのガバナンスとコンプライアンス専用ブースでは、VR体験や書籍のプレゼント、スワッグをご用意しています。ご質問がある場合は、他のAWSエキスパートと共に専門家として待機していますので、ぜひお立ち寄りください。
以上で本日のセッションを終了させていただきます。ご参加いただき、誠にありがとうございました。アンケートのご記入をお忘れなく。それでは、素晴らしいイベントをお楽しみください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion