Üretim sorguları için denetim kaydı, çalışmış her ifade için şunlara cevap vermenizi sağlamalı: kim istedi, kim onay verdi, tam olarak ne çalıştı ve ne yaptı. Kayıt yalnızca bir bağlantının gerçekleştiğini söylüyorsa bunların hiçbirine cevap veremez; çoğu veritabanı günlüğünün verdiği de budur.
Veritabanı günlükleri neyi kaçırır?
Bir veritabanı bir hesap ve bir ifade görür. Bir ekip tek bir hesabı paylaştığında, parola paylaşmadan üretim veritabanı erişimi yazısında tartışıldığı gibi, günlük kişiyi değil hesabı adlandırır. Onay diye bir kavramı yoktur; bu yüzden ifade çalışmadan önce ikinci bir kişinin onu okuduğunu gösteremez.
Bunların hiçbiri veritabanı günlüğünü işe yaramaz kılmaz. Onu bağımsız bir kaynak olarak tutun. Ama kimin yetkilendirildiğinin kaydı değildir.
Her kayıt neyi taşımalı?
Bir denetçinin üretim verisindeki bir değişiklik için sorduğu sorulara bakın:
- Kim talep etti, bir hesap olarak değil, adı olan bir kişi olarak.
- Kim onayladı, başka bir kişi ve hangi kanaldan: web kuyruğu mu, sohbet mesajı mı.
- Tam olarak ne çalıştı, bir özet değil, hazırlanmış SQL.
- Ne zaman başladı ve bitti, süresiyle birlikte.
- Neye dokundu, yazmalar için etkilenen satır sayısı olarak.
- Nasıl sonuçlandı, tamamlandı mı, başarısız mı.
- Çevresinde ne var: girişler, yetkilendirmeler, yapılandırma değişiklikleri ve sonuç indirmeleri; çünkü erişim sorgunun dışında da verilir ve kullanılır.
QueryProxy bir isteğin her adımı için bir kayıt yazar: gönderim, karar (kanal ve geçersiz kılma bayrağıyla), süre ve etkilenen satırlarla birlikte yürütmenin başlangıcı ve bitişi, sonuç indirmeleri; ayrıca girişler, yetkilendirmeler ve yapılandırma değişiklikleri. Referans onay akışıdır.
Kim okuyabilmeli?
Sorgulayabilen herkes değil. QueryProxy’de denetim günlüğü Denetçi ve Admin için ayrılmıştır; DBA’nın ona erişimi yoktur. Denetçi rolü salt okunurdur ve kaydı CSV olarak dışa aktarabilir; ayrıca takımın istek listesini ve ayrıntısını okur: SQL, durum, talep eden, gözden geçiren ve onay izi. Sonuç satırlarını göremez ya da indiremez. Bu ayrım önemlidir: kaydı kontrol eden kişinin bunu yapmak için veriyi görmesi gerekmemeli.
Kayda güvenilebilir mi?
İki dürüst sınır.
Birincisi, buradaki “değiştirilemez” uygulamayı tarif eder. Model katmanı güncellemeleri ve silmeleri reddeder; yani hiçbir ekran ve hiçbir API bir kaydı düzenlemeye izin vermez. Altındaki depolamaya doğrudan erişimi olan biri hakkında bir şey söylemez. O depolamayı hassas sayın ve yedekleyin.
İkincisi, IP adresi ancak proxy kurulumunuz kadar iyidir. Kayıtlar istemci IP’sini
QueryProxy’nin gördüğü haliyle tutar. Bir reverse proxy’nin arkasında, onu
TRUSTED_PROXIES içinde belirtmediğiniz sürece bu proxy’nin kendi adresidir;
üretim güvenliği rehberi, X-Forwarded-For’a
herkesten güvenmenin kayıttaki adresi de neden sahteleyebildiğini açıklar.
Kayıt ayrıca bir tutanaktır, izleyici değildir. Tuhaf bir şey olduğunda alarm üretmez; bu yüzden onu kimin ve ne sıklıkla okuyacağına karar verin.
Uyumluluğa ne katar?
Kanıt üretir. Bir kontrolü geçirmez. Talep, tam SQL’i, talep eden kişi olmayan adı belli bir onaylayan ve sonuç, denetçilerin istediği belgedir; SOC 2 sayfası kayıtları ilişkili oldukları ölçütlerle eşler, GDPR ve veritabanı erişimi ise veri koruma tarafını ele alır. Erişim gözden geçirmeleri ve olay müdahalesi gibi kuruluşunuzda kalanlar o sayfalarda listelenir.
Sohbet onayları nereye oturur?
Slack ya da Teams’ten onaylamak rahattır; bu yüzden kayıt bunu da kapsamalıdır. Sohbette alınan bir karar kanalıyla birlikte kaydedilir ve web ile aynı kurallara tabidir: kendi talebini onaylama engellenir ve bir yönetici geçersiz kılması kayıtta işaretlenir. Bunun nasıl çalıştığı Slack ve Teams üzerinden SQL onayı yazısında anlatılıyor.
Ne zaman daha basit bir kurulum yeter?
Üretimi tek kişi yönetiyorsa ve her değişiklik gözden geçirilmiş migration’lardan geçiyorsa, sürüm kontrol geçmişiniz zaten denetim kaydınızdır. İhtiyaç, üretime elle bakan çok kişi olduğunda ve biri sonradan bir ifadeyi kimin onayladığını sorduğunda ortaya çıkar.
Başka araçları tartıyorsanız, StrongDM karşılaştırması bir erişim platformunun ifade düzeyindeki bir onay kaydından nasıl ayrıldığını gösterir.
Sık sorulanlar
- Bir veritabanı denetim kaydı neler içermeli?
- Kimin istediği, kimin onayladığı, tam olarak neyin çalıştığı, ne zaman başlayıp bittiği, kaç satıra dokunduğu ve nasıl sonuçlandığı. QueryProxy'de bir isteğin her adımı bir kayıt yazar; girişler, yetkilendirmeler, yapılandırma değişiklikleri ve sonuç indirmeleri de buna dahildir.
- Veritabanının kendi sorgu günlüğü yeterli mi?
- Genellikle hayır. Çoğu zaman paylaşılan bir hesaptan gelen bir ifadeyi gösterir ve içinde bir onay yoktur. Bir gözden geçirenin ifadeyi görüp görmediğini de söyleyemez. Yararlı bir ikinci kaynaktır, kimin yetkilendirildiğinin kaydı değildir.
- Bir denetçi sorgu sonuçlarını görebilir mi?
- QueryProxy'de hayır. Denetçi rolü denetim günlüğünü, onun CSV dışa aktarımını, ayrıca SQL, durum, talep eden, gözden geçiren ve onay izini içeren istek listesi ile ayrıntısını okur. Sonuç satırlarını göremez ya da indiremez.
- Denetim günlüğü düzenlenebilir mi?
- Uygulama üzerinden hayır. Model katmanı güncellemeleri ve silmeleri reddeder. Günlüğü tutan depolamaya doğrudan erişimi olan biri bu güvencenin dışındadır; bu yüzden o depolamayı diğer hassas veriler gibi kısıtlayın ve yedekleyin.
- Denetim günlüğü neden reverse proxy'min IP adresini gösteriyor?
- Kayıtlar istemci IP'sini QueryProxy'nin gördüğü haliyle tutar. Bir reverse proxy'nin arkasında, proxy'yi TRUSTED_PROXIES içinde belirtmediğiniz sürece bu proxy'nin adresidir. Bunu ayarlayın ve rastgele kaynaklardan gelen X-Forwarded-For'a güvenmeyin.