Veritabanı İzleme (DAM) Yönetişim Değildir

Veritabanı erişim izleme araçları olgun ürünlerdir. Trafiği görürler, kural yazdırırlar, alarm üretirler ve denetim döneminde ciddi bir kayıt yığını sunarlar. Bu yazı onların eksik olduğunu iddia etmiyor. Anlatmaya çalıştığı şey daha basit: izleme ile yönetişim aynı soruya cevap vermez. Biri ne olduğunu yazar, diğeri olmasına kimin karar verdiğini.

"Guardium Var, Size Ne Gerek Var"

Bu cümleyi çok duyuyoruz ve makul bir cümle. Kurum bir izleme aracına ciddi para vermiştir, kurmuştur, kuralları yazmıştır ve denetimden geçmiştir. Yeni bir katmanın neden gerektiğini sormak doğru bir refleks.

Cevap tek bir ayrımda toplanıyor. İzleme aracı çalıştırma anında ve sonrasında devreye girer. Yönetişim katmanı çalıştırmadan önce devreye girer. İkisi arasındaki fark, kameranın turnikeden farkı kadardır. Kamera olan biteni kaydeder ve bu değerlidir. Turnike kimin gireceğine karar verir. Bir kurumun ikisine birden ihtiyacı olması, birinin yetersiz olduğu anlamına gelmez.

İzleme Aracı Tam Olarak Ne Yapar

Bir veritabanı erişim izleme aracı, veritabanına gelen trafiği yakalar ve yazdığınız kurallara göre kaydeder veya uyarır. Yakaladığı bilgi genellikle şudur: hangi oturum, hangi hesap, hangi kaynak adres, hangi saniye, hangi ifade. Bu bilgi doğrudur ve başka hiçbir yerden bu kadar güvenilir biçimde alınamaz.

İzleme aracının doğası gereği bilmediği şey ise kararın kendisidir. Kural, gelen trafiğe bakarak yazılır. Bir ifadenin izinli olup olmadığı bilgisi trafiğin içinde taşınmaz; o bilgi başka bir sistemde, çoğu zaman bir bilet kaydında veya bir e-postada durur.

İzlemenin Göremediği Üç Şey

1. İzin kararı ve dayandığı kural

Bir izleme aracı "bu güncelleme çalıştı" der. "Bu güncellemenin çalışması için gereken onay alınmıştı ve onay şu kurala dayanıyordu" diyemez, çünkü onay bilgisi ona hiç ulaşmaz. Denetçi ikinci cümleyi ister. Birinci cümle tek başına bir bulguyu kapatmaz.

2. Çalışan metnin onaylanan metin olduğu

Bilette bir betik durur, çalışan başka bir betiktir. Aradaki fark kötü niyet değil, sıradan bir düzeltmedir: bir kolon adı eklenmiş, bir koşul değişmiştir. İzleme aracı çalışan metni görür ama onaylanan metni hiç görmediği için ikisini karşılaştıramaz. Karşılaştırma, iki metnin de aynı kayıtta durduğu bir yerde yapılabilir.

3. Okuma tarafındaki gerekçe ve teslim

İzleme aracı bir sorgunun çalıştığını görür. Görmediği şey şudur: bu sorgu neden çalıştı, sonucu kaç satırdı, hangi kolonlar maskelendi, dosya kime gitti, alıcı adres onaylı mıydı ve dosya ne kadar süre saklanacak. Kişisel veri denetiminde sorulan sorular tam olarak bunlardır ve hiçbiri trafikte taşınmaz.

Kural Paradoksu: Engelleme Neden Kapatılır

Birçok izleme ürününün engelleme kipi vardır. Koşulsuz bir güncelleme geldiğinde işlemi durdurabilir. Teoride bu, sorunu kökten çözer. Pratikte kurumların önemli bir kısmı engellemeyi bilinçli olarak kapatır ve gerekçeleri sağlamdır.

Gerekçe şudur: engelleme, yetkili ve deneyimli bir veritabanı yöneticisinin bilerek yaptığı işi de durdurur. Milyonlarca satırlık planlı bir güncelleme, koşulsuz görünen ama tamamen doğru bir bakım işi, bir kurtarma müdahalesi. Bunları engellemek operasyonu kilitler. Kurum da makul olanı yapar: engellemeyi kapatır, uyarıyı açık bırakır ve telafi edici kontrol olarak "deneyimli kişi ve log" der.

Paradoks burada: en yüksek riskli işlemler, tam olarak engellemenin kapatıldığı işlemlerdir. Telafi edici kontrol de kişiye bağımlıdır. Bu, kötü bir tasarım değil; izleme aracının doğasının getirdiği bir sınırdır. İzleme aracı ifadenin niyetini bilemez, o yüzden ya hepsini durdurur ya da hiçbirini.

Yönetişim katmanı bu ikilemi başka bir yerden çözer. Amaç işlemi engellemek değil, riske göre güvenlik bariyerini yükseltmektir. Koşulsuz bir güncelleme veya geri alınamayan bir tablo boşaltma görüldüğünde işlem yasaklanmaz; ek onay istenir, otomatik çalıştırma kapanır, geri alma planı sorulur ve karar gerekçesiyle birlikte kayda geçer. Deneyimli yönetici işini yapmaya devam eder, sadece işi artık kayıtlıdır.

Ayrıcalıklı Hesap Gürültüsü

İzleme kurulumlarının en bilinen sıkıntısı, ayrıcalıklı hesapların ürettiği alarm yığınıdır. Veritabanı yöneticisi gün boyunca kuralları tetikleyen işler yapar. Hepsi meşrudur, hepsi alarm üretir ve bir süre sonra kimse alarmlara bakmaz. Kurum ya kuralı gevşetir ya da o hesabı istisna listesine alır. İkisi de kapsamı daraltır.

Kararın önceden verildiği bir düzende bu gürültü doğal olarak azalır. Ayrıcalıklı hesabın yaptığı iş zaten bir talebe, bir onaya ve bir kurala bağlıdır. İzleme aracı için beklenen davranış artık tanımlıdır; anlamlı alarm, beklenmeyen olandır.

İkisi Birlikte Nasıl Çalışır

Doğru kurgu, ikisini yarıştırmak değil katmanlamaktır. Üç katman birbirini doğrular:

Bu kurguda en değerli ürün, iki katmanın çapraz doğrulamasıdır. Kurum standardı gereği üretim veritabanına ulaşan her yol yönetişim kanalından geçiyorsa, o kanalda izi olmayan bir değişikliğin izleme aracında görünmesi doğrudan bir istisnadır. Tek başına hiçbir katman bunu söyleyemez; ikisi yan yana konduğunda cevap kendiliğinden çıkar. Aynı mantık korelasyon vergisini de düşürür: eşleştirmeyi her seferinde bir insanın yapması gerekmez.

Kendi Kurulumunuzu Ölçün

İzleme aracınızın kapsamını değil, kararınızın kapsamını ölçün. Beş soru:

• Geçen ay üretilen alarmların kaçı ayrıcalıklı hesaplardan geldi ve kaçı incelendi?
• Engelleme kipi hangi kurallarda açık, hangilerinde bilinçli olarak kapalı?
• Bir alarm için "bu işlem onaylıydı" demek kaç dakika sürüyor ve kaç sisteme bakmak gerekiyor?
• Üretimden veri okuma taleplerinin gerekçesi ve teslim adresi nerede duruyor?
• Kurum standardınız "yönetişim kanalı dışında değişiklik yapılmaz" diyor mu, yoksa bu bir alışkanlık mı?

Üçüncü sorunun cevabı dakikalarla ölçülüyorsa iki katman zaten birbirine bağlı demektir. Saatlerle ölçülüyorsa aradaki bağı her seferinde bir insan kuruyor.