Veritabanı Yetki Matrisi Nasıl Hazırlanır? Örnek Tablo ve KVKK

Denetçi ya da KVKK danışmanı "yetki matrisinizi görebilir miyiz?" dediğinde çoğu kurum bir Excel dosyası açar. Dosyada roller ve uygulama ekranları vardır, ama veritabanı genellikle tek satırdır: "DBA: tam yetki". Bu yazı, veritabanı katmanı için kullanılabilir bir yetki matrisinin nasıl kurulacağını, örnek bir tabloyu ve matrisin belge olarak kalmaması için neyin gerektiğini anlatır.

Yetki Matrisi Nedir?

Yetki matrisi, hangi rolün hangi kaynak üzerinde hangi işlemi yapabileceğini tek tabloda gösteren belgedir. Satırlarda roller, sütunlarda kaynaklar ve işlemler durur; kesişim hücresi "izin var", "izin yok" ya da "onayla" der. Amaç iki soruyu birlikte cevaplamaktır: kim neye erişebilir ve bu erişim neden gerekli?

Kişisel veri işleyen her kurum için bu belge bir gerekliliğe dönüşür. Kişisel Verileri Koruma Kurulunun Kişisel Veri Güvenliği Rehberi, erişim yetkilerinin tanımlanmasını ve düzenli olarak kontrol edilmesini teknik tedbirler arasında sayar. Kanun "yetki matrisi" kelimesini kullanmaz; ama yetkilerin tanımlı ve kontrol edilir olduğunu göstermenin en yaygın yolu budur.

Veritabanı İçin Matrisin Eksenleri

Uygulama ekranları için yazılmış bir matris veritabanında işe yaramaz, çünkü veritabanında yetki dört katmanda verilir. Matrisin sütunları bu katmanları ayrı göstermelidir:

• Ortam: üretim, test, geliştirme. Aynı rol üretimde okur, testte yazar olabilir.
• Kapsam: sunucu, veritabanı, şema, tablo ya da kolon. Kişisel veri içeren kolonlar ayrı satır ister.
• İşlem: okuma (SELECT), veri değiştirme (INSERT, UPDATE, DELETE), yapı değiştirme (CREATE, ALTER, DROP), yetki verme (GRANT).
• Erişim biçimi: kalıcı yetki, talep ve onayla geçici erişim, yalnız maskelenmiş görüntü.

Satırlarda kişi değil rol durur. Tipik roller: uygulama servis hesabı, DBA, geliştirici, raporlama ve analiz, uygulama destek ekibi, dış tedarikçi ve acil durum hesabı. Paylaşılan hesaplar ayrı satırda yazılmalı ve kimlerin kullandığı belirtilmelidir; aksi halde matris "bu işlemi kim yaptı?" sorusunda işe yaramaz.

Örnek Yetki Matrisi

Aşağıdaki tablo üretim ortamı için bir başlangıç örneğidir. Kendi rollerinize ve şemalarınıza göre uyarlayın; asıl değer hücrelerin tek tek tartışılıp karara bağlanmasındadır.

Tablodaki "talep ve onayla" ve "onaylı değişiklikle" hücreleri matrisin en önemli kısmıdır. Bunlar kalıcı bir yetki değil, her seferinde gerekçe ve onay isteyen bir erişim biçimidir. Bu hücreleri "var" diye yazmak, matrisi okuyan herkese yanlış bir resim verir.

Yedi Adımda Hazırlama

1. Envanter: Üretim sunucularını, veritabanlarını ve kişisel veri içeren tabloları listeleyin.
2. Roller: Kişileri değil görevleri yazın. Her rolün sahibini (onaylayacak yöneticiyi) belirleyin.
3. Hassas kolonlar: T.C. kimlik numarası, telefon, e-posta, adres, kart ve hesap bilgisi gibi kolonları ayrı işaretleyin.
4. Hücre kararları: Her rol ve kaynak için "var", "yok", "talep ve onayla" ya da "yalnız maskelenmiş" kararı verin; gerekçeyi yanına yazın.
5. Gerçek durumu çekin: Veritabanındaki mevcut yetkileri sistemden alın ve matrisle karşılaştırın (aşağıdaki bölüm).
6. Farkları kapatın: Fazla yetkileri kaldırın, eksik olanları talep yoluyla verin ve her kararı kayda geçirin.
7. Takvim: Matrisi ve gerçek yetkileri belirli aralıklarla yeniden karşılaştırın; yalnız değişeni gözden geçirin.

Matris ile Gerçek Yetki Arasındaki Fark

En sık görülen sorun şudur: matris güzel hazırlanır, ama veritabanındaki gerçek yetkiler ondan bağımsız yaşar. Bir proje için verilen db_owner kaldırılmaz, ayrılan çalışanın hesabı silinmez, rol üyeliği iç içe gruplarla genişler. Denetçi matrisi değil, sistemden alınan listeyi ister.

Bu yüzden matris iki parçadan oluşmalıdır: olması gereken (karar) ve olan (sistemden alınan liste). SQL Server, PostgreSQL ve Oracle için eksiksiz yetki listesini çeken sorgular ve iki gözden geçirme arasındaki farkla çalışma yöntemi veritabanı yetki gözden geçirmesi yazısında adım adım var.

Matrisin Cevaplamadığı Soru

Mükemmel bir matris bile yalnız "kim neye erişebilir" sorusunu cevaplar. Denetimde ve bir olaydan sonra sorulan ise başka bir sorudur: yetkisi olan kişi bu erişimi ne zaman, hangi gerekçeyle ve kimin onayıyla kullandı? Kalıcı yetkisi olan bir DBA'nın her işlemi matrise uygundur; ama hangisinin bir talebe dayandığını matris söylemez. Bu fark yetkisi vardı, gerekçesi yoktu yazısında ayrıntılı anlatılıyor.

SQL Change Guard matristeki "talep ve onayla" ve "onaylı değişiklikle" hücrelerini uygulanabilir hale getirmek için tasarlandı: üretime giden değişiklik ve üretimden veri talebi gerekçeyle açılır, rol ve risk düzeyine göre onaya gider, hassas kolonlar maskelenir ve her talep için bir denetim dosyası üretilir. Ürün veritabanındaki kalıcı yetki listesini çıkarmaz; o liste yine veritabanının kendisinden alınır.

Sık Sorulan Sorular

Yetki matrisi Excel'de tutulabilir mi?

Karar kısmı için evet; önemli olan sürüm geçmişinin ve onaylayanın belli olmasıdır. Gerçek yetkiler ise Excel'e elle yazılmamalı, her gözden geçirmede sistemden yeniden alınmalıdır.

Yetki matrisi ne sıklıkla gözden geçirilmeli?

Kurumların çoğu üretim ortamı için üç ya da altı ayda bir gözden geçirme yapar; ayrılan çalışan ve rol değişikliği ise beklemeden işlenir. Doğru sıklığı kurumunuzun risk değerlendirmesi ve tabi olduğu düzenleme belirler.

KVKK yetki matrisi zorunlu mu?

Kanun "yetki matrisi" kelimesini kullanmaz; veri sorumlusundan uygun güvenlik düzeyini sağlamak için gerekli tedbirleri almasını ister. Kurulun rehberi erişim yetkilerinin tanımlanmasını ve kontrolünü bu tedbirler arasında sayar ve matris bunu göstermenin en yaygın yoludur.

DBA'ya üretimde tam yetki vermek yanlış mı?

Çoğu kurumda kaçınılmazdır, çünkü bakım ve acil müdahale bunu gerektirir. Sorun yetkinin kendisi değil, kullanımının bir talebe ve onaya bağlanmamasıdır. Matriste bu, kalıcı yetkinin yanında "onaylı değişiklikle" kuralı olarak yazılır.