セキュリティガイドライン、アクセス許可、依存関係 🔗
Splunk Distribution of OpenTelemetry Collector はデフォルトでセキュアな方法で動作しますが、設定主導型なので、セキュリティを管理するには少なくともアーキテクチャーと機能の基本的な理解が必要です。詳細は プロセッサー・アーキテクチャー と Collector のデプロイモード を参照してください。
注意
公開されている GitHub の課題報告を使ってセキュリティ脆弱性を報告しないでください。セキュリティ問題を報告するには、セキュリティ脆弱性を報告する を参照してください。
セキュリティガイドライン 🔗
エンドユーザー向け 🔗
Collector を使用するときは、以下のガイドラインに従ってください。
Collector の設定 🔗
設定で最低限必要なコンポーネントをアクティブにします。
重要な構成情報が安全に保管されるようにします。
アクセス許可を設定する 🔗
Collectorをrootまたはadminユーザで実行しないでください。
必要に応じて、コンポーネントに特権アクセスを要求するように設定します。
レシーバーとエクスポーターを設定する 🔗
暗号化と認証を使用します。
セキュリティリスクを減らすために、設定パラメータが適切に変更されていることを確認してください。
プロセッサーを設定する 🔗
機密性の高いメタデータの難読化またはスクラブ設定を行います。
すべての推奨プロセッサーを設定します。
エクステンションを設定する 🔗
機密性の高い健康データやテレメトリデータを公開しないでください。
開発者向け 🔗
以下の一般的なガイドラインに従ってください：
Collector 構成ファイルから構成情報を取得します。
設定ヘルパー関数を使用します。
Collector の設定 🔗
セントラル設定ファイルを使用します。
設定ヘルパーを使用します。
アクセス許可を設定する 🔗
特権アクセスを最小限にします。
特権アクセスが必要なものとその理由を文書化します。
レシーバーとエクスポーターを設定する 🔗
レシーバーとエクスポーターのデフォルトが暗号化接続になるように設定します。
ヘルパー関数を使うようにレシーバーとエクスポーターを設定します。詳細は GitHub の exporter helper を参照してください。
エクステンションを設定する 🔗
センシティブなヘルスデータやテレメトリデータをデフォルトで公開しないようにエクステンションを設定します。
一般設定 🔗
Collector のバイナリには組み込みまたはデフォルトの構成が含まれていないため、起動する前に構成ファイルを指定する必要があります。Collector に渡された構成ファイルは、ロードする前に検証する必要があります。無効な構成が検出された場合は、保護メカニズムとして Collector の起動に失敗する必要があります。
コンフィグレーションは Collector の動作を駆動するため、コンフィグレーションが最小限の機能セットのみをアクティブにし、必要最小限のポートセットをエクスポーズするように注意する必要があります。詳細は、公開ポートとエンドポイント を参照してください。さらに、送受信通信にはTLSと認証を使用する必要があります。
Collectorはコンフィグレーションをメモリに保持するが、起動時にコンフィグレーションがどこからロードされるかは、使用するパッケージングに依存します。例えば、KubernetesではシークレットやConfigMapsを使用できるが、Dockerではイメージはコンテナにコンフィグレーションを埋め込み、デフォルトでは暗号化された方法では保存されません。
コンフィギュレーションには以下のような機密情報が含まれている可能性があります：
APIトークンなどの認証情報
秘密鍵を含むTLS証明書
機密情報は、暗号化されたファイルシステムやシークレットストアなど、安全に保存する必要があります。Collector は環境変数の展開をサポートする必要があるため、環境変数を使用して機密データおよび非機密データを処理できます。詳細は、Configuration Environment Variables を参照してください。
OpenTelemetry コンポーネントの設定に関する詳細は、以下のセクションで説明します。
アクセス許可 🔗
Collectorはカスタムユーザーでの実行をサポートしており、rootまたはadminユーザーとして実行する必要はありません。ほとんどの使用例では、Collectorを機能させるために特権アクセスは必要ありません。一部のコンポーネントは特権アクセスを必要とする場合があります。これらのコンポーネントをアクティブにする場合は注意してください。Collectorコンポーネントは、ネットワークアクセスやRBACなどの外部アクセス許可も必要とする場合があります。
アクセス許可の詳細については、以下のセクションで説明します。
レシーバーおよびエクスポーター 🔗
レシーバーとエクスポーターは、プッシュ・ベースでもプル・ベースでも構いません。いずれの場合も、接続は安全な認証チャネルを介して確立する必要があります。Collector の攻撃ベクトルを最小限に抑えるため、未使用のレシーバーおよびエクスポー ターは非アクティブにする必要があります。攻撃ベクトルとは、ハッカーがシステムの脆弱性を悪用しようとしてネットワークやコンピュータに不正にアクセスするために使用する経路や方法のことです。
レシーバーとエクスポーターは、バッファ、キュー、ペイロード、ワーカーの設定を、コンフィギュレーション・パラメータを使って公開する可能性があります。これらの設定が利用可能な場合、エンドユーザーはデフォルト値を慎重に変更できます。これらの値を不適切に設定すると、リソースの枯渇を含む追加の攻撃ベクトルにCollector がさらされる可能性があります。
レシーバーが動作するために Collector を特権モードで実行する必要がある可能性があり、これはセキュリティ上の懸念となる可能性があります。
開発者は、暗号化された接続（ insecure: false コンフィギュレーション設定を使用）、およびレシーバーとエクスポーターのヘルパー関数を使用する必要があります。
プロセッサー 🔗
プロセッサーはレシーバーとエクスポーターの中間に位置し、何らかの形でデータを処理する責任を負います。セキュリティの観点からは、プロセッサーは以下のような点で有用です。
推奨構成 🔗
プロセッサーはデフォルトではアクティブ化されていません。データソースによっては、複数のプロセッサーをアクティブにすることができます。プロセッサーはデータソースごとにアクティブにする必要があり、すべてのプロセッサーがすべてのデータソースをサポートしているわけではありません。
プロセッサーの順番が重要であることに留意してください。以下の各セクションの順番がベストプラクティスです。詳細については、各プロセッサーのマニュアルを参照してください。
トレース
memory_limiterプロセッサー任意のサンプリング・プロセッサー
コンテキストからのソース送信に依存するプロセッサー（例えば、
k8sattributes）。batchプロセッサーその他のプロセッサー
メトリクス
memory_limiterプロセッサーコンテキストからのソース送信に依存するプロセッサー（例えば、
k8sattributes）。その他のプロセッサー
機密データのスクラブ 🔗
Collector を使用して、バックエンドにエクスポートする前に機密データをスクラブするのが一般的です。これは、サードパーティのバックエンドにデータを送信する場合に特に重要です。Collectorを設定して、機密データを難読化またはスクラブしてからエクスポートします。
資源利用に関するセーフガード 🔗
さらに、プロセッサーはリソース使用に関するセーフガードを提供します。batch および memory_limiter プロセッサーは、Collector がリソース効率に優れ、過負荷時にメモリ不足にならないようにします。少なくとも、定義されたすべてのパイプラインでこれら2つのプロセッサーをアクティブにします。詳細は、ref:rec-processor-config を参照してください。
エクステンション 🔗
レシーバー、プロセッサー、エクスポーターはテレメトリデータを直接扱うが、以下のセクションで説明するように、エクステンションは通常異なるニーズに応えます。
健全性とテレメトリ 🔗
初期の拡張機能は、ヘルスチェック情報、Collectorのメトリクスとトレース、およびプロファイリングデータの生成と収集機能を提供しました。デフォルト設定で有効にすると、ヘルスチェック・エクステンションを除くこれらのエクステンションはすべて、Collectorにローカルでのみアクセスできます。これらの拡張機能をリモートアクセス用に設定する場合は、機密情報が公開される可能性があるため、注意してください。
転送 🔗
転送エクステンションは通常、Collector でネイティブにサポートされていないテレメトリデータを収集する必要がある場合に使用します。たとえば、http_forwarder 拡張は HTTP ペイロードを受信して転送できます。転送拡張はレシーバーやエクスポーターに似ているため、同じセキュリティに関する考慮事項が適用されます。
オブザーバー 🔗
オブザーバーはエンドポイントのサービスディスカバリーを行うことができます。レシーバーのような他のコンポーネントは、エンドポイントの出入りを通知するために、これらの拡張を購読することができます。オブザーバーは、サービスディスカバリーを実行するために特定のアクセス許可を要求することができます。例えば、k8s_observer はKubernetesの特定のRBAC権限を必要とし、host_observer はCollectorが特権モードで実行されることを必要とします。
サブプロセス 🔗
拡張機能を使用してサブプロセスを実行することもでき、Collector でネイティブに実行できない収集メカニズム（たとえばFluentBit）に役立ちます。サブプロセスは、サブプロセス自体に依存するまったく別の攻撃ベクトルを公開します。一般に、Collectorと並行してサブプロセスを実行する前に、注意が必要です。
依存関係 🔗
Splunk Distribution of OpenTelemetry Collector は、さまざまな外部依存関係 :new-page:` <https://github.com/signalfx/splunk-otel-collector/network/dependencies>` に依存しています。これらの依存関係は Dependabot によって監視されています。依存関係は 毎日チェックされ 関連するプルリクエストは自動的に開かれます。
最新のセキュリティアップデートを確実に入手するために、最新リリース にアップグレードしてください。このプロジェクトの依存関係に対してセキュリティの脆弱性が検出された場合、それは以下のいずれかの理由による可能性があります：
古いリリースを使用しています。
アップデートを含む新しいリリースはリリースされていません。
更新された依存関係がマージされていないのは、おそらく何らかの破壊的な変更があったためです（この場合、私たちは問題の解決に積極的に取り組み、詳細を追ったGitHub issuesを開きます）。
依存関係はパッチを適用した更新版をリリースしていません。