Kanıtı İmzalayan Anahtar Nerede Durmalı?

İmzalı bir kanıt dosyası, imzayı üreten anahtar kadar güçlüdür. Anahtar yanlış yerde duruyorsa imza teknik olarak kusursuz çalışır ama hiçbir şey kanıtlamaz. Bu yazı, kanıt imzalama anahtarının nerede durması gerektiğini ve kurumların bu konuda yaptığı tipik hataları anlatıyor.

Anahtar Neden Veritabanında Duramaz

İmzanın verdiği güvence tek bir cümleyle özetlenir: imzalı bir dosyayı, özel anahtara sahip olmayan biri değiştirip yeniden imzalayamaz. Bu cümle yalnızca özel anahtar, kayıtlara ve dosyalara ulaşabilen kişilerin ulaşamadığı bir yerdeyse doğrudur.

Anahtar bir tabloda tutuluyorsa, kaydı değiştirmek isteyen kişi zaten oradadır. Doğru yer, uygulamanın yapılandırma katmanı ya da işletim sisteminin sertifika deposudur; özel anahtarın dışa aktarılamaz işaretlendiği bir sertifika deposu daha da iyidir. Kriter basittir: veritabanı yöneticisinin olağan yetkileriyle ulaşabildiği hiçbir yer uygun değildir.

Simetrik mi, Asimetrik mi

Kanıt imzalamada anahtar tipinin seçimi, denetçinin neyi bağımsız yapabileceğini belirler.

• Simetrik anahtar (örneğin HMAC). İmzalayan da doğrulayan da aynı anahtarı bilir. Bu yüzden anahtar denetçiye verilemez; doğrulama ancak ürünün içinden yapılabilir ve denetçi ürünün söylediğine güvenmek zorunda kalır.
• Asimetrik anahtar (örneğin RSA). Özel kısım kurumda kalır, açık kısım pakete konur. Denetçi imzayı kendi makinesinde doğrular ve kurumdan hiçbir sır istemez. İmza anahtarı tanımlı kurulumda SQL Change Guard kanıt dosyalarını, dönem paketlerini ve defter özetlerini RSA ile imzalar; imza kurulumda açılır, anahtar tanımlı değilse paketler imzasız üretilir ve doğrulama betiği bunu açıkça yazar.

Açık anahtarın paketin içinde olması tek başına güven vermez: kendi anahtarını pakete koyan biri de imzayı geçirir. Bu yüzden kurum, açık anahtarın parmak izini paketlerden bağımsız bir yerde (iç portal, imzalı yazı) yayımlar ve denetçi paketteki anahtarı bu değerle karşılaştırır. Kayıtların kendisi ise hiçbir anahtara dayanmaz: SQL Server ledger tablosunda motor tarafından korunur ve SQL Server'ın kendi yordamıyla doğrulanır.

Anahtara Kim Erişebilmeli

Cevap, mümkün olan en az sayıda kişi ve bu kişilerin veritabanı yöneticisi olmamasıdır. Buradaki asıl mesele bir kişiyi güvenilmez saymak değil, yetkilerin kesişimini engellemektir.

Bir kişi hem kayıtları değiştirebiliyor hem de imza anahtarına erişebiliyorsa, imzalı dosya o kişi için bir kontrol değildir. Denetçinin sorduğu soru da tam olarak budur: bu iki yetki aynı kişide birleşiyor mu?

Pratikte üç ayrım işe yarar: anahtar sunucu yöneticisinde, veri veritabanı yöneticisinde, kanıt üretme yetkisi ise ayrı bir izinle üçüncü bir rolde durur. Küçük ekiplerde bu kesişim tamamen engellenemeyebilir; o zaman doğru davranış, kesişimi bir bulgu olarak kabul edip telafi edici kontrol tanımlamaktır. Defter özetinin veritabanı ekibinin silemediği bir depoya yazılması tam olarak böyle bir telafi edici kontroldür.

Rotasyon: En Sık Yapılan Hata

Anahtar politikaları genellikle periyodik rotasyon ister. Kanıt imzalamada rotasyonun bir tuzağı vardır: anahtarı değiştirdiğinizde eski dosyalar eski anahtarla imzalanmıştır ve yeni anahtarla doğrulanamaz.

Naif çözüm eski dosyaları yeni anahtarla yeniden imzalamaktır ve bu, imzanın bütün anlamını yok eder: geçmişi yeniden mühürleme yeteneğini kurumsal bir prosedür haline getirmiş olursunuz.

Doğru çözüm bir anahtar halkasıdır. Her dosya, hangi anahtarla imzalandığını gösteren bir kimlik taşır. İmza her zaman aktif anahtarla atılır, eski anahtarların açık kısmı halkada kalır ve eski dosyalar onlarla doğrulanmaya devam eder. SQL Change Guard bu deseni kullanır: manifestte imzalayan anahtarın kimliği yazar.

Anahtar Kaybolursa

Asimetrik imzada özel anahtarın kaybı geçmişi bozmaz: daha önce imzalanmış dosyalar, açık anahtar elde olduğu sürece doğrulanmaya devam eder. Kaybedilen şey yeni imza atma yeteneğidir; yeni bir anahtar üretilir, parmak izi yeniden yayımlanır ve imza yeni anahtarla devam eder.

Asıl tehlike kayıp değil sızıntıdır. Özel anahtarı ele geçiren biri, kurum adına imzalı görünen dosya üretebilir. Bu yüzden anahtarın yedeği de erişim kontrolüne tabidir ve sızıntı şüphesinde anahtar hemen değiştirilip eski parmak izinin hangi tarihe kadar geçerli olduğu yazılı olarak duyurulmalıdır. Kayıtların bütünlüğü ise bundan etkilenmez; o, imzaya değil deftere ve dışarı yazılmış özetlere dayanır.

Denetçiye Gösterilecek Kontrol Listesi

Bu altı sorunun yazılı cevabı varsa, anahtar yönetimi konusu denetimde bir bulgu üretmez.

• Özel anahtar nerede saklanıyor ve veritabanı yöneticisi oraya ulaşabiliyor mu?
• Açık anahtarın parmak izi paketlerden bağımsız olarak nerede yayımlandı?
• Anahtar ne zaman ve nasıl değiştirilecek?
• Rotasyondan sonra eski dosyalar nasıl doğrulanacak?
• Anahtarın yedeği nerede ve o yedeğe kim ulaşıyor?
• Anahtara erişebilenle kayıtları değiştirebilen aynı kişi mi? Değilse nasıl ayrıldığı gösterilebiliyor mu?

Son soru en önemlisidir ve çoğu kurumun cevabı yoktur. Cevabınız "hayır, ayrı" ise bunu gösteren bir kayıt da olmalıdır. Yetki listesi bir ekran görüntüsü değil, değişiklikleri izlenen bir kayıt olduğunda o cevap kanıta dönüşür.

Sık Sorulan Sorular

Denetçiye hangi anahtarı vermeliyiz?

Yalnız açık anahtarı ve onun parmak izini. Özel anahtar kimseye verilmez. Denetçinin bağımsızlığı, açık anahtarla imza doğrulamasından ve SQL Server ledger defterinin kendi yordamıyla doğrulanmasından gelir; ikisi de özel anahtar gerektirmez.

Kurumsal anahtar kasası kullanmak zorunda mıyız?

Zorunlu değil. Kriter aracın markası değil, anahtarın veritabanına erişebilen kişilerin ulaşamayacağı bir yerde durmasıdır. İşletim sisteminin sertifika deposu da bunu sağlar. Kasa varsa kullanmak elbette daha iyidir; erişim kaydı ve rotasyon disiplinini beraberinde getirir.

Anahtar değiştiğinde eski kanıt dosyaları geçersiz mi olur?

Anahtar halkası doğru kurulduysa hayır. Her dosya hangi anahtarla imzalandığını taşır ve doğrulama o anahtarın açık kısmıyla yapılır. Eski açık anahtarlar ve parmak izleri saklanmalıdır.

Sunucu bağlantı parolaları da aynı anahtarla mı korunuyor?

Hayır ve olmamalıdır. Farklı işler farklı anahtar tipleri ister. Kullanıcı parolaları geri çevrilmesi gerekmediği için şifrelenmez, özetlenir. Sunucu bağlantı parolaları kullanılabilmek için geri çözülmelidir, bu yüzden hem gizlilik hem bütünlük veren bir kipte şifrelenir. Kanıt dosyaları ise asimetrik bir anahtarla imzalanır. Üç iş, üç ayrı yöntem ve ayrı anahtarlar.