翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
セキュリティ OU - Security Tooling アカウント
| 簡単なアンケート |
次の図は、 AWS Security Tooling アカウントで設定されているセキュリティサービスを示しています。
Security Tooling アカウントは、セキュリティサービスの運用、 のモニタリング AWS アカウント、セキュリティアラートとレスポンスの自動化に専念しています。セキュリティの目的は以下の通りです。
-
セキュリティガードレール、モニタリング、対応へのアクセスを管理するための制御されたアクセスを専用アカウントに提供します。
-
セキュリティオペレーションデータをモニタリングし、トレーサビリティを維持するために、適切な一元化されたセキュリティインフラストラクチャを維持します。検出、調査、対応は、セキュリティライフサイクルの重要な部分であり、品質プロセス、法的義務またはコンプライアンス義務をサポートし、脅威の特定と対応の取り組みに使用することができます。
-
暗号化キーやセキュリティグループ設定などの適切なセキュリティ設定とオペレーションを別のレイヤーで制御できるようにすることで、defense-in-depthの組織戦略をさらにサポートします。セキュリティオペレーターが作業するアカウントです。 AWS 組織全体の情報を表示する読み取り専用/監査ロールが一般的ですが、書き込み/変更ロールの数は制限され、厳密に制御、モニタリング、ログ記録されます。
設計上の考慮事項
-
AWS Control Tower は、デフォルトでセキュリティ OU の下のアカウントを監査アカウントとして指定します。アカウントの名前は、 AWS Control Tower セットアップ中に変更できます。
-
セキュリティツールアカウントを複数持つのが適切かもしれません。例えば、セキュリティイベントのモニタリングと対応は、多くの場合、専用のチームに割り当てられています。ネットワークセキュリティは、クラウドインフラストラクチャやネットワークチームと協力して、独自のアカウントとロールを保証する場合があります。このような分割は、一元化されたセキュリティエンクレーブを分離するという目的を保持し、職務の分離、最小特権、およびチーム割り当ての単純化の可能性をさらに強調するものです。を使用している場合 AWS Control Tower、セキュリティ OU AWS アカウント での追加の作成が制限されます。
セキュリティサービスの委任管理者
Security Tooling アカウントは、 全体で管理者/メンバー構造で管理されるセキュリティサービスの管理者アカウントとして機能します AWS アカウント。前述のように、これは AWS Organizations 委任管理者機能を通じて処理されます。現在委任管理者をサポートしている AWS SRA のサービスには、ルートアクセス AWS Config、 AWS Firewall Manager、Amazon GuardDuty、IAM Access Analyzer、Amazon Macie、 AWS Security Hub、 AWS Security Hub CSPM Amazon Detective、 AWS Audit Manager Amazon Inspector AWS CloudTrail、および の IAM 一元管理が含まれます AWS Systems Manager。セキュリティチームがこれらのサービスのセキュリティ機能を管理し、セキュリティ固有のイベントや検出結果をモニタリングします。
AWS IAM アイデンティティセンター は、メンバーアカウントへの委任管理をサポートします。 AWS SRA は、共有サービスアカウントの IAM アイデンティティセンターセクションで後述するように、IAM アイデンティティセンターの委任管理者アカウントとして共有サービスアカウントを使用します。
一元化されたルートアクセス
Security Tooling アカウント は、ルートアクセス機能の IAM 集中管理のための委任管理者アカウントです。 この機能は、メンバーアカウントで認証情報管理と特権ルートアクションを有効にすることで、組織レベルで有効にする必要があります。メンバーアカウントに代わって特権ルートアクションを実行できるようにするには、委任された管理者に明示的にsts:AssumeRootアクセス許可を付与する必要があります。このアクセス許可は、組織管理アカウントまたは委任管理者アカウントでメンバーアカウントの特権ルートアクションが有効になっている場合にのみ使用できます。このアクセス許可により、ユーザーは Security Tooling アカウントから一元的にメンバーアカウントで特権ルートユーザータスクを実行できます。特権セッションを起動したら、誤って設定された S3 バケットポリシーの削除、誤って設定された SQS キューポリシーの削除、メンバーアカウントのルートユーザー認証情報の削除、メンバーアカウントのルートユーザー認証情報の再有効化を行うことができます。これらのアクションは、 コンソール、 AWS Command Line Interface (AWS CLI)、または APIs を使用して実行できます。
AWS CloudTrail
AWS CloudTrail
SRA では、Security Tooling AWS アカウントは CloudTrail を管理するための委任管理者アカウントです。組織の証跡ログを保存する対応する S3 バケットは、ログアーカイブアカウントに作成されます。これは、CloudTrail ログ権限の管理と使用を分離するためです。S3 バケットを作成または更新して組織の証跡のログファイルを保存する方法については、CloudTrail ドキュメントを参照してください。セキュリティのベストプラクティスとして、組織の証跡aws:SourceArnの条件キーを S3 バケットのリソースポリシー (および KMS キーや SNS トピックなどの他のリソース) に追加します。これにより、S3 バケットは特定の証跡に関連付けられているデータのみを受け入れるようになります。証跡は、ログファイルの整合性検証用のログファイル検証で設定されます。ログファイルとダイジェストファイルは、SSE-KMS を使用して暗号化されます。組織の証跡は CloudWatch Logs のロググループとも統合され、長期保持のためにイベントを送信します。
注記
組織の証跡は、管理アカウントと委任管理者アカウントの両方から作成および管理できます。ただし、ベストプラクティスとして、管理アカウントへのアクセスを制限し、利用可能な場合は委任管理者機能を使用する必要があります。
設計上の考慮事項
-
CloudTrail は、多くの場合、大量のアクティビティであるため、デフォルトではデータイベントを記録しません。ただし、S3 バケット、Lambda 関数、CloudTrail レイクに AWS 送信される外部からのログイベント、SNS トピックなど、特定の重要な AWS リソースのデータイベントをキャプチャする必要があります。これを行うには、個々のリソースの ARNs を指定して、特定のリソースからのデータイベントを含めるように組織の証跡を設定します。
-
メンバーアカウントが独自のアカウントの CloudTrail ログファイルにアクセスする必要がある場合は、中央の S3 バケットから組織の CloudTrail ログファイルを選択的に共有できます。ただし、メンバーアカウントがアカウントの CloudTrail ログにローカル Amazon CloudWatch ロググループを必要とする場合、またはログ管理イベントとデータイベント (読み取り専用、書き込み専用、管理イベント、データイベント) を組織の証跡とは異なる方法で設定する場合は、適切なコントロールを使用してローカル証跡を作成できます。ローカルアカウント固有の証跡には追加料金
が発生します。
AWS Security Hub CSPM
AWS Security Hub クラウドセキュリティ体制管理
Security Hub CSPM は と統合 AWS Organizations され、 AWS 組織内のすべての既存および将来のアカウントにおけるセキュリティ体制の管理を簡素化します。委任管理者アカウント (この場合は Security Tooling) の Security Hub CSPM 中央設定機能を使用して、Security Hub CSPM サービス、セキュリティ標準、およびセキュリティコントロールを リージョン全体の組織アカウントと組織単位 (OUs) で設定する方法を指定できます。 これらの設定は、ホームリージョンと呼ばれる 1 つのプライマリリージョンから数ステップで設定できます。中央設定を使用しない場合は、アカウントとリージョンごとに Security Hub CSPM を個別に設定する必要があります。委任管理者は、アカウントと OUs をセルフマネージドとして指定できます。この場合、メンバーは各リージョンで個別に設定を構成できます。また、委任管理者はリージョン間でメンバーアカウントまたは OU を設定できます。組織内のすべてのアカウントと OU を、一元管理型、すべてセルフマネージド型、または両方の組み合わせとして指定できます。これにより、一貫した設定の適用が簡素化され、OU とアカウントごとに変更する柔軟性が提供されます。
Security Hub CSPM 委任管理者アカウントは、すべてのメンバーアカウントの結果の表示、インサイトの表示、詳細の制御を行うこともできます。さらに、委任管理者アカウント内で集約リージョンを指定して、アカウントとリンクされたリージョン間で検出結果を一元化することもできます。検出結果は、アグリゲータリージョンと他のすべてのリージョンの間で継続的かつ双方向に同期されます。
Security Hub CSPM は、複数の との統合をサポートしています AWS のサービス。Amazon GuardDuty、 AWS Config、Amazon Macie、IAM Access Analyzer、 AWS Firewall Manager、Amazon Inspector、 Amazon Route 53 Resolver DNS Firewall、および AWS Systems Manager Patch Manager は、検出結果を Security Hub CSPM にフィードできます。Security Hub CSPM は、AWS Security Finding 形式 (ASFF) と呼ばれる標準形式を使用して検出結果を処理します。Security Hub CSPM は、統合された製品間で検出結果を関連付けて、最も重要な検出結果を優先します。Security Hub CSPM の検出結果のメタデータを強化して、セキュリティの検出結果のコンテキスト化、優先順位付け、およびアクションの実行を強化できます。このエンリッチメントにより、Security Hub CSPM に取り込まれるすべての検出結果に、リソースタグ、新しい AWS アプリケーションタグ、およびアカウント名情報が追加されます。これにより、自動化ルールの検出結果を微調整し、検出結果とインサイトを検索またはフィルタリングし、アプリケーションごとにセキュリティ体制のステータスを評価することができます。さらに、自動化ルールを使用して検出結果を自動的に更新できます。Security Hub CSPM が検出結果を取り込むと、検出結果の抑制、重要度の変更、検出結果へのメモの追加など、さまざまなルールアクションを適用できます。これらのルールアクションは、結果が関連付けられているリソース ID やアカウント IDs、そのタイトルなど、結果が指定された基準と一致する場合に有効になります。自動化ルールを使用して、ASFF の選択結果フィールドを更新できます。ルールは、新しい検出結果と更新された検出結果の両方に適用されます。
セキュリティイベントの調査中に、Security Hub CSPM から Amazon Detective に移動して GuardDuty の検出結果を調査できます。Security Hub CSPM では、統合をスムーズにするために、Detective (存在する場合) などのサービスの委任管理者アカウントを調整することをお勧めします。たとえば、Detective と Security Hub CSPM の間で管理者アカウントを調整しない場合、検出結果から Detective に移動することはできません。包括的なリストについては、Security Hub CSPM ドキュメントの「Security Hub CSPM と AWS のサービス の統合の概要」を参照してください。
Amazon VPC の Network Access Analyzer
Security Hub CSPM は、モニタリング機能に加えて、Amazon EventBridge との統合をサポートし、特定の検出結果の修復を自動化します。結果を受け取ったときに実行するカスタムアクションを定義できます。たとえば、チケット発行システムや自動修復システムに検出結果を送信するなどのカスタムアクションを設定できます。その他の議論と例については、 AWS ブログ記事「 による自動応答と修復 AWS Security Hub CSPM
Security Hub CSPM は、サービスにリンクされた AWS Config ルール を使用して、コントロールのほとんどのセキュリティチェックを実行します。これらのコントロールをサポートするには、Security Hub CSPM AWS Config が有効になっている各アカウントで、管理者 (または委任管理者) アカウントとメンバーアカウントを含むすべてのアカウントで を有効にする必要があります。 AWS リージョン
設計上の考慮事項
-
PCI-DSS などのコンプライアンス標準が Security Hub CSPM にすでに存在する場合、フルマネージド型の Security Hub CSPM サービスが最も簡単に運用できます。ただし、セキュリティ、運用、コスト最適化チェックなど、独自のコンプライアンスまたはセキュリティ標準をアセンブルする場合、 AWS Config コンフォーマンスパックは簡素化されたカスタマイズプロセスを提供します。( AWS Config およびコンフォーマンスパックの詳細については、AWS Config「」セクションを参照してください)。
-
Security Hub CSPM の一般的なユースケースは次のとおりです。
-
アプリケーション所有者がリソースのセキュリティとコンプライアンス体制 AWS を可視化するダッシュボードとして
-
セキュリティオペレーション、インシデント対応担当者、脅威ハンターが使用するセキュリティ検出結果の中央ビューとして、 AWS アカウント および リージョン全体の AWS セキュリティおよびコンプライアンスの検出結果をトリアージしてアクションを実行します。
-
セキュリティとコンプライアンスの検出結果を AWS アカウント および リージョン間で集約し、一元化されたセキュリティ情報とイベント管理 (SIEM) またはその他のセキュリティオーケストレーションシステムにルーティングするには
セットアップ方法など、これらのユースケースに関する追加のガイダンスについては、ブログ記事「3 つの定期的な Security Hub CSPM の使用パターンとデプロイ方法
」を参照してください。 -
実装例
AWS SRA コードライブラリ
AWS Security Hub
AWS Security Hub は、重要なセキュリティ脅威を優先し、大規模な対応を支援する統合クラウドセキュリティソリューションです。Security Hub は、体制管理 (AWS Security Hub CSPM)、脆弱性管理 (Amazon Inspector)、機密データ (Amazon Macie)、脅威検出 (Amazon GuardDuty) など、複数のソースからのセキュリティシグナルを自動的に関連付けて強化することで、セキュリティ問題をほぼリアルタイムで検出します。これにより、セキュリティチームは自動分析とコンテキストに応じたインサイトを通じて、クラウド環境でアクティブなリスクに優先順位を付けることができます。Security Hub は、攻撃者がエクスポージャ検出結果に関連するリソースにアクセスするために悪用できる潜在的な攻撃経路を視覚的に表現します。これにより、複雑なセキュリティシグナルが実用的なインサイトに変換されるため、セキュリティについて情報に基づいた意思決定を迅速に行うことができます。
Security Hub は戦略的に再設計され、関連するセキュリティサービス構成要素がセキュリティ上の成果を達成できるように簡素化されました。脅威マトリックスのセキュリティ検出結果をさまざまなセキュリティシグナルにほぼリアルタイムで関連付けることで、最も重要なリスクに優先順位を付けることができます。結果は、 AWS リソースに関連する露出を検出するために相関しています。露出は、セキュリティコントロール、設定ミス、またはアクティブな脅威によって悪用される可能性のあるその他の領域のより広範な弱点を表します。例えば、インターネットから到達可能であり、悪用の可能性の高いソフトウェアの脆弱性がある EC2 インスタンスが公開される可能性があります。
Security Hub と Security Hub CSPM は補完的なサービスです。Security Hub CSPM は、セキュリティ体制を包括的に把握し、セキュリティ業界標準とベストプラクティスに照らしてクラウド環境を評価するのに役立ちます。Security Hub は、重要なセキュリティ問題の優先順位付けと対応に役立つ統一されたエクスペリエンスを提供します。Security Hub CSPM の検出結果は Security Hub に自動的にルーティングされ、Amazon Inspector などの他のセキュリティサービスの検出結果との相関に基づいて露出レポートを生成します。これにより、環境内の最も重大なリスクを特定できます。
Security Hub は、 AWS 環境内のリソースの概要をタイプ別および関連する検出結果別にも提供します。露出状況と攻撃シーケンスに応じてリソースに優先順位をつけて表示します。リソースタイプを選択すると、そのリソースタイプに関連付けられているすべてのリソースを確認できます。
最適なエクスペリエンスを得るには、Security Hub と Security Hub CSPM を有効にするとともに、Amazon GuardDuty
AWS SRA では、Security Tooling アカウントは Security Hub、Security Hub CSPM、およびその他の AWS セキュリティサービスの委任管理者として機能します。Security Tooling アカウント内で、メンバーアカウントに関連付けられているすべてのリソースを表示できます。リンクされた AWS リージョン からホーム内のすべてのリソースを表示することもできます AWS リージョン。
実装ノート
Security Hub を有効にするには、以前に Security Hub CSPM を有効にしたことがあるかどうかを考慮した手順を含む 3 つのステップが必要です。Security Hub は とネイティブに統合されており AWS Organizations、設定と実装のプロセスを簡素化し、すべての検出結果を 1 つの場所に一元化して集約します。SRA のベストプラクティスに従って、Security Tooling AWS アカウントを委任管理者アカウントとして使用して、Security Hub を管理および設定します。 専用アカウント構造Security Hub の設定を使用して、将来のリージョンとアカウントを含むすべてのリージョン、OUs、アカウントを自動的に有効にします。また、複数の の検出結果、リソース、傾向を 1 つのホームリージョン AWS リージョン に集約するようにクロスリージョン集約を設定する必要があります。設定中に、Jira Cloud や ServiceNow などのネイティブ統合を有効にすることもできます。
設計上の考慮事項
-
Security Hub の検出結果は、Open Cybersecurity Schema Framework (OCSF) でフォーマットされています。Security Hub は OCSF で検出結果を生成し、Security Hub CSPM などから OCSF で検出結果を受け取ります AWS のサービス。これらの OCSF の検出結果は、Amazon EventBridge 経由で自動化のために送信することも、中央ログ集約アカウントに保存してセキュリティログの分析と保持を実行することもできます。
-
AWS 組織管理アカウントは、Security Hub の委任管理者として自身を指定することはできません。これは、Security Tooling AWS アカウントを委任管理者として指定する SRA のベストプラクティスと一致しています。また、次の点にも注意してください。
-
Security Hub CSPM の指定された管理者アカウントは自動的に Security Hub の指定された管理者になります。
-
Security Hub を使用して委任管理を削除すると、Security Hub CSPM の委任管理も削除されます。同様に、Security Hub CSPM を使用して委任管理を削除すると、Security Hub の委任管理も削除されます。
-
-
Security Hub には、仕様に基づいて検出結果を自動的に変更してアクションを実行する機能が含まれており、Security Hub は次のタイプのオートメーションをサポートしています。
-
自動化ルール。定義された基準に基づいて、検出結果を自動的に更新し、検出結果を抑制し、検出結果をほぼリアルタイムでチケット発行ツールに送信します。
-
自動応答と修復。特定の検出結果とインサイトに対して実行する自動アクションを定義するカスタム EventBridge ルールを作成します。
-
-
Security Hub は、ポリシーを通じてすべてのメンバーアカウントとリージョンに Amazon Inspector を設定し、デプロイを通じて GuardDuty と Security Hub CSPM を設定できます。ポリシーは、アカウントとリージョンの AWS Organizations ポリシーを生成します。デプロイは、選択したアカウントとリージョンでセキュリティ機能を有効にする 1 回限りのアクションです。デプロイは、新しく有効化されたアカウントには適用されません。別の方法として、GuardDuty および Security Hub CSPM で新しいメンバーアカウントの機能を自動的に有効にすることもできます。
Amazon GuardDuty
Amazon GuardDuty
GuardDuty は、基本的なデータソースの提供に加えて、セキュリティ検出結果を特定するためのオプション機能を提供します。これには、EKS Protection、RDS Protection、S3 Protection、Malware Protection、Lambda Protection が含まれます。新しいディテクターの場合、これらのオプション機能は、手動で有効にする必要がある EKS Protection を除き、デフォルトで有効になっています。
-
GuardDuty S3 Protection を使用すると、GuardDuty はデフォルトの CloudTrail 管理イベントに加えてCloudTrail の Amazon S3 データイベントをモニタリングします。データイベントをモニタリングすることで、GuardDuty は S3 バケット内のデータに対する潜在的なセキュリティリスクについて、オブジェクトレベルの API オペレーションをモニタリングできます。
-
GuardDuty Malware Protection は、アタッチされた Amazon EC2 インスタンスまたはコンテナワークロードでマルウェアの存在を検出します。GuardDuty は、新しくアップロードされたオブジェクトまたは既存のオブジェクトの新しいバージョンをスキャンして、S3 バケット内の潜在的なマルウェアも検出します。
-
GuardDuty RDS Protection は、データベースのパフォーマンスに影響を与えることなく、Amazon Aurora データベースへのアクセスアクティビティをプロファイリングおよびモニタリングするように設計されています。
-
GuardDuty EKS Protection には、EKS 監査ログモニタリングと EKS ランタイムモニタリングが含まれます。EKS 監査ログモニタリングを使用すると、GuardDuty は Amazon EKS クラスターからの Kubernetes 監査ログをモニタリングし、悪意のあるアクティビティや疑わしいアクティビティがないか分析します。EKS Runtime Monitoring は、GuardDuty セキュリティエージェント (Amazon EKS アドオン) を使用して、個々の Amazon EKS ワークロードをランタイムで可視化します。GuardDuty セキュリティエージェントは、侵害されている可能性のある Amazon EKS クラスター内の特定のコンテナを識別するのに役立ちます。また、個々のコンテナから基盤となる Amazon EC2 ホストまたはより広範な AWS 環境に権限をエスカレートしようとする試みを検出することもできます。
GuardDuty には、データソース、複数のタイプの AWS リソース、および 内の時間にわたるマルチステージ攻撃を自動的に検出する拡張脅威検出と呼ばれる機能も用意されています AWS アカウント。GuardDuty は、シグナルと呼ばれるこれらのイベントを関連付けて、自身を AWS 環境に対する潜在的な脅威として示すシナリオを特定し、攻撃シーケンスの検出結果を生成します。これには、 AWS 認証情報の悪用に関連する侵害や、.GuardDuty でのデータ侵害の試みに関連する脅威シナリオが含まれます AWS アカウント。GuardDuty は、すべての攻撃シーケンスの検出タイプを重大と見なします。 GuardDuty この機能はデフォルトで有効になっており、追加コストは発生しません。
AWS SRA では、GuardDuty は を通じてすべてのアカウントで有効になっており AWS Organizations、すべての検出結果は GuardDuty 委任管理者アカウント (この場合は Security Tooling アカウント) の適切なセキュリティチームによって表示および実行可能です。GuardDuty のアクティブな検出結果はログアーカイブアカウントの中央 S3 バケットにエクスポートされるため、検出結果は 90 日以上保持できます。検出結果は委任管理者アカウントからエクスポートされ、同じリージョン内の関連付けられたメンバーアカウントからのすべての検出結果も含まれます。S3 バケット内の検出結果は、 AWS KMS カスタマーマネージドキーで暗号化されます。S3 バケットポリシーと KMS キーポリシーは、GuardDuty のみがリソースを使用できるように設定されています。
AWS Security Hub CSPM を有効にすると、GuardDuty の検出結果は Security Hub CSPM と Security Hub に自動的に流れます。Amazon Detective が有効な場合、GuardDuty の結果は Detective ログの取り込み処理に含まれます。GuardDuty と Detective は、クロスサービスユーザーワークフローをサポートしています。GuardDuty は、選択した結果から、その結果を調査するための厳選されたビジュアライゼーションセットを含む Detective ページにリダイレクトするリンクをコンソールから提供します。例えば、GuardDuty を Amazon EventBridge と統合して、新しい GuardDuty の検出結果への応答の自動化など、GuardDuty のベストプラクティスを自動化することもできます。 GuardDuty
実装例
AWS SRA コードライブラリ
AWS Config
AWS Config
を使用して AWS リソースの設定を評価できますAWS Config ルール。 は、マネージドルールと呼ばれるカスタマイズ可能な事前定義されたルールのライブラリ AWS Config を提供するか、独自のカスタムルールを記述できます。プロアクティブモード (リソースがデプロイされる前) または検出モード (リソースがデプロイされた後) AWS Config ルール で実行できます。リソースは、設定変更時、定期的、あるいはその両方で評価できます。
コンフォーマンスパックは、アカウントとリージョン、または の組織全体に単一のエンティティとしてデプロイできる AWS Config ルールと修復アクションのコレクションです AWS Organizations。コンフォーマンスパックは、 AWS Config マネージドルールまたはカスタムルールと修復アクションのリストを含む YAML テンプレートを作成することによって作成されます。 AWS 環境の評価を開始するには、サンプルコンフォーマンスパックテンプレートのいずれかを使用します。
AWS Config は と統合 AWS Security Hub CSPM して、 AWS Config マネージドルール評価とカスタムルール評価の結果を結果として Security Hub CSPM に送信します。
AWS Config ルール は と組み合わせて使用 AWS Systems Manager して、非準拠のリソースを効果的に修復できます。Systems Manager Explorer を使用して AWS アカウント 全体のAWS Configルールのコンプライアンスステータスを収集し AWS リージョン 、Systems Manager Automation ドキュメント (ランブック) を使用して非準拠 AWS Config ルールを解決します。実装の詳細については、ブログ記事「Remediate noncompliant AWS Config rules with AWS Systems Manager Automation runbooks
AWS Config アグリゲータは、 の複数のアカウント、リージョン、および組織にわたって設定およびコンプライアンスデータを収集します AWS Organizations。アグリゲータダッシュボードには、集約されたリソースの設定データが表示されます。インベントリとコンプライアンスダッシュボードは、組織全体、組織全体 AWS アカウント、 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 委任管理者アカウントは、すべてのメンバーアカウントからリソース設定とコンプライアンスデータを集約して、単一のビューを提供することもできます。Security Hub CSPM が有効で APIs 、少なくとも 1 つの AWS Config マネージドルールまたはカスタム AWS Config ルールが存在する場合 AWS Security Hub CSPM、 AWS AWS Config は検出結果を送信するようにネイティブに統合されています。
AWS SRA では、 AWS Config 委任管理者アカウントは Security Tooling アカウントです。 AWS Config 配信チャネルは、ログアーカイブアカウントの一元化された S3 バケットにリソース設定スナップショットを配信するように設定されています。Log Archive アカウントは中央ログリポジトリストアであるため、リソース設定の保存に使用されます。
設計上の考慮事項
-
AWS Config は、設定およびコンプライアンス変更の通知を Amazon EventBridge にストリーミングします。つまり、EventBridge のネイティブフィルタリング機能を使用してAWS Config イベントをフィルタリングし、特定のタイプの通知を特定のターゲットにルーティングできます。例えば、特定のルールやリソースタイプのコンプライアンス通知を特定の電子メールアドレスに送信したり、設定変更通知を外部 IT サービス管理 (ITSM) または構成管理データベース (CMDB) ツールにルーティングしたりすることができます。詳細については、AWS Config ベストプラクティス
のブログ投稿を参照してください。 -
AWS Config プロアクティブルール評価の使用に加えて、リソース設定のコンプライアンスをプロアクティブにチェックするpolicy-as-code評価ツールAWS CloudFormation Guardである を使用できます。 AWS CloudFormation Guard コマンドラインインターフェイス (CLI) には、ポリシーをコードとして表現するために使用できる宣言型のドメイン固有の言語 (DSL) が用意されています。さらに、 AWS CLI コマンドを使用して、 CloudFormation 変更セット、JSON ベースの Terraform 設定ファイル、Kubernetes 設定などの JSON 形式または YAML 形式の構造化データを検証できます。評価は、作成プロセスの一部として AWS CloudFormation Guard CLI
を使用してローカルで実行することも、デプロイパイプライン 内で実行することもできます。AWS Cloud Development Kit (AWS CDK) アプリケーションがある場合は、cdk-nag を使用してベストプラクティスをプロアクティブにチェックできます。
実装例
AWS SRA コードライブラリ
Amazon Security Lake
Amazon Security Lake
AWS SRA では、Security Lake の委任管理者アカウントとして Log Archive アカウントを使用することをお勧めします。委任管理者アカウントの設定の詳細については、「Security OU ‒ Log Archive account」セクションの「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 アカウントと、Lambda 関数またはクローラによってバックアップされたカスタムソースに対して、Security Lake の S3 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 テーブルからソースデータをクエリできます。クロスアカウントアクセスは、Lake Formation を使用してクエリアクセス用に自動的に設定されます。Security Tooling アカウントを Security Lake クエリアクセスサブスクライバーとして設定すると、そのアカウントには Security Lake アカウントのログへの読み取り専用アクセスが付与されます。このサブスクライバータイプを使用すると、Athena と AWS Glue テーブルは Security Lake Log Archive アカウントから AWS Resource Access Manager 、() を通じて Security Tooling アカウントと共有されますAWS RAM。この機能を有効にするには、クロスアカウントデータ共有設定をバージョン 3 に更新する必要があります。
サブスクライバーの作成の詳細については、Security Lake ドキュメントの「サブスクライバー管理」を参照してください。
カスタムソースを取り込むためのベストプラクティスについては、Security Lake ドキュメントの「カスタムソースからデータを収集する」を参照してください。
Amazon Quick Sight
設計上の考慮事項
アプリケーションチームがビジネス要件を満たすために Security Lake データへのクエリアクセスを必要とする場合、Security Lake 管理者はそのアプリケーションアカウントをサブスクライバー として設定する必要があります。
Amazon Macie
Amazon Macie
Macie は、 を通じてすべてのアカウントで有効になっています AWS Organizations。委任された管理者アカウント (この場合は Security Tooling アカウント) で適切なアクセス許可を持つプリンシパルは、どのアカウントでも Macie を有効にしたり停止にしたり、メンバーアカウントが所有するバケットに対して機密データ検出ジョブを作成したり、すべてのメンバーアカウントのすべてのポリシー結果を表示したりすることができます。機密データの結果は、機密結果ジョブを作成したアカウントでのみ表示できます。詳細については、Macie ドキュメントの「組織としての複数の Macie アカウントの管理」を参照してください。
Macie の検出結果は、レビューと分析 AWS Security Hub CSPM のために に流れます。また、Macie は Amazon EventBridge と統合して、アラート、セキュリティ情報およびイベント管理 (SIEM) システムへのフィード、自動修復などの結果への自動応答を促進します。
設計上の考慮事項
-
S3 オブジェクトが管理する AWS Key Management Service (AWS KMS) キーで暗号化されている場合は、Macie のサービスにリンクされたロールをキーユーザーとしてその KMS キーに追加して、Macie がデータをスキャンできるようにします。
-
Macie は Amazon S3 内のオブジェクトのスキャンに最適化されています。その結果、Amazon S3 に (永続的または一時的に) 配置できる Macie がサポートするオブジェクトタイプ は、機密データをスキャンできます。つまり、Amazon Relational Database Service (Amazon RDS) または Amazon Aurora データベースの定期的なスナップショットエクスポート、エクスポートされた Amazon DynamoDB テーブル
、またはネイティブまたはサードパーティーアプリケーションから抽出されたテキストファイルなど、他のソースからのデータを Amazon S3 に移動して Macie で評価することができます。
実装例
AWS SRA コードライブラリ
IAM Access Analyzer
AWS クラウド 導入ジャーニーを加速し、イノベーションを続けるには、きめ細かなアクセス (アクセス許可) を厳密に制御し、アクセスの拡散を防ぎ、アクセス許可を効果的に使用することが重要です。過剰で未使用のアクセスはセキュリティ上の課題となり、企業が最小特権の原則を強制することが困難になります。この原則は、セキュリティ要件と運用要件およびアプリケーション開発要件のバランスを取るための IAM アクセス許可を継続的に適切なサイズにすることを含む、重要なセキュリティアーキテクチャの柱です。この取り組みには、中央セキュリティチーム、Cloud Center of Excellence (CCoE) チーム、分散開発チームなど、複数のステークホルダーペルソナが含まれます。
AWS Identity and Access Management Access Analyzer
IAM Access Analyzer の外部アクセスアナライザーの検出結果は、Amazon S3 バケットや IAM ロールなど、外部エンティティと共有されている AWS 組織やアカウント内のリソースを識別するのに役立ちます。選択した AWS 組織またはアカウントは、信頼ゾーンと呼ばれます。アナライザーは自動推論
同様に、IAM Access Analyzer の内部アクセスアナライザーの検出機能は、 AWS 組織内および組織またはアカウント内のプリンシパルと共有されているアカウント内のリソースを特定するのに役立ちます。この分析は、組織内の意図したプリンシパルのみが指定されたリソースにアクセスできるようにすることで、最小特権の原則をサポートします。これは有料機能であり、検査するリソースの明示的な設定が必要です。この機能は、設計上内部的にもロックダウンする必要がある特定の機密リソースを慎重にモニタリングするために使用します。
IAM Access Analyzer の検出結果は、組織やアカウントで AWS 付与された未使用のアクセスを特定するのにも役立ちます。
-
未使用の IAM ロール – 指定された使用期間内にアクセスアクティビティがないロール。
-
未使用の IAM ユーザー、認証情報、アクセスキー – IAM ユーザーに属する認証情報で、 AWS のサービス および リソースへのアクセスに使用されます。
-
未使用の IAM ポリシーとアクセス許可 – 指定された使用期間内にロールによって使用されなかったサービスレベルおよびアクションレベルのアクセス許可。IAM Access Analyzer は、ロールにアタッチされたアイデンティティベースのポリシーを使用して、それらのロールがアクセスできるサービスとアクションを決定します。アナライザーは、すべてのサービスレベルのアクセス許可に対する未使用のアクセス許可のレビューを提供します。
IAM Access Analyzer から生成された検出結果を使用して、組織のポリシーとセキュリティ標準に基づいて、意図しないアクセスや未使用のアクセスを可視化し、修復できます。修復後、これらの検出結果は次にアナライザーが実行されるときに解決済みとしてマークされます。検出結果が意図的な場合は、IAM Access Analyzer でアーカイブ済みとしてマークし、セキュリティリスクが大きい他の検出結果に優先順位を付けることができます。さらに、アップアーカイブルールを設定して、特定の検出結果を自動的にアーカイブできます。例えば、定期的にアクセスを許可する特定の Amazon S3 バケットに関する検出結果を自動的にアーカイブするためのアーカイブルールを作成できます。
ビルダーは、IAM Access Analyzer を使用して、開発およびデプロイ (CI/CD) プロセスの早い段階で自動化された IAM ポリシーチェックを実行し、企業のセキュリティ標準に準拠できます。IAM Access Analyzer のカスタムポリシーチェックとポリシーレビューを と統合 AWS CloudFormation して、開発チームの CI/CD パイプラインの一部としてポリシーレビューを自動化できます。これには、以下が含まれます。
-
IAM ポリシーの検証 – IAM Access Analyzer は、IAM ポリシーの文法と AWS ベストプラクティスに照らしてポリシーを検証します。セキュリティ警告、エラー、一般的な警告、ポリシーの提案など、ポリシー検証チェックの結果を表示できます。現在、100 を超えるポリシー検証チェックが利用可能であり、 AWS Command Line Interface (AWS CLI) と APIs を使用して自動化できます。
-
IAM カスタムポリシーチェック – IAM Access Analyzer カスタムポリシーチェックは、指定されたセキュリティ標準に照らしてポリシーを検証します。カスタムポリシーチェックでは、自動推論を使用して、企業のセキュリティ基準を満たすためのより高いレベルの保証を提供します。カスタムポリシーチェックのタイプは次のとおりです。
-
参照ポリシーと照合する: ポリシーを編集するときに、ポリシーの既存のバージョンなどの参照ポリシーと比較して、更新が新しいアクセスを許可するかどうかを確認できます。CheckNoNewAccessAPI は、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 によって追跡されず、生成されたポリシーに含まれません。
IAM Access Analyzer は、 の委任管理者機能を通じて Security Tooling アカウントにデプロイされます AWS Organizations。委任された管理者には、 AWS 組織を信頼ゾーンとして持つアナライザーを作成および管理するためのアクセス許可があります。
設計上の考慮事項
アカウントスコープの結果 (アカウントが信頼境界として機能する場所) を取得するには、各メンバーアカウントにアカウントスコープのアナライザーを作成します。これは、アカウントパイプラインの一部として実行できます。アカウントスコープの検出結果は、メンバーアカウントレベルで Security Hub CSPM に流れます。そこから、Security Hub CSPM 委任管理者アカウント (Security Tooling) に流れます。
実装例
-
AWS SRA コードライブラリ
は、IAM Access Analyzer のサンプル実装を提供します。委任管理者アカウント内で組織レベルのアナライザーを設定し、各アカウント内でアカウントレベルのアナライザーを設定する方法を示します。 -
カスタムポリシーチェックをビルダーワークフローに統合する方法については、 AWS ブログ記事「IAM Access Analyzer カスタムポリシーチェックの紹介
」を参照してください。
AWS Firewall Manager
AWS Firewall Manager
Firewall Manager は、少数の特定のアカウントやリソースではなく AWS 組織全体を保護する場合や、保護する新しいリソースを頻繁に追加する場合に特に便利です。Firewall Manager は、セキュリティポリシーを使用して、デプロイする必要がある関連するルール、保護、アクション、および含めるか除外するアカウントとリソース (タグで示される) を含む、一連の設定を定義できます。細分化された柔軟な設定を作成しながら、多数のアカウントと VPC に制御をスケールアウトさせることが可能です。これらのポリシーは、新しいアカウントとリソースが作成された場合でも、設定したルールを自動的かつ一貫して適用します。Firewall Manager は を通じてすべてのアカウントで有効になり AWS Organizations、設定と管理は Firewall Manager の委任管理者アカウント (この場合は Security Tooling アカウント) の適切なセキュリティチームによって実行されます。
保護するリソース AWS リージョン を含む各 AWS Config に対して を有効にする必要があります。すべてのリソース AWS Config に対して を有効にしない場合は、使用する Firewall Manager ポリシーのタイプに関連付けられているリソースに対して有効にする必要があります。 AWS Security Hub CSPM と Firewall Manager の両方を使用すると、Firewall Manager は自動的に検出結果を Security Hub CSPM に送信します。Firewall Manager は、コンプライアンス違反のリソースと検出した攻撃の検出結果を作成し、その検出結果を Security Hub CSPM に送信します。Firewall Manager ポリシーを設定すると AWS WAF、すべての対象アカウントのウェブアクセスコントロールリスト (ウェブ ACLs) のログ記録を一元的に有効にし、ログを 1 つのアカウントで一元化できます。
Firewall Manager では、組織のファイアウォールリソースを管理できる管理者を 1 人または複数持つことができます。複数の管理者を割り当てる場合、制限的な管理範囲条件を適用して、各管理者が管理できるリソース (アカウント、OUs、リージョン、ポリシータイプ) を定義できます。これにより、組織内のさまざまな管理者に役割を割り当てる上での柔軟性が提供され、最小権限の原則を維持しやすくなります。SRA は、Security Tooling AWS アカウントに委任された完全な管理スコープを持つ 1 人の管理者を使用します。
設計上の考慮事項
AWS 組織内の個々のメンバーアカウントのアカウントマネージャーは、特定のニーズに合わせて Firewall Manager マネージドサービスで追加のコントロール ( AWS WAF ルールや Amazon VPC セキュリティグループなど) を設定できます。
実装例
AWS SRA コードライブラリ
Amazon EventBridge
Amazon EventBridge
設計上の考慮事項
-
EventBridge は、さまざまなターゲットにイベントをルーティングできます。セキュリティアクションを自動化するための重要なパターンの 1 つは、特定のイベントを個々の AWS Lambda レスポンダーに接続し、適切なアクションを実行することです。例えば、特定の状況では、EventBridge を使用して、バケットポリシーを修正し、公開許可を削除する Lambda レスポンダーに公開 S3 バケットの結果をルーティングしたい場合があります。これらのレスポンダーは、調査プレイブックとランブックに統合して、対応アクティビティを調整できます。
-
セキュリティ運用チームが成功するためのベストプラクティスは、セキュリティイベントと結果事項のフローを、チケッティングシステム、バグ/イシューシステム、またはその他のセキュリティ情報およびイベント管理 (SIEM) システムなどの通知およびワークフローシステムに統合することです。これにより、電子メールおよび静的レポートからワークフローを取り除き、イベントや結果をルーティング、エスカレーション、管理することが可能になります。EventBridge の柔軟なルーティング機能は、この統合を可能にする強力なイネーブラーです。
Amazon Detective
Amazon Detective
Detective は Amazon Security Lake と統合され、セキュリティアナリストが Security Lake に保存されているログをクエリおよび取得できるようにします。この統合を使用して、Detective でセキュリティ調査を実行中に Security Lake に保存されている CloudTrail ログと Amazon VPC フローログから追加情報を取得できます。
Detective は、Amazon GuardDuty GuardDuty によって検出された検出結果も取り込みます。アカウントで Detective を有効にすると、そのアカウントがビヘイビアグラフの管理者アカウントになります。Detective を有効にする前に、アカウントが GuardDuty に登録されてから 48 時間以上が経過していることを確認してください。この要件を満たしていない場合、DetectiveDetective を有効にすることはできません。
Detective のその他のオプションのデータソースには、Amazon EKS 監査ログと が含まれます AWS Security Hub CSPM。Amazon EKS 監査ログデータソースは、Amazon EKS クラスター、Kubernetes ポッド、コンテナイメージ、Kubernetes サブジェクトのエンティティタイプに関して提供される情報を強化します。Security Hub データソースはAWS セキュリティ検出結果の一部であり、製品間の検出結果を Security Hub に関連付け、Detective に取り込みます。
Detective は、単一のセキュリティ侵害イベントに関連する複数の検出結果を検出結果グループに自動的にグループ化します。脅威アクターは通常、時間やリソースにまたがる複数のセキュリティ検出結果につながる一連のアクションを実行します。したがって、検出結果グループは、複数のエンティティと検出結果を含む調査の開始点である必要があります。また、Detective は、検出結果グループを自動的に分析する生成 AI を使用して検出結果グループの概要を提供し、セキュリティ調査の迅速化に役立つ自然言語でのインサイトを提供します。
Detective は と統合されます AWS Organizations。組織管理アカウントは、メンバーアカウントを Detective 管理者アカウントとして委任します。SRA では、これは Security Tooling AWS アカウントです。Detective 管理者アカウントは、組織内のすべての現在のメンバーアカウントを Detective メンバーアカウントとして自動的に有効にし、 AWS 組織に追加された新しいメンバーアカウントを追加することもできます。Detective 管理者アカウントは、現在 AWS 組織には存在しないが、同じリージョンにあるメンバーアカウントを招待して、プライマリアカウントの動作グラフにデータを提供することもできます。メンバーアカウントが招待を承諾して有効になると、Detective は、メンバーアカウントのデータを取り込み、その動作グラフに抽出し始めます。
設計上の考慮事項
GuardDuty および AWS Security Hub CSPM コンソールから Detective 検出結果プロファイルに移動できます。これらのリンクは、調査プロセスを合理化するのに役立ちます。アカウントは、Detective とピボット元のサービス (GuardDuty または Security Hub CSPM) の両方の管理アカウントである必要があります。サービスのプライマリアカウントが同じであれば、統合リンクはシームレスに機能します。
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 種類の証拠を収集します。自動化される証拠には、 AWS Config と からのコンプライアンスチェックの証拠 AWS Security Hub CSPM、 からの管理イベントの証拠 AWS CloudTrail、 AWS service-to-service API コールの設定の証拠の 3 種類があります。自動化できない証拠については、Audit Manager では手動証拠をアップロードできます。
デフォルトでは、Audit Manager のデータは AWS マネージドキーを使用して暗号化されます。 AWS SRA は、暗号化にカスタマーマネージドキーを使用して、論理アクセスをより細かく制御します。また、Audit Manager が評価レポートを発行 AWS リージョン する で S3 バケットを設定する必要があります。このバケットはカスタマーマネージドキーで暗号化し、Audit Manager のみがレポートを発行できるようにバケットポリシーを設定する必要があります。
注記
Audit Manager は、特定のコンプライアンス標準および規制への準拠の検証に関連する証拠の収集を支援します。ただし、コンプライアンスは評価されません。したがって、Audit Manager を通じて収集された証拠には、監査に必要な運用プロセスの詳細が含まれていない場合があります。Audit Manager は、法律顧問やコンプライアンスの専門家に代わるものではありません。評価対象のコンプライアンスフレームワーク (複数可) の認定を受けているサードパーティーの評価機関のサービスを利用することをお勧めします。
Audit Manager の評価は、 AWS 組織内の複数のアカウントで実行できます。Audit Manager は証拠を収集し、 の委任管理者アカウントに統合します AWS Organizations。この監査機能は、主にコンプライアンスチームと内部監査チームによって使用され、 への読み取りアクセスのみが必要です AWS アカウント。
設計上の考慮事項
-
Audit Manager は AWS Security Hub CSPM、、、 などの他の AWS セキュリティサービスを補完 AWS Config して AWS Security Hub、リスク管理フレームワークの実装を支援します。Audit Manager は独立したリスク保証機能を提供しますが、Security Hub CSPM AWS Config はリスクの監視に役立ち、コンフォーマンスパックはリスクの管理に役立ちます。内部監査機関 (IIA)
によって開発された 3 行モデル に精通している監査プロフェッショナルは、この の組み合わせが 3 つの防御線をカバーする AWS のサービス のに役立つことに注意してください。詳細については、 AWS クラウド 「 オペレーションと移行」ブログの「 - 2 部構成のブログシリーズ 」を参照してください。 -
Audit Manager が Security Hub CSPM の証拠を収集するには、両方のサービスの委任管理者アカウントが同じである必要があります AWS アカウント。このため、SRA AWS では、Security Tooling アカウントが Audit Manager の委任管理者になります。
AWS Artifact
AWS Artifact
AWS Artifact は、委任管理機能をサポートしていません。代わりに、この機能を監査チームとコンプライアンスチームに関連する Security Tooling アカウントの IAM ロールのみに制限して、必要に応じてそれらのレポートをダウンロード、レビュー、外部監査人に提供できます。さらに、IAM ポリシーを通じて特定の IAM ロールが特定の AWS Artifact レポートのみにアクセスできるように制限することもできます。IAM ポリシーのサンプルについては、 AWS Artifact ドキュメントを参照してください。
設計上の考慮事項
監査チームとコンプライアンスチーム AWS アカウント 専用の を持つことを選択した場合、Security Tooling アカウントとは別のセキュリティ監査アカウント AWS Artifact でホストできます。 AWS Artifact レポートは、組織が文書化されたプロセスに従っているか、特定の要件を満たしていることを示す証拠を提供します。監査アーティファクトは、システム開発ライフサイクル全体で収集およびアーカイブされ、内部または外部の監査と評価の証拠として使用できます。
AWS KMS
AWS Key Management Service
1 つのデプロイオプションは、 AWS KMS キーと IAM ポリシーの組み合わせを使用して、アプリケーションリソースによってアプリケーションアカウントのキーを使用する機能を委任しながら、キー管理の責任を 1 つのアカウントに一元化することです。このアプローチは安全かつ簡単に管理できますが、スロットリング制限、アカウントサービス制限、セキュリティチームが運用上のキー管理タスクに溜まっているため AWS KMS 、ハードルが発生する可能性があります。もう 1 つのデプロイオプションは、複数のアカウントへの配置 AWS KMS を許可する分散モデルを用意し、特定のアカウントのインフラストラクチャとワークロードを担当するユーザーに独自のキーの管理を許可することです。このモデルにより、ワークロードチームは暗号化キーの使用に対する制御、柔軟性、俊敏性が向上します。また、API の制限を回避し、影響範囲を 1 AWS アカウント つのみに制限し、レポート、監査、その他のコンプライアンス関連のタスクを簡素化するのに役立ちます。分散モデルでは、分散キーが同じ方法で管理され、確立されたベストプラクティスとポリシーに従ってキーの使用 AWS KMS が監査されるように、ガードレールをデプロイして適用することが重要です。詳細については、ホワイトペーパーAWS Key Management Service 「ベストプラクティス
Security Tooling アカウント AWS KMS では、組織が管理する AWS CloudTrail AWS 組織の証跡など、一元化されたセキュリティサービスの暗号化を管理するために使用されます。
AWS Private CA
AWS Private Certificate Authority (AWS Private CA) は、EC2 インスタンス、コンテナ、IoT デバイス、オンプレミスリソースのプライベートエンドエンティティ TLS 証明書のライフサイクルを安全に管理するのに役立つマネージドプライベート CA サービスです。これにより、実行中のアプリケーションへの暗号化された TLS 通信が可能になります。を使用すると AWS Private CA、独自の CA 階層 (ルート CA、下位 CAs、エンドエンティティ証明書) を作成し、証明書を発行して内部ユーザー、コンピュータ、アプリケーション、サービス、サーバー、およびその他のデバイスを認証し、コンピュータコードに署名できます。プライベート CA によって発行された証明書は、インターネットではなく AWS 組織内でのみ信頼されます。
パブリックキーインフラストラクチャ (PKI) またはセキュリティチームは、すべての PKI インフラストラクチャの管理を担当できます。これには、プライベート CA の管理と作成が含まれます。ただし、ワークロードチームが証明書要件をセルフサービスできるようにするプロビジョニングが必要です。SRA は、ルート CA AWS が Security Tooling アカウント内でホストされている一元的な CA 階層を示しています。これにより、ルート CA は PKI 全体の基盤であるため、セキュリティチームは厳格なセキュリティコントロールを適用できます。ただし、プライベート CA からのプライベート証明書の作成は、 AWS Resource Access Manager (AWS RAM) を使用して CA をアプリケーションアカウントと共有することで、アプリケーション開発チームに委任されます。 は、クロスアカウント共有に必要なアクセス許可 AWS RAM を管理します。これにより、すべてのアカウントでプライベート CA が不要になり、よりコスト効率の高いデプロイ方法が提供されます。ワークフローと実装の詳細については、ブログ記事「 AWS RAM を使用して AWS Private CA クロスアカウントを共有する方法
注記
AWS Certificate Manager (ACM) は、 で使用するパブリック TLS 証明書のプロビジョニング、管理、デプロイにも役立ちます AWS のサービス。この機能をサポートするには、ACM がパブリック証明書 AWS アカウント を使用する に存在する必要があります。これは、このガイドの「アプリケーションアカウント」セクションで後ほど説明します。
設計上の考慮事項
-
を使用すると AWS Private CA、最大 5 つのレベルで認証機関の階層を作成できます。また、それぞれ独自のルートを持つ複数の階層を作成することもできます。 AWS Private CA 階層は、組織の PKI 設計に従う必要があります。ただし、CA 階層を増やすと、証明書パス内の証明書の数が増え、その結果、エンドエンティティ証明書の検証時間が長くなることに注意してください。明確に定義された 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 Inspector は、リソースを変更するたびにリソースを自動的にスキャンすることで、リソースのライフサイクル全体を通じて環境を継続的に評価します。リソースの再スキャンを開始するイベントには、EC2 インスタンスへの新しいパッケージのインストール、パッチのインストール、リソースに影響を与える新しい一般的な脆弱性と露出 (CVE) レポートの発行が含まれます。Amazon Inspector は、EC2 インスタンスのオペレーティングシステムの Center of Internet Security (CIS) Benchmark 評価をサポートしています。
Amazon Inspector は、コンテナイメージ評価のために Jenkins や TeamCity などの開発者ツールと統合されています。継続的インテグレーションおよび継続的デリバリー (CI/CD) ツール内のソフトウェアの脆弱性についてコンテナイメージを評価し、ソフトウェア開発ライフサイクルの以前の時点にセキュリティをプッシュできます。評価結果は CI/CD ツールのダッシュボードで利用できるため、ブロックされたビルドやコンテナレジストリへのイメージプッシュなどの重要なセキュリティ問題に応じて自動アクションを実行できます。がアクティブな場合は AWS アカウント、CI/CD ツールマーケットプレイスから Amazon Inspector プラグインをインストールし、Amazon Inspector サービスをアクティブ化することなく Amazon Inspector スキャンをビルドパイプラインに追加できます。この機能は、オンプレミス AWS、ハイブリッドクラウドなど、どこでもホストされる CI/CD ツールで動作するため、すべての開発パイプラインで 1 つのソリューションを一貫して使用できます。Amazon Inspector がアクティブ化されると、すべての EC2 インスタンス、Amazon ECR および CI/CD ツールのコンテナイメージ、Lambda 関数を大規模に自動的に検出し、既知の脆弱性を継続的にモニタリングします。
Amazon Inspector のネットワーク到達可能性の検出結果は、インターネットゲートウェイ、VPC ピアリング接続、仮想ゲートウェイ経由の仮想プライベートネットワーク (VPNs) などの VPC エッジとの間の EC2 インスタンスのアクセシビリティを評価します。これらのルールは、 AWS ネットワークのモニタリングを自動化し、管理ミスのセキュリティグループ、アクセスコントロールリスト (ACLs)、インターネットゲートウェイなどを通じて EC2 インスタンスへのネットワークアクセスが誤って設定される可能性のある場所を特定するのに役立ちます。さらなる詳細については、Amazon Inspector documentation を参照してください。
Amazon Inspector が脆弱性またはオープンネットワークパスを特定すると、調査できる検出結果が生成されます。検出結果には、リスクスコア、影響を受けるリソース、修復推奨事項など、脆弱性に関する包括的な詳細が含まれます。リスクスコアは環境に合わせて特別に調整され、up-to-date CVE 情報を、ネットワークアクセシビリティやエクスプロイト可能性情報などの時間的および環境的要因と関連付けて、コンテキストに応じた検出結果を提供することで計算されます。
Amazon Inspector Code Security は、ファーストパーティアプリケーションソースコード、サードパーティーアプリケーションの依存関係、Infrastructure as Code (IaC) の脆弱性をスキャンします。Code Security をアクティブ化した後、スキャンする頻度、スキャンタイプ、リポジトリを決定するためのスキャン設定を作成してコードリポジトリに適用できます。Code Security は、静的アプリケーションセキュリティテスト (SAST)、ソフトウェアコンポジション分析 (SCA)、IaC スキャンをサポートしています。頻度を設定するには、オンデマンド、コード変更時、または定期的にスキャンを定義できます。コードスキャンでは、コードスニペットをキャプチャして検出された脆弱性をハイライトします。コードスニペットは KMS キーで暗号化されて保存されます。組織の委任管理者は、メンバーアカウントに属するコードスニペットを表示できません。ソースコードマネージャー (SCMs) を Code Security と統合すると、Amazon Inspector コンソールにすべてのコードリポジトリがプロジェクトとして一覧表示されます。Code Security は、各リポジトリのデフォルトブランチのみをモニタリングします。Amazon Inspector は、開発者が作業する場所で特定のコード修正の推奨事項を直接提供することで、セキュリティ修復を合理化します。SCM との双方向統合により、重要な検出結果と高い検出結果に対するプルリクエスト (PRs) とマージリクエスト (MRs) 内のコメントとして修正が自動的に提案され、ワークフローを中断することなく対処すべき最も重要な脆弱性をデベロッパーに警告します。
脆弱性をスキャンするには、 AWS Systems Manager エージェント (SSMAgent) AWS Systems Managerを使用して EC2 インスタンスを管理する必要があります。 Amazon ECR または Lambda 関数の EC2 インスタンスのネットワーク到達可能性やコンテナイメージの脆弱性スキャンにエージェントは必要ありません。
Amazon Inspector は と統合 AWS Organizations されており、委任管理をサポートしています。SRA AWS では、Security Tooling アカウントが Amazon Inspector の委任管理者アカウントになります。Amazon Inspector の委任管理者アカウントは、 AWS 組織のメンバーの検出結果データと特定の設定を管理できます。これには、すべてのメンバーアカウントの集計結果の詳細の表示、メンバーアカウントのスキャンの有効化または無効化、 AWS 組織内のスキャンされたリソースの確認が含まれます。
設計上の考慮事項
-
Amazon Inspector は、両方のサービスが有効になっていると、 AWS Security Hub CSPM および Security Hub と自動的に統合されます。この統合を使用して、Amazon Inspector から Security Hub CSPM にすべての検出結果を送信し、セキュリティ体制の分析にそれらの検出結果を含めることができます。
-
Amazon Inspector は、検出結果、リソースカバレッジの変更、個々のリソースの初期スキャンのイベントを Amazon EventBridge に自動的にエクスポートし、オプションで Amazon Simple Storage Service (Amazon S3) バケットに自動的にエクスポートします。アクティブな検出結果を S3 バケットにエクスポートするには、Amazon Inspector が検出結果を暗号化するために使用できる AWS KMS キーと、Amazon Inspector がオブジェクトをアップロードできるようにするアクセス許可を持つ S3 バケットが必要です。 Amazon Inspector EventBridge の統合により、既存のセキュリティおよびコンプライアンスワークフローの一環として、検出結果をほぼリアルタイムでモニタリングおよび処理できます。EventBridge イベントは、元のメンバーアカウントに加えて、Amazon Inspector の委任管理者アカウントに発行されます。
-
Amazon Inspector Code Security と GitHub SaaS、GitHub Enterprise Cloud、GitHub Enterprise Server の統合には、パブリックインターネットアクセスが必要です。
実装例
AWS SRA コードライブラリ
AWS Security Incident Response
AWS Security Incident Response
AWS SRA では、 AWS Security Incident Response は委任管理者アカウントとして Security Tooling アカウントにデプロイされます。Security Tooling アカウントは、セキュリティサービスを運用し、セキュリティアラートとレスポンスを自動化するアカウントの目的と一致するため、選択されます。Security Tooling アカウントは、Security Hub CSPM と GuardDuty の委任管理者アカウントとしても機能します。これにより、ワークフロー管理を簡素化 AWS Security Incident Responseできます。 AWS Security Incident Response は と連携するように設定されているため AWS Organizations、Security Tooling アカウントから組織のアカウント全体のインシデント対応を管理できます。
AWS Security Incident Response は、インシデント対応ライフサイクルの次のフェーズを実装するのに役立ちます。
-
準備: 封じ込めアクションの対応計画と SSM ドキュメントを作成して維持します。
-
検出と分析: セキュリティの検出結果を自動的に分析し、インシデントの重大度を判断します。
-
検出と分析: サービスがサポートするケースを開き、 AWS CIRT に連絡してサポートを依頼します。CIRT は、アクティブなセキュリティイベント中にサポートを提供する個人のグループです。
-
封じ込めと根絶: SSM ドキュメントを介して自動封じ込めアクションを実行します。
-
インシデント後アクティビティ: インシデントの詳細を文書化し、インシデント後分析を実行します。
AWS Security Incident Response を使用してセルフマネージドケースを作成することもできます。 AWS Security Incident Response は、アカウントまたはリソースに影響を与える可能性のある何かを認識したり、対処したりする必要がある場合に、アウトバウンド通知またはケースを作成できます。この機能は、サブスクリプションの一部としてプロアクティブレスポンスとアラートのトリアージワークフローを有効にする場合にのみ使用できます。
設計上の考慮事項
-
を実装するときは AWS Security Incident Response、自動応答アクションを本番環境で有効にする前に、慎重に確認してテストしてください。自動化はインシデント対応を高速化できますが、自動アクションを不適切に設定すると、正当なワークロードに影響を与える可能性があります。
-
で SSM ドキュメントを使用して AWS Security Incident Response 、一般的なインシデントタイプのサービスの組み込みベストプラクティスを維持しながら、組織固有の封じ込め手順を実装することを検討してください。
-
VPC AWS Security Incident Response で を使用する場合は、Systems Manager やその他の統合サービス用に適切な VPC エンドポイントが設定されており、プライベートサブネットで封じ込めアクションが有効になっていることを確認してください。
すべての 内に共通のセキュリティサービスをデプロイする AWS アカウント
このリファレンスの前半の「組織全体にセキュリティサービス AWS を適用する」セクションでは、 を保護するセキュリティサービスが強調表示され AWS アカウント、これらのサービスの多くは 内で設定および管理できることに注意してください AWS Organizations。これらのサービスの一部はすべてのアカウントにデプロイする必要があり、SRA AWS に表示されます。これにより、一貫したガードレールの設定が有効になり、 AWS 組織全体の集中的なモニタリング、管理、ガバナンスが可能になります。
Security Hub CSPM、GuardDuty AWS Config、IAM Access Analyzer、および CloudTrail 組織の証跡は、すべてのアカウントに表示されます。最初の 3 つは、「管理アカウント、信頼されたアクセス、委任された管理者」セクションで前述した委任管理者機能をサポートしています。CloudTrail は現在、別のアグリゲーションメカニズムを使用しています。
AWS SRA GitHub コードリポジトリ
設計上の考慮事項
-
特定のアカウント設定では、追加のセキュリティサービスが必要になる場合があります。例えば、S3 バケットを管理するアカウント (アプリケーションアカウントとログアーカイブアカウント) には Amazon Macie も含め、これらの一般的なセキュリティサービスで CloudTrail S3 データイベントのログ記録を有効にすることを検討する必要があります。(Macie は、一元化された設定とモニタリングによる委任管理をサポートします。) もう 1 つの例は Amazon Inspector です。これは、EC2 インスタンスまたは Amazon ECR イメージをホストするアカウントにのみ適用されます。
-
このセクションで前述したサービスに加えて、 AWS SRA には、 AWS Organizations 統合と委任された管理者機能をサポートする Amazon Detective と の AWS Audit Manager 2 つのセキュリティに焦点を当てたサービスが含まれています。ただし、これらのサービスは以下のシナリオで最適に使用されていることがわかっているため、アカウントベースラインの推奨サービスには含まれていません。
-
これらの機能を実行する専用のチームまたはリソースグループがあります。Detective はセキュリティアナリストチームが最適に活用でき、Audit Manager は内部監査またはコンプライアンスチームに役立ちます。
-
プロジェクトの開始時に GuardDuty や Security Hub CSPM などのコアツールセットに重点を置き、追加の機能を提供するサービスを使用してこれらを構築したいと考えています。
-