Ayrıcalıklı Hesap Olmamalı. Peki Sabah 03:00'te Kim Girdi?

"Üretimde kimsenin yetkisi yok." Bu cümle çok kurumda duyuluyor ve çoğunda bir kısmı doğru: geliştiricilerin üretime doğrudan erişimi kapatılmış, değişiklikler hat üzerinden geçiyor, tablo başına yetkiler dar. Sonra bir soru geliyor: "Peki DBA hesapları? Servis hesapları? Tedarikçinin bağlandığı hesap? Acil durum hesabı?" Cevap genellikle bir duraklama ve şu oluyor: "Onlar başka tabii." Bu yazı o "başka tabii" hesaplar hakkında.

Sıfır Kalıcı Yetki Nereye Gidiyor?

Fikrin adı artık yerleşti: sıfır kalıcı yetki. Kimsenin sürekli yetkisi olmaz; iş için gereken yetki, gereken süre için verilir, iş bitince geri alınır. Kimlik ve erişim ürünleri bunu giderek daha çok veritabanlarına ve yapay zekâ kimliklerine de uyguluyor. Fikir doğru. Ama uygulamada iki şey yaşanıyor:

• Kalıcı yetkinin tamamen kalkması bir gecede olmaz. Yıllarca birikmiş hesaplar, servis kimlik bilgileri, paylaşılan parolalar vardır.
• Yetkiyi kaldırmak yetmez. Kaldırıldığını sürekli göstermek gerekir.

Üç Katman: Zorla, İzle, Kanıtla

Ayrıcalıklı hesap sorununu üç ayrı iş olarak düşünmek gerekiyor. Üçünü aynı araçtan beklemek hayal kırıklığı getirir.

1. Zorla. Kalıcı yetkiyi veritabanında kaldırmak, erişimi süreli hale getirmek, parolayı kasada tutmak. Bu kimlik ve erişim yönetiminin işidir ve kurumun kararıdır.
2. İzle. Veritabanına giden her trafiği görmek ve beklenmeyen hesabı yakalamak. Bu veritabanı etkinlik izleme (DAM) ve SIEM işidir.
3. Kanıtla. İzinli olanın ne olduğunu, kimin onayladığını, hangi metnin çalıştığını ve bunun sonradan değiştirilemediğini göstermek. Bu yönetişim katmanının işidir.

SQL Change Guard'ın yaptığı üçüncüsüdür. Bilerek zorlamıyor: bir proxy değil, veritabanında hesap kapatmıyor. Bu satış dilinde bir eksik gibi görünebilir; mimari açıdan bir sınırdır ve dürüstçe söylenmesi gerekir. Yönetişim katmanı zorlamıyor ama zorlamanın işleyip işlemediğini ölçülebilir kılıyor, çünkü "izinli olan" bilgisi onda duruyor.

"Kalıcı Yetki Yok" Cümlesini Nasıl Test Edersiniz?

Bu cümlenin kanıtı bir politika belgesi değildir. Kanıtı, izinli hesap listesi dışında üretimde işlem olup olmadığıdır. Kurgu şöyle çalışır:

• Ürün üretim sunucusuna tek bir hesapla bağlanır. Bu hesap "beklenen hesaplar" listesinde durur.
• Ürün her bağlantıyı rol ve talep numarası taşıyan bir adla açar.
• Yürütme başladığında ve bittiğinde SIEM'e olay gider.
• DAM'de bu listenin dışındaki bir hesapla DDL, DML ya da yetki komutu görünürse SIEM alarm üretir. Kurumun kendi uygulama hesapları kurumun kendi listesindedir.

Yani "kimsenin yetkisi yok" cümlesi bir gün kendi kendini sınar. Yanlışsa bir hafta sonra sabah rapor olarak önünüze gelir.

Sabah 03:00 Gerçeği

Kalıcı yetkiyi kaldırmak kolay, acil durumu kaldırmak imkânsız. Üretimde bir yangın çıktığında birinin girmesi gerekir ve o an onay toplantısı yapılamaz. Acil yolu yok etmek yerine kanıtlı hale getirmek gerekir:

• Acil talep de bir taleptir. Gerekçe ister (olay numarası kurum ayarıyla zorunlu tutulabilir), onay adımlarını kısaltır ama atlamaz.
• İz ertesi sabah kapanır. Acil çalıştırma sonradan gözden geçirilmeden kapanmış sayılmaz. Gözden geçirme bekleyen kayıtlar raporda en üstte durur.
• Süzülemeyen izler vardır. Acil talebin oluşturma, onay ve çalıştırma olayları sıradan önemdedir ve kurum SIEM eşiğini yükseltirse süzülebilir. Süzülemeyenler şunlardır: acil gözden geçirme olayı, ITSM açıksa ITSM kapı istisnası, acil durum hesabıyla giriş ve adında acil, atlama ya da geçersiz kılma anlamı taşıyan olaylar. Bu yüzden acil izleme kuralı "acil talep açıldı" olayına değil, "acil çalıştırıldı ve gözden geçirilmedi" durumuna bağlanır.

Sonuç: 03:00'te giren kişi girebilir. Ama 09:00'da "dün gece kim girdi, neden, ne çalıştırdı, gözden geçirildi mi?" sorusu tek sayfada cevaplanır.

Bir Kontrolü Kapatan, İzini de Kapatabilir mi?

Ayrıcalıklı hesabın asıl tehlikesi yetkisi değildir. Tehlike, aynı kişinin kontrolü ve kaydı da değiştirebilmesidir. Bu yüzden üç şey ayrı yerlerde durmalıdır:

• Denetim izi, kaydı tutan kişinin değiştiremeyeceği biçimde imzalı olmalı.
• Yalnız ekleme yapılabilen bir defter ve dışarı yazılan düzenli bir özet, izin kendi içinde yeniden yazılmasını fark edilir kılmalı.
• Kontrolü gevşeten bir ayar değişikliği, süzgeç ne olursa olsun SOC'a gitmeli.

Bu, "yönetici ne kadar güvenilir" sorusunu "yönetici ne yaparsa yapsın fark edilir mi" sorusuna çevirir. İkincisi daha savunulabilir bir sorudur.

Sık Sorulan Sorular

Sıfır kalıcı yetki tek başına yeterli mi?

Hayır. Yetkiyi kaldırmak yetmez, kaldırıldığını sürekli göstermek gerekir. Zorlama kimlik ve erişim yönetiminin, tespit DAM ve SIEM'in, kanıt yönetişim katmanının işidir. Üçü birlikte çalışmadan kurgu eksik kalır.

Acil durum girişi nasıl kanıtlı hale gelir?

Acil talep gerekçe ister (olay numarası kurum ayarıyla zorunlu tutulabilir), onay adımlarını kısaltır ama atlamaz; gözden geçirilmeyen acil talepler raporda gözden geçirme bekleyen olarak görünür. Gözden geçirme olayı SIEM'de süzülemeyen bir olaydır; bu yüzden izleme kuralı "acil çalıştırıldı ve gözden geçirilmedi" durumuna bağlanmalıdır.

SQL Change Guard ayrıcalıklı hesabı kapatır mı?

Hayır. SQL Change Guard bir proxy değildir ve veritabanında hesap kapatmaz. Zorlamanın işleyip işlemediğini ölçülebilir kılar: izinli hesap ve talep bilgisi onda durur, alarm kuralı DAM ve SIEM tarafında yazılır.