セキュリティ OU - Security Tooling アカウント - AWS 規範ガイダンス

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

セキュリティ OU - Security Tooling アカウント

セキュリティ AWS リファレンスアーキテクチャ (AWS SRA) の未来に影響を与えるには、簡単なアンケートに回答してください。

次の図は、Security Tooling アカウントで設定されている AWS セキュリティサービスを示しています。

Security Tooling アカウントのセキュリティサービス

Security Tooling アカウントは、セキュリティサービスの運用、AWS アカウントのモニタリング、セキュリティアラートと対応の自動化に専念しています。セキュリティの目的は以下の通りです。

  • セキュリティガードレール、モニタリング、対応へのアクセスを管理するための制御されたアクセスを専用アカウントに提供します。

  • セキュリティオペレーションデータをモニタリングし、トレーサビリティを維持するために、適切な一元化されたセキュリティインフラストラクチャを維持します。検出、調査、対応は、セキュリティライフサイクルの重要な部分であり、品質プロセス、法的義務またはコンプライアンス義務をサポートし、脅威の特定と対応の取り組みに使用することができます。

  • 暗号化キーやセキュリティグループ設定など、適切なセキュリティ設定とオペレーションを別のレイヤーで制御することで、a defense-in-depth 組織戦略をさらにサポートします。セキュリティオペレーターが作業するアカウントです。読み取りonly/audit roles to view AWS organization-wide information are typical, whereas write/modifyロールの数は限られており、厳密に制御、モニタリング、ログ記録されています。

設計上の考慮事項
  • AWS Control Tower は、デフォルトでセキュリティ OU の下にあるアカウントを監査アカウントに指定します。AWS Control Tower のセットアップ中にアカウントの名前を変更できます。

  • セキュリティツールアカウントを複数持つのが適切かもしれません。例えば、セキュリティイベントのモニタリングと対応は、多くの場合、専任チームに割り当てられています。ネットワークセキュリティは、クラウドインフラストラクチャやネットワークチームと協力して、独自のアカウントとロールを保証する場合があります。このような分割は、一元化されたセキュリティエンクレーブを分離するという目的を保持し、職務の分離、最小特権、およびチーム割り当ての単純化の可能性をさらに強調するものです。AWS Control Tower を使用している場合、セキュリティ OU で追加の AWS アカウントの作成が制限されます。

セキュリティサービスの委任管理者

Security Tooling アカウントは、AWS アカウント全体で管理者/メンバー構造で管理されるセキュリティサービスの管理者アカウントとして機能します。前述のように、これは AWS Organizations の委任された管理者機能を通じて処理されます。現在委任管理者をサポートしている SRA AWS 内のサービスには、AWS Config、AWS Firewall Manager、Amazon GuardDuty、AWS IAM Access Analyzer、Amazon Macie、AWS Security Hub、Amazon Detective、AWS Audit Manager、Amazon Inspector、 CloudTrailAWS、AWS Systems Manager などがあります。セキュリティチームがこれらのサービスのセキュリティ機能を管理し、セキュリティ固有のイベントや検出結果をモニタリングします。

IAM Identity Center は、メンバーアカウントへの委任管理をサポートしています。AWS SRA は、共有サービスアカウントの Word Identity Center セクションで後述するように、IAM IAM Identity Center の委任管理者アカウントとして共有サービスアカウントを使用します。

AWS CloudTrail

CloudTrailAWS は、AWS アカウントのアクティビティのガバナンス、コンプライアンス、監査をサポートするサービスです。 CloudTrail を使用すると、AWS インフラストラクチャ全体のアクションに関連するアカウントアクティビティをログに記録し、継続的にモニタリングし、保持できます。 CloudTrail は AWS Organizations と統合されており、その統合を使用して、AWS 組織内のすべてのアカウントのすべてのイベントをログに記録する単一の証跡を作成できます。これは、組織の証跡と呼ばれます。組織の証跡を作成および管理できるのは、組織の管理アカウント内または委任管理者アカウントからのみです。組織の証跡を作成すると、指定した名前の証跡が、AWS 組織に属するすべての AWS アカウントに作成されます。証跡は、AWS 組織内の管理アカウントを含むすべてのアカウントのアクティビティをログに記録し、ログを 1 つの S3 バケットに保存します。この S3 バケットは感度が高いため、このガイドの後半にあるAmazon S3「中央ログストア」セクションで説明されているベストプラクティスに従って保護する必要があります。AWS 組織内のすべてのアカウントは、証跡のリストで組織の証跡を表示できます。ただし、メンバー AWS アカウントには、この証跡への表示専用アクセス権があります。デフォルトでは、 CloudTrail コンソールで組織の証跡を作成する場合、証跡はマルチリージョンの証跡です。その他のセキュリティのベストプラクティスについては、 CloudTrail AWS ドキュメントを参照してください。

AWS SRA、Security Tooling アカウントは、 CloudTrail を管理するための委任管理者アカウントです。組織の証跡ログを保存する対応する S3 バケットは、ログアーカイブアカウントに作成されます。これは、 CloudTrail ログ権限の管理と使用を分離するためです。組織の証跡のログファイルを保存するために S3 バケットを作成または更新する方法については、 CloudTrail AWS ドキュメントを参照してください。

注記

組織の証跡は、管理アカウントと委任管理者アカウントの両方から作成および管理できます。ただし、ベストプラクティスとして、管理アカウントへのアクセスを制限し、利用可能な場合は委任管理者機能を使用する必要があります。

設計上の考慮事項
  • メンバーアカウントが自分のアカウントの CloudTrail ログファイルにアクセスする必要がある場合は、中央の S3 バケットから組織の CloudTrail ログファイルを選択的に共有できます。ただし、メンバーアカウントがアカウントの CloudWatch ログに local CloudTrail ロググループを必要とする場合、またはログ管理イベントとデータイベント (読み取り専用、書き込み専用、管理イベント、データイベント) を組織の証跡とは異なる方法で設定する場合は、適切なコントロールを使用してローカル証跡を作成できます。ローカルアカウント固有の証跡には追加料金が発生します。

AWS Security Hub

AWS Security Hub は、AWS のセキュリティ体制を包括的に把握し、セキュリティ業界標準とベストプラクティスに照らして環境をチェックするのに役立ちます。Security Hub は、AWS 統合サービス、サポートされているサードパーティー製品、および使用する可能性のあるその他のカスタムセキュリティ製品全体からセキュリティデータを収集します。セキュリティの傾向を継続的にモニタリング・分析し、特に優先度の高いセキュリティ問題を特定するのに役立ちます。取り込まれたソースに加えて、Security Hub は独自の検出結果を生成します。これは、1 つ以上のセキュリティ標準にマッピングされるセキュリティコントロールによって表されます。これらの標準には、AWS Foundational Security Best Practices (FSBP)、Center for Internet Security (CIS)、AWS Foundations Benchmark v1.20 および v1.4.0、米国国立標準技術研究所 (NIST) SP 800-53 Rev. 5、Payment Card Industry Data Security Standard (PCIDSS)、およびサービスマネージド標準が含まれます。現在のセキュリティ標準のリストと特定のセキュリティコントロールの詳細については、Security Hub ドキュメントの「Security Hub 標準リファレンス」を参照してください。

Security Hub は AWS Organizations と統合され、AWS 組織内のすべての既存および将来のアカウントにおけるセキュリティ体制の管理を簡素化します。委任管理者アカウント (この場合は Security Tooling) の Security Hub 中央設定機能を使用して、Security Hub サービス、セキュリティ標準、およびセキュリティコントロールを リージョン全体の組織アカウントと組織単位 (OUs) でどのように設定するかを指定できます。これらの設定は、ホームリージョンと呼ばれる 1 つのプライマリリージョンから数ステップで設定できます。中央設定を使用しない場合は、各アカウントとリージョンで個別に Security Hub を設定する必要があります。委任管理者は、アカウントと OUs をセルフマネージド型として指定できます。この場合、メンバーはリージョンごとに個別に設定するか、一元管理型として指定できます。委任管理者はリージョン間でメンバーアカウントまたは OU を設定できます。組織内のすべてのアカウントと OUs を、一元管理型、すべてセルフマネージド型、またはその両方の組み合わせとして指定できます。これにより、OU とアカウントごとに変更できる柔軟性を提供しながら、一貫した設定を簡単に適用できます。

Security Hub の委任管理者アカウントは、すべてのメンバーアカウントから調査結果の表示、インサイトの表示、および詳細の制御を行うこともできます。さらに、委任された管理者アカウント内で集約リージョンを指定して、アカウントとリンクされたリージョン全体で検出結果を一元化することもできます。検出結果は、アグリゲータリージョンと他のすべてのリージョン間で継続的かつ双方向に同期されます。

Security Hub は、複数の AWS サービスとの統合をサポートしています。Amazon GuardDuty、AWS Config、Amazon Macie、AWS IAM Access Analyzer、AWS Firewall Manager、Amazon Inspector、AWS Systems Manager Patch Manager は、結果を Security Hub にフィードできます。Security Hub は、Word Security Finding Format (AWSASFF) と呼ばれる標準形式を使用して検出結果を処理します。Security Hub は、結果を統合された製品全体と関連づけて、最も重要なものに優先順位を付けます。Security Hub の検出結果のメタデータを強化して、セキュリティの検出結果のコンテキスト化、優先順位付け、およびアクションの実行を強化できます。このエンリッチメントは、Security Hub に取り込まれるすべての検出結果に、リソースタグ、新しい AWS アプリケーションタグ、およびアカウント名情報を追加します。これにより、自動化ルールの検出結果を微調整し、検出結果とインサイトを検索またはフィルタリングし、アプリケーションごとにセキュリティ体制のステータスを評価できます。さらに、自動化ルールを使用して検出結果を自動的に更新できます。Security Hub が検出結果を取り込み、検出結果の抑制、重要度の変更、検出結果へのメモの追加など、さまざまなルールアクションを適用できます。これらのルールアクションは、検出結果が、検出結果が関連付けられているリソースまたはアカウント IDs、またはそのタイトルなど、指定した基準に一致する場合に有効になります。自動化ルールを使用して、ASFF 内の選択した検出結果フィールドを更新できます。ルールは、新しい検出結果と更新された検出結果の両方に適用されます。

セキュリティイベントの調査中に、Security Hub から Amazon Detective に移動して Amazon GuardDuty の検出結果を調査できます。Security Hub では、Detective (存在する場合) などのサービスの委任管理者アカウントを調整して、よりスムーズに統合することをお勧めします。例えば、Detective と Security Hub の間で管理者アカウントを整列させない場合、検出結果から Detective に移動することはできません。包括的なリストについては、Security Hub ドキュメントの「Security Hub との AWS サービス統合の概要」を参照してください。

Amazon VPC の Network Access Analyzer 機能で Security Hub を使用すると、AWS ネットワーク設定のコンプライアンスを継続的にモニタリングできます。これにより、不要なネットワークアクセスをブロックし、重要なリソースの外部アクセスを防ぐことができます。アーキテクチャと実装の詳細については、Word ブログ記事「Amazon AWS Network Access Analyzer と VPC AWS Security Hub を使用したネットワークコンプライアンスの継続的な検証」を参照してください。

Security Hub は、モニタリング機能に加えて、Amazon EventBridge との統合をサポートし、特定の検出結果の修復を自動化します。結果を受け取ったときに実行するカスタムアクションを定義できます。たとえば、チケット発行システムや自動修復システムに結果を送信するなどのカスタムアクションを設定できます。その他の議論や例については、AWS ブログ記事「Automated Response and Remediation with AWS Security Hub」および「How to deploy the AWS Solution for Security Hub Automated Response and Remediation」を参照してください。

Security Hub は、サービスにリンクされた AWS Config ルールを使用して、コントロールのセキュリティチェックのほとんどを実行します。これらのコントロールをサポートするには、Security Hub が有効になっている各 AWS リージョンで、管理者 (または委任管理者) アカウントとメンバーアカウントを含むすべてのアカウントで Word Config を有効にする必要があります。 AWS

設計上の考慮事項
  • PCI-DSS などのコンプライアンス標準が Security Hub にすでに存在する場合、フルマネージド Security Hub サービスは、それを運用する最も簡単な方法です。ただし、セキュリティ、運用、コスト最適化チェックなど、独自のコンプライアンスまたはセキュリティ標準をアセンブルする場合、AWS Config コンフォーマンスパックは簡略化されたカスタマイズプロセスを提供します。(AWS Config とコンフォーマンスパックの詳細については、AWS Config セクションを参照してください。)

  • Security Hub の一般的なユースケースは次のとおりです。

    • AWS リソースのセキュリティとコンプライアンス体制をアプリケーション所有者に可視化するダッシュボードとして

    • セキュリティオペレーション、インシデント対応担当者、脅威ハンターが使用するセキュリティ検出結果を一元的に把握し、AWS アカウントとリージョン全体の AWS セキュリティとコンプライアンスの検出結果を優先順位付けしてアクションを実行します。

    • AWS アカウントとリージョンをまたいでセキュリティとコンプライアンスに関する結果を集約し、一元化されたセキュリティ情報とイベント管理 (SIEM) またはその他のセキュリティオーケストレーションシステムに送信するには

    これらのユースケースのセットアップ方法など、これらのユースケースに関する追加のガイダンスについては、ブログ記事「Security Hub の 3 つの繰り返しの使用パターンとデプロイ方法」を参照してください。

実装例

AWS SRAコードライブラリは、Security Hub のサンプル実装を提供します。これには、サービスの自動有効化、メンバーアカウントへの委任管理 (Security Tooling)、AWS 組織内のすべての既存および将来のアカウントに対して Security Hub を有効にするための設定が含まれます。

Amazon GuardDuty

Amazon GuardDuty は、AWS アカウントとワークロードを保護するために、悪意のあるアクティビティや不正な動作を継続的にモニタリングする脅威検出サービスです。モニタリングおよび監査の目的では常に適切なログをキャプチャして保存する必要がありますが、Amazon GuardDuty は CloudTrailAWS、Amazon VPC フローログ、および AWS DNSから直接独立したデータストリームを取得します。Amazon S3 バケットポリシーを管理したり、ログの収集と保存方法を変更したりする必要はありません。 GuardDuty アクセス許可は、サービスにリンクされたロールとして管理され、 GuardDuty を無効にすることでいつでも取り消すことができます。これにより、複雑な設定なしでサービスを簡単に有効にでき、IAM アクセス許可の変更や S3 バケットポリシーの変更がサービスのオペレーションに影響を与えるリスクがなくなります。

GuardDuty には、基本的なデータソースの提供に加えて、セキュリティ上の検出結果を特定するためのオプション機能が用意されています。これには、EKS Protection、RDS Protection、S3 Protection、Malware Protection、Lambda Protection が含まれます。新しいディテクターの場合、これらのオプション機能は、手動で有効にする必要がある EKS Protection を除き、デフォルトで有効になっています。

  • GuardDuty S3 Protection では、 GuardDuty は default CloudTrail 管理イベントに加えて、Amazon S3 データイベントを in CloudTrail でモニタリングします。データイベントをモニタリングすることで、 GuardDuty は S3 バケット内のデータに対する潜在的なセキュリティリスクについて、オブジェクトレベルの API オペレーションをモニタリングできます。

  • GuardDuty Malware Protection は、アタッチされた Amazon Elastic Block Store (Amazon EC2) ボリュームでエージェントレススキャンを開始することで、Amazon EBS インスタンスまたはコンテナワークロードにマルウェアが存在することを検出します。

  • RDS GuardDuty Protection は、データベースのパフォーマンスに影響を与えることなく、Amazon Aurora データベースへのアクセスアクティビティをプロファイリングおよびモニタリングするように設計されています。

  • EKS GuardDuty Protection には、EKS 監査ログのモニタリングと EKS Runtime Monitoring が含まれます。EKS Audit Log Monitoring を使用すると、 GuardDuty は Amazon EKS クラスターからの Kubernetes 監査ログをモニタリングし、潜在的に悪意のあるアクティビティや疑わしいアクティビティがないか分析します。EKS Runtime Monitoring は、 GuardDuty セキュリティエージェント (Amazon EKS アドオン) を使用して、個々の Amazon EKS ワークロードをランタイムで可視化します。 GuardDuty セキュリティエージェントは、Amazon EKS クラスター内で侵害されている可能性のある特定のコンテナを識別するのに役立ちます。また、個々のコンテナから基盤となる Amazon EC2 ホストまたはより広範な AWS 環境に権限をエスカレートしようとする試みを検出することもできます。

GuardDuty は AWS Organizations を通じてすべてのアカウントで有効になり、すべての検出結果は GuardDuty 委任管理者アカウント (この場合は Security Tooling アカウント) の適切なセキュリティチームによって表示および実行できます。 

AWS Security Hub が有効になっている場合、 GuardDuty の検出結果は自動的に Security Hub に流れます。Amazon Detective を有効にすると、 GuardDuty の検出結果が Detective ログ取り込みプロセスに含まれます。 GuardDuty と Detective はクロスサービスユーザーワークフローをサポートします。ここで、 GuardDuty は、選択した検出結果から、その検出結果を調査するための厳選された視覚化セットを含む Detective ページにリダイレクトするコンソールからのリンクを提供します。例えば、 GuardDuty を Amazon EventBridge と統合して、new GuardDuty の検出結果への応答を自動化するなど、Word のベストプラクティスを自動化することもできます。 GuardDuty

実装例

AWS SRAコードライブラリは、Amazon GuardDuty の実装例を提供します。これには、暗号化された S3 バケット設定、委任された管理、 GuardDuty 組織内のすべての既存および将来のアカウントに対する AWS 有効化が含まれます。

AWS設定

AWS Config は、Word AWSアカウントでサポートされている AWS リソースの設定を評価、監査、評価できるサービスです。AWS Config は AWS リソース設定を継続的にモニタリングして記録し、記録された設定を目的の設定と照合して自動的に評価します。また、AWS Config を他の サービスと統合して、自動監査およびモニタリングパイプラインで手間のかかる作業を行うこともできます。例えば、AWS Config は AWS Secrets Manager で個々のシークレットの変更をモニタリングできます。 

AWS Config ルールを使用して、AWS リソースの設定を評価できます。AWS Config には、マネージドルールと呼ばれるカスタマイズ可能な事前定義されたルールのライブラリが用意されています。または、独自のカスタムルールを作成することもできます。AWS Config ルールは、プロアクティブモード (リソースのデプロイ前) または検出モード (リソースのデプロイ後) で実行できます。リソースは、設定変更時、定期的、あるいはその両方で評価できます。

コンフォーマンスパックは、アカウントとリージョン、または AWS Organizations の組織全体に単一のエンティティとしてデプロイできる AWS Config ルールと修復アクションのコレクションです。コンフォーマンスパックは、YAML Config マネージドルールまたはカスタムルールと修復アクションのリストを含む AWS テンプレートを作成することによって作成されます。AWS 環境の評価を開始するには、サンプルのコンフォーマンスパックテンプレートのいずれかを使用します。 

AWS Config は AWS Security Hub と統合され、AWS Config マネージドルールとカスタムルールの評価の結果を Security Hub の結果として送信します。 

AWS Config ルールを AWS Systems Manager と組み合わせて使用すると、非準拠のリソースを効果的に修正できます。AWS Systems Manager Explorer を使用して、AWS リージョン全体で AWS アカウントの AWS Config ルールのコンプライアンスステータスを収集し、Systems Manager Automation ドキュメント (ランブック) を使用して、非準拠の AWS Config ルールを解決します。実装の詳細については、ブログ記事AWS Systems Manager Automation ランブックを使用して非準拠の AWS Config ルールを修正する」を参照してください。

AWS Config アグリゲータは、AWS Organizations の複数のアカウント、リージョン、および組織にわたって設定およびコンプライアンスデータを収集します。アグリゲータダッシュボードには、集約されたリソースの設定データが表示されます。インベントリおよびコンプライアンスダッシュボードには、AWS アカウント間、Word AWSリージョン間、または AWS 組織内の AWS リソース設定とコンプライアンスステータスに関する重要かつ最新の情報が表示されます。これにより、AWS Config の高度なクエリを記述しなくても、AWS リソースインベントリを視覚化して評価できます。リソース別のコンプライアンスの概要、非準拠リソースを持つ上位 10 のアカウント、タイプ別の実行中と停止中の EC2 インスタンスの比較、ボリュームタイプとサイズ別の EBS ボリュームなど、重要なインサイトを得ることができます。

AWS Control Tower を使用して AWS 組織を管理する場合、一連の AWS Config ルールが検出ガードレールとしてデプロイされます (必須、強く推奨、または選択的に分類されます)。これらのガードレールは、リソースを管理し、AWS 組織内のアカウント全体のコンプライアンスをモニタリングするのに役立ちます。これらの AWS Config ルールは、 の値を持つaws-control-towerタグを自動的に使用しますmanaged-by-control-tower

AWS Config は、保護するリソースを含む AWS 組織と AWS リージョンのメンバーアカウントごとに有効にする必要があります。AWS 組織内のすべてのアカウントで、AWS Config ルールを一元管理 (作成、更新、削除など) できます。AWS Config 委任管理者アカウントから、すべてのアカウントに共通の一連の AWS Config ルールをデプロイし、AWS Config ルールを作成すべきではないアカウントを指定できます。AWS Config 委任管理者アカウントは、すべてのメンバーアカウントのリソース設定とコンプライアンスデータを集約して、単一のビューを提供することもできます。委任管理者アカウントの APIs を使用して、Word AWS組織のメンバーアカウントが基盤となる AWS Config ルールを変更できないようにすることで、ガバナンスを適用します。

設計上の考慮事項
  • AWS Config は、設定とコンプライアンス変更の通知を Amazon EventBridge にストリーミングします。つまり、 EventBridge のネイティブフィルタリング機能を使用して AWS Config イベントをフィルタリングし、特定のタイプの通知を特定のターゲットにルーティングできます。例えば、特定のルールまたはリソースタイプのコンプライアンス通知を特定の E メールアドレスに送信したり、設定変更通知を外部の IT サービス管理 (ITSM) または設定管理データベース (CMDB) ツールにルーティングしたりできます。詳細については、ブログ記事AWS Config のベストプラクティス」を参照してください。 

  • AWS Config プロアクティブルール評価の使用に加えて、AWS CloudFormation Guard を使用できます。これは、リソース設定のコンプライアンスをプロアクティブにチェックする policy-as-code 評価ツールです。 CloudFormation AWS Guard コマンドラインインターフェイス (CLI) には、ポリシーをコードとして表現するために使用できる宣言型ドメイン固有の言語 (DSL) が用意されています。さらに、AWS コマンドを使用して、CLI 変更セット、JSON ベースの Terraform 設定ファイル、Kubernetes 設定などの CloudFormation 形式または JSON YAML形式の構造化データを検証できます。Word Guard CloudFormation AWS をオーサリングプロセスCLIの一部として使用して評価をローカルで実行することも、デプロイパイプライン内で実行することもできます。AWS Cloud Development Kit (AWS CDK) アプリケーションがある場合は、cdk-nag を使用してベストプラクティスをプロアクティブにチェックできます。

実装例

AWS SRAライブラリは、AWS Config コンフォーマンスパックを Word AWS組織内のすべての AWS アカウントとリージョンにデプロイするサンプル実装を提供します。AWS Config アグリゲータモジュールは、組織管理アカウント内のメンバーアカウント (セキュリティツール) に管理を委任し、AWS 組織内のすべての既存および将来のアカウントのために委任された管理者アカウント内で Word Config アグリゲータを設定することで、AWS Config AWSアグリゲータを設定するのに役立ちます。AWS Config Control Tower 管理アカウントモジュールを使用して、組織管理アカウント内で AWSAWS Config を有効にできます。Word Control Tower では有効になりません。

Amazon Security Lake

Amazon Security Lake は、フルマネージド型のセキュリティデータレイクサービスです。Security Lake を使用して、AWS 環境、Software as a Service (SaaS) プロバイダー、オンプレミス、およびサードパーティーソースのセキュリティデータを自動的に一元化できます。Security Lake は、セキュリティデータに対する分析ツールの使用を簡素化する正規化されたデータソースを構築するため、組織全体のセキュリティ体制をより完全に理解できます。データレイクは、Amazon Simple Storage Service (Amazon S3) バケットに支えられており、データの所有権はお客様が保持します。Security Lake は、AWS、Amazon AWS CloudTrail、Amazon Route 53VPC、Amazon S3、AWS Lambda、Amazon EKS 監査ログなど、Word サービスのログを自動的に収集します。

AWS SRA、Security Lake の委任管理者アカウントとしてログアーカイブアカウントを使用することをお勧めします。委任管理者アカウントの設定の詳細については、「セキュリティ OU – ログアーカイブアカウント」セクションの「Amazon Security Lake」を参照してください。 Security Lake データにアクセスしたい、またはカスタム抽出、変換、ロード (ETL) 関数を使用して Security Lake バケットに非ネイティブログを書き込む機能を必要とするセキュリティチームは、Security Tooling アカウント内で動作する必要があります。

Security Lake は、さまざまなクラウドプロバイダーからのログ、サードパーティーソリューションからのログ、またはその他のカスタムログを収集できます。Security Tooling アカウントを使用して ETL 関数を実行し、ログを Open Cybersecurity Schema Framework (OCSF) 形式に変換し、Apache Parquet 形式でファイルを出力することをお勧めします。Security Lake は、Security Tooling アカウントと、Security Lake の S3 バケットにデータを書き込むために AWS Lambda 関数または AWS Glue クローラによってバックアップされたカスタムソースに適切なアクセス許可を持つクロスアカウントロールを作成します。

Security Lake 管理者は、Security Tooling アカウントを使用し、Security Lake がサブスクライバーとして収集するログへのアクセスを要求するセキュリティチームを設定する必要があります。Security Lake は、2 種類のサブスクライバーをサポートしています。

  • データアクセス – サブスクライバーは Security Lake の Amazon S3 オブジェクトに直接アクセスできます。Security Lake はインフラストラクチャとアクセス許可を管理します。Security Tooling アカウントを Security Lake データアクセスサブスクライバーとして設定すると、アカウントは Amazon Simple Queue Service (Amazon SQS) を介して Security Lake バケット内の新しいオブジェクトの通知を受け取り、Security Lake はそれらの新しいオブジェクトにアクセスするためのアクセス許可を作成します。

  • クエリアクセス — サブスクライバーは、Amazon Athena などのサービスを使用して、S3 バケット内の AWS Lake Formation テーブルからソースデータをクエリできます。クロスアカウントアクセスは、AWS Lake Formation を使用してクエリアクセス用に自動的に設定されます。Security Tooling アカウントを Security Lake クエリアクセスサブスクライバーとして設定すると、そのアカウントには Security Lake アカウントのログへの読み取り専用アクセスが付与されます。このサブスクライバータイプを使用すると、Athena テーブルと AWS Glue テーブルは、Security Lake Log Archive アカウントから AWS Resource Access Manager (AWS RAM) を介して Security Tooling アカウントと共有されます。この機能を有効にするには、クロスアカウントデータ共有設定をバージョン 3 に更新する必要があります。

サブスクライバーの作成の詳細については、Security Lake ドキュメントの「サブスクライバー管理」を参照してください。

カスタムソースを取り込むためのベストプラクティスについては、Security Lake ドキュメントの「カスタムソースからデータを収集する」を参照してください。

Amazon QuickSightAmazon OpenSearch、および Amazon SageMaker を使用して、Security Lake に保存するセキュリティデータに対する分析を設定できます。

設計上の考慮事項

アプリケーションチームがビジネス要件を満たすために Security Lake データへのクエリアクセスを必要とする場合、Security Lake 管理者はそのアプリケーションアカウントをサブスクライバーとして設定する必要があります。

Amazon Macie

Amazon Macie は、フルマネージド型のデータセキュリティおよびデータプライバシーサービスであり、機械学習とパターンマッチングを使用して AWS 内の機密データを検出し、保護します。ワークロードが処理しているデータの種類と分類を特定して、適切なコントロールが確実に適用されるようにする必要があります。Macie を使用して、機密データの検出とレポートを自動化するには、機密データの自動検出を実行する方法と、機密データ検出ジョブを作成して実行する方法の 2 つの方法があります。機密データの自動検出により、Macie は S3 バケットインベントリを毎日評価し、サンプリング手法を使用してバケットから代表的な S3 オブジェクトを識別して選択します。その後、Macie は選択したオブジェクトを取得して分析し、機密データがないか検査します。機密データ検出ジョブは、より深く、より的を絞った分析を提供します。このオプションでは、分析する S3 バケット、サンプリング深度、S3 オブジェクトのプロパティから派生するカスタム基準など、分析の幅と深さを定義します。Macie がバケットのセキュリティまたはプライバシーに関する潜在的な問題を検出すると、ユーザー用に ポリシーの調査結果を作成します。自動データ検出は、すべての Macie の新規のお客様に対してデフォルトで有効になっており、既存の Macie のお客様はワンクリックで有効にできます。

Macie は AWS Organizations を通じてすべてのアカウントで有効になっています。委任された管理者アカウント (この場合は Security Tooling アカウント) で適切なアクセス許可を持つプリンシパルは、どのアカウントでも Macie を有効にしたり停止にしたり、メンバーアカウントが所有するバケットに対して機密データ検出ジョブを作成したり、すべてのメンバーアカウントのすべてのポリシー結果を表示したりすることができます。機密データの結果は、機密結果ジョブを作成したアカウントでのみ表示できます。詳細については、Macie のドキュメントの「Amazon Macie で複数アカウントを管理する」を参照してください。

Macie の検出結果は AWS Security Hub に流れ、レビューと分析が行われます。Macie は Amazon EventBridge とも統合されており、アラート、セキュリティ情報とイベント管理 (SIEM) システムへのフィード、自動修復などの検出結果への自動応答が容易になります。

設計上の考慮事項
  • S3 オブジェクトが管理する AWS Key Management Service (AWS KMS) キーで暗号化されている場合、Macie のサービスにリンクされたロールをキーユーザーとしてその KMS キーに追加して、Macie がデータをスキャンできるようにします。

  • Macie は Amazon S3 内のオブジェクトのスキャンに最適化されています。その結果、Amazon S3 に (永続的または一時的に) 配置できる Macie がサポートするオブジェクトタイプ は、機密データをスキャンできます。つまり、Amazon Amazon Relational Database Service (Amazon RDS) や Amazon Aurora データベースの定期的なスナップショットエクスポートエクスポートされた Amazon DynamoDB テーブル、ネイティブアプリケーションやサードパーティーアプリケーションから抽出されたテキストファイルなど、他のソースからのデータは Amazon S3 に移動して Macie によって評価できます。

実装例

AWS SRAコードライブラリは、Amazon Macie のサンプル実装を提供します。これには、メンバーアカウントに管理を委任し、AWS 組織内のすべての既存アカウントと将来のアカウントの委任管理者アカウント内で Macie を設定することが含まれます。Macie は、AWS KMSカスタマーマネージドキーで暗号化された中央 S3 バケットに結果を送信するようにも設定されています。

AWS IAM Access Analyzer

AWS Cloud の導入ジャーニーを加速し、イノベーションを続けるには、きめ細かなアクセス (アクセス許可) を厳しく制御し、アクセスの拡散を抑え、アクセス許可を効果的に使用することが重要です。過剰で未使用のアクセスはセキュリティ上の課題となり、企業が最小特権の原則を適用するのが困難になります。この原則は、セキュリティ要件と運用上およびアプリケーション開発上の要件のバランスをとるために IAM のアクセス許可を継続的に適切なサイジングすることを含む、重要なセキュリティアーキテクチャの柱です。この取り組みには、中央セキュリティチームや Cloud Center of Excellence (CCoE) チーム、分散型開発チームなど、複数の利害関係者のペルソナが含まれます。

AWS IAM Access Analyzer には、エンタープライズのセキュリティ基準を満たすために未使用のアクセスを削除することで、きめ細かなアクセス許可を効率的に設定し、意図したアクセス許可を検証し、アクセス許可を絞り込むためのツールが用意されています。ダッシュボードと Word Security Hub を通じて、外部および未使用のアクセスの検出結果を可視化できます。 AWS さらに、イベントベースのカスタム通知および修復ワークフローのために Amazon EventBridge をサポートしています。

IAM Access Analyzer の外部検出結果機能は、外部エンティティと共有されている Amazon S3 バケットや IAM ロールなど、AWS 組織およびアカウントのリソースを識別するのに役立ちます。選択した AWS 組織またはアカウントは、信頼ゾーンと呼ばれます。アナライザーは自動推論を使用して、信頼ゾーン内のサポートされているすべてのリソースを分析し、信頼ゾーン外からリソースにアクセスできるプリンシパルの結果を生成します。これらの検出結果は、外部エンティティと共有されているリソースを特定し、リソース許可をデプロイする前に、ポリシーがリソースへのパブリックアクセスとクロスアカウントアクセスにどのように影響するかをプレビューするのに役立ちます。

IAM Access Analyzer の検出結果は、AWS 組織およびアカウントで付与された未使用のアクセスを特定するのにも役立ちます。

  • 未使用の IAM ロール – 指定された使用期間内にアクセスアクティビティがないロール。

  • 未使用の IAM ユーザー、認証情報、アクセスキー – IAM ユーザーに属する認証情報で、AWS のサービスとリソースへのアクセスに使用されます。

  • 未使用の IAM ポリシーとアクセス許可 – 指定された使用ウィンドウ内でロールによって使用されなかったサービスレベルおよびアクションレベルのアクセス許可。IAM Access Analyzer は、ロールにアタッチされたアイデンティティベースのポリシーを使用して、それらのロールがアクセスできるサービスとアクションを決定します。アナライザーは、すべてのサービスレベルのアクセス許可について、未使用のアクセス許可を確認します。

IAM Access Analyzer から生成された結果を使用して、組織のポリシーとセキュリティ標準に基づいて、意図しないアクセスや未使用のアクセスを可視化し、修正できます。修復後、これらの検出結果は次にアナライザーが実行されるときに解決済みとしてマークされます。検出結果が意図的なものである場合は、IAM Access Analyzer にアーカイブ済みとしてマークし、セキュリティリスクが大きい他の検出結果に優先順位を付けることができます。さらに、アーカイブルールを設定して、特定の検出結果を自動的にアーカイブできます。例えば、定期的にアクセスを許可する特定の Amazon S3 バケットに関する検出結果を自動的にアーカイブするためのアーカイブルールを作成できます。

ビルダーは、IAM Access Analyzer を使用して、開発とデプロイ (IAM パイプライン) の早い段階で自動化された Word ポリシーチェックを実行できます。CI/CD) process to adhere to your corporate security standards. You can integrate IAM Access Analyzer custom policy checks and policy reviews with AWS CloudFormation to automate policy reviews as a part of your development team’s CI/CDこれには、以下が含まれます。

  • IAM ポリシーの検証 — IAM Access Analyzer は、IAM ポリシーの文法と Word のベストプラクティスに照らしてポリシーを検証します。 AWS セキュリティ警告、エラー、一般的な警告、ポリシーの提案など、ポリシー検証チェックの結果を表示できます。現在、100 を超えるポリシー検証チェックが利用可能で、AWS コマンドラインインターフェイス (AWS) と CLI を使用して自動化できますAPIs。

  • IAM カスタムポリシーチェック — IAM Access Analyzer カスタムポリシーチェックは、指定したセキュリティ標準に照らしてポリシーを検証します。カスタムポリシーチェックでは、自動推論を使用して、企業のセキュリティ基準を満たすためのより高いレベルの保証を提供します。カスタムポリシーチェックのタイプは次のとおりです。

    • 参照ポリシーと照合する: ポリシーを編集するときに、ポリシーの既存のバージョンなどの参照ポリシーと比較して、更新によって新しいアクセスが付与されるかどうかを確認できます。CheckNoNewAccess API は 2 つのポリシー (更新されたポリシーと参照ポリシー) を比較して、更新されたポリシーが参照ポリシーに新しいアクセスを導入するかどうかを判断し、合格または不合格のレスポンスを返します。

    • IAM アクションのリストと照合する: CheckAccessNotGranted を使用してAPI、ポリシーがセキュリティ標準で定義されている重要なアクションのリストへのアクセスを許可しないようにすることができます。このAPIは、ポリシーと最大 100 の IAM アクションのリストを取得して、ポリシーが少なくとも 1 つのアクションを許可しているかどうかを確認し、合格または不合格のレスポンスを返します。

セキュリティチームやその他の IAM ポリシーの作成者は、IAM Access Analyzer を使用して、IAM ポリシーの文法とセキュリティ標準に準拠したポリシーを作成できます。適切なサイズのポリシーを手動で作成すると、エラーが発生しやすくなり、時間がかかります。IAM Access Analyzer ポリシー生成機能は、プリンシパルのアクセスアクティビティに基づく IAM ポリシーの作成に役立ちます。IAM Access Analyzer は、サポートされているサービスの AWS CloudTrail ログを確認し、指定された日付範囲でプリンシパルが使用したアクセス許可を含むポリシーテンプレートを生成します。その後、このテンプレートを使用して、必要なアクセス許可のみを付与するきめ細かなアクセス許可を持つポリシーを作成できます。

  • アクセスアクティビティに基づいてポリシーを生成するには、アカウントで CloudTrail 証跡が有効になっている必要があります。

  • IAM Access Analyzer は、生成されたポリシーで Amazon S3 データイベントなどのデータイベントのアクションレベルのアクティビティを識別しません。

  • iam:PassRole アクションは CloudTrail によって追跡されず、生成されたポリシーには含まれません。

Access Analyzer は、AWS Organizations の委任管理者機能を通じて Security Tooling アカウントにデプロイされます。委任された管理者は、AWS 組織を信頼ゾーンとして持つアナライザーを作成および管理するためのアクセス許可を持っています。

設計上の考慮事項
  • アカウントスコープの結果 (アカウントが信頼境界として機能する場所) を取得するには、各メンバーアカウントにアカウントスコープのアナライザーを作成します。これは、アカウントパイプラインの一部として実行できます。アカウントスコープの結果は、メンバーアカウントレベルで Security Hub に流れ込みます。そこから、Security Hub の委任管理者アカウント (Security Tooling) に流れます。

実装例
  • AWS SRAライブラリは、IAM Access Analyzer のサンプル実装を提供します。委任管理者アカウント内で組織レベルのアナライザーを設定し、各アカウント内でアカウントレベルのアナライザーを設定する方法を示します。

  • カスタムポリシーチェックをビルダーワークフローに統合する方法については、AWS ブログ記事「Introducing IAM Access Analyzer custom policy checks」を参照してください。

AWS Firewall Manager

AWS Firewall Manager はWAF、複数のアカウントとリソースにわたる AWS、AWS Shield Advanced、Amazon VPC セキュリティグループ、AWS Network Firewall、Route 53 Resolver DNS Firewall の管理およびメンテナンスタスクを簡素化することで、ネットワークを保護するのに役立ちます。Firewall Manager では、AWS WAF ファイアウォールルール、Shield Advanced 保護、Amazon VPC セキュリティグループ、AWS Network Firewall ファイアウォール、および DNS Firewall ルールグループの関連付けを 1 回だけセットアップします。ルールと保護が既存のアカウントとリソースに (追加する新しいリソースにも) 自動的に適用されます。

Firewall Manager は、少数の特定のアカウントやリソースではなく、AWS 組織全体を保護する場合や、保護する新しいリソースを頻繁に追加する場合に特に便利です。Firewall Manager は、セキュリティポリシーを使用して、デプロイする必要がある関連するルール、保護、アクション、および含めるか除外するアカウントとリソース (タグで示される) を含む、一連の設定を定義できます。きめ細かな柔軟な設定を作成しながら、多数のアカウントや VPCs に制御をスケールアウトできます。これらのポリシーは、新しいアカウントとリソースが作成された場合でも、設定したルールを自動的かつ一貫して適用します。Firewall Manager は AWS Organizations を通じてすべてのアカウントで有効になり、設定と管理は Firewall Manager の委任管理者アカウント (この場合は Security Tooling アカウント) の適切なセキュリティチームによって実行されます。 

保護するリソースを含む AWS リージョンごとに AWS Config を有効にする必要があります。すべてのリソースに対して AWS Config を有効にしない場合は、使用する Firewall Manager ポリシーのタイプに関連付けられているリソースに対して有効にする必要があります。AWS Security Hub と Firewall Manager の両方を使用すると、Firewall Manager は自動的に結果を Security Hub に送信します。Firewall Manager は、コンプライアンス違反のリソースと検出した攻撃に対しての結果を作成し、Security Hub に送信します。AWS 用の Firewall Manager ポリシーを設定するとWAF、対象範囲内のすべてのアカウントについてウェブアクセスコントロールリスト (ウェブACLs) へのログ記録を一元的に有効にし、ログを 1 つのアカウントで一元化できます。 

設計上の考慮事項
  • AWS 組織内の個々のメンバーアカウントのアカウントマネージャーは、特定のニーズに合わせて Firewall Manager マネージドサービスで追加のコントロール (AWS WAF ルールや Amazon VPC セキュリティグループなど) を設定できます。

実装例

AWS SRAコードライブラリは、AWS Firewall Manager のサンプル実装を提供します。委任管理 (Security Tooling) のデモ、最大許容セキュリティグループのデプロイ、セキュリティグループポリシーの設定、複数の WAF ポリシーの設定を行います。

Amazon EventBridge

Amazon EventBridge は、アプリケーションをさまざまなソースのデータに簡単に接続できるようにするサーバーレスイベントバスサービスです。セキュリティオートメーションによく使用されます。お客様は、データの送信先を判断するためのルーティングルールを設定して、すべてのデータソースにリアルタイムで反応するアプリケーションアーキテクチャを構築できます。各アカウントでデフォルトのイベントバスを使用するだけでなく、カスタムアプリケーションからイベントを受信するためにカスタムイベントバスを作成することができます。Security Tooling アカウントでイベントバスを作成し、AWS 組織内の他のアカウントからセキュリティ固有のイベントを受信できます。例えば、AWS Config ルール、 GuardDuty、Security Hub を EventBridge にリンクすることで、セキュリティデータのルーティング、アラートの発行、問題解決のためのアクションの管理のための柔軟で自動化されたパイプラインを作成できます。 

設計上の考慮事項
  • EventBridge は、さまざまなターゲットにイベントをルーティングできます。セキュリティアクションを自動化するための重要なパターンの 1 つは、特定のイベントを個々の AWS Lambda 応答者に接続して、適切なアクションを実行することです。例えば、特定の状況では、 EventBridge を使用して、バケットポリシーを修正し、パブリックアクセス許可を削除する Lambda レスポンダーにパブリック S3 バケットの検出結果をルーティングできます。これらのレスポンダーは、調査プレイブックとランブックに統合して、対応アクティビティを調整できます。

  • セキュリティ運用チームが成功するためのベストプラクティスは、セキュリティイベントと検出結果のフローを、チケットシステム、バグ/問題システム、または別のセキュリティ情報とイベント管理 (SIEM) システムなどの通知およびワークフローシステムに統合することです。これにより、電子メールおよび静的レポートからワークフローを取り除き、イベントや結果をルーティング、エスカレーション、管理することが可能になります。in EventBridge の柔軟なルーティング機能は、この統合の強力なイネーブラーです。

Amazon Detective

Amazon Detective は、セキュリティアナリストのセキュリティ検出結果や疑わしいアクティビティの根本原因を簡単に分析、調査、および迅速に特定できるようにすることで、応答性の高いセキュリティコントロール戦略をサポートします。Detective は、Word ログと Amazon CloudTrail AWS VPCフローログから、ログイン試行、API コール、ネットワークトラフィックなどの時間ベースのイベントを自動的に抽出します。Detective を使用して、最大 1 年間の履歴イベントデータにアクセスできます。Detective は、 CloudTrail ログと Amazon VPC フローログの独立したストリームを使用して、これらのイベントを使用します。Detective は、機械学習とビジュアライゼーションにより、リソースの動作とリソース間のインタラクションを時系列で統合したインタラクティブなビューを作成します。これは ビヘイビアグラフ と呼ばれます。動作グラフを調べて、ログオン試行の失敗や不審な API 呼び出しなど、さまざまなアクションを調べることができます。

Detective は Amazon Security Lake と統合され、セキュリティアナリストが Security Lake に保存されているログをクエリおよび取得できるようにします。この統合を使用して、Detective でセキュリティ調査を行う際に Security Lake に保存されている CloudTrail AWS ログと Amazon VPC フローログから追加情報を取得できます。

Detective は、GuardDuty Runtime Monitoring によって検出された脅威など、Amazon GuardDuty によって検出された検出結果も取り込みます。アカウントで Detective を有効にすると、そのアカウントがビヘイビアグラフの管理者アカウントになります。Detective を有効にする前に、アカウントが少なくとも 48 時間 GuardDuty に登録されていることを確認してください。この要件を満たさない場合、Detective を有効にすることはできません。

Detective は、1 つのセキュリティ侵害イベントに関連する複数の検出結果を検出結果グループに自動的にグループ化します。脅威アクターは通常、時間やリソースにまたがる複数のセキュリティ検出結果につながる一連のアクションを実行します。したがって、検出結果グループは、複数のエンティティと検出結果を含む調査の開始点となる必要があります。Detective は、検出結果グループを自動的に分析し、セキュリティ調査の迅速化に役立つ自然言語でのインサイトを提供する生成 AI を使用して、検出結果グループの概要も提供します。

Detective は AWS Organizations と統合されています。組織管理アカウントは、メンバーアカウントを Detective 管理者アカウントとして委任します。AWS SRA、これは Security Tooling アカウントです。Detective 管理者アカウントは、組織内のすべての現在のメンバーアカウントを検出メンバーアカウントとして自動的に有効にし、AWS 組織に追加された新しいメンバーアカウントを追加することもできます。Detective 管理者アカウントは、現在 AWS 組織には存在しないが、同じリージョンにあるメンバーアカウントを招待して、プライマリアカウントの動作グラフにデータを提供することもできます。メンバーアカウントが招待を承諾して有効になると、Detective は、メンバーアカウントのデータを取り込み、その動作グラフに抽出し始めます。

設計上の考慮事項
  • Word および GuardDuty AWS Security Hub コンソールから Detective の検出結果プロファイルに移動できます。これらのリンクは、調査プロセスを合理化するのに役立ちます。アカウントは、Detective とピボット元のサービス (GuardDuty または Security Hub) の両方の管理アカウントである必要があります。サービスのプライマリアカウントが同じであれば、統合リンクはシームレスに機能します。

AWS Audit Manager

AWS Audit Manager は、AWS の使用を継続的に監査し、監査の管理方法と規制や業界標準への準拠を簡素化するのに役立ちます。これにより、証拠の手動による収集、レビュー、管理から、証拠の収集を自動化するソリューションへの移行、監査証拠のソースを追跡する簡単な方法の提供、チームワークのコラボレーションの有効化、証拠のセキュリティと整合性の管理に役立ちます。監査の時期において、Audit Manager は、コントロールのステークホルダーのレビューを管理するのに役立ちます。

Audit Manager を使用すると、Center for Internet Security (CIS) ベンチマーク、CIS AWS Foundations Benchmark、System and Organization Controls 2 (SOC 2)、Payment Card Industry Data Security Standard (PCI DSS) などの構築済みのフレームワークに対して監査を行うことができます。また、内部監査の特定の要件に基づいて、標準またはカスタムのコントロールを使用して独自のフレームワークを作成することもできます。

Audit Manager は 4 種類の証拠を収集します。Word Config と AWS Security Hub からのコンプライアンスチェックの証拠、AWS からの管理イベントの証拠、AWS CloudTrail AWS service-to-serviceAPIコールからの設定の証拠の 3 種類の証拠が自動化されています。自動化できない証拠については、Audit Manager では手動証拠をアップロードできます。

注記

Audit Manager は、特定のコンプライアンス標準および規制への準拠の検証に関連する証拠の収集を支援します。ただし、コンプライアンスは評価されません。したがって、Audit Manager を通じて収集された証拠には、監査に必要な運用プロセスの詳細が含まれていない場合があります。Audit Manager は、法律顧問やコンプライアンスの専門家に代わるものではありません。評価対象のコンプライアンスフレームワークの認定を受けているサードパーティーの評価機関のサービスをエンゲージすることをお勧めします (複数可)。

Audit Manager の評価は、AWS 組織内の複数のアカウントで実行できます。Audit Manager は証拠を収集し、AWS Organizations の委任された管理者アカウントに統合します。この監査機能は、主にコンプライアンスチームと内部監査チームによって使用され、AWS アカウントへの読み取りアクセスのみが必要です。

設計上の考慮事項
  • Audit Manager は、Security Hub や AWS Config などの他の AWS セキュリティサービスを補完して、リスク管理フレームワークの実装を支援します。Audit Manager は独立したリスク保証機能を提供しますが、Security Hub はリスクの監督に役立ち、AWS Config コンフォーマンスパックはリスクの管理に役立ちます。Institute of Internal Auditors (IIA) によって開発された 3 行モデルに精通している監査プロフェッショナルは、この AWS サービスの組み合わせが 3 行の防御をカバーするのに役立つことに注意してください。詳細については、AWS Cloud Operations & Migrations ブログの 2 部構成のブログシリーズを参照してください。

  • Audit Manager が Security Hub の証拠を収集するには、両方のサービスの委任管理者アカウントが同じ AWS アカウントである必要があります。このため、AWS SRA では、Security Tooling アカウントが Audit Manager の委任管理者になります。

AWSアーティファクト

AWS Artifact は Security Tooling アカウント内でホストされ、コンプライアンスアーティファクト管理機能を AWS 組織管理アカウントから分離します。この職務の分離は重要です。これは、絶対に必要な場合を除き、AWS 組織管理アカウントをデプロイに使用しないことが推奨されます。代わりに、メンバーアカウントにデプロイを渡します。監査アーティファクトの管理はメンバーアカウントから行うことができ、関数はセキュリティおよびコンプライアンスチームと密接に連携するため、Security Tooling アカウントは AWS Artifact の管理者アカウントとして指定されます。AWS Artifact レポートを使用して、Word AWS 証明書、Payment Card Industry (ISOPCI)、System and Organization Controls (SOC) レポートなどの AWS セキュリティおよびコンプライアンスドキュメントをダウンロードできます。

AWS Artifact は委任管理機能をサポートしていません。代わりに、この機能を監査チームとコンプライアンスチームに関連する Security Tooling アカウントの IAM ロールのみに制限して、必要に応じてこれらのレポートをダウンロード、レビュー、外部監査人に提供できます。さらに、特定の IAM ロールが Word IAMポリシーを通じて特定の AWS Artifact レポートのみにアクセスできるように制限することもできます。サンプル IAM ポリシーについては、AWS Artifact ドキュメントを参照してください。

設計上の考慮事項
  • 監査チームとコンプライアンスチーム専用の AWS アカウントを持つことを選択した場合、Security Tooling アカウントとは別のセキュリティ監査アカウントで AWS Artifact をホストできます。AWS Artifact レポートは、組織が文書化されたプロセスに従っているか、特定の要件を満たしていることを示す証拠を提供します。監査アーティファクトは、システム開発ライフサイクルを通じて収集およびアーカイブされ、内部または外部の監査および評価の証拠として使用できます。

AWS KMS

AWS Key Management Service (AWS KMS) は、暗号化キーを作成および管理し、幅広い AWS サービスおよびアプリケーションでの使用を制御するのに役立ちます。AWS KMS は、ハードウェアセキュリティモジュールを使用して暗号化キーを保護する、安全で回復力のあるサービスです。キーのストレージ、ローテーション、アクセス制御など、キーマテリアルの業界標準のライフサイクルプロセスに従います。AWS KMS、暗号化キーと署名キーを使用してデータを保護するのに役立ち、AWS 暗号化SDKによるサーバー側の暗号化とクライアント側の暗号化の両方に使用できます。Word AWSKMS、保護と柔軟性のために、カスタマーマネージドキー、AWS マネージドキー、AWS 所有キーの 3 種類のキーをサポートしています。カスタマーマネージドキーは、ユーザーが作成、所有、管理する AWS KMS アカウントの AWS Word キーです。AWS マネージドキーは、AWS KMS と統合された AWS サービスによってユーザーに代わって作成、管理、使用されるアカウント内の AWS KMSです。AWS 所有キーは、AWS AWSサービスが複数の KMS アカウントで使用するために所有および管理する AWS キーのコレクションです。KMS キーの使用の詳細については、AWS のドキュメントと KMS AWS KMS の暗号化の詳細を参照してください。

AWS SRA は、KMS キーが使用されるアカウント内にローカルに存在する分散キー管理モデルを推奨し、特定のアカウントのインフラストラクチャとワークロードを担当するユーザーが独自のキーを管理できるようにします。すべての暗号化関数に対して、1 つのアカウントで 1 つのキーを使用しないことをお勧めします。キーは、関数とデータ保護の要件に基づいて作成し、最小特権の原則を適用できます。このモデルにより、ワークロードチームは暗号化キーの使用に対する制御、柔軟性、俊敏性が向上します。また、API の制限を回避し、影響の範囲を単一の AWS アカウントに制限し、レポート、監査、その他のコンプライアンス関連のタスクを簡素化するのに役立ちます。場合によっては、暗号化アクセス許可は復号アクセス許可とは別に保持され、管理者はライフサイクル機能を管理しますが、管理するキーを使用してデータを暗号化または復号化することはできません。分散モデルでは、分散キーが同じ方法で管理され、KMS キーの使用が確立されたベストプラクティスとポリシーに従って監査されるように、ガードレールをデプロイして適用することが重要です。詳細については、Word AWS ドキュメントの「Word Key Management Service のセキュリティのベストプラクティス」を参照してください。 AWS KMS

代替のデプロイオプションは、キーポリシーと KMS ポリシーを組み合わせてアプリケーションリソースによってアプリケーションアカウントのキーを使用する機能を委任しながら、IAM キー管理の責任を 1 つのアカウントに一元化することです。このアプローチは安全かつ簡単に管理できますが、AWS KMSスロットリング制限、アカウントサービスの制限、セキュリティチームが運用キー管理タスクに悩まされているため、ハードルが発生する可能性があります。

AWS SRA、一元化されたモデルと分散されたモデルを組み合わせたものです。Security Tooling アカウントでは、AWS KMS は、Word 組織によって管理される CloudTrail AWS 組織の証跡など、一元化されたセキュリティサービスの暗号化を管理するために使用されますAWS。このガイドの後半にあるアプリケーションアカウントセクションでは、ワークロード固有のリソースを保護するために使用される KMS キーパターンについて説明します。

AWS Private CA

AWS Private Certificate Authority (AWS Private CA) は、EC2 インスタンス、コンテナ、IoT デバイス、オンプレミスリソースのプライベートエンドエンティティ TLS 証明書のライフサイクルを安全に管理するためのマネージドプライベート CA サービスです。これにより、実行中のアプリケーションへの暗号化された TLS 通信が可能になります。では AWS Private CA、独自の CA 階層 (下位 CAs を介してエンドエンティティ証明書にルート CA) を作成し、それを使用して証明書を発行して、内部ユーザー、コンピュータ、アプリケーション、サービス、サーバー、その他のデバイスを認証し、コンピュータコードに署名できます。プライベート CA によって発行された証明書は、インターネットではなく、AWS 組織内でのみ信頼されます。

パブリックキーインフラストラクチャ (PKI) またはセキュリティチームは、すべての PKI インフラストラクチャの管理を担当できます。これには、プライベート CA の管理と作成が含まれます。ただし、ワークロードチームが証明書要件をセルフサービスできるようにするプロビジョニングが必要です。AWS SRA、ルート CA が Security Tooling アカウント内でホストされている一元化された CA 階層を示しています。これにより、ルート CA は PKI 全体の基盤となるため、セキュリティチームは厳格なセキュリティコントロールを適用できます。ただし、プライベート CA からのプライベート証明書の作成は、Word Resource Access Manager (AWS Word) を使用して CA をアプリケーションアカウントと共有することで、アプリケーション開発チームに委任されますAWSRAM。AWS は、クロスアカウント共有に必要なアクセス許可RAMを管理します。これにより、すべてのアカウントでプライベート CA が不要になり、よりコスト効率の高いデプロイ方法が提供されます。ワークフローと実装の詳細については、ブログ記事AWS を使用して AWS Private CA クロスアカウントRAMを共有する方法」を参照してください。

注記

ACM は、TLS サービスで使用するパブリック AWS 証明書のプロビジョニング、管理、デプロイにも役立ちます。この機能をサポートするには、ACM証明書を使用する Word アカウントに AWS が存在する必要があります。これは、このガイドの「アプリケーションアカウント」セクションで後ほど説明します。

設計上の考慮事項
  • を使用すると AWS Private CA、最大 5 つのレベルで認証機関の階層を作成できます。また、それぞれ独自のルートを持つ複数の階層を作成することもできます。 AWS Private CA 階層は組織の PKI 設計に従う必要があります。ただし、CA 階層を増やすと、証明書パス内の証明書の数が増え、エンドエンティティ証明書の検証時間が長くなることに注意してください。明確に定義された CA 階層には、各 CA に適したきめ細かなセキュリティコントロール、異なるアプリケーションへの下位 CA の委任などの利点があります。これにより、管理タスクが分割され、取り消し可能な信頼が制限された CA の使用、異なる有効期間を定義する機能、パス制限を適用する機能につながります。ルートと下位の CAs は別々の AWS アカウントにあることが理想的です。を使用して CA 階層を計画する方法の詳細については AWS Private CA、 AWS Private CA ドキュメントとブログ記事「自動車および製造のエンタープライズスケール AWS Private CA 階層を保護する方法」を参照してください。

  • AWS Private CA は既存の CA 階層と統合できます。これにより、ACM の自動化およびネイティブ AWS 統合機能を、現在使用している既存の信頼のルートと組み合わせて使用できます。オンプレミスの親 CA AWS Private CA によってバックアップされた下位 CA を に作成できます。実装の詳細については、 AWS Private CA ドキュメントの「外部親 CA によって署名された下位 CA 証明書のインストール」を参照してください。

Amazon Inspector

Amazon Inspector は、Amazon EC2 インスタンス、Amazon Container Registry (Amazon ECR) のコンテナイメージ、Word AWS Lambda 関数を自動的に検出してスキャンする自動脆弱性管理サービスで、既知のソフトウェアの脆弱性や意図しないネットワークへの露出を検出してスキャンします。

Amazon Inspector は、リソースに変更を加えるたびにリソースを自動的にスキャンすることで、リソースのライフサイクル全体を通じて環境を継続的に評価します。リソースの再スキャンを開始するイベントには、EC2 インスタンスへの新しいパッケージのインストール、パッチのインストール、リソースに影響する新しい一般的な脆弱性と露出 (CVE) レポートの公開が含まれます。Amazon Inspector はCIS インスタンスのオペレーティングシステムの Center of Internet Security (EC2) Benchmark 評価をサポートしています。

Amazon Inspector は、コンテナイメージ評価のために Jenkins や TeamCity などのデベロッパーツールと統合されています。コンテナイメージの継続的インテグレーションと継続的デリバリー (CI/CD) tools, and push security to an earlier point in the software development lifecycle. Assessment findings are available in the CI/CD tool’s dashboard, so you can perform automated actions in response to critical security issues such as blocked builds or image pushes to container registries. If you have an active AWS account, you can install the Amazon Inspector plugin from your CI/CD tool marketplace and add an Amazon Inspector scan in your build pipeline without needing to activate the Amazon Inspector service. This feature works with CI/CD tools hosted anywhere—on AWS, on premises, or in hybrid clouds—so you can consistently use a single solution across all your development pipelines. When Amazon Inspector is activated, it automatically discovers all your EC2 instances, container images in Amazon ECR and CI/CD ツール、Word AWS Lambda 関数を大規模に評価し、既知の脆弱性を継続的にモニタリングできます。

Amazon Inspector のネットワーク到達可能性の検出結果は、仮想ゲートウェイを介したインターネットゲートウェイ、EC2 ピアリング接続、仮想プライベートネットワーク (VPC) などの VPC エッジとの間の VPNs インスタンスのアクセシビリティを評価します。これらのルールは、AWS ネットワークのモニタリングを自動化し、管理ミスのあるセキュリティグループ、アクセスコントロールリスト (ACLs)、インターネットゲートウェイなどを通じて、EC2 インスタンスへのネットワークアクセスが誤って設定される可能性のある場所を特定するのに役立ちます。さらなる詳細については、Amazon Inspector documentation を参照してください。

Amazon Inspector が脆弱性またはオープンネットワークパスを特定すると、調査できる結果が生成されます。検出結果には、リスクスコア、影響を受けるリソース、修復の推奨事項など、脆弱性に関する包括的な詳細が含まれます。リスクスコアは環境に合わせて特別に調整され、 up-to-date CVE情報をネットワークのアクセシビリティやエクスプロイト可能性情報などの時間的および環境的要因と関連付けて、コンテキストに応じた検出結果を提供することで計算されます。

脆弱性をスキャンするには、EC2 Systems Manager エージェント (AWS エージェント) を使用して SSM Systems Manager で AWS インスタンスを管理する必要があります。Amazon EC2 ECRまたは Lambda 関数の Word インスタンスのネットワーク到達可能性やコンテナイメージの脆弱性スキャンにエージェントは必要ありません。

Amazon Inspector は AWS Organizations と統合されており、委任された管理をサポートしています。AWS SRA、Security Tooling アカウントが Amazon Inspector の委任管理者アカウントになります。Amazon Inspector の委任された管理者アカウントは、AWS 組織のメンバーの検出結果データと特定の設定を管理できます。これには、すべてのメンバーアカウントの集約された結果の詳細の表示、メンバーアカウントのスキャンの有効化または無効化、AWS 組織内のスキャンされたリソースの確認が含まれます。

設計上の考慮事項
  • Amazon Inspector は、両方のサービスが有効になっている場合、AWS Security Hub と自動的に統合されます。この統合を使用して、すべての検出結果を Amazon Inspector からSecurity Hub に送信できます。これにより、Security Hub には、これらの検出結果をセキュリティ体制の分析に含めることができます。

  • Amazon Inspector は、検出結果、リソースカバレッジの変更、個々のリソースの初期スキャンのイベントを Amazon EventBridge に自動的にエクスポートし、オプションで Amazon Simple Storage Service (Amazon S3) バケットにエクスポートします。アクティブな検出結果を S3 バケットにエクスポートするには、Amazon Inspector が検出結果を暗号化するために使用できる AWSKMS キーと、Amazon Inspector がオブジェクトをアップロードできるようにするアクセス許可を持つ S3 バケットが必要です。 EventBridge 統合により、既存のセキュリティおよびコンプライアンスワークフローの一部として、ほぼリアルタイムで検出結果をモニタリングおよび処理できます。 EventBridge イベントは、発信元のメンバーアカウントに加えて、Amazon Inspector の委任管理者アカウントに発行されます。

実装例

AWS SRAコードライブラリは、Amazon Inspector のサンプル実装を提供します。これは、委任管理 (セキュリティツール) を示し、AWS 組織内のすべての既存アカウントと将来のアカウントに Amazon Inspector を設定します。

すべての AWS アカウントに共通のセキュリティサービスをデプロイする

このリファレンスの前半のAWS 組織全体のセキュリティサービスの適用」セクションでは、AWS アカウントを保護するセキュリティサービスが強調表示され、これらのサービスの多くは AWS Organizations 内で設定および管理できることがわかりました。これらのサービスの一部はすべてのアカウントにデプロイする必要があります。Word AWS SRA に表示されます。これにより、一貫したガードレールのセットが可能になり、AWS 組織全体で一元的なモニタリング、管理、ガバナンスが可能になります。 

Security Hub、 GuardDuty、AWS Config、Access Analyzer、 CloudTrail AWS 組織の証跡は、すべてのアカウントに表示されます。最初の 3 つは、 管理アカウント、信頼されたアクセス、および委任された管理者セクションで前述した委任された管理者機能をサポートしています。 CloudTrail は現在、別の集約メカニズムを使用しています。

AWS SRA コードリポジトリは、GitHub AWS 組織管理アカウントを含むすべてのアカウントで Security Hub、 GuardDuty、AWS Config、Firewall Manager、 CloudTrail 組織の証跡を有効にするサンプル実装を提供します。

設計上の考慮事項
  • 特定のアカウント設定では、追加のセキュリティサービスが必要になる場合があります。例えば、S3 バケットを管理するアカウント (アプリケーションアカウントとログアーカイブアカウント) には Amazon Macie も含め、これらの一般的なセキュリティサービスで CloudTrail S3 データイベントログを有効にすることを検討する必要があります。(Macie は、一元化された設定とモニタリングによる委任管理をサポートします。) もう 1 つの例は Amazon Inspector です。これは、EC2 インスタンスまたは Amazon ECR イメージをホストするアカウントにのみ適用されます。

  • このセクションで前述したサービスに加えて、AWS SRA には、Word Organizations の統合と委任された管理者機能をサポートする Amazon Detective と AWS AWS Audit Manager という 2 つのセキュリティに焦点を当てたサービスが含まれています。ただし、これらのサービスは以下のシナリオで最適に使用されることがわかっているため、これらはアカウントベースライン作成の推奨サービスに含まれていません。

    • これらの機能を実行する専任のチームまたはリソースグループがあります。Detective はセキュリティアナリストチームが最適に活用されており、Audit Manager は内部監査チームやコンプライアンスチームに役立ちます。

    • プロジェクトの開始時に GuardDuty や Security Hub などのツールのコアセットに焦点を当て、追加の機能を提供するサービスを使用してこれらを構築したいと考えています。