# Veritabanı Nedir? Kurumlar İçin Database Güvenliği Neden Kritik?

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/veritabani-guvenligi/veritabani-nedir-database-guvenligi

![Veritabanı Nedir? Kurumlar İçin Database Güvenliği Neden Kritik?](/images/bilgi-merkezi/covers/cover-veritabani-01.webp)

Modern kurumların neredeyse tüm dijital operasyonları veritabanları üzerinde çalışır.

Müşteri kayıtları,

finansal işlemler,

personel bilgileri,

ERP sistemleri,

CRM uygulamaları,

e-ticaret platformları,

mobil uygulamalar,

web servisleri,

üretim sistemleri,

log kayıtları,

API servisleri

ve kurumsal uygulamaların büyük bölümü veritabanlarıyla doğrudan ilişkilidir.

Bir web uygulamasının ön yüzü kullanıcıya görünen kısmı oluştururken asıl kritik bilgiler çoğu zaman arka taraftaki database sistemlerinde tutulur.

Bu nedenle veritabanları yalnızca teknik altyapının bir parçası değildir.

Aynı zamanda kurumun;

operasyonel hafızası,

ticari verisi,

müşteri bilgisi,

finansal kayıtları

ve çoğu zaman en değerli dijital varlıklarının bulunduğu merkezdir.

Bu nedenle modern siber güvenlik yaklaşımında veritabanı güvenliği ayrı bir uzmanlık alanı olarak ele alınmalıdır.

Temel soru şudur:

**“Bir saldırgan veritabanına erişirse kurumun hangi verilerine ulaşabilir ve ne kadar zarar verebilir?”**

Bu sorunun cevabı birçok kurum için oldukça kritiktir.

### Veritabanı Nedir?

Veritabanı, verilerin düzenli, erişilebilir ve yönetilebilir biçimde saklanmasını sağlayan sistemdir.

Basit bir Excel tablosu da veri tutabilir.

Ancak kurumsal ölçekte;

milyonlarca kayıt,

binlerce eşzamanlı kullanıcı,

yüksek işlem hacmi,

karmaşık sorgular,

yetkilendirme,

yedekleme,

replikasyon,

audit

ve transaction yönetimi

gibi ihtiyaçlar oluşur.

Bu noktada Database Management System yani DBMS kullanılır.

### DBMS Nedir?

DBMS:

#### Database Management System

yani:

#### Veritabanı Yönetim Sistemi

anlamına gelir.

DBMS, verinin;

oluşturulmasını,

saklanmasını,

okunmasını,

güncellenmesini,

silinmesini,

yetkilendirilmesini

ve yönetilmesini sağlar.

Kurumsal dünyada yaygın kullanılan örnekler arasında;

PostgreSQL,

Microsoft SQL Server,

Oracle Database,

MySQL,

MariaDB

bulunabilir.

### Veritabanı ile Database Aynı Şey midir?

Günlük kullanımda çoğu zaman aynı anlamda kullanılır.

Teknik olarak database verinin bulunduğu yapıyı ifade ederken DBMS bu yapıyı yöneten yazılımdır.

Ancak kurumsal konuşmalarda;

“database sunucusu”,

“veritabanı sistemi”,

“database altyapısı”

ifadeleri çoğu zaman daha geniş anlamda kullanılır.

### Veritabanları Neden Kurumlar İçin Kritik?

Bir kurumun birçok kritik iş süreci database olmadan çalışamaz.

Örneğin e-ticaret sistemini düşünelim.

Veritabanında;

ürün bilgileri,

stok durumu,

müşteri hesapları,

siparişler,

ödeme bilgileri,

adresler

bulunabilir.

Database erişilemez hale gelirse web sitesi açık görünse bile kullanıcı sipariş veremeyebilir.

Bu nedenle database:

**iş sürekliliğinin temel parçalarından biridir.**

### Veritabanı Güvenliği Nedir?

Veritabanı güvenliği, database sistemlerinin ve içerisinde bulunan verilerin;

yetkisiz erişim,

veri sızıntısı,

veri değiştirme,

silme,

ransomware,

insider threat,

yanlış yapılandırma

gibi risklere karşı korunmasıdır.

Bu yalnızca database password belirlemek anlamına gelmez.

Gerçek database security;

kimlik doğrulama,

yetkilendirme,

network güvenliği,

şifreleme,

audit,

patch management,

backup,

monitoring

ve hardening

gibi birçok katmandan oluşur.

### Database Security Neden Ayrı Bir Güvenlik Alanıdır?

Firewall kullanmak database'i otomatik olarak güvenli hale getirmez.

EDR kullanmak da database erişimlerini tam olarak kontrol etmez.

Database sistemlerinin kendi;

user,

role,

permission,

schema,

stored procedure,

trigger,

audit

mekanizmaları vardır.

Bu nedenle database güvenliği ayrı uzmanlık gerektirir.

### Veritabanı Güvenliğinde CIA Üçlüsü

Database security klasik bilgi güvenliği prensipleriyle açıklanabilir.

#### Confidentiality – Gizlilik

Veriye yalnızca yetkili kişiler erişmelidir.

Örneğin insan kaynakları database'indeki maaş bilgilerini herkes görememelidir.

#### Integrity – Bütünlük

Veri yetkisiz şekilde değiştirilememelidir.

Örneğin banka hesabındaki bakiye izinsiz değiştirilememelidir.

#### Availability – Erişilebilirlik

Veri gerektiğinde kullanılabilir olmalıdır.

Database down olursa kritik uygulamalar çalışmayabilir.

### Bir Veritabanında Ne Tür Veriler Bulunabilir?

Kuruma göre database içerisinde;

kişisel veriler,

finansal bilgiler,

müşteri kayıtları,

kimlik bilgileri,

adresler,

telefon numaraları,

e-posta adresleri,

ödeme kayıtları,

ticari sırlar,

üretim verileri,

loglar,

şifre hash'leri

bulunabilir.

Bu nedenle database compromise ciddi veri ihlaline dönüşebilir.

### Database Breach Nedir?

Database Breach, yetkisiz kişinin database içerisindeki verilere erişmesi veya bunları dışarı çıkarmasıdır.

Bu olay;

zayıf parola,

SQL Injection,

yanlış yetkilendirme,

çalıntı administrator hesabı,

açık database portu,

uygulama zafiyeti

nedeniyle gerçekleşebilir.

### Database Saldırı Yüzeyi Nedir?

Attack Surface, saldırganın erişebileceği veya kötüye kullanabileceği tüm noktaları ifade eder.

Database için saldırı yüzeyi şu bileşenleri içerebilir:

- Database portları
- Administrator console
- Web uygulamaları
- API'ler
- Service account'lar
- Backup dosyaları
- Replication bağlantıları
- Database management araçları
- Cloud yönetim hesapları
- İşletim sistemi

Bu nedenle database yalnızca kendi yazılımı üzerinden korunmaz.

### Database Portları İnternete Açık Olmalı mı?

Genel olarak kritik kurumsal database sistemleri doğrudan internete açık olmamalıdır.

Örneğin;

PostgreSQL,

MSSQL,

MySQL

portlarının internet üzerinden herkese açık olması saldırı yüzeyini büyütür.

Database'e yalnızca gerekli application server veya yönetim network'lerinden erişim sağlanmalıdır.

### Database Network Segmentasyonu Neden Önemlidir?

Database server kullanıcı bilgisayarlarıyla aynı flat network üzerinde bulunmamalıdır.

Örnek mimari:

User VLAN

↓

Application VLAN

↓

Database VLAN

şeklinde ayrılabilir.

Firewall yalnızca gerekli trafik akışlarına izin verir.

### Kullanıcılar Database'e Doğrudan Bağlanmalı mı?

Çoğu uygulamada hayır.

Kullanıcı;

web application

veya

business application

üzerinden veri erişimi sağlamalıdır.

Database'e doğrudan kullanıcı bağlantısı minimum seviyede tutulmalıdır.

### Database Administrator – DBA Kimdir?

DBA:

#### Database Administrator

veritabanı sistemlerinin;

kurulum,

yapılandırma,

performans,

backup,

restore,

yetkilendirme

ve operasyonundan sorumlu uzman rolüdür.

DBA yüksek yetkilere sahip olabilir.

Bu nedenle DBA account'ları privileged account kabul edilmelidir.

### DBA Hesabı Neden Kritik?

DBA çoğu zaman database içerisindeki tüm verilere erişebilir.

Örneğin DBA;

tablo okuyabilir,

veri değiştirebilir,

kullanıcı oluşturabilir,

database silebilir.

Bu nedenle DBA account compromise kritik güvenlik olayıdır.

### Database Administrator Hesabı Günlük Kullanım İçin Kullanılmalı mı?

Hayır.

Administrator hesabı yalnızca yönetim işlemleri için kullanılmalıdır.

Günlük;

mail,

internet,

doküman

işlemlerinde kullanılmamalıdır.

### Least Privilege Database Güvenliğinde Nedir?

Least Privilege:

#### Minimum Yetki Prensibi

kullanıcıya yalnızca ihtiyaç duyduğu izinlerin verilmesini ifade eder.

Örneğin bir reporting kullanıcısı sadece:

SELECT

yetkisine ihtiyaç duyabilir.

Bu kullanıcıya;

UPDATE,

DELETE,

DROP

yetkisi verilmemelidir.

### Database Role-Based Access Control – RBAC

RBAC, kullanıcı yetkilerinin roller üzerinden yönetilmesini sağlar.

Örneğin;

DB_ReadOnly

DB_Developer

DB_Operator

DB_Admin

rolleri oluşturulabilir.

Bu yaklaşım erişim yönetimini kolaylaştırır.

### Her Uygulama Ayrı Database User Kullanmalı mı?

Mümkün olduğunca evet.

Birden fazla uygulamanın aynı database hesabını kullanması;

audit,

yetki yönetimi,

incident investigation

açısından sorun oluşturabilir.

Her uygulamanın ayrı service account kullanması daha sağlıklıdır.

### Shared Database Account Neden Risklidir?

Örneğin 20 kişi:

dbadmin

hesabını kullanıyorsa hangi işlemi kimin yaptığı bilinemez.

Bu durum accountability sorununa yol açar.

### Database Password Nasıl Olmalı?

Database hesaplarında;

güçlü,

benzersiz,

uzun

password kullanılmalıdır.

Default password'ler kesinlikle değiştirilmelidir.

### Default Database Account'lar Kontrol Edilmeli mi?

Evet.

Kurulum sırasında gelen;

default user,

sample user,

test database

kaldırılmalı veya güvenli hale getirilmelidir.

### Database Hardening Nedir?

Database Hardening, gereksiz özellikleri kapatarak ve güvenlik ayarlarını güçlendirerek saldırı yüzeyini azaltma sürecidir.

Örneğin;

gereksiz servisleri kapatmak,

default account'ları kaldırmak,

minimum network erişimi sağlamak,

güvenli authentication kullanmak

database hardening kapsamındadır.

### Database Hardening Neden Önemlidir?

Database yazılımları çok sayıda özellik barındırabilir.

Ancak kullanılmayan özellikler saldırı yüzeyini büyütebilir.

Temel prensip:

**Kullanılmayan özellik kapatılmalıdır.**

### Database Patch Management Nedir?

Database yazılımları da diğer yazılımlar gibi güvenlik açıklarına sahip olabilir.

Vendor tarafından yayınlanan security patch'lerin kontrollü şekilde uygulanması gerekir.

### Database Patch'leri Neden Geciktirilir?

Kurumlar database patch işlemlerinden çekinebilir.

Çünkü kritik uygulamalar etkilenebilir.

Ancak yıllarca patch yapılmayan database ciddi saldırı riski oluşturabilir.

Bu nedenle;

test,

staging,

change management,

rollback plan

kullanılmalıdır.

### Vulnerability Management Database Sistemlerini Kapsamalı mı?

Evet.

Database server;

işletim sistemi,

DBMS versiyonu,

network servisi,

configuration

açısından değerlendirilmelidir.

### Database Security Assessment Nedir?

Database Security Assessment, veritabanının güvenlik yapılandırmasının sistematik olarak incelenmesidir.

Örneğin;

zayıf account'lar,

gereksiz yetkiler,

açık portlar,

eksik patch'ler,

audit ayarları

kontrol edilebilir.

### Database Hardening Benchmark Kullanılabilir mi?

Evet.

CIS Benchmark gibi güvenli yapılandırma rehberleri kullanılabilir.

Ayrıca vendor'ın security hardening dokümanları takip edilebilir.

### SQL Injection Nedir?

SQL Injection, uygulamanın kullanıcı girdisini güvenli şekilde işleyememesi sonucu saldırganın database sorgusunu manipüle edebilmesi durumudur.

Bu zafiyet genellikle application layer'da oluşur.

Ancak sonuç database üzerinde ortaya çıkar.

### SQL Injection Neden Tehlikelidir?

Başarılı bir SQL Injection saldırısı sonucunda saldırgan;

veri okuyabilir,

veri değiştirebilir,

authentication bypass yapabilir

ve uygulamanın sahip olduğu database yetkileri ölçüsünde ciddi etki oluşturabilir.

### SQL Injection Database Problemi midir?

Hem uygulama hem database güvenliğiyle ilgilidir.

Asıl hata çoğu zaman uygulamanın güvenli sorgu oluşturmamasıdır.

Ancak database account'a aşırı yetki verilmişse saldırının etkisi büyür.

### Parameterized Query Nedir?

Parameterized Query, kullanıcı girdisinin SQL komutundan ayrılmasını sağlayan güvenli sorgu yöntemidir.

SQL Injection riskini azaltan temel yöntemlerden biridir.

### Stored Procedure SQL Injection'ı Tamamen Engeller mi?

Hayır.

Stored procedure güvenli şekilde tasarlanırsa faydalıdır.

Ancak içerisinde dinamik ve güvensiz SQL oluşturuluyorsa yine SQL Injection oluşabilir.

### Database Firewall Nedir?

Database Firewall, database sorgularını ve bağlantılarını analiz ederek anormal veya yetkisiz davranışları engellemeye yardımcı olabilir.

Bu geleneksel network firewall'dan farklıdır.

### Web Application Firewall Database'i Korur mu?

WAF özellikle web tabanlı SQL Injection saldırılarını tespit veya engellemeye yardımcı olabilir.

Ancak database güvenliğinin yerine geçmez.

Defense in Depth uygulanmalıdır.

### Defense in Depth Nedir?

Defense in Depth yani Derinlemesine Savunma, birden fazla güvenlik katmanının birlikte kullanılmasını ifade eder.

Database için örnek:

WAF

↓

Secure Application

↓

Firewall

↓

Database Authentication

↓

RBAC

↓

Audit

↓

DAM

Bu katmanlardan biri başarısız olsa bile diğerleri saldırıyı sınırlayabilir.

### Database Encryption Nedir?

Database Encryption, verinin şifrelenerek korunmasıdır.

İki temel alan vardır:

#### Encryption at Rest

ve

#### Encryption in Transit

### Encryption at Rest Nedir?

Disk üzerinde bulunan database dosyalarının şifrelenmesidir.

Storage çalınsa veya disk dosyaları ele geçirilse bile verinin okunmasını zorlaştırır.

### TDE Nedir?

TDE:

#### Transparent Data Encryption

yani:

#### Şeffaf Veri Şifreleme

olarak ifade edilir.

Database dosyalarının ve bazı durumlarda transaction log'ların şifrelenmesini sağlar.

Uygulama genellikle bu süreçten etkilenmeden çalışabilir.

### TDE Database Kullanıcısından Veriyi Gizler mi?

Hayır.

Bu çok önemli bir ayrımdır.

Yetkili database kullanıcısı normal sorguyla veriyi okuyabilir.

TDE daha çok disk veya database file seviyesindeki veri hırsızlığına karşı koruma sağlar.

### Column-Level Encryption Nedir?

Belirli hassas kolonların ayrıca şifrelenmesidir.

Örneğin;

TCKN,

kredi kartı bilgisi,

sağlık verisi

gibi alanlar ayrıca şifrelenebilir.

### Database Encryption in Transit Nedir?

Client ile database arasındaki trafiğin TLS gibi güvenli protokollerle şifrelenmesidir.

Bu sayede network üzerinden database sorguları ve cevapları açık şekilde taşınmaz.

### Database TLS Neden Önemlidir?

Database network trafiğinde;

username,

query,

response,

hassas veri

bulunabilir.

TLS kullanılmazsa network sniffing riski oluşabilir.

### Database Encryption Key Nerede Tutulmalı?

Encryption key;

database ile aynı açık dosya sistemi içerisinde korunmamalıdır.

KMS,

HSM,

secure vault

kullanılabilir.

### Database Backup Şifrelenmeli mi?

Evet.

Production database şifreli olup backup dosyasının şifresiz tutulması önemli bir güvenlik açığıdır.

Backup içerisinde production verisinin tamamı bulunabilir.

### Database Backup Neden Kritik?

Database corruption,

yanlış SQL işlemi,

ransomware,

hardware failure,

administrator hatası

durumunda backup kullanılabilir.

### Database Backup ile File Backup Aynı mı?

Hayır.

Database transaction tabanlı sistemdir.

Dosyanın basit kopyasını almak database consistency açısından yeterli olmayabilir.

### Database Consistent Backup Nedir?

Database'in transaction açısından tutarlı şekilde yedeklenmesini sağlar.

Restore edildiğinde database düzgün şekilde açılmalıdır.

### Full Database Backup Nedir?

Database'in tamamının backup'ıdır.

Recovery zincirinin temelini oluşturabilir.

### Differential Database Backup Nedir?

Son full backup'tan sonra değişen verilerin yedeğidir.

Bazı database platformlarında desteklenir.

### Transaction Log Backup Nedir?

Database transaction kayıtlarının backup'ıdır.

Bu yapı daha düşük RPO sağlayabilir.

### Point-in-Time Recovery Nedir?

PITR:

#### Point-in-Time Recovery

database'i belirli bir zaman noktasına geri getirme yeteneğidir.

Örneğin saat 14:37'de hatalı DELETE işlemi yapılmışsa:

14:36:59

noktasına geri dönüş hedeflenebilir.

### Database RPO Neden Kritik?

Yoğun transaction yapan database'te 24 saatlik backup yeterli olmayabilir.

Örneğin bankacılık veya e-ticaret database'inde dakikalar bile önemli olabilir.

Bu nedenle RPO iş ihtiyacına göre belirlenmelidir.

### Database RTO Neden Kritik?

Database birçok application'ın dependency'sidir.

Database 8 saat restore edilirse tüm uygulamalar 8 saat çalışamayabilir.

Bu nedenle restore performansı test edilmelidir.

### Database Restore Testi Yapılmalı mı?

Kesinlikle.

Backup alındığını görmek yeterli değildir.

Backup'ın gerçekten restore edilebildiği doğrulanmalıdır.

### Database Integrity Check Nedir?

Database içerisindeki page, index veya data structure bozulmalarını tespit etmeyi amaçlayan kontrollerdir.

Platforma göre farklı integrity check mekanizmaları bulunabilir.

### Database Corruption Nedir?

Database dosyalarının veya veri yapısının bozulmasıdır.

Nedenleri;

storage problemi,

hardware failure,

software bug,

yanlış shutdown

olabilir.

### Corruption Backup'a Taşınabilir mi?

Evet.

Bozuk database'in backup'ı alınırsa backup içerisinde de corruption bulunabilir.

Bu nedenle integrity monitoring önemlidir.

### Database Maintenance Nedir?

Database Maintenance, database'in sağlıklı, performanslı ve güvenli çalışması için yapılan düzenli bakım işlemleridir.

Örneğin;

index maintenance,

statistics update,

integrity check,

backup,

patch,

log kontrolü,

capacity management

yapılabilir.

### Database Bakımı Sadece Performans İçin mi Yapılır?

Hayır.

Database maintenance;

performans,

availability,

security,

data integrity

için önemlidir.

### Index Nedir?

Index, database sorgularının daha hızlı çalışmasını sağlayan veri yapısıdır.

Kitabın sonundaki indeks gibi düşünülebilir.

### Çok Fazla Index Zararlı Olabilir mi?

Evet.

Index query performansını artırabilir.

Ancak INSERT, UPDATE ve DELETE işlemlerini yavaşlatabilir.

Bu nedenle index yönetimi dengeli yapılmalıdır.

### Fragmentation Nedir?

Bazı database sistemlerinde index yapılarının zamanla dağınık hale gelmesi performansı etkileyebilir.

Platforma göre reorganize veya rebuild işlemleri değerlendirilebilir.

### Statistics Nedir?

Database optimizer'ın query plan oluştururken kullandığı veri dağılım bilgilerini ifade eder.

Statistics eskiyse kötü execution plan oluşabilir.

### Query Performance Güvenlikle İlgili midir?

Dolaylı olarak evet.

Kötü sorgular CPU ve memory kaynaklarını tüketerek denial-of-service benzeri etki oluşturabilir.

Bu nedenle performans izleme aynı zamanda availability güvenliğini destekler.

### Database Connection Pool Nedir?

Application'ların her sorguda yeni bağlantı açmak yerine mevcut database bağlantılarını tekrar kullanmasını sağlayan mekanizmadır.

Yanlış yapılandırılırsa database connection exhaustion oluşabilir.

### Maximum Connection Neden Önemlidir?

Kontrolsüz bağlantılar database kaynaklarını tüketebilir.

Bu nedenle connection limit ve pool ayarları önemlidir.

### Database Monitoring Nedir?

Database Monitoring, database'in;

availability,

performance,

security,

capacity

durumunun sürekli izlenmesidir.

### Hangi Database Metrikleri İzlenmeli?

Örneğin;

CPU,

memory,

disk usage,

IO latency,

connection count,

slow query,

deadlock,

failed login

izlenebilir.

### Failed Login Neden Güvenlik Olayıdır?

Çok sayıda başarısız database login;

brute force,

credential stuffing,

yanlış yapılandırılmış uygulama

göstergesi olabilir.

### Database Audit Nedir?

Database Audit, database üzerinde yapılan işlemlerin kayıt altına alınmasıdır.

Örneğin;

kim bağlandı,

hangi tabloyu okudu,

hangi veriyi değiştirdi,

hangi kullanıcı oluşturuldu

takip edilebilir.

### Database Log ile Audit Aynı Şey midir?

Her zaman değil.

Operational log sistemin teknik çalışmasını gösterir.

Audit log ise kullanıcı faaliyetlerini ve güvenlik açısından önemli işlemleri kaydetmeye odaklanabilir.

### Audit Log Neden Kritik?

Bir veri ihlali sonrası şu soruya cevap verilmesi gerekir:

**“Hangi kullanıcı hangi veriye erişti?”**

Audit yoksa bu soruya cevap vermek çok zor olabilir.

### Database Activity Monitoring – DAM Nedir?

DAM:

#### Database Activity Monitoring

veritabanı aktivitelerinin merkezi ve güvenlik odaklı olarak izlenmesini sağlar.

Database query,

login,

privileged activity,

sensitive data access

gibi olaylar analiz edilebilir.

### DAM Neden Kullanılır?

Özellikle;

yüksek hacimli database,

kritik veri,

compliance gereksinimleri,

privileged user monitoring

bulunan kurumlarda faydalıdır.

### DBA Aktivitesi İzlenmeli mi?

Evet.

DBA yüksek yetkiye sahiptir.

Ancak “administrator zaten güvenilirdir” yaklaşımı yeterli değildir.

Privileged account aktiviteleri audit edilmelidir.

### Insider Threat Database İçin Neden Kritik?

Database'e yasal erişimi bulunan çalışan kötü niyetli davranabilir.

Örneğin müşteri listesini dışarı çıkarabilir.

Bu nedenle yalnızca dış saldırganlara odaklanılmamalıdır.

### Data Exfiltration Nedir?

Data Exfiltration, verinin yetkisiz şekilde kurum dışına çıkarılmasıdır.

Database için;

bulk query,

export,

dump,

backup copy

üzerinden gerçekleşebilir.

### Büyük SELECT Sorguları İzlenmeli mi?

Kritik ve hassas database'lerde normal davranıştan çok daha yüksek veri çeken sorgular güvenlik açısından incelenebilir.

Örneğin normalde 50 müşteri kaydı görüntüleyen kullanıcı bir anda 5 milyon kayıt çekiyorsa alarm üretilebilir.

### Database Anomaly Detection Nedir?

Kullanıcının normal database davranışından sapmaların tespit edilmesidir.

Örneğin;

gece erişim,

farklı IP,

çok sayıda tablo erişimi,

yüksek veri export

anomali olarak değerlendirilebilir.

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

Kritik database sistemlerinde evet.

SIEM üzerinden;

failed login,

privileged activity,

account creation,

permission change,

audit event

merkezi olarak izlenebilir.

### Database ve SOC Entegrasyonu

SOC ekipleri database güvenlik olaylarını network ve endpoint olaylarıyla birlikte değerlendirebilir.

Örneğin;

EDR → credential theft

Firewall → database connection

DAM → bulk customer query

SIEM → data exfiltration alarmı

aynı incident içerisinde ilişkilendirilebilir.

### Database Güvenliği ile DLP Arasındaki İlişki

DLP hassas verinin kurum dışına çıkmasını kontrol etmeye odaklanır.

Database ise verinin ana kaynaklarından biridir.

DAM + DLP birlikte kullanıldığında database'den çıkan verinin hareketi daha iyi izlenebilir.

### Sensitive Data Discovery Nedir?

Database içerisinde hangi tabloların hassas veri içerdiğinin tespit edilmesidir.

Örneğin;

TCKN,

IBAN,

telefon,

adres,

e-posta

bulunan kolonlar keşfedilebilir.

### Data Classification Database İçin Neden Önemlidir?

Tüm database tabloları aynı önemde değildir.

Veri;

Public,

Internal,

Confidential,

Restricted

gibi sınıflara ayrılabilir.

Daha hassas veriye daha güçlü kontroller uygulanabilir.

### Database Masking Nedir?

Data Masking, hassas verinin gerçek değerini gizleyerek farklı bir değer göstermektir.

Örneğin:

12345678901

yerine:

123******01

gösterilebilir.

### Data Masking Nerede Kullanılır?

Özellikle;

test,

development,

support

ortamlarında faydalıdır.

Gerçek müşteri verisinin geliştirici ortamında bulunmasını azaltır.

### Production Database Test Ortamına Kopyalanmalı mı?

Doğrudan ve kontrolsüz şekilde kopyalanmamalıdır.

Production database kişisel ve hassas veri içeriyorsa test ortamında ciddi risk oluşabilir.

### Data Masking ve Anonymization Aynı mı?

Hayır.

Masking genellikle veriyi görünürlük açısından gizler.

Anonymization ise kişinin artık tanımlanamayacağı şekilde veriyle ilişkinin kaldırılmasını hedefler.

### Database Secrets Nerede Saklanmalı?

Application connection string içerisinde;

username,

password,

API secret

bulunabilir.

Bu bilgiler source code içerisinde hard-code edilmemelidir.

### Connection String Nedir?

Application'ın database'e nasıl bağlanacağını belirleyen konfigürasyondur.

Örneğin;

server,

port,

database name,

username

içerebilir.

### Hard-Coded Password Neden Risklidir?

Kaynak kod repository'sine database password yazılırsa;

developer,

CI/CD sistemi,

repository compromise

sonucu credential ele geçirilebilir.

### Secret Management Kullanılmalı mı?

Evet.

Vault veya cloud secret manager gibi sistemlerden credential dinamik şekilde alınabilir.

### Password Rotation Database İçin Gerekli mi?

Risk ve mimariye göre düzenli credential rotation uygulanabilir.

Özellikle privileged ve service account'lar için önemlidir.

### Certificate-Based Authentication Kullanılabilir mi?

Bazı database ortamlarında certificate veya güçlü merkezi identity mekanizmaları kullanılabilir.

Bu statik password kullanımını azaltabilir.

### MFA Database Login İçin Kullanılabilir mi?

Database platformunun doğrudan desteğine veya kullanılan identity katmanına bağlıdır.

Özellikle DBA yönetim erişimlerinde MFA güçlü şekilde değerlendirilmelidir.

### PAM Database Administrator İçin Kullanılmalı mı?

Kritik ortamlarda faydalıdır.

PAM;

password vault,

session recording,

approval,

JIT access

sağlayabilir.

### JIT Database Access Nedir?

Database administrator yetkisinin sürekli açık olmaması, ihtiyaç anında geçici verilmesidir.

Örneğin DBA production erişimi yalnızca change süresi boyunca aktif olabilir.

### Production Database Erişimi Nasıl Yönetilmeli?

Örneğin:

talep

↓

manager approval

↓

PAM

↓

temporary access

↓

session recording

↓

access revoke

şeklinde süreç oluşturulabilir.

### Developer Production Database'e Erişmeli mi?

Mümkün olduğunca minimum seviyede.

Developer erişimi gerekiyorsa;

read-only,

temporary,

audited

şekilde sağlanabilir.

### Separation of Duties Database İçin Nedir?

Örneğin DBA'nın hem database yönetip hem audit loglarını silebilmesi risk oluşturabilir.

Görevlerin ayrılığı prensibi uygulanabilir.

### Database Audit Log Değiştirilemez Olmalı mı?

Kritik ortamlarda audit kayıtlarının database administrator tarafından kolayca silinememesi önemlidir.

Loglar merkezi SIEM veya immutable log storage'a gönderilebilir.

### Database High Availability Nedir?

HA:

#### High Availability

database'in kesinti durumunda hizmet vermeye devam etmesini hedefler.

Cluster veya replication kullanılabilir.

### HA Backup Yerine Geçer mi?

Hayır.

Primary database yanlışlıkla silinirse bu değişiklik replica'ya da aktarılabilir.

Replication backup değildir.

### Database Replication Nedir?

Verinin bir database sisteminden başka sisteme kopyalanmasıdır.

Amaç;

availability,

read scaling,

DR

olabilir.

### Synchronous Replication Nedir?

Transaction tamamlanmadan önce replica'nın da veriyi alması beklenebilir.

Daha düşük RPO sağlar ancak latency etkileyebilir.

### Asynchronous Replication Nedir?

Primary işlemi tamamlar ve veri replica'ya daha sonra gönderilir.

Performans avantajı vardır ancak belli miktarda veri kaybı olabilir.

### Database DR Neden Ayrı Planlanmalı?

Database çoğu uygulamanın merkezi dependency'sidir.

DR sırasında;

replica activation,

DNS,

connection string,

data consistency

kontrol edilmelidir.

### Database Failover Nedir?

Primary database devre dışı kaldığında secondary database'in aktif hale gelmesidir.

Automatic veya manual olabilir.

### Failback Nedir?

Primary ortam geri geldiğinde servisin tekrar ana sisteme taşınmasıdır.

Data synchronization doğru yapılmalıdır.

### Split-Brain Database Riski Nedir?

İki database node'un aynı anda primary olduğunu düşünmesi veri tutarsızlığı yaratabilir.

Cluster mimarilerinde quorum ve fencing mekanizmaları önemlidir.

### Database Capacity Management Nedir?

Storage, memory, CPU ve connection kapasitesinin gelecekteki ihtiyaca göre planlanmasıdır.

Database disk dolarsa sistem durabilir.

### Database Disk Dolması Güvenlik Olayı mı?

Availability açısından evet.

Örneğin transaction log diski tamamen dolarsa application işlemleri durabilir.

### Transaction Log Neden İzlenmeli?

Transaction log hızla büyüyebilir.

Backup veya maintenance hatası nedeniyle disk tamamen dolabilir.

### Database Alerting Neleri Kapsamalı?

Örneğin;

CPU high,

disk full,

replication lag,

backup failed,

failed login,

deadlock,

slow query,

privilege change

alarm üretmelidir.

### Database Baseline Nedir?

Database'in normal davranış profili oluşturulur.

Örneğin normal;

CPU,

query rate,

login count,

data volume

bilinir.

Sapmalar daha kolay tespit edilir.

### Database Security Baseline Nedir?

Güvenli configuration standardıdır.

Örneğin;

hangi portlar açık,

hangi authentication kullanılacak,

hangi account'lar bulunacak,

hangi audit policy aktif olacak

tanımlanır.

### Dev, Test ve Production Database Ayrılmalı mı?

Evet.

Production database ile test sistemleri aynı güvenlik düzeyinde olmayabilir.

Bu nedenle environment separation yapılmalıdır.

### Test Database Production Credential Kullanmalı mı?

Hayır.

Her ortamın ayrı credential ve secret'ları olmalıdır.

### Database Change Management Nedir?

Schema veya configuration değişikliklerinin kontrollü şekilde uygulanmasıdır.

Örneğin;

ALTER TABLE,

index değişikliği,

version upgrade

change sürecine tabi olabilir.

### Database Schema Change Neden Risklidir?

Yanlış schema değişikliği;

application outage,

data loss,

performance degradation

oluşturabilir.

### Database Rollback Planı Olmalı mı?

Evet.

Değişiklik başarısız olursa geri dönüş yöntemi önceden belirlenmelidir.

### Pre-Change Backup Alınmalı mı?

Kritik database değişikliklerinden önce backup veya restore point oluşturmak faydalı olabilir.

### Database Upgrade Öncesi Ne Yapılmalı?

Genellikle;

compatibility test,

backup,

rollback plan,

application test

yapılmalıdır.

### End-of-Life Database Nedir?

Vendor desteği sona ermiş database sürümüdür.

Security patch alınmadığı için yüksek risk oluşturabilir.

### Legacy Database Neden Tehlikelidir?

Eski uygulamalar eski database versiyonuna bağımlı olabilir.

Ancak security vulnerability ve compatibility riskleri zamanla artar.

### Database Asset Inventory Nedir?

Kurumun sahip olduğu tüm database sistemlerinin envanteridir.

Örneğin;

server,

database name,

version,

owner,

criticality,

data classification

bilgileri tutulabilir.

### Bilinmeyen Database Güvenlik Riski midir?

Evet.

IT'nin bilmediği bir database;

patchsiz,

backupsız,

internete açık

olabilir.

Bu nedenle asset discovery önemlidir.

### Shadow Database Nedir?

İş birimlerinin BT bilgisi olmadan oluşturduğu database veya veri deposudur.

Security ve compliance açısından risklidir.

### Cloud Database Güvenliği

Cloud database servislerinde infrastructure management'in bazı bölümleri provider tarafından yönetilebilir.

Ancak müşteri yine;

IAM,

network,

data,

backup,

configuration

gibi alanlardan sorumludur.

### Managed Database Güvenli midir?

Managed olması otomatik olarak tamamen güvenli olduğu anlamına gelmez.

Yanlış IAM veya public network exposure ciddi risk oluşturabilir.

### Public Cloud Database Neden Risklidir?

Database public internetten erişilebiliyorsa brute-force ve vulnerability scanning gibi riskler artar.

Private endpoint ve network restriction değerlendirilebilir.

### Cloud Database Shared Responsibility

Provider database platformunun bazı altyapı bileşenlerini yönetebilir.

Müşteri ise;

user,

role,

data,

network access,

backup policy

gibi alanları yönetir.

### Database Güvenliği ve KVKK

Kişisel verilerin önemli bölümü database sistemlerinde bulunur.

Bu nedenle KVKK açısından;

erişim kontrolü,

loglama,

şifreleme,

data minimization,

retention

gibi kontroller önemlidir.

### Database Audit KVKK Açısından Neden Önemlidir?

Bir veri ihlalinde hangi kullanıcının hangi verilere eriştiğinin belirlenebilmesi önemli olabilir.

Audit kayıtları olay incelemesini destekler.

### Database Retention Nedir?

Verinin ne kadar süre tutulacağını belirleyen politikadır.

Her veri sınırsız süre tutulmamalıdır.

### Database Data Minimization Nedir?

İş amacı için gerekli olmayan verinin tutulmamasıdır.

Gereksiz veri hem saldırı etkisini hem compliance riskini büyütür.

### Database Güvenliği ve ISO/IEC 27001

ISO/IEC 27001 açısından database içerisindeki bilgi varlıklarının;

gizlilik,

bütünlük,

erişilebilirlik

riskleri değerlendirilmelidir.

Erişim kontrolü, backup, logging, vulnerability management ve cryptography gibi süreçler database güvenliğiyle doğrudan ilişkilidir.

### Database Güvenliği ve PCI DSS

Kart verisi tutulan database sistemleri PCI DSS kapsamına girebilir.

Bu durumda;

access control,

logging,

encryption,

vulnerability management

gibi ek gereksinimler oluşabilir.

### Kurumsal Database Güvenlik Kontrol Listesi

Bir kurum şu sorulara cevap verebilmelidir:

Database envanterimiz var mı?

Hangi database hangi veriyi tutuyor?

Database internete açık mı?

Network segmentasyonu var mı?

Default account'lar kapalı mı?

DBA hesapları ayrı mı?

Least Privilege uygulanıyor mu?

Audit aktif mi?

Database logları SIEM'e gidiyor mu?

Veri şifreli mi?

TLS kullanılıyor mu?

Backup şifreli mi?

Restore test ediliyor mu?

Patch'ler güncel mi?

Database vulnerability assessment yapılıyor mu?

Bu sorular database security maturity hakkında güçlü bir başlangıç noktası oluşturur.

### Database Güvenliğinde En Sık Yapılan Hatalar

Kurumlarda sık karşılaşılan hatalar şunlardır:

- Database portlarını internete açmak,
- default kullanıcıları bırakmak,
- ortak DBA account kullanmak,
- uygulama account'larına gereksiz yetki vermek,
- şifreleme kullanmamak,
- database loglarını izlememek,
- audit açmamak,
- patch'leri yıllarca ertelemek,
- test ortamında production verisi kullanmak,
- backup'ı şifresiz saklamak,
- restore testi yapmamak,
- developer'lara sürekli production erişimi vermek,
- hard-coded database password kullanmak,
- hassas veriyi sınıflandırmamak.

### Database Güvenliğinde Defense in Depth Yaklaşımı

Güvenli bir database mimarisi tek kontrole dayanmaz.

Örnek:

#### WAF

↓

#### Secure Application

↓

#### Network Firewall

↓

#### Database Segmentation

↓

#### Strong Authentication

↓

#### RBAC / Least Privilege

↓

#### Encryption

↓

#### Audit & DAM

↓

#### SIEM Monitoring

↓

#### Encrypted & Immutable Backup

Bu katmanlar birbirini tamamlar.

### Database Güvenliğinde Yönetimin Sorması Gereken Sorular

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

Kritik verilerimiz hangi database'lerde?

Kimler bu verilere erişebilir?

DBA'ların aktiviteleri izleniyor mu?

Database'ler internete açık mı?

Son security assessment ne zaman yapıldı?

Son patch ne zaman uygulandı?

Database backup'ları restore edildi mi?

Bir administrator müşteri database'ini export ederse bunu fark eder miyiz?

Bu sorular teknik ayrıntılardan çok kurumun gerçek risk durumunu gösterir.

### Sonuç: Veritabanı Güvenliği Kurumsal Siber Güvenliğin Merkezindedir

Modern kurumlarda uygulamaların değeri büyük ölçüde işledikleri veriden gelir.

Bu verinin önemli bölümü ise database sistemlerinde bulunur.

Bu nedenle bir veritabanının güvenliğini yalnızca:

**“Şifresi güçlü mü?”**

sorusu üzerinden değerlendirmek doğru değildir.

Gerçek database security;

**network segmentation,**

**strong authentication,**

**least privilege,**

**RBAC,**

**encryption,**

**hardening,**

**patch management,**

**audit logging,**

**Database Activity Monitoring,**

**backup**

ve **restore testing**

gibi kontrollerin birlikte uygulanmasını gerektirir.

Aynı zamanda database güvenliği yalnızca dış saldırganlara karşı yapılmaz.

Administrator hataları,

insider threat,

yanlış configuration,

uygulama zafiyetleri,

data corruption

ve hardware failure

gibi riskler de değerlendirilmelidir.

Kurumların hedefi yalnızca database'in çalışmasını sağlamak olmamalıdır.

Gerçek hedef:

**verinin doğru kişilere, doğru yetkiyle, doğru zamanda erişilebilir olması ve bütünlüğünün korunmasıdır.**

Bu nedenle güçlü bir database güvenlik yaklaşımı üç temel soruya cevap verebilmelidir:

#### Kim erişiyor?

#### Neye erişiyor?

#### Ne yaptı?

Bunlara bir dördüncü soru daha eklenmelidir:

#### Bir sorun olduğunda veriyi güvenli şekilde geri getirebiliyor muyuz?

Bu sorulara güvenilir cevap verebilen kurumlar database güvenliği açısından çok daha sağlam bir zemine sahip olur.