データの取り込みの概要
Google Security Operations は、お客様のログを取り込み、データを正規化して、セキュリティ アラートを検出します。データの取り込み、脅威検出、アラート、ケース管理のためのセルフサービス機能が用意されています。Google SecOps は、他の SIEM システムからアラートを受信して分析することもできます。
データの取り込みアーキテクチャの概要
次の図は、セキュリティ データが Google SecOps に流れ込み、インターフェースで分析用に処理される仕組みを示しています。
データの取り込みの主な手順
Google SecOps は、セキュリティ データを次のように処理します。
- Amazon S3 やGoogle Cloudなどのクラウド サービスからセキュリティ データを取得します。Google SecOps は、このデータを転送中に暗号化します。
- 暗号化されたセキュリティ データを分離してアカウントに保存します。アクセスできるのはお客様と、プロダクトのサポート、開発、メンテナンスを行う少数の Google 担当者のみです。
- 未加工のセキュリティ データを解析して検証し、処理と表示を容易にします。
- データをインデックスに登録して、高速検索を実現します。
- 解析とインデックス付けを終えたデータをアカウントに保存します。
- ユーザーがセキュリティ データを検索して確認するための安全なアクセスを提供します。
- セキュリティ データと VirusTotal マルウェア データベースを比較して、一致するものを特定します。アセットビューなどの Google SecOps のイベントビューで、[VT コンテキスト] をクリックして VirusTotal の情報を表示します。Google SecOps がセキュリティ データを VirusTotal と共有することはありません。
データ取り込み方法の概要
Google SecOps 取り込みサービスは、すべてのデータのゲートウェイとして機能します。
Google SecOps は、次のシステムを使用してデータを取り込みます。
Google Cloud: Google SecOps は、 Google Cloud 組織からデータを直接取得します。これは、すべての標準 Google Cloud ログ（監査、VPC フロー、DNS、ファイアウォールなど）の主な方法です。これは、 Google Cloud テレメトリーを Google SecOps に取り込む最も費用対効果が高く、パフォーマンスの高い方法です。詳細については、 Google Cloud データを Google SecOps に取り込むをご覧ください。
Bindplane エージェント: オンプレミス環境とサーバー（Windows または Linux）からログを収集するためのマネージド エージェントです。Bindplane は、任意のソースから Google SecOps にログを収集、精製、エクスポートできるテレメトリー パイプラインです。そのため、他の方法では機能しないさまざまな種類のログを柔軟に収集できます。これは、オンプレミス データ（ファイアウォール ログ、Windows ログ、Linux ログなど）や、Google SecOps に取り込む前に前処理（絞り込みやフィルタなど）するクラウドデータに使用できます。このエージェントは、Bindplane OP 管理コンソールを使用して管理することもできます。詳細については、Bindplane エージェントを使用するをご覧ください。
データフィード: データフィードは、主にクラウドベースのログで使用されます。サードパーティのログが Cloud Storage や Amazon S3 などのオブジェクト ストアにすでに集約されている場合や、サードパーティが webhook などの「プッシュ」ベースの方法をサポートしている場合に使用されます。データフィードは、API ベースの統合の事前定義されたセットのすぐに使えるサポートも提供します。クラウドベースのログ（EDR や SaaS アプリケーションなど）や、Direct API として事前定義された特定のインテグレーションには、データフィードを使用します。データフィードは、ログを Google SecOps の取り込みサービスに直接送信します。詳しくは、フィード管理のドキュメントをご覧ください。データフィードでは、最大 4 MB のログ行がサポートされています。Cloud Logging を使用して、フィードのアクティビティとエラーをモニタリングできます。詳細については、Cloud Logging を使用してフィード アクティビティを分析するをご覧ください。
Chronicle API 取り込み方法: 他の方法に適合しないカスタム アプリケーション、大容量アプリケーション、自社開発アプリケーションには、最新の Chronicle API 取り込み方法を使用します。この方法は、他の取り込み方法よりも少し複雑です。
- フォワーダー: フォワーダーはサポート終了となりました。代わりに Bindplane エージェントを使用することをおすすめします。
パーサーは、お客様のシステムからのログを統合データモデル（UDM）に変換します。Google SecOps 内のダウンストリーム システムは、UDM を使用して、ルールや UDM 検索などの追加機能を提供します。
エンドツーエンドのデータフローとレイテンシ、およびこれらの要素が最近取り込まれたデータのクエリと分析の可用性にどのように影響するかなど、データの取り込みライフサイクルの詳細については、検索のデータの可用性についてをご覧ください。
仕様:
ファイルを読み込む場合、ログを正常に読み込むには、ファイル拡張子から想定される形式とファイル コンテンツの形式が一致している必要があります。
サイズの大きいファイル（5 ～ 10 GB 以上）は、データの取り込みを大幅に遅延させる可能性があります。
取り込みでサポートされているのは UTF-8 エンコードのみです。
取り込みとデータの可用性の時間を理解する
Google SecOps での分析に使用できるデータは、いくつかのステージによって異なります。遅延のトラブルシューティングを行うには、ソースシステムの遅延と Google SecOps の処理時間を区別します。
ソースシステムの遅延（取り込み前）: 多くのデータソースには固有のレイテンシがあります。イベントが発生しても、すぐにデータを収集できない場合があります。一般的には次のような原因が考えられます。
- ソースの処理とバッチ処理のスケジュール。
- イベントをログファイルまたは API エンドポイントに書き込むのに必要な時間。
- API レート上限。
- イベントのタイムスタンプと、ログが取り込み可能になる時刻（
createTimeなど）の差。
Google SecOps の取り込みと処理の遅延: データが取り込みポイントに到達した後、次の手順で遅延が発生する可能性があります。
- 収集間隔: プールされたソース（API やストレージ バケットなど）の場合、構成されたフィード頻度（5 分ごとや 1 時間ごとなど）によって最大遅延が決まります。
- 内部パイプライン: 解析、正規化、インデックス登録、拡充。詳細については、検索のデータの可用性についてをご覧ください。
遅延が発生した場合は、原因がソースか Google SecOps かを特定します。たとえば、Blob ストレージ サービスのログはリアルタイムではなく、ポーリング頻度に依存します。
ソース側の遅延がわかっているログタイプのリストについては、Feed Management API リファレンスをご覧ください。
さらにサポートが必要な場合 コミュニティ メンバーや Google SecOps のプロフェッショナルから回答を得ることができます。