DAM Her Şeyi Görür, Hangisinin İzinli Olduğunu Bilmez

Denetçi ekrana tek bir cümle yazar: "Bu çeyrekte üretim sunucularında 412 şema değişikliği çalışmış. Kaçı onaylıydı?" Odada iki ekip var. Güvenlik ekibi veritabanı etkinlik izleme (DAM) raporunu tutuyor: her değişiklik, hesap, saat, sorgu. Değişiklik yönetimi ekibi talep listesini tutuyor: kim istedi, kim onayladı, ne zaman. İki liste de doğru. Ama biri diğerine bakmıyor.

Sonraki iki hafta iki tabloyu elle eşleştirmekle geçiyor. Buna değişiklik mutabakatı deniyor ve çoğu kurumda hâlâ bir Excel işi.

DAM Neyi Görür, Neyi Göremez?

DAM'in gücü kapsamıdır. Veritabanına giden her yolu görür: DBA'nın kendi bağlantısı, uygulama servis hesapları, tedarikçi hesapları, acil durum hesabı. Hangi hesap, hangi makineden, hangi sorguyu, ne zaman çalıştırdı sorusuna eksiksiz cevap verir. Göremediği şey niyettir: "Bu işlem onaylı mıydı? Çalışan metin, onaylanan metin miydi?" Onay veritabanının içinde yaşamaz, bir süreç sisteminde yaşar.

Süreç Sistemi Neyi Bilir, Neyi Bilmez?

Süreç sisteminin gücü bilgidir: talebi, gerekçeyi, onaylayanı, riski, çalıştırılan metnin özetini ve sonucu bilir. Bilmediği şey kapsamdır: yalnız kendi üzerinden geçen işi görür. Aynı veritabanına başka bir yoldan girilmişse süreç sistemi için o iş hiç olmamıştır.

• DAM her şeyi görür, hangisinin izinli olduğunu bilmez.
• Süreç sistemi izinli olanı bilir, geri kalanı görmez.

İki eksik aynı hikâyenin iki yarısıdır.

Birleşince Ne Olur?

Yönetişim katmanı DAM ve SIEM'e üç bilgi verirse kural yazılabilir hale gelir.

1. Hangi hesap izinli. SQL Change Guard üretim sunucusuna tek bir SQL hesabıyla bağlanır. "Beklenen hesaplar" raporu yalnız bu hesabı verir. Kurum kendi uygulama hesaplarını kendi DAM ve SIEM listesine ekler; ürün bu hesapları bilmez, bilmesi de gerekmez.
2. Hangi oturum hangi talebe ait. Ürün her bağlantıyı kendini tanıtan bir adla açar: SQL Change Guard/Execute/123 gibi rol ve talep numarası. DAM'in kayıtlarında "bu oturum 123 numaralı talebin yürütmesi" yazar.
3. İş hangi pencerede yapıldı. Yürütme başladığında ve bittiğinde SIEM'e birer olay gider. Olayda yürütmenin başlangıç ve bitiş zamanı, kullanılan SQL hesabı ve yürütücü makinenin adı (executorHost) bulunur.

Salı günü 14:02'de olan şey şöyle okunur:

Aynı sunucuda 14:20'de başka bir hesapla bir ALTER TABLE görünürse eşleşen bir olay yoktur. Alarm.

Kural "Üç Şey Birlikte"

Uygulama adı bağlanan tarafın kendi beyanıdır. Bir hesabı olan herkes bağlantı dizesine aynı adı yazabilir. Bu yüzden doğru kural yalnız ada bakmaz, üç şeyi birlikte arar:

• Hesap yürütücünün hesabı mı?
• DAM'deki istemci adresi, olaydaki yürütücü makine adıyla (executorHost) uyuşuyor mu?
• O pencerede eşleşen bir olay var mı?

Ad, eşleştirmeyi kolaylaştıran bir ipucudur. Kanıt hesap, adres ve olaydır.

Ne Zorlar, Ne Zorlamaz?

• Zorlama veritabanında yapılır.
• Tespit DAM ve SIEM'de yapılır.
• Kanıt yönetişim katmanında durur.

Yalnız zorlama yapan kurum zorlamanın delindiğini öğrenemez. Yalnız izleyen kurum izlediği şeyin izinli olup olmadığını bilemez.

Kendi Kurumunuza Üç Soru

1. Geçen ay üretimde çalışan değişikliklerin kaçının onaylı bir talebi vardı? Bu sayıyı bir saat içinde üretebilir misiniz?
2. DAM'inizde "beklenen hesaplar" listesi var mı, yoksa her hesap izinli mi sayılıyor?
3. Onaylı bir işlemi çalıştıran hesabın başka yerde kullanıldığını fark edebilir misiniz?

Üçüncü soruya cevabınız "hayır" ise onay sistemi sağlam olsa bile kapı arkadan açıktır.

Sık Sorulan Sorular

DAM ile değişiklik yönetimi aracı birbirinin yerine geçer mi?

Hayır. DAM veritabanına giden her yolu görür ama onayı bilmez. Süreç sistemi onayı bilir ama yalnız kendi üzerinden geçen işi görür. İkisi birbirini tamamlar: DAM kapsamı, yönetişim katmanı izinli olanın bilgisini verir.

Oturum adına bakarak izinli işlemi anlayabilir miyiz?

Tek başına hayır. Uygulama adı bağlanan tarafın beyanıdır ve bir hesabı olan herkes aynı adı yazabilir. Doğru kural hesabı, istemci adresini (yürütücü makine adıyla karşılaştırarak) ve o penceredeki eşleşen olayı birlikte arar.

SQL Change Guard veritabanına başka yoldan girişi engeller mi?

Hayır. SQL Change Guard bir proxy değildir. Erişimi zorlamak kalıcı yetkileri veritabanında kaldırmakla olur ve kurumun kararıdır. Ürün, DAM ve SIEM ile birlikte zorlamanın işleyip işlemediğini görünür kılar.

Kurumun kendi uygulama hesapları beklenen hesaplar listesine nasıl girer?

Kurum kendi uygulama hesaplarını kendi DAM ve SIEM listesine ekler. Ürünün "beklenen hesaplar" raporu yalnız ürünün kendi yürütme hesabını verir.