Veritabanı Yetki Gözden Geçirmesi: Excel Döngüsünden Çıkmak

Üç ayda bir aynı döngü yaşanır: veritabanı ekibi kullanıcı listesini Excel'e aktarır, yöneticilere gönderir, yöneticiler her satıra "uygundur" yazıp geri yollar. Denetçi örnek seçer, bir satırda iki yıl önce ayrılmış bir çalışanın hesabını görür ve döngünün tamamı bir bulguya dönüşür. Sorun yöneticilerin özensizliği değildir; liste anlaşılmaz, eksik ve her seferinde baştan sorulan bir listedir. Bu yazı veritabanı yetki gözden geçirmesinin eksiksiz listeyle nasıl başladığını, her seferinde yalnız farka nasıl bakıldığını ve kararın nasıl kanıta dönüştüğünü sorgularla anlatır.

Excel Döngüsü Neden İşe Yaramaz

Üç sebebi vardır. Liste eksiktir: genellikle yalnız oturum açma hesaplarını içerir; veritabanı rol üyelikleri, nesneye doğrudan verilmiş izinler ve sunucu rolleri (örneğin sysadmin) ayrı yerlerde durur. Liste okunmaz: 800 satırlık bir tabloyu gözden geçiren yönetici, hangi satırın riskli olduğunu bilemez ve hepsini onaylar. Döngü kapanmaz: "kaldırılsın" denen yetkinin gerçekten kaldırıldığını gösteren bir sonraki adım yoktur.

Denetçi Neye Bakar

1. Listenin tamlığı: liste sistemden mi çekildi, hangi sorguyla, bütün yetki türlerini kapsıyor mu?
2. Gözden geçirenin uygunluğu: yetkiyi veren kişi kendi verdiği yetkiyi onaylamıyor mu, gözden geçiren işi biliyor mu?
3. Kararın kaydı: her satır için kim, ne zaman, hangi kararı verdi?
4. Uygulama: kaldırılması kararlaştırılan yetki kaldırıldı mı ve bu bir sonraki listede görünüyor mu?

Eksiksiz Liste: SQL Server, PostgreSQL, Oracle

SQL Server. Dört parça birlikte alınır: sunucu rolleri, her veritabanında rol üyelikleri, nesneye ya da şemaya doğrudan verilen izinler ve oturum açma hesabı silinmiş ama veritabanında kalmış kullanıcılar. Veritabanı sorguları her veritabanında ayrı çalıştırılır.

-- 1) Server role members (sysadmin, securityadmin, ...)
SELECT r.name AS ServerRole, m.name AS Member, m.type_desc, m.is_disabled
FROM sys.server_role_members AS rm
JOIN sys.server_principals AS r ON r.principal_id = rm.role_principal_id
JOIN sys.server_principals AS m ON m.principal_id = rm.member_principal_id
ORDER BY r.name, m.name;

-- 2) Database role members (run in each database)
SELECT DB_NAME() AS DatabaseName, r.name AS DbRole, m.name AS Member, m.type_desc
FROM sys.database_role_members AS rm
JOIN sys.database_principals AS r ON r.principal_id = rm.role_principal_id
JOIN sys.database_principals AS m ON m.principal_id = rm.member_principal_id
ORDER BY r.name, m.name;

-- 3) Permissions granted directly (including those granted to public)
SELECT DB_NAME() AS DatabaseName, pr.name AS Principal, pe.state_desc, pe.permission_name,
       CASE pe.class WHEN 0 THEN N'DATABASE'
                     WHEN 1 THEN OBJECT_SCHEMA_NAME(pe.major_id) + N'.' + OBJECT_NAME(pe.major_id)
                     WHEN 3 THEN N'SCHEMA::' + SCHEMA_NAME(pe.major_id)
                     ELSE pe.class_desc END AS Securable
FROM sys.database_permissions AS pe
JOIN sys.database_principals AS pr ON pr.principal_id = pe.grantee_principal_id
ORDER BY pr.name;

-- 4) Orphaned users: the login is gone, the user is still here
SELECT dp.name, dp.type_desc
FROM sys.database_principals AS dp
LEFT JOIN sys.server_principals AS sp ON sp.sid = dp.sid
WHERE sp.sid IS NULL AND dp.authentication_type IN (1, 3) AND dp.principal_id > 4;

PostgreSQL. Roller ve üyelikleri pg_roles ve pg_auth_members katalogundan, tablo izinleri information_schema.role_table_grants görünümünden alınır. PUBLIC satırlarını filtrelemeyin; herkese verilen izin en geniş izindir.

SELECT r.rolname, r.rolsuper, r.rolcanlogin,
       ARRAY(SELECT b.rolname FROM pg_auth_members AS m
             JOIN pg_roles AS b ON b.oid = m.roleid
             WHERE m.member = r.oid) AS member_of
FROM pg_roles AS r
WHERE r.rolname NOT LIKE 'pg\_%'
ORDER BY r.rolname;

SELECT grantee, table_schema, table_name, privilege_type
FROM information_schema.role_table_grants
WHERE table_schema NOT IN ('pg_catalog', 'information_schema')
ORDER BY grantee, table_schema, table_name;

Oracle. Rol, sistem ve nesne izinleri üç ayrı görünümdedir. Oracle'ın kendi bakımını yaptığı hesaplar (12c ve sonrası) oracle_maintained kolonuyla dışarıda bırakılır.

SELECT grantee, granted_role, admin_option FROM dba_role_privs
WHERE grantee NOT IN (SELECT username FROM dba_users WHERE oracle_maintained = 'Y');

SELECT grantee, privilege, admin_option FROM dba_sys_privs
WHERE grantee NOT IN (SELECT username FROM dba_users WHERE oracle_maintained = 'Y');

SELECT grantee, owner, table_name, privilege FROM dba_tab_privs
WHERE grantee NOT IN (SELECT username FROM dba_users WHERE oracle_maintained = 'Y');

Her Seferinde Baştan Değil, Farkla

Her gözden geçirmenin listesini tarihiyle bir tabloya kaydedin; en kolayı yukarıdaki üçüncü sorguya INTO dbo.AccessReview_2026Q3 eklemektir. Bir sonraki turda gözden geçirene 800 satır değil, iki liste arasındaki fark gönderilir: yeni eklenen yetkiler ve kaybolan yetkiler. Fark ile birlikte en yüksek yetkiler (sysadmin, db_owner, CONTROL, Oracle'da DBA rolü) her turda baştan gösterilir, çünkü riskleri değişmese de sahiplerinin hâlâ doğru kişiler olduğu teyit edilmelidir.

-- Added since the last review
SELECT Principal, Securable, permission_name FROM dbo.AccessReview_2026Q3
EXCEPT
SELECT Principal, Securable, permission_name FROM dbo.AccessReview_2026Q2;

-- Gone since the last review (removals to be confirmed)
SELECT Principal, Securable, permission_name FROM dbo.AccessReview_2026Q2
EXCEPT
SELECT Principal, Securable, permission_name FROM dbo.AccessReview_2026Q3;

Kararın Kaydı ve Döngünün Kapanması

Her satır için dört alan kaydedilir: gözden geçiren, tarih, karar (kalsın ya da kaldırılsın) ve kaldırılacaksa gerekçe. "Kaldırılsın" kararı bir değişiklik talebine dönüşür ve uygulanır. Döngü, bir sonraki listenin "kaybolan yetkiler" bölümünde o satırın görünmesiyle kapanır. Kaldırılması kararlaştırıldığı halde bir sonraki listede hâlâ duran yetki, bir sonraki denetimin ilk bulgusudur.

Ürünün Katkısı ve Sınırı

Önce sınır: SQL Change Guard hedef veritabanlarının güncel yetki listesini çıkarmaz ve iki liste arasındaki farkı hesaplamaz; bu iş yukarıdaki sorgularla yapılır. Ürünün katkısı üç yerdedir:

• Farkın kaynağı. Ürün üzerinden açılan taleplerdeki GRANT, REVOKE, DENY ve hesap ya da rol yönetimi ifadeleri "Privileged Account Operations" raporunda hedef hesap, yetki, talebin durumu, isteyen, çalıştıran ve çalıştırma zamanıyla listelenir. Fark listesindeki yeni bir yetki bu raporda çalıştırılmış (Executed) bir talebe bağlanıyorsa gözden geçiren ne zaman ve kimin istediğiyle verildiğini görür; onayın ayrıntısı talebin denetim dosyasındadır. Bağlanmıyorsa yetki ürün dışından verilmiştir ve ayrıca sorulmalıdır.
• Kaldırma talebinin kaydı. "Kaldırılsın" kararı ürün üzerinden bir değişiklik talebi olarak çalıştırılırsa, talep, onay ve çalıştırılan REVOKE metni denetim dosyasında durur.
• Ürünün kendi erişimi. Ürün de gözden geçirmenin kapsamındadır. "User Permission Matrix" raporu her ürün hesabını rolü, durumu, kimlik doğrulama türü, son kurum girişi ve izin setiyle tek tabloda verir; "User Access Changes" raporu hesapları kimin açtığını, yetkilerini kimin değiştirdiğini gösterir. "Expected Access Principals" raporu ürünün her hedef sunucuda kullandığı SQL hesabını listeler; bu hesabın hedefteki yetkileri de gözden geçirilecek listenin içindedir.

Sık Sorulan Sorular

Gözden geçirme ne sıklıkla yapılmalı?

Sıklığı kurumun politikası ve tabi olduğu düzenleme belirler. Yaygın uygulama, ayrıcalıklı hesapları üç ayda bir, diğerlerini altı ayda bir gözden geçirmektir. Hangisini seçerseniz seçin, denetçi seçtiğiniz sıklığa uyup uymadığınızı test eder.

Gözden geçirmeyi kim yapmalı?

Verinin iş tarafındaki sahibi ile teknik ekip birlikte. Yetkiyi veren veritabanı yöneticisi, kendi verdiği yetkinin tek gözden geçireni olmamalıdır; aksi halde kontrol kendini onaylar.

Uygulama ve servis hesapları da listeye girer mi?

Evet ve çoğu zaman en geniş yetkiler onlardadır. Her servis hesabının bir sahibi atanmalı ve gözden geçirmeyi o kişi yapmalıdır. Sahibi bulunamayan bir servis hesabı, ilk sorulması gereken satırdır.

Kurum dizini (Active Directory) grupları nasıl ele alınır?

Veritabanında bir Windows grubuna yetki verilmişse, veritabanı listesi yalnız grubu gösterir; grubun üyeleri dizindedir. Gözden geçirme iki adımlıdır: grubun yetkisi veritabanı listesinde, grubun üyeleri dizinin kendi gözden geçirmesinde onaylanır. İkisi birbirine referans vermelidir.