このページは Cloud Translation API によって翻訳されました。

Google SecOps で Bindplane を使用する

以下でサポートされています。

Google SecOps SIEM

このドキュメントでは、Google Security Operations 用の Bindplane について説明します。

Bindplane はテレメトリーパイプラインです。任意のソースからログを収集、絞り込み、Google SecOps にエクスポートできます。

Bindplane には、Google 専用の 2 つのエディションがあります。

Bindplane には、次の主要コンポーネントが含まれています。

Bindplane コレクタ。OpenTelemetry（OTel）Collector に基づくオープンソースエージェント。Microsoft Windows イベントログなど、さまざまなソースからログを収集し、Google SecOps に送信します。コレクタはオンプレミスまたはクラウドにインストールできます。

このコンポーネントは、OpenTelemetry（BDOT）Collector 用の Bindplane Distribution、bindplane エージェント、収集エージェント、コレクタ、エージェントとも呼ばれます。
Bindplane Server。OTel コレクタデプロイを管理するための包括的で統合されたプラットフォーム。これらのデプロイは Google SecOps と Google Cloudに存在できます。多くの Google SecOps のお客様が Bindplane Server を使用していますが、使用は任意です。Bindplane Server は、オンプレミスまたは Bindplane クラウドで実行できます。サーバーの詳細については、Bindplane サーバーをご覧ください。

このコンポーネントは、Bindplane Observability Pipeline（OP）管理コンソールまたは Bindplane 管理コンソールとも呼ばれます。

Bindplane の Google エディション

Bindplane には、Google 専用の 2 つのエディション（Bindplane（Google エディション）と Bindplane Enterprise（Google エディション））があります。

Bindplane（Google エディション）

Bindplane（Google エディション）は、すべての Google SecOps のお客様に提供されます。

Bindplane（Google エディション）は、Bindplane Cloud でセルフサービスできます。

Bindplane（Google エディション）のインストールとセルフホスティングを開始する、またはオンプレミス Bindplane サーバーの鍵を生成するには、Bindplane（Google エディション）をご覧ください。

Bindplane Enterprise（Google エディション） - Google SecOps Enterprise Plus のお客様向け

Google SecOps Enterprise Plus をご利用のお客様には、Bindplane Enterprise（Google エディション）が含まれています。

大規模なデプロイには、Bindplane Enterprise（Google エディション）をおすすめします。

Bindplane Enterprise（Google エディション）のライセンスキーを取得するには、Google アカウントチームにお問い合わせください。

Bindplane Google エディション - 違い

次の表に、Bindplane Google エディションの違いを示します。

トピック/機能	Bindplane（Google エディション）	Bindplane Enterprise（Google エディション）
費用	Google SecOps のすべてのお客様に無料で提供	Google SecOps Enterprise Plus のお客様は無料で利用可能
ルーティング/宛先	Google のみ（Google SecOps、Cloud Logging、BigQuery、Google SecOps 経由の Cloud Storage など）	Google（SIEM 移行のための Google 以外の宛先への 12 か月間のルーティングを含む）
フィルタリング	正規表現を使用した基本フィルタ	高度なフィルタリングプロセッサ（条件、フィールド、重大度などでフィルタリング）、データの削減、ログサンプリング、重複除去
秘匿化	N/A	個人情報（PII）のマスキング
変換	フィールドの追加、フィールドの移動、データの解析（KV、JSON、CSV、XML、タイムスタンプ、正規表現による解析）、フィールドの名前変更、イベントブレーカー	Bindplane（Google エディション）でサポートされているすべての機能に加えて、フィールドの削除、空の値の削除、coalesce が含まれます。
一般的なプラットフォームレベルの機能	オンプレミスまたはクラウドホスト型の Gateway（コレクタからのデータを集約）、Bindplane コレクタ、Bindplane サーバー（Bindplane 管理レイヤ）、すべてのソース、Google SecOps プロセッサによるサイレントホストモニタリング、永続キュー、テレメトリーの拡充、高可用性、RBAC、両方の Google SecOps 取り込み API のサポート、認証情報の難読化、コレクタのグループ化、動的なログタイプの割り当てなどの高度なフリート管理	Bindplane（Google エディション）でサポートされているすべての機能

Bindplane コレクタのアーキテクチャ

Bindplane は、BDOT Collector（一般にコレクタと呼ばれる）を使用して、Open Agent Management Protocol（OpAMP）でテレメトリー管理を標準化します。Bindplane を使用して、OpenTelemetry Collector のカスタム ディストリビューションを作成して管理することもできます。

コレクタは、外部依存関係のない軽量のウェブサーバーとして Linux または Docker で実行できます。

Bindplane OpenTelemetry コレクタのデプロイアーキテクチャの詳細については、デプロイをご覧ください。

以降のセクションでは、使用可能なアーキテクチャオプションについて説明します。

コレクタは、ゲートウェイとして機能するコレクタにログを送信します

大規模なデプロイでは、ゲートウェイとして機能する Bindplane Enterprise（Google エディション）コレクタを使用することをおすすめします。これらのゲートウェイは、ネットワーク経由で他のコレクタからテレメトリーを受信し、必要に応じて追加の処理を行い、データを Google SecOps に転送します。

ゲートウェイとして機能するコレクタは、他のすべてのコレクタと同じバイナリを使用します。

次の図は、ゲートウェイとして機能するコレクタにログを送信するコレクタを示しています。

コレクタは、ゲートウェイとして機能するコレクタにログを送信します

コレクタはログを Google SecOps 取り込み API に直接送信します

次の図は、コレクタがログを Google SecOps 取り込み API に直接送信する様子を示しています。

コレクタはログを Google SecOps 取り込み API に直接送信します

コレクタがログを Cloud Logging に直接送信する

次の図は、コレクタがログを Cloud Logging に直接送信する様子を示しています。

コレクタがログを Cloud Logging に直接送信する

コレクタが複数の宛先にログを送信する

次の図は、コレクタが複数の宛先にログを送信する様子を示しています。

コレクタが複数の宛先にログを送信する

Bindplane サーバー

Bindplane サーバーには次の主な機能があります。

一元管理。このサーバーを使用すると、 Google Cloud全体で OTel コレクタのすべてのデプロイを管理できます。各デプロイのステータスを表示し、コレクタの起動、停止、再起動などの一般的な管理タスクを実行できます。
リアルタイムモニタリング。サーバーは、OTel コレクタのデプロイのリアルタイムモニタリングを提供します。CPU 使用率、メモリ使用量、スループットなどの指標を追跡できます。ログとトレースを表示して、問題のトラブルシューティングを行うこともできます。
アラートと通知。サーバーでは、コレクタがダウンしたときや指標のしきい値を超えたときなど、重要なイベントのアラートと通知を設定できます。
構成管理。サーバーを使用すると、OTel コレクタの構成を一元的に管理できます。構成ファイルの編集、環境変数の設定、セキュリティポリシーのすべてのデプロイへの適用を行うことができます。
Google Cloudとの統合。 Google Cloud で OTel コレクタのデプロイを作成して管理し、サーバーを使用して Google Cloud リソースにアクセスできます。

Bindplane は、クラウドとオンプレミスのデプロイオプションを提供します。詳細については、Bindplane サーバーを使用するをご覧ください。

技術要件と推奨事項

このセクションでは、Google SecOps で Bindplane をインストールして実行するための技術要件と推奨事項について説明します。

帯域幅の要件

Bindplane は、次のネットワーク接続を維持します。

コレクタ管理
コレクタのスループットの測定
コマンドラインとウェブユーザーインターフェース

接続要件

デフォルトでは、Bindplane はポート 3001 をリッスンします。このポートは構成可能です。

Bindplane ポートは次の目的で使用されます。

OpAMP（WebSocket）を使用したコレクタのコマンドと制御
コレクタスループット測定リクエスト（HTTP POST リクエスト）
ブラウザと CLI ユーザー（HTTP と WebSocket）

コレクタは、OpAMP（WebSocket）とスループット測定（HTTP）用に Bindplane への接続を開始できる必要があります。

Bindplane がコレクタへの接続を開始することはありません。ファイアウォールを構成して Bindplane がコレクタネットワークにアクセスできないようにすることはできますが、コレクタネットワークは構成されたポートで Bindplane にアクセスできる必要があります。

Bindplane コレクタの一般的な技術要件

Bindplane コレクタの一般的な技術要件については、以下をご覧ください。

コレクタリソースの要件

Bindplane のリソース要件は、管理対象コレクタの数によって異なります。マネージドコレクタの数が増加すると、CPU、メモリ、ディスクスループット/IOPS、ネットワーク消費量も増加します。

CPU、メモリ、ストレージ容量のサイジングには、次の表を使用します。

コレクタ数	Bindplane ノード	フォールトトレラント	CPU コアの数	メモリ	データベース
1～100 人	1	なし	2	4 GB	bbolt
100 ～ 25,000	1	なし	4	16 GB	postgres
1 ～ 60,000	3	1	2	8 GB	postgres
60,001 ～ 125,000	5	1	2	8 GB	postgres
125,001 ～ 250,000	10	2	2	8 GB	postgres

インストールとデプロイを計画する

以降のセクションでは、Bindplane のデプロイを計画する際に考慮すべき推奨事項とベストプラクティスについて説明します。

スケーリングとフォールトトレランスを考慮する

水平スケーリングは、フォールトトレランスを提供し、エクスポータのボトルネックを解消できるため、推奨されます。

ゲートウェイモードで Bindplane コレクタを実行する場合は、ロードバランサとペアにして、フォールトトレランスと水平スケーリングを実現することをおすすめします。

必要なコレクタの数を計算する

ワークロードに必要なコレクタの数を計算するときは、予想されるスループットまたはログレートを考慮し、次の表を使用します。この表は、各コレクタに 4 個の CPU コアと 16 GB のメモリがあることを前提としています。この表にはプロセッサを使用した計算は含まれていません。プロセッサを追加すると、コンピューティング要件が増加します。

テレメトリースループット	ログ/秒	コレクタ
5 GB/月	250,000	2
10 GB/m	500,000	3
20 GB/m	1,000,000	5
100 GB/月	5,000,000	25

フォールトトレランスのためにコレクタフリートをオーバープロビジョニングする

フォールトトレランスを確保するために、コレクタフリートをオーバープロビジョニングします。1 つ以上のコレクタシステムで障害が発生した場合や、メンテナンスのためにオフラインになった場合、残りのコレクタはテレメトリースループットを管理するのに十分な容量を備えている必要があります。

固定数のコレクタを使用している場合は、CPU とメモリの垂直スケーリングを実装してスループットを向上させることができます。

オフロード処理のオーバーヘッド

一般に、コレクタの処理はできるだけ少なくすることが望ましいです。処理要件が厳しい場合は、その処理をゲートウェイコレクタのフリートにオフロードすると便利です。たとえば、コストの高い正規表現演算でテレメトリーをフィルタする代わりに、ゲートウェイコレクタにそのタスクを実行させることができます。通常、ゲートウェイコレクタは専用システムで実行されます。この処理オーバーヘッドは、データベースサーバーで実行される可能性のある非ゲートウェイコレクタとは異なり、同じシステムで実行されている他のサービスのコンピューティング能力を消費しないため、正当化されます。

ゲートウェイモードのベストプラクティス

Bindplane コレクタをゲートウェイモードで実行する場合は、次のベストプラクティスに沿ってデプロイを計画することをおすすめします。

少なくとも 2 つのコレクタをロードバランサの背後に配置します。
各コレクタには、少なくとも 2 つのコアが必要です。
各コレクタには、少なくとも 8 GB のメモリが必要です。
各コレクタには、永続キュー用に 60 GB の使用可能な容量が必要です。

必要に応じてロードバランサを使用する

Bindplane を高可用性モードで運用する場合は、ロードバランサが必要です。

ゲートウェイモードで Bindplane コレクタを実行する場合は、ロードバランサを使用してパフォーマンスと冗長性を高めます。ロードバランシングにより、ゲートウェイフリートの水平スケーリングが可能になり、停止を引き起こすことなく障害に耐えることができます。

Bindplane コレクタは、さまざまなロードバランサと連携できます。

詳細については、ロードバランサをご覧ください。

ロードバランシングのポートとプロトコル

Bindplane はデフォルトでポート 3001 をリッスンします。

OpenTelemetry の幅広いネットワークベースのレシーバをサポートするには、ロードバランサが次の機能をサポートする必要があります。

TCP/UDP 転送プロトコル
HTTP と gRPC アプリケーションプロトコル

ロードバランシングのサイジング

フォールトトレランスを最大限に高めるには、Bindplane ノードで管理するコレクタの数を 30,000 以下にする必要があります。各コレクタは、Bindplane への 2 つの接続を開きます（1 つは OpAMP リモート管理用、もう 1 つはスループット指標のパブリッシュ用）。この上限により、ほとんどのロードバランサで設定されているバックエンドインスタンスあたりの接続上限（約 65,535 個）を超えないようにできます。

組織に 100,000 個のコレクタがある場合、クラスタサイズ 3 では不十分です。各ノードは、約 33,000 個のコレクタを担当します。これは、Bindplane インスタンスあたり 66,000 個の TCP 接続に相当します。メンテナンスのために 1 つのノードがダウンすると、この状況はさらに悪化します。残りの Bindplane インスタンスがそれぞれ 50,000 個のコレクタ、つまり 100,000 個の TCP 接続を管理することになるためです。

ロードバランシングのサイジングに関するベストプラクティス

ヘルスチェックを実装する。コレクタがトラフィックを受信する準備ができていることを確認するようにロードバランサを構成します。
接続を均等に分散する。接続はコレクタ間で均等に分散する必要があります。
必要なプロトコルをサポートする。OpenTelemetry の幅広いネットワークベースのレシーバをサポートするには、ロードバランサが次の機能をサポートする必要があります。
- TCP/UDP 転送プロトコル
- HTTP と gRPC アプリケーションプロトコル

詳細については、コレクタの復元力をご覧ください。

ソースタイプのロードバランシング

ネットワーク経由でリモートシステムからテレメトリーを受信するソースタイプは、ロードバランシングの候補として適しています。たとえば、次のようなソースタイプがあります。

OTLP
Syslog
TCP / UDP
Splunk HEC
Fluent Forward

本番環境で高可用性モードを使用する

Bindplane インスタンスは、単一インスタンス構成またはマルチインスタンス構成でデプロイできます。高可用性（HA）と復元力を必要とする本番環境デプロイの場合は、マルチインスタンス（HA）デプロイモデルを使用することをおすすめします。

Bindplane が 25,000 個を超えるコレクタを管理する場合は、高可用性（HA）モードで Bindplane を運用することをおすすめします。

Bindplane の HA については、高可用性をご覧ください。

HA 用のコレクタと Bindplane サーバーの数を計算する

Bindplane を HA モードで運用する場合は、各 Bindplane サーバーが処理するコレクタの数を検討する必要があります。

Bindplane インスタンスの合計数から、メンテナンスによって使用不可になることが予想されるノードの最大数を差し引きます。ノードの停止中に各ノードが管理するコレクタの数が 30,000 を超えないようにします。

HA 用の Postgres

HA モードで Bindplane を運用する場合、Postgres が前提条件となります。

HA 用 Prometheus

HA モードで Bindplane を運用する場合は、Prometheus が必要です。

詳細については、Prometheus をご覧ください。

HA 用のイベントバス

Bindplane は、イベントバスを使用して Bindplane 内のコンポーネント間で通信します。Bindplane を HA モードで運用する場合は、イベントバスを使用して Bindplane サーバー間でイベントを送信できます。

詳細については、イベントバスをご覧ください。

テスト環境または概念実証に単一インスタンスデプロイを使用する

テスト環境または概念実証には、単一インスタンスのデプロイを使用することをおすすめします。

詳細については、単一インスタンスをご覧ください。

バックエンド認証情報を分離する

認証情報をすべてのコレクタシステムにデプロイする代わりに、認証情報をゲートウェイコレクタにのみ保持できます。これにより、認証情報のローテーションが簡素化され、認証情報のデプロイをシステムの一部に制限することで、セキュリティ攻撃対象領域が縮小されます。

ゲートウェイコレクタをファイアウォールで保護する

ゲートウェイコレクタは、内部ネットワークからファイアウォールで保護された境界ネットワーク内に配置できます。他のコレクタがデータをゲートウェイコレクタに転送できるようにネットワークを構成し、ゲートウェイコレクタがアプリケーションネットワークにアクセスできないようにブロックできます。これにより、エンドポイントにインターネットへの直接アクセス権を付与することなく、クラウドベースのバックエンドにテレメトリーを送信できます。

ファイアウォールで、構成されたポートの Bindplane に HTTP トラフィックが到達できるようにする必要があります。

ファイアウォール構成を確認する

コレクタとインターネットの間にあるファイアウォールまたは認証プロキシには、次のホストへのアクセス権を開放するルールが必要です。

接続タイプ	発信先	ポート
TCP	malachiteingestion-pa.googleapis.com	443
TCP	asia-northeast1-malachiteingestion-pa.googleapis.com	443
TCP	asia-south1-malachiteingestion-pa.googleapis.com	443
TCP	asia-southeast1-malachiteingestion-pa.googleapis.com	443
TCP	australia-southeast1-malachiteingestion-pa.googleapis.com	443
TCP	europe-malachiteingestion-pa.googleapis.com	443
TCP	europe-west2-malachiteingestion-pa.googleapis.com	443
TCP	europe-west3-malachiteingestion-pa.googleapis.com	443
TCP	europe-west6-malachiteingestion-pa.googleapis.com	443
TCP	europe-west12-malachiteingestion-pa.googleapis.com	443
TCP	me-central1-malachiteingestion-pa.googleapis.com	443
TCP	me-central2-malachiteingestion-pa.googleapis.com	443
TCP	me-west1-malachiteingestion-pa.googleapis.com	443
TCP	northamerica-northeast2-malachiteingestion-pa.googleapis.com	443
TCP	accounts.google.com	443
TCP	oauth2.googleapis.com	443

本番環境のデプロイに PostgreSQL を使用する

Bindplane の本番環境デプロイには Postgres が必要です。

Postgres は、Bindplane を HA モードで運用するための前提条件です。

通常、CPU コアの数と使用可能なメモリによって、PostgreSQL ストレージバックエンドのパフォーマンスが制限されます。PostgreSQL ストレージは、ソリッドステートドライブ（SSD）などの低レイテンシで高スループットのストレージでバックアップすることをおすすめします。

コレクタ数	CPU コアの数	メモリ
1 ～ 60,000	4	16 GB
60,001 ～ 125,000	8	32 GB
125,001 ～ 250,000	16	64 GB

詳細については、以下をご覧ください。

適切な認証を実装する

Bindplane は、次のプロトコルとサービスによる認証をサポートしています。これらが適切に実装されていることを確認してください。

Azure Entra LDAP。詳細については、Azure LDAP と Bindplane 認証タイプの変更をご覧ください。
LDAP。
OpenID Connect（OIDC）。
ローカル。
SAML。
Postgres TLS。詳細については、Postgres TLS をご覧ください。
Kubernetes。詳細については、GKE Workload Identity をご覧ください。

Bindplane サーバーを使用する

ほとんどの Google SecOps のお客様は Bindplane サーバーを使用していますが、使用は任意です。Bindplane サーバーをインストールする場合は、storage.googleapis.com へのアクセス権が必要です。コレクタのみをインストールする場合は、このアクセスは必要ありません。

ログを標準化して Google SecOps にエクスポートするように Bindplane サーバーを構成する方法を示すデモについては、[このページ](https://bindplane.com/use-case-demo) に移動し、[Google SecOps Configuration] を選択します。

Bindplane Cloud サーバーを使用する

Bindplane Cloud は Google のお客様にご利用いただけます。

Google エディションにログインします。

Bindplane Cloud Server に関する問題については、Bindplane サポートにお問い合わせください。オンプレミスの Bindplane Server に関する問題については、Google SecOps サポートにお問い合わせください。

Google Cloudで Bindplane サーバーを使用する

Google Cloudで Bindplane サーバーを実行する方法については、Bindplane Enterprise Edition をご覧ください。

Bindplane オンプレミスサーバーを使用する

オンプレミスの Bindplane サーバーの使用には、既存の Google Cloud 利用規約が適用されます。

Linux にオンプレミスサーバーをインストールする

オンプレミスの Bindplane サーバーは、スクリプトを実行するか（推奨）、バイナリファイルをダウンロードして手動でインストールすることで、Linux にインストールできます。詳細については、Bindplane Server をインストールするをご覧ください。

スクリプトを使用して Linux にオンプレミス Bindplane サーバーをインストールするには、次の操作を行います。

次のスクリプトを実行します。

curl -fsSlL https://storage.googleapis.com/bindplane-op-releases/bindplane/latest/install-linux.sh -o install-linux.sh && bash install-linux.sh --init && rm install-linux.sh
手順に沿って操作すると、サーバーの初期化が完了します。

バイナリファイルを使用して Linux にオンプレミスの Bindplane サーバーをインストールする手順は次のとおりです。

次のいずれかのファイルをダウンロードします。
Bindplane Server を構成するの手順に沿って、構成ファイルを更新します。

サポートされている Linux ディストリビューション:

Red Hat、Centos、Oracle Linux 7、8、9
Debian 11、12
Ubuntu LTS 20.04 と 22.04
SUSE Linux 12 および 15
Alma Linux と Rocky Linux

詳細については、以下をご覧ください。

オンプレミス環境での Docker のデプロイ

詳細については、Bindplane Server をインストールするをご覧ください。

Bindplane Docker コンテナイメージは、次の場所にあります。

GitHub パッケージ: ghcr.io/observiq/Bindplane-ee
Google アーティファクトリポジトリ: us-central1-docker.pkg.dev/observiq-containers/bindplane/bindplane-ee
Docker Hub: observiq/bindplane-ee

コンテナイメージにはリリースバージョンのタグが付けられます。たとえば、リリース v1.35.0 には observiq/bindplane-ee:1.35.0 というタグが付けられます。

Bindplane コレクタをインストールする

このセクションでは、さまざまなシステムに Google SecOps 用 Bindplane コレクタをインストールする方法について説明します。

通常、コレクタは最小限のリソースを使用します。ただし、大量のログを処理する場合は、他のサービスに影響を与えないように、リソース消費に注意してください。詳細については、技術要件と推奨事項、インストールとデプロイを計画する、エージェントのサイジングとスケーリングをご覧ください。

コレクタ（OTel エージェント）のインストール方法については、Bindplane OTel Collector をご覧ください。

GitHub のドキュメント bindplane-otel-collector もご覧ください。

コレクタをインストールするには、次のものが必要です。

Google SecOps の取り込み認証ファイル

ファイルをダウンロードするには、次の手順に従います。
1. Google SecOps コンソールを開きます。
2. [SIEM Settings] > [Collection Agent] に移動します。
3. Google SecOps の取り込み認証ファイルをダウンロードします。
Google SecOps のお客様 ID

お客様 ID を確認する手順は次のとおりです。
1. Google SecOps コンソールを開きます。
2. [SIEM 設定] > [プロファイル] に移動します。
3. [組織の詳細情報] セクションからお客様 ID をコピーします。
Windows 2012 SP2 以降、または systemd を使用する Linux ホスト
インターネット接続
GitHub へのアクセス

デプロイツール

このセクションでは、Bindplane のデプロイツールについて説明します。

GitOps

次のものを含む GitOps モデルを使用して Bindplane リソースをデプロイします。

Bindplane 認証
Bindplane CLI
ネットワークアクセス
GitHub リポジトリと GitHub Actions との統合
既存のリソースをエクスポートする
機密性の高い値の管理
GitHub Action ワークフローを確立する
構成のコミットとテスト、自動ロールアウトの有効化、直接編集または UI エクスポート方法を使用したリソースの更新の手順
機密性の高い値を更新して RBAC を使用する

詳細については、GitOps をご覧ください。

Ansible

Ansible を使用した Bindplane のデプロイについては、bindplane-agent-ansible をご覧ください。

Bindplane CLI

Bindplane CLI については、GitOps をご覧ください。

Terraform

Terraform を使用して Bindplane リソースを構成する方法については、Bindplane プロバイダをご覧ください。

Kubernetes

Bindplane を使用した Kubernetes の詳細については、以下をご覧ください。

Windows に Bindplane コレクタをインストールする

Windows に Bindplane コレクタをインストールするには、次の PowerShell コマンドを実行します。

msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet

または、インストールウィザードを使用してインストールするには、Windows 用の最新のインストーラをダウンロードします。インストーラをダウンロードしたら、インストールウィザードを開き、手順に沿って Bindplane コレクタを構成してインストールします。

Windows への Bindplane コレクタのインストールについて詳しくは、Windows へのインストールをご覧ください。

Linux に Bindplane コレクタをインストールする

インストールするパッケージを自動的に決定するスクリプトを使用して、Linux にコレクタをインストールできます。同じスクリプトを使用して、既存のインストールを更新することもできます。

インストールスクリプトを使用してインストールするには、次のスクリプトを実行します。

sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh

ローカルパッケージからのインストール

ローカルパッケージからコレクタをインストールするには、-f を使用してパッケージのパスを指定します。

sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh -f path_to_package

RPM のインストール

リリースページからアーキテクチャ用の RPM パッケージをダウンロードし、rpm を使用してパッケージをインストールします。amd64 パッケージをインストールする例を次に示します。

sudo rpm -U ./observiq-otel-collector_v${VERSION}_linux_amd64.rpm
sudo systemctl enable --now observiq-otel-collector

VERSION は、ダウンロードしたパッケージのバージョンに置き換えます。

DEB のインストール

リリースページからアーキテクチャ用の DEB パッケージをダウンロードし、dpkg を使用してパッケージをインストールします。amd64 パッケージのインストールについては、次の例を参照してください。

sudo dpkg -i --force-overwrite ./observiq-otel-collector_v${VERSION}_linux_amd64.deb
sudo systemctl enable --now observiq-otel-collector

VERSION は、ダウンロードしたパッケージのバージョンに置き換えます。

Bindplane コレクタを構成する

コレクタをインストールすると、observiq-otel-collector サービスが実行され、構成の準備が整います。

コレクタは、手動または Bindplane サーバーを使用して構成できます。

コレクタを手動で構成する場合は、コレクタが Google SecOps で認証されるようにエクスポーターパラメータを更新する必要があります。

OTel コレクタ構成ファイル

Linux では、コレクタの構成ファイルは /opt/observiq-otel-collector/config.yaml にあります。

OTel コレクタサービスとログ

コレクタはデフォルトで C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log にログを記録します。

コレクタプロセスの標準エラーログは C:\Program Files\observIQ OpenTelemetry Collector\log\observiq_collector.err にあります。

Linux でコレクタのログを表示するには、sudo tail -F /opt/observiq-otel-collector/log/collector.log を実行します。

一般的な Linux OTel コレクタサービスコマンド:

OTel コレクタサービスを停止するには、sudo systemctl stop observiq-otel-collector を実行します。
OTel コレクタサービスを開始するには、sudo systemctl start observiq-otel-collector を実行します。
OTel コレクタサービスを再起動するには、sudo systemctl restart observiq-otel-collector を実行します。
起動時に OTel コレクタサービスを有効にするには、sudo systemctl enable observiq-otel-collector を実行します。

構成の変更のためにコレクタサービスを再起動する

構成を変更する場合は、構成の変更を有効にするためにコレクタサービスを再起動する必要があります（sudo systemctl restart observiq-otel-collector）。

デフォルトのサンプル構成ファイルを使用する

デフォルトでは、コレクタ構成ファイルは C:\Program Files\observIQ OpenTelemetry Collector\config.yaml にあります。

コレクタで使用されるサンプル構成ファイルと認証トークンをダウンロードするには:

Google SecOps コンソールを開き、[SIEM 設定] > [収集エージェント] に移動します。

構成ファイルで次の 2 つのセクションをカスタマイズします。

レシーバー: コレクタが収集して Google SecOps に送信するログを指定します。
エクスポーター: コレクタがログを送信する宛先を指定します。次のエクスポーターがサポートされています。
- Google SecOps エクスポーター: ログを Google SecOps 取り込み API に直接送信します。
- Google SecOps フォワーダーエクスポーター: Google SecOps フォワーダーにログを送信します。
- Cloud Logging エクスポーター: ログを（Cloud Logging）に送信します。

エクスポーターで、次のようにカスタマイズします。

customer_id: Google SecOps のお客様 ID。
endpoint: Google SecOps リージョンエンドポイント。
creds: 認証トークン。

または、creds_file_path を使用して認証情報ファイルを直接参照することもできます。Windows 構成の場合は、バックスラッシュでパスをエスケープします。
log_type: ログタイプ。[ログタイプ] として [WINDOWS_DNS] を選択することをおすすめします。
ingestion_labels: 取り込みラベル。これらのラベルは、Google SecOps でログを識別します。
namespace: オプションの名前空間。

各ログタイプにはエクスポーターを構成する必要があります。

ログ収集構成のサンプル

以降のセクションでは、ログ収集の構成例を示します。

Windows イベントと sysmon を Google SecOps に直接送信する

サンプルで次のパラメータを構成します。

chronicleexporter
- namespace
- ingestion_labels
- log_type
- customer_id
- creds

構成の例:

receivers:
  windowseventlog/sysmon:
    channel: Microsoft-Windows-Sysmon/Operational
    raw: true
  windowseventlog/security:
    channel: security
    raw: true
  windowseventlog/application:
    channel: application
    raw: true
  windowseventlog/system:
    channel: system
    raw: true

processors:
  batch:

exporters:
  chronicle/sysmon:
    endpoint: malachiteingestion-pa.googleapis.com
    creds: '{
  "type": "service_account",
  "project_id": "malachite-projectname",
  "private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
  "private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
  "client_email": "account@malachite-projectname.iam.gserviceaccount.com",
  "client_id": "123456789123456789",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.iam.gserviceaccount.com",
  "universe_domain": "googleapis.com"
}' 
    log_type: 'WINDOWS_SYSMON'
    override_log_type: false
    raw_log_field: body
    customer_id: 'dddddddd-dddd-dddd-dddd-dddddddddddd'
  chronicle/winevtlog:
    endpoint: malachiteingestion-pa.googleapis.com
    creds: '{
  "type": "service_account",
  "project_id": "malachite-projectname",
  "private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
  "private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
  "client_email": "account@malachite-projectname.iam.gserviceaccount.com",
  "client_id": "123456789123456789",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.iam.gserviceaccount.com",
  "universe_domain": "googleapis.com"
}'
    log_type: 'WINEVTLOG'
    override_log_type: false
    raw_log_field: body
    customer_id: 'dddddddd-dddd-dddd-dddd-dddddddddddd'

service:
  pipelines:
    logs/sysmon:
      receivers: [windowseventlog/sysmon]
      processors: [batch]
      exporters: [chronicle/sysmon]
    logs/winevtlog:
      receivers: 
        - windowseventlog/security
        - windowseventlog/application
        - windowseventlog/system
      processors: [batch]
      exporters: [chronicle/winevtlog]

Windows イベントと syslog を Google SecOps に直接送信する

サンプルで次のパラメータを構成します。

windowseventlogreceiver
tcplogreceiver
- listen_address
chronicleexporter
- namespace
- ingestion_labels
- log_type
- customer_id
- creds

構成の例:

receivers:
    tcplog:
      listen_address: "0.0.0.0:54525"
    windowseventlog/source0__application:
        attributes:
            log_type: windows_event.application
        channel: application
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__security:
        attributes:
            log_type: windows_event.security
        channel: security
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__system:
        attributes:
            log_type: windows_event.system
        channel: system
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds: '{ json blob for creds }'
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        ingestion_labels:
            env: dev
        log_type: <applicable_log_type>
        namespace: testNamespace
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - windowseventlog/source0__system
                - windowseventlog/source0__application
                - windowseventlog/source0__security
            exporters:
                - chronicle/chronicle_w_labels
        logs/source1__chronicle_w_labels-0:
            receivers:
                - tcplog
            exporters:
                - chronicle/chronicle_w_labels

Windows イベントと syslog を Google SecOps フォワーダーに送信する

サンプルで次のパラメータを構成します。

構成の例:

receivers:
tcplog:
    listen_address: "0.0.0.0:54525"
    windowseventlog/source0__application:
        attributes:
            log_type: windows_event.application
        channel: application
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__security:
        attributes:
            log_type: windows_event.security
        channel: security
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__system:
        attributes:
            log_type: windows_event.system
        channel: system
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
exporters:
    chronicleforwarder/forwarder:
        export_type: syslog
        raw_log_field: body
        syslog:
            endpoint: 127.0.0.1:10514
            transport: udp
service:
    pipelines:
        logs/source0__forwarder-0:
            receivers:
                - windowseventlog/source0__system
                - windowseventlog/source0__application
                - windowseventlog/source0__security
            exporters:
                - chronicleforwarder/forwarder
        logs/source1__forwarder-0:
            receivers:
                - tcplog
            exporters:
                - chronicleforwarder/forwarder

syslog を Google SecOps に直接送信する

サンプルで次のパラメータを構成します。

tcplogreceiver
- listen_address
chronicleexporter
- namespace
- ingestion_labels
- log_type
- customer_id
- Creds

構成の例:

receivers:
  tcplog:
    listen_address: "0.0.0.0:54525"

exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds: '{ json blob for creds }'
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        ingestion_labels:
            env: dev
        log_type: <applicable_log_type>
        namespace: testNamespace
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - tcplog
            exporters:
                - chronicle/chronicle_w_labels

Windows イベントをリモートで収集し、Google SecOps に直接送信する

サンプルで次のパラメータを構成します。

windowseventlogreceiver
- username
- password
- server
chronicleexporter
- namespace
- ingestion_labels
- log_type
- customer_id
- creds

構成の例:

receivers:
    windowseventlog/system:
        channel: system
        max_reads: 100
        start_at: end
        poll_interval: 10s
        raw: true
        remote:
            username: "username"
            password: "password"
            server: "remote-server"
    windowseventlog/application:
        channel: application
        max_reads: 100
        start_at: end
        poll_interval: 10s
        raw: true
        remote:
            username: "username"
            password: "password"
            server: "server-ip"
    windowseventlog/security:
        channel: security
        max_reads: 100
        start_at: end
        poll_interval: 10s
        raw: true
        remote:
            username: "username"
            password: "password"
            server: "server-ip"
exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds: '{ json blob for creds }'
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        ingestion_labels:
            env: dev
        log_type: WINEVTLOG
        namespace: testNamespace
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - windowseventlog/system
                - windowseventlog/application
                - windowseventlog/security
            exporters:
                - chronicle/chronicle_w_labels

Cloud Logging にデータを送信する

サンプルで credentials_file パラメータを構成します。

構成の例:

exporters:
  googlecloud:
    credentials_file: /opt/observiq-otel-collector/credentials.json

SQL データベースにクエリを実行し、結果を Google SecOps に送信する

サンプルで次のパラメータを構成します。

sqlqueryreceiver
chronicleexporter
- namespace
- ingestion_labels
- log_type
- customer_id
- creds

構成の例:

receivers:
  sqlquery/source0:
    datasource: host=localhost port=5432 user=postgres password=s3cr3t sslmode=disable
    driver: postgres
    queries:
      - logs:
          - body_column: log_body
        sql: select * from my_logs where log_id > $$1
        tracking_column: log_id
        tracking_start_value: "10000"
processors:
  transform/source0_processor0__logs:
    error_mode: ignore
    log_statements:
      - context: log
        statements:
          - set(attributes["chronicle_log_type"], "POSTGRESQL") where true
exporters:
  chronicle/chronicle_sql:
    compression: gzip
    creds: '{
  "type": "service_account",
  "project_id": "malachite-projectname",
  "private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
  "private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
  "client_email": "account@malachite-projectname.iam.gserviceaccount.com",
  "client_id": "123456789123456789",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.iam.gserviceaccount.com",
  "universe_domain": "googleapis.com"
}' 
    customer_id: customer_id
    endpoint: malachiteingestion-pa.googleapis.com
    log_type: POSTGRESQL
    namespace: null
    raw_log_field: body
    retry_on_failure:
      enabled: false
    sending_queue:
      enabled: false
service:
  pipelines:
    logs/source0_chronicle_sql-0:
      receivers:
        - sqlquery/source0
      processors:
        - transform/source0_processor0__logs
      exporters:
        - chronicle/chronicle_sql

正規表現に一致するログを削除する

正規表現に一致するログを削除するようにコレクタを構成できます。これは、既知のエラーやデバッグメッセージなど、不要なログを除外するのに役立ちます。

正規表現に一致するログを削除するには、filter/drop-matching-logs-to-Chronicle タイプのプロセッサを構成に追加します。このプロセッサは、IsMatch 関数を使用して、ログ本文を正規表現と照合して評価します。関数が true を返すと、ログは破棄されます。

次の構成例では、ログ本文に文字列 <EventID>10</EventID> または <EventID>4799</EventID> を含むログを削除します。

正規表現をカスタマイズして、必要なパターンに一致させることができます。IsMatch 関数は RE2 正規表現構文を使用します。

構成の例:

processors:
    filter/drop-matching-logs-to-Chronicle:
        error_mode: ignore
        logs:
            log_record:
                - (IsMatch(body, "<EventID>10</EventID>")) or (IsMatch(body, "<EventID>4799</EventID>"))

次の例では、同じ構成のパイプラインにプロセッサを追加します。

service:
  pipelines:
    logs/winevtlog:
      receivers: 
        - windowseventlog/security
        - windowseventlog/application
        - windowseventlog/system
      processors: 
      - filter/drop-matching-logs-to-Chronicle # Add this line
      - batch
      exporters: [chronicle/winevtlog]

Bindplane の運用とメンテナンス

このセクションでは、日常的な運用とメンテナンスのアクションについて説明します。

OTel 構成を検証する

Bindplane OTel 構成を確認する方法については、OTelBin をご覧ください。

コレクタリリースアップデート

Bindplane は bindplane-otel-collector/releases をポーリングして、新しいコレクタリリースを検出できます。この機能は省略可能です。

Bindplane 構成で agentVersions.syncInterval を 0 に設定すると、GitHub ポーリングを無効にできます。

agentVersions:
syncInterval: 0

バックアップと障害復旧

Bindplane を使用したバックアップと障害復旧については、Bindplane リソースをご覧ください。

PostgreSQL のバックアップと障害復旧

Bindplane を使用した PostgreSQL のバックアップと障害復旧については、PostgreSQL のドキュメントをご覧ください。

BBolt のバックアップと障害復旧

Bindplane を使用した BBolt（非推奨）のバックアップと障害復旧については、BBolt Store のドキュメントをご覧ください。

復元力と再試行

再試行は、サポートされているすべての宛先でデフォルトで有効になっています。デフォルトでは、失敗したリクエストは 5 秒後に再試行され、最大 30 秒まで段階的にバックオフされます。5 分後に、リクエストは完全に削除されます。

詳細については、コレクタの復元力をご覧ください。

重大度フィルタを使用してログの量を減らす

ログの量を減らす方法については、重大度フィルタを使用してログの量を減らすをご覧ください。

サードパーティコレクタとの Bindplane 統合

BindPlane は、エッジでの収集に BindPlane コレクタを使用するとより強力になりますが、ほとんどの場合、既存のインフラストラクチャ内に留まることができます。たとえば、すでに Fluent Bit または Splunk Universal Forwarder を使用している場合は、引き続き使用できます。

Bindplane と Splunk の統合

Bindplane を使用した Splunk については、以下をご覧ください。

他のサードパーティコレクタとの Bindplane 統合

Bindplane とサードパーティコレクタの統合については、OpAMP 拡張機能を使用して他の OpenTelemetry コレクタを接続するをご覧ください。

Silent Host Monitoring

Google Security Operations Silent Host Monitoring を使用すると、Google Cloud Monitoring を使用して取り込み率の変化に関するアラートを作成できます。コレクタごとにアラートを生成し、取り込み率が定義されたしきい値を下回った場合に通知して、コレクタの停止の可能性を示します。

Bindplane を使用したサイレントホストモニタリングについては、以下をご覧ください。

Linux で Bindplane をアップグレードする

最後に --init フラグを指定せずにインストールコマンドを実行するだけで、Bindplane をアップグレードできます。Bindplane をアップグレードするには、Bindplane サーバーでこのスクリプトを実行します。詳細については、Bindplane Server のアップグレード、ダウングレード、アンインストールをご覧ください。

Bindplane をモニタリングする

Bindplane をモニタリングする方法については、Bindplane のモニタリングをご覧ください。

Bindplane で Kubernetes をモニタリングする

Bindplane で Kubernetes をモニタリングする方法については、Kubernetes モニタリングをご覧ください。

その他のドキュメント

Bindplane（以前の observIQ）の詳細については、以下をご覧ください。

さらにサポートが必要な場合 コミュニティメンバーや Google SecOps のプロフェッショナルから回答を得ることができます。

Google SecOps で Bindplane を使用する

Bindplane の Google エディション

Bindplane（Google エディション）

Bindplane Enterprise（Google エディション） - Google SecOps Enterprise Plus のお客様向け

Bindplane Google エディション - 違い

Bindplane コレクタのアーキテクチャ

コレクタは、ゲートウェイとして機能するコレクタにログを送信します

コレクタはログを Google SecOps 取り込み API に直接送信します

コレクタがログを Cloud Logging に直接送信する

コレクタが複数の宛先にログを送信する

Bindplane サーバー

技術要件と推奨事項

帯域幅の要件

接続要件

Bindplane コレクタの一般的な技術要件

コレクタ リソースの要件

インストールとデプロイを計画する

スケーリングとフォールト トレランスを考慮する

必要なコレクタの数を計算する

フォールト トレランスのためにコレクタ フリートをオーバー プロビジョニングする

オフロード処理のオーバーヘッド

ゲートウェイ モードのベスト プラクティス

必要に応じてロードバランサを使用する

ロード バランシングのポートとプロトコル

ロード バランシングのサイジング

ロード バランシングのサイジングに関するベスト プラクティス

ソースタイプのロード バランシング

本番環境で高可用性モードを使用する

HA 用のコレクタと Bindplane サーバーの数を計算する

HA 用の Postgres

HA 用 Prometheus

HA 用のイベントバス

テスト環境または概念実証に単一インスタンス デプロイを使用する

バックエンド認証情報を分離する

ゲートウェイ コレクタをファイアウォールで保護する

ファイアウォール構成を確認する

本番環境のデプロイに PostgreSQL を使用する

適切な認証を実装する

Bindplane サーバーを使用する

Bindplane Cloud サーバーを使用する

Google Cloudで Bindplane サーバーを使用する

Bindplane オンプレミス サーバーを使用する

Linux にオンプレミス サーバーをインストールする

サポートされている Linux ディストリビューション:

オンプレミス環境での Docker のデプロイ

Bindplane コレクタをインストールする

デプロイツール

GitOps

Ansible

Bindplane CLI

Terraform

Kubernetes

Windows に Bindplane コレクタをインストールする

Linux に Bindplane コレクタをインストールする

ローカル パッケージからのインストール

RPM のインストール

DEB のインストール

Bindplane コレクタを構成する

OTel コレクタ構成ファイル

OTel コレクタ サービスとログ

構成の変更のためにコレクタ サービスを再起動する

デフォルトのサンプル構成ファイルを使用する

ログ収集構成のサンプル

Windows イベントと sysmon を Google SecOps に直接送信する

Windows イベントと syslog を Google SecOps に直接送信する

Windows イベントと syslog を Google SecOps フォワーダーに送信する

syslog を Google SecOps に直接送信する

Windows イベントをリモートで収集し、Google SecOps に直接送信する

Cloud Logging にデータを送信する

SQL データベースにクエリを実行し、結果を Google SecOps に送信する

正規表現に一致するログを削除する

Bindplane の運用とメンテナンス

OTel 構成を検証する

コレクタ リリース アップデート

バックアップと障害復旧

PostgreSQL のバックアップと障害復旧

BBolt のバックアップと障害復旧

復元力と再試行

重大度フィルタを使用してログの量を減らす

サードパーティ コレクタとの Bindplane 統合

コレクタリソースの要件

スケーリングとフォールトトレランスを考慮する

フォールトトレランスのためにコレクタフリートをオーバープロビジョニングする

ゲートウェイモードのベストプラクティス

ロードバランシングのポートとプロトコル

ロードバランシングのサイジング

ロードバランシングのサイジングに関するベストプラクティス

ソースタイプのロードバランシング

テスト環境または概念実証に単一インスタンスデプロイを使用する

ゲートウェイコレクタをファイアウォールで保護する

Bindplane オンプレミスサーバーを使用する

Linux にオンプレミスサーバーをインストールする

ローカルパッケージからのインストール

OTel コレクタサービスとログ

構成の変更のためにコレクタサービスを再起動する

コレクタリリースアップデート

サードパーティコレクタとの Bindplane 統合

他のサードパーティコレクタとの Bindplane 統合