Veritabanı Güvenliği Nedir? PostgreSQL, MSSQL ve Oracle Sistemleri Nasıl Korunur?

Kurumsal sistemlerin en değerli bileşenlerinden biri çoğu zaman veritabanıdır.

Müşteri kayıtları.

Finansal bilgiler.

Kimlik verileri.

Siparişler.

Sözleşmeler.

İnsan kaynakları kayıtları.

Uygulama konfigürasyonları.

Yetki bilgileri.

Bir saldırgan uygulama sunucusunu ele geçirdiğinde asıl hedef çoğu zaman orada kalmak değildir.

Gerçek hedef veridir.

Bu nedenle Database Security – Veritabanı Güvenliği, sistem ve bulut güvenliğinin en kritik alanlarından biridir.

PostgreSQL, Microsoft SQL Server ve Oracle gibi platformlar farklı teknik özelliklere sahip olsa da temel güvenlik prensipleri benzerdir:

Minimum yetki, minimum network exposure, güçlü kimlik doğrulama, encryption, auditing, privileged access control ve güvenli backup.

Veritabanı güvenliği sadece SQL Injection saldırısını önlemek değildir.

Bir database;

uygulamadan tamamen bağımsız şekilde,

yanlış kullanıcı yetkisi,

açık network portu,

zayıf DBA hesabı,

eski sürüm,

hatalı audit ayarı,

şifrelenmemiş backup

nedeniyle risk altında olabilir.

Bu nedenle modern database security yaklaşımı;

Database Hardening + IAM/PAM + Network Security + Encryption + DAM + Monitoring + Backup Security + Vulnerability Management

katmanlarını birlikte ele almalıdır.

Veritabanı Güvenliği Nedir?

Database Security, veritabanı sistemlerinin, içindeki verilerin, kullanıcıların, yetkilerin ve yönetim arayüzlerinin yetkisiz erişim, veri sızıntısı, manipülasyon ve hizmet kesintisi risklerine karşı korunmasıdır.

Bu kapsamda;

• PostgreSQL Security,
• Microsoft SQL Server Security,
• Oracle Security,
• Database Hardening,
• Database Access Control,
• Database Activity Monitoring,
• Database Encryption,
• Database Backup Security

gibi alanlar değerlendirilir.

Asıl hedef yalnızca database'i erişilebilir tutmak değildir.

Aynı zamanda:

Kim neye erişiyor?

Hangi veriyi okuyor?

Hangi privileged işlem yapılıyor?

Bu aktivite loglanıyor mu?

sorularına cevap verebilmektir.

PostgreSQL Güvenliği Nasıl Sağlanır?

PostgreSQL açık kaynak dünyasında en yaygın kurumsal veritabanlarından biridir.

Güvenlik açısından;

pg_hba.conf,

user/role yapısı,

network binding,

SSL/TLS,

logging,

extension kullanımı

kritik alanlardır.

İlk prensip, database'in gereksiz şekilde internete açık olmamasıdır.

PostgreSQL çoğu zaman yalnızca application server veya belirli admin network'lerinden erişilebilir olmalıdır.

pg_hba.conf Nedir?

PostgreSQL'de pg_hba.conf, hangi kullanıcıların hangi kaynak IP'lerden hangi authentication yöntemiyle bağlanabileceğini belirleyen kritik yapılandırma dosyasıdır.

Yanlış veya çok geniş kurallar risk oluşturabilir.

Örneğin tüm network'e geniş authentication izni vermek yerine;

application subnet,

DBA network,

backup server

gibi kaynaklara özel erişim tanımlanabilir.

PostgreSQL Role Güvenliği Nasıl Yönetilir?

PostgreSQL'de kullanıcı ve role yapısı merkezi önem taşır.

Her uygulamanın database superuser hesabıyla çalışması ciddi hatadır.

Uygulama yalnızca ihtiyacı olan;

SELECT,

INSERT,

UPDATE,

EXECUTE

gibi permission'lara sahip olmalıdır.

Bu Least Privilege prensibidir.

PostgreSQL Superuser Neden Kritik?

PostgreSQL superuser geniş database yetkilerine sahiptir.

Bir uygulama hesabının superuser olması saldırı etkisini büyütür.

Örneğin uygulama tarafındaki vulnerability üzerinden database hesabı ele geçirilirse saldırgan tüm database üzerinde geniş kontrol elde edebilir.

Bu nedenle superuser hesaplar yalnızca DBA operasyonları için kullanılmalıdır.

MSSQL Güvenliği Nasıl Sağlanır?

Microsoft SQL Server Security, authentication, server role, database role, network, encryption ve auditing katmanlarının birlikte korunmasını gerektirir.

Kritik alanlar arasında;

sa hesabı,

sysadmin role,

Windows Authentication,

SQL Authentication,

TCP/IP erişimi,

SQL Server Audit

yer alır.

Özellikle sysadmin role üyelikleri minimum tutulmalıdır.

sa Hesabı Nedir?

sa, SQL Server'ın yüksek yetkili SQL authentication hesabıdır.

Bu hesabın;

aktif olması,

zayıf parola kullanması,

uygulamalar tarafından kullanılması

yüksek risk oluşturabilir.

Mümkün olduğunda kişisel DBA hesapları, merkezi identity ve kontrollü privileged access tercih edilmelidir.

Windows Authentication MSSQL İçin Daha Güvenli midir?

Uygun kurumsal ortamlarda Windows/AD tabanlı authentication merkezi kimlik yönetimi, MFA/PAM katmanları ve account lifecycle açısından avantaj sağlayabilir.

Ancak bu, yanlış AD yetkisinin güvenli olduğu anlamına gelmez.

Database role'leri yine minimum tutulmalıdır.

Oracle Güvenliği Nasıl Sağlanır?

Oracle Database ortamlarında;

SYS,

SYSTEM,

DBA role,

listener,

TDE,

audit,

database vault

gibi bileşenler güvenlik açısından önemlidir.

Oracle genellikle kritik finansal ve kurumsal sistemlerde kullanıldığı için privileged DBA erişimleri özellikle sıkı yönetilmelidir.

SYS ve SYSTEM Hesapları Neden Kritik?

Oracle tarafında SYS ve SYSTEM yüksek yetkili hesaplar arasında yer alır.

Bu hesapların günlük uygulama bağlantıları için kullanılması uygun değildir.

Kişisel DBA hesapları ve görev bazlı roller tercih edilmelidir.

Ayrıca bu hesapların kullanımı detaylı audit edilmelidir.

Database Hardening Nedir?

Database Hardening, veritabanının gereksiz özelliklerden, geniş yetkilerden ve riskli konfigürasyonlardan arındırılmasıdır.

Bu kapsamda;

gereksiz kullanıcıların silinmesi,

varsayılan hesapların kapatılması,

network exposure'ın azaltılması,

güvenli TLS kullanımı,

audit'in etkinleştirilmesi,

gereksiz extension veya feature'ların kapatılması

gibi işlemler yapılabilir.

Database Security Baseline Nedir?

Kuruma özel minimum güvenlik standardıdır.

Örneğin;

DB yalnızca private network'te çalışacak.

DBA erişimi PAM üzerinden olacak.

Uygulama hesapları superuser olmayacak.

TLS zorunlu olacak.

Audit logları SIEM'e gönderilecek.

Backup şifreli tutulacak.

Bu baseline tüm database platformlarında ortak prensip olarak uygulanabilir.

CIS Database Benchmark Kullanılabilir mi?

Evet.

CIS tarafından belirli database teknolojileri için hardening önerileri bulunabilir.

Ancak her kontrol production ortamına doğrudan uygulanmamalıdır.

Performans, compatibility ve iş gereksinimleri değerlendirilmelidir.

Benchmark bir başlangıç noktasıdır, nihai güvenlik modeli değildir.

Database Network Security Nasıl Sağlanır?

Database portları mümkün olduğunca doğrudan internete açık olmamalıdır.

Örneğin;

PostgreSQL 5432,

MSSQL 1433,

Oracle 1521

gibi portlar yalnızca gerekli application veya admin subnet'lerden erişilebilir olmalıdır.

Güvenli akış şu şekilde düşünülebilir:

User → Application → Database

Doğrudan:

Internet → Database

mimarisi çoğu kurumsal sistem için uygun değildir.

Database Public IP Kullanmalı mı?

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

Cloud ortamında managed database kullanılıyorsa private endpoint veya private network tercih edilebilir.

Public erişim gerekiyorsa;

source IP restriction,

strong authentication,

TLS,

monitoring

gibi ek kontroller kullanılmalıdır.

Database Firewall Nedir?

Database'e hangi kaynakların bağlanabileceğini belirleyen network veya database seviyesindeki filtreleme mekanizmasıdır.

Cloud managed database'lerde provider firewall veya security group kullanılabilir.

On-premise ortamda network firewall + host firewall katmanları değerlendirilebilir.

Database Segmentation Neden Önemlidir?

Database sunucuları user network'ten ayrıştırılmalıdır.

Örneğin normal çalışan laptop'ının production database'e doğrudan bağlantı kurmasına gerek olmayabilir.

Bu lateral movement riskini azaltır.

İdeal modelde yalnızca uygulama sunucuları ve yetkili DBA yönetim ağı erişebilir.

Database Admin Erişimi Nasıl Sağlanmalı?

DBA kullanıcıları doğrudan internet veya normal laptop üzerinden production database'e bağlanmamalıdır.

Daha kontrollü model:

DBA → MFA/PAM → Bastion → Database

şeklinde olabilir.

Bu yapı privileged access'in loglanmasını ve sınırlandırılmasını kolaylaştırır.

Database PAM Nedir?

Privileged Access Management, DBA hesaplarının parola veya session erişimini merkezi yönetebilir.

Örneğin DBA;

database parolasını görmeden,

onay aldıktan sonra,

belirli süre için

session açabilir.

Session kayıt altına alınabilir.

Bu özellikle kritik finansal sistemlerde değerlidir.

Shared DBA Account Neden Risklidir?

Birden fazla DBA aynı dba_admin hesabını kullanıyorsa hangi işlemi kimin yaptığı net olarak anlaşılamaz.

Bu accountability problemini oluşturur.

Kişisel hesap + role elevation modeli tercih edilmelidir.

Just-in-Time DBA Access Nedir?

DBA'nın sürekli privileged yetkili olması yerine yalnızca bakım anında kısa süreli yüksek yetki almasıdır.

Örneğin 1 saatlik admin role.

Süre sonunda yetki otomatik kaldırılır.

Bu standing privilege riskini azaltır.

Application Database Account Nasıl Olmalı?

Her uygulama kendi ayrı database hesabını kullanmalıdır.

Bu hesap sadece gerekli schema ve table'lara erişmelidir.

Örneğin reporting uygulamasının DELETE yetkisine ihtiyacı yoksa verilmemelidir.

Bu şekilde application compromise etkisi sınırlandırılır.

Tek Database Account'u Tüm Uygulamalarda Kullanmak Riskli mi?

Evet.

Bir uygulama compromise olduğunda aynı credential diğer uygulamaların database erişimini de tehlikeye atabilir.

Her application veya workload için ayrı identity tercih edilmelidir.

Bu aynı zamanda attribution'ı da kolaylaştırır.

Service Account Database Security'de Neden Kritik?

Database bağlantıları çoğu zaman service account veya application credential ile yapılır.

Bu credential'lar;

config file,

environment variable,

source code

içerisinde saklanabilir.

Açığa çıktıklarında saldırgan database'e doğrudan erişebilir.

Bu nedenle secret management gerekir.

Database Password Kod İçinde Tutulmalı mı?

Hayır.

Source code veya repository içerisinde düz metin database credential ciddi risktir.

Secret vault kullanılabilir.

Credential runtime sırasında uygulamaya güvenli şekilde sağlanabilir.

Database Secret Rotation Nedir?

Database kullanıcı parolalarının periyodik veya olay bazlı olarak değiştirilmesidir.

Ancak uygulamaların downtime yaşamadan yeni credential'a geçmesi gerekir.

Bu nedenle secret rotation mümkün olduğunca otomatik tasarlanmalıdır.

Passwordless Database Access Mümkün mü?

Bazı cloud ve kurumsal platformlarda IAM veya managed identity tabanlı database authentication kullanılabilir.

Örneğin workload static password tutmadan database'e erişebilir.

Bu static secret riskini azaltabilir.

Ancak IAM permission yine doğru yönetilmelidir.

Database Encryption at Rest Nedir?

Database dosyalarının disk üzerinde şifrelenmesini ifade eder.

Örneğin;

TDE,

storage encryption

kullanılabilir.

Bu özellikle disk veya backup çalınması durumunda veri koruması sağlar.

Ancak database'e yetkili login yapan saldırgan veriyi yine okuyabilir.

Bu nedenle encryption access control'un alternatifi değildir.

TDE Nedir?

Transparent Data Encryption – TDE, veritabanı dosyalarını storage üzerinde şifrelemeye yardımcı olan mekanizmadır.

Oracle ve MSSQL gibi platformlarda kullanılabilir.

Avantajı uygulama tarafında büyük değişiklik gerektirmeden encryption sağlamasıdır.

Ancak encryption key güvenliği kritik hale gelir.

Encryption in Transit Database İçin Neden Önemlidir?

Application ile database arasındaki trafik TLS olmadan gidiyorsa credential veya veri ağ üzerinde okunabilir hale gelebilir.

Bu nedenle production database bağlantılarında TLS tercih edilmelidir.

Özellikle hybrid ve cloud networklerde önemlidir.

Database Certificate Validation Neden Önemlidir?

TLS kullanmak tek başına yeterli değildir.

Client server certificate'ı doğrulamıyorsa Man-in-the-Middle riski devam edebilir.

Bu nedenle certificate chain ve hostname validation doğru yapılandırılmalıdır.

Column-Level Encryption Nedir?

Belirli hassas kolonların ayrıca şifrelenmesidir.

Örneğin;

TCKN,

kredi kartı,

sağlık bilgisi,

özel finansal veri

gibi alanlarda kullanılabilir.

Bu, tüm database encryption'dan farklı bir data protection seviyesidir.

Tokenization Nedir?

Hassas verinin doğrudan saklanması yerine gerçek değerin yerine token kullanılmasıdır.

Özellikle ödeme ve PCI DSS kapsamındaki yapılarda kullanılabilir.

Tokenization veri exposure etkisini azaltabilir.

Data Masking Nedir?

Hassas verinin belirli kullanıcı veya ortamlarda kısmen gizlenmesidir.

Örneğin:

**** **** **** 1234

gibi.

Özellikle test ve development ortamlarında production verisinin tamamının görünmesini önlemek için değerlidir.

Dynamic Data Masking Nedir?

Veri database içinde gerçek haliyle durur ancak belirli kullanıcılar sorguladığında maskelenmiş görünür.

Bu erişim kontrolünü destekler.

Ancak güçlü encryption veya permission'ın yerini tutmaz.

Test Ortamında Production Data Kullanmak Riskli mi?

Evet.

Development ve test ortamları genellikle production kadar güçlü korunmayabilir.

Gerçek müşteri verisinin doğrudan kopyalanması data exposure riskini artırır.

Data masking veya synthetic data kullanılabilir.

Database Audit Nedir?

Database Auditing, kullanıcıların ve uygulamaların database üzerinde yaptığı kritik işlemlerin kayıt altına alınmasıdır.

Örneğin;

login,

DDL,

privileged query,

table access,

user creation,

role change

izlenebilir.

Bu kayıtlar Incident Response ve compliance açısından değerlidir.

Database Activity Monitoring – DAM Nedir?

DAM, database aktivitelerini sürekli izleyen ve şüpheli davranışları tespit etmeye çalışan güvenlik yaklaşımıdır.

Örneğin;

DBA'nın gece müşteri tablosunu dump etmesi,

uygulama hesabının normalde erişmediği tabloyu okuması,

çok yüksek query hacmi

anomaliler olarak görülebilir.

DAM ile Database Audit Aynı Şey mi?

Hayır.

Database Audit daha çok yerel log ve olay kayıtlarına odaklanabilir.

DAM ise merkezi;

monitoring,

behavior analysis,

alerting,

policy enforcement

sunabilir.

İkisi birbirini tamamlayabilir.

DAM Neden Özellikle DBA Hesapları İçin Önemlidir?

DBA zaten teknik olarak veriye erişebilir.

Bu nedenle “erişim var mı?” sorusundan çok:

Erişim meşru mu?

sorusu önemlidir.

DAM yüksek yetkili kullanıcı aktivitelerini izleyerek insider threat risklerini azaltabilir.

Privileged Database Activity Nasıl İzlenmeli?

Örneğin;

schema değişikliği,

user creation,

role grant,

mass export,

audit disable

yüksek değerli olaylardır.

Bu aktiviteler SIEM/DAM üzerinde alarm üretebilir.

SQL Injection ile Database Security Aynı Şey midir?

Hayır.

SQL Injection, uygulama katmanındaki input validation ve query construction problemi olabilir.

Database Security ise çok daha geniştir.

Örneğin SQL Injection yoktur.

Ama application database hesabı DBA yetkilidir.

Bu durumda uygulamadaki başka bir RCE açığı yine tüm database'i tehlikeye atabilir.

Bu nedenle AppSec ve DB Security birlikte düşünülmelidir.

SQL Injection Etkisi Database Yetkisine Bağlı mıdır?

Evet.

Uygulama hesabı yalnızca belirli tabloyu okuyabiliyorsa SQL Injection etkisi sınırlı olabilir.

Ama aynı hesap;

DROP TABLE,

CREATE USER,

filesystem erişimi

gibi yüksek yetkilere sahipse saldırının etkisi büyür.

Bu nedenle Least Privilege, SQL Injection için de önemli compensating control'dür.

Stored Procedure Güvenliği Nasıl Yönetilir?

Stored procedure'ler uygulama mantığı ve privileged işlemler içerebilir.

Hangi kullanıcıların EXECUTE yetkisine sahip olduğu kontrol edilmelidir.

Dynamic SQL kullanımı ve input handling ayrıca değerlendirilmelidir.

Database Extension ve Plugin Güvenliği

PostgreSQL extension veya Oracle/MSSQL ek bileşenleri yeni fonksiyonlar sağlar.

Ancak kullanılmayan extension saldırı yüzeyi oluşturabilir.

Yalnızca gerekli bileşenler aktif tutulmalıdır.

xp_cmdshell Nedir ve Neden Risklidir?

SQL Server tarafında xp_cmdshell, database üzerinden işletim sistemi komutlarının çalıştırılmasına imkan veren güçlü özelliktir.

Gerekli olmadığı sürece devre dışı tutulmalıdır.

Aktifse erişimi çok sıkı kontrol edilmelidir.

Bu, database compromise'ın OS compromise'a dönüşebildiği klasik örneklerden biridir.

PostgreSQL COPY ve File Access Riskleri

Database platformları bazı durumlarda server filesystem ile etkileşim sağlayabilir.

Bu yetkiler privileged kullanıcılarla sınırlandırılmalıdır.

Uygulama hesaplarının gereksiz filesystem erişimi olmamalıdır.

Oracle UTL_FILE ve External Procedure Riskleri

Oracle gibi gelişmiş database platformlarında filesystem veya harici servislerle etkileşim sağlayan özellikler bulunabilir.

Bu özellikler yalnızca gerekli hesaplara verilmelidir.

Çünkü database'den host seviyesine geçiş riskini artırabilir.

Database OS Account Güvenliği

Database engine genellikle işletim sistemi üzerinde özel service account ile çalışır.

Bu hesabın;

root,

Local Administrator

gibi gereksiz yüksek yetkili olmaması gerekir.

Database service account minimum OS privilege ile çalışmalıdır.

Database Server Hardening Neden Gerekli?

Database engine güvenli olsa bile underlying Windows veya Linux sunucusu zayıf olabilir.

Bu nedenle;

OS patch,

EDR,

host firewall,

SSH/RDP security,

CIS hardening

uygulanmalıdır.

Database Security ve Server Security birbirinden ayrı düşünülemez.

Database Patch Management Nasıl Yapılır?

Database engine'ler de düzenli security update alır.

Patch sürecinde;

vendor advisory,

CVE severity,

exploitability,

downtime,

HA architecture

değerlendirilmelidir.

Kritik database'lerde patch öncesi test ve rollback planı gerekir.

Database Version EOL Riski Nedir?

Vendor desteği bitmiş database sürümleri artık security patch alamayabilir.

Bu durumda yeni açıklar kalıcı risk oluşturur.

Bu nedenle PostgreSQL, MSSQL ve Oracle sürüm lifecycle'ları takip edilmelidir.

Database Vulnerability Assessment Nedir?

Database'in;

version,

configuration,

account,

permission,

known vulnerability

alanlarının değerlendirilmesidir.

Credentialed scan ve configuration review ile daha doğru sonuç alınabilir.

Sadece port taraması yeterli değildir.

Database Security Assessment Nedir?

Daha geniş bir çalışmadır.

Şu alanları kapsayabilir:

Architecture

Authentication

Authorization

Network

Encryption

Audit

Backup

PAM/DAM

Patch

Hardening

Amaç yalnızca zafiyet bulmak değil, data exposure riskini anlamaktır.

Database Pentest ile Security Assessment Arasındaki Fark

Database Security Assessment

Konfigürasyon ve yetki risklerini inceler.

Penetration Test

Yetkilendirilmiş senaryolarla bu risklerin ne kadar istismar edilebilir olduğunu test eder.

Örneğin assessment:

Application user yüksek yetkili.

Pentest:

Bu yetki üzerinden kritik schema değiştirilebiliyor mu?

sorusunu doğrulayabilir.

Database Backup Neden Kritik Güvenlik Alanıdır?

Backup çoğu zaman database'in tam kopyasını içerir.

Production erişimi çok sıkı olsa bile backup file yanlış yerde tutuluyorsa veri sızabilir.

Bu nedenle backup;

encrypted,

access-controlled,

retention-managed

olmalıdır.

Database Backup Şifrelenmeli mi?

Hassas veri barındıran sistemlerde güçlü şekilde değerlendirilmelidir.

Çünkü backup file çalındığında database authentication mekanizmaları devre dışı kalmış olabilir.

Saldırgan offline olarak veriye erişmeye çalışabilir.

Backup Encryption Key Nerede Tutulmalı?

Backup ile aynı yerde tutulmamalıdır.

Key management ayrı ve kontrollü olmalıdır.

Aksi halde backup dosyası ve key birlikte ele geçirilirse encryption etkisiz kalır.

Database Backup Ransomware Riski

Ransomware saldırganları backup'ları da silebilir veya encrypt edebilir.

Bu nedenle;

immutable backup,

offline copy,

separate credentials,

network segmentation

değerlendirilebilir.

Database Restore Testi Neden Gereklidir?

Backup almak restore edilebildiği anlamına gelmez.

Periyodik restore testleriyle;

backup integrity,

RTO,

RPO,

application compatibility

doğrulanmalıdır.

Bu siber dayanıklılığın temel parçasıdır.

Database High Availability ile Backup Aynı Şey midir?

Hayır.

Replication veya cluster availability sağlar.

Ama yanlış query tüm veriyi silerse değişiklik replica'ya da yayılabilir.

Bu nedenle HA ile backup farklı problemlere çözüm sağlar.

Database Replication Security

Primary ve replica arasındaki bağlantı;

authentication,

TLS,

network restriction

ile korunmalıdır.

Replication account gereğinden fazla yetkili olmamalıdır.

Aksi halde compromise geniş etki oluşturabilir.

Read Replica Yetkileri Nasıl Yönetilmeli?

Read-only replica üzerinde uygulama veya reporting kullanıcıları çalışabilir.

Ancak replica'nın network ve IAM erişimi yine kontrol edilmelidir.

“Read-only” olması hassas veri sızıntısı riskini ortadan kaldırmaz.

Database Cloud Security Nasıl Sağlanır?

AWS RDS, Azure SQL veya Google Cloud SQL gibi managed servislerde provider;

OS,

hardware,

bazı patch

sorumluluklarını yönetebilir.

Ancak müşteri;

network,

IAM,

user permissions,

data,

encryption,

backup policy

gibi alanlardan hâlâ sorumludur.

Managed Database'de Root Erişimi Olmaması Daha Güvenli mi?

Bazı managed database servislerinde OS seviyesinde erişim olmaz.

Bu saldırı yüzeyini azaltabilir.

Ancak application ve IAM riskleri devam eder.

Bir admin hesabının database'i public yapması hâlâ mümkündür.

Private Endpoint Managed Database İçin Neden Önemli?

Database'in public internet yerine cloud private network üzerinden erişilmesini sağlar.

Bu, internet attack surface'ini azaltır.

Özellikle production database'lerde güçlü bir network control'dür.

Cloud IAM Database Access İçin Kullanılabilir mi?

Bazı platformlar native IAM authentication destekler.

Bu sayede static database password kullanımını azaltmak mümkün olabilir.

Avantajlar;

central identity,

temporary token,

MFA/JIT integration

olabilir.

Ancak authorization yine doğru role'lerle sınırlandırılmalıdır.

Database Key Vault Entegrasyonu

Database credential ve encryption key'leri merkezi secret/key vault üzerinden yönetilebilir.

Bu;

rotation,

audit,

access control

avantajı sağlar.

Ancak vault erişimi kritik privilege haline gelir.

Database Connection Pool Security

Application'lar database connection pool kullanabilir.

Credential pool config içinde bulunabilir.

Bu config'in log veya debug output'ta görünmemesi gerekir.

Ayrıca idle connection ve timeout ayarları availability açısından önemlidir.

Database DoS Riski Nedir?

Saldırgan veya hatalı query;

CPU,

memory,

connection pool,

lock,

disk IO

kaynaklarını tüketebilir.

Bu database availability'yi etkiler.

Resource limit ve query timeout gibi kontroller önemlidir.

Connection Limit Neden Gereklidir?

Tek bir application veya user sınırsız connection açarsa database kaynaklarını tüketebilir.

Per-user veya per-application connection limit uygulanabilir.

Bu aynı zamanda noisy neighbor riskini azaltır.

Query Timeout Nedir?

Uzun süren query'lerin belirli sürede sonlandırılmasıdır.

Özellikle reporting veya web uygulamalarında yanlış sorguların tüm database kaynaklarını tüketmesini önleyebilir.

Ancak iş ihtiyaçlarına göre ayarlanmalıdır.

Resource Governor Nedir?

Bazı database platformları workload'lara farklı resource quota veya sınırlamalar tanımlayabilir.

Örneğin reporting workload production transaction'ları etkilememelidir.

Bu availability güvenliği için değerlidir.

Database Locking Güvenlik Konusu mu?

Dolaylı olarak evet.

Saldırgan veya hatalı uygulama uzun transaction'larla table lock oluşturabilir.

Bu service disruption'a neden olabilir.

Database monitoring bu davranışları tespit edebilir.

Mass Data Export Nasıl Tespit Edilir?

Normal kullanıcı günde birkaç yüz kayıt okuyor.

Bir anda milyonlarca satır export ediyor.

Bu davranış anomaly olabilir.

DAM veya SIEM üzerinden;

query volume,

rows returned,

data transfer

izlenebilir.

Insider Threat Database İçin Neden Kritik?

DBA veya privileged user teknik olarak birçok veriye erişebilir.

Bu nedenle insider riskleri sadece access control ile çözülemez.

Monitoring ve separation of duties gerekir.

Separation of Duties Database'de Nasıl Uygulanır?

Aynı kişi;

database admin,

audit log admin,

backup admin

olmamalı olabilir.

Görevler ayrılığı sayesinde tek kişinin hem işlem yapıp hem kayıtları değiştirmesi zorlaşır.

Maker-Checker Database İşlemlerinde Kullanılır mı?

Kritik schema change veya privileged grant işlemlerinde iki aşamalı onay uygulanabilir.

Bir kişi değişikliği hazırlar.

Başka yetkili onaylar.

Bu özellikle finansal ve regulated sistemlerde değerlidir.

Database Change Management Nedir?

Production database değişikliklerinin kontrollü şekilde yapılmasıdır.

Örneğin;

DDL,

index,

user grant,

config change

change kaydıyla ilişkilendirilebilir.

Bu güvenlik ve operasyonel stabiliteyi artırır.

Database Audit Logs SIEM'e Gönderilmeli mi?

Evet, kritik database'lerde faydalıdır.

Ancak log hacmi çok yüksek olabilir.

Bu nedenle;

privileged activity,

failed login,

role change,

schema change,

sensitive table access

gibi yüksek değerli olaylar önceliklendirilebilir.

Database SIEM Use Case Örnekleri

Örneğin;

Repeated Failed DBA Login

New Privileged User Created

Audit Disabled

Mass Data Export

Sensitive Table Access by Unusual User

Unexpected Schema Change

Database Login from New Source

gibi use case'ler oluşturulabilir.

Audit Disable Olayı Neden Kritik?

Saldırgan veya insider audit'i kapatmaya çalışıyorsa bu defense evasion göstergesi olabilir.

Audit configuration değişiklikleri yüksek priority ile izlenmelidir.

Database Login Anomaly Nasıl Tespit Edilir?

Normalde application account sadece application server'dan bağlanır.

Bir anda DBA laptop'ından veya farklı ülkedeki IP'den bağlantı gelir.

Bu anomali olabilir.

Source, time ve account behavior birlikte değerlendirilmelidir.

Application Account Interactive Login Yapmalı mı?

Genellikle service/application account sadece uygulama tarafından kullanılmalıdır.

İnsan kullanıcı aynı credential ile manuel login yapmamalıdır.

Interactive kullanım beklenmeyen aktivite olarak alarm üretilebilir.

Database Activity Baseline Nedir?

Normal kullanıcı ve uygulamaların database davranışının tanımlanmasıdır.

Örneğin;

normal query type,

normal access time,

normal source,

normal data volume

bilinir.

Anomali tespiti bu baseline üzerinden yapılabilir.

Database Threat Hunting Yapılır mı?

Evet.

Örneğin hipotez:

“Bir privileged account son 30 günde hassas müşteri tablolarını olağandışı şekilde export etmiş olabilir.”

Audit ve DAM kayıtlarında geçmişe dönük analiz yapılabilir.

Database Forensics Nedir?

Database olaylarının adli olarak analiz edilmesidir.

Kullanılabilecek kaynaklar;

audit logs,

transaction logs,

database logs,

OS logs,

DAM telemetry,

backup history

olabilir.

Ancak log retention önceden yeterli olmalıdır.

Transaction Log Forensics Mümkün mü?

Platforma bağlı olarak transaction veya redo log'lar belirli değişikliklerin anlaşılmasına yardımcı olabilir.

Ancak bu iş özel uzmanlık gerektirir.

Bu nedenle Incident Response sırasında database uzmanı sürece dahil edilmelidir.

Database Incident Response Nasıl Yapılır?

Bir database compromise şüphesinde;

hesaplar,

session'lar,

query history,

privilege changes,

data access,

backup,

OS telemetry

birlikte incelenmelidir.

Sadece şüpheli kullanıcıyı disable etmek yeterli olmayabilir.

Persistence veya yeni account oluşturulmuş olabilir.

Database Compromise Sonrası Credential Rotation

Application account,

DBA account,

replication account,

backup account

credential'ları etkilenmiş olabilir.

Risk kapsamına göre rotate edilmelidir.

Ayrıca aynı credential başka sistemlerde kullanılıyorsa kontrol edilmelidir.

Database Security Assessment Nasıl Yapılır?

Genel akış şöyle olabilir:

1. Asset Inventory

Database instance'ları belirlenir.

2. Architecture Review

On-prem/cloud ve network yapısı incelenir.

3. User & Role Review

Yetkiler değerlendirilir.

4. Hardening

CIS/vendor baseline kontrol edilir.

5. Network Exposure

Public ve internal erişimler analiz edilir.

6. Encryption

At-rest ve in-transit kontrol edilir.

7. Audit & DAM

Monitoring kapsamı incelenir.

8. Backup Security

Encryption ve immutability değerlendirilir.

9. Vulnerability/Patch

Version ve CVE analizi yapılır.

10. Attack Path

Application → DB → OS/cloud yolları değerlendirilir.

Database Attack Path Nedir?

Saldırganın uygulamadan veya kimlikten database'e ve daha kritik kaynaklara ilerleyebildiği ilişki zinciridir.

Örneğin:

Internet

↓

Web Application RCE

↓

Application Credential

↓

Database

↓

DBA Privilege

↓

OS Command Execution

↓

Production Server

Bu zincir sadece database güvenliği değildir.

AppSec, secret management ve server security de içerir.

Database Toxic Combination Örneği

Tek tek şu bulgular olabilir:

Web app'de orta seviye SSRF.

Secret vault geniş erişimli.

Database public değil.

Application DB hesabı DBA.

Birlikte bakıldığında saldırgan kritik veriye ulaşabilir.

Bu nedenle modern database risk yönetiminde bulguların ilişkisi önemlidir.

DAM ile PAM Birlikte Nasıl Kullanılır?

PAM:

Kim privileged erişim aldı?

sorusunu cevaplar.

DAM:

Database içinde ne yaptı?

sorusunu cevaplar.

Birlikte kullanıldığında yüksek yetkili erişim çok daha görünür hale gelir.

Database Security KPI'ları Nelerdir?

Örnek metrikler:

Privileged Account Count

Shared DBA Account Count

Public Database Count

Unencrypted Database Count

Unencrypted Backup Count

Critical DB Vulnerability Count

PAM Coverage

DAM Coverage

Audit Logging Coverage

Dormant Account Count

Restore Test Success Rate

Bu metrikler database security posture'u ölçmeye yardımcı olabilir.

Database Security Score Kullanılabilir mi?

Yönetim görünürlüğü için;

Access Control,

Network,

Encryption,

Audit,

Backup,

Patch

alanları puanlanabilir.

Ancak tek bir public production database ortalama skordan daha önemli olabilir.

Bu nedenle score + critical risk birlikte verilmelidir.

Database Security Raporunda Neler Olmalıdır?

Profesyonel rapor şu bölümleri içerebilir:

Executive Summary

Kritik iş ve veri riskleri.

Database Inventory

PostgreSQL, MSSQL, Oracle instance'ları.

Architecture & Exposure

Network ve public erişimler.

User & Privilege Review

DBA ve application hesapları.

Hardening Findings

Konfigürasyon sorunları.

Encryption Status

At-rest ve in-transit.

Audit & Monitoring

DAM/SIEM görünürlüğü.

Vulnerability & Patch

EOL ve CVE riskleri.

Backup Security

Encryption ve restore durumu.

Attack Path Analysis

Uygulama-database-OS/cloud zincirleri.

Remediation Roadmap

Önceliklendirilmiş iyileştirmeler.

Database Güvenliğinde En Büyük Hata Nedir?

En büyük hatalardan biri:

“Database internete açık değil, o halde güvenli.”

yaklaşımıdır.

Database private network'te olabilir.

Ama application hesabı DBA olabilir.

Shared admin account kullanılabilir.

Audit kapalı olabilir.

Backup şifrelenmemiş olabilir.

Aynı password yıllardır değişmemiş olabilir.

Yani private network yalnızca bir güvenlik katmanıdır.

Gerçek database security çok daha geniştir.

PostgreSQL, MSSQL ve Oracle İçin Ortak Güvenlik Prensipleri

Platformlar farklı olsa da ortak yaklaşım şöyledir:

Private Network

Gereksiz public exposure yok.

Least Privilege

Uygulama ve kullanıcı minimum yetkili.

Privileged Access Control

DBA erişimleri PAM/JIT ile yönetilir.

Encryption

At-rest ve in-transit.

Audit

Kritik aktiviteler loglanır.

DAM

Hassas veri erişimleri izlenir.

Patch & Hardening

Database ve OS güncel tutulur.

Backup Security

Backup şifreli ve geri döndürülebilir.

SIEM Integration

Şüpheli aktiviteler SOC tarafından görülür.

Database Security Lifecycle Nasıl Olmalıdır?

Sağlıklı model şu şekilde düşünülebilir:

Discover

Database envanteri.

↓

Harden

Güvenli baseline.

↓

Control Access

IAM/PAM ve Least Privilege.

↓

Protect Data

Encryption ve masking.

↓

Monitor

Audit, DAM ve SIEM.

↓

Patch

Vulnerability management.

↓

Backup

Secure recovery.

↓

Assess

Security assessment.

↓

Retest

Düzeltmelerin doğrulanması.

Bu döngü sürekli uygulanmalıdır.

Sonuç: Veritabanı Güvenliği Verinin Kendisine Giden Son Savunma Katmanıdır

Firewall güçlü olabilir.

Cloud IAM doğru olabilir.

Kubernetes sıkılaştırılmış olabilir.

Application güvenli olabilir.

Ama veritabanına gereğinden fazla yetkiyle bağlanan tek bir hesap bütün bu güvenlik zincirini zayıflatabilir.

Bu nedenle database security yalnızca DBA ekibinin operasyonel konusu değildir.

Kurumsal veri güvenliğinin doğrudan merkezindedir.

Güçlü bir database security yaklaşımı;

Database Hardening + Least Privilege + PAM + Network Segmentation + Encryption + DAM + SIEM + Patch Management + Secure Backup

katmanlarıyla oluşturulmalıdır.

Ve şu soru sürekli sorulmalıdır:

Bir saldırgan uygulama hesabını bugün ele geçirse database içerisinde ne kadar ilerleyebilir?

Sadece kendi schema'sını mı okuyabilir?

Bütün müşteri verisini mi export edebilir?

Yeni admin kullanıcı oluşturabilir mi?

Database üzerinden işletim sistemine geçebilir mi?

Backup'lara erişebilir mi?

Gerçek güvenlik seviyesi bu soruların cevaplarında ortaya çıkar.

Ancak veriyi korumak yalnızca production database'i korumak anlamına gelmez.

Ransomware saldırıları bize çok kritik başka bir gerçeği de gösterdi:

Saldırganlar artık yedekleri de hedefliyor.

Çünkü güvenli ve geri döndürülebilir backup varsa kurum yeniden ayağa kalkabilir.

Backup yoksa veya saldırgan tarafından silinmişse teknik olay doğrudan iş sürekliliği krizine dönüşebilir.