Mimari, OpenTelemetry ajanlarının yan hizmetler olarak dağıtıldığı, sıfır güvenli bir telemetri boru hattına odaklanmaktadır. Bu ajanlar, veri iletiminden önce, hassas Kişisel Tanımlanabilir Bilgileri (PII) ağda düz metin olarak geçmemesini sağlamak için HashiCorp Vault'tan kiracıya özgü anahtarları kullanarak alan düzeyinde şifreleme uygular. Bölgesel Apache Kafka kümeleri, şifrelenmiş tamponlar olarak görev yapar ve Apache Flink gibi akış işlemcilerine akarak gizliliği koruyan analizler gerçekleştirir. ClickHouse veya Apache Pinot üzerine inşa edilmiş bir federated sorgu katmanı, her kiracı için ayrı mantıksal parçalar ile paylaşılan altyapıyı sürdürerek zeki indeksleme ve belirti itmesi ile alt-saniye arama yetenekleri sağlar. Anomali tespiti, merkeziyetsiz hassas verileri toplamadan, birleştirilen, farklı olarak özel metrikler üzerinde çalışır ve hassas verileri merkezi hale getirmeden toplu desen tanıma için Apache Spark kullanır.
Günde on milyon hastaya hizmet veren küresel bir tele sağlık platformu, kritik bir uyum açığı ile karşılaştı. Mevcut Jaeger izleme altyapıları, tıbbi kayıtlar ve PHI dahil olmak üzere tam istek yüklerini yakalıyordu. Bu, HIPAA ve GDPR gereksinimlerini ihlal ederek, kuruluşa büyük bir güvenlik yükümlülüğü yaratıyordu.
Çözüm A: Kiracı Bazında İzole Gözlemleme Yığınları
Her bir sağlık hizmeti sağlayıcısı müşterisi, ayrı depolama arka uçları ile birlikte izole Prometheus ve Jaeger örnekleri çalıştıran özel Kubernetes kümeleri alırdı. Bu yaklaşım, tam veri ayrımı garantisi sağladı ve uyum denetimlerini basitleştirdi. Ancak, operasyonel yük yönetimi 500'den fazla ayrı küme gerektiriyordu ve otuz mühendislik ekibi gerektiriyordu; ayrıca, kiracılar arası performans karşılaştırmaları mümkün hale gelmedi. Sermaye harcamaları, tekrarlanan altyapı ve kaybolmuş kapasite nedeniyle %400 arttı.
Çözüm B: Rol Tabanlı Erişim Kontrolü ile Merkezi Düz Metin Toplama
Alan düzeyinde RBAC ve sorgu zamanında veri maskeleme ile büyük bir Elasticsearch kümesi uygulaması. Bu, altyapı maliyetlerini önemli ölçüde düşürdü ve birleştirilmiş sorgulama yetenekleri sağladı. Ancak, güvenlik denetimleri sırasında fatal bir hata ortaya çıktı: toplama katmanı, hafızada ve depolamada çözülmüş PHI içeriyordu, yüksek değerli bir saldırı hedefi oluşturuyordu. Herhangi bir Elasticsearch kümesi veya ayrıcalıklı kimlik bilgilerin ele geçirilmesi, milyonlarca kaydı açığa çıkarırdı, sıfır güven gereksinimlerini ve düzenleyici standartları ihlal ediyordu.
Çözüm C: Sıfır-Güven Alan Düzeyinde Şifreleme ile Federated Sorgu Uçakları
Hassas alanları, belirleyici AES-256 şifreleme ile kiracı kapsamındaki anahtarları kullanarak emisyon öncesinde şifreleyen OpenTelemetry toplayıcıları, yan hizmetler olarak dağıtım. Hassas olmayan iz metadata (zaman damgaları, hizmet adları, süreler) indeksleme için düz metin olarak kalırken, PHI içeren yükler ve etiketler şifreli kalır. Özel bir sorgu ara yüzü, istekleri yakalar, bunları bölgesel ClickHouse kümelerine yönlendirir ve yalnızca talep hizmetinin bellek alanında, geçici anahtar kiralamaları kullanarak şifre çözmeyi koordine eder. Anomali tespiti, şifrelemeden kaçınarak veri tabanındaki metadata ve şifrelenmiş özellik vektörlerindeki desenleri analiz etmek için Flink kullanır.
Seçilen Çözüm ve Sonuç
Ekip, altı aylık bir kavramsal kanıtın ardından Çözüm C'yi seçti. Bu mimari, karmaşık iz aramaları için %99'luk persentilde ortalama 650 ms sorgu gecikmesi sağladı ve alt-saniye gereksinimi içinde kaldı. Platform, telemetri yönetimi ile ilgili olarak kritik bir bulgu olmadan HIPAA ve GDPR denetimlerini geçti. Operasyonel maliyetler, Çözüm A'ya kıyasla %60 azaldı, aynı zamanda herhangi bir potansiyel ihlal durumunda kıvılcım etkisi, tüm veri kümesi yerine bireysel hizmet örnekleri ile sınırlı kaldı. Anomali tespit sistemi, platform mühendislik ekibine hasta verilerini açığa çıkarmadan ilk ayda üretimde üç kritik performans gerilemesini tespit etti.
Soru 1: Geçmiş anahtar sürümleri ile şifrelenmiş tarihsel izleri sorgulama yeteneğini kaybetmeden alan düzeyinde şifrelenmiş telemetri için anahtar değişimini nasıl yönetirsiniz?
Adaylar genellikle, değişim sırasında tüm veri kümesini şifre çözme ve yeniden şifreleme önerir, bu ise petabyte ölçeğinde hesaplama açısından zahmetlidir. Doğru yaklaşım, veri şifreleme anahtarlarının (DEK'ler) telemetri alanlarını şifrelemesi ve anahtar şifreleme anahtarlarının (KEK'ler) DEK'leri koruması için bir anahtar hiyerarşisi uygulamaktır. Her bir iz ile birlikte şifrelenmemiş metadata olarak DEK ID'sini saklayın. Değişim sırasında, yalnızca yeni KEK ile DEK'leri yeniden şifreleyin, geçmiş DEK'leri erişilebilir ancak yeni anahtar tarafından korunan bir şekilde tutun. Şifreli alanlar üzerinde eşitlik aramaları (hasta_id gibi) sağlamak için sorgulama sürecinde kullanılan belirleyici şifreleme için, şifreli şifre üretimini anahtar değişiminde tutarken, anahtar sürümlemesi aracılığıyla anlamsal güvenliği koruyacak şekilde düz metin hash'inden türetilmiş Sentetik Başlatma Vektörleri (IV'ler) uygulayın.
Soru 2: Gözlemleme arka uçundaki yüksek kardinalite alanlarında (kullanıcı kimlikleri veya oturum token'ları gibi) kardinalite patlamasını nasıl önlersiniz, ayrıca belirli kullanıcı yolculuklarını ayıklama yeteneğini korumak için?
Birçok aday, yüksek kardinalite alanlarını tamamen engellemeyi önermektedir ki bu da hata ayıklama yeteneğini yok eder. Sofistike çözüm, Tokenizasyon ile Bloom Filtreleri'ni birleştirir. Yüksek kardinalite tanımlayıcıları, toplayıcı düzeyinde belirleyici token'lar ile değiştirilirken, ayrı, yüksek oranda kısıtlı bir yan hizmet, son 24 saat için hash(token) -> kullanıcı_id eşlemesini tutar. Tarihsel sorgular için, mühendisler gizlilik geçidine talepler gönderir ve iş gerekçesini doğrular, ardından özel token-kullanıcı eşleme bilgilerini geçici olarak tekrar yaşatır. Depolama katmanında (ClickHouse), hizmet adları ve işlemler için LowCardinality veri türlerini kullanın ve token'ları birincil sıralama anahtarları yerine seyrek ikinci indekslerde depolayın. Bu yaklaşım, dizin boyutunu yönetilebilir tutar ( ClickHouse'ta "çok fazla parça" hatasını önlemek) ve gerekli olduğunda denetlenmiş, zaman sınırlı yeniden oluşturma iş akışları aracılığıyla belirli kullanıcı izlerini yeniden yapılandırma yeteneğini korur.
Soru 3: Gerçek zamanlı anomali tespitinde farklı gizliliği nasıl uygularsınız, mikro-gecikaların regresyonlarını tespit etmek için gerekli istatistiksel kullanımı yok etmeden?
Yeni başlayanlar genellikle, gerçek anormalleri gizleyen (yüksek epsilon) veya gizliliği sızdıran (düşük epsilon) küresel gürültü eklemeyi yaygın olarak uygularlar. Mimari çözüm, iki katmanlı bir toplama stratejisi gerektirir. İlk olarak, her hizmetin iletimden önce kendi histogram kutularına kalibre edilmiş Laplace gürültüsü eklediği Yerel Farklılık Gizliliği (LDP) kullanın. Bu, bireysel izleri korurken birikimli dağılımları korur. İkincisi, Flink kümesi içinde Güvenli Çok Taraflı Hesaplama (SMPC) uygulayın, bölgesel toplayıcılar şifrelenmiş sayaclar üzerinde küresel istatistikleri hesaplar, bireysel katkıları öğrenmeden. Gecikme tespiti için özellikle, anormallikler uyarlanabilir eşikleri aştığında gizlilik bütçesini harcayan Seyrek Vektör Teknikleri (SVT) kullanın, her ölçümde değil. Epsilon bütçesi bölme ayarlarını, nadir kritik uyarılara bütçenin %70'ini ve rutin sağlık kontrollerine %30'unu ayıracak şekilde Gizlilik Hesaplama kütüphaneleri gibi Google Privacy-on-Beam ile yapılandırın. Bu, bireysel kullanıcı faaliyetleri için matematiksel gizlilik sınırlamalarını garanti ederken, 5ms gecikme kaymalarını tespit etmek için yeterli sinyal-gürültü oranını korur.