このアーキテクチャは、ゼロトラストテレメトリパイプラインに基づいています。ここで、OpenTelemetry エージェントがサイドカーとしてデプロイされ、サービスレベルでトレースをキャプチャします。これらのエージェントは、HashiCorp Vault からのテナント固有の鍵を使用してフィールドレベルの暗号化を行い、機密の個人識別情報（PII）がプレーンテキストでネットワークを横断することを防ぎます。地域別の Apache Kafka クラスターは暗号化されたバッファとして機能し、プライバシーを保護する分析を行うストリームプロセッサー（Apache Flink）に供給します。ClickHouse または Apache Pinot に基づいた連合クエリレイヤーは、共有インフラストラクチャを使用して、テナントごとに別々の論理シャードを維持し、インテリジェントインデックスおよび述語プッシュダウンを介してサブ秒のルックアップを可能にします。異常検知は、生のスパンではなく集約された差分プライベートメトリクスで行われ、Apache Spark を利用して中央集権化された復号化された機密データを扱うことなくバッチパターン認識を行います。
毎日1000万人の患者にサービスを提供するグローバルな遠隔医療プラットフォームは、重大なコンプライアンスギャップに直面しました。既存の Jaeger トレースインフラストラクチャは、医療記録やPHIを含む全リクエストペイロードをキャプチャしていました。これは、HIPAAおよびGDPRの要件に違反し、同時に組織にとって大規模なセキュリティリスクを生み出しました。
解決策A: テナントごとの分離された可観測性スタック
各医療提供者クライアントには、分離されたKubernetesクラスターが提供され、独立したPrometheusおよびJaegerインスタンスが実行され、別々のストレージバックエンドを持ちます。このアプローチにより、完全なデータ分離が保証され、コンプライアンス監査が簡素化されました。しかし、運用コストが高く、500以上の別々のクラスターを管理するには30人のエンジニアが必要でした。また、テナント間のパフォーマンス比較が不可能になりました。インフラストラクチャの資本支出は、重複したインフラストラクチャと余剰キャパシティのために400%増加しました。
解決策B: ロールベースアクセス制御による中央集権的プレーンテキスト集約
フィールドレベルのRBACとクエリ時のデータマスキングを使用して単一の大規模なElasticsearchクラスターを実装し、インフラストラクチャコストを大幅に削減し、統一されたクエリ能力を提供しました。しかし、致命的な欠陥はセキュリティ監査中に浮かび上がりました: 集約レイヤーにはメモリおよびストレージに復号化されたPHIが含まれており、高価値の攻撃ターゲットを生成していました。Elasticsearchクラスターや特権資格情報のいずれかが侵害されると、数百万のレコードが暴露され、ゼロトラスト要件および規制基準に失敗しました。
解決策C: ゼロトラストフィールドレベルの暗号化および連合クエリプラン
OpenTelemetryコレクターをサイドカーとして展開し、感度の高いフィールドを決定論的なAES-256暗号化を使用してテナントスコープキーで暗号化し、排出前に非機密のトレースメタデータ（タイムスタンプ、サービス名、滞在時間）はインデックス用にプレーンテキストとして残し、PHIを含むペイロードやタグは暗号化されたままにします。カスタムクエリプロキシがリクエストを傍受し、地域別のClickHouseクラスターへのルーティングを行い、要求するサービスのメモリ空間内でのみ、Vaultからの一時的な鍵リースを使用して復号化を制御します。異常検知は、復号化なしにメタデータおよび暗号化された特徴ベクトルのパターンを分析するためにFlinkを利用します。
選ばれた解決策および結果
チームは6か月の概念実証の後、解決策Cを選択しました。このアーキテクチャは、99パーセンタイルの複雑なトレースルックアップに対して平均クエリレイテンシ650msを達成し、サブ秒の要件を満たしました。プラットフォームはHIPAAおよびGDPR監査を通過し、テレメトリ処理に関して重大な結果はゼロでした。運用コストは解決策Aと比較して60%減少し、潜在的な侵害の影響範囲は全データセットではなく、個々のサービスインスタンスに留まりました。異常検知システムは、プラットフォームエンジニアチームに患者データが暴露されることなく、最初の月内に本番環境で3つの重大なパフォーマンス低下を特定しました。
質問1: フィールドレベルで暗号化されたテレメトリの鍵ローテーションを、過去の鍵バージョンで暗号化された履歴トレースをクエリする能力を失うことなくどのように処理しますか？
候補者はしばしばローテーション中に全データセットを復号化および再暗号化することを提案しますが、ペタバイトスケールでは計算的に困難です。正しいアプローチは、データ暗号化鍵（DEK）がテレメトリフィールドを暗号化し、鍵暗号化鍵（KEK）がDEKを保護するEnvelope Encryptionを使用した鍵階層を実装することです。DEK IDを各スパンとともに未暗号化のメタデータとして保存します。ローテーション中は、新しいKEKでDEKを再暗号化するだけで済み、履歴DEKは新しいマスターキーで保護されつつアクセス可能なまま保たれます。クエリに使用される決定論的暗号化については（暗号化フィールド上での等価検索を可能にするため）、平文ハッシュから導出された**合成初期化ベクトル（IV）**を実装し、特定のフィールドに対して一貫した暗号文生成を行い、鍵バージョンによって意味的なセキュリティを維持します。
質問2: 観測バックエンド内の高基数フィールド（ユーザーIDやセッショントークンなど）における基数爆発を防ぎながら、特定のユーザージャーニーをデバッグする能力を維持するにはどうしますか？
多くの候補者は高基数フィールドを完全にブロックするだけだと提案し、デバッグ能力を破壊します。高度な解決策は、トークン化をブルームフィルターと組み合わせて利用します。高基数の識別子はコレクターレベルで決定論的トークンに置き換えられ、非常に制限されたサイドカーが過去24時間のみのハッシュ（トークン）->ユーザーIDのマッピングを維持します。履歴クエリでは、エンジニアがプライバシーゲートウェイを介してリクエストを提出し、ビジネスの正当性を検証し、そのクエリセッションのために特定のトークンとユーザーのマッピングを一時的に再構成します。ストレージ層（ClickHouse）では、サービス名や操作のためにLowCardinalityデータ型を利用し、トークンはプライマリソーティングキーではなくスパースセカンダリインデックスに保存します。このアプローチにより、インデックスサイズが管理可能に保たれ、特定のユーザートレースを再構成する能力を必要に応じて、監査済みの時間制限付きの再構成ワークフローを通じて保持します。
質問3: マイクロレイテンシの回帰を検出するために必要な統計的有用性を損なうことなく、リアルタイムの異常検知において差分プライバシーをどのように実装していますか？
初心者は通常、グローバルなノイズ追加を均一に適用しますが、これは実際の異常をマスクする（高いイプシロン）か、プライバシーを漏洩させる（低いイプシロン）ことになります。建築的解決策は、二層の集約戦略が必要です。最初に、OpenTelemetryエージェントレベルで**ローカル差分プライバシー（LDP）を利用し、各サービスが発信前に自身のヒストグラムバケットにキャリブレーションされたラプラスノイズを追加します。これにより、個々のトレースが保護され、集計の分布が保持されます。次に、Flinkクラスター内でSecure Multi-Party Computation（SMPC）を実装し、地域の集約者が暗号化されたカウンターに基づいて個々の貢献を学習することなくグローバル統計を計算します。特にレイテンシ検出のために、異常が適応閾値を超えたときのみプライバシーバジェットを消費するスパースベクトル技術（SVT）**を採用します。イプシロンバジェットの分割を設定するために、プライバシーアカウンティングライブラリ（例: Google Privacy-on-Beam）を使用して、バジェットの70%を稀な重要なアラートに、30%をルーチンの健康チェックに割り当てます。これにより、5msレイテンシのシフトを検出するための信号対ノイズ比が十分に保たれながら、個々のユーザー活動に対して数学的なプライバシー境界が保証されます。