Database Hardening Nedir? Güvenli Veritabanı Yapılandırması Nasıl Yapılır?

Bir veritabanı sisteminin kurulmuş ve çalışıyor olması, güvenli olduğu anlamına gelmez.

Kurulum tamamlandıktan sonra;

default hesaplar,

gereksiz servisler,

açık portlar,

fazla yetkiler,

zayıf authentication yöntemleri,

eski protokoller,

eksik patch seviyeleri

ve yetersiz loglama

gibi birçok risk devam edebilir.

Bu nedenle kurumsal database sistemlerinde yalnızca installation değil, aynı zamanda:

Database Hardening

yani güvenli yapılandırma süreci uygulanmalıdır.

Database hardening, veritabanının ihtiyaç duyulmayan özelliklerini kapatmayı, erişim alanını daraltmayı, yetkileri sınırlandırmayı, güvenli authentication yöntemlerini uygulamayı ve sistemin saldırı yüzeyini mümkün olduğunca azaltmayı hedefler.

Temel yaklaşım şudur:

Kullanılmayan özellik kapalı olmalıdır.

Gereksiz kullanıcı bulunmamalıdır.

Gereksiz port açık olmamalıdır.

Gereksiz yetki verilmemelidir.

Bu prensipler basit görünse de gerçek dünya saldırılarında en kritik farkı çoğu zaman bu temel güvenlik kontrolleri oluşturur.

Database Hardening Nedir?

Database Hardening, veritabanı sisteminin güvenli çalışması için gereksiz servislerin, varsayılan yapılandırmaların ve fazla yetkilerin azaltılması sürecidir.

Amaç database'in saldırı yüzeyini küçültmektir.

Hardening kapsamında;

network,

authentication,

authorization,

operating system,

database configuration,

logging,

encryption,

patch management

birlikte değerlendirilir.

Hardening ile Security Aynı Şey midir?

Hardening, database security'nin önemli bir bölümüdür.

Ancak database security daha geniştir.

Örneğin;

DAM,

SIEM,

backup security,

incident response,

data classification

da database security kapsamına girer.

Hardening ise ağırlıklı olarak sistemin güvenli konfigürasyonuna odaklanır.

Database Security Baseline Nedir?

Security Baseline, database sistemlerinin minimum güvenlik standardını tanımlar.

Örneğin kurum şunu belirleyebilir:

Tüm database yönetim bağlantıları TLS kullanmalıdır.

Default hesaplar kapatılmalıdır.

DBA hesapları kişiye özel olmalıdır.

Audit aktif olmalıdır.

Production database internete açık olmamalıdır.

Bu kurallar kurumun database security baseline'ını oluşturur.

Neden Standart Bir Baseline Gerekir?

Kurumda 100 database sunucusu olduğunu düşünelim.

Her DBA farklı güvenlik ayarı kullanırsa;

bazı sunucular güvenli,

bazıları zayıf

hale gelir.

Standart baseline tüm sistemlerin minimum güvenlik seviyesinde olmasını sağlar.

CIS Benchmark Nedir?

CIS Benchmark, sistemlerin güvenli yapılandırılması için kullanılan yaygın rehberlerden biridir.

Database sistemleri için de farklı benchmark dokümanları bulunabilir.

Bu rehberler;

authentication,

network,

logging,

permissions,

configuration

gibi alanlarda öneriler sunar.

CIS Benchmark Otomatik Uygulanmalı mı?

Her öneri körü körüne production sisteme uygulanmamalıdır.

Çünkü;

application compatibility,

performance,

business requirement

etkilenebilir.

Bu nedenle baseline kurumun kendi ortamına göre uyarlanmalıdır.

Vendor Hardening Guide Nedir?

Database üreticileri kendi security configuration rehberlerini yayınlayabilir.

Örneğin;

PostgreSQL,

Microsoft SQL Server,

Oracle Database

için vendor best practice dokümanları kullanılabilir.

Database Hardening Nereden Başlamalı?

İlk adım:

Asset Inventory

olmalıdır.

Hangi database sistemlerinin bulunduğu bilinmeden hardening yapılamaz.

Envanterde;

DBMS türü,

version,

IP,

port,

owner,

criticality,

environment

bilgileri bulunabilir.

Production, Test ve Development Ayrılmalı mı?

Evet.

Production database'ler test veya development ortamlarından ayrı tutulmalıdır.

Aynı;

credential,

network,

admin account

kullanılmamalıdır.

Test Ortamı Neden Risklidir?

Test ortamları genellikle daha düşük güvenlik seviyesine sahiptir.

Eğer production verisi test ortamına kopyalanmışsa saldırgan buradan kritik veriye ulaşabilir.

Production Verisi Test Ortamında Kullanılmalı mı?

Mümkün olduğunca maskelenmiş veya anonimleştirilmiş veri kullanılmalıdır.

Gerçek müşteri verisinin doğrudan development ortamına kopyalanması önemli güvenlik ve gizlilik riski oluşturur.

Default Account Nedir?

Database kurulumu sırasında otomatik oluşturulan kullanıcı veya administrator hesaplarıdır.

Bazıları bilinen isimlere sahip olabilir.

Default Account Neden Risklidir?

Saldırgan kullanıcı adını tahmin etmek zorunda kalmaz.

Örneğin administrator account ismi biliniyorsa sadece password hedef alınabilir.

Bu nedenle kullanılmayan default hesaplar;

kapatılmalı,

silinmeli

veya güvenli hale getirilmelidir.

Sample Database ve Demo User'lar Kaldırılmalı mı?

Production ortamlarında kullanılmayan;

sample database,

demo user,

test schema

kaldırılmalıdır.

Bunlar saldırı yüzeyini artırabilir.

Database Administrator Hesabı Nasıl Olmalı?

DBA hesapları kişiye özel olmalıdır.

Örneğin:

dbadmin

gibi ortak hesap yerine:

dbadmin.ali

dbadmin.ayse

gibi kişisel hesaplar kullanılabilir.

Bu sayede audit mümkün olur.

Shared DBA Account Neden Risklidir?

10 DBA aynı account'u kullanıyorsa yapılan işlemin kim tarafından gerçekleştirildiği bilinemez.

Bu accountability problemini doğurur.

DBA Account ile Normal Kullanıcı Account Ayrılmalı mı?

Evet.

Aynı kişi;

normal kullanıcı

ve

privileged database administrator

için ayrı hesap kullanmalıdır.

Privileged Account Nedir?

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

DBA hesapları privileged account olarak kabul edilir.

Privileged Account Management Database Hardening'in Parçası mı?

Evet.

Privileged account'lar için;

MFA,

PAM,

JIT access,

session recording

gibi kontroller uygulanabilir.

Least Privilege Database Hardening İçin Neden Kritik?

Kullanıcıya yalnızca ihtiyacı kadar izin verilmelidir.

Bu yaklaşım saldırı etkisini azaltır.

Örneğin application yalnızca veri okuyacaksa;

DROP TABLE

yetkisine ihtiyacı yoktur.

Application Database User Neden Minimum Yetkili Olmalı?

Web uygulaması SQL Injection zafiyeti içerirse saldırgan application'ın database yetkilerini kullanabilir.

Application account çok yetkiliyse saldırının etkisi büyür.

Application Account DBA Olmalı mı?

Genellikle hayır.

Bu en ciddi database security hatalarından biridir.

Web application hesabının database administrator yetkisine ihtiyacı çoğu durumda yoktur.

Read-Only Account Nedir?

Sadece veri okuma yetkisine sahip kullanıcıdır.

Reporting ve BI sistemlerinde kullanılabilir.

SELECT Yetkisi Bile Riskli Olabilir mi?

Evet.

Kullanıcı tüm customer tablosuna SELECT yetkisine sahipse milyonlarca kayıt çekebilir.

Bu nedenle tablo ve kolon bazlı yetkilendirme değerlendirilebilir.

Schema-Based Authorization Nedir?

Kullanıcıların sadece belirli schema'lara erişebilmesidir.

Bu yöntem application ve ekip bazlı ayrım sağlar.

Row-Level Security Nedir?

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

Örneğin bir bölge yöneticisi sadece kendi bölgesindeki müşterileri görebilir.

Column-Level Security Nedir?

Belirli kolonlara erişimin sınırlandırılmasıdır.

Örneğin kullanıcı;

müşteri adı

görebilir

ancak

TCKN

göremeyebilir.

Database Authentication Nedir?

Kullanıcının kimliğinin doğrulanmasıdır.

Authentication yöntemleri platforma göre değişebilir.

Password-Based Authentication Güvenli midir?

Güçlü password policy ile kullanılabilir.

Ancak mümkün olduğunda merkezi identity veya certificate tabanlı yöntemler değerlendirilebilir.

Güçlü Database Password Nasıl Olmalı?

Password;

uzun,

benzersiz,

tahmin edilmesi zor

olmalıdır.

Aynı password farklı sistemlerde kullanılmamalıdır.

Password Rotation Gerekli mi?

Risk bazlı uygulanabilir.

Özellikle;

DBA,

service account,

privileged account

credential'ları düzenli olarak kontrol edilmelidir.

Password Expiry Her Service Account İçin Uygun mu?

Her zaman değil.

Otomatik uygulamalar için plansız expiry outage oluşturabilir.

Bu nedenle secret management ve controlled rotation kullanılmalıdır.

Service Account Nedir?

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

Service Account Interactive Login Yapmalı mı?

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

Service account normal kullanıcı gibi desktop login yapmamalıdır.

Service Account Shared Olmalı mı?

Farklı uygulamalar mümkün olduğunca ayrı service account kullanmalıdır.

Bu hem least privilege hem audit açısından önemlidir.

Hard-Coded Database Password Neden Risklidir?

Source code içerisinde password bulunursa;

Git repository,

developer laptop,

CI/CD log

üzerinden credential sızabilir.

Secret Management Nedir?

Password ve API key gibi bilgilerin güvenli vault sisteminde tutulmasıdır.

Application ihtiyaç olduğunda secret'ı kontrollü şekilde alır.

Database Connection String Güvenliği

Connection string içerisinde;

server,

username,

password

bilgileri olabilir.

Bu nedenle application configuration dosyaları korunmalıdır.

Environment Variable Kullanmak Yeterli mi?

Hard-code etmeye göre daha iyi olabilir.

Ancak environment variable da okunabilir.

Kritik ortamlarda secret manager tercih edilebilir.

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

Genellikle hayır.

Production database server'ın doğrudan public internet üzerinden erişilebilir olması risklidir.

Database Network Access Nasıl Sınırlandırılmalı?

Örneğin sadece;

application server,

backup server,

management network

database'e erişebilir.

IP Allow-List Nedir?

Sadece belirli IP adreslerinin database'e bağlanabilmesine izin verilmesidir.

Firewall Database Hardening İçin Yeterli mi?

Hayır.

Firewall önemli bir katmandır.

Ancak database kendi authentication ve authorization kontrollerini de uygulamalıdır.

Defense in Depth Neden Gereklidir?

Tek bir kontrol başarısız olabilir.

Örneğin firewall yanlış yapılandırılırsa database authentication hâlâ koruma sağlamalıdır.

Database VLAN Nedir?

Database sunucularının ayrı network segmentinde tutulmasıdır.

Örneğin:

User Network

↓

Web Tier

↓

Application Tier

↓

Database Tier

şeklinde katmanlı mimari kurulabilir.

User VLAN Database'e Doğrudan Erişmeli mi?

Genellikle hayır.

Kullanıcıların database'e doğrudan bağlantısı minimum seviyede olmalıdır.

Database Management Network Nedir?

DBA yönetim işlemlerinin yapıldığı ayrı ve daha güvenli network segmentidir.

Bastion Host Kullanılabilir mi?

Evet.

DBA önce bastion host'a bağlanıp oradan database'e erişebilir.

Bu doğrudan erişimi azaltır.

VPN Database Yönetimi İçin Yeterli mi?

VPN önemli bir kontrol olabilir.

Ancak;

MFA,

RBAC,

PAM

ile birlikte kullanılmalıdır.

ZTNA Database Yönetiminde Kullanılabilir mi?

Evet.

Zero Trust Network Access, kullanıcı ve cihaz doğrulamasına göre kontrollü erişim sağlayabilir.

Database TLS Nedir?

Client ile database arasındaki bağlantının şifrelenmesini sağlar.

TLS Kullanılmazsa Ne Olur?

Database trafiği network üzerinde açık taşınabilir.

Bu trafik içerisinde;

query,

username,

hassas data

bulunabilir.

Eski TLS Versiyonları Kapatılmalı mı?

Güncel güvenlik gereksinimlerine göre eski ve zayıf protokoller kapatılmalıdır.

Database Certificate Yönetimi Neden Önemlidir?

TLS certificate süresi dolarsa application database'e bağlanamayabilir.

Bu nedenle expiration monitoring yapılmalıdır.

Self-Signed Certificate Kullanılabilir mi?

Teknik olarak kullanılabilir.

Ancak trust management ve validation zayıf olabilir.

Kurumsal PKI tercih edilebilir.

Database Encryption at Rest Hardening'in Parçası mı?

Evet.

Disk veya database file ele geçirilirse verinin okunmasını zorlaştırır.

TDE Database Hardening İçin Yeterli mi?

Hayır.

TDE sadece belirli risklere karşı koruma sağlar.

DBA account compromise durumunda yetkili kullanıcı veriyi okuyabilir.

Column Encryption Neden Kullanılır?

Çok hassas alanların ayrıca korunmasını sağlar.

Örneğin;

TCKN,

kart bilgisi,

sağlık verisi

için kullanılabilir.

Database Backup Encryption Neden Hardening'e Dahildir?

Production database şifreli olsa bile backup şifresizse veri sızabilir.

Bu nedenle backup da encryption politikası kapsamına alınmalıdır.

Database Audit Hardening'in Parçası mı?

Evet.

Güvenli database yalnızca erişimi engellemez.

Erişimleri kayıt altına da alır.

Database Audit Neleri Kaydetmeli?

Risk bazlı olarak;

login,

failed login,

privilege change,

user creation,

DDL operation,

sensitive table access

loglanabilir.

Her Query Audit Edilmeli mi?

Her zaman uygun olmayabilir.

Çok yüksek log hacmi oluşabilir.

Bu nedenle kritik veri ve privileged user aktiviteleri önceliklendirilebilir.

DBA Aktivitesi İzlenmeli mi?

Evet.

DBA çok yüksek yetkiye sahip olduğu için aktiviteleri audit edilmelidir.

DBA Audit Log'u Silebilir mi?

Mümkünse audit loglar bağımsız sisteme aktarılmalıdır.

Örneğin SIEM veya immutable storage kullanılabilir.

Database Logları SIEM'e Gönderilmeli mi?

Kritik database'lerde evet.

SIEM;

failed login,

privilege escalation,

suspicious query,

bulk data access

gibi olayları korele edebilir.

Failed Login Monitoring Neden Önemlidir?

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

brute-force,

credential stuffing,

yanlış configuration

göstergesi olabilir.

Database Brute Force Nasıl Sınırlandırılır?

Genel savunma yaklaşımı olarak;

network restriction,

account lockout,

MFA,

monitoring

uygulanabilir.

Account Lockout Her Service Account İçin Kullanılmalı mı?

Dikkatli uygulanmalıdır.

Bir saldırgan lockout mekanizmasını kullanarak kritik application service account'u kilitleyebilir.

Bu nedenle risk bazlı politika gereklidir.

Database Error Message'ları Hassas Bilgi Sızdırabilir mi?

Evet.

Detaylı error message;

table name,

schema,

database version

gibi bilgiler gösterebilir.

Application kullanıcıya minimum hata bilgisi göstermelidir.

Database Version Bilgisi Gizlenmeli mi?

Gereksiz banner ve version disclosure saldırganın hedef belirlemesini kolaylaştırabilir.

Mümkün olduğu ölçüde gereksiz bilgi ifşası azaltılmalıdır.

Unused Feature Disablement Nedir?

Kullanılmayan database özelliklerinin kapatılmasıdır.

Neden Gereksiz Feature Kapatılır?

Her feature;

code,

port,

permission

ekleyebilir.

Bu saldırı yüzeyini büyütür.

Database Extension ve Plugin'ler Riskli mi?

Evet.

Gereksiz veya eski extension'lar vulnerability oluşturabilir.

PostgreSQL Extension'ları Kontrol Edilmeli mi?

Evet.

Sadece gerçekten gerekli extension'lar kullanılmalıdır.

MSSQL Extended Feature'lar Kontrol Edilmeli mi?

Evet.

Kullanılmayan advanced feature veya integration mekanizmaları kapalı tutulabilir.

Oracle Optional Component'lar Kontrol Edilmeli mi?

Evet.

Kullanılmayan component'lar saldırı yüzeyini artırabilir.

Database OS Hardening Nedir?

Database server'ın işletim sisteminin de güvenli yapılandırılmasıdır.

Database Server Üzerinde Gereksiz Yazılım Olmalı mı?

Hayır.

Database server mümkün olduğunca dedicated olmalıdır.

Database Server'da Web Browser Kullanılmalı mı?

Genellikle hayır.

Server üzerinde internet browsing malware ve phishing riskini artırır.

Database Server E-posta İçin Kullanılmalı mı?

Hayır.

Database server yalnızca kendi görevini yapmalıdır.

Local Administrator Sayısı Sınırlandırılmalı mı?

Evet.

Database server üzerinde local admin yetkisi minimum kişide bulunmalıdır.

OS Patch ile Database Patch Aynı mı?

Hayır.

Hem işletim sistemi hem DBMS patch edilmelidir.

Database Patch Management Hardening'in Temel Parçası mı?

Evet.

Eski database versiyonları bilinen vulnerability'lere sahip olabilir.

Patch Öncesi Neden Test Yapılır?

Application compatibility problemi oluşabilir.

Bu nedenle patch önce staging ortamında test edilebilir.

Emergency Security Patch Nasıl Yönetilmeli?

Kritik vulnerability durumunda hızlandırılmış change süreci uygulanabilir.

Ancak backup ve rollback planı bulunmalıdır.

Database Vulnerability Assessment Nedir?

Database üzerindeki;

eksik patch,

yanlış configuration,

zayıf account,

permission

gibi risklerin değerlendirilmesidir.

Vulnerability Scanner Database Credential Kullanmalı mı?

Credentialed scan daha derin configuration kontrolü sağlayabilir.

Ancak production database'te güvenli ve kontrollü tasarlanmalıdır.

Hardening Kontrolü Tek Seferlik mi?

Hayır.

Zamanla;

yeni kullanıcı,

yeni role,

configuration change,

upgrade

hardening seviyesini bozabilir.

Bu nedenle periyodik assessment yapılmalıdır.

Configuration Drift Nedir?

Sistemin zaman içerisinde security baseline'dan uzaklaşmasıdır.

Örneğin ilk kurulumda port kapalıdır.

Altı ay sonra troubleshooting için açılır ve unutulur.

Bu configuration drift'tir.

Configuration Compliance Nedir?

Database'in kurum security baseline'ına uyup uymadığının kontrol edilmesidir.

Automated Compliance Scan Kullanılabilir mi?

Evet.

Database configuration periyodik olarak otomatik kontrol edilebilir.

Database Hardening ve Change Management İlişkisi

Hardening ayarlarının izinsiz değişmemesi gerekir.

Bu nedenle kritik configuration değişiklikleri change sürecine tabi olmalıdır.

Database Configuration Backup Alınmalı mı?

Evet.

Database'in;

configuration,

security setting,

user-role mapping

gibi bilgilerinin recovery planı olmalıdır.

Hardening Sonrası Uygulama Testi Yapılmalı mı?

Kesinlikle.

Bir güvenlik ayarı application'ın çalışmasını bozabilir.

Bu nedenle functional validation gerekir.

Hardening Performance'ı Etkileyebilir mi?

Bazı kontroller ek overhead oluşturabilir.

Örneğin yoğun audit loglama performansı etkileyebilir.

Ancak çözüm güvenliği kapatmak değil doğru tuning yapmaktır.

Security ile Performance Arasında Denge Nasıl Kurulur?

Risk bazlı karar verilmelidir.

Kritik verinin korunması için gerekli security control yalnızca küçük performance maliyeti oluşturuyorsa kaldırılmamalıdır.

Database Hardening ve High Availability

HA node'larının tamamında aynı security baseline uygulanmalıdır.

Primary güvenli, secondary zayıf olmamalıdır.

DR Database Hardening Unutulmamalı mı?

Hayır.

Disaster Recovery ortamı da production kadar güvenli olmalıdır.

DR Ortamı Neden Bazen Daha Risklidir?

Sürekli kullanılmadığı için;

patch,

password,

configuration

kontrolleri unutulabilir.

Saldırgan açısından kolay hedef olabilir.

Backup Database Server Hardening Gerekli mi?

Backup repository ve management server'ları da kritik sistem olarak değerlendirilmelidir.

Database Backup Account Minimum Yetkili Olmalı mı?

Evet.

Backup service account yalnızca ihtiyaç duyduğu izinlere sahip olmalıdır.

Database Backup Ayrı Credential Kullanmalı mı?

Mümkün olduğunca evet.

Production DBA account ile backup service account aynı olmamalıdır.

Database Replication Account Nasıl Korunmalı?

Replication account;

sadece replication için gerekli yetkiye sahip,

network olarak sınırlandırılmış,

güçlü credential kullanan

hesap olmalıdır.

Cloud Database Hardening Nedir?

Managed database kullanılsa bile müşteri tarafında;

IAM,

network,

encryption,

audit,

backup

ayarları hardening kapsamındadır.

Cloud Database Public Endpoint Kapatılmalı mı?

İhtiyaç yoksa evet.

Private endpoint kullanılması saldırı yüzeyini azaltabilir.

Cloud IAM Database Güvenliği İçin Neden Kritik?

Cloud administrator hesabı database erişimini değiştirebilir.

Bu nedenle cloud IAM de database security'nin parçasıdır.

Cloud Database Security Group Nedir?

Database network erişimini kontrol eden firewall benzeri rule set'idir.

Gereksiz geniş CIDR izinleri verilmemelidir.

0.0.0.0/0 Database İçin Neden Risklidir?

Bu tanım tüm internetten erişime izin verebilir.

Production database için ciddi risk oluşturur.

Cloud Database Encryption Default Olarak Açık Olsa Yeterli mi?

Encryption'ın;

key ownership,

rotation,

backup encryption

boyutları da değerlendirilmelidir.

Key Management Database Hardening'in Parçası mı?

Evet.

Encryption key yanlış korunursa encryption kontrolü anlamını kaybedebilir.

KMS Nedir?

Key Management Service, encryption key'lerin merkezi olarak yönetilmesini sağlar.

HSM ile KMS Arasındaki İlişki

KMS logical key management sağlar.

Bazı KMS sistemleri arka planda HSM kullanabilir.

Database Hardening ve Data Classification

Hangi database'in hangi hassas veriyi tuttuğu bilinmelidir.

Daha hassas veri daha güçlü security baseline gerektirebilir.

Her Database Aynı Hardening Seviyesinde Olmalı mı?

Minimum baseline aynı olabilir.

Ancak kritik database'lerde ek kontroller uygulanabilir.

Tier Bazlı Database Hardening

Örneğin:

Tier 1 – Kritik Database

MFA + PAM + DAM + Encryption + SIEM + Immutable Backup

Tier 2 – Önemli Database

RBAC + Encryption + Audit + SIEM + Backup

Tier 3 – Düşük Kritik

Minimum security baseline + Backup

gibi risk bazlı model oluşturulabilir.

Sensitive Data Discovery Hardening'i Nasıl Etkiler?

Database içinde TCKN, IBAN veya sağlık verisi keşfedilirse ek;

encryption,

masking,

audit

uygulanabilir.

Data Masking Database Hardening'in Parçası mı?

Özellikle non-production ortamlarında evet.

Dynamic Data Masking Nedir?

Yetkisiz kullanıcının hassas veriyi maskelenmiş görmesini sağlar.

Masking Encryption Yerine Geçer mi?

Hayır.

Masking görüntüyü sınırlar.

Encryption verinin kendisini korur.

Database Hardening ve SQL Injection

SQL Injection çoğunlukla application zafiyetidir.

Ancak database hardening saldırının etkisini sınırlar.

SQL Injection Sonrası Least Privilege Neden Önemlidir?

Application account sadece SELECT yetkisine sahipse saldırganın etkisi daha sınırlı olabilir.

Ancak DBA yetkisi varsa sonuç çok daha ciddi olabilir.

Stored Procedure Yetkileri Kontrol Edilmeli mi?

Evet.

Stored procedure üzerinden privilege escalation riski oluşabilir.

Dynamic SQL Riskli mi?

Güvensiz kullanıcı girdisiyle birleştirilirse SQL Injection riski oluşturabilir.

Database Hardening ve API Security İlişkisi

API backend database'e erişiyorsa API compromise database riskine dönüşebilir.

Bu nedenle application identity ve minimum database permission önemlidir.

Database Audit ile DAM Arasındaki Fark

Audit database'in kendi kayıt mekanizmasıdır.

DAM ise database activity'yi merkezi ve güvenlik odaklı izleyen ayrı bir çözüm olabilir.

DAM Hardening Yerine Geçer mi?

Hayır.

DAM saldırı tespiti sağlar.

Hardening ise saldırı yüzeyini azaltır.

İkisi birlikte kullanılmalıdır.

Database Hardening ve SIEM

Database security event'leri SIEM'e gönderilebilir.

Örneğin:

Admin Login

Privilege Granted

User Created

Failed Login

Audit Disabled

alarm üretilebilir.

Audit Disable Edilirse Alarm Üretilmeli mi?

Evet.

Audit mekanizmasının kapatılması kritik security event olabilir.

Database Administrator Audit'i Devre Dışı Bırakabilmeli mi?

Mümkün olduğunca bu yetki ayrılmalıdır.

Separation of Duties uygulanabilir.

Separation of Duties Nedir?

Tek kullanıcının hem tüm işlemleri yapıp hem izlerini silememesidir.

Security Auditor Rolü Oluşturulabilir mi?

Evet.

Auditor sadece log ve security configuration okuyabilir.

Database değiştirme yetkisi olmayabilir.

Database Hardening ve Insider Threat

Kötü niyetli çalışanlar meşru credential kullanabilir.

Bu nedenle yalnızca authentication yeterli değildir.

Audit ve behavior monitoring gerekir.

Bulk Data Export İzlenmeli mi?

Evet.

Milyonlarca kayıt çekilmesi normal kullanıcı davranışı olmayabilir.

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

Evet.

Database dump tüm veriyi tek dosyada dışarı çıkarabilir.

Bu yüksek riskli yetkidir.

Backup File Yetkileri Sınırlandırılmalı mı?

Evet.

Database backup dosyası production verisinin tam kopyası olabilir.

Database Hardening ve KVKK

Kişisel veri bulunan database'lerde hardening;

yetkisiz erişimin önlenmesi,

loglama,

şifreleme,

erişim sınırlandırma

açısından önemlidir.

Database Hardening ve ISO/IEC 27001

ISO/IEC 27001 perspektifinde;

access control,

secure configuration,

logging,

cryptography,

vulnerability management

database hardening ile doğrudan ilişkilidir.

Database Hardening ve PCI DSS

Kart verisi işlenen database'lerde;

minimum privilege,

audit,

encryption,

patching

gibi kontroller daha kritik hale gelir.

Database Hardening Checklist

Kurumsal bir checklist şu başlıkları içerebilir:

• Asset inventory
• Supported database version
• Security patches
• Default account review
• Unique DBA accounts
• Least Privilege
• RBAC
• Service account review
• Password policy
• Secret management
• MFA/PAM
• Network segmentation
• Public access control
• Firewall allow-list
• TLS
• Encryption at Rest
• Backup encryption
• Audit logging
• SIEM integration
• Unused feature removal
• OS hardening
• Vulnerability assessment
• Configuration compliance
• Backup and restore test

PostgreSQL Hardening İçin Temel Yaklaşım

PostgreSQL ortamında özellikle;

pg_hba.conf erişim kuralları,

role ve permission yönetimi,

TLS,

extension kontrolü,

logging,

superuser hesapları,

network binding

önemlidir.

Ancak ayarlar application ihtiyacına göre tasarlanmalıdır.

PostgreSQL Superuser Kullanımı Sınırlandırılmalı mı?

Evet.

Günlük application işlemleri superuser ile yapılmamalıdır.

pg_hba.conf Neden Kritik?

PostgreSQL'e hangi kullanıcıların hangi network'ten ve hangi authentication yöntemiyle bağlanabileceğini belirleyen temel kontrol noktalarından biridir.

PostgreSQL Listen Address Kontrol Edilmeli mi?

Evet.

Database sadece gerekli network interface'lerde dinlemelidir.

MSSQL Hardening İçin Temel Yaklaşım

MSSQL ortamında;

login,

server role,

database role,

SQL Server authentication,

Windows authentication,

TLS,

audit,

extended feature'lar

kontrol edilmelidir.

SA Hesabı Neden Kritik?

MSSQL'deki yüksek yetkili administrator hesabıdır.

Kullanılmıyorsa güvenli şekilde devre dışı bırakılması veya güçlü şekilde korunması değerlendirilebilir.

Windows Authentication Tercih Edilebilir mi?

Kurumsal identity entegrasyonu açısından avantaj sağlayabilir.

Ancak AD güvenliği de kritik hale gelir.

Oracle Hardening İçin Temel Yaklaşım

Oracle ortamlarında;

privileged users,

listener security,

roles,

profiles,

audit,

TDE,

patch level

önemlidir.

Oracle Listener Neden Korunmalı?

Client bağlantılarının database'e ulaşmasını sağlayan önemli network bileşenidir.

Gereksiz network erişimi sınırlandırılmalıdır.

SYS ve SYSTEM Hesapları Günlük Kullanılmalı mı?

Hayır.

Yüksek yetkili hesaplar yalnızca gerekli yönetim işlemlerinde kullanılmalıdır.

Database Hardening Projesi Nasıl Yürütülür?

Örnek süreç:

• Database inventory çıkarılır.
• Kritik sistemler sınıflandırılır.
• Mevcut configuration assessment yapılır.
• Security baseline oluşturulur.
• Gap'ler belirlenir.
• Risk analizi yapılır.
• Test ortamında hardening uygulanır.
• Application testleri yapılır.
• Production'a change ile uygulanır.
• Compliance düzenli izlenir.

Hardening Gap Analysis Nedir?

Mevcut configuration ile hedef security baseline arasındaki farkların belirlenmesidir.

Gap'ler Nasıl Önceliklendirilir?

Örneğin:

Public database exposure → Critical

Default admin password → Critical

Eksik audit → High

Minor logging ayarı → Medium

gibi risk bazlı sınıflandırılabilir.

Tüm Hardening Maddeleri Aynı Anda Uygulanmalı mı?

Her zaman değil.

Kritik uygulamalarda kontrollü fazlara bölmek daha güvenli olabilir.

Hardening Sonrası Security Validation Nasıl Yapılır?

Configuration tekrar taranır.

Network erişimi doğrulanır.

Kullanıcı yetkileri test edilir.

Application'ın çalıştığı doğrulanır.

Logların üretildiği kontrol edilir.

Database Hardening KPI'ları Nelerdir?

Örneğin:

Security Baseline Compliance

Patch Compliance

Privileged Account Count

Public Database Exposure

Audit Coverage

Encrypted Database Coverage

Open Critical Finding

Security Baseline Compliance Nedir?

Database'lerin belirlenen security standardına uyum oranıdır.

Örneğin 100 database'in 92'si baseline'a uyuyorsa:

%92 compliance

olarak raporlanabilir.

Public Database Exposure KPI Olabilir mi?

Evet.

Örneğin hedef:

0 Critical Production Database Publicly Exposed

olabilir.

Privileged Account Sayısı İzlenmeli mi?

Evet.

Gereksiz privilege zamanla birikebilir.

Database Hardening Ne Sıklıkla Kontrol Edilmeli?

Periyodik olarak ve;

major upgrade,

migration,

security incident,

configuration change

sonrasında kontrol edilmelidir.

Database Hardening'de En Sık Yapılan Hatalar

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

• Production database'i internete açmak
• Default account bırakmak
• Ortak DBA hesabı kullanmak
• Application hesabına DBA yetkisi vermek
• Her network'ten database erişimine izin vermek
• TLS kullanmamak
• Eski database sürümü kullanmak
• Gereksiz extension ve feature bırakmak
• Backup'ı şifresiz saklamak
• Audit'i kapalı tutmak
• DBA aktivitelerini izlememek
• Hard-coded database password kullanmak
• Production credential'ı test ortamında kullanmak
• Public cloud security group'u aşırı geniş açmak
• Security baseline oluşturmamak

Database Hardening İçin Yönetimin Sorması Gereken Sorular

Yönetim veya BT yöneticileri şu soruların cevaplarını alabilmelidir:

Kaç production database'imiz var?

Bunlardan kaçı public erişilebilir?

Kaçında destek dışı database sürümü kullanılıyor?

Kaç privileged DBA hesabımız var?

Database bağlantıları şifreli mi?

Database backup'ları şifreli mi?

Audit aktif mi?

Database güvenlik logları merkezi olarak izleniyor mu?

Son hardening assessment ne zaman yapıldı?

Bu sorular kurumun database security posture'unu ölçmek için değerlidir.

Sık Sorulan Sorular

Database hardening nedir?

Database sisteminin gereksiz özelliklerden, fazla yetkilerden ve zayıf yapılandırmalardan arındırılarak daha güvenli hale getirilmesidir.

Database hardening neden gereklidir?

Default configuration çoğu zaman kurumun güvenlik ihtiyacına göre optimize edilmemiştir.

CIS Benchmark nedir?

Database ve diğer sistemlerin güvenli configuration'ı için kullanılan yaygın security baseline rehberlerinden biridir.

Database portu internete açık olmalı mı?

Kritik production database'ler için genellikle hayır. Erişim sadece gerekli application ve management network'lerinden sağlanmalıdır.

Application user DBA olabilir mi?

Çoğu durumda olmamalıdır. Minimum yetki kullanılmalıdır.

Database TLS gerekli mi?

Hassas verinin network üzerinde korunması için güçlü şekilde önerilir.

Database backup şifrelenmeli mi?

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

Database administrator aktiviteleri izlenmeli mi?

Evet. Privileged account aktiviteleri audit edilmelidir.

Hardening bir kere yapılıp bırakılır mı?

Hayır. Configuration drift nedeniyle periyodik olarak doğrulanmalıdır.

Database hardening performansı bozar mı?

Bazı güvenlik kontrolleri ek yük oluşturabilir ancak doğru tuning ile güvenlik ve performans dengelenmelidir.

Sonuç: Database Hardening Saldırıyı Başlamadan Zorlaştırır

Siber güvenlikte yalnızca saldırıyı tespit etmeye odaklanmak yeterli değildir.

Daha güçlü yaklaşım:

saldırganın kullanabileceği yolları baştan azaltmaktır.

Database Hardening'in temel amacı budur.

Gereksiz account yoksa saldırılacak kullanıcı sayısı azalır.

Database public değilse internet tabanlı saldırı yüzeyi küçülür.

Application minimum yetkiliyse SQL Injection saldırısının etkisi sınırlandırılır.

TLS kullanılıyorsa network üzerindeki veri korunur.

Audit açıksa şüpheli aktiviteler araştırılabilir.

DBA hesapları PAM ve MFA ile korunuyorsa privileged account compromise daha zor hale gelir.

Bu nedenle güçlü bir database hardening yaklaşımı;

Secure Configuration,

Least Privilege,

RBAC,

Network Segmentation,

TLS,

Encryption,

Patch Management,

Audit Logging,

Secret Management

ve Security Monitoring

kontrollerini birlikte ele almalıdır.

En kritik prensip ise oldukça basittir:

Database yalnızca çalışması için ihtiyaç duyduğu erişime, özelliğe ve yetkiye sahip olmalıdır.

Bunun dışındaki her açık port, her kullanılmayan account, her gereksiz privilege ve her etkin fakat kullanılmayan özellik saldırı yüzeyinin bir parçasıdır.

Bu nedenle kurumsal database security'nin güçlü temeli:

Minimum Surface + Minimum Privilege + Maximum Visibility

yaklaşımıdır.

Yani:

Minimum saldırı yüzeyi,

minimum yetki

ve maksimum görünürlük.

Gerçek Database Hardening bu üç prensip üzerine kurulmalıdır.