Kanıt Paketini Denetçi Nasıl Doğrular?

Bir denetimde en sık duyulan cümlelerden biri şudur: "kayıtlarımız değiştirilemez." Deneyimli denetçi bunu not alır ama kanıt saymaz, çünkü cümleyi söyleyen taraf ile kaydı tutan taraf aynıdır. Bu yazı, o cümlenin yerine ne konabileceğini ve denetçinin kendi masasında hangi kontrolleri yapabileceğini anlatıyor.

Denetçinin Cevaplayamadığı Soru

Denetçiye bir ekran görüntüsü, bir Excel dosyası ya da veritabanından alınmış bir liste verildiğinde, elinde tek bir bilgi vardır: bu dosya kendisine bugün verildi. Dosyanın ne zaman üretildiğini, üretildikten sonra düzenlenip düzenlenmediğini ve hangi sistemden çıktığını dosyanın kendisinden okuyamaz.

Bu yüzden denetim sürer. Zayıf kanıt daha fazla örnek gerektirir, daha fazla örnek daha fazla soru üretir. Kanıtın gücünü artırmanın yolu daha çok belge göndermek değil, gönderilen belgenin denetçi tarafından tek başına kontrol edilebilir olmasıdır.

Doğrulanabilir Bir Paketin İçinde Ne Olur

Doğrulanabilir kanıt teslimi tek bir dosya değil, küçük bir dosya kümesidir. Kümenin biçimi standarttır ve her teslimde aynıdır; denetçi tek bir yordam öğrenir.

• Verinin kendisi. Düz metin, makine tarafından işlenebilir bir biçimde. Gözle de okunabilir olması önemlidir; denetçi ne imzalandığını görmelidir.
• Künye dosyası. Pakete hangi dosyaların girdiğini ve her birinin SHA-256 özetini listeler. Paketten bir dosya çıkarılmasını yakalayan şey bu listedir.
• Künyenin imzası. Asimetrik bir imza, yani doğrulayan tarafın özel anahtara ihtiyacı yoktur.
• Açık anahtar. İmzayı kontrol etmek için gereken tek şey. Kurumdan ayrıca bir şey istenmez.
• Doğrulama betiği. Kolaylık içindir, kanıtın parçası değildir. Yaptığı her şey elle de yapılabilir olmalıdır.

SQL Change Guard bu ambalajı üç ayrı teslimde de aynı biçimde kullanır: bir talebin denetim dosyası, günlük çapaların paketi ve ham denetim kayıtlarının paketi. Üçü farklı soruya cevap verir ama kabuğu aynıdır.

Dört Adım, Dört Ayrı Soru

Doğrulamanın adımları birbirinin yerine geçmez. Birinin geçmesi diğerini geçmiş saymaz ve bu ayrım, denetçinin raporuna ne yazacağını belirler.

1. Dosyalar değişmiş mi. Künyedeki listeye bakılır ve her dosyanın SHA-256 özeti yeniden hesaplanır. Tutmayan bir satır, o dosyanın paket üretildikten sonra değiştiğini gösterir.
2. Künye kimden geldi. İmza, paketteki açık anahtarla doğrulanır. Geçerse künye, ilgili özel anahtarı elinde tutan kurulumdan çıkmıştır ve o günden beri tek bayt değişmemiştir.
3. Anahtar doğru anahtar mı. Açık anahtarın parmak izi hesaplanır ve kurumun paketin dışında yayımladığı değerle karşılaştırılır.
4. İçerik kendi içinde tutarlı mı. İlk üç adım ambalajı doğrular. Dördüncüsü içeriğe bakar: kayıtların birbirine bağlı olması ve daha önce teslim alınmış bir değerle karşılaştırma.

Atlanan Adım: Parmak İzi

Üçüncü adım en sık atlanan ve atlandığında ikinci adımı anlamsız kılan adımdır. Paketin içindeki açık anahtarla paketin içindeki imzayı doğrulamak, kendi kendini onaylayan bir işlemdir: kim olursa olsun kendi anahtar çiftini üretip her ikisini de pakete koyabilir ve doğrulama geçer.

Parmak izi bu döngüyü kırar. Kurum, kanıt imzalama anahtarının parmak izini paketten bağımsız bir kanaldan bildirir: sözleşme eki, denetim el kitabı, kurumsal portalde sabit bir sayfa. Denetçi paketteki anahtarın parmak izini hesaplar ve o dış değerle karşılaştırır. Ancak o zaman imza bir köken kanıtına dönüşür.

Parmak izinin anahtarın kendisinden alınması gerekir, anahtarı taşıyan metin dosyasından değil. Aynı anahtar iki kurulumda farklı satır sonlarıyla yazılabilir; metnin özeti değişir, anahtar değişmez. Bu yüzden özet, anahtarın ikili gösteriminden alınır.

Doğrulamanın Kanıtlamadığı Şeyler

Dürüst olmak, uzun vadede daha ikna edicidir. Bir doğrulama başarılı geçtiğinde şunlar gösterilmiş olur: paket üretildiğinden beri değişmedi, ilan edilmiş anahtarı elinde tutan kurulumdan çıktı ve içindeki kayıtlar birbirine bağlı.

Gösterilmeyen şey, kayda yazılanın o gün doğru olduğudur. Mühür bir kaydın erken yazıldığını gösterir, doğru olduğunu değil. Yanlış bilgi de imzalanabilir ve imza onu doğru yapmaz. Denetçinin içeriği değerlendirmesi hâlâ gerekir; doğrulamanın yaptığı şey, içeriğin sonradan değiştirilmiş olma ihtimalini masadan kaldırmaktır.

İkinci sınır şudur: hiç kayıt üretilmemiş bir işlem, kanıt paketinde görünmez. Ürünün dışından, doğrudan veritabanına yapılan bir müdahaleyi gösterecek olan şey imza değil, veritabanı seviyesinde tutulan ayrı izdir. İki mekanizma farklı sorulara bakar ve biri diğerinin yerini almaz.

Kurum Tarafında Ne Yapmak Gerekir

Doğrulanabilir kanıt üretmek teknik olarak zor değildir, ama üç kurumsal karar gerektirir.

• Anahtar sahipliği. Kanıt imzalama anahtarı kurumun kendi anahtar yönetimi disiplinine girmelidir. Üründe gömülü bir anahtar bulunmamalı, anahtarı kurum belirlemelidir.
• Parmak izinin yayımlanması. Bir kez yapılır ve rotasyonda güncellenir. Yapılmazsa imza kontrolü kendi kendini onaylayan bir işleme düşer.
• Kurulum kimliği. Her kurulumun kendine ait bir etiketi olmalıdır. Aynı etiketi taşıyan iki kurulumun dosyaları birbirinin yerine geçebilir ve "bu paket bizim kurulumumuzdan mı" kontrolü sessizce anlamsızlaşır.

Bunlar kurulduğunda denetim konuşması değişir. "Kayıtlarımız değiştirilemez" cümlesi yerini şuna bırakır: "şu paketi alın, şu komutu çalıştırın, sonucu kendiniz görün." İkinci cümle test edilebilir olduğu için birincisinden çok daha güçlüdür.

Sık Sorulan Sorular

Denetçiye imza anahtarımızı vermemiz gerekir mi?

Hayır ve vermemelisiniz. İmza asimetriktir: doğrulama açık anahtarla yapılır, açık anahtar da paketin içinde gider. Özel anahtar kurumda kalır. Denetim zincirini imzalayan anahtar da ayrıdır ve o hiç dışarı çıkmaz; en değerli iki kontrol zaten o anahtarı gerektirmeyecek biçimde kurgulanmıştır.

Doğrulama için özel bir yazılım kurmak gerekir mi?

Gerekmez ve gerekmemesi bir tasarım kararıdır. Kanıtı bağımsız kontrol etmesi gereken kişiye sizden bir şey kurdurmak, bağımsızlığı zayıflatır. Windows ile gelen PowerShell ya da openssl bütün adımlar için yeterlidir. Pakete konan betik yalnızca kolaylıktır.

Paketi kim üretebilmeli?

Ayrı bir izinle sınırlanmalıdır. Paket betiklerin tam metnini, hangi sunucularda çalıştığını ve onaylayanları içerir; kurum dışına çıkabilen hassas bir dosyadır. Ayrıca paketin üretilmesi de bir olaydır ve denetim izine yazılmalıdır. Bu kayıt, teslimlerin düzenli yapıldığını sonradan göstermenin de tek yoludur.

Doğrulama başarısız olursa bu kurcalama anlamına mı gelir?

Doğrudan değil. En sık sebep taşıma sırasında bozulan bir dosya ya da zip açılırken yapılan bir hatadır. Doğru yaklaşım, paketi yeniden istemek ve kontrolü tekrarlamaktır. İkinci kez de tutmuyorsa bu bir bulgudur ve sebebi kurumdan yazılı olarak istenmelidir. Anlamlı olan, sonucun her iki halde de belirsiz kalmamasıdır.