Mimari temel, bağımsız bölgesel kümelerin egemenliğini koruduğu bir hücre tabanlı topoloji üzerine inşa edilmiştir ve küresel bir kontrol düzlemine katılır. Her bölgesel hücre, yerel durum makineleri çoğaltması için Raft uzlaşısını kullanan aktif bir HashiCorp Vault kümesi dağıtır ve bu küme, Thales Luna veya AWS CloudHSM gibi FIPS 140-2 Seviye 3 sertifikalı HSM modülleri ile desteklenir. Bölge ötesi meta veri senkronizasyonu, zamanla tutarlı hizmet keşfi için CRDT tabanlı çelişki olmadan çoğaltılan veri türleri kullanır, bununla birlikte hassas kriptografik işlemler kesinlikle yerelde tutulur, böylece anahtar materyali dışarı çıkmaz.
Dinamik kimlik rotasyonu, her işleme düğümüne yerleştirilen SPIFFE (Herkes İçin Güvenli Üretim Kimlik Çerçevesi) ile entegre edilerek statik sırları ortadan kaldırır. İş yükleri, Node ve Workload doğrulayıcıları tarafından onaylanan kriptografik kimliklere bağlı kısa ömürlü JWT jetonları aracılığıyla kimlik doğrulaması yapar ve kapsayıcı yeniden başlatmaları veya yapılandırma yenilemelerine gerek kalmadan otomatik rotasyonu mümkün kılar. Bu mekanizma, sırların ömrünü günlerden dakikalar seviyesine indirerek potansiyel dışa akışın etkisini büyük ölçüde azaltır.
Anlık iptal yayılımı, bölgesel kümeler arasındaki gRPC iki yönlü akış bağlantıları üzerinde SWIM (Ölçeklenebilir Zayıf Tutarlılıkta Enfeksiyon Tarzı Süreç Grubu Üyeliği) protokolü ile çalışır. Güvenlik olayları iptal tetiklediğinde, köken gönderici, haberi ağ üzerinden yayarak, merkezi koordinasyon darboğazları olmadan yüzlerce düğüm arasında alt saniyelik bir yakınsama sağlar. Bu yaklaşım, bağımsızlıkla ilgili geleneksel kalp atışı tabanlı sistemlerin küme boyutuyla doğrusal yük getirdiği durumlarla karşılaştırıldığında anlamlı bir avantaj sunar.
Uyumluluk ve anahtar töreni prosedürleri, küme başlatma veya felaket kurtarma sırasında ustalık anahtarını yeniden oluşturmak için birden fazla operatör gerektiren Shamir'ın Gizli Paylaşımı uygulamaktadır. HSM kümeleri, fiziksel ve mantıksal güvenlik sınırlarını sıkı şekilde koruyarak, şifrelenmemiş özel anahtarların uygulama belleğinde veya donanım sınırının dışındaki kalıcı depolamada asla var olmamasını sağlar. Düzenli anahtar rotasyon törenleri, yeni anahtar çiftleri oluşturmak için HSM sınırları içinde PKCS#11 işlemleri kullanır, böylece materyalin ana işletim sistemine maruz kalmasını engeller.
Küresel bir ödeme işlemcisindeki kritik bir ihlal yanıtı sırasında, Terraform durum dosyalarına gömülü statik AWS IAM kimlik bilgilerinin dışarı sızdırıldığını ve bu durumun saldırganların üç kıtada üretim veritabanlarına kalıcı erişim sağladığını keşfettik. Acil durum, mikro hizmet ağımızda birlikte çalışan binlerce veritabanı şifresini aynı anda döndürmeyi gerektiriyordu; ayrıca, iptal edilen kimlik bilgilerinin ağı bölmelerinde bile anında kullanılamaz hale gelmesini sağlamalıydık.
İlk çözüm, ana AWS bölgemizde PostgreSQL arka planda merkezi bir HashiCorp Vault dağıtımı gerçekleştirmekti; bu, otomatikleştirilmiş rotasyon için CloudWatch Events tarafından tetiklenen Lambda işlevleri kullanarak sunuluyordu. Bu yaklaşım güçlü tutarlılık garantileri sunarken, aleyhte bir tek noktada başarısızlık durumu oluşturuyordu; herhangi bir bölgesel kesinti, sırların küresel olarak erişilemez hale gelmesine sebep oluyordu ve %99.999 kullanılabilirlik SLA’mızı ihlal ediyordu. Ayrıca, sır alma için bölge ötesi gecikme sürekli 300 ms'yi aşıyor, bu da ödeme yetkilendirme iş akışları için alt 100 ms'lik gereksinimimizi yerine getiremiyordu.
İkinci çözüm, federatif kontrol düzlemi ve OAuth 2.0 kimlik köprülemesi ile bulut yerel gizli yöneticilerin (Secrets Manager, Azure Key Vault, GCP Secret Manager) benimsenmesini önermekteydi. Bu, mükemmel bölgesel kullanılabilirlik ve yerel uyumluluk sertifikaları sağladı; ancak, kabul edilemez bir tedarikçi bağımlılığı yarattı ve bulutlar arasında 1-5 dakika süren asenkron çoğaltma gecikmeleri nedeniyle anlık küresel iptali önledi. Heterojen ortamlar arasında birleşik denetim izlerinin eksikliği, PCI DSS seviye 1 uyumluluk gereksinimlerimizi de karmaşık hale getirdi çünkü, adli analiz için tek bir gerçek kaynak garanti edemiyorduk.
Üçüncü çözüm, bölgesel Vault kümeleri ile Raft uzlaşması, kriptografik iş yükü kimliği için SPIFFE/SPIRE ve gRPC iki yönlü akışlar üzerindeki özel bir dedikodu tabanlı iptal protokolü ile hücre tabanlı bir topoloji oluşturmaktı. Bu tasarım, bölgesel hücrelerin bölünmeler sırasında bağımsız bir şekilde çalışmasına izin verirken, epidemik yayın aracılığıyla alt saniyelik iptal yayılımını sağladı ve güvenlik ile otonomluk arasında denge oluşturarak kendi kendine görevlerini yerine getirmeye imkân tanıdı. Bu yaklaşımı, sıfır-duraklama rotasyon gereksinimini karşıladığı ve FIPS 140-2 Seviye 3 uyumluluğu için AWS CloudHSM aracılığıyla donanım destekli anahtar yönetimi sağladığı için, işletme karmaşıklığına rağmen seçtik.
Uygulamanın ardından bu altyapı, kimlik maruziyet pencerelerini dört saatten beş saniyenin altına düşürdü, us-east-1 bölgesindeki tam bir kesintiyi hizmette bozulma olmaksızın başarıyla karşıladı ve gizlilik yönetimi için telafi önlemleri gerektirmeden PCI DSS denetimlerini geçti.
CAP teoremi, ağ bölünmeleri sırasında gizlilik yönetiminde nasıl tezahür eder ve neden tüm gizlilik işlemleri için yalnızca nihai tutarlılığı kullanamayız?
Bölünmeler sırasında sistem, kullanılabilirlik ve tutarlılık arasında seçim yapmak zorundadır. Gizlilik rotasyon işlemleri için, bir ihlal senaryosunda eski kriptografik anahtarlar sunmak geri dönüşü olmayan güvenlik maruziyetine yol açtığı için CP (Tutarlılık, Kullanılabilirlikten Üstün) önceliğini veriyoruz. Ancak, iptal edilmemiş sırların okuma işlemleri için AP (Kullanılabilirlik, Tutarlılıktan Üstün) davranışını kabul edebiliriz. Kritik ayrım, meta veri kontrol düzleminin (tutarlı olması gereken) veri düzlemi alımından (tazeliği karşılama toleransına sahip olabilen) ayrılmasıdır. Adaylar genellikle tüm gizlilik işlemlerinin anlık tutarlılık gerektirdiğini varsayıyorlar ve okuma replikalarının sınırlandırılmış bir süreyle kalan verileri %95 oranında iletebileceğini gözden kaçırıyorlar; oysa iptali kontrol etme işlemleri her zaman uzlaşı katmanına ulaşmalıdır.
Gizlilik rotasyonundaki "şiddetli sürü" probleminin nedeni nedir ve ölçekle nasıl eksponansiyel geri çekilme ile jitter bunu çözemez?
Sertifikalar, binlerce pod arasında eş zamanlı olarak süresi dolduğunda (örneğin, UTC'de gece yarısı), eş zamanlı yenileme talepleri Vault kümesini aşırı yorar. Basit eksponansiyel geri çekilme, tam jitter, yeniden deneme fırtınaları oluşturduğu için işlevsel değildir; çünkü Kubernetes denetleyicileri genellikle pod'ları eş zamanlı olarak yeniden başlatırlar. Çözüm, istemci tarafında Token Bucket oran sınırlaması uygulamak ve yenileme pencerelerini bir zaman diliminde (örneğin, sona ermeden 6 saat önce) dağıtan proaktif bir rotasyon planlaması kullanmaktır. Ayrıca, Cubbyhole kimlik doğrulaması kullanarak, yanıt sarma ile geçici jetonları yerel olarak önbelleğe almak, kimlik doğrulama yükünü %80 oranında azaltır. Adaylar genellikle istemci tarafında işbirliğinin zorunlu olduğunu göz ardı ederler; sadece sunucu tarafındaki oran sınırlaması, zincirleme başarısızlıklara neden olur.
Neden karşılıklı TLS, sıfır güven gizlilik yönetiminde iş yükü kimliği için yetersizdir ve hangi ek doğrulama mekanizmaları gereklidir?
mTLS, bir iş yükünün geçerli bir sertifikaya sahip olduğunu doğrular, ancak iş yükünün dağıtım sonrası herhangi bir şekilde tehlikeye atılmış olduğunu veya sertifikanın tehlikeye sokulmuş bir düğümden dışarı sızdırıldığını ispat edemez. Kubernetes düğüm kimliğini Hizmet Hesabı projeksiyonu aracılığıyla doğrulayan Node Attestation ve pod etiketlerini ve görüntü özeti bilgilerini doğrulayan Workload Attestation ile birlikte SPIFFE uygulamamız gerekir. Dahası, sırların TPM (Güvenilir Platform Modülü) ölçümleriyle bağlanması, kriptografik materyalin belirli donanım örneklerine bağlı olmasını sağlar. Adaylar genellikle taşınan güvenliğin kimlik doğrulama ile karıştırıldığını gözden kaçırırlar; gizlilik yönetimi, yalnızca kriptografik sahiplik değil, talep edenin çalışma durumunun sürekli doğrulanmasını gerektirir.