OpenTelemetryは、クラウドネイティブ環境における観測性（Observability）を実現するためのオープンソースプロジェクトであり、CNCF（Cloud Native Computing Foundation）が主導する重要な技術スタックの一つです。この技術は、アプリケーションのメトリクス、トレース、ログなどのテレメトリデータを収集・伝送するためのフレームワークとして広く採用されています。しかし、未暗號化のテレメトリデータは情報漏洩のリスクを高め、法規制やセキュリティ要件に違反する可能性があります。本記事では、OpenTelemetryにおける伝送中の暗號化技術の必要性、実裝方法、および課題について詳しく解説します。
OpenTelemetryが未暗號化で伝送するテレメトリデータには、主機名、OS情報、Javaバージョン、データベース種類、接続文字列、SQL文など、セキュリティ上重要な情報が含まれています。Wiresharkなどのパケットキャプチャツールを用いることで、これらの情報は簡単に解析可能です。攻撃者はこれらの情報から特定のシステムやネットワーク構造を特定し、さらなる攻撃を仕掛ける可能性があります。
法規制の観點からも、伝送中の暗號化は必須です。アメリカではFedRAMP SC8、歐州およびUKではGDPR、UK GDPR、ENISA NIS2指令、醫療分野ではHIPAAが伝送中の暗號化を義務付けています。これらの要件を満たすためには、OpenTelemetryのテレメトリデータを暗號化する必要があります。
TLS（Transport Layer Security）は、雙方向認証と暗號化を提供するプロトコルであり、サーバーの真偽性を検証し、データを通信先のみに見えるようにします。OpenTelemetry Collectorでは、collector.yamlファイルを用いてTLSを構成します。デフォルトではHTTP/Protobufが使用されるため、TLS設定は手動で行う必要があります。
主要な設定パラメータには、最低限のTLSバージョン（TLS 1.3を推奨）、サーバー証明書（.crt）と秘密鍵（.key）、FIPS準拠のためのOpenSSLバージョンの指定が含まれます。FIPS（Federal Information Processing Standard）準拠環境では、-provider fipsパラメータを指定してアルゴリズムを制限する必要があります。
自署名証明書を生成するには、以下のOpenSSLコマンドを使用します：
openssl req -new -x509 -nodes -days 365 -out collector.crt -keyout collector.key
このコマンドでは、-newで新規リクエストを生成し、-x509で自署名証明書を直接生成します。-days 365は証明書の有効期限を365日と設定し、-outと-keyoutで出力ファイルを指定します。
証明書のフィールドには、O（組織単位）、L（地域）、C（國コード）、CN（ホスト名）が含まれます。CNはDNS名と一致する必要があります。FIPS準拠の場合は、-provider fipsパラメータを指定してアルゴリズムを制限します。
OpenTelemetry Collectorの4318ポートにopenssl s_clientを用いてTLS 1.3接続をテストします。自署名証明書はJavaクライアントでunable to find valid certification pathエラーを引き起こします。これは信頼チェーンが存在しないためです。
信頼チェーンの検証では、公眾ネットワークではLet's Encryptなどの信頼された根証明機関（CA）のチェーンを依存します。自署名証明書は、信頼ストアに根証明書を手動で追加しないと信頼されません。攻撃者は偽裝して証明書を生成する可能性があるため、信頼された証明書源を確保する必要があります。
Javaクライアントでは、OpenTelemetryエンドポイントをhttpからhttpsに変更します。自署名証明書の信頼問題を迴避するため、自動的に未検証証明書を受容しないように設定する必要があります。
ネットワーク隔離環境では、攻撃者が偽裝して証明書を生成する可能性があるため、証明書の出所を信頼できるものに保つ必要があります。サーバー側では正しい証明書と秘密鍵を設定し、定期的に証明書を更新する必要があります。
組織は自社のCA（Certificate Authority）を構築し、証明書を管理する必要があります。CA証明書を各ノードに配布し、Javaクライアントではkeytoolを用いて信頼ストアにCA証明書を手動で追加します。
keytool -import -alias internal-ca -file internal-ca.crt -keystore $JAVA_HOME/lib/security/cacerts
信頼ストアのパスはlib/security/cacertsです。
Macではシステムのキーチェーンに証明書を追加し、WiresharkでTLS接続を検証します。暗號化されたデータパケット（encrypted payload）を確認し、クライアント/サーバーの情報層構造を確認します。
OpenTelemetryはデフォルトで明文ポート4318を使用します。生産環境では、明確な識別のために専用のTLSポート（例：465）を指定する必要があります。TLSの有効化はネットワーク遅延とリソース消費を増加させるため、プロダクション環境では専門チームによる証明書管理が必須です。
雙方向TLS（mTLS）を導入することで、認証の強化が可能です。クライアントはリクエストに証明書を埋め込む必要があります。OpenTelemetry Collectorのドキュメントには関連する設定ガイドが提供されています。
OpenTelemetryはデフォルトでTLSを有効化し、明文通信のリスクを迴避する必要があります。信頼チェーンの構築には、自署名証明書では信頼チェーンが形成されないため、専門チームによるCAアーキテクチャの管理が必要です。
開発環境では自署名証明書を用いて迅速な検証が可能です。一方、生産環境では厳格な証明書管理プロセスに従う必要があります。
OpenTelemetryのテレメトリデータを伝送中に暗號化することは、情報漏洩のリスクを迴避し、法規制を遵守するための不可欠なステップです。TLSの構成、証明書の生成、信頼チェーンの検証、Javaクライアントの信頼設定などの手順を実施する必要があります。自署名証明書は信頼チェーンを手動で管理する必要があり、公眾ネットワークでは信頼されたCAを用いることが推奨されます。