Önce sonuç: TPM bir kasa değil, anakarta lehimlenmiş bir yardımcı işlemcidir. AMD'nin TPM ürün yazılımının 8.3/8.5 sürümlerinde yüksek riskli güvenlik açıkları ortaya çıktığında ilk tepkim mikrokodu güncellemek değil, kendi anahtar saklama envanterimizi gözden geçirmek oldu — yedekleme şifreleme kök anahtarını doğrudan TPM'e bağlayan tüm makineleri iyileştirme bekleyen olarak işaretledim. Bu yazı üç şeyi netleştiriyor: güven kökü nasıl kırılıyor, anahtar sızıntısı hangi noktaya kadar zincirleme etki yapıyor ve şu anda kullandığım anahtar ayrıştırma çözümü nedir.
TPM'in güven kökü, aslında kime güveniyor
TPM'in temel değeri "anahtar asla çipten çıkmaz" vaadini sunmasıdır. Özel anahtar çip içinde üretilir, içinde kullanılır; dış veri yolu yalnızca sonucu taşır, anahtarı taşımaz. Bu modelin geçerlilik önkoşulu çip ürün yazılımının kendisinin güvenilir olmasıdır. AMD'nin TPM uygulaması fTPM yolunu izler; ürün yazılımı işlemci içindeki güvenlik yardımcı işlemcisinde çalışır. 8.3 ve 8.5 sürümlerinde açıklanan sorunların özü, ürün yazılımı katmanındaki bellek izolasyonu ve komut doğrulamasında bulunan kusurlardır; saldırgan yerel kod yürütme yetkisi elde ettikten sonra belirli komut dizileri oluşturarak izole edilmesi gereken anahtar nesnelerini okuyabilir.
Buradaki sınırlayıcı koşula dikkat edin: yerel yetki gerekiyor. Bu yüzden çoğu kişinin ilk tepkisi "sorun değil, sunucumuza zaten başkası giriş yapamıyor" oluyor. Sorun yedekleme senaryosunda. Yedekleme aracıları, anlık görüntü hizmetleri, veritabanının TDE anahtar sarmalaması — bu süreçler zaten ana makinede çalışıyor. Web uygulaması ele geçirildiğinde, konteyner kaçışı başarılı olduğunda saldırganın eline geçen şey yerel yetki oluyor ve ardından doğrudan TPM'e okuma isteği gönderiyor. Güven zinciri ürün yazılımı halkasında kopuyor; üstündeki LUKS, BitLocker, TDE hepsi işlevsiz kalıyor.
Yedekleme anahtarı sızıntısı tek bir makineyi kaybetmek değildir
Bir kez simülasyon yaptım. Bir veritabanı ana makinesinin TDE kök anahtarının okunduğunu varsayalım, saldırgan ne yapabilir: diskteki tablespace dosyalarını alır, çevrimdışı çözer, tüm veriyi ele geçirir. Bu henüz ilk katman. Gerçek zincirleme etki yedekleme sistemindeki anahtar yeniden kullanımında — birçok ekip kolaylık olsun diye aynı KEK (anahtar şifreleme anahtarı) setini üretim veritabanı, yedekleme veritabanı ve arşiv soğuk depolamayı sarmalamak için kullanıyor. Bir kök anahtarın sızması, son üç yılın tüm yedeklerinin çözülebilmesi anlamına geliyor. Denetim günlükleri, mali kayıtlar, kullanıcı kimlik bilgileri, hepsi tek seferde paketlenmiş oluyor.
Daha can sıkıcı olan zaman boyutu. TPM güvenlik açığının açıklanmasından düzeltilmesine kadar bir pencere var, düzeltmeden tüm ürün yazılımının güncellenmesine kadar bir pencere daha var; yedekleme verilerinin saklama süresi ise genellikle 3 ila 7 yıl. Bugün düzeltseniz bile üç yıl önce sızdırılmış anahtarla şifrelenmiş o arşiv hâlâ teyp kütüphanesinde duruyor. Anahtar döndürme geçmiş verinin sorununu çözemez; tüm arşivleri yeniden şifrelemedikçe. Bu maliyeti kimse hesaplamak istemiyor.
Anahtar ayrıştırma: anahtarı çipten çıkarmak
Benim yaklaşımım anahtar yaşam döngüsünü donanım güven kökünden ayırıp üç katmana bölmek.
Birinci katman, bağımsız anahtar yönetim katmanı. Yedekleme şifrelemesinin kök anahtarı artık ana makine TPM'i tarafından üretilmiyor; bağımsız bir KMS hizmeti tarafından merkezi olarak üretilip saklanıyor, ana makine yalnızca kısa vadeli erişim kimlik bilgisi tutuyor. TPM "önyükleme bütünlüğü ölçümü" rolüne indirgeniyor, artık anahtar saklama sorumluluğu taşımıyor. Böylece ürün yazılımı kırılsa bile saldırganın eline geçen anahtar değil kimlik bilgisi oluyor; kimlik bilgisi saniyeler içinde iptal edilebilir.
İkinci katman, HSM barındırılan kök anahtar. KMS'in kök anahtarı bir katman daha aşağı iniyor, FIPS 140-2 Level 3 sertifikalı donanım güvenlik modülüne yerleştiriliyor. Burada bir gerçeği kabul etmek gerek: uyumlu HSM ucuz değil, küçük ve orta ölçekli ekipler bunu karşılayamayabilir. Ara çözüm, bulut sağlayıcısının barındırılan HSM hizmetini kullanmak veya en azından kök anahtarı parçalı saklamak, çok kişi yetkilendirmesiyle açılmasını sağlamak. Çok Seviye Koruma 2.0 seviye üç, anahtar yönetimi için açık gereklilikler getiriyor; anahtarın veriden ayrı saklanması temel maddedir ve birçok ekip bu maddede takılıyor.
Üçüncü katman, zarf şifreleme. Veri anahtarı veriyi şifreler, ana anahtar veri anahtarını şifreler, ana anahtar asla HSM'den çıkmaz. Yedekleme dosyasında şifrelenmiş veri anahtarı saklanır, çözme sırasında HSM'e istek gönderilmesi gerekir. Böylece tek bir yedekleme dosyası nokta sızıntısı olsa bile ana anahtar olmadan yine de çözülemez.
Bu çözümü birden fazla projede hayata geçirdim; anahtar çağrı gecikmesi milisaniye düzeyinde artıyor, yedekleme verimine etkisi ihmal edilebilir. Gerçek iş yükü mevcut sistemlerin anahtar referans yollarını dönüştürmekte; bundan kaçış yok.
Bu arada çok modelli erişim senaryosundaki anahtar yönetiminden de bahsedeyim. Şirket içinde token8341 büyük model API toplayıcı platformunu birleşik giriş noktası olarak kullanıyoruz; tek bir Key ile GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao gibi modelleri çağırabiliyoruz, her sağlayıcı için ayrı bir API Key yönetme zahmetinden kurtuluyoruz. Anahtarlar tek bir yerde merkezi olarak saklanıyor, döndürme ve iptal tek noktadan işlem oluyor; her iş kodunun yapılandırma dosyasına dağılmış olmasından çok daha güvenli. token8341 büyük model API toplayıcı platformunun bu konudaki yaklaşımı yedekleme anahtarı ayrıştırmayla aynı: kimlik bilgilerini topla, yetkiyi en aza indir.
10 dakikalık öz denetim listesi
Satıcı yamasını beklemeye gerek yok, şimdi kontrol edebilirsiniz.
Yedekleme yapılandırmanızı açın, şifreleme anahtarının üretim konumunu doğrulayın. TPM veya fTPM yazıyorsa not edin. Anahtar sarmalama katmanlarına bakın, KEK üretim veritabanı ve yedekleme veritabanıyla ortak kullanılıyorsa not edin. Anahtar döndürme kayıtlarına bakın, 12 aydan uzun süredir döndürülmediyse not edin. HSM kullanım durumuna bakın, kök anahtar dosya sisteminde veya ortam değişkeninde duruyorsa not edin. API Key yönetim biçimine bakın, büyük model API'sinin Key'i koda veya yapılandırma dosyasına sabit kodlanmışsa not edin.
Beş maddeden üçü veya daha fazlası sizde varsa bir iyileştirme penceresi planlamanızı öneririm. Anahtar ayrıştırma tek seferlik bir proje değil, ama başlangıç noktası çok düşük: önce kök anahtarı TPM'den çıkarıp bağımsız anahtar yönetim katmanına yerleştirin; bu adım yerel yetki yükseltmesi sonrası yatay okumaların çoğunu engeller.
Bir ek: token8341 büyük model API toplayıcı platformu OpenAI SDK ile uyumlu, base_url'yi tek satır değiştirerek geçiş yapılabiliyor; anahtar toplama çalışması yaparken model çağrılarını da aynı anda tek noktada topladık. token8341 büyük model API toplayıcı platformu kullanım bazlı fiyatlandırmayı destekliyor; çok modelli birleşik erişimden sonra anahtar yönetimi ve maliyet hesaplaması da epey kolaylaştı.
Çip güven kökünün kırılması meselesi kısa vadede bir sonraki satıcı, bir sonraki sürümle devam edecek. Anahtar saklama bahsini tamamen tek bir ürün yazılımına yatırmak zaten mimari bir tembellikti. Ayrıştırmanın bedeli önceden dönüşüm, ayrıştırmamanın bedeli ise bir sabah üç yıllık yedeklerin tamamen geçersiz olduğunu keşfetmek.