クラウドにおけるデータ侵害への対応

クラウドにおけるデータ侵害への対応

クラウド環境におけるデータ侵害への対応は、証拠保全、インシデントの封じ込め、分散システムの復旧のために特有の手順を必要とする独自の課題を伴います。クラウドインフラの動的かつ一時的な性質（自動的に破棄され得る instances、短期間で失効するログ、上書きされる snapshots）は、フォレンジック上のアーティファクトが消失する前にそれらを取得するための即時の対応を要求します。サーバーを物理的に制御できる on-premises 環境とは異なり、クラウドでは、対応は Cloud Service Provider (CSP) の APIs、攻撃のタイムラインを再構築するための CloudTrail (AWS)、Activity Logs (Azure)、または Cloud Audit Logs (GCP) の分析、公開された S3 buckets、開放された security groups、過剰な権限を持つ IAM roles といった露出した構成の特定、データの保全と侵害されたリソースの隔離のための CSP サポートチームとの連携、侵害された可能性のある IAM 権限および access keys の詳細なレビュー、ならびに攻撃者の影響を受けていない不変の snapshots/backups からの復元に依存します。対応のスピードは、特に一分一秒が重要となるデータの exfiltration の事例において極めて重要であり、封じ込めと復旧のために自動化（IaC、Lambda functions、Azure Functions を介して）を用いる能力は、制御されたインシデントと、数千の顧客に影響を及ぼし大規模な通知に関する規制上の義務を生じさせる壊滅的な規模の侵害との分かれ目となり得ます。

Snapshots および Backups による迅速な封じ込め

クラウド侵害への対応の最初のステップは、証拠を破壊しかねない封じ込め措置を講じる前に、侵害された環境のフォレンジック上有効なコピーを確保することです。影響を受けたすべての EC2 instances/VMs、EBS ボリューム/ディスク、RDS/SQL Database データベース、および攻撃の証拠を含み得るその他のあらゆるストレージリソースの snapshots を直ちに作成してください。重要：これらの snapshots には特定の tags（incident-id、timestamp、"DO NOT DELETE"）を付与し、偶発的または自動的な削除を防ぐ保持ポリシーを構成してください。実行中の instances については、マシンをシャットダウンまたは隔離する前に、LiME (Linux) や FTK Imager (Windows) といったツールを SSM Session Manager (AWS) または Custom Script Extension (Azure) 経由で実行して memory dumps を作成することを検討してください。同時に、不変性を確保するために、CloudTrail/Activity Logs を MFA Delete および Bucket Lock で保護された別個の S3 bucket/Storage Account にエクスポートしてください——API 呼び出しのログはクラウドにおける悪意ある行為の唯一の記録であることが多く、保全されなければ上書きされたり速やかに失効したりする可能性があることを忘れないでください。初期の攻撃ベクトルを明らかにし得る VPC Flow Logs、DNS Query Logs、およびあらゆる WAF/Load Balancer ログのエクスポートも構成してください。推奨される手法は、これらのアーティファクトが自動的にコピーされる別個の "forensics account" または "security account" を用意し、本番環境の侵害された認証情報から隔離することです。

CloudTrail および Activity Logs の分析

CloudTrail (AWS)、Azure Activity Log、および GCP Cloud Audit Logs は、侵害の間に何が起きたのかを理解するための主要な信頼できる情報源です——これらは、誰が、どこから、いつ、どのようなパラメータで呼び出したかを含め、お客様のクラウドアカウントで行われたすべての API 呼び出しを記録します。AWS CloudTrail Lake、Azure Log Analytics、または Google Cloud Logging といったツールを用いて、疑わしいイベントを迅速にクエリしてください：新しい IAM ユーザーの作成、access keys の生成、security groups/NSGs への変更、許容的なファイアウォールルールの作成、bucket policies の変更、CreateSnapshot に続いて外部アカウントへの共有を行う exfiltration の試み、AttachUserPolicy または PutRolePolicy による権限昇格、ならびに通常とは異なる地理的リージョンでの侵害された認証情報の使用を探してください。人間のユーザーではなくサービス認証情報（service accounts、roles）で実行されたイベントには特に注意してください。これは侵害された instances を通じた横方向の移動を示している可能性があるためです。既知の悪意あるイベントから遡って追跡することで、"patient zero"——最初に侵害されたリソースまたは認証情報——を特定してください。S3 Server Access Logs または Database Audit Logs 経由で利用可能であれば、data plane のイベント（S3 オブジェクトへのアクセス、データベースの queries）も分析してください。CloudMapper、ScoutSuite、Prowler といったツールや、boto3 (AWS) または Azure SDK を用いたカスタム Python スクリプトは、数千のイベントの分析を自動化して異常を特定できます。後に規制報告および post-mortem 分析に使用できる形式で、タイムライン全体を文書化してください。

露出した構成の特定

クラウドにおけるデータ侵害は、高度な exploits ではなく misconfigurations に起因することが多くあります——機密データを含む公開設定の S3 buckets、インターネットからの SSH/RDP アクセスを許可する 0.0.0.0/0 ルールを持つ security groups、公開リポジトリにコミットされたソースコード内に hardcoded された secrets、コンテナの環境変数内のデータベース認証情報、公開共有されたディスクの snapshots、ならびに重要なリソースに対する完全な制御を付与する "*"（wildcard）権限を持つ IAM policies などです。Prisma Cloud、Wiz、Orca Security といった CSPM (Cloud Security Posture Management) ツール、または Prowler、ScoutSuite、CloudSploit といった open-source ツールを用いて直ちに scans を実行し、セキュリティの best practices に違反するすべての構成を特定してください。特に次の点に注力してください：public-read または public-read-write を持つ S3/Blob Storage buckets、0.0.0.0/0 を許可する ingress rules を持つ security groups/NSGs、管理者権限を付与する inline policies を持つ IAM ユーザー/service principals、EC2 user data または Lambda environment variables 内に露出した secrets、認証なしまたはデフォルト認証情報で露出したデータベース、ならびに攻撃者によって作成された可能性のある予期しないリージョン内のリソース。最も重大な露出は直ちに是正してください（機密データを含む公開 buckets は今すぐ非公開にすべきです）が、証拠の連鎖を保全するために、変更を加える前にすべてを文書化してください。攻撃者が、新しい IAM ユーザー、悪意ある Lambda functions、または再侵入を可能にする security group rules といった backdoors を作成した可能性があることを考慮してください——最近作成された、または攻撃の期間中に変更されたリソースを探してください。

Cloud Service Provider との連携

重大なインシデント、特に CSP 自身のインフラの侵害を伴い得るもの（極めて稀ではありますが）や、お客様が単独で実行できない措置（CDNs の背後にある真の送信元 IP の特定、すでに失効したログの保全、他の tenants における活動の調査など）を必要とするものについては、お客様の Cloud Service Provider のサポートに security incident case を起票すべきです。AWS、Azure、GCP には専門のインシデント対応チームがあり、次のことが可能です：お客様の tenant からすでに削除または失効したものの、CSP 内部の backups にはまだ存在するログおよびフォレンジックデータの保全、悪意ある活動に関連する送信元 IP および ASNs に関する情報の提供、侵害された認証情報が他の環境で使用されたかどうかの確認（他の顧客のプライバシーを侵害することなく）、subpoenas を介した法的手続きのための証拠保全の支援、そして極端な場合にはお客様のアカウントの完全な隔離または悪意あるリソースの takedowns の実施。AWS については、AWS Support Center を使用して severity "critical" の case を起票し "security incident" と記載してください——AWS Trust & Safety チームに接続されます。Azure には Security Response Center および正式な incident reporting プロセスがあります。GCP には Google Cloud Support を介した同様のプロセスがあります。重要：連絡する前に詳細な情報を準備してください——インシデントのタイムライン、影響を受けたリソース（instance IDs、ARNs、resource IDs）、侵害の証拠、ならびに CSP に求める具体的な措置。CSPs は shared responsibility model の下で運営されていることを忘れないでください——彼らはクラウド「の」セキュリティ（物理インフラ、hypervisor、グローバルネットワーク）に責任を負いますが、お客様はクラウド「における」セキュリティ（お客様のアプリケーション、データ、構成、IAM）に責任を負います。

侵害された IAM 権限のレビュー

封じ込め後の最初の措置の一つは、攻撃者がアクセス制御の変更を通じて persistence を確立した可能性があると想定したうえで、お客様のクラウドアカウントにおけるすべての IAM 権限、roles、policies、認証情報の完全な監査であるべきです。すべての IAM ユーザー、service accounts、roles を一覧化してください——それらがいつ作成されたか、最後の活動、および攻撃の期間中に作成されたものがあるかどうかを確認してください。すべての access keys、特に管理者アカウントに関連付けられたもの、またはログ内に疑わしい活動を示すものを直ちに rotate してください。AWS STS RevokeSessionsPolicy または他のクラウドにおける同等の手段を用いて、IAM roles のアクティブな sessions を失効させてください。各 principal にアタッチされた inline policies および managed policies を精査してください——最近追加された過剰な権限、特に Actions または Resources 内の wildcards (*) を探してください。外部アカウントがお客様の roles を引き受けることを許可するように変更されていないことを確認するため、IAM roles の assume role trust policies をレビューしてください。重要な S3 buckets では MFA delete を、機密性の高い管理操作には MFA を有効にしてください。侵害された管理者によってさえ特定の破壊的操作が行われることを防ぐため、AWS Organization レベルで SCPs (Service Control Policies) を実装してください。over-provisioned な権限および external access を特定するため、AWS IAM Access Analyzer、Azure AD Privileged Identity Management、または GCP Policy Analyzer を構成してください。least privilege の原則を厳格に採用してください——role/ユーザーが buckets の一覧表示のみを必要とする場合は、s3:* を付与せず、s3:ListBucket のみを付与してください。永続的な認証情報の代わりに、HashiCorp Boundary や AWS Systems Manager Session Manager といったツールによる just-in-time access の実装を検討してください。重要な環境については、すべての IAM が侵害されるという極端な事態に備え、オフラインの物理的 vault に保管された認証情報を用いる break-glass procedures を構成してください。