翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

序章

セキュリティは最優先事項です AWS。 AWS お客様は、最もセキュリティの影響を受けやすい組織のニーズをサポートするために構築されたデータセンターとネットワークアーキテクチャからメリットを得られます。 には責任共有モデル AWS があります。クラウドのセキュリティ AWS を管理し、お客様はクラウドのセキュリティを担当します。つまり、セキュリティ目標の達成に役立ついくつかのツールやサービスへのアクセスなど、セキュリティ実装を完全に制御できます。これらの機能は、 で実行されているアプリケーションのセキュリティベースラインを確立するのに役立ちます AWS クラウド。

設定ミスや外部要因の変更など、ベースラインからの逸脱が発生した場合は、対応して調査する必要があります。これを成功させるには、環境 AWS 内のセキュリティインシデント対応の基本概念と、セキュリティ問題が発生する前にクラウドチームの準備、教育、トレーニングを行うための要件を理解する必要があります。使用できるコントロールと機能を把握し、潜在的な問題を解決するためのトピックの例を確認し、自動化を使用して対応速度と一貫性を向上させる修復方法を特定することが重要です。さらに、これらの要件を満たすためのセキュリティインシデント対応プログラムの構築に関連するコンプライアンス要件と規制要件を理解する必要があります。

セキュリティインシデント対応は複雑な場合があるため、反復アプローチを実装することをお勧めします。まずコアセキュリティサービスから始め、基本的な検出と対応機能を構築し、プレイブックを作成して、反復と改善を行うインシデント対応メカニズムの初期ライブラリを作成します。

[開始する前に]

でセキュリティイベントのインシデント対応について学習する前に AWS、 AWS セキュリティとインシデント対応に関連する標準とフレームワークを理解してください。これらの基盤は、このガイドで説明されている概念とベストプラクティスを理解するのに役立ちます。

AWS セキュリティ標準とフレームワーク

まず、「Best Practices for Security, Identity, and Compliance」、「Security Pillar - AWS Well-Architected Framework」、「Security Perspective of the Overview of the AWS Cloud Adoption Framework (AWS CAF)」ホワイトペーパーを読むことをお勧めします。

AWS CAF は、クラウドに移行する組織のさまざまな部分間の調整をサポートするガイダンスを提供します。 AWS CAF ガイダンスは、クラウドベースの IT システムの構築に関連する視点と呼ばれるいくつかの重点分野に分かれています。セキュリティの観点からは、ワークストリーム全体にセキュリティプログラムを実装する方法について説明しています。その 1 つがインシデント対応です。このドキュメントは、効果的で効率的なセキュリティインシデント対応プログラムと機能の構築を支援するために、お客様と連携した経験の成果です。

業界のインシデント対応標準とフレームワーク

このホワイトペーパーは、米国国立標準技術研究所 (NIST) によって作成された「Computer Security Incident Handling Guide SP 800-61 r2」のインシデント対応標準とベストプラクティスに従います。NIST によって導入された概念を読み、理解することは、役立つ前提条件です。この NIST ガイドの概念とベストプラクティスは、このホワイトペーパーの AWS テクノロジーに適用されます。ただし、オンプレミスのインシデントシナリオは、このガイドの対象外です。

AWS インシデント対応の概要

まず、クラウドでのセキュリティオペレーションとインシデント対応がどのように異なるかを理解することが重要です。効果的な対応機能を構築するには AWS、従来のオンプレミス対応からの逸脱と、インシデント対応プログラムへの影響を理解する必要があります。これらの各違いと、インシデント対応の主要な AWS 設計原則については、このセクションで詳しく説明します。

AWS インシデント対応の側面

組織内のすべての AWS ユーザーは、セキュリティインシデント対応プロセスの基本を理解し、セキュリティ担当者はセキュリティ問題への対応方法を理解する必要があります。教育、トレーニング、経験は、クラウドインシデント対応プログラムを成功させるために不可欠であり、起こり得るセキュリティインシデントに対処する前に十分な余裕を持って実施するのが理想的です。クラウドで成功するインシデント対応プログラムの基盤は、準備、運用、インシデント後のアクティビティです。

これらの各側面を理解するには、以下の説明を参考にしてください。

これらの各側面については、このガイドで詳しく説明します。次の図は、前述の NIST インシデント対応ライフサイクルに沿って、これらの側面のフローを示していますが、検出と分析を含むオペレーションと、封じ込め、根絶、復旧が含まれています。

AWS インシデント対応の原則と設計目標

NIST SP 800-61 コンピュータセキュリティインシデント処理ガイドで定義されているインシデント対応の一般的なプロセスとメカニズムは健全ですが、クラウド環境でのセキュリティインシデントへの対応に関連する以下の特定の設計目標も考慮することをお勧めします。

これらの設計目標は、インシデント対応と脅威検知の両方を実施する能力について、アーキテクチャの実装を確認することを促すものです。クラウド実装を計画する際は、インシデントへの対応を検討してください。理想的には、フォレンジック的に健全な対応方法論を使用します。場合によっては、これらの対応タスク用に複数の組織、アカウント、ツールが特別に設定されている可能性があります。これらのツールと機能は、デプロイパイプラインによってインシデント対応担当者が利用できるようにする必要があります。リスクを大きくする可能性があるため、静的な状態のままにしないでください。

クラウドセキュリティインシデントドメイン

AWS 環境内のセキュリティイベントを効果的に準備して対応するには、クラウドセキュリティインシデントの一般的なタイプを理解する必要があります。セキュリティインシデントが発生する可能性があるのは、サービス、インフラストラクチャ、アプリケーションの 3 つのドメインがお客様の責任内に存在します。ドメインごとに、異なる知識、ツール、対応プロセスが必要です。以下のドメインを検討してください。

これらのドメインでは、 AWS アカウント、リソース、またはデータに対して行動する可能性のあるアクターを検討してください。内部的か外部的かにかかわらず、リスクフレームワークを使用して組織に対する特定のリスクを判断し、それに応じて準備します。さらに、インシデント対応計画や慎重なアーキテクチャ構築に役立つ脅威モデルを開発する必要があります。

でのインシデント対応の主な違い AWS

インシデント対応は、オンプレミスまたはクラウドにおけるサイバーセキュリティ戦略の不可欠な部分です。最小特権や多層防御などのセキュリティ原則は、オンプレミスとクラウドの両方でデータの機密性、完全性、可用性を保護することを目的としています。これらのセキュリティ原則をサポートするいくつかのインシデント対応パターンには、ログ保持、脅威モデリングから派生したアラート選択、プレイブック開発、セキュリティ情報とイベント管理 (SIEM) 統合が含まれます。違いは、顧客がクラウドでこれらのパターンの設計とエンジニアリングを開始したときに始まります。以下は、 でのインシデント対応の主な違いです AWS。

相違点 #1: 責任共有としてのセキュリティ

セキュリティとコンプライアンスの責任は、 AWS とその顧客の間で共有されます。この責任共有モデルは、ホストオペレーティングシステムと仮想化レイヤーから、サービスが運用されている施設の物理的なセキュリティまで、コンポーネントを AWS 運用、管理、制御するため、お客様の運用上の負担の一部を軽減します。責任共有モデルの詳細については、責任共有モデルのドキュメントを参照してください。

クラウドにおける責任共有が変更されると、インシデント対応のオプションも変わります。これらのトレードオフを計画して理解し、ガバナンスのニーズと一致させることは、インシデント対応における重要なステップです。

直接的な関係に加えて AWS、特定の責任モデルで責任を持つ他のエンティティが存在する可能性があります。たとえば、オペレーションの一部の側面を担当する内部組織単位があるとします。また、クラウドテクノロジーの一部を開発、管理、運用する他の関係者と関係がある場合もあります。

運用モデルに合った適切なインシデント対応計画と適切なプレイブックを作成してテストすることは非常に重要です。

違い #2: クラウドサービスドメイン

クラウドサービスに存在するセキュリティ責任の違いにより、セキュリティインシデントの新しいドメイン、「インシデントドメイン」セクションで前述したサービスドメインが導入されました。サービスドメインには、お客様のアカウント AWS 、IAM アクセス許可、リソースメタデータ、請求、およびその他の領域が含まれます。このドメインは、インシデント対応の対応方法によって異なります。サービスドメイン内のレスポンスは通常、従来のホストベースおよびネットワークベースのレスポンスではなく、API コールを確認して発行することによって行われます。サービスドメインでは、影響を受けるリソースのオペレーティングシステムとやり取りしません。

次の図は、アーキテクチャのアンチパターンに基づくサービスドメインのセキュリティイベントの例を示しています。この場合、権限のないユーザーは IAM ユーザーの長期的なセキュリティ認証情報を取得します。IAM ユーザーには、Amazon Simple Storage Service (Amazon S3) バケットからオブジェクトを取得することを許可する IAM ポリシーがあります。このセキュリティイベントに対応するには、 AWS APIs AWS CloudTrailや Amazon S3 アクセス AWS ログなどのログを分析します。また、 AWS APIs を使用してインシデントを封じ込め、インシデントから復旧します。

相違点 #3: インフラストラクチャをプロビジョニングするための APIs

もう 1 つの違いは、オンデマンドセルフサービスの クラウド特性です。主要施設のお客様は、世界中の多くの地理的場所で利用可能なパブリックエンドポイントとプライベートエンドポイントを介して RESTful API AWS クラウド を使用して とやり取りします。お客様は、 AWS 認証情報を使用してこれらの APIsにアクセスできます。オンプレミスのアクセスコントロールとは対照的に、これらの認証情報は必ずしもネットワークまたは Microsoft Active Directory ドメインによってバインドされるわけではありません。認証情報は、代わりに AWS アカウント内の IAM プリンシパルに関連付けられます。これらの API エンドポイントは企業ネットワークの外部からアクセスできます。これは、認証情報が予想されるネットワークまたは地域外で使用されているインシデントにいつ対応するかを理解することが重要です。

API ベースの性質上 AWS、セキュリティイベントに対応するための重要なログソースは です。これは、 AWS アカウントで行われた管理 API コールを追跡し AWS CloudTrail、API コールのソースの場所に関する情報を見つけることができます。

違い #4: クラウドの動的な性質

クラウドは動的であり、リソースをすばやく作成および削除できます。自動スケーリングを使用すると、トラフィックの増加に基づいてリソースをスピンアップおよびスピンダウンできます。存続期間の短いインフラストラクチャとペースの速い変更では、調査対象のリソースが存在しないか、変更されている可能性があります。 AWS リソースの一時的な性質と、 AWS リソースの作成と削除を追跡する方法を理解することは、インシデント分析にとって重要です。を使用してAWS Config、 AWS リソースの設定履歴を追跡できます。

違い #5: データアクセス

データアクセスはクラウドでも異なります。セキュリティ調査に必要なデータを収集するためにサーバーに接続することはできません。データは、有線および API コールを通じて収集されます。このシフトに備えて APIs でデータ収集を実行する方法を練習して理解し、効果的な収集とアクセスのための適切なストレージを検証する必要があります。

相違点 #6: 自動化の重要性

お客様がクラウド導入のメリットを完全に実感するには、運用戦略に自動化を採用する必要があります。Infrastructure as Code (IaC) は、 AWS CloudFormation やサードパーティーソリューションなどのネイティブ IaC サービスによって容易になるコードを使用して AWS 、サービスがデプロイ、設定、再設定、破棄される、高効率の自動環境のパターンです。これにより、インシデント対応の実装は高度に自動化されます。これは、特に証拠を処理するときに、人為的なミスを回避するのが推奨されます。自動化はオンプレミスで使用されますが、 ではよりシンプルで不可欠です AWS クラウド。

これらの違いに対処する

これらの違いに対処するには、次のセクションで説明するステップに従って、人、プロセス、テクノロジーにわたるインシデント対応プログラムが適切に準備されていることを確認します。