İçindekiler
Veritabanı günlüğünde bir satır var: salı sabahı müşteri tablosunda otuz bin kayıt güncellenmiş. Oturumu açan hesabın adı bir uygulama hesabı. O hesabın parolasını dört kişi biliyor. Denetçi "bunu kim yaptı" diye soruyor ve kimse cevap veremiyor. Bu yazı, kaydın var olduğu halde neden kimseyi göstermediğini ve bunun nasıl düzeltileceğini anlatıyor.
Denetçinin Cevaplanamayan Sorusu
Denetimlerde en çok bulgu üreten soru "kayıt tutuyor musunuz" değildir. Kayıt genellikle tutulur. Bulgu üreten soru şudur: "Bu kaydı bir kişiye bağlayabiliyor musunuz?"
Veritabanı tarafında bu bağ sık sık kopar ve kopma teknik bir arıza değildir. Sistemin tasarlandığı şekilde çalışmasının doğal sonucudur. Uygulamalar tek bir hesapla bağlanır, yönetim işleri yükseltilmiş yetkili bir hesapla yapılır, bakım işleri bir zamanlayıcı hesabıyla koşar. Her biri kendi başına mantıklıdır; toplamı, hiçbir işlemin bir insana atfedilemediği bir ortamdır.
Kaydın olması yetmez
Denetim izinin üç özelliği birlikte aranır: olayın ne olduğu, ne zaman olduğu ve kimin yaptığı. İlk ikisi neredeyse her kurumda vardır. Üçüncüsü yoksa kayıt bir olay günlüğüdür, denetim izi değildir. Aradaki fark, sorumluluğun bir kişiye kadar izlenebilmesidir.
Kimliğin Kaybolduğu Beş Yer
| Durum | Günlükte görünen | Kaybolan |
|---|---|---|
| Uygulama havuz hesabı | Tek bir servis hesabı adı | İşlemi tetikleyen son kullanıcı. Uygulama içindeki kimlik veritabanına hiç ulaşmaz. |
| Ortak yönetici hesabı | Yükseltilmiş yetkili tek bir hesap | Ekipteki hangi kişinin bağlandığı. Parolayı bilen herkes aynı görünür. |
| Zamanlanmış işler ve bakım betikleri | Zamanlayıcı hizmet hesabı | İşin içeriğini kimin yazdığı ve en son ne zaman değiştirdiği. İçerik yıllar önce yazılmış olabilir. |
| Atlama sunucusu üzerinden bağlanma | Atlama sunucusunun adresi ve ortak hesap | Zincirin ilk halkası. Atlama sunucusunda kimlik varsa bile veritabanı onu görmez. |
| Tedarikçi güncelleme aracı | Ürünün kendi kurulum hesabı | Kurumdan kimin izin verdiği ve neyin değiştiği. Değişiklik dışarıdan gelir, sorumluluk içeride kalır. |
Bu beş durumun ortak noktası şudur: hiçbiri bir güvenlik açığı olarak raporlanmaz. Hepsi çalışan bir mimarinin parçasıdır. Sorun ancak bir şey ters gittiğinde ya da denetçi örneklem seçtiğinde görünür hale gelir.
Standartlar Ne Diyor
Bu konu, denetim standartlarının en net konuştuğu alanlardan biridir ve yorum payı azdır.
ISO/IEC 27001 kimlik yönetimi kontrolü bireysel hesap verilebilirliği ister: her kullanıcının başkasıyla paylaşılmayan benzersiz bir tanımlayıcısı olmalıdır. Ayrıcalıklı erişim hakları kontrolü ise yükseltilmiş yetkilerin sınırlı, tahsisli ve izlenebilir olmasını bekler. Birden fazla kişinin tek bir yönetici parolasını paylaştığı ve eylemleri kişiye bağlayacak bir düzenin bulunmadığı ortamlar denetimde uygunsuzluk olarak işaretlenir.
Kart ödeme standardı aynı beklentiyi daha keskin ifade eder: yönetici ve tedarikçi hesapları dahil her hesabın izlenebilirlik için benzersiz bir kimliği olmalıdır.
Standartların hepsi aynı kaçış kapısını da tanır: paylaşılan hesap teknik olarak kaçınılmazsa, telafi edici kontroller tanımlanır ve belgelenir. Kabul edilen tipik telafi, hesabın bir kasada tutulması ve her kullanımın bireysel olarak alınıp iade edilmesidir. Yani standart paylaşılan hesabı yasaklamaz; atfedilemez kullanımı yasaklar.
Paylaşılan Hesap Neden Tamamen Kaldırılamaz
Bu noktada verilen tipik karar hatalıdır: "paylaşılan hesapları kaldıralım." Uygulamada bu çoğu zaman mümkün değildir ve zorlandığında daha kötü sonuçlar üretir.
Bir uygulama, bağlantı havuzunu verimli kullanabilmek için tek bir kimlikle bağlanır. Her son kullanıcı için ayrı veritabanı oturumu açmak, havuzu işlevsiz bırakır ve performansı ciddi biçimde düşürür. Yani uygulama havuz hesabı bir ihmal değil, bilinçli bir mimari tercihtir.
Yönetim tarafında da mutlak bir ayrım her zaman kurulamaz. Bazı bakım araçları belirli bir hesapla çalışmak üzere tasarlanmıştır, bazı tedarikçi ürünleri kendi kurulum hesabını şart koşar. Bunları zorlamak, ekibi kayıtsız yollara iter: kişi kendi hesabıyla giremediği için ortak hesabı kullanır ve kullandığını da kimseye söylemez.
Yanlış hedef, doğru hedef
Hedef, paylaşılan hesapları yok etmek değildir. Hedef, paylaşılan bir bağlantı üzerinden yapılan her işlemin gerçek bir kişiye atfedilebilmesidir. Bu ikisi karıştırıldığında yıllarca süren ve hiç bitmeyen bir hesap temizliği projesi doğar; atıf sorunu ise olduğu yerde kalır.
Doğru Ayrım: Bağlantı Kimliği ve İşlem Kimliği
Sorunu çözen ayrım şudur. Veritabanına bağlanan kimlik ile işlemin sorumlusu olan kimlik aynı olmak zorunda değildir. Önemli olan, ikisi arasındaki bağın kayıtlı olmasıdır.
Bağlantı kimliği teknik bir gerekliliktir: hangi hesabın oturum açtığı, hangi haklara sahip olduğu. Bu genellikle bir servis hesabıdır ve öyle kalmalıdır.
İşlem kimliği yönetişim gerekliliğidir: bu işi kim istedi, kim onayladı, kim çalıştırdı. Bu bilgi veritabanı oturumundan çıkarılamaz; işin geçtiği katmanda üretilmesi gerekir.
Bu ayrım kurulduğunda cevap değişir. Veritabanı günlüğü hala servis hesabını gösterir, ancak o çalıştırmanın bir talep kaydı vardır ve o kayıt üç ayrı kişiyi adıyla taşır. Denetçinin sorusu artık cevaplanabilir: işlemi tetikleyen talebi kim açtı, hangi gerekçeyle onaylandı ve düğmeye kim bastı.
SQL Change Guard bu modeli kullanır. Hedef sunucuya kendi tanımlı bağlantısıyla erişir; çalıştırmayı başlatan kişi ise talep kaydında ayrıca tutulur ve zamanlanmış ya da paket akışlarda bile düğmeye basan kişi kaydedilir. Böylece paylaşılan bir bağlantı üzerinden yapılan iş, bireysel hesap verilebilirliği bozmadan yürür.
Uygulanabilir Kontrol Listesi
Aşağıdaki adımlar sırayla uygulanabilir ve hiçbiri mimariyi yeniden yazmayı gerektirmez.
1. Envanteri çıkarın. Üretim veritabanlarına bağlanan tüm hesapları listeleyin ve her birinin yanına tek bir bilgi yazın: bu hesabın arkasında kaç kişi var? Bu liste çoğu kurumda hiç yapılmamıştır ve tek başına aydınlatıcıdır.
2. Uygulama hesaplarını ayırın. Uygulama havuz hesapları bu tartışmanın konusu değildir; onların arkasındaki kimlik uygulama günlüğünde aranır. Odağı, insanların elle kullandığı hesaplara çevirin. Gerçek risk oradadır.
3. Elle kullanılan her hesap için atıf yolu tanımlayın. Kişi bu hesabı kullanacaksa hangi kayıt onu gösterecek? Cevap "hiçbiri" ise o hesabın kullanımı bir talep kaydına bağlanmalıdır.
4. Parolaları kayıttan çıkarın. Ortak parolanın bir sohbet başlığında, bir elektronik tabloda veya bir kişinin aklında durması aynı kapıya çıkar: parola değiştirildiğinde kimin hala erişebildiğini kimse bilmez. Parolalar merkezi olarak saklanmalı ve uygulama tarafında şifreli tutulmalıdır.
5. Ölçün. Geçen ay üretimde çalışan işlemlerin yüzde kaçı bir kişiye bağlanabiliyor? Bu tek sayı, tüm program boyunca izlenmesi gereken göstergedir ve zaman içinde yükselmelidir.
Sık Sorulan Sorular
Uygulama hesabını her kullanıcı için ayırmak çözüm değil mi?
Teoride evet, pratikte hayır. Uygulamalar bağlantı havuzunu tek bir kimlik üzerinden verimli kullanır; her son kullanıcı için ayrı oturum açmak havuzu işlevsiz bırakır ve performansı ciddi biçimde düşürür. Kullanıcı bazlı kimlik uygulama katmanında zaten vardır ve orada aranmalıdır. Veritabanı tarafında aranması gereken şey, uygulamanın kendi akışı dışında yapılan elle işlemlerin kime ait olduğudur.
Veritabanının kendi denetim özelliği bunu çözmez mi?
Veritabanı denetimi ne çalıştığını ve hangi oturumdan geldiğini çok iyi kaydeder. Kaydedemediği şey, o oturumun arkasındaki gerçek kişidir; çünkü bu bilgi veritabanına hiç ulaşmaz. Oturum bir servis hesabıysa denetim kaydı da servis hesabını gösterir. Eksik olan veri değil, verinin bağlanacağı kimliktir ve o kimliğin işin geçtiği katmanda üretilmesi gerekir.
Parola kasası kullanıyoruz. Bu yeterli mi?
Kasa doğru yönde önemli bir adımdır ve standartların kabul ettiği telafi edici kontrol tam olarak budur: hesabın kasada tutulması ve her kullanımın bireysel olarak alınıp iade edilmesi. Kasanın gösteremediği şey, alınan yetkiyle ne yapıldığıdır. Kayıt "Ayşe salı 09:40'ta hesabı aldı" der; "Ayşe müşteri tablosunda otuz bin satır güncelledi ve bu iş şu talebe dayanıyordu" diyemez. İki kayıt birlikte anlamlıdır.
Veritabanı yöneticisi doğrudan yönetim aracıyla bağlanırsa bu katman devre dışı kalmaz mı?
Kalır ve bunu açıkça söylemek gerekir: bir yönetim aracıyla sunucuya bağlanabilen kişiyi hiçbir yönetişim katmanı yazılım olarak durduramaz. Bu bir ürün eksiği değil, mimarinin gerçeğidir. Kapatılması gereken şey teknik bir engel değil, iki katmanlı bir disiplindir. Birincisi kapsam: üretim sunucularına doğrudan bağlanabilen kişi sayısının azaltılması ve kalan bağlantıların gerekçeli olması. İkincisi çapraz doğrulama: veritabanı erişim izleme kaydınız ile talep kayıtlarınız periyodik olarak karşılaştırılır ve talebe karşılık gelmeyen her işlem bir istisna olarak listelenir. Bu liste boş değilse süreç kapsamı eksiktir; boşsa disiplin çalışıyordur. Yönetişim katmanının değeri, doğrudan bağlantıyı imkansız kılmak değil, doğrudan bağlantıyı fark edilir kılmaktır.
Küçük bir ekibiz, herkes birbirini tanıyor. Yine de gerekli mi?
Atıf, güvensizlikle ilgili değildir; koruma ile ilgilidir. Üretimde bir şey bozulduğunda ve kim yaptığı bilinmediğinde, şüphe o hesaba erişimi olan herkesin üzerinde kalır. Kaydın net olması, işi yapmayan kişileri de korur. Ayrıca ekipler değişir: bugün herkesin tanıdığı dört kişi, iki yıl sonra ayrılmış olabilir ve o zaman geriye yalnızca kayıt kalır.
Nereden başlamak gerekir?
Hesap envanteriyle ve tek bir soruyla: her hesabın arkasında kaç kişi var? Ardından yalnızca insanların elle kullandığı hesaplara odaklanın ve her biri için bir atıf yolu tanımlayın. Bu iki adım, mimariye dokunmadan denetimdeki en büyük bulgu kalemini kapatır. Uygulama hesapları için ise doğru cevap onları bölmek değil, elle yapılan işi ayrı bir kayda taşımaktır.
Kendi hesap envanterinizle bakalım
Paylaşılan bir bağlantı üzerinden yapılan işin nasıl kişiye atfedildiğini, sizin senaryonuzla canlı gösterelim.
Demo Planlayın →