Kurumsal Database Güvenlik Politikası Nasıl Oluşturulur? ISO 27001, KVKK ve Regülasyonlar

Veritabanı güvenliği yalnızca teknik ekiplerin konusu değildir.

Bir kurumda database güvenliği;

bilgi güvenliği,

BT operasyonları,

yazılım geliştirme,

hukuk,

risk yönetimi,

iç denetim,

iş sürekliliği

ve üst yönetimin ortak sorumluluğudur.

Çünkü database içerisinde yalnızca teknik kayıtlar bulunmaz.

Kurumun;

müşteri bilgileri,

personel verileri,

finansal kayıtları,

ticari sırları,

kimlik bilgileri,

işlem geçmişleri,

kritik operasyonel verileri

veritabanlarında saklanır.

Bu nedenle database güvenliği yalnızca:

“Firewall açık mı?”

veya

“DBA password'ü güçlü mü?”

sorularıyla sınırlandırılamaz.

Kurumsal yaklaşım şu sorulara cevap vermelidir:

Kaç database var?

Hangileri kritik?

Hangi veriler hassas?

Kimler erişebiliyor?

Hangi hesaplar privileged?

Encryption var mı?

Audit aktif mi?

Backup alınabiliyor mu?

Restore test edildi mi?

Patch seviyesi güncel mi?

Cloud database'ler dahil mi?

Third-party erişimleri kontrol ediliyor mu?

Incident olduğunda ne yapılacağı biliniyor mu?

Bu soruların tamamı:

Kurumsal Database Güvenlik Politikası

içerisinde sistematik hale getirilmelidir.

Database Security Policy Nedir?

Database Security Policy, kurumun veritabanlarını hangi güvenlik prensipleri, teknik kontroller ve yönetişim kurallarıyla koruyacağını belirleyen politika dokümanıdır.

Bu politika yalnızca DBA ekibine yönelik olmamalıdır.

Aynı zamanda;

application owner,

security team,

system administrator,

developer,

internal audit,

business owner

rollerinin sorumluluklarını da tanımlamalıdır.

Database Güvenlik Politikası Neden Gereklidir?

Politika olmadığı durumda güvenlik kişisel tercihlere dönüşebilir.

Bir DBA TLS açar.

Diğeri açmaz.

Bir ekip audit kullanır.

Diğer ekip kapatır.

Bir database günlük backup alır.

Diğeri haftalık alır.

Sonuçta kurum genelinde tutarsız bir güvenlik seviyesi oluşur.

Politikanın Temel Amacı Nedir?

Amaç minimum database security standardı oluşturmaktır.

Örneğin:

“Tüm kritik production database'ler encryption, audit, backup, access control ve patch management kapsamına alınmalıdır.”

gibi kurallar tanımlanabilir.

Database Security Policy ile Procedure Arasındaki Fark Nedir?

Policy:

Ne yapılacağını ve hangi prensiplerin geçerli olduğunu

tanımlar.

Procedure:

Nasıl yapılacağını

tanımlar.

Örnek

Policy:

Privileged database access kişiye özel hesaplarla yapılmalıdır.

Procedure:

PAM üzerinden access request açılır, manager onayı alınır ve JIT erişim sağlanır.

Standard Nedir?

Politikayı teknik olarak detaylandıran zorunlu gereksinimlerdir.

Örneğin:

Database TLS kullanılmalı.

Audit minimum event listesi tanımlı olmalı.

Production database public internet'e açık olmamalı.

Guideline Nedir?

Zorunlu olmayan ancak önerilen uygulamalardır.

Database Security Governance Nedir?

Database güvenliğinin roller, süreçler, kontroller ve raporlama mekanizmalarıyla yönetilmesidir.

Database Security Governance Neden Önemlidir?

Çünkü teknik kontrol bir kez kurulabilir.

Ancak governance yoksa zamanla;

yeni kullanıcılar eklenir,

yetkiler büyür,

patch'ler gecikir,

audit kapanır,

backup başarısız olur.

Bu nedenle güvenlik sürekli yönetilmelidir.

İlk Adım: Database Inventory

Güvenemediğiniz değil, bilmediğiniz sistem en büyük risktir.

Bu nedenle ilk adım:

database inventory

oluşturmaktır.

Database Inventory Neleri İçermeli?

Örneğin:

Database Name

Platform

Version

Server

Environment

Owner

Business Service

Criticality

Data Classification

Backup Status

Encryption Status

Audit Status

Neden Database Owner Tanımlanmalı?

Her database'in teknik ve iş sahibi bilinmelidir.

Sahipsiz database'lerde access review ve risk kararları zorlaşır.

Technical Owner Kimdir?

Database operasyonundan sorumlu ekip veya kişidir.

Business Owner Kimdir?

Database içerisindeki verinin iş açısından sorumluluğunu taşıyan kişidir.

Data Owner Nedir?

Verinin hangi amaçla kullanıldığı ve kimlerin erişmesi gerektiği konusunda karar verebilen iş rolüdür.

Database Owner ile Data Owner Aynı mı?

Her zaman değil.

DBA sistemi yönetebilir.

Ancak müşteri verisinin kim tarafından görülmesi gerektiğine iş birimi karar vermelidir.

Shadow Database Nedir?

Resmi envanter dışında çalışan database sistemidir.

Shadow Database Neden Risklidir?

Bu sistem;

backup,

patch,

audit,

security monitoring

kapsamı dışında kalabilir.

Database Discovery Sürekli Yapılmalı mı?

Evet.

Network ve cloud environment'ta yeni database instance'ları periyodik olarak tespit edilebilir.

Database Criticality Classification Nedir?

Database'lerin iş etkisine göre sınıflandırılmasıdır.

Örnek Criticality Seviyeleri

Tier 1 – Critical

Tier 2 – High

Tier 3 – Medium

Tier 4 – Low

Criticality Ne İşe Yarar?

Security ve recovery kontrollerinin önceliğini belirler.

Tier 1 Database İçin Ne Beklenir?

Örneğin;

yüksek availability,

düşük RPO,

audit,

encryption,

DAM,

immutable backup

zorunlu olabilir.

Data Classification Nedir?

Database içerisindeki verilerin hassasiyetine göre sınıflandırılmasıdır.

Örnek Data Classification

Public

Internal

Confidential

Restricted

Restricted Data Nedir?

En yüksek hassasiyete sahip veri sınıfıdır.

Örneğin;

kimlik,

finans,

sağlık,

credential

verileri bu kapsama alınabilir.

Data Classification Database Security'yi Nasıl Etkiler?

Veri ne kadar hassassa;

encryption,

audit,

access control,

monitoring

seviyesi artırılabilir.

Database Security Policy'de Access Control

Access control politikanın en kritik bölümlerinden biridir.

Temel Access Control Prensibi Nedir?

Need-to-Know + Least Privilege

Need-to-Know Nedir?

Kullanıcının sadece iş görevi için gerçekten ihtiyaç duyduğu veriye erişmesidir.

Least Privilege Nedir?

Kullanıcının sadece gerekli minimum yetkiye sahip olmasıdır.

Role-Based Access Control – RBAC

Database permission'larının kişilere tek tek verilmesi yerine iş rollerine göre yönetilmesidir.

RBAC Policy'de Nasıl Tanımlanmalı?

Örneğin:

Developer → Development database

Support → Limited production read

DBA → Administrative access

Auditor → Audit read

Privileged Access Policy Nedir?

DBA, SYS, sysadmin veya superuser gibi yüksek yetkili hesapların nasıl yönetileceğini belirler.

Privileged Hesaplar İçin Neler Zorunlu Olabilir?

MFA

PAM

JIT

Session Recording

Personal Account

Approval

Shared DBA Account Yasaklanmalı mı?

Kritik production ortamlarında kişiye özel account tercih edilmelidir.

Break-Glass Account Policy Nedir?

Acil durumda kullanılacak yüksek yetkili hesabın kullanım kurallarıdır.

Break-Glass Hesabı Nasıl Yönetilmeli?

Güçlü şekilde korunmalı.

Normalde kullanılmamalı.

Kullanıldığında alert üretmeli.

Sonrasında review yapılmalıdır.

Joiner-Mover-Leaver Süreci Database İçin Uygulanmalı mı?

Evet.

Yeni çalışan gelir.

Rol değişir.

İşten ayrılır.

Database permission buna göre güncellenmelidir.

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

Criticality'ye göre periyodik yapılmalıdır.

Örneğin privileged hesaplar daha sık gözden geçirilebilir.

Access Recertification Nedir?

Data owner veya manager'ın mevcut yetkileri yeniden onaylamasıdır.

Dormant Account Policy Nedir?

Uzun süre kullanılmayan hesapların devre dışı bırakılması veya review edilmesidir.

Service Account Policy Nedir?

Application ve servis hesaplarının nasıl oluşturulup yönetileceğini belirler.

Service Account İçin Zorunlu Kontroller

Dedicated account

Minimum permission

Secret vault

Credential rotation

No interactive login

Owner assignment

Service Account'un Owner'ı Olmalı mı?

Evet.

Sahipsiz service account zamanla orphan account haline gelir.

Orphan Account Nedir?

Artık hangi application veya ekip için kullanıldığı bilinmeyen hesaptır.

Orphan Account Neden Risklidir?

Kimse kapatmaya cesaret edemediği için yıllarca aktif kalabilir.

Database Authentication Policy

Authentication yöntemi de standartlaştırılmalıdır.

Password Authentication Her Yerde Kullanılmalı mı?

Hayır.

Uygun ortamlarda merkezi identity, certificate veya federated authentication kullanılabilir.

MFA Database İçin Nasıl Uygulanır?

Doğrudan database engine veya PAM/SSO katmanı üzerinden uygulanabilir.

Password Policy Neleri İçermeli?

Örneğin:

Minimum strength

No sharing

Rotation where appropriate

Secure storage

Compromise response

Password Rotation Tek Başına Yeterli mi?

Hayır.

Strong authentication ve access monitoring de gerekir.

Hard-Coded Database Password Yasaklanmalı mı?

Evet.

Source code içerisinde database credential tutulmamalıdır.

Secret Management Policy

Credential ve secret'ların;

vault,

secret manager,

KMS

gibi güvenli sistemlerde tutulması tanımlanmalıdır.

Connection String Güvenliği

Application connection string içerisinde password varsa secure configuration mekanizmasında tutulmalıdır.

Network Security Policy

Database network erişimi açık ve kontrolsüz olmamalıdır.

Production Database Public Internet'e Açık Olmalı mı?

İş ihtiyacı yoksa hayır.

Network Segmentation Nedir?

Database sistemlerinin application, user ve management network'lerinden kontrollü şekilde ayrılmasıdır.

Database VLAN Kullanılabilir mi?

Evet.

Firewall Rules Nasıl Olmalı?

Allow-list yaklaşımı tercih edilmelidir.

Allow-List Nedir?

Sadece gerekli kaynakların database'e erişebilmesidir.

Management Access Nasıl Olmalı?

VPN,

ZTNA,

PAM,

bastion

gibi kontrollü erişim yöntemleri kullanılabilir.

DBA Laptop'undan Direkt Database Erişimi Olmalı mı?

Kritik sistemlerde özel yönetim ortamı veya PAM kullanılması daha güvenli olabilir.

Zero Trust Database İçin Ne İfade Eder?

Network içerisinde olmak otomatik güven anlamına gelmez.

Her connection;

identity,

device,

authorization

ile doğrulanmalıdır.

Database Encryption Policy

Database security policy hangi verinin şifrelenmesi gerektiğini tanımlamalıdır.

Encryption Katmanları

Encryption at Rest

Encryption in Transit

TDE

Column-Level Encryption

Backup Encryption

TLS Zorunlu Olmalı mı?

Critical production database bağlantıları için secure transport kullanılmalıdır.

TDE Policy Nasıl Olmalı?

Hassas data file'lar için risk bazlı olarak at-rest encryption uygulanabilir.

TDE Access Control Yerine Geçer mi?

Hayır.

Sensitive Column Encryption Policy

Çok hassas veri alanları ayrıca encryption altında tutulabilir.

Key Management Policy Nedir?

Encryption key lifecycle'ını tanımlar.

Key Management Policy Neleri İçermeli?

Key creation

Storage

Access

Rotation

Backup

Recovery

Revocation

Destruction

KMS/HSM Ne Zaman Kullanılmalı?

Kritik cryptographic key'lerin merkezi ve kontrollü yönetiminde kullanılabilir.

Key Administrator DBA'dan Ayrı Olmalı mı?

Kritik sistemlerde Separation of Duties açısından değerlendirilebilir.

Database Audit Policy

Audit politikanın zorunlu bölümlerinden biri olmalıdır.

Minimum Audit Event'leri Neler Olabilir?

Login

Failed Login

User Creation

Role Change

Privilege Grant

DDL

Sensitive Data Access

Backup/Restore

Audit Change

Her Query Loglanmalı mı?

Hayır.

Risk bazlı logging kullanılmalıdır.

Privileged Activity Audit Edilmeli mi?

Evet.

Audit Log Nerede Tutulmalı?

Critical loglar merkezi sisteme aktarılmalıdır.

SIEM Integration Policy

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

SIEM'e Hangi Database Event'leri Öncelikli Gönderilmeli?

Privileged login

Failed login spike

Sensitive data bulk read

New admin

Mass delete

Audit disabled

DAM Policy Nedir?

Database Activity Monitoring kapsamını ve detection use case'lerini tanımlar.

DAM Hangi Database'lerde Zorunlu Olabilir?

Critical veya restricted data tutan database'lerde kullanılabilir.

DAM Use Case'leri Politika İçinde Tanımlanmalı mı?

Evet.

Örnek DAM Use Case

Privileged user sensitive table bulk SELECT.

Database Backup Policy

Her database için backup gereksinimleri tanımlanmalıdır.

Backup Policy Neleri İçermeli?

Backup frequency

Retention

Encryption

Immutability

Offsite copy

Restore test

RPO Policy'de Olmalı mı?

Evet.

Critical database'lerin kabul edilebilir veri kaybı tanımlanmalıdır.

RTO Policy'de Olmalı mı?

Evet.

Recovery süresi iş gereksinimine göre belirlenmelidir.

Backup Immutable Olmalı mı?

Kritik sistemlerde ransomware riskine karşı değerlendirilebilir.

Backup Encryption Zorunlu Olmalı mı?

Hassas database backup'larında encryption güçlü şekilde uygulanmalıdır.

Restore Test Policy Nedir?

Backup'ların belirli aralıklarla gerçek restore ile doğrulanmasını zorunlu kılar.

Backup Başarılı Logu Yeterli mi?

Hayır.

PITR Policy

Transaction-critical database'lerde point-in-time recovery kabiliyeti tanımlanabilir.

PostgreSQL WAL

PITR için kullanılabilir.

MSSQL Transaction Log

PITR için kullanılabilir.

Oracle Archive Log

Recovery zincirinin temel parçasıdır.

Disaster Recovery Policy

Critical database'lerin alternatif ortamda nasıl ayağa kaldırılacağını tanımlar.

DR Policy Neleri İçermeli?

Primary Site

DR Site

Replication

RPO

RTO

Failover

Failback

Testing

HA ile DR Aynı mı?

Hayır.

HA local veya node failure'a odaklanabilir.

DR daha büyük felaket senaryolarını kapsar.

Database Patch Management Policy

Database version ve patch seviyelerinin nasıl yönetileceğini tanımlar.

Patch Policy Neleri İçermeli?

Inventory

Vendor advisory monitoring

Risk assessment

Patch SLA

Testing

Change management

Validation

Unsupported Database Kullanılabilir mi?

İstisna süreci olmadan kullanılmamalıdır.

EOL Database İçin Ne Yapılmalı?

Upgrade veya migration planı oluşturulmalıdır.

Patch SLA Nedir?

Vulnerability severity'ye göre patch uygulama süresidir.

Emergency Patch Süreci Olmalı mı?

Evet.

Database Vulnerability Management Policy

Database'lerin düzenli security assessment'tan geçmesini sağlar.

Vulnerability Assessment Neleri Kapsar?

Version

Configuration

Exposure

Weak authentication

Excessive privilege

Missing patch

Database Penetration Test Yapılmalı mı?

Scope ve risk doğrultusunda application-database interaction ve external exposure testleri yapılabilir.

Database Security Assessment ile Pentest Aynı mı?

Hayır.

Assessment daha çok configuration ve governance inceler.

Pentest exploitability ve exposure'ı test eder.

Secure Configuration Baseline

Her database teknolojisi için teknik hardening standardı oluşturulmalıdır.

PostgreSQL Baseline

pg_hba.conf

roles

TLS

logging

extensions

OS permission

gibi maddeleri içerebilir.

MSSQL Baseline

sa

sysadmin

Windows Authentication

service account

TDE

SQL Server Audit

advanced features

gibi başlıkları içerebilir.

Oracle Baseline

SYS/SYSDBA

listener

profiles

PUBLIC privileges

TDE

Unified Auditing

gibi kontrolleri içerebilir.

CIS Benchmark Kullanılabilir mi?

Uygun database platformlarında security baseline oluştururken referans olarak kullanılabilir.

Vendor Security Guide Kullanılmalı mı?

Evet.

Platform üreticisinin security guidance'ı da dikkate alınmalıdır.

Configuration Drift Policy

Database configuration'ın approved baseline'dan sapması izlenmelidir.

Configuration Drift Neden Oluşur?

Emergency change.

Manual admin action.

Upgrade.

New feature.

Drift Detection Otomatik Yapılabilir mi?

Evet.

Database Change Management Policy

Production database değişiklikleri kontrollü yapılmalıdır.

Hangi Değişiklikler Change Kapsamında Olmalı?

Schema changes

Patch

Role changes

Configuration

Major maintenance

Emergency Change Nedir?

Acil incident veya kritik vulnerability nedeniyle hızlandırılmış değişikliktir.

Change Approval Security'i Yavaşlatır mı?

Doğru tasarlanırsa hayır.

Riskli değişikliklerin kontrollü yapılmasını sağlar.

Database Dev/Test/Prod Ayrımı

Environment separation database security'nin temel prensiplerinden biridir.

Developer Production Database'e Erişmeli mi?

Sadece iş ihtiyacı varsa kontrollü ve geçici erişim sağlanmalıdır.

Production Data Test Ortamına Kopyalanmalı mı?

Mümkün olduğunca masked veya anonymized data kullanılmalıdır.

Data Masking Policy

Dev/test sistemlerinde hassas production verisinin gizlenmesini tanımlar.

Static Data Masking Nedir?

Production verisinin kopyalanmadan önce kalıcı olarak maskelenmesidir.

Dynamic Data Masking Nedir?

User'ın gördüğü verinin yetkiye göre maskelenmesidir.

Masking Encryption Yerine Geçer mi?

Hayır.

Database Secure Development Policy

Developer'ların güvenli database erişim yöntemleri kullanması gerekir.

SQL Injection Policy

Parameterized Query zorunlu hale getirilebilir.

Prepared Statement Kullanılmalı mı?

Evet.

Dynamic SQL Policy

Gereksiz dynamic SQL sınırlandırılmalı ve review edilmelidir.

ORM Security

ORM kullanmak automatic security sağlamaz.

Raw SQL review edilmelidir.

Application Database Account Policy

Application account minimum permission ile çalışmalıdır.

Application DBA Olabilir mi?

İstisnai gereksinim yoksa hayır.

Third-Party Database Access Policy

Vendor ve consultant erişimleri kontrollü yönetilmelidir.

Third-Party Access İçin Neler Olmalı?

Named account

Time-limited access

Approval

PAM

Logging

Vendor Shared Account Kullanabilir mi?

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

Third-Party Access Otomatik Expire Olmalı mı?

Evet.

Geçici access süre sonunda kaldırılabilir.

Remote Vendor Access Nasıl Yapılmalı?

Controlled VPN/ZTNA/PAM üzerinden.

Third-Party Session Recording Yapılmalı mı?

Kritik ortamlarda değerlendirilebilir.

Database Outsourcing Risk

Managed service kullanmak security responsibility'yi ortadan kaldırmaz.

Cloud Database Security Policy

Cloud managed database'ler de merkezi policy kapsamına alınmalıdır.

Cloud Database Inventory Gerekli mi?

Evet.

Public Cloud Database Exposure Kontrol Edilmeli mi?

Kesinlikle.

Cloud Security Group Nedir?

Database'e network erişimini sınırlayan cloud firewall mekanizmasıdır.

Private Endpoint Kullanılmalı mı?

Uygun servislerde public exposure yerine private connectivity tercih edilebilir.

Cloud IAM Database Güvenliğinin Parçası mı?

Evet.

Cloud Database Encryption

Provider-managed key veya customer-managed key kullanılabilir.

Cloud Backup Policy

Automated backup'lar;

retention,

encryption,

cross-region,

cross-account

açısından değerlendirilmelidir.

Shared Responsibility Model Nedir?

Cloud provider altyapının bazı bölümlerinden sorumludur.

Customer ise;

identity,

configuration,

data,

access

gibi alanlardan sorumlu olabilir.

Database Security Incident Response Policy

Database güvenlik olayı olduğunda ne yapılacağı önceden tanımlanmalıdır.

Database Security Incident Örnekleri

Unauthorized login

Mass data extraction

Privilege escalation

Database ransomware

Data corruption

Backup deletion

Incident Response Akışı

Detection

↓

Triage

↓

Containment

↓

Investigation

↓

Eradication

↓

Recovery

↓

Lessons Learned

Database Incident'ta İlk Yapılması Gereken Ne?

Olay türüne göre değişir.

Ancak evidence korunmadan rastgele değişiklik yapılmamalıdır.

Audit Loglar Incident'ta Kritik mi?

Evet.

Database Forensics Policy

Log ve transaction information'ın güvenli şekilde korunmasını tanımlar.

Time Synchronization Neden Policy'de Olmalı?

Incident timeline için sistemlerin ortak saat kullanması gerekir.

Database Security Event Classification

Event'ler severity seviyelerine ayrılabilir.

Örnek Severity

Critical

High

Medium

Low

Critical Database Event Örnekleri

Audit Disabled

New Superuser

Mass Delete

Sensitive Data Export

Backup Deleted

Database Security Exception Management

Her sistem policy'ye tam uyamayabilir.

Bu durumda resmi exception süreci olmalıdır.

Exception Neleri İçermeli?

Reason

Risk

Compensating Controls

Owner

Expiry Date

Permanent Exception Olmalı mı?

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

Compensating Control Nedir?

Asıl kontrol uygulanamadığında riski azaltan alternatif kontroldür.

Örnek

Legacy database TLS desteklemiyor.

Compensating controls:

Isolated network

IP allow-list

VPN

Migration plan

Exception Expiry Neden Önemlidir?

Geçici istisnaların kalıcı hale gelmesini önler.

Database Security Risk Assessment

Her database risk bazlı değerlendirilmelidir.

Risk Faktörleri

Internet Exposure

Data Sensitivity

Privilege Level

Version

Backup Status

Audit Coverage

Database Risk Score Oluşturulabilir mi?

Evet.

Örnek Risk Score

Critical Data: +30

Public Exposure: +30

Unsupported Version: +20

No Audit: +10

No Encryption: +10

Toplam:

100/100 yüksek risk.

Database Security KPI Nedir?

Güvenlik programının performansını ölçen göstergelerdir.

Örnek Database Security KPI'ları

Asset Inventory Coverage

Patch Compliance

Audit Coverage

Encryption Coverage

Privileged Access Review Completion

Backup Success

Restore Test Success

DAM Coverage

Inventory Coverage Hedefi Ne Olmalı?

İdeal hedef:

%100

Critical Database Audit Coverage Hedefi?

Kritik sistemlerde mümkün olduğunca:

%100

Unsupported Database Sayısı?

Hedef:

0

Restore Test Success Rate?

Kritik database'lerde mümkün olduğunca:

%100

Database Security KRI Nedir?

Key Risk Indicator risk seviyesini gösterir.

Örnek KRI

Public database count

EOL database count

Unreviewed privileged accounts

Failed backups

KPI ile KRI Farkı Nedir?

KPI süreç performansını ölçer.

KRI risk seviyesini gösterir.

Database Security Dashboard

Üst yönetim için dashboard oluşturulabilir.

Dashboard Neleri Göstermeli?

Total Databases

Critical Databases

High-Risk Findings

Patch Compliance

Encryption Coverage

Audit Coverage

Backup Health

Dashboard SQL Detayı Göstermeli mi?

Üst yönetim için çoğunlukla hayır.

Risk ve trend gösterilmelidir.

Database Security RACI Nedir?

Rollerin sorumluluk dağılımını gösterir.

Örnek RACI Rolleri

DBA

Security

Application Owner

Data Owner

SOC

Internal Audit

DBA'nın Sorumlulukları

Hardening

Maintenance

Backup operations

Performance

Security Team Sorumlulukları

Security baseline

Monitoring

Risk assessment

Incident response

Data Owner Sorumlulukları

Kimlerin veriye erişmesi gerektiğini belirlemek.

Application Owner Sorumlulukları

Application account ve secure database access.

SOC Sorumlulukları

Database security alertlerini izlemek.

Internal Audit Sorumlulukları

Politika ve kontrol etkinliğini bağımsız olarak değerlendirmek.

Separation of Duties Neden Governance İçin Önemli?

Tek kişinin;

access verme,

kullanma,

audit etme

yetkilerinin tamamına sahip olması risklidir.

Database Security Training

DBA ve developer'lar düzenli security training almalıdır.

DBA Security Training Konuları

Least Privilege

Hardening

Encryption

Audit

Backup Security

Incident Response

Developer Training Konuları

SQL Injection

Parameterized Query

Secret Management

ORM Security

Database Access Control

SOC Training Konuları

Database log

DAM

Data Exfiltration

Privileged Activity

Database Security Documentation

Kritik yapılandırmalar dokümante edilmelidir.

Dokümantasyon Neleri İçermeli?

Architecture

Owner

Backup

RPO/RTO

Access model

DR

Credential Dokümana Yazılmalı mı?

Hayır.

Vault referansı kullanılmalıdır.

Database Security Policy Ne Sıklıkla Review Edilmeli?

En azından periyodik ve önemli değişikliklerden sonra.

Hangi Olaylarda Policy Review Gerekebilir?

Major breach

New regulation

New database platform

Cloud migration

Major architecture change

ISO/IEC 27001 ve Database Güvenliği

ISO/IEC 27001 doğrudan “database şöyle yapılandırılmalıdır” şeklinde ürün bazlı bir teknik rehber değildir.

Risk bazlı bir bilgi güvenliği yönetim sistemi yaklaşımı sağlar.

Database güvenliği açısından;

access control,

privileged access,

cryptography,

logging,

backup,

vulnerability management,

incident management,

business continuity

gibi alanlarla ilişki kurulabilir.

Database Policy ISO 27001'i Nasıl Destekler?

Database security kontrollerinin;

tanımlanması,

uygulanması,

ölçülmesi,

review edilmesi

sürecini sistematik hale getirir.

ISO 27001 Sertifikası Database'in Güvenli Olduğunu Garanti Eder mi?

Hayır.

Sertifika yönetim sisteminin belirli gereksinimleri karşıladığını gösterir.

Teknik kontrollerin etkinliği ayrıca değerlendirilmelidir.

KVKK ve Database Güvenliği

Kişisel verilerin büyük bölümü database sistemlerinde tutulduğu için veritabanı güvenliği KVKK kapsamındaki veri güvenliği yaklaşımı açısından kritik öneme sahiptir.

KVKK İçin Hangi Database Kontrolleri Önemlidir?

Risk bazlı olarak;

Access Control

Authorization

Encryption

Logging

Backup

Monitoring

Data Minimization

değerlendirilebilir.

Database Encryption KVKK İçin Yeterli mi?

Hayır.

Audit KVKK İçin Neden Önemlidir?

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

Data Minimization Nedir?

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

Database Data Minimization Nasıl Uygulanabilir?

Gereksiz kolonları toplamamak.

Retention sonrası veri silmek.

Test sistemlerinde gerçek veri kullanmamak.

Retention Policy Database İçin Neden Önemlidir?

Veri gereğinden uzun süre tutulmamalıdır.

Database Retention ile Backup Retention Uyumlu Olmalı mı?

Evet.

Production'dan silinen veri yıllarca backup'ta kalıyorsa lifecycle ayrıca değerlendirilmelidir.

Secure Data Deletion Nedir?

Retention sona erdiğinde verinin uygun yöntemle erişilemez hale getirilmesidir.

Database Row DELETE Her Zaman Fiziksel Silme midir?

Hayır.

Storage ve backup sistemlerinde kopyalar bulunabilir.

Bu nedenle data lifecycle bütünsel yönetilmelidir.

KVKK Uyumunda Database Inventory Neden Önemlidir?

Kişisel verinin hangi sistemlerde tutulduğunu bilmeden etkili veri güvenliği sağlamak zordur.

PCI DSS ve Database Security

Ödeme kartı verisi işleyen database'lerde;

strong access control,

encryption,

logging,

monitoring,

segmentation

gibi kontroller özellikle önemlidir.

DORA ve Database Resilience

Finansal kuruluşlar açısından operasyonel dayanıklılık ve ICT risk yönetimi kapsamında database'lerin;

availability,

backup,

recovery,

monitoring

yetenekleri önem taşır.

Regülasyon Değişirse Policy Güncellenmeli mi?

Evet.

Compliance ile Security Aynı mı?

Hayır.

Compliance minimum gereksinimleri sağlayabilir.

Security gerçek riskleri azaltmaya odaklanmalıdır.

Checkbox Compliance Nedir?

Kontrolün yalnızca denetim geçmek için kağıt üzerinde uygulanmasıdır.

Örnek Checkbox Compliance

Audit açık.

Ama kimse logları izlemiyor.

Teknik olarak kontrol var.

Gerçekte detection yok.

Effective Control Nedir?

Kontrolün gerçekten riski azaltmasıdır.

Database Security Audit Nasıl Yapılmalı?

Periyodik olarak;

inventory,

configuration,

access,

audit,

backup,

patch

kontrol edilebilir.

Internal Audit ile Technical Assessment Aynı mı?

Hayır.

Internal audit governance ve control effectiveness değerlendirir.

Technical assessment configuration seviyesine iner.

Database Security GAP Analysis Nedir?

Mevcut durum ile hedef security standardı arasındaki farkın belirlenmesidir.

GAP Analysis Aşamaları

Inventory

↓

Assessment

↓

Risk Scoring

↓

Remediation Plan

↓

Validation

Remediation Plan Nedir?

Security finding'lerinin;

owner,

deadline,

priority

ile kapatılmasını sağlar.

Database Security Finding Örneği

Finding:

Production database public internet'e açık.

Risk:

Unauthorized access.

Action:

Private network migration.

Owner:

Infrastructure Team.

Due Date:

30 gün.

Finding Closure Nasıl Doğrulanmalı?

Sadece owner “kapattım” dememelidir.

Teknik validation yapılmalıdır.

Database Security Maturity Model

Seviye 1 – Ad Hoc

Database güvenliği kişilerin bilgisine bağlıdır.

Seviye 2 – Documented

Temel policy ve procedures vardır.

Seviye 3 – Standardized

Tüm database platformlarında security baseline uygulanır.

Seviye 4 – Monitored

SIEM, DAM ve KPI ile sürekli izleme vardır.

Seviye 5 – Risk-Driven & Automated

Discovery, compliance, monitoring ve response büyük ölçüde otomatik hale gelmiştir.

Seviye 1 Kurum Nasıl Görünür?

Database listesi tam bilinmez.

Shared DBA account vardır.

Backup kontrolü manuel yapılır.

Patch düzensizdir.

Seviye 3 Kurum Nasıl Görünür?

Inventory tamdır.

Baseline vardır.

Access review yapılır.

Backup ve patch süreçleri standarttır.

Seviye 5 Kurum Nasıl Görünür?

Yeni database otomatik keşfedilir.

Policy violation otomatik tespit edilir.

Privileged activity real-time izlenir.

Response otomasyonu vardır.

Database Security Roadmap Nasıl Oluşturulur?

Kurum her şeyi aynı anda yapmak zorunda değildir.

Risk bazlı roadmap oluşturulabilir.

İlk 30 Gün

Database inventory

Criticality

Privileged account inventory

Public exposure review

İlk 60 Gün

Security baseline

Access review

Backup validation

Patch review

İlk 90 Gün

SIEM integration

DAM use cases

Encryption review

Restore testing

Sonraki Aşama

Automation

Continuous compliance

Behavior analytics

SOAR integration

Database Security Policy İçin Örnek Ana Başlıklar

Kurumsal bir politika şu başlıklardan oluşabilir:

• Amaç
• Kapsam
• Roller ve Sorumluluklar
• Database Envanteri
• Veri Sınıflandırma
• Access Control
• Privileged Access
• Authentication
• Network Security
• Encryption
• Audit ve Logging
• DAM
• Backup ve Recovery
• Patch Management
• Vulnerability Management
• Change Management
• Development ve Test
• Third-Party Access
• Cloud Database Security
• Incident Response
• Compliance
• Exception Management
• KPI ve Reporting

Database Security Checklist

Kurumsal kontrol listesi:

• Tüm database'ler envanterde mi?
• Owner tanımlı mı?
• Criticality belirli mi?
• Data classification yapıldı mı?
• Public exposure kontrol edildi mi?
• Shared account var mı?
• Privileged access PAM altında mı?
• MFA kullanılıyor mu?
• Least Privilege uygulanıyor mu?
• TLS aktif mi?
• At-rest encryption var mı?
• Backup encrypted mı?
• Audit aktif mi?
• SIEM entegrasyonu var mı?
• DAM kritik database'lerde aktif mi?
• Backup düzenli mi?
• Restore test yapıldı mı?
• RPO/RTO tanımlı mı?
• Patch seviyesi güncel mi?
• EOL database var mı?
• Vulnerability assessment yapılıyor mu?
• Third-party erişimler kontrollü mü?
• Cloud database'ler kapsamda mı?
• Incident response planı var mı?

Yönetimin Sorması Gereken 15 Kritik Database Güvenlik Sorusu

• Kaç database'imiz var?
• Hangileri kritik?
• Hangilerinde kişisel veya hassas veri var?
• Kaçı internete açık?
• Kaç privileged account var?
• Shared DBA hesabı var mı?
• Kaç database encrypted?
• Kaçında audit aktif?
• Kaçı DAM altında?
• Kaçında patch eksik?
• Destek dışı database var mı?
• Son restore testimiz ne zaman?
• RPO/RTO hedeflerimizi karşılıyor muyuz?
• DBA hassas veri okursa fark edebilir miyiz?
• Bir ransomware saldırısında database'i gerçekten geri getirebilir miyiz?

Bu sorulara net cevap verilemiyorsa database security governance geliştirilmelidir.

Database Security'de En Sık Yapılan Kurumsal Hatalar

Kurumlarda sık görülen hatalar:

• Database inventory tutmamak
• Güvenliği yalnızca DBA'nın sorumluluğu sanmak
• Shared administrator account kullanmak
• Access review yapmamak
• Application hesaplarına aşırı yetki vermek
• Database'i internete açmak
• TLS kullanmamak
• Encryption key yönetimini ihmal etmek
• Audit açıp logları izlememek
• DAM'i sadece compliance ürünü gibi görmek
• Backup alıp restore test etmemek
• Patch'leri sürekli ertelemek
• EOL database kullanmak
• Production data'yı test ortamına kontrolsüz taşımak
• Third-party erişimlerini süresiz bırakmak
• Cloud database'leri policy dışında değerlendirmek
• Incident response planı oluşturmamak
• Security KPI üretmemek

Database Security Programı Nasıl Ölçülür?

İyi bir program yalnızca teknik finding sayısıyla ölçülmez.

Örnek göstergeler:

Critical Database Inventory Coverage

Privileged Access Review Completion

Encryption Coverage

Audit Coverage

DAM Coverage

Patch Compliance

Backup Success Rate

Restore Test Success Rate

Mean Time to Detect

Mean Time to Remediate

Security Program Başarılıysa Finding Sayısı Sıfır mı Olmalı?

Hayır.

Gerçekçi sistemlerde yeni finding'ler çıkabilir.

Önemli olan:

bulmak, önceliklendirmek ve zamanında kapatmaktır.

Continuous Improvement Nedir?

Database güvenlik programının sürekli ölçülüp geliştirilmesidir.

PDCA Database Security İçin Kullanılabilir mi?

Evet.

Plan

Do

Check

Act

yaklaşımı uygulanabilir.

Plan

Policy ve risk hedefleri belirlenir.

Do

Security controls uygulanır.

Check

Audit, KPI ve assessment yapılır.

Act

Finding'ler kapatılır ve süreç geliştirilir.

Sık Sorulan Sorular

Database Security Policy nedir?

Kurumun veritabanlarını hangi teknik ve yönetsel güvenlik kontrolleriyle koruyacağını belirleyen politika dokümanıdır.

Database güvenliği sadece DBA'nın sorumluluğu mu?

Hayır. Security, application, data owner, SOC, risk ve management dahil birçok rol ortak sorumluluk taşır.

ISO 27001 database güvenliğini kapsar mı?

Risk bazlı bilgi güvenliği yönetimi içerisinde access control, logging, cryptography, backup ve vulnerability management gibi alanlarla ilişkilendirilebilir.

KVKK için database encryption zorunlu mu?

Tek bir teknik kontrol tüm durumlara uygulanmaz. Risk bazlı teknik ve idari tedbirler birlikte değerlendirilmelidir. Encryption önemli güvenlik kontrollerinden biridir.

Database audit zorunlu mu?

Kritik ve hassas sistemlerde kimlerin hangi işlemleri yaptığının izlenebilir olması güçlü bir güvenlik ihtiyacıdır.

DAM her database'te kullanılmalı mı?

Her database için zorunlu değildir. Criticality ve data sensitivity'ye göre önceliklendirilmelidir.

Database backup policy neden gereklidir?

Backup sıklığı, retention, encryption, immutability ve restore testlerini standartlaştırır.

RPO ve RTO politika içinde tanımlanmalı mı?

Kritik sistemler için evet.

Database security assessment ne sıklıkla yapılmalı?

Risk seviyesine ve kurum politikasına göre periyodik yapılmalıdır.

Cloud database policy kapsamına girer mi?

Kesinlikle. Managed olması security responsibility'yi ortadan kaldırmaz.

Sonuç: Database Güvenliği Bir Ürün Değil, Süreçtir

Kurumsal database güvenliğinin en büyük hatası güvenliği tek bir ürüne veya tek bir ekibe indirgemektir.

Firewall tek başına yeterli değildir.

Encryption tek başına yeterli değildir.

PAM tek başına yeterli değildir.

DAM tek başına yeterli değildir.

Backup tek başına yeterli değildir.

Gerçek database güvenliği bu kontrollerin birlikte ve yönetilebilir şekilde çalışmasıyla ortaya çıkar.

Bu nedenle kurumsal database security modeli şu yapıda ele alınmalıdır:

Inventory

↓

Classification

↓

Access Control

↓

Authentication

↓

Hardening

↓

Encryption

↓

Audit

↓

DAM

↓

Backup & Recovery

↓

Patch & Vulnerability Management

↓

Monitoring

↓

Incident Response

↓

Governance

Bu zincirin herhangi bir halkası eksik olduğunda risk büyür.

Kurum database'lerinin;

nerede olduğunu,

hangi veriyi tuttuğunu,

kimlerin eriştiğini,

hangi kontrollerle korunduğunu,

hangi sürümde çalıştığını,

hangi noktaya kadar geri dönebildiğini

bilmelidir.

En kritik değişim ise şu düşünce yapısıdır:

Database security yalnızca:

“DBA dikkatli olsun.”

yaklaşımıyla yönetilemez.

Süreç;

policy,

standard,

monitoring,

audit,

KPI

ve continuous improvement

ile kurumsallaştırılmalıdır.

Doğru hedef:

kişiye bağımlı database güvenliği

değil;

ölçülebilir ve denetlenebilir database security governance

oluşturmaktır.

Bu nedenle güçlü bir kurum şu soruya her zaman cevap verebilmelidir:

“Kritik veritabanlarımız ne kadar güvende?”

Ve bu cevabı:

“Bence güvende.”

şeklinde değil;

ölçülebilir kanıtlarla verebilmelidir:

%100 kritik database envanterde.

%100 privileged access audit altında.

%100 kritik database backup kapsamında.

%100 restore testleri doğrulanmış.

Kritik patch açıkları SLA içerisinde kapatılıyor.

Yüksek riskli database aktiviteleri gerçek zamanlı izleniyor.

İşte gerçek kurumsal database güvenliği budur.