CISA の国家サイバー セキュリティ保護システム（NCPS）への Google Cloud のログの報告

※この投稿は米国時間 2022 年 12 月 14 日に、Google Cloud blog に投稿されたものの抄訳です。

このブログは、Google Cloud 上で TIC 3.0 を遵守したソリューションを設計するためのガイドに続くもので、テレメトリー報告要件に関する拡張ガイダンスを提供するものです。

国家サイバーセキュリティ保護システム（NCPS）は、アメリカ合衆国サイバーセキュリティ・社会基盤安全保障庁（CISA）が連邦政府文民機関の IT インフラストラクチャを高度なサイバー脅威から保護し、防衛できるようにするための機能を提供しています。各機関が IT インフラストラクチャをクラウドに移行する中、CISA のアナリストがクラウド上の各機関のワークロードに対して状況認識とサポートを提供できるように、NCPS プログラムは進化を遂げています

このブログでは、Google Cloud が NCPS Cloud インターフェース リファレンス アーキテクチャ（NCIRA）プログラム文書*に記載されているテレメトリー サイクルに従って、機関がどのようにログを収集し、ログを拡充させて、CISA に報告するかについてのガイダンスを提供します。

レポートのパターン:

NCPS のテレメトリー サイクルは、機関のクラウド リソースから CISA に情報を提供するための 3 つのステージを備えています。

1. ステージ A: クラウド センシング - テレメトリーの生成

2. ステージ B:  機関による処理 - 通信のためのテレメトリーを準備

3. ステージ C: CISA への報告 - 機関から CISA のインフラストラクチャとコントロールへの情報の伝達と移行を含む

^{NCPS Cloud Telemetry Cycle: https://www.cisa.gov/sites/default/files/publications/CISA_NCPS_Cloud_Interface_RA_Volume-1.pdf}

各ステージには、そのステージで行われる機能を把握するための属性があります。次のセクションでは、これらの各ステージと Google Cloud での構成方法について説明します。

A. クラウド センシング

NCPS プログラムは、異なるセンサーの位置（ゲートウェイ、サブネット、インターフェース、またはサービス）と、生成する異なる遠隔測定タイプ（ネットワーク フロー ログ、パケット キャプチャ、アプリケーション ログ、またはトランザクション ログ）を特定しました。クラウド サービスのモデル（IaaS、PaaS、SaaS）は、サービスに対してロギングを有効にしたときに構成できる適切な属性とオプションに影響を及ぼします。  

Google Cloud は、Google Cloud のサービス、センサーの位置、テレメトリーの種類ごとにロギングを有効にする方法の構成ガイダンスを集め、NCPS for Google Cloud - クラウド センシング ドキュメントで公開し、このステージの要件を実現しました。  

B. 機関による処理

このステージでは、ログデータのフィルタリング、拡充、集約、CISA の CLAW（Cloud Log Aggregation Warehouse）への取り込みに適した形式への変換が行われます。Google Cloud において、この変換は Cloud Logging から Pub/Sub に目的のログをルーティングするログルーターと、Pub/Sub からのログを処理する Dataflow パイプラインを用いて、フィルタリング、集約、拡充、変換、そして最終的に CLAW にログを送ることで行われます。機関による処理の図の一例を以下に示します。

また、規模に応じた設計を行うために、以下のように、Pub/Sub と Dataflow パイプラインを別のプロジェクトにデプロイし、他の複数のプロジェクトでログルーターを構成して、集中型モデルでログをエクスポートすることもできます。

機関は、次のステージで CISA に送信する前に、ログに対して実行する操作のオプションを持っています。

データのフィルタリング: 機関のログデータは、3 つのレベルでフィルタリングできます。

1. 
   

2. Pub/Sub フィルタ - ログルーターが Pub/Sub トピックにログを送信するとき、これらのログは Pub/Sub サブスクリプションのフィルタを利用して追加でフィルタにかけることができます。

3. Dataflow パイプライン - Dataflow パイプラインにログが流れると、パイプラインで Beam ParDo 変換のカスタム変換を活用し、ログエントリや特定の属性をフィルタアウト（除外）することも可能です。

データ拡充: ログが Dataflow を通過する際に、ログデータを拡充することも可能です。たとえば、Google Cloud API を使ってロードバランサのホストとポートを取得し、ロードバランサの各ログ行にアイテムを追加します。

データ集計: ログデータは、Dataflow を流れるログと同時に集約できます。この例として、一定時間内（5 分ごとなど）の 2 つのデータソースを結合し、その時間内の他のログを論理的に結合した 1 つのログファイルを生成できます。

データ変換: ログデータは、Dataflow を通過する際に変換できます。この例として、ログの日付を特定のフォーマットやタイムゾーンに変換すること、ログ行のプロパティを複数のプロパティに分割すること、ログ行のプロパティを単一のプロパティに結合することが挙げられます。

C. CISA へのレポート

これが機関の処理の最終ステージです。データの転送は push 型でも pull 型でも可能ですが、CISA では、機関が取り込み速度をコントロールできるように push 型を推奨しています。機関は CISA と協力して、受信側の認証情報に関して必要な情報を得る必要があります。これらの認証情報を使って、データフロー パイプラインは、必要な時間枠の間隔（通常 15 分）で CISA CLAW に最終ログを送信するシンクを作成できます。

オプションとして、機関はパイプラインに追加のシンクを追加し、CISA CLAW に送信されるログを正確にアーカイブできます。多くの場合、CISA CLAW に送信されるのと同じ Dataflow PCollection を格納する BigQuery シンクを Dataflow パイプラインに作成することで実現できます。

サンプル パイプライン

機関の Dataflow パイプラインの全サンプルはこちらでご覧いただけます。サンプルのうち、Pub/Sub からログを読み込み、ログを拡張して CLAW に送信する具体的な Dataflow コードを示すスクリーンショットは以下のとおりです。

まとめ

Google には、FedRAMP、ITAR、NIST SP 800-53、DoD IL4、IL5 など、政府機関の要件に対応してきた歴史があります。Google はこのパターンを継続し、連邦政府民間機関が TIC 3.0 に関する CISA のガイダンスを遵守できるように支援しています。  

Google Cloud 環境において、この CISA ガイダンスを遵守するための追加情報または支援が必要な場合は、Google アカウント チームまたは Google TIC 3.0 テクニカル チーム tic-initiative@google.com までご連絡ください。