翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
セキュリティ OU — ログアーカイブアカウント
| 簡単なアンケートを実施して |
次の図は、Log Archive アカウントで設定されている AWS セキュリティサービスを示しています。
ログアーカイブアカウントは、セキュリティ関連のすべてのログとバックアップの取り込みとアーカイブ専用です。一元化されたログを使用すると、Amazon S3 オブジェクトアクセス、ID による不正なアクティビティ、IAM ポリシーの変更、および機密リソースで実行されるその他の重要なアクティビティをモニタリング、監査、およびアラートを実行できます。セキュリティの目的はシンプルです。これは不変のストレージであり、制御、自動化、モニタリングされたメカニズムによってのみ、イミュータブルに保存、アクセスされ、耐久性のために構築されている必要があります（適切なレプリケーションおよびアーカイブプロセスの使用などによる）。ログとログ管理プロセスの完全性と可用性を保護するための詳細な制御を実装できます。アクセスに使用する最小権限のロールを割り当てたり、管理対象の AWS KMS キーでログを暗号化したりするなどの予防的統制に加えて、AWS Config などの探偵的統制を使用して、この権限のコレクションを監視 (および警告、修正) して、予期しない変更がないか確認します。
設計上の考慮事項
-
インフラストラクチャ、オペレーション、およびワークロードチームが使用するオペレーションログデータは、多くの場合、セキュリティ、監査、コンプライアンスチームが使用するログデータと重複します。オペレーションログデータを ログアーカイブアカウントに統合することをお勧めします。特定のセキュリティおよびガバナンス要件に基づいて、このアカウントに保存されたオペレーションログデータをフィルタリングする必要がある場合があります。また、ログアーカイブアカウントのオペレーションログデータにアクセスできるユーザーを指定する必要がある場合もあります。
ログの種類
AWS SRA に表示される主なログには、 CloudTrail (組織証跡)、Amazon VPC フローログ、Amazon CloudFront と AWS WAF からのアクセスログ、Amazon Route 53 からの DNS ログが含まれます。これらのログは、ユーザー、ロール、AWS サービス、またはネットワークエンティティ（たとえば IP アドレスによって識別される）によって実行された（または試みられた）アクションの監査に役立ちます。他のログタイプ（アプリケーションログやデータベースログなど）もキャプチャ、アーカイブすることができます。ログソースおよびログのベストプラクティスの詳細については、各サービスのセキュリティドキュメント を参照してください。
中央ログストアとしての Amazon S3
多くの AWS サービスは、デフォルトで、または排他的に Amazon S3 に情報を記録します。Amazon S3 に情報を記録するサービスの例としては、AWS、Amazon VPC フローログ、AWS Config、Elastic Load Balancing などがあります。 CloudTrailつまり、ログの整合性は S3 オブジェクトの整合性によって実現され、ログの機密性は S3 オブジェクトのアクセスコントロールによって実現され、ログの可用性は S3 オブジェクトロック、S3 オブジェクトバージョン、S3 ライフサイクルルールによって実現されます。専用アカウントにある集中管理専用のS3バケットに情報を記録することで、これらのログをわずか数個のバケットで管理し、厳格なセキュリティ制御、アクセス、職務分掌を実施できます。
AWS SRA では、Amazon S3 に保存されているプライマリログの送信元となるため CloudTrail、このセクションではそれらのオブジェクトを保護する方法について説明します。このガイダンスは、独自のアプリケーションまたは他の AWS サービスによって作成されたその他の S3 オブジェクトにも適用されます。Amazon S3 に高い整合性、強力なアクセス制御、および自動的な保持または破棄を必要とするデータがある場合は、いつでもこれらのパターンを適用してください。
S3 バケットにアップロードされるすべての新しいオブジェクト ( CloudTrail ログを含む) は、Amazon S3 が管理する暗号化キー (SSE-S3) による Amazon サーバー側の暗号化を使用してデフォルトで暗号化されます。これは保存中のデータを保護するのに役立ちますが、アクセスコントロールは IAM ポリシーによってのみ制御されます。マネージドセキュリティレイヤーを追加するには、すべてのセキュリティ S3 バケットで、管理する AWS KMS キー (SSE-KMS) によるサーバー側の暗号化 (SSE-KMS) を使用できます。これにより、第 2 レベルのアクセス制御が追加されます。ログファイルを読み取るには、ユーザーは S3 オブジェクトの Amazon S3 読み取り権限と、関連するキーポリシーによる復号化を許可する IAM ポリシーまたはロールの両方を持っている必要があります。
Amazon S3 CloudTrail に保存されているログオブジェクトの整合性を保護または検証するための 2 つのオプションがあります。 CloudTrail ログファイルの整合性を検証して、 CloudTrail ログファイルが配信後に変更されたか削除されたかを判断します。もう 1 つのオプションは S3 オブジェクトロックです。
S3 バケット自体を保護することに加えて、ロギングサービス (例: CloudTrail) と Log Archive アカウントの最小権限の原則に従うことができます。たとえば、AWS マネージド IAM AWSCloudTrail_FullAccess ポリシーによって付与されたアクセス権限を持つユーザーは、自分の AWS アカウントで最も機密性が高く重要な監査機能を無効化または再設定できます。この IAM ポリシーの適用は、できるだけ少ない人数に制限してください。
AWS Config や AWS IAM Access Analyzer が提供するような検出的統制を使用して、この広範囲にわたる予防統制の集合を監視 (および警告、修正) して、予期しない変化がないかを監視します。
S3 バケットのセキュリティベストプラクティスの詳細については、Amazon S3 ドキュメント、オンラインテックトーク
実装例
AWS SRA コードライブラリは
Amazon Security Lake
AWS SRA では、Amazon セキュリティレイクの委任管理者アカウントとしてログアーカイブアカウントを使用することを推奨しています。これを行うと、Security Lake はサポートされているログを、SRA が推奨する他のセキュリティログと同じアカウントの専用 S3 バケットに収集します。
ログとログ管理プロセスの可用性を保護するため、Security Lake の S3 バケットには、Security Lake サービス、または Security Lake がソースまたはサブスクライバー用に管理する IAM ロールのみがアクセスするようにしてください。アクセスに最小権限のロールを割り当てたり、管理対象の AWS Key Management Services (AWS KMS) キーでログを暗号化したりするなどの予防的統制を採用することに加えて、AWS Config などの検出的統制を使用して、この権限のコレクションを監視 (および警告、修正) して、予期しない変更がないかどうかを確認します。
Security Lake 管理者は、AWS 組織全体でログ収集を有効にできます。これらのログは Log Archive アカウントのリージョン S3 バケットに保存されます。さらに、ログを一元化し、保存と分析を容易にするために、Security Lake 管理者は 1 つ以上のロールアップリージョンを選択できます。このリージョンでは、すべてのリージョン S3 バケットのログが統合されて保存されます。サポートされている AWS サービスのログは、オープンサイバーセキュリティスキーマフレームワーク (OCSF) と呼ばれる標準化されたオープンソーススキーマに自動的に変換され、Apache Parquet 形式で Security Lake S3 バケットに保存されます。OCSF のサポートにより、Security Lake は AWS やその他のエンタープライズセキュリティソースからのセキュリティデータを効率的に標準化および統合して、セキュリティ関連情報の統一された信頼性の高いリポジトリを作成します。
セキュリティレイクは、Amazon S3 と AWS AWS Lambda の AWS CloudTrail CloudTrail 管理イベントとデータイベントに関連するログを収集できます。Security Lake CloudTrail で管理イベントを収集するには、 CloudTrail 読み取り/書き込み管理イベントを収集するマルチリージョン組織トレイルが少なくとも 1 つ必要です。 CloudTrail トレイルのロギングが有効になっている必要があります。マルチリージョントレイルは、複数のリージョンのログファイルを、単一の AWS アカウントの単一の S3 バケットに配信します。リージョンが異なる国にある場合は、データのエクスポート要件を考慮して、マルチリージョントレイルを有効にできるかどうかを判断してください。
AWS Security Hub はセキュリティレイクでサポートされているネイティブデータソースであり、セキュリティハブの結果をセキュリティレイクに追加する必要があります。Security Hub は、さまざまな AWS サービスとサードパーティの統合から結果を生成します。これらの調査結果は、コンプライアンス態勢の概要と、AWSおよびAWS Sパートナーソリューションのセキュリティ推奨事項に従っているかどうかを把握するのに役立ちます。
ログとイベントから可視性と実用的な洞察を得るには、Amazon Athena、Amazon OpenSearch Service、Amazon Quicksight、サードパーティソリューションなどのツールを使用してデータをクエリできます。Security Lake のログデータにアクセスする必要があるユーザーは、Log Archive アカウントに直接アクセスしないでください。Security Tooling アカウントからのみデータにアクセスする必要があります。または、 OpenSearch サービスなどの分析ツール、 QuickSightまたはセキュリティ情報およびイベント管理（SIEM）ツールなどのサードパーティツールを提供する他の AWS アカウントまたはオンプレミスの場所を使用することもできます。データにアクセスできるようにするには、管理者は Log Archive アカウントで Security Lake サブスクライバーを設定し、データにアクセスする必要があるアカウントをクエリアクセスサブスクライバーとして設定する必要があります。詳細については、本ガイドの「セキュリティ OU — セキュリティツールアカウント」セクションの「Amazon Security Lake」を参照してください。
Security Lake には、サービスへの管理者アクセスを管理するのに役立つ AWS 管理ポリシーが用意されています。詳細については、『Security Lake ユーザーガイド』を参照してください。ベストプラクティスとして、開発パイプラインを使用して Security Lake の設定を制限し、AWS コンソールまたは AWS Command Line Interface (AWS CLI) を使用して設定を変更しないようにすることをお勧めします。さらに、Security Lake の管理に必要な権限のみを与えるように、厳密な IAM ポリシーとサービスコントロールポリシー (SCP) を設定する必要があります。これらの S3 バケットへの直接アクセスを検出するように通知を設定できます。
