# Database Activity Monitoring – DAM Nedir? Veritabanı Aktiviteleri Nasıl İzlenir?

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

![Database Activity Monitoring – DAM Nedir? Veritabanı Aktiviteleri Nasıl İzlenir?](/images/bilgi-merkezi/covers/cover-veritabani-08.webp)

Kurumsal veritabanı güvenliğinde yalnızca kullanıcıların kim olduğunu bilmek yeterli değildir.

Asıl önemli olan şudur:

#### Bu kullanıcı database içerisinde gerçekte ne yaptı?

Bir DBA'nın teknik olarak customer database'e erişim yetkisi olabilir.

Ancak şu soru yine de cevaplanmalıdır:

Bu erişim gerçekten iş amacıyla mı yapıldı?

Bir support kullanıcısı neden gece 03:00'te milyonlarca müşteri kaydı sorguladı?

Bir service account neden daha önce hiç erişmediği tabloya bağlandı?

Bir kullanıcı normalde 100 kayıt görüntülerken neden bir anda 2 milyon kayıt çekti?

Bir administrator neden audit ayarını değiştirdi?

Bu sorular klasik access control sistemlerinin tek başına cevaplayamadığı sorulardır.

Authentication kullanıcının kim olduğunu doğrular.

Authorization kullanıcının ne yapmaya yetkili olduğunu belirler.

Ancak:

#### Database Activity Monitoring – DAM

kullanıcının gerçekte ne yaptığını izlemeye odaklanır.

Bu nedenle DAM modern database security mimarisinde önemli bir görünürlük ve detection katmanıdır.

### DAM Nedir?

DAM:

#### Database Activity Monitoring

yani:

#### Veritabanı Aktivite İzleme

anlamına gelir.

DAM çözümleri database üzerinde gerçekleşen;

login,

query,

privileged activity,

sensitive data access,

DDL,

DML,

configuration change

gibi aktiviteleri izler ve analiz eder.

Amaç yalnızca log toplamak değildir.

Amaç:

**şüpheli database davranışlarını anlamlandırmak ve tespit etmektir.**

### DAM ile Database Audit Aynı Şey mi?

Hayır.

Database Audit çoğunlukla DBMS'nin kendi loglama mekanizmasına dayanır.

DAM ise bu aktiviteleri daha merkezi ve güvenlik odaklı analiz eder.

Basitleştirirsek:

Database Audit:

#### Ne oldu?

DAM:

#### Bu olay normal mi, şüpheli mi?

sorusuna cevap vermeye çalışır.

### DAM Neden Gereklidir?

Kurumlarda database sayısı arttıkça her sistemin audit loglarını tek tek incelemek mümkün değildir.

Örneğin kurumda;

50 PostgreSQL,

30 MSSQL,

20 Oracle

database bulunduğunu düşünelim.

Her database günde milyonlarca event üretebilir.

DAM bu aktiviteleri merkezi olarak izlemeye yardımcı olur.

### DAM Hangi Problemi Çözer?

Temel problem:

#### Database içerisinde görünürlük eksikliği

dir.

Firewall network trafiğini görür.

EDR endpoint davranışını görür.

WAF web request'lerini görür.

DAM ise:

**database query davranışını**

görür.

### DAM Ne Tür Aktiviteleri İzleyebilir?

Örneğin:

Successful Login

Failed Login

SELECT

INSERT

UPDATE

DELETE

CREATE USER

GRANT

REVOKE

DROP TABLE

Database Export

Backup Activity

Sensitive Table Access

### DAM Sadece SQL Query mi İzler?

Hayır.

Platforma göre;

session,

authentication,

user,

role,

configuration,

database object

aktiviteleri de izlenebilir.

### DAM Hangi Database Sistemlerinde Kullanılabilir?

DAM çözümleri çoğunlukla;

PostgreSQL,

Microsoft SQL Server,

Oracle Database,

MySQL,

MariaDB

gibi yaygın sistemleri destekleyebilir.

Bazı çözümler cloud database platformlarını da destekler.

### DAM Architecture Nedir?

DAM çözümünün database aktivitelerini nasıl topladığı ve analiz ettiğini ifade eder.

Farklı deployment modelleri bulunabilir.

### Network-Based DAM Nedir?

Database trafiğini network seviyesinde analiz eder.

Bu yaklaşım database server'a agent kurmadan visibility sağlayabilir.

### Network-Based DAM Avantajı Nedir?

Production database'e software agent yükleme ihtiyacını azaltabilir.

### Network-Based DAM Dezavantajı Nedir?

Encrypted database traffic veya local database activity tam görünmeyebilir.

Bu nedenle mimariye göre ek yöntem gerekebilir.

### Agent-Based DAM Nedir?

Database veya işletim sistemi üzerine agent kurulmasıyla aktivitelerin izlenmesidir.

### Agent-Based DAM Avantajı Nedir?

Local activity ve encrypted session hakkında daha yüksek visibility sağlayabilir.

### Agent-Based DAM Riski Var mı?

Production database üzerinde agent;

performance,

compatibility,

availability

açısından dikkatli test edilmelidir.

### Native Audit Integration Nedir?

DAM, database'in native audit kayıtlarını okuyabilir.

### Native Audit + DAM Birlikte Kullanılabilir mi?

Evet.

Database native audit event üretir.

DAM bu event'leri merkezi olarak analiz eder.

### Proxy-Based DAM Nedir?

Database connection'larının bir proxy üzerinden geçirilerek analiz edilmesidir.

### Proxy-Based Model Avantajı Nedir?

Database trafiği merkezi enforcement noktasından geçebilir.

### Proxy-Based Model Dezavantajı Nedir?

Database connection path'e yeni dependency ekler.

Bu nedenle high availability doğru tasarlanmalıdır.

### DAM Inline Çalışabilir mi?

Bazı ürünlerde evet.

Query'ler database'e ulaşmadan önce incelenebilir.

### DAM Out-of-Band Çalışabilir mi?

Evet.

Trafiği engellemeden yalnızca monitoring yapabilir.

### Blocking ile Monitoring Aynı mı?

Hayır.

Monitoring:

Şüpheli davranışı tespit eder.

Blocking:

İşlemi engellemeye çalışır.

### DAM Query Engellemeli mi?

Bu kurum riskine göre belirlenir.

Production database'te yanlış positive nedeniyle kritik query'nin engellenmesi ciddi outage oluşturabilir.

Bu nedenle başlangıçta monitor-only kullanılabilir.

### DAM Policy Nedir?

Hangi database aktivitelerinin;

izleneceğini,

alarm üreteceğini,

engelleneceğini

belirleyen kurallardır.

### DAM Policy Örneği

Örneğin:

DBA → Customer_PII table → SELECT

durumunda alert üretilebilir.

### Her SELECT Alarm Üretmeli mi?

Hayır.

Bu çok fazla false positive oluşturur.

Context gereklidir.

### DAM Context Nedir?

Query'nin;

kim tarafından,

hangi saat,

hangi IP,

hangi application,

hangi tablo,

ne kadar veri

ile çalıştırıldığını birlikte değerlendirmektir.

### Privileged User Monitoring Nedir?

DBA ve administrator gibi yüksek yetkili kullanıcıların aktivitelerinin detaylı izlenmesidir.

### DAM DBA'yı Neden İzler?

Çünkü DBA'nın teknik erişim hakkı olabilir.

Ancak her erişim business justified olmayabilir.

### DBA Her Şeyi Görebiliyorsa Güvenlik Nasıl Sağlanır?

Yetki tamamen kaldırılamıyorsa;

audit,

DAM,

PAM,

session monitoring

ile accountability artırılabilir.

### DAM DBA Query'lerini Kaydedebilir mi?

Evet.

Platform ve ürün desteğine göre executed query'ler kaydedilebilir.

### DBA Sensitive Data Okursa Alarm Üretilebilir mi?

Evet.

Örneğin DBA normalde system tables ile çalışırken customer PII tablosuna erişirse alert üretilebilir.

### Sensitive Data Access Monitoring Nedir?

Kişisel veya kritik veri içeren database tablolarına erişimin özel olarak izlenmesidir.

### Sensitive Data Nasıl Belirlenir?

Data discovery ve classification ile;

TCKN,

IBAN,

credit card,

email,

phone,

salary,

health data

gibi alanlar belirlenebilir.

### DAM Data Discovery Yapabilir mi?

Bazı DAM çözümleri database discovery ve sensitive data discovery özellikleri sunabilir.

### Database Discovery Nedir?

Network veya inventory üzerinden bilinmeyen database sistemlerinin tespit edilmesidir.

### Shadow Database Nedir?

IT veya security ekibinin bilgisi dışında çalışan database sistemidir.

### Shadow Database Neden Risklidir?

Bu sistem;

patchsiz,

backup'sız,

internete açık,

audit dışı

olabilir.

### DAM Shadow Database Tespitine Yardımcı Olabilir mi?

Bazı platformlarda network discovery özellikleri kullanılabilir.

### Sensitive Data Discovery Nedir?

Database içerisinde hangi tablo veya kolonların hassas veri içerdiğinin otomatik veya manuel belirlenmesidir.

### Data Classification DAM İçin Neden Kritik?

DAM tüm tabloları aynı risk seviyesinde değerlendirmemelidir.

Örneğin product catalog ile customer PII aynı hassasiyette değildir.

### Critical Table Nedir?

Kurumsal açıdan yüksek risk taşıyan database tablosudur.

Örneğin:

Customer

Employee_Salary

Payment

User_Credential

### Critical Table Access Daha Yüksek Severity Olmalı mı?

Evet.

Alert risk skoru data classification ile artırılabilir.

### DAM Query Analysis Nedir?

Database üzerinde çalıştırılan sorguların güvenlik açısından analiz edilmesidir.

### Query Analysis Neleri İnceler?

Örneğin:

Query Type

Source User

Target Table

Row Count

Execution Time

Time of Day

Application

### Query Pattern Nedir?

Bir uygulama veya kullanıcı tarafından normalde çalıştırılan SQL davranışıdır.

### Query Baseline Nedir?

Normal query pattern'inin belirlenmesidir.

### Baseline Olmadan Anomaly Detection Zor mu?

Evet.

Normal davranış bilinmeden anormal davranışın tespiti zorlaşır.

### DAM Anomaly Detection Nedir?

Kullanıcının normal database davranışından sapmasının tespitidir.

### Örnek Database Anomalisi

Normal:

Kullanıcı gündüz 09:00–18:00 arası 500–1000 kayıt sorguluyor.

Anormal:

Gece 02:45'te 4 milyon kayıt sorguluyor.

Bu yüksek riskli anomaly olabilir.

### Behavioral Analytics Nedir?

Kullanıcıların davranış profillerini analiz eden yöntemdir.

### DAM UEBA ile Entegre Olabilir mi?

Evet.

User and Entity Behavior Analytics sistemleri database aktivitelerini diğer identity davranışlarıyla birlikte değerlendirebilir.

### DAM User Risk Score Oluşturabilir mi?

Bazı çözümler kullanıcı aktivitelerini risk skoruna dönüştürebilir.

### Örnek Risk Score Faktörleri

Privileged Account

New Source IP

Night Access

Sensitive Table Access

Bulk Data Read

Database Export

bir araya geldiğinde yüksek risk score oluşabilir.

### Bulk Data Access Nedir?

Normalden çok daha fazla kaydın kısa sürede okunmasıdır.

### Bulk Data Access Her Zaman Saldırı mı?

Hayır.

ETL,

backup,

reporting

işlemleri de büyük veri okuyabilir.

### DAM Normal ETL ile Data Exfiltration'ı Nasıl Ayırır?

Context kullanır.

Örneğin;

service account,

source IP,

schedule,

query pattern

karşılaştırılabilir.

### Data Exfiltration Detection Nedir?

Database verisinin yetkisiz şekilde dışarı çıkarılmasına ilişkin davranışların tespit edilmesidir.

### Database Data Exfiltration Nasıl Görünebilir?

Örneğin;

yüksek hacimli SELECT,

database export,

dump,

suspicious application access

şeklinde görülebilir.

### DAM Data Exfiltration'ı Kesin Olarak Tespit Eder mi?

Hayır.

Bir activity'nin malicious olup olmadığı context gerektirir.

DAM detection ve investigation için sinyal sağlar.

### Database Export Monitoring Neden Kritik?

Export işlemi milyonlarca kaydı tek dosyada dışarı çıkarabilir.

### CSV Export İzlenebilir mi?

Uygulama veya database tarafında audit ve DAM yeteneklerine göre izlenebilir.

### Database Dump Aktivitesi İzlenmeli mi?

Evet.

Özellikle production database'te yüksek riskli işlem olabilir.

### Backup Activity DAM İçin Önemli mi?

Evet.

Backup production verisinin tam kopyasını oluşturabilir.

### Restore Activity Neden İzlenmeli?

Production verisinin farklı bir server'a restore edilmesi veri sızıntısı yolu olabilir.

### Alternate Restore Alarmı Nedir?

Database'in beklenmeyen bir sisteme restore edilmesi durumunda üretilen güvenlik alarmıdır.

### DAM Credential Abuse Tespit Edebilir mi?

Davranış üzerinden yardımcı olabilir.

Örneğin çalınmış DBA credential'ı normalden farklı IP veya zamanda kullanılırsa anomaly oluşabilir.

### Credential Compromise ile Insider Threat Nasıl Ayrılır?

Her zaman kolay değildir.

Bu nedenle identity, endpoint ve database logları birlikte analiz edilmelidir.

### DAM ile EDR Birlikte Nasıl Çalışır?

Örnek:

EDR → Credential Dumping Alert

↓

DAM → Aynı kullanıcının privileged database login'i

↓

DAM → Sensitive Table Bulk Read

Bu olaylar güçlü incident göstergesi olabilir.

### DAM ile SIEM Arasındaki Fark Nedir?

DAM database'e özel visibility sağlar.

SIEM birçok güvenlik kaynağını merkezi olarak toplar ve korele eder.

### DAM SIEM'in Yerine Geçer mi?

Hayır.

Tamamlayıcıdır.

### SIEM DAM'in Yerine Geçer mi?

Her zaman değil.

Native database logları yeterli detay üretmeyebilir.

DAM database-specific telemetry sağlayabilir.

### DAM SIEM'e Hangi Event'leri Gönderebilir?

Örneğin:

Privileged Login

Failed Login Spike

Sensitive Data Access

Bulk Query

Audit Disabled

New DBA User

Suspicious Export

### DAM SOC İçin Neden Değerlidir?

SOC endpoint ve network dışında database davranışını da görebilir.

### Database Security Monitoring Nedir?

Database güvenlik olaylarının sürekli izlenmesi ve analiz edilmesidir.

DAM bu sürecin temel araçlarından biri olabilir.

### DAM Real-Time Monitoring Sağlayabilir mi?

Evet.

Ürünün ve mimarinin yeteneklerine göre near real-time veya real-time alerting yapılabilir.

### Real-Time Database Alert Neden Önemlidir?

Data exfiltration olayında saatler sonra müdahale etmek geç olabilir.

### Alert Severity Nasıl Belirlenmeli?

Kullanıcı privilege seviyesi,

database criticality,

data sensitivity,

activity type,

anomaly score

gibi faktörlere göre belirlenebilir.

### DAM Policy Tuning Nedir?

Alarm kurallarının gerçek ortam davranışına göre optimize edilmesidir.

### DAM Kurulduğu Gün Her Şeyi Engellemeli mi?

Hayır.

Önce normal davranışın öğrenilmesi ve policy tuning yapılması genellikle daha güvenlidir.

### Learning Mode Nedir?

DAM çözümünün belirli süre normal database davranışını gözlemlemesidir.

### Learning Period Ne Kadar Olmalı?

Sistemin workload'una göre değişir.

Aylık kapanış, hafta sonu işlemleri gibi özel dönemler de göz önünde bulundurulmalıdır.

### False Positive Nedir?

Normal database aktivitesinin yanlışlıkla saldırı olarak işaretlenmesidir.

### False Positive Fazla Olursa Ne Olur?

SOC alarmları göz ardı etmeye başlayabilir.

Bu alert fatigue oluşturur.

### False Negative Nedir?

Gerçek saldırının tespit edilememesidir.

### DAM Tuning Amacı Nedir?

False positive azaltılırken gerçek saldırıların detection coverage'ı korunmalıdır.

### Known Application Baseline Nedir?

Belirli application account'un normalde hangi query'leri çalıştırdığının bilinmesidir.

### Application Account Yeni Tabloya Erişirse Alarm Üretilebilir mi?

Evet.

Özellikle normal pattern dışında ise değerlendirilebilir.

### Service Account Farklı IP'den Login Olursa Ne Olmalı?

Application service account sadece belirli server'lardan gelmelidir.

Başka IP yüksek riskli event olabilir.

### Source Application Monitoring Nedir?

Database bağlantısının hangi application tarafından yapıldığının izlenmesidir.

### Connection String Bilgisi DAM Tarafından Görülür mü?

Ürüne ve mimariye göre bazı client metadata bilgileri görülebilir.

### Database User Mapping Nedir?

Database user'ın gerçek insan veya application identity ile eşleştirilmesidir.

### Shared Account DAM İçin Neden Sorundur?

DAM dbadmin hesabını görür.

Ama hesabı hangi kişinin kullandığını bilemeyebilir.

Bu nedenle kişiye özel account önemlidir.

### PAM ve DAM Birlikte Kullanılmalı mı?

Kritik ortamlarda çok faydalıdır.

PAM:

#### Kim privileged session açtı?

DAM:

#### Database içerisinde ne yaptı?

sorularını cevaplar.

### Örnek PAM + DAM Akışı

DBA access request açar.

↓

Manager onaylar.

↓

PAM session başlatır.

↓

DAM database query'lerini izler.

↓

SIEM olayları korele eder.

Bu güçlü accountability sağlar.

### JIT Access DAM'i Tamamlar mı?

Evet.

JIT erişim süresini sınırlar.

DAM erişim sırasında yapılan işlemleri izler.

### Database Firewall ile DAM Aynı mı?

Hayır.

Database Firewall belirli query veya connection'ları engellemeye odaklanabilir.

DAM daha geniş monitoring ve analytics sağlar.

### DAM Blocking Kullanılabilir mi?

Bazı çözümlerde evet.

Örneğin;

yasaklı query,

unexpected user,

critical table access

engellenebilir.

### Blocking Policy Neden Dikkatli Kullanılmalı?

False positive production outage oluşturabilir.

### Monitor First, Block Later Yaklaşımı Nedir?

Önce davranış izlenir.

Policy doğrulanır.

Daha sonra yüksek güvenilirlikli kurallar blocking moduna alınabilir.

### DAM ve SQL Injection

DAM bazı SQL Injection belirtilerini query seviyesinde görebilir.

### DAM SQL Injection'ı Önler mi?

Tek başına hayır.

Secure coding temel kontroldür.

DAM detection katmanıdır.

### SQL Injection Sonrası DAM Ne Görebilir?

Application account'un normalden farklı;

table,

query type,

data volume

erişimlerini gösterebilir.

### DAM ve Ransomware

Ransomware database'e doğrudan SQL üzerinden saldırmayabilir.

Ancak mass delete veya destructive database activity izlenebilir.

### Mass DELETE Alarmı Üretilmeli mi?

Kritik production sistemlerde evet.

### Mass UPDATE Neden Risklidir?

Büyük miktarda verinin kısa sürede değiştirilmesi integrity incident olabilir.

### DROP TABLE Real-Time Alert Olmalı mı?

Kritik sistemlerde yüksek severity event olarak değerlendirilebilir.

### Database Schema Change Monitoring Nedir?

CREATE, ALTER ve DROP işlemlerinin izlenmesidir.

### Unexpected Schema Change Ne Gösterebilir?

Yetkisiz administrator aktivitesi veya compromise ihtimali olabilir.

### DAM Audit Disable Olayını Görebilir mi?

Ürün mimarisine göre audit/configuration değişiklikleri izlenebilir.

### Audit Disable Neden Critical Event'tir?

Saldırgan iz bırakmamak için logging'i devre dışı bırakabilir.

### DAM Bypass Edilebilir mi?

Her güvenlik kontrolü gibi uygun mimari kurulmazsa bypass riski olabilir.

Bu nedenle DAM agent, collector ve policy'leri de korunmalıdır.

### DAM Administrator Kim Olmalı?

Mümkün olduğunca DBA'dan bağımsız security ekibi tarafından yönetilmesi Separation of Duties sağlayabilir.

### DBA DAM Loglarını Silebilmeli mi?

Mümkünse hayır.

### DAM Logs Immutable Olmalı mı?

Kritik audit verisi için değiştirilmeye karşı koruma değerlendirilebilir.

### DAM Retention Nedir?

Database activity kayıtlarının ne kadar süre saklanacağını belirler.

### DAM Retention Nasıl Belirlenmeli?

Risk,

forensic requirement,

storage,

regulatory need

birlikte değerlendirilmelidir.

### DAM Çok Fazla Veri Üretir mi?

Evet.

Yoğun transaction database'lerinde çok yüksek event hacmi olabilir.

### Full Query Capture Her Database İçin Uygun mu?

Her zaman değil.

Risk bazlı capture uygulanabilir.

### Sensitive Query Capture Nedir?

Sadece belirli kritik kullanıcı, database veya tablo aktivitelerinin detaylı kaydedilmesidir.

### Query Parametreleri Loglanmalı mı?

Hassas veri içerebilir.

Bu nedenle masking veya filtering uygulanmalıdır.

### DAM Privacy Riski Oluşturabilir mi?

Evet.

Monitoring sistemi kendisi de hassas database sorgularını saklayabilir.

Bu nedenle DAM repository'si de korunmalıdır.

### DAM Repository Nasıl Korunmalı?

Encryption,

RBAC,

MFA,

audit,

backup

uygulanmalıdır.

### DAM High Availability Neden Önemlidir?

Monitoring sistemi down olursa visibility kaybı oluşabilir.

### DAM Outage Database'i Durdurmalı mı?

Deployment modeline göre karar verilmelidir.

Inline sistemlerde fail-open/fail-close tasarımı kritik olabilir.

### Fail-Open Nedir?

DAM arızalandığında database trafiğinin devam etmesidir.

Availability korunur ancak monitoring kaybı oluşabilir.

### Fail-Close Nedir?

DAM arızalandığında trafik engellenir.

Security artabilir ancak production outage riski vardır.

### Hangisi Tercih Edilmeli?

Business impact ve risk değerlendirmesine göre belirlenmelidir.

### DAM Health Monitoring Nedir?

DAM'in kendisinin;

collector,

agent,

storage,

policy

sağlığının izlenmesidir.

### Agent Offline Alarmı Gerekli mi?

Evet.

Database activity aniden sıfıra düştüğünde “saldırı yok” değil “telemetry yok” olabilir.

### DAM Coverage Nedir?

Kurum database'lerinin ne kadarının DAM ile izlendiğini gösterir.

### DAM Coverage KPI Nedir?

Örneğin:

Critical Database DAM Coverage = %100

hedeflenebilir.

### Sensitive Database Coverage Nedir?

Hassas veri içeren database'lerin ne kadarının monitoring altında olduğunu gösterir.

### Privileged User Monitoring Coverage Nedir?

DBA hesaplarının yüzde kaçının aktivitelerinin DAM ile izlendiğini gösterir.

### DAM Policy Coverage Nedir?

Belirlenen security use case'lerin ne kadarının aktif policy ile izlendiğini ölçer.

### DAM Use Case Nedir?

Belirli database security riskini tespit etmek için oluşturulan detection senaryosudur.

### Önemli DAM Use Case'leri

Örnekler:

Privileged user unusual access

Sensitive table bulk SELECT

New superuser creation

Mass DELETE

Database export outside schedule

Dormant user login

Service account from new IP

Audit disabled

Schema change outside maintenance window

### DAM Use Case 1 – DBA Sensitive Data Access

DBA normalde database maintenance yapıyor.

Bir gün customer PII tablosunda milyonlarca satır sorguluyor.

DAM bunu behavioral anomaly olarak tespit edebilir.

### DAM Use Case 2 – Compromised Service Account

Application account normalde sadece application server IP'sinden bağlanıyor.

Bir gün farklı workstation IP'sinden login oluyor.

High-risk alert üretilebilir.

### DAM Use Case 3 – Bulk Data Exfiltration

Normal user ortalama 1.000 row okuyor.

Bir session içerisinde 5 milyon row okunuyor.

DAM high-volume data access alarmı üretebilir.

### DAM Use Case 4 – Privilege Escalation

Normal kullanıcıya DBA veya elevated role atanıyor.

Bu yüksek severity event olarak SIEM'e gönderilebilir.

### DAM Use Case 5 – Audit Evasion

Audit veya monitoring configuration değiştiriliyor.

Bu defense evasion davranışı olarak değerlendirilebilir.

### DAM Use Case 6 – Production Export

Production database'in tamamı mesai dışında export ediliyor.

Bu işlem change veya backup job ile eşleşmiyorsa araştırılabilir.

### DAM ile Ticket Entegrasyonu

Change veya access ticket bilgileri alert context'e eklenebilir.

### Ticket Context Neden Faydalıdır?

Gece yapılan schema değişikliği saldırı gibi görünebilir.

Ancak onaylı maintenance ticket varsa normal olabilir.

### DAM ve CMDB Entegrasyonu

Database asset'in;

owner,

criticality,

environment

bilgileri CMDB'den alınabilir.

### CMDB DAM Severity'yi Nasıl Etkiler?

Production payment database alert'i ile development test database alert'i aynı severity olmamalıdır.

### DAM ve Data Classification Entegrasyonu

Sensitive table bilgileri DLP veya data classification sisteminden alınabilir.

### DAM ve DLP Arasındaki Fark

DAM database içerisindeki erişimi izler.

DLP verinin endpoint, e-mail veya cloud üzerinden hareketini izler.

### DAM + DLP Birlikte Nasıl Çalışır?

DAM:

User 2 milyon customer record okudu.

DLP:

Aynı kullanıcı CSV dosyasını dışarı göndermeye çalıştı.

SIEM:

Olayları korele etti.

Bu çok daha güçlü detection sağlar.

### DAM ve NDR Entegrasyonu

NDR database'e gelen sıra dışı network connection'ı tespit edebilir.

DAM connection sonrasında yapılan query davranışını gösterebilir.

### DAM ve EDR Entegrasyonu

EDR endpoint compromise'ı gösterir.

DAM o endpoint'ten database erişimini gösterebilir.

### DAM ve IAM Entegrasyonu

Identity bilgileri database user mapping için kullanılabilir.

### DAM ve Active Directory

AD user ile database login ilişkisi kurulabilirse incident investigation kolaylaşır.

### DAM ve Cloud IAM

Cloud database erişiminde cloud identity ve database activity birlikte değerlendirilebilir.

### Cloud Database DAM Nedir?

Managed database servislerindeki aktivitelerin merkezi olarak izlenmesidir.

### Cloud Database'te DAM Gerekli mi?

Managed olması database activity riskini ortadan kaldırmaz.

### Cloud Control Plane ile DAM Birlikte İzlenmeli mi?

Evet.

Örneğin:

Cloud IAM → Public Access Enabled

DAM → Unknown IP Login

DAM → Bulk Data Read

olayları birlikte çok güçlü sinyal oluşturur.

### Database Public Exposure DAM ile Tespit Edilir mi?

DAM activity'yi gösterebilir.

Network ve cloud security araçları exposure'ı daha iyi belirler.

### DAM Database Vulnerability Scanner mıdır?

Hayır.

DAM activity monitoring yapar.

Vulnerability scanner configuration ve vulnerability arar.

### DAM ile Database Security Assessment Farkı

Assessment:

#### Sistem ne kadar güvenli yapılandırılmış?

DAM:

#### Sistemde ne oluyor?

sorusunu cevaplar.

### DAM Patch Management Yapmaz

Doğru.

DAM patch uygulamaz.

Ancak exploit sonrası anormal aktiviteleri tespit etmeye yardımcı olabilir.

### DAM Backup Yerine Geçmez

Doğru.

DAM data activity monitoring sağlar.

Recovery sağlamaz.

### DAM Encryption Yerine Geçmez

Doğru.

Encryption veriyi korur.

DAM erişimi izler.

### DAM PAM Yerine Geçmez

Doğru.

PAM privileged access'i kontrol eder.

DAM database içindeki davranışı izler.

### Güçlü Database Security Stack

Örnek yapı:

#### IAM

↓

#### MFA

↓

#### PAM / JIT

↓

#### RBAC / Least Privilege

↓

#### Database Hardening

↓

#### Encryption

↓

#### DAM

↓

#### SIEM / SOC

↓

#### Backup / Recovery

Bu katmanların tamamı farklı riskleri azaltır.

### DAM Deployment Projesi Nasıl Başlatılır?

İlk adım ürün kurmak olmamalıdır.

Öncelikle;

database inventory,

criticality,

data classification,

use case

belirlenmelidir.

### DAM Projesi İçin Örnek Aşamalar

- Database envanteri çıkarılır.
- Kritik database'ler belirlenir.
- Hassas veri sınıflandırılır.
- Privileged account'lar listelenir.
- Monitoring mimarisi seçilir.
- DAM collector/agent kurulur.
- Learning period başlatılır.
- Policy tuning yapılır.
- SIEM entegrasyonu yapılır.
- SOC use case'leri devreye alınır.

### İlk Önce Hangi Database'ler DAM'e Alınmalı?

Risk bazlı olarak;

müşteri,

finans,

personel,

ödeme,

authentication

verisi içeren production sistemler önceliklendirilebilir.

### DAM Proof of Concept Nasıl Yapılmalı?

Sadece ürünün log ürettiği gösterilmemelidir.

Gerçek use case'ler test edilmelidir.

### DAM POC'de Ne Test Edilebilir?

Örneğin:

DBA login tespiti

Sensitive table access

Bulk SELECT

User creation

Role grant

SIEM alert latency

### DAM Performans Testi Gerekli mi?

Evet.

Production'a yakın workload altında etkisi ölçülmelidir.

### DAM Alert Latency Nedir?

Database aktivitesi ile alert oluşması arasındaki süredir.

### Data Exfiltration Use Case'inde Latency Neden Önemlidir?

Dakikalar içinde milyonlarca kayıt dışarı çıkabilir.

### DAM SLA Tanımlanabilir mi?

Evet.

Critical event'lerin SOC'a ne kadar sürede ulaşacağı tanımlanabilir.

### DAM Incident Response Sürecine Nasıl Bağlanmalı?

Critical DAM alert otomatik incident oluşturabilir.

### Örnek DAM Incident Akışı

DAM Alert

↓

SIEM Correlation

↓

SOC Triage

↓

User/Asset Context

↓

Database Investigation

↓

Containment

↓

Incident Response

### DAM Alert Sonrası Hesap Otomatik Kapatılmalı mı?

Her event için değil.

Yüksek güvenilirlikli use case'lerde SOAR ile otomasyon değerlendirilebilir.

### SOAR DAM ile Kullanılabilir mi?

Evet.

### SOAR Nedir?

Security Orchestration, Automation and Response olaylara otomatik veya yarı otomatik müdahale sağlar.

### DAM + SOAR Örneği

Critical DAM alert:

Unexpected DBA + Bulk PII Read.

SOAR:

PAM session terminate.

User risk increase.

Incident create.

SOC notify.

Bu kontrollü otomasyon olabilir.

### Otomatik Blocking Riskli mi?

Evet.

Yanlış pozitif kritik iş sürecini durdurabilir.

Bu nedenle onay mekanizması kullanılabilir.

### DAM Maturity Model

#### Seviye 1 – Visibility Yok

Database aktiviteleri merkezi izlenmez.

#### Seviye 2 – Native Logs

Database audit logları bulunur.

#### Seviye 3 – Central Monitoring

DAM veya merkezi monitoring kullanılır.

#### Seviye 4 – Behavioral Detection

Anomaly ve sensitive data use case'leri vardır.

#### Seviye 5 – Automated Response

DAM + SIEM + PAM + SOAR entegre çalışır.

### DAM KPI'ları Nelerdir?

Örneğin:

Critical Database Coverage

Privileged User Coverage

Sensitive Data Coverage

Alert Response Time

False Positive Rate

Policy Coverage

DAM Availability

### False Positive Rate Nedir?

Üretilen alertlerin ne kadarının gerçek risk oluşturmadığını ölçer.

### Çok Düşük Alert Sayısı İyi mi?

Her zaman değil.

Monitoring eksik veya policy fazla dar olabilir.

### DAM Coverage Raporu Yönetim İçin Faydalı mı?

Evet.

Örneğin:

Critical Database: 24

DAM Monitored: 22

Coverage: %91,7

gibi rapor oluşturulabilir.

### DAM İçin Yönetimin Sorması Gereken Sorular

Yönetim şu sorulara cevap alabilmelidir:

Kaç kritik database'imiz var?

Kaçı DAM altında?

DBA aktivitelerini izleyebiliyor muyuz?

Sensitive data tablolarını biliyor muyuz?

Bir kullanıcı milyonlarca kayıt çekerse alarm alıyor muyuz?

Database export edildiğinde fark ediyor muyuz?

DAM loglarını kim yönetiyor?

DAM event'leri SIEM/SOC'a gidiyor mu?

### Database Activity Monitoring'de En Sık Yapılan Hatalar

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

- DAM'i sadece compliance için kurmak
- Database envanteri çıkarmadan deployment yapmak
- Hassas veri sınıflandırmamak
- Tüm query'lere aynı risk seviyesini vermek
- Privileged kullanıcıları özel izlememek
- Shared DBA account kullanmak
- Learning period yapmamak
- Policy tuning yapmamak
- Çok fazla false positive üretmek
- DAM'i SIEM'e entegre etmemek
- DAM administrator'ı DBA ile aynı role vermek
- DAM loglarını korumamak
- Agent health'i izlememek
- Sadece on-prem database'leri kapsamak
- DR database'lerini monitoring dışında bırakmak

### PostgreSQL DAM Yaklaşımı

PostgreSQL ortamlarında DAM;

native log,

audit extension,

network veya agent-based telemetry

üzerinden activity toplayabilir.

Özellikle;

superuser,

role changes,

critical table access,

connection behavior

izlenebilir.

### MSSQL DAM Yaklaşımı

Microsoft SQL Server ortamlarında;

SQL Server Audit,

Extended Events,

network activity

gibi kaynaklar DAM ile ilişkilendirilebilir.

### Oracle DAM Yaklaşımı

Oracle ortamlarında native audit, Unified Auditing ve database activity kaynakları DAM ile kullanılabilir.

### Çoklu Database Platformu DAM İçin Neden Önemlidir?

Büyük kurumlarda farklı database teknolojileri bulunabilir.

DAM ortak monitoring katmanı sağlayarak güvenlik ekiplerine tek görünüm sunabilir.

### Merkezi DAM Dashboard Neler Gösterebilir?

Örneğin:

Top Privileged Users

Critical Alerts

Sensitive Database Access

Failed Login Trend

Top Data Volume Users

New Database Discovery

### Database Security Dashboard Yönetim İçin Nasıl Olmalı?

SQL query detayından çok;

risk,

coverage,

incident,

trend

göstermelidir.

### DAM ve KVKK

Kişisel verilerin bulunduğu database'lerde erişimlerin izlenebilir olması veri güvenliği sürecine katkı sağlar.

DAM;

kim,

ne zaman,

hangi hassas veriye

eriştiğinin takip edilmesini destekleyebilir.

Ancak DAM tek başına KVKK uyumu sağlamaz.

### DAM ve ISO/IEC 27001

ISO/IEC 27001 perspektifinde logging, monitoring, access control ve security event management önemli alanlardır.

DAM database seviyesinde bu kontrolleri destekler.

### DAM ve PCI DSS

Kart verisinin bulunduğu ortamlarda privileged access ve data activity monitoring önemli güvenlik ihtiyaçlarından biridir.

### DAM ile Forensic Investigation

Incident sonrası hangi account'un hangi sorguları çalıştırdığı araştırılabilir.

### DAM Forensic Timeline'a Katkı Sağlar mı?

Evet.

Database event'leri diğer loglarla zaman sırasına alınabilir.

### Örnek Forensic Timeline

02:58 → EDR credential alert

03:02 → Privileged DB login

03:04 → Customer table access

03:08 → 2.8 million rows read

03:11 → Database export

03:13 → Outbound network anomaly

Bu zincir incident scope'u anlamayı kolaylaştırır.

### DAM Logları Olmazsa Ne Kaybederiz?

Database üzerinde gerçekleştirilen aktivitelerin detayını kaybedebiliriz.

Bu da incident investigation'ı zorlaştırır.

### Sık Sorulan Sorular

#### DAM nedir?

Database Activity Monitoring, veritabanı aktivitelerini güvenlik amacıyla merkezi olarak izleyen ve analiz eden yaklaşımdır.

#### DAM ile database audit aynı mı?

Hayır. Native audit olayları kaydederken DAM bunları merkezi olarak analiz edip anomaly ve security alert üretebilir.

#### DAM DBA'yı izler mi?

Evet. Privileged user monitoring DAM'in en önemli use case'lerinden biridir.

#### DAM SQL Injection'ı engeller mi?

Tek başına hayır. Ancak anormal query davranışını tespit etmeye yardımcı olabilir.

#### DAM veri sızıntısını tespit eder mi?

Bulk read, export ve unusual sensitive data access gibi sinyalleri tespit etmeye yardımcı olabilir.

#### DAM SIEM'in yerine geçer mi?

Hayır. DAM database-specific visibility sağlar; SIEM farklı kaynakları merkezi olarak korele eder.

#### DAM ve PAM birlikte kullanılmalı mı?

Kritik ortamlarda oldukça faydalıdır. PAM erişimi kontrol eder, DAM database içerisinde yapılan aktiviteleri izler.

#### DAM performansı etkiler mi?

Deployment yöntemine göre etkileyebilir. Bu nedenle production öncesi performans testi yapılmalıdır.

#### DAM tüm query'leri kaydetmeli mi?

Her zaman değil. Risk ve veri hassasiyetine göre audit policy oluşturulmalıdır.

#### DAM cloud database'lerde kullanılabilir mi?

Evet. Ürün ve cloud servisi desteğine göre managed database aktiviteleri izlenebilir.

### Sonuç: Yetkili Olmak Her Aktivitenin Normal Olduğu Anlamına Gelmez

Database güvenliğinin en önemli gerçeklerinden biri şudur:

Bir kullanıcının teknik olarak yetkili olması, yaptığı her işlemin güvenli veya iş açısından gerekli olduğu anlamına gelmez.

DBA customer database'e erişebilir.

Ancak gece milyonlarca kişisel veri sorgulaması normal olmayabilir.

Application account database'e bağlanabilir.

Ancak farklı bir IP'den bağlanması normal olmayabilir.

Reporting user SELECT yapabilir.

Ancak tüm database'i export etmesi normal olmayabilir.

Bu nedenle modern database security yalnızca:

#### Access Control

ile sınırlı olmamalıdır.

Erişim sonrasında gerçekleştirilen davranış da izlenmelidir.

DAM'in temel amacı budur.

Güçlü bir Database Activity Monitoring mimarisi;

**Database Discovery,**

**Sensitive Data Classification,**

**Privileged User Monitoring,**

**Query Analysis,**

**Behavioral Analytics,**

**Anomaly Detection,**

**Data Exfiltration Detection,**

#### SIEM Integration

ve **Incident Response**

süreçlerini bir araya getirir.

En önemli güvenlik zinciri şu şekilde düşünülebilir:

#### IAM

↓

#### MFA

↓

#### PAM

↓

#### RBAC

↓

#### Database

↓

#### DAM

↓

#### SIEM

↓

#### SOC

↓

#### Incident Response

Burada DAM kritik bir noktada bulunur.

Çünkü database'in içerisinde gerçekte ne olduğunu güvenlik ekibine görünür hale getirir.

Bu nedenle kurumsal database security açısından doğru soru:

**“Kullanıcı bu veriye erişmeye yetkili mi?”**

değil sadece;

aynı zamanda:

**“Bu erişim normal mi, gerekli mi ve olağan davranışla uyumlu mu?”**

olmalıdır.

Bir kurum şu soruya güvenilir şekilde cevap verebiliyorsa:

**“DBA hassas müşteri verisini iş amacı dışında sorgularsa bunu fark eder miyiz?”**

database güvenliğinde önemli bir olgunluk seviyesine ulaşmış demektir.

Gerçek DAM yaklaşımı şu dört kelimeyle özetlenebilir:

**Visibility + Context + Detection + Response**

#### Sıradaki Bölüm

#### PostgreSQL, MSSQL ve Oracle Güvenliği: Kritik Yapılandırmalar ve Farklar

Bir sonraki bölümde vendor bağımsız database security yaklaşımından üç önemli kurumsal veritabanı platformuna geçeceğiz.

**PostgreSQL Security, Microsoft SQL Server Security, Oracle Database Security, Authentication, Superuser/SA/SYS Accounts, Network Security, TLS, Auditing, Encryption, Patch Management, Backup ve Hardening** başlıklarını karşılaştırmalı olarak ele alacağız.

Ayrıca şu soruya cevap vereceğiz:

**“PostgreSQL, MSSQL ve Oracle için güvenlik yaklaşımı aynı mı; yoksa her platformun ayrı kritik noktaları mı var?”**