re:Invent 2024: AWSセキュリティコントロールの3カテゴリーと実装方法
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Navigating the AWS security controls toolbox (COP361)
この動画では、AWS環境におけるセキュリティコントロールの3つの主要カテゴリーについて解説しています。予防的コントロールとしてService Control PoliciesやResource Control Policies、検知メカニズムとしてAWS Config Rules、事前対応的コントロールとしてCloudFormation Hooksの活用法を詳しく説明しています。AWS Security HubやAWS Control Towerなどのサービスを活用した統合的なセキュリティ管理の方法や、約500のAWS Config Managed Rulesの活用、Conformance Packsによる一貫したポリシー適用など、具体的な実装方法にも踏み込んでいます。特にIMDSv2への自動修復デモを通じて、AWS Systems Managerとの連携による実践的なセキュリティ運用の手法を示しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS Security Controlsツールボックス：概要と課題
ようこそ。本日は「COP 361 AWS Security Controlsツールボックスの活用法」についてご説明させていただきます。今日の急速に進化し続けるクラウド環境において、適切なセキュリティ態勢を維持することは極めて重要です。様々な選択肢の中から最適なものを選ぶのは大変な作業だと認識しています。本セッションでは、セキュアな環境を実現するために活用できる3つの主要なカテゴリーやサービスに焦点を当てます。私はPrincipal Solutions ArchitectのRodolfo Brenesで、ガバナンスとコンプライアンスを専門としています。AWS Config、AWS Organizations policies、そしてCloudFormation Guardについて、これらのメカニズムと他のサービスとの連携方法をご紹介します。このセッションを通じて、どこから始めればよいのか、そしてこれらのサービスをどのように活用できるのかを包括的に理解していただけることを願っています。
本日のアジェンダは、まず導入から始まり、お客様が直面している主な課題について説明します。その後、セキュリティに関連するガバナンスサービス、様々な実装オプション、そして簡単なデモをご紹介します。組織によって異なる目的や目標を持っているのは当然のことです。 当社のMark Schwartzが述べたように、ガバナンスには2つの重要な目的のバランスが必要です：コントロールと、同時に実現可能性の確保です。私たちは、お客様やユーザーがAWSを選んだ理由でもあるアジリティを失うことは望んでいません。お客様が適切に管理された環境、つまりイノベーションに集中し続けることができるLanding Zoneを提供することを目指しています。
まずは、コントロールに関する課題から見ていきましょう。お客様が直面する最初の課題は、AWSで利用可能な様々な観点に圧倒されることです。2つ目は断片化です - 適用可能な異なるコントロールが、異なるドメインにまたがっているということです。例えば、セキュリティコントロール、カスタマイズコントロール、そしてCompute、Databaseなど、様々なニーズに対応する必要があります。3つ目は複雑さです - これらのサービスがどのように連携するかを理解するのは非常に困難な場合があります。4つ目はスケールでのガバナンスです - クラウドインフラの成長に合わせて、現在の環境やセキュリティメカニズム、コントロールをどのように確実に成長させていくかということです。
それでは、ガバナンスとコンプライアンスをサポートするサービスのリストから始めましょう。まずは要件の定義から始めることをお勧めします。どのようなポリシーや戦略に従いたいのか、どのサービスがそれらの目的をサポートできるのか、そしてAWS内でどのようなソリューションが利用可能かを理解する必要があります。2つ目の側面は、これらのコントロールをどのようにデプロイし運用するかです。多くのサービスがあり、先ほど述べたように、これはお客様がこの分野に取り組み始める際の課題の一つとなっています。3つ目の側面は、導入したメカニズムをどのように測定し評価するか、それらが適切に機能していることをどのように確認し、時間とともにどのように進化させていくかということです。本日は、コントロールをデプロイできるサービスに焦点を当てます。
最初に、オーケストレーターとしてのControl Towerについてですが、Control Towerの詳細には深く立ち入りませんが、これは中央の場所から管理された方法でオーケストレーションを可能にするサービスだということを覚えておいてください。AWS Organizations、プロアクティブなコントロールを実行するためのCloudFormation機能、そしてAWS Configルールについて見ていきます。これらはSecurity Hubなどの他のサービスと集約・統合することができます。
予防的・検知的・事前対応的コントロールの詳細
それでは、これらのコントロールが3つの主要な柱でどのように適用されているかについてお話ししましょう。1つ目は予防的コントロールです。ここでは、 コンプライアンス違反となる設定ミスを完全に防ぐための特定のベースラインを強制できるコントロールがあります。多くの方がすでにご存知のService Control Policiesがあります。これはAWS Organizationのアイデンティティに適用可能なメカニズムやガードです。次にResource Control Policiesがありますが、これは1週間ほど前に発表された非常に新しいポリシーです。これにより、従来のIdentityやService Control Policiesで持っていたコントロールをリソースレベルに拡張することができます。最後にDeclarative Policiesですが、これはリソースに対する特定のガードレールやベースライン設定を強制する方法で、Organization自体からそれらを実施する方法です。現在のローンチ時点では、日曜日にリリースされ、基本的にAC2をカバーしています。
AC2がローンチ時点でカバーされている一方で、 検知メカニズムについても見ていきましょう。これらは、何かがコンプライアンス違反になった場合に、望ましくない変更や望まない状態を検出するためのセーフガードです。これを実現する方法がAWS Config Rulesで、その仕組みと他のサービスとの統合について見ていきます。AWS Configは、複数のサービスのバックエンドで動作する中核的な存在です。今回はセキュリティについて話しているので、Security Hubとの統合に焦点を当てますが、Trusted AdvisorやNetwork Firewall Managerなどの他のサービスも強化していることを覚えておいてください。
3つ目のタイプは事前対応的コントロールです。Infrastructure as Codeを活用して、 コンプライアンス違反を防ぐために必要な評価を実行する方法です。 最近議論されているのは、Service Control PoliciesとResource Control Policiesの使い方についてです。Service Control Policiesは長年存在し、Organizationのプリンシパルへの一貫したアクセスコントロールの強制に重点を置いています。例えば、Organization内で特定のプリンシパルやアイデンティティが実行できるアクションの量を制限したい場合は、Service Control Policiesを使用します。Organizationの外部でリソースを消費する際に何らかのペリメータを設けたい場合は、SCPsを使用します。
Resource Control Policiesは、これをリソースレベルにもたらし、Organization内のリソースへの一貫したアクセスコントロールを強制します。リソースに対してデータペリメータ要件などのメカニズムを提供したい場合、メンバーアカウントでResource Policiesを使用します。Resource Control Policiesを使用すると、必要なOrganizational Unitsを通じてOrganizationレベルでこれを強制できるため、各アカウントのリソースレベルで何が設定されているかを気にする必要がなく、一元的に強制できます。
Resource Control Policiesの 主なユースケースは、データペリメータコントロールです。SCPsとRCPsがどのように連携するかの例を見てみましょう。RCPsを使用することは、SCPsが不要になるということではありません - これらは包括的なソリューションを提供する異なるユースケースのためのものです。この例では、SCPsを通じてリソースペリメータと呼ばれるものを定義している企業ユーザーがいます。リソースペリメータは、企業ユーザーがOrganization外部の非企業リソースにアクセスできないことを示します。しかし、Organization内にリソースがあり、外部ユーザーがそれにアクセスできないようにしたい場合はどうでしょうか？そこでResource Policiesが役立ち、アイデンティティペリメータを確立します。
Declarative Policiesについて、先ほど申し上げたように、これは常に存在していなければならないベースライン設定を確立する方法です。 Declarative Policiesの重要なポイントは、AWS Organizationsを活用してポリシーを適用できることです。この具体的なケースでは、 EC2の特定の属性に対して適用されます。現在、Declarative PolicysはEC2の属性をサポートしています。EBSスナップショットの例を見てみると、EBSスナップショットのパブリック共有は、使用されるAPIに関係なく、常にプライベートである必要があると指定しています。もしAWSが明日、新しいパブリックスナップショットの作成方法をリリースしたとしても、このポリシーが継承されます。
これを導入することで、 コントロールプレーンでのAPI呼び出しがAWSによって一元的に管理されることを確実にできます。これは非常に強力な機能です。なぜなら、たとえメンバーアカウントでVPCへのパブリックアクセスを試みても（これもDeclarative Policiesで設定可能な別の属性です）、中央で管理してそれを防ぐことができるからです。 次に、Detective Controlsに移りましょう。予防的なメカニズムについて説明しましたが、何かがデプロイされたり変更されたりした場合、それをどのように検知できるでしょうか？AWS Configは、サポートされているすべてのリソースの変更を追跡し続けるレコーダーを持つ機能を提供します。AWS Config Rulesを通じて評価を実行しますが、これはマネージドルールやGuardやLambdaを使用して作成されたカスタムルールのステートメントです。これにより、継続的な評価を実行し、リソースの継続的なコンプライアンスを維持することができます。何かがコンプライアンス違反の場合、通知を受け、その結果が集約されます。
これらの発見事項を修復したい場合、自動または手動で実行できます。ここでAWS Systems Managerとの統合により、これらの自動化を実行するためのドキュメントを使用できます。これにより、単なる検知だけでなく、AWS内でこのセルフヒーリング機能を持つことができるのです。
AWS Config Rulesについて、先ほど申し上げたように、キーのローテーションやバージョニングの有効化など、一般的なユースケース向けに約500のAWS Config Managed Rulesを活用できます。独自のカスタムルールを作成することもでき、Conformance Packsも利用できます。Conformance Packsは基本的に、AWSが提供するAWS Config Rulesのグループです。サービスにアクセスすると、PCI DSSやAmazon S3の運用ベストプラクティスなど、一般的なユースケース向けの多くのConformance Packsを利用できます。特定のユースケースや、社内ガイドラインに従って適用したいルールセットがある場合も対応可能です。これらは不変であり、 AWS ConfigのDelegated Administrator Accountからメンバーレベルのアカウントにデプロイすると、変更することはできません。
最後にProactive Controlsですが、AWS CloudFormation Hooksを活用することで、インフラストラクチャアズコードのデプロイメント内でコードを使用してテンプレートをポリシー評価として実行し、必要なガイドラインに従っていることを確認できます。この具体的なケースでは、デプロイされるすべてのAmazon S3バケットで特定の設定を有効にする必要があることを強制しています。ガイドラインに従っていない場合、2つの異なるアクションを取ることができます：デプロイメントは許可しながら警告するだけの場合と、そのコントロールのデプロイメントを完全に失敗させる場合です。つまり、デプロイメント前に、 開発者フレンドリーな方法でこれらの予防的な評価を実行できるのです。
AWS ConfigとSecurity Hubを活用したセキュリティ管理のデモンストレーション
例えば、AWS CloudFormationを使用している場合、失敗の理由を示し、プロセスをロールバックします。また、AWS CloudFormationはTerraformのようなツールとも連携します。 ここで、これらがどのように連携するのかを説明させていただきます。AWS Control Towerはコントロールをデプロイする方法だとお話ししましたが、セキュリティに焦点を当てると、AWS Security Hubは様々な検出結果を集約できるツールです。検知メカニズムとしては、AWS ConfigやAWS Configなどのネイティブソリューションを活用したAWS Systems Manager、Amazon GuardDutyなどを利用できます。Amazon Inspectorは全てをAWS Security Hub内に集約し、Security Hubはイベントベースのメカニズムを使用してAWS Systems Managerによる修復を実行できます。具体的な例を見ていきましょう。
このケースでは、AWSコンソールにアクセスし、AWS Configに移動して、先ほど説明した検知メカニズムの活用方法を見ていきます。リソースに移動すると、追跡されているすべてのリソースを検索してフィルタリングできます。この例では、EC2インスタンスの設定を確認します。リソースインベントリを実行すると、すべての詳細情報が表示されます。ここに表示されているJSONファイルからインスタンスのメタデータをすべて取得できますが、具体的な例に焦点を当てています。このEC2インスタンスのインスタンスメタデータバージョンを確認したいと思います。この場合、「optional」と表示されており、これはEC2インスタンスでインスタンスメタデータのバージョン1が実行されていることを意味します。つまり、そのインスタンスと通信する際にトークンが必要ないということで、これはベストプラクティスではありません。
では、これを強制するための評価をどのように実行できるでしょうか？先ほど説明したように、様々なユースケースに対応した約500のマネージドルールを利用できます。この例では、この例のために作成したカスタムルールに焦点を当てます。このルールを見てみると、編集時にGuardという言語を利用できることがわかります。これはこの種の設定とコントロールのルール編集のためのドメイン固有言語です。JSONファイルの特定の値キーパーで必要な値が「optional」ではなく「required」でなければならないと指定しています。
つまり、これを強制する必要があるということです。このルールに移動すると、修復アクションを設定できます。修復アクションを設定すると、手動または自動で適用できます。具体的に見ていきましょう。このインスタンスがコンプライアンス違反であることが示されています。修復アクションを実行したい場合は、この修復を管理できます。バージョン1を実行していて、バージョン2に変更したい場合、AWS Systems Managerから管理されているこのスクリプトを強制実行できます。利用可能なオプションは多数あります。AWS Systems Managerに代わって操作を実行するために必要な権限を持つロールを設定するだけです。このインスタンスに移動して、修復を選択するだけです。これは例として手動で行っていますが、イベントの変更時にトリガーすることもできます。
IMDSv2がバージョン1であることを検出するたびに、自動的に自己修復して修正することができます。オペレーションハブを管理するAWS Systems Managerに移動すると、変更管理ツールと自動化に焦点を当てた多くの機能があります。AWS Configから自動的にトリガーされた自動化が実行され、この問題を修正するために実行されたすべてのステップとAPIコールを確認できます。EC2インスタンスで検出メカニズムを実行することができ、これはスケールで実行可能です。これが基本的な例です。バージョン1を使用していたため、現在はIMDSv2が必須となっており、この例で必要なベストプラクティスに従っていることがわかります。数分後にはコンプライアンスステータスが表示されますが、すでに反映されています。
Conformance Packsについて説明しますと、独自のルールグループを持つことができます。活用できる様々なテンプレートが用意されています。ご覧の通り、運用のベストプラクティスやセキュリティのベストプラクティスがあり、特定の基準に従うこともできます。これらは、基盤として活用できるテンプレートです。組織レベルでこれらのテンプレートを作成・展開するためのマネージドソリューションが必要な場合は、AWS Security Hubを活用できます。従うことのできるセキュリティ基準が複数用意されています。この例では、組織の管理を1つの特定のアカウント、つまりセキュリティアカウントに委任しています。必要な事前許可は全て設定済みです。
Central Configurationに移動すると、組織全体でSecurity Hubの調査結果を一元的に集約していることが分かります。これを展開すると、新規アカウントでは指定した必要なリージョンでSecurity Hubが自動的に有効化されます。AWS Foundational Security Best Practicesスタンダードを展開したところ、コントロールの80%がパスしていることが示されています。まだ修正が必要な項目もあります。Security Hubから詳しく確認できる、最も多くの指摘があったアセット（アカウント、重要度、リソースなど）に関する情報を提供しています。どのコントロールが適用されているか、どれがパスし、どれが失敗し、どれが評価中なのかを表示します。例えば、重要度の高い項目を示し、お客様が判断に迷いがちな優先順位付けの情報を提供します。
また、ここから確認できるFoundational Security Best Practicesの他に、CISなど複数の領域があります。Insightsも用意されており、必要に応じてConfig Rulesに基づいて独自のInsightsを作成することもできます。これらは事前に構築されたInsightsとして利用できます。さらに、サードパーティツールとの統合も可能です。他のセキュリティポスチャ管理サービスからの調査結果も取り込み、リージョンごとにこれらの調査結果を表示します。マルチアカウント戦略や各アカウントの調査結果を確認でき、全リージョンにわたってそれらを集約することができます。
InspectorやAmazon Macieなど複数のサービスを実行している場合、これらの情報もこの単一のダッシュボードで、リソースや関連情報と共に確認できます。先ほど説明したように、AWS Configに戻ると、Security Hubのバックエンドでは、これらのセキュリティ基準は実際にはAWS Config Rulesとして実行されています。Security Hubというプレフィックスが付いたルールが表示されますが、これらのルールはサービスによって管理され、ユーザーに代わって評価チェックを実行しています。もちろん、他のサービスを活用したい場合や異なるコントロールが必要な場合は、独自のルールを展開して統合することも可能です。
さらに詳しい話を聞きたい方は、Cloud Operationsキオスクにお越しください。ガバナンスとコンプライアンスに特化したキオスクを用意しています。ご清聴ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion