Yetki Değişikliği: Denetimin En Sessiz Boşluğu

Bir kurumda değişiklik yönetimi kurulduğunda kapsam genellikle şema ve veri değişiklikleriyle sınırlı kalır. Yetki değişikliği ise arada kalır: şema değiştirmez, veri değiştirmez, bu yüzden hiçbir aracın doğal kapsamına girmez. Oysa üretim veritabanında yapılan en kalıcı ve en sessiz değişiklik odur.

Neden Kimsenin Kapsamında Değil

Yetki değişikliği bir sınıflandırma sorunu yüzünden kapsam dışında kalır. Şema sürümleme aracı onu taşımaz, çünkü sürümlenen şey tablo yapısıdır. Kimlik yönetimi sistemi onu görmez, çünkü verilen yetki uygulamanın değil veritabanının kendi yetkisidir. Değişiklik yönetimi süreci onu istemez, çünkü "bir kolon eklendi" gibi somut bir çıktısı yoktur.

Sonuçta bir GRANT ifadesi genellikle şu yolu izler: birisi sorar, veritabanı yöneticisi çalıştırır, iş biter. Ne talep vardır ne onay ne de gerekçe. Bu, kurumun en yetkili kişilerine verilen en sessiz güçtür.

Yetki Değişikliğini Diğerlerinden Ayıran Üç Şey

Bir: belirtisi yoktur. Yanlış bir şema değişikliği uygulamayı bozar ve hemen fark edilir. Yanlış bir veri değişikliği rapora yansır. Fazladan verilmiş bir yetki hiçbir şeyi bozmaz; yalnızca birinin görmemesi gereken veriyi görebilmesini sağlar. Belirti olmadığı için kendi kendine ortaya çıkmaz.

İki: kalıcıdır. Şema değişikliği bir sonraki sürümle güncellenir, veri düzeltmesi bir kez çalışır. Yetki ise verildiği gibi kalır. Yıllar önce bir sorunu çözmek için verilmiş bir yetki, o sorun çoktan unutulduktan sonra da yürürlüktedir.

Üç: birikir. Tek tek bakıldığında her yetki makuldür. Beş yıl sonra toplamına bakıldığında, kimsenin bilerek vermeyeceği bir erişim haritası çıkar. Bu birikime yetki şişmesi denir ve denetimin en sık bulgu ürettiği alandır.

Güncel Yetki Listesi Neden Kanıt Değil

Denetçi yetki sorduğunda çoğu kurum veritabanından güncel yetki listesini çıkarır. Bu liste doğrudur ama sorulan soruyu cevaplamaz.

Güncel liste bir fotoğraftır, kayıt ise filmdir. Denetim filmi ister: yetkinin nasıl bugünkü hâline geldiğini görmek ister. Fotoğrafla cevaplanan tek soru "şu an ne var" sorusudur ve denetçinin en az ilgilendiği soru odur.

Kaydın Taşıması Gereken Altı Alan

Bir yetki değişikliği kaydı, sonradan sorulacak her soruyu tek başına cevaplayabilmelidir:

1. Kime. Yetkiyi alan kullanıcı ya da rol. Betikten ayrıştırılıp ayrı bir alan olarak saklanmalı; betiğin içinde metin olarak kalırsa aranamaz.
2. Ne. Verilen yetkinin kendisi: SELECT, EXECUTE, CONTROL, ALTER. Bu da ayrı alan olmalı.
3. Nerede. Hangi sunucu, hangi veritabanı, hangi nesne. Aynı yetkinin test ve üretimde farklı anlamı vardır.
4. Kim istedi. Talebi açan kişi ve varsa bilet numarası.
5. Kim onayladı. Onaylayan kişi, rolü ve o gün yürürlükte olan onay kuralı.
6. Neden. Yazılı gerekçe. Bu alan boş bırakılabiliyorsa, bir yıl sonra kimse hatırlamaz.

Geçici Yetki: Bir Günlüğüne Verilip Unutulan

Yetki şişmesinin en büyük kaynağı kötü niyet değil, geri alınmayan geçici yetkidir. Bir sorunu incelemek için bir günlüğüne verilen erişim, sorun çözüldükten sonra kaldırılmaz; çünkü kaldırmayı hatırlatan bir şey yoktur.

Bunun pratik çözümü basittir ve teknik değildir: geçici yetkinin geri alma betiği, verildiği anda hazırlanır. Yetki talebi açılırken karşılığı olan REVOKE ifadesi de üretilir ve bir tarihe bağlanır. Geri alma ayrı bir iş olmaktan çıkar, aynı talebin parçası olur.

İkinci pratik adım, yetki değişikliğini atlanamaz kural olarak işaretlemektir. Acil durumda birçok adım kısaltılabilir; erişim sınırını genişleten bir işlem kısaltılmamalıdır. Acil bir düzeltme için yetki gerekiyorsa, o yetki de kayda girer ve olay sonrası gözden geçirmede tekrar bakılır.

Sık Sorulan Sorular

Yetki yönetimini kimlik yönetimi sistemimiz yapmıyor mu?

Kimlik yönetimi kişinin hangi uygulamalara ve gruplara ait olduğunu yönetir, bunu iyi yapar. Veritabanının kendi yetkileri çoğu zaman bunun dışındadır: bir kullanıcıya doğrudan verilen SELECT yetkisi ya da bir veritabanı rolüne eklenen üyelik, kimlik sisteminde görünmez. İkisi birbirini tamamlar; veritabanı tarafındaki değişikliğin de kendi kaydı olmalıdır.

Rol üzerinden yönetsek yetki takibi kolaylaşmaz mı?

Kolaylaşır ve doğru yaklaşım budur. Ama sorun yer değiştirir: bu kez rolün kendisine hangi yetkilerin eklendiği ve role kimin üye yapıldığı izlenmelidir. Rol üyeliği de bir yetki değişikliğidir ve aynı altı alanı taşımalıdır. Rol kullanmak kaydı gereksiz kılmaz, kaydı sadeleştirir.

Yetki değişikliği geri alınabilir mi?

Teknik olarak evet: GRANT ifadesinin karşılığı REVOKE, rol üyeliğinin karşılığı üyelikten çıkarmadır. Dikkat edilecek nokta, geri almanın da bir yetki değişikliği olmasıdır. Kayıtsız yapılan bir geri alma, kayıtsız yapılan bir verme kadar sorunludur; birinin erişimi sessizce kesildiğinde bu da açıklanabilir olmalıdır.

Nereden başlamalıyız?

Yeni yetki değişikliklerini kayda almakla. Geçmişi geriye dönük çıkarmaya çalışmak çoğu kurumda mümkün değildir ve başlamayı geciktirir. Bugünden itibaren her GRANT ve REVOKE bir talep ve onay taşısın; bir çeyrek sonra elinizde denetime gösterilebilir bir kayıt olur. Mevcut yetkilerin gözden geçirilmesi ayrı ve daha uzun bir iştir.