Veritabanı Yetkilendirme: RBAC, Least Privilege ve Ayrıcalıklı Hesaplar

Veritabanı güvenliğinde en kritik sorulardan biri şudur:

“Kim hangi veriye erişebilir?”

Ancak tek başına bu soru da yeterli değildir.

Aynı zamanda şunların da bilinmesi gerekir:

Bu kullanıcı neden erişebiliyor?

Hangi yetkiye sahip?

Bu yetki ne zamandan beri açık?

Gerçekten hâlâ gerekli mi?

Bu erişim kayıt altına alınıyor mu?

Kurumsal database sistemlerinde yetkilendirme yalnızca kullanıcı oluşturmak ve parola vermek anlamına gelmez.

Doğru tasarlanmış bir erişim modeli;

Identity, Authentication, Authorization, RBAC, Least Privilege, Segregation of Duties, PAM, JIT Access, Access Review ve Audit

gibi birçok güvenlik katmanını birlikte ele alır.

Çünkü birçok veri ihlalinde saldırganın özel bir exploit geliştirmesine bile gerek kalmaz.

Ele geçirilmiş veya gereğinden fazla yetkili bir kullanıcı hesabı, kritik verilere doğrudan erişmek için yeterli olabilir.

Bu nedenle veritabanı güvenliğinde temel prensip şudur:

Her kullanıcı yalnızca ihtiyaç duyduğu veriye, yalnızca ihtiyaç duyduğu süre boyunca ve yalnızca ihtiyaç duyduğu yetkiyle erişebilmelidir.

Database Authorization Nedir?

Database Authorization, kimliği doğrulanmış kullanıcının hangi işlemleri yapabileceğini belirleyen yetkilendirme mekanizmasıdır.

Örneğin bir kullanıcı;

SELECT

yetkisine sahip olabilir.

Başka bir kullanıcı;

INSERT

ve

UPDATE

yapabilir.

Bir DBA ise;

CREATE,

ALTER,

DROP,

GRANT

gibi daha yüksek yetkilere sahip olabilir.

Yetkilendirme, kullanıcının kim olduğunu değil, ne yapabileceğini belirler.

Authentication ile Authorization Arasındaki Fark Nedir?

Authentication:

“Sen kimsin?”

sorusuna cevap verir.

Authorization ise:

“Ne yapabilirsin?”

sorusunu cevaplar.

Örneğin kullanıcı doğru parola ile database'e bağlanır.

Bu authentication'dır.

Sadece belirli tabloları okuyabiliyorsa bu authorization'dır.

Identity and Access Management – IAM Database İçin Neden Önemlidir?

IAM, kimliklerin ve erişim haklarının merkezi olarak yönetilmesini sağlar.

Database tarafında;

user lifecycle,

role assignment,

privilege review,

account disable,

access approval

gibi süreçleri kapsar.

Database User Nedir?

Database User, veritabanına bağlanabilen veya database içerisinde yetki verilen kimliktir.

Bu kimlik;

insan kullanıcı,

application,

service account,

integration account,

backup account

olabilir.

İnsan Kullanıcısı ile Service Account Aynı Şey mi?

Hayır.

İnsan kullanıcı belirli bir kişiyi temsil eder.

Service account ise uygulama veya servis tarafından kullanılır.

Bu ayrım audit açısından çok önemlidir.

Shared Database Account Nedir?

Birden fazla kişinin aynı database hesabını kullanmasıdır.

Örneğin:

dba

admin

reportuser

hesabının onlarca kişi tarafından ortak kullanılması shared account örneğidir.

Shared Account Neden Risklidir?

En büyük problem accountability kaybıdır.

Bir kullanıcı kritik veri sildiğinde:

“Bu işlemi kim yaptı?”

sorusuna cevap verilemeyebilir.

Aynı zamanda bir çalışan kurumdan ayrıldığında password değiştirilmek zorunda kalabilir.

Kişiye Özel DBA Hesabı Neden Kullanılmalı?

Her DBA'nın ayrı privileged account'u olması audit kabiliyetini artırır.

Örneğin:

ali.dbadmin

ayse.dbadmin

gibi hesaplar kullanılabilir.

Bu sayede işlemler kişiye bağlanabilir.

Least Privilege Nedir?

Least Privilege, kullanıcıya görevini yerine getirebilmesi için gerekli minimum yetkinin verilmesi prensibidir.

Database güvenliğinin en temel prensiplerinden biridir.

Örneğin rapor hazırlayan bir kullanıcı sadece SELECT yetkisine ihtiyaç duyuyorsa;

DELETE,

UPDATE,

DROP

yetkilerine sahip olmamalıdır.

Neden Minimum Yetki Kullanılmalı?

Çünkü hesap compromise edilirse saldırgan yalnızca o hesabın yetkileri kadar ilerleyebilir.

Bu saldırının etkisini sınırlar.

Fazla Yetki Neden Tehlikelidir?

Bir application account'a DBA yetkisi verildiğini düşünelim.

Application üzerinde SQL Injection oluşursa saldırgan database üzerinde çok geniş yetkilere sahip olabilir.

Bu nedenle uygulama hesabı yalnızca ihtiyaç duyduğu objelere erişmelidir.

Permission Creep Nedir?

Kullanıcının zaman içerisinde farklı görevler nedeniyle sürekli yeni yetkiler alması ancak eski yetkilerin kaldırılmaması durumudur.

Örneğin çalışan:

Finance → Sales → Management

rollerinde çalışmış olabilir.

Ancak önceki rollerin yetkileri hâlâ duruyorsa privilege accumulation oluşur.

Privilege Accumulation Nedir?

Zaman içerisinde gereksiz yetkilerin birikmesidir.

Bu durum insider threat ve account compromise etkisini artırır.

RBAC Nedir?

RBAC:

Role-Based Access Control

yani:

Rol Tabanlı Erişim Kontrolü

anlamına gelir.

Yetkiler doğrudan kullanıcılara değil rollere verilir.

Kullanıcı da ilgili role atanır.

RBAC Neden Daha İyidir?

100 kullanıcıya tek tek permission vermek yerine;

Finance_Read

Finance_Write

DB_Operator

DB_Admin

rolleri oluşturulabilir.

Bu hem yönetimi hem audit'i kolaylaştırır.

Role Tasarımı Nasıl Yapılmalı?

Roller iş fonksiyonlarına göre tasarlanmalıdır.

Örneğin:

HR_ReadOnly

HR_Operator

Finance_Reporting

Application_Service

Database_Admin

Security_Auditor

gibi roller kullanılabilir.

Çok Fazla Role Oluşturmak Sorun mu?

Evet.

Role explosion yönetimi zorlaştırabilir.

Çok az rol ise fazla yetki verilmesine neden olabilir.

Dengeli bir model gerekir.

Read-Only Role Nedir?

Sadece veri okuma yetkisi sağlar.

Raporlama veya analiz kullanıcıları için kullanılabilir.

Read-Only Gerçekten Risksiz mi?

Hayır.

Bir kullanıcı sadece SELECT yetkisine sahip olsa bile milyonlarca müşteri kaydını okuyabilir.

Bu nedenle read-only yetki dahi veri sınıflandırmasına göre sınırlandırılmalıdır.

Table-Level Permission Nedir?

Kullanıcının sadece belirli tablolara erişmesini sağlar.

Örneğin:

Employee_Name

tablosuna erişebilir

ama:

Salary

tablosuna erişemez.

Column-Level Permission Nedir?

Belirli kolonlara erişimi sınırlar.

Örneğin kullanıcı;

isim,

şehir

görebilir.

Ancak;

TCKN,

IBAN,

maaş

göremez.

Row-Level Security Nedir?

Kullanıcının sadece belirli satırları görmesini sağlar.

Örneğin:

İstanbul bölge yöneticisi yalnızca İstanbul müşterilerini görebilir.

Schema-Based Access Control Nedir?

Kullanıcının yalnızca belirli schema'lara erişebilmesidir.

Bu yaklaşım uygulamaların birbirinden ayrılmasına yardımcı olur.

Database Object-Level Permission Nedir?

Database içerisindeki;

table,

view,

procedure,

function,

schema

gibi objelere özel yetki verilmesidir.

EXECUTE Yetkisi Nedir?

Stored procedure veya function çalıştırma yetkisidir.

Bir kullanıcı doğrudan tabloya erişmek yerine sadece belirli procedure'leri çalıştırabilir.

Bu erişim kontrolünü güçlendirebilir.

Stored Procedure Yetkisi Güvenli midir?

Doğru tasarlanırsa faydalıdır.

Ancak procedure içerisinde aşırı yetkili veya dinamik SQL kullanımı privilege escalation riskine yol açabilir.

Database Role ile OS Role Aynı mı?

Hayır.

Database rolleri DBMS içindeki yetkileri yönetir.

OS account ise işletim sistemi seviyesinde erişimi kontrol eder.

İki katmanın da ayrı güvenliği vardır.

Privileged Account Nedir?

Normal kullanıcıdan daha geniş yetkiye sahip hesaptır.

Database tarafında;

DBA,

superuser,

sysadmin,

SYS,

SYSTEM

gibi hesaplar privileged account olabilir.

Privileged Account Neden Kritik?

Bu hesaplar;

veri okuyabilir,

kullanıcı oluşturabilir,

yetki verebilir,

audit ayarlarını değiştirebilir,

database objelerini silebilir.

Bu nedenle compromise etkisi çok yüksektir.

DBA Her Veriyi Görmeli mi?

Bu önemli bir sorudur.

Teknik olarak DBA çoğu zaman geniş erişime sahip olabilir.

Ancak iş ihtiyacı açısından her DBA'nın her hassas veriyi görmesi gerekmeyebilir.

Mümkün olan ortamlarda görev ayrılığı ve ek erişim kontrolleri uygulanmalıdır.

DBA ile Security Administrator Ayrılmalı mı?

Kritik ortamlarda evet.

Bir kişi database operasyonunu yönetirken başka kişi security policy veya audit'i yönetebilir.

Segregation of Duties Nedir?

Segregation of Duties:

Görevlerin Ayrılığı

anlamına gelir.

Tek bir kişinin tüm kritik yetkileri kontrol etmesini engeller.

Görev Ayrılığı Neden Önemlidir?

Bir DBA;

veriyi değiştirebiliyor

ve

audit logunu silebiliyorsa

kötü niyetli işlemin tespit edilmesi zorlaşır.

Four-Eyes Principle Database İçin Kullanılabilir mi?

Evet.

Kritik işlemler ikinci kişi onayı gerektirebilir.

Örneğin:

Production schema değişikliği

veya

çok yüksek yetki grant işlemi

ikinci onaya bağlanabilir.

PAM Nedir?

PAM:

Privileged Access Management

ayrıcalıklı hesapların güvenli şekilde yönetilmesini sağlar.

Database PAM Nasıl Çalışır?

DBA doğrudan database password'ünü bilmek zorunda olmayabilir.

Örnek akış:

DBA

↓

PAM

↓

Approval

↓

Temporary Session

↓

Database

şeklinde olabilir.

PAM Ne Sağlar?

PAM;

credential vault,

session recording,

password rotation,

approval workflow,

JIT access,

audit

sağlayabilir.

Credential Vault Nedir?

Privileged password'lerin güvenli biçimde saklandığı sistemdir.

DBA password'ü kullanıcıya açık şekilde gösterilmeyebilir.

Session Recording Nedir?

DBA oturumunda yapılan işlemlerin kayıt altına alınmasıdır.

Bu özellikle kritik production sistemlerinde değerlidir.

JIT Access Nedir?

JIT:

Just-In-Time Access

yetkinin sürekli açık olmaması anlamına gelir.

Kullanıcı ihtiyaç anında belirli süreli yetki alır.

JIT Database Access Örneği

DBA production database'e müdahale edecek.

Access request açar.

Yönetici onaylar.

30 dakikalık privileged erişim açılır.

Süre sonunda otomatik kapanır.

JIT Neden Güvenlidir?

Kalıcı privileged account sayısını azaltır.

Bir credential compromise edilse bile sürekli administrator yetkisi bulunmayabilir.

JEA Nedir?

JEA:

Just Enough Administration

kullanıcıya sadece gerekli yönetim fonksiyonlarının verilmesini hedefler.

JIT ve JEA Farkı

JIT:

Ne kadar süre?

JEA:

Ne kadar yetki?

sorularını cevaplar.

İkisi birlikte güçlü bir model oluşturur.

Break-Glass Database Account Nedir?

Normal identity sistemleri kullanılamadığında acil erişim için kullanılan hesaptır.

Break-Glass Account Neden Gereklidir?

Örneğin;

Active Directory erişilemiyor,

PAM down,

SSO çalışmıyor

olabilir.

Bu durumda kritik database recovery için bağımsız hesap gerekebilir.

Break-Glass Account Nasıl Korunmalı?

Bu hesap;

çok güçlü credential,

sıkı audit,

kullanım alarmı,

sınırlı erişim

ile korunmalıdır.

Break-Glass Account Günlük Kullanılmalı mı?

Hayır.

Kullanımı olağan dışı olay kabul edilmelidir.

Database Service Account Nedir?

Application veya servislerin database'e otomatik bağlanmak için kullandığı hesaptır.

Service Account DBA Yetkisine Sahip Olmalı mı?

Genellikle hayır.

Yalnızca gereken objelere erişmelidir.

Service Account Password Nerede Saklanmalı?

Source code veya düz metin config dosyasında saklanmamalıdır.

Secret manager veya vault tercih edilebilir.

Service Account Interactive Login Yapabilmeli mi?

Mümkün olduğunca hayır.

Bu hesap yalnızca servis amacıyla kullanılmalıdır.

Service Account Owner Belirlenmeli mi?

Evet.

Her service account'un;

hangi uygulamaya ait olduğu,

sorumlu ekibi,

amacı

bilinmelidir.

Orphan Service Account Nedir?

Hangi uygulama veya ekip tarafından kullanıldığı bilinmeyen hesaptır.

Bu hesaplar ciddi security risk oluşturur.

Service Account Inventory Neden Önemlidir?

Kurum hangi application'ın hangi database credential'ını kullandığını bilmelidir.

Aksi halde password rotation sırasında kritik uygulama kesilebilir.

Database Password Rotation Nasıl Yapılmalı?

Plansız rotation yerine kontrollü süreç kullanılmalıdır.

Örneğin:

New secret oluşturulur.

Application güncellenir.

Connection doğrulanır.

Old secret iptal edilir.

Automatic Secret Rotation Nedir?

Secret manager'ın credential'ı otomatik olarak değiştirmesidir.

Bu statik password riskini azaltabilir.

Database Credential Source Code'da Bulunursa Ne Olur?

Repository erişimi olan kişiler credential'ı görebilir.

Ayrıca repository compromise durumunda database erişimi tehlikeye girer.

Developer Production Database'e Erişmeli mi?

Varsayılan olarak sürekli full erişim verilmemelidir.

Gerçek ihtiyaç varsa kontrollü şekilde sağlanabilir.

Developer Erişimi Nasıl Olabilir?

Örneğin:

read-only,

temporary,

PAM controlled,

audited

erişim kullanılabilir.

Support Ekibi Database'e Erişmeli mi?

Sadece ihtiyaç duyduğu ölçüde.

Support için çoğu zaman maskelenmiş view veya belirli sorgular yeterli olabilir.

Help Desk DBA Yetkisine Sahip Olmalı mı?

Genellikle hayır.

Yetki rollerin gerçek iş ihtiyacına göre ayrılması gerekir.

Database Access Request Nedir?

Kullanıcının database erişimi istemesi için kullanılan resmi süreçtir.

Access Request Neleri İçermeli?

Örneğin:

Kullanıcı kim?

Hangi database?

Hangi tablo/schema?

Hangi yetki?

Ne kadar süre?

Business justification nedir?

Manager Approval Gerekli mi?

Kritik database'lerde erişim çoğu zaman yönetici veya data owner onayına bağlanabilir.

Data Owner Kimdir?

Belirli verinin iş açısından sahibi olan roldür.

Örneğin HR verisinin sahibi İnsan Kaynakları olabilir.

DBA Access Vermeye Tek Başına Karar Vermeli mi?

Her durumda hayır.

DBA teknik olarak erişimi uygular.

Ancak iş açısından onayı data owner verebilir.

Access Review Nedir?

Mevcut kullanıcı yetkilerinin periyodik olarak gözden geçirilmesidir.

Access Review Neden Gereklidir?

Çalışanların;

görevi değişir,

departmanı değişir,

projeden ayrılır.

Ancak database yetkileri unutulabilir.

Access Review Ne Sıklıkla Yapılmalı?

Tek bir evrensel süre yoktur.

Kritik sistemlerde daha sık olabilir.

Örneğin;

üç aylık,

altı aylık

gözden geçirme yapılabilir.

Privileged Access Review Daha Sık Olmalı mı?

Genellikle evet.

DBA ve yüksek yetkili hesaplar daha yüksek risk taşır.

User Access Recertification Nedir?

Kullanıcının sahip olduğu erişimin yeniden onaylanmasıdır.

Manager veya data owner:

“Bu kullanıcının erişimi hâlâ gerekli.”

şeklinde onay verir.

Joiner-Mover-Leaver Süreci Nedir?

Kullanıcı yaşam döngüsünü yönetir.

Joiner

Yeni çalışan.

Mover

Görevi değişen çalışan.

Leaver

Kurumdan ayrılan çalışan.

Leaver Database Access Ne Zaman Kapatılmalı?

Kurum politikası ve risk seviyesine uygun şekilde ayrılık sürecinin parçası olarak hızla kaldırılmalıdır.

Kullanıcı Sadece AD'den Silinirse Database Yetkisi de Gider mi?

Her zaman değil.

Database içerisinde local account veya ayrı credential bulunabilir.

Bu nedenle database access ayrıca kontrol edilmelidir.

Dormant Account Nedir?

Uzun süredir kullanılmayan hesaptır.

Dormant Account Neden Risklidir?

Sahibi hesabın varlığını unutmuş olabilir.

Credential ele geçirilirse saldırgan uzun süre fark edilmeden kullanabilir.

Last Login Takip Edilmeli mi?

Evet.

Uzun süredir kullanılmayan hesaplar access review kapsamında değerlendirilebilir.

Disabled Account Silinmeli mi?

Hemen silmek audit veya recovery ihtiyacını etkileyebilir.

Kurum politikası doğrultusunda disable, retention ve deletion süreci oluşturulabilir.

Database Local Account mu Central Identity mi?

Merkezi identity;

lifecycle,

MFA,

access review

konularında avantaj sağlayabilir.

Ancak bağımsız recovery ihtiyacı da dikkate alınmalıdır.

Active Directory Database Authentication İçin Kullanılabilir mi?

Evet.

Bazı platformlarda Windows/AD authentication kullanılabilir.

Bu centralized identity sağlar.

AD Compromise Database'i Etkiler mi?

Evet.

Eğer database tamamen AD kimliğine güveniyorsa Domain Admin compromise database riskine dönüşebilir.

Database Admin Domain Admin Olmalı mı?

Genellikle hayır.

Bu iki yüksek yetkili rol ayrı tutulmalıdır.

Domain Admin Database'te Otomatik Yetkili Olmalı mı?

Mümkün olduğunca böyle geniş trust ilişkileri sınırlandırılmalıdır.

Local Emergency Database Account Neden Tutulabilir?

AD veya identity provider erişilemezse recovery için kullanılabilir.

Ancak sıkı koruma gerekir.

MFA Database Yetkilendirmede Nerede Kullanılır?

Özellikle administrator erişimi öncesinde MFA uygulanabilir.

Bu doğrudan DBMS, PAM, bastion veya SSO katmanında olabilir.

Phishing-Resistant MFA Nedir?

Phishing saldırılarına karşı daha güçlü authentication yöntemleridir.

Örneğin donanım security key veya modern passkey tabanlı yöntemler kullanılabilir.

DBA İçin SMS MFA Yeterli mi?

Mümkün olan yerlerde daha güçlü phishing-resistant yöntemler tercih edilebilir.

MFA Yetkilendirme Yerine Geçer mi?

Hayır.

MFA sadece kullanıcı kimliğinin doğrulanmasını güçlendirir.

Kullanıcının ne yapabileceğini RBAC ve permission sistemi belirler.

Database Access Network Olarak da Sınırlandırılmalı mı?

Evet.

Yetkili kullanıcı bile yalnızca belirli management network'ten bağlanabilir.

DBA Ev Bilgisayarından Database'e Doğrudan Bağlanmalı mı?

Kritik sistemlerde doğrudan erişim yerine;

VPN,

ZTNA,

PAW,

bastion,

PAM

gibi kontrollü mekanizmalar tercih edilebilir.

PAW Nedir?

Privileged Access Workstation, yüksek yetkili yönetim işlemleri için ayrılmış güvenli cihazdır.

DBA PAW Üzerinden Ne Yapmamalı?

E-posta,

internet browsing,

kişisel uygulamalar

gibi riskli işlemler yapılmamalıdır.

Bastion Host Database Erişiminde Nasıl Kullanılır?

DBA önce güvenli bastion'a bağlanır.

Database sadece bastion IP'sinden gelen yönetim bağlantılarına izin verir.

Database Privileged Session Monitoring Nedir?

Yüksek yetkili kullanıcıların yaptığı işlemlerin izlenmesidir.

Privileged Session Monitoring Neleri Kaydedebilir?

Login zamanı,

source IP,

session duration,

executed query,

changed object

gibi bilgiler kaydedilebilir.

DBA'nın SELECT Sorguları da İzlenmeli mi?

Hassas data bulunan ortamlarda evet.

DBA'nın teknik yetkisi olması her veriyi iş amacı dışında okumasını meşru hale getirmez.

Sensitive Table Access İzlenmeli mi?

Evet.

Örneğin;

Customer_PII,

Salary,

Payment_Data

tablolarına erişim yüksek riskli event olarak sınıflandırılabilir.

Bulk SELECT Nedir?

Kısa sürede çok büyük miktarda kayıt okunmasıdır.

Bu normal raporlama olabilir veya data exfiltration göstergesi olabilir.

Database Export Yetkisi Sınırlandırılmalı mı?

Evet.

Export, dump veya bulk extract yetkileri yüksek risklidir.

Database Backup'a Erişim Kimlerde Olmalı?

Backup verisi production database'in tam kopyasını içerebilir.

Bu nedenle backup repository erişimi database erişiminden bile daha hassas olabilir.

Backup Administrator Database Verisini Okuyabilir mi?

Mimariye bağlıdır.

Ancak backup rolü gereksiz şekilde application verisini okuyabilmemelidir.

Database Restore Yetkisi Riskli mi?

Evet.

Kullanıcı hassas database'i farklı bir sunucuya restore ederek veriyi dışarı çıkarabilir.

Bu nedenle restore işlemleri audit edilmelidir.

Alternate Location Restore Neden Hassastır?

Production database güvenli olabilir.

Ancak aynı backup test sunucusuna restore edilirse veri kontrolsüz hale gelebilir.

Database Audit Loglarında Hangi Yetki Değişiklikleri İzlenmeli?

Örneğin:

GRANT

REVOKE

Role Assignment

Admin Creation

User Creation

Permission Change

loglanabilir.

Privilege Escalation Nedir?

Kullanıcının sahip olduğundan daha yüksek yetkiye ulaşmasıdır.

Database Privilege Escalation Nasıl Önlenir?

Savunma açısından;

minimum permission,

secure role design,

patching,

stored procedure review,

audit

uygulanmalıdır.

GRANT OPTION Neden Hassastır?

Bir kullanıcının kendi yetkisini başkasına devretmesini sağlayabilir.

Bu nedenle kontrol edilmelidir.

Role Inheritance Nedir?

Bir role verilen yetkilerin alt rollere veya kullanıcıya otomatik geçmesidir.

Karmaşık role hiyerarşilerinde beklenmeyen yetkiler oluşabilir.

Effective Permission Nedir?

Kullanıcının farklı role ve grant'lerden gelen tüm gerçek yetkilerinin toplamıdır.

Neden Effective Permission Analizi Yapılmalı?

Kullanıcı doğrudan DBA görünmeyebilir.

Ancak birkaç farklı role üzerinden dolaylı olarak yüksek yetkiye sahip olabilir.

Toxic Permission Combination Nedir?

Tek tek normal görünen yetkilerin birlikte kullanıldığında yüksek risk oluşturmasıdır.

Örneğin;

user create

role grant

yetkileri privilege escalation potansiyeli yaratabilir.

Permission Analytics Nedir?

Kullanıcıların gerçek erişim haklarının analiz edilmesidir.

Özellikle büyük yapılarda entitlement management çözümleri kullanılabilir.

Database Identity Governance Nedir?

Database kullanıcılarının ve yetkilerinin yaşam döngüsü boyunca politikaya uygun yönetilmesini ifade eder.

Identity Governance Neleri Kapsar?

Access request,

approval,

provisioning,

access review,

recertification,

deprovisioning

süreçlerini kapsar.

Access Provisioning Nedir?

Onaylanan erişimin kullanıcıya verilmesidir.

Deprovisioning Nedir?

Erişim ihtiyacı sona erdiğinde yetkinin kaldırılmasıdır.

Manual Provisioning Riskli mi?

Çok sayıda database olduğunda insan hatası oluşabilir.

Otomasyon ve merkezi identity governance değerlendirilebilir.

Temporary Access Neden Tercih Edilmeli?

Projeye özel erişimlerin süresiz kalmasını engeller.

Access Expiration Nedir?

Belirlenen tarihte erişimin otomatik sona ermesidir.

Database Emergency Access Nasıl Audit Edilmeli?

Emergency access kullanıldığında;

alarm,

ticket,

session recording,

post-review

yapılabilir.

Post-Access Review Nedir?

Kritik privileged session sonrasında yapılan işlemlerin tekrar gözden geçirilmesidir.

Database Access Logları SIEM'e Gönderilmeli mi?

Kritik sistemlerde evet.

SIEM Hangi Database Access Olaylarını İzleyebilir?

Örneğin:

Multiple Failed DBA Login

New Privileged User Created

Unexpected Role Grant

DBA Login Outside Working Hours

Bulk Sensitive Data Access

Dormant Account Login

Break-Glass Account Used

Impossible Travel Database İçin Kullanılabilir mi?

Merkezi identity ile destekleniyorsa aynı privileged kullanıcının kısa sürede çok farklı lokasyonlardan bağlanması anomali olarak değerlendirilebilir.

UEBA Database Access İçin Kullanılabilir mi?

Evet.

User and Entity Behavior Analytics normal kullanıcı davranışından sapmaları analiz edebilir.

Database Anomaly Detection Neleri Görebilir?

Örneğin bir DBA normalde günde 20 query çalıştırırken gece 03:00'te milyonlarca kayıt export ediyorsa anomali üretilebilir.

Database Access ile DAM İlişkisi

DAM, database üzerindeki gerçek aktiviteleri izleyerek yetkilendirme sistemini tamamlar.

RBAC Varsa DAM Gerekli mi?

Kritik yapılarda ikisi farklı amaçlara hizmet eder.

RBAC:

Ne yapabilirsin?

DAM:

Gerçekte ne yaptın?

sorusuna cevap verir.

Database Access ve DLP Birlikte Kullanılabilir mi?

Evet.

Database'ten çıkan hassas verinin daha sonra e-posta, endpoint veya cloud üzerinden sızması DLP ile izlenebilir.

Zero Trust Database Access Nedir?

Hiçbir kullanıcı veya network'ün varsayılan olarak güvenilir kabul edilmemesi yaklaşımıdır.

Zero Trust Database İçin Nasıl Uygulanabilir?

Örneğin:

Identity Verification

↓

MFA

↓

Device Trust

↓

PAM Approval

↓

JIT Access

↓

Database RBAC

↓

Continuous Monitoring

şeklinde uygulanabilir.

Network İçindeyim, O Halde Güvenilirim Yaklaşımı Doğru mu?

Hayır.

Internal network'teki cihaz da compromise olabilir.

Database Access Policy Nedir?

Database erişiminin hangi kurallara göre verileceğini tanımlar.

Database Access Policy Neleri İçermeli?

Örneğin;

access request,

approval,

role model,

privileged access,

MFA,

review frequency,

termination process,

emergency access

tanımlanabilir.

Production Database Erişim Politikası Daha Sıkı Olmalı mı?

Evet.

Development ve production aynı risk seviyesine sahip değildir.

Non-Production Database Güvenliği Önemsiz mi?

Hayır.

Gerçek veri bulunabilir veya production credential'larına ulaşmak için kullanılabilir.

Production Data Test Ortamında Nasıl Korunmalı?

Masking,

tokenization,

anonymization

uygulanabilir.

Data Masking Yetkilendirmeyi Tamamlar mı?

Evet.

Kullanıcının erişmesi gereken tablo olabilir ancak hassas kolonları gerçek değerleriyle görmesi gerekmeyebilir.

Database Access ve KVKK

Kişisel veriye erişim yalnızca görev gereği yetkili kişilerle sınırlandırılmalıdır.

Bu nedenle access control database güvenliğinin ve veri koruma süreçlerinin önemli parçasıdır.

KVKK Açısından Loglama Neden Önemlidir?

Kişisel veriye kimlerin eriştiğinin araştırılabilmesini destekler.

ISO/IEC 27001 Açısından Database Yetkilendirme

ISO/IEC 27001 yaklaşımında identity management, authentication, access rights ve privileged access risk bazlı olarak yönetilmelidir.

Database RBAC, access review ve PAM süreçleri bu yaklaşımı destekler.

PCI DSS Açısından Database Access

Kart verisi ortamında need-to-know ve least privilege prensipleri kritik önem taşır.

Privileged erişimler ayrıca izlenmelidir.

Access Control Matrix Nedir?

Hangi rolün hangi database veya tablo üzerinde hangi yetkiye sahip olduğunu gösteren matristir.

Örnek:

Rol	Customer DB	Finance DB	HR DB	Yetki
Sales	Evet	Hayır	Hayır	Read
Finance	Sınırlı	Evet	Hayır	Read/Write
HR	Hayır	Hayır	Evet	Read/Write
DBA	Teknik	Teknik	Teknik	Admin

Gerçek kurumlarda matris çok daha detaylı olabilir.

Database Access Review Checklist

Periyodik gözden geçirmede şu sorular sorulabilir:

Kullanıcı hâlâ kurumda mı?

Görevi değişti mi?

Bu database'e hâlâ ihtiyacı var mı?

Role doğru mu?

Privileged erişim gerekli mi?

Son login ne zaman?

Shared account var mı?

Dormant account var mı?

Service account owner belli mi?

MFA aktif mi?

Privileged Database Access Checklist

• Kişiye özel DBA hesabı
• MFA
• PAM
• JIT access
• Session recording
• Access approval
• Network restriction
• PAW/Bastion
• Audit logging
• SIEM monitoring
• Periodic recertification
• Break-glass kontrolü

Service Account Güvenlik Checklist

• Her uygulama için ayrı account
• Minimum permission
• Interactive login disabled
• Secret vault
• Password rotation
• Owner defined
• Usage monitored
• Unused account removed
• Network source restricted
• Audit enabled

Database Access Maturity Nasıl Ölçülür?

Örnek seviyeler:

Seviye 1 – Kontrolsüz

Shared account ve geniş yetkiler kullanılır.

Seviye 2 – Temel

Kişisel account'lar ve bazı role'ler bulunur.

Seviye 3 – Standart

RBAC, approval ve access review uygulanır.

Seviye 4 – Kontrollü

PAM, MFA, JIT ve merkezi audit kullanılır.

Seviye 5 – Dinamik

Risk bazlı, otomatik ve sürekli doğrulanan Zero Trust access modeli uygulanır.

Database Yetkilendirmede KPI'lar

Örneğin:

Privileged Account Count

Shared Account Count

Dormant Account Count

MFA Coverage

PAM Coverage

Access Review Completion

Expired Access Count

Orphan Service Account Count

MFA Coverage Nedir?

Privileged database hesaplarının ne kadarında MFA uygulandığını gösterir.

PAM Coverage Nedir?

Privileged account'ların ne kadarının PAM üzerinden yönetildiğini gösterir.

Access Review Completion Rate Nedir?

Planlanan access review'ların zamanında tamamlanma oranıdır.

Shared Account Hedefi Ne Olmalı?

Kritik ortamlarda mümkün olduğunca sıfıra yaklaştırılmalıdır.

Database Yetkilendirmede En Sık Yapılan Hatalar

Kurumlarda sık görülen hatalar şunlardır:

• Ortak DBA hesabı kullanmak
• Application user'a DBA vermek
• Developer'a sürekli production erişimi vermek
• Her kullanıcıya geniş SELECT yetkisi vermek
• Eski çalışan hesaplarını açık bırakmak
• Role yerine kullanıcıya tek tek izin vermek
• Service account owner belirlememek
• Database password'lerini source code'da tutmak
• MFA kullanmamak
• PAM kullanmamak
• Yetkileri süresiz bırakmak
• Access review yapmamak
• Break-glass account'u günlük kullanmak
• DBA aktivitelerini audit etmemek
• Backup ve restore yetkilerini kontrol etmemek

Yönetimin Sorması Gereken Database Access Soruları

Üst yönetim ve BT yöneticileri şu sorulara cevap alabilmelidir:

Kaç DBA hesabımız var?

Kaçı kişiye özel?

Shared account var mı?

Application account'larımızın kaçı yüksek yetkili?

Privileged hesaplarda MFA var mı?

PAM kullanılıyor mu?

Son access review ne zaman yapıldı?

Kurumdan ayrılan kişinin database erişimi ne kadar sürede kapanıyor?

DBA hassas müşteri verisini okursa bunu tespit edebilir miyiz?

Bu sorular gerçek access control maturity seviyesini ortaya çıkarır.

Sık Sorulan Sorular

Database RBAC nedir?

Kullanıcı yetkilerinin roller üzerinden yönetilmesidir.

Least Privilege nedir?

Kullanıcıya yalnızca görevini yapması için gereken minimum yetkinin verilmesidir.

DBA account paylaşılmalı mı?

Hayır. Kişiye özel privileged hesaplar audit açısından çok daha güvenlidir.

Application user DBA olabilir mi?

Çoğu durumda olmamalıdır. Uygulama sadece ihtiyaç duyduğu objelere erişmelidir.

Database için PAM gerekli mi?

Kritik ve yüksek yetkili ortamlarda PAM ciddi güvenlik avantajı sağlar.

JIT database access nedir?

Kullanıcıya sadece ihtiyaç duyduğu süre için geçici database erişimi verilmesidir.

Developer production database'e erişmeli mi?

Varsayılan olarak sürekli geniş erişim verilmemelidir. İhtiyaç halinde kontrollü, geçici ve audit edilen erişim sağlanabilir.

Service account nasıl korunmalı?

Minimum yetki, secret vault, rotation, network restriction ve monitoring kullanılmalıdır.

Access review nedir?

Kullanıcıların mevcut database yetkilerinin hâlâ gerekli olup olmadığının periyodik kontrolüdür.

Database admin aktiviteleri izlenmeli mi?

Evet. Privileged işlemler audit edilmeli ve kritik sistemlerde merkezi olarak izlenmelidir.

Sonuç: Database Güvenliğinde En Kritik Kontrol Doğru Yetkidir

Veritabanı güvenliği çoğu zaman;

firewall,

encryption,

backup,

patch

üzerinden konuşulur.

Ancak güçlü bir database sisteminin en kritik güvenlik katmanlarından biri:

erişim kontrolüdür.

Çünkü en güvenli network arkasında bulunan, tamamen şifrelenmiş ve güncel bir database bile yanlış kullanıcıya yanlış yetki verilmişse risk altındadır.

Bu nedenle kurumların şu prensipleri benimsemesi gerekir:

Her kullanıcı kişiye özel olmalıdır.

Her erişimin iş gerekçesi bulunmalıdır.

Her kullanıcı minimum yetkiye sahip olmalıdır.

Privileged hesaplar ekstra korunmalıdır.

Yetkiler sonsuza kadar açık bırakılmamalıdır.

Tüm kritik işlemler audit edilmelidir.

Modern database erişim modeli şu şekilde düşünülmelidir:

Identity

↓

Strong Authentication

↓

Approval

↓

PAM / JIT

↓

RBAC

↓

Least Privilege

↓

Continuous Monitoring

Bu yaklaşım yalnızca dış saldırganlara karşı değil;

insider threat,

credential compromise,

human error

ve

privilege abuse

risklerine karşı da güçlü koruma sağlar.

En kritik güvenlik sorusu şudur:

“Bu kullanıcı database'e erişebiliyor mu?”

değil;

“Bu kullanıcı tam olarak hangi veriye, hangi nedenle, hangi yetkiyle ve ne kadar süre erişebiliyor?”

sorusudur.

Gerçek database access security bu sorunun her kullanıcı için net biçimde cevaplanabilmesidir.