# Database Activity Monitoring – DAM Nedir? Veritabanı Erişimlerinin İzlenmesi ve Hassas Veri Koruması

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/veri-guvenligi-siniflandirma/dam-ile-hassas-veri-korumasi

![Database Activity Monitoring – DAM Nedir? Veritabanı Erişimlerinin İzlenmesi ve Hassas Veri Koruması](/images/bilgi-merkezi/covers/cover-veriguv-07.webp)

Database Activity Monitoring, kısaca **DAM**, veritabanları üzerinde gerçekleştirilen erişimlerin, sorguların, kullanıcı aktivitelerinin ve kritik işlemlerin izlenmesini, analiz edilmesini ve gerektiğinde güvenlik olayı olarak değerlendirilmesini sağlayan veri güvenliği yaklaşımıdır. Türkçede **veritabanı aktivite izleme** veya **veritabanı erişimlerinin izlenmesi** olarak ifade edilebilen DAM, özellikle kritik ve hassas verilerin tutulduğu database sistemlerinde önemli bir güvenlik katmanıdır.

Bir kurum veritabanını şifrelemiş olabilir. Kullanıcı erişimleri IAM, PAM veya RBAC ile kontrol altına alınmış olabilir. Ancak yetkili bir kullanıcının veritabanına girdikten sonra hangi sorguları çalıştırdığını, hangi tabloları okuduğunu, kaç kayıt dışarı çıkardığını veya hassas alanlara olağan dışı şekilde erişip erişmediğini görmek için farklı bir güvenlik katmanına ihtiyaç vardır.

DAM tam olarak bu noktada devreye girer.

Modern Database Activity Monitoring yaklaşımının temel sorusu şudur:

**“Veritabanına kim erişti, ne yaptı, hangi veriyi okudu, ne kadar veri çıkardı ve bu davranış normal miydi?”**

Bu nedenle DAM yalnızca database loglarını toplamak değildir. Asıl amaç veritabanı aktivitelerini **identity, data sensitivity, privilege level, query behavior ve risk context** ile birlikte değerlendirerek anlamlı güvenlik görünürlüğü oluşturmaktır.

### DAM Nedir?

Database Activity Monitoring, database üzerinde gerçekleşen aktivitelerin sürekli veya düzenli şekilde izlenmesini sağlayan güvenlik kontrolüdür.

DAM ile genel olarak şu tür aktiviteler izlenebilir:

User Login

Database Connection

SQL Query

Table Access

Column Access

Data Modification

Bulk Export

Privilege Change

Schema Change

Administrative Activity

Failed Access

gibi işlemler.

Amaç yalnızca “kim giriş yaptı?” sorusuna cevap vermek değildir.

Asıl amaç:

**“Giriş yaptıktan sonra ne yaptı?”**

sorusunu cevaplamaktır.

### Database Activity Monitoring Neden Gereklidir?

Veritabanları genellikle kurumların en kritik bilgilerinin merkezi deposudur.

Müşteri bilgileri,

çalışan verileri,

finansal kayıtlar,

ödeme bilgileri,

ticari sırlar,

kimlik bilgileri,

işlem kayıtları

çoğu zaman database içerisinde tutulur.

Bu nedenle database compromise durumunda etki çok yüksek olabilir.

Saldırgan açısından veritabanına erişmek, kurumun en değerli verilerine doğrudan ulaşmak anlamına gelebilir.

Yetkili kullanıcı açısından ise fazla yetki büyük miktarda hassas veriye erişim imkânı sağlayabilir.

Bu nedenle database security yalnız authentication ve encryption ile sınırlı olmamalıdır.

### Database Audit ile DAM Arasındaki Fark Nedir?

Database Audit, veritabanı tarafından üretilen native audit logs üzerinden activity kayıtlarının tutulmasını ifade eder.

DAM ise bu aktiviteleri daha merkezi, davranışsal ve güvenlik odaklı şekilde analiz etmeye çalışır.

Native database audit:

“User X, Table Y üzerinde SELECT yaptı.”

diyebilir.

DAM ise buna şunları ekleyebilir:

Bu tablo Restricted Data içeriyor.

User normalde bu tabloya erişmiyor.

Saat 03:00'te erişim gerçekleşti.

500.000 kayıt sorgulandı.

Bu nedenle event high-risk olabilir.

Bu context DAM'i daha değerli hale getirir.

### Native Database Logging Yeterli midir?

Her zaman değil.

Native logging önemli ve gereklidir.

Ancak farklı database technologies farklı log formats üretir.

Bir kurumda:

Oracle

PostgreSQL

MSSQL

MySQL

MongoDB

gibi farklı systems bulunabilir.

Bu logs'un merkezi şekilde normalize edilmesi ve security context ile analiz edilmesi zor olabilir.

DAM bu heterojen ortamda merkezi visibility sağlayabilir.

### DAM Hangi Veritabanlarını İzler?

DAM yaklaşımı relational ve bazı non-relational database environments'da uygulanabilir.

Örneğin:

Oracle

Microsoft SQL Server

PostgreSQL

MySQL

MariaDB

DB2

NoSQL databases

cloud databases

gibi environments monitoring kapsamına alınabilir.

Teknik yöntem platforma göre değişebilir.

Ancak security objective aynıdır:

**Database activity visibility.**

### DAM Nasıl Çalışır?

DAM farklı deployment yöntemleri kullanabilir.

Örneğin:

Agent-Based Monitoring

Network-Based Monitoring

Proxy-Based Monitoring

Native Audit Log Collection

API-Based Monitoring

gibi approaches bulunabilir.

Her yöntemin visibility, performance ve deployment trade-off'ları vardır.

### Agent-Based DAM Nedir?

Agent-Based DAM, database server veya host üzerinde agent kullanarak activities'i izler.

Bu yaklaşım encrypted local database traffic veya host-level events için güçlü visibility sağlayabilir.

Avantajı detailed activity monitoring olabilir.

Ancak server üzerinde agent deployment ve maintenance gerektirir.

### Network-Based DAM Nedir?

Network-Based DAM, database traffic'i network üzerinden analiz eder.

Bu approach database server'a agent kurmadan monitoring sağlayabilir.

Ancak encrypted database traffic visibility'yi sınırlayabilir.

Bu nedenle modern environments'da network-only monitoring her zaman yeterli olmayabilir.

### Proxy-Based DAM Nedir?

Proxy-Based DAM modelinde database connections bir proxy üzerinden geçirilir.

Proxy activity'yi inspect ve policy enforcement yapabilir.

Bu strong control sağlayabilir.

Ancak architecture'a inline component eklediği için availability ve performance dikkatle planlanmalıdır.

### Native Audit Log Collection

DAM platformları database'in native audit logs'unu toplayabilir.

Bu low-impact deployment sağlar.

Ancak available information database configuration'a bağlıdır.

Audit policy yeterince detaylı değilse visibility sınırlı kalabilir.

### SQL Activity Monitoring Nedir?

SQL Activity Monitoring, database üzerinde çalıştırılan SQL statements'in izlenmesini ifade eder.

Örneğin:

SELECT

INSERT

UPDATE

DELETE

ALTER

DROP

GRANT

REVOKE

gibi statements analiz edilebilir.

Bu query-level visibility database security için kritik değerdedir.

### SELECT Sorgusu Neden Güvenlik Riski Olabilir?

SELECT read-only işlem gibi görünebilir.

Ancak büyük miktarda sensitive data dışarı çıkarılabilir.

Örneğin:

SELECT * FROM CUSTOMERS

sorgusu milyonlarca customer record döndürebilir.

Bu nedenle yalnız DELETE veya DROP gibi destructive actions değil büyük SELECT operations da izlenmelidir.

### Bulk Data Export Nedir?

Bulk Data Export, büyük miktarda database record'un tek seferde veya kısa sürede dışarı çıkarılmasıdır.

Bu legitimate olabilir.

Örneğin reporting process büyük dataset çekebilir.

Ancak attacker veya malicious insider de bulk export kullanabilir.

Bu nedenle DAM:

Data Volume

User Identity

Time

Table Sensitivity

Historical Behavior

context'ini değerlendirmelidir.

### Büyük Sorgu Her Zaman Saldırı mıdır?

Hayır.

Bir BI application her gece 10 milyon record okuyabilir.

Bu normal olabilir.

Aynı operation standard employee account tarafından gece 03:00'te gerçekleştirilirse farklı değerlendirilmelidir.

Bu nedenle static thresholds tek başına yeterli değildir.

Behavioral baseline gerekir.

### Database Anomaly Detection Nedir?

Database Anomaly Detection, normal database activity pattern'larının dışındaki davranışları tespit etmeye çalışır.

Örneğin user normalde:

Finance tables

üzerinde çalışıyor.

Bir gün:

HR Salary Table

üzerinde query çalıştırıyor.

Bu unusual access olabilir.

Benzer şekilde login time, query volume ve source location da anomaly signal olabilir.

### User Behavior Analytics Database İçin Nasıl Kullanılır?

Behavior analytics kullanıcıların normal access patterns'ını öğrenebilir.

Örneğin:

User A normally queries 100–500 rows/day.

Bir gün 1.5 million rows query ederse risk score yükseltilebilir.

Bu DAM + UEBA yaklaşımıdır.

### Sensitive Table Monitoring

Her table aynı risk seviyesinde değildir.

Örneğin:

Public Product Catalog

ile:

Customer Credit Card Table

aynı monitoring priority'sine sahip olmamalıdır.

Data Classification burada critical context sağlar.

Restricted tables için daha sıkı alerting uygulanabilir.

### Sensitive Column Monitoring

Table'ın tamamı sensitive olmayabilir.

Örneğin customer table içerisinde:

Name

Email

Identity Number

Credit Card

fields bulunabilir.

Credit Card ve Identity Number daha yüksek sensitivity taşıyabilir.

Column-level monitoring bu access'i ayrı değerlendirebilir.

### DAM ve Data Classification

Data Classification DAM alert'lerinin anlamını ciddi biçimde artırır.

Örneğin:

User accessed Table X

tek başına bilgi sağlar.

Ancak:

User accessed Restricted Customer Data

çok daha anlamlıdır.

Bu nedenle DAM mümkün olduğunca data classification context ile entegre edilmelidir.

### DAM ve Data Discovery

Data Discovery sensitive tables ve columns'ı belirler.

DAM ise bu data'ya kimin eriştiğini izler.

Bu iki katman birlikte:

#### Where is sensitive data?

ve:

#### Who is using it?

sorularını cevaplar.

### DBA Kimdir?

DBA, yani Database Administrator, veritabanlarının kurulumu, performansı, backup, erişim ve bakım süreçlerinden sorumlu teknik roldür.

DBA genellikle yüksek permissions'a sahiptir.

Bu nedenle database security açısından privileged identity olarak değerlendirilmelidir.

### DBA Yetkileri Neden Risklidir?

DBA sistemin çalışması için broad access'e ihtiyaç duyabilir.

Ancak bu permissions sensitive data'ya erişim de sağlayabilir.

Örneğin DBA:

salary records

customer data

financial information

görebilir.

Teknik yetki ile business authorization aynı şey değildir.

Bu nedenle DBA activities izlenmelidir.

### Privileged DBA Monitoring Nedir?

Privileged DBA Monitoring, yüksek yetkili database administrators tarafından gerçekleştirilen activities'in detaylı şekilde izlenmesidir.

Özellikle şu actions önemlidir:

User Creation

Privilege Grant

Audit Disable

Table Export

Bulk SELECT

Schema Modification

Data Deletion

Bu events high-risk olabilir.

### DBA Audit'i Devre Dışı Bırakabilir mi?

Broad privilege sahibi DBA audit configuration üzerinde değişiklik yapabiliyorsa log visibility etkilenebilir.

Bu nedenle audit controls mümkün olduğunca separation of duties prensibiyle korunmalıdır.

Database administrator ile security monitoring administrator rolleri ayrılabilir.

### Separation of Duties Database Security'de Neden Önemli?

Tek bir user:

Database Administrator

Audit Administrator

Security Administrator

rollerine sahipse büyük risk oluşabilir.

User hem activity yapıp hem logları değiştirebilir.

Bu nedenle duties separation uygulanmalıdır.

### DAM ve PAM Birlikte Nasıl Çalışır?

PAM privileged access session'ını kontrol eder.

DAM ise database içerisinde gerçekleştirilen SQL activity'yi izler.

Örneğin:

PAM:

DBA login session başladı.

DAM:

DBA SELECT * FROM CUSTOMER çalıştırdı.

Bu combined visibility güçlü accountability sağlar.

### PAM Session Recording ile DAM Aynı Şey midir?

Hayır.

PAM screen veya terminal session recording yapabilir.

DAM database-level query activity'yi görür.

PAM user activity context'i sağlar.

DAM data-level activity context'i sağlar.

Bu nedenle birbirini tamamlarlar.

### Just-in-Time DBA Access

DBA accounts permanent privileged access taşımak zorunda değildir.

PAM üzerinden:

On-Demand Access

Approval

Time-Limited Session

sağlanabilir.

DAM ise bu session boyunca query activities'i izleyebilir.

Bu Zero Standing Privilege yaklaşımıdır.

### Database Service Account Monitoring

Database'e yalnız humans erişmez.

Applications ve services da service accounts kullanır.

Bu accounts büyük data access'e sahip olabilir.

Normalden farklı query behavior compromise göstergesi olabilir.

DAM machine identities'i de izlemelidir.

### Application Account Neden Risklidir?

Application database credential compromise edilirse attacker application'ın erişebildiği data'ya ulaşabilir.

Bu account genellikle sürekli aktiftir ve automation nedeniyle yüksek query volume normal görünebilir.

Bu nedenle baseline kritik önemdedir.

### Shared Database Account

Birden fazla kişi aynı database account'u kullanırsa accountability kaybolur.

Örneğin:

dbaadmin

hesabını 5 farklı DBA kullanıyorsa hangi kişinin hangi query'yi çalıştırdığı zor anlaşılır.

Bu nedenle individual identities veya PAM-based checkout kullanılmalıdır.

### Database Login Monitoring

Database login events temel security signals arasındadır.

Örneğin:

Failed Logins

New Source IP

Unusual Login Time

New Application

gibi patterns izlenebilir.

Ancak login monitoring tek başına yeterli değildir.

Post-login behavior da analiz edilmelidir.

### Failed Database Login

Çok sayıda failed login credential attack göstergesi olabilir.

Ancak misconfigured application da aynı pattern'i oluşturabilir.

Bu nedenle context önemlidir.

DAM ve SIEM correlation bu ayrımı destekleyebilir.

### Database Brute Force

Attacker database credentials üzerinde brute-force veya password spraying uygulayabilir.

Repeated failed authentication detect edilmelidir.

Firewall veya database access control bu source'u block edebilir.

### Direct Database Access Neden Riskli?

Business users mümkün olduğunca application üzerinden data'ya erişmelidir.

Direct SQL access broad visibility sağlayabilir.

Bu nedenle direct database access yalnız gerekli teknik users ile sınırlandırılmalıdır.

### Production Database Access

Production databases özellikle yüksek risk taşır.

Developers veya analysts production'a doğrudan erişiyorsa sensitive data exposure artabilir.

Mümkün olduğunda:

Read Replica

Masked Data

Test Environment

kullanılabilir.

### Production Data Test Ortamında Kullanılmalı mı?

Gerçek production data test environments'a kontrolsüz kopyalanmamalıdır.

Test environment genellikle daha düşük security seviyesine sahiptir.

Static Data Masking veya synthetic data tercih edilebilir.

DAM test environments'da da sensitive data usage'ı izleyebilir.

### Database Data Masking

DAM ile masking farklı controls'dür.

DAM activity'yi monitor eder.

Masking user'ın sensitive value'yu görmesini sınırlar.

Örneğin standard support user:

****1234

görür.

DBA full value görebilir.

Bu role-based exposure reduction sağlar.

### Dynamic Data Masking

Dynamic masking query result'ta user'ın authorization seviyesine göre sensitive fields'ı maskeler.

Bu database access security için önemlidir.

DAM hangi user'ın masked veya full data'ya eriştiğini monitor edebilir.

### Database Encryption ile DAM Arasındaki İlişki

Database encryption storage compromise'e karşı protection sağlar.

DAM ise active database usage'ı monitor eder.

Database encrypted olsa bile authorized query plaintext data döndürür.

Bu nedenle DAM encryption'ın tamamlayıcısıdır.

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

Hayır.

Transparent Data Encryption data files'ı korur.

Ancak user normal SQL query çalıştırdığında database engine data'yı decrypt eder.

DAM bu query'yi izler.

Bu iki control farklı threat scenarios'a yöneliktir.

### Database Firewall Nedir?

Database Firewall, SQL traffic üzerinde security policy uygulayabilir.

Certain queries veya source connections block edilebilir.

DAM monitoring yaparken database firewall enforcement sağlayabilir.

Bazı architectures bu capabilities'i birlikte sunabilir.

### SQL Injection ile DAM

SQL Injection application üzerinden malicious database queries çalıştırılmasına neden olabilir.

DAM unusual query patterns'i detect etmeye yardımcı olabilir.

Örneğin application normalde belirli query structure kullanırken bir anda unusual UNION veya metadata query çalışabilir.

Ancak SQL Injection prevention'ın ana katmanları secure coding, parameterized queries ve application security'dir.

DAM detection layer sağlar.

### Database Enumeration

Attacker database'e eriştikten sonra schemas, tables ve columns hakkında bilgi toplamaya çalışabilir.

System metadata queries normal user için unusual olabilir.

DAM enumeration behavior'ı detect edebilir.

### Schema Change Monitoring

Database schema üzerinde:

CREATE

ALTER

DROP

gibi commands high-impact olabilir.

Bu changes configuration management kapsamında izlenmelidir.

Unexpected schema change malicious activity göstergesi olabilir.

### DROP TABLE Neden Critical Event'tir?

DROP TABLE data availability ve integrity açısından ciddi etki oluşturabilir.

Bu nedenle production environment'ta high severity alert üretilebilir.

Ancak approved maintenance event olabilir.

Change management context alert'i zenginleştirebilir.

### Privilege Escalation Monitoring

Database içerisinde user kendi privileges'ını artırmaya çalışabilir.

Örneğin GRANT DBA veya equivalent privilege.

Bu high-risk activity'dir.

DAM privilege changes'i monitor etmelidir.

### New User Creation

Yeni database user creation güvenlik açısından izlenmelidir.

Attackers persistence amacıyla account oluşturabilir.

New users approved change records ile correlate edilebilir.

### Audit Configuration Changes

Audit logging'in disable edilmesi veya kapsamının azaltılması critical security event'tir.

Bu tamper attempt göstergesi olabilir.

DAM bu changes'i detect etmeye çalışmalıdır.

### Log Tampering

Attacker tracks'ini silmek için logs'u değiştirmeye çalışabilir.

Bu nedenle logs mümkün olduğunca centralized ve tamper-resistant environment'a gönderilmelidir.

SIEM burada önemlidir.

### DAM ve SIEM

DAM database activity telemetry üretir.

SIEM bunu:

EDR

IAM

PAM

Firewall

Cloud

signals ile correlate edebilir.

Bu attack chain visibility sağlar.

### DAM + SIEM Örnek Senaryo

Örneğin:

Identity system suspicious login detect eder.

↓

EDR endpoint compromise alert verir.

↓

DAM customer table üzerinde bulk SELECT görür.

↓

DLP external upload detect eder.

Bu events tek başına ayrı görünebilir.

SIEM correlation bunları aynı data breach attempt olarak değerlendirebilir.

### DAM ve SOC

High-risk database alerts SOC process'ine entegre edilmelidir.

Ancak bütün queries SOC alert olmamalıdır.

Risk-based use case'ler oluşturulmalıdır.

Örneğin:

Restricted Table

Privileged User

Bulk Export

Unusual Time

=

Critical Alert.

### SOC İçin DAM Use Case'leri

Örnek DAM SOC use case'leri:

Unusual DBA Access

Mass Sensitive Data Export

Failed Login Burst

Audit Disable Attempt

Privilege Escalation

New Database User

High-Risk Query

Access from Unknown Source

Restricted Table Access

After-Hours Data Extraction

olabilir.

### DAM Alert Fatigue

Her SELECT query alert oluşturursa DAM kullanılamaz hale gelir.

Bu nedenle:

Baselining

Whitelisting

Risk Scoring

Data Classification

Behavior Analytics

kullanılmalıdır.

Amaç log toplamak değil high-value detection üretmektir.

### Database Activity Baselining

Normal database behavior'ın profili çıkarılabilir.

Örneğin application:

hangi tables'a erişiyor?

hangi hours'da?

ne kadar data çekiyor?

hangi query types kullanıyor?

Bu baseline dışındaki deviations investigation tetikleyebilir.

### Static Rule ve Behavioral Rule Farkı

Static rule:

“DBA salary table'a erişirse alert.”

Behavioral rule:

“User son 90 günde hiç salary table'a erişmedi, bugün 500k kayıt okudu.”

İkinci rule daha contextual olabilir.

En iyi model ikisini birlikte kullanabilir.

### Database Risk Scoring

Risk score şu factors üzerinden oluşturulabilir:

User Privilege

Data Classification

Query Type

Data Volume

Time

Source

Historical Behavior

Device Risk

Bu contextual DAM modelidir.

### Data Volume Monitoring

Data volume data exfiltration detection için önemlidir.

Örneğin query result 10 row yerine 10 million row içeriyorsa risk artabilir.

Ancak thresholds business process'e göre belirlenmelidir.

### Result Set Monitoring

Certain DAM architectures query result size hakkında visibility sağlayabilir.

Bu mass extraction detection için değerlidir.

Örneğin user normalde small query yaparken suddenly huge result set alabilir.

### Sensitive Data Query Monitoring

Query text içerisinde sensitive columns veya tables referenced ise risk score artırılabilir.

Bu classification-aware query monitoring'dir.

### Database Access Governance

DAM yalnız detect değil governance süreçlerini de besleyebilir.

Örneğin user bir database'e access permission'a sahip ancak 12 aydır kullanmıyor.

Bu access review sırasında revoke candidate olabilir.

Actual usage data entitlement optimization için kullanılabilir.

### DAM ve IGA

IGA configured permissions'ı yönetir.

DAM actual usage'ı gösterir.

Bu bilgiler birlikte:

User has access

ama:

Never uses access

finding'i oluşturabilir.

Bu Least Privilege optimization sağlar.

### Unused Database Privileges

Unused privileges attack surface'i artırır.

Örneğin user UPDATE permission'a sahip ancak sadece SELECT kullanıyor.

Permission right-sizing yapılabilir.

Bu continuous Least Privilege yaklaşımıdır.

### Database Role Review

Database roles zaman içerisinde broad hale gelebilir.

Örneğin role'a yeni privilege eklenir ve yüzlerce user otomatik olarak kazanır.

DAM actual activity ile role design'ı validate etmeye yardımcı olabilir.

### DAM ve DSPM

DSPM sensitive data location ve exposure riskini gösterir.

DAM actual access activity'yi gösterir.

DSPM:

“Restricted data burada.”

DAM:

“Şu identity bu data'yı okuyor.”

Bu birleşim Data Security açısından çok değerlidir.

### DSPM + DAM Risk Senaryosu

Örneğin DSPM:

Customer database contains Restricted PII.

Ayrıca:

500 users have access.

DAM ise:

User X performed 2 million row export.

Bu combined risk çok daha anlamlıdır.

### DAM ve DLP

DAM database'den data'nın çıkarıldığını görür.

DLP endpoint veya network üzerinden data'nın nereye gönderildiğini görür.

Örneğin:

DAM:

Bulk export detected.

DLP:

File uploaded to personal cloud.

Bu end-to-end exfiltration visibility sağlar.

### Database-to-Endpoint Data Flow

Sensitive data çoğu zaman database'den endpoint'e export edilir.

Bu noktada DAM monitoring database tarafında biter.

DLP endpoint tarafında protection'a devam eder.

Bu nedenle layered architecture gerekir.

### DAM ve Data Lineage

Data lineage database'den data'nın hangi downstream systems'a aktarıldığını gösterebilir.

DAM actual access ile lineage birleştiğinde data movement daha iyi anlaşılabilir.

Bu özellikle analytics environments için önemlidir.

### Cloud Database Monitoring

Cloud databases traditional on-prem databases'ten farklı visibility models kullanabilir.

Examples:

Managed SQL

Cloud Data Warehouse

Serverless Database

Bu environments'da native logs, APIs ve cloud telemetry önemlidir.

DAM architecture cloud-native monitoring capabilities'i desteklemelidir.

### AWS, Azure ve Google Cloud Database Security Mantığı

Cloud provider fark etmeksizin temel sorular aynıdır:

Kim connect oldu?

Hangi identity?

Hangi query?

Hangi data?

Ne kadar data?

Hangi network source?

Encryption var mı?

Logs merkezi mi?

Cloud-native database security bu sorulara cevap vermelidir.

### Serverless Database Monitoring

Serverless databases infrastructure layer'ı provider tarafından yönetebilir.

Traditional host agent deployment mümkün olmayabilir.

Bu nedenle API, native audit ve cloud telemetry tabanlı monitoring gerekir.

### Data Warehouse Monitoring

Data warehouses çok büyük volume'da sensitive information içerebilir.

Analytics users geniş read access'e sahip olabilir.

Mass query burada normal olabilir.

Bu nedenle behavior baselines user role ve workload'a göre oluşturulmalıdır.

### Data Lakehouse ve Database Activity

Modern analytics architectures SQL interfaces üzerinden data lake veya lakehouse query edebilir.

Bu environments da DAM benzeri monitoring gerektirir.

Traditional database boundary ortadan kalkmaktadır.

### Big Data Access Monitoring

Large-scale analytics platformları sensitive data'nın merkezi kopyalarını tutabilir.

User queries ve export operations monitor edilmelidir.

Data Discovery ve classification burada kritik context sağlar.

### Database Secrets Güvenliği

Database credentials source code veya config files içerisinde plaintext tutulmamalıdır.

Secrets manager kullanılmalıdır.

DAM unusual connection behavior detect edebilir ancak credential protection önleyici kontroldür.

### Passwordless Database Authentication

Modern environments'da database access:

certificate,

federated identity,

temporary token,

managed identity

üzerinden yapılabilir.

Bu long-lived passwords riskini azaltabilir.

DAM identity mapping doğru yapılmalıdır.

### Database Identity Federation

Enterprise identity system ile database authentication entegre edildiğinde accountability artar.

User individual identity ile connect olur.

Shared DB credentials azalır.

Bu IAM ve DAM integration için güçlü foundation sağlar.

### Service Account Password Rotation

Application database credentials uzun süre değişmeden kalmamalıdır.

Secrets management rotation uygulanabilir.

Ancak application availability etkilenmemelidir.

Automation önemlidir.

### Database Connection Encryption

DAM database activity'nin yanı sıra data in transit protection da önemlidir.

Application ile database arasındaki connection TLS kullanmalıdır.

Internal network trust edilmemelidir.

### TLS Database Security'de Neden Önemli?

Unencrypted database traffic network sniffing ile credentials veya sensitive data expose edebilir.

Bu nedenle database protocols mümkün olduğunca TLS ile korunmalıdır.

Ancak encrypted traffic network-based DAM visibility'sini etkileyebilir.

Architecture buna göre seçilmelidir.

### Database Backup Monitoring

Database security yalnız live database ile sınırlı değildir.

Backups büyük miktarda sensitive data içerir.

Backup creation, restore ve export activities izlenmelidir.

Unauthorized restore data exposure oluşturabilir.

### Database Restore Neden Risklidir?

User production backup'ını test server'a restore edebilir.

Test server lower security seviyesine sahip olabilir.

Bu data leakage oluşturabilir.

Restore operations approval ve monitoring altında olmalıdır.

### Snapshot Security

Cloud database snapshots sensitive data içerir.

Snapshot public sharing veya cross-account sharing risklidir.

DSPM/CSPM snapshot posture'u analiz edebilir.

DAM live activity'yi izlerken snapshots ayrıca governance kapsamına alınmalıdır.

### Database Clone Riski

Modern cloud databases hızlı clone oluşturabilir.

Bu developer productivity sağlar.

Ancak sensitive data copies hızla çoğalabilir.

Clone creation governance ve masking ile kontrol edilmelidir.

### Shadow Database Nedir?

Security Team'in inventory'sinde olmayan database instances Shadow Database olarak düşünülebilir.

Developer temporary database oluşturabilir.

Sensitive production data kopyalanabilir.

Data Discovery bu unknown repositories'i bulmalıdır.

DAM yalnız bilinen databases üzerinde etkili olabilir.

### DAM ve Shadow Data

Database'den export edilen data file'a dönüştüğünde DAM visibility kaybolabilir.

Bu nedenle Shadow Data discovery ve DLP gerekir.

Data Security lifecycle database boundary'nin ötesine geçmelidir.

### DAM ve Insider Threat

Malicious insider authorized database user olabilir.

Authentication bypass gerekmez.

Bu nedenle DAM insider risk için önemli telemetry sağlar.

Örneğin:

Employee

Notice Period

Bulk Customer Export

After-Hours Activity

high-risk olabilir.

### Departing Employee Database Activity

İşten ayrılmak üzere olan employee unusual database access gerçekleştiriyorsa additional monitoring uygulanabilir.

Ancak privacy ve employment policies dikkate alınmalıdır.

Risk controls uygun governance altında olmalıdır.

### Contractor Database Access

External consultants temporary database access alabilir.

Bu access:

Time-Bound

Approved

Least Privilege

Monitored

olmalıdır.

DAM contractor activity için yüksek visibility sağlayabilir.

### Third-Party Application Access

Third-party application database'e direct connection kuruyorsa supply chain risk oluşur.

Credential compromise provider üzerinden data exposure yaratabilir.

Third-party connections inventory'de olmalıdır.

### Database Query Allowlisting

Highly controlled environments'da applications yalnız expected query patterns çalıştırabilir.

Unexpected SQL patterns alert veya block edilebilir.

Bu database firewall veya advanced DAM capabilities ile uygulanabilir.

### Query Blocking Yapılmalı mı?

Inline enforcement risklidir.

Yanlış positive critical business query'yi block edebilir.

Bu nedenle blocking yalnız well-tested high-confidence rules için kullanılmalıdır.

Çoğu use case monitoring + response ile başlayabilir.

### DAM Deployment'ta Performance Etkisi

Database monitoring performance üzerinde yük oluşturabilir.

Özellikle detailed auditing high-volume systems'da maliyetli olabilir.

Bu nedenle:

Scope

Sampling

Audit Levels

Infrastructure Sizing

dikkatli planlanmalıdır.

### Audit Everything Doğru Yaklaşım mı?

Her şeyi maksimum detayla loglamak storage ve performance sorunları oluşturabilir.

Risk-based audit daha sağlıklı olabilir.

Örneğin Restricted schemas daha detaylı izlenebilir.

Public reference data daha düşük logging seviyesinde olabilir.

### Log Retention

Database activity logs ne kadar süre tutulacağı policy ile belirlenmelidir.

Security investigation, compliance ve operational requirements dikkate alınmalıdır.

Logs sensitive information içerebileceği için kendileri de korunmalıdır.

### DAM Logs Hassas Veri İçerebilir mi?

Evet.

Query text içerisinde personal data veya credentials bulunabilir.

Bu nedenle logs:

Encryption

Access Control

Retention

ile korunmalıdır.

Monitoring system yeni data leakage kaynağı olmamalıdır.

### DAM Platform Güvenliği

DAM platformu çok kritik telemetry ve bazı durumlarda sensitive query data tutabilir.

Bu nedenle DAM administrative access PAM altında olabilir.

MFA, RBAC ve audit uygulanmalıdır.

### Monitoring the Monitor

DAM platformunda yapılan configuration changes de loglanmalıdır.

Kim rule değiştirdi?

Kim alert disable etti?

Kim data export etti?

Bu meta-monitoring accountability sağlar.

### AI ve Database Activity Monitoring

AI applications ve AI Agents database access gerçekleştirmeye başladıkça DAM yeni bir identity class'ını izlemek zorunda kalmaktadır.

Artık yalnız:

Human User

ve:

Application Account

değil:

AI Agent

da database query çalıştırabilir.

### AI Agent Database Access

AI Agent natural language request'i SQL query'ye çevirebilir.

Örneğin user:

“Bana tüm müşterileri getir.”

der.

Agent geniş SELECT çalıştırabilir.

Bu authorization ve data leakage riski oluşturabilir.

DAM agent queries'i ayrıca izlemelidir.

### Text-to-SQL Riski

Generative AI Text-to-SQL capabilities database access'i kolaylaştırır.

Ancak model yanlış veya overly broad query üretebilir.

Örneğin gerekli 10 record yerine entire table çekebilir.

Bu nedenle query validation ve Least Privilege önemlidir.

### AI Agent İçin Database Least Privilege

AI Agent'ın database role'ü task-specific olmalıdır.

Reporting agent:

SELECT

permission alabilir.

Ancak:

DROP

DELETE

GRANT

permissions almamalıdır.

Bu Agentic Least Privilege yaklaşımıdır.

### AI Agent Query Guardrails

Agent-generated queries üzerinde guardrails uygulanabilir.

Örneğin:

No DELETE

No DROP

Row Limit

Restricted Table Deny

Human Approval for Bulk Query

gibi controls olabilir.

DAM bu guardrails sonrası actual query activity'yi izler.

### AI Agent Bulk Export Riski

AI Agent otomasyon nedeniyle çok hızlı büyük data volume çıkarabilir.

Human user'ın saatler sürecek operation'ını saniyeler içinde yapabilir.

Bu nedenle rate limits ve data volume controls önem kazanır.

### RAG ve Database Monitoring

RAG systems yalnız vector databases değil relational databases üzerinden de retrieval yapabilir.

Permission-aware retrieval uygulanmalıdır.

DAM model veya retrieval service'in hangi data'ya eriştiğini loglayabilir.

### AI Query Attribution

AI system database'e service account ile bağlanıyorsa hangi end-user'ın request'i query'yi tetiklediği loglanmalıdır.

Aksi halde tüm activity tek service account altında görünür.

Bu attribution problemi yeni nesil DAM için kritik olacaktır.

### Agent Identity + User Identity

İdeal log context şu bilgileri içerebilir:

End User

AI Agent

Service Account

Database

Query

Data Classification

Bu chain accountability sağlar.

### AI Data Exfiltration

AI Agent database'den data çekip external API'ye gönderebilir.

DAM database extraction'ı görür.

DLP veya API monitoring outbound transfer'i görür.

Bu nedenle AI Data Security multi-layer monitoring gerektirir.

### Database Activity Monitoring Projesi Nasıl Başlatılır?

İlk adım database inventory oluşturmaktır.

Hangi databases var?

Hangileri production?

Hangileri sensitive data içeriyor?

Kimler access ediyor?

Hangi database technologies kullanılıyor?

Bu visibility sonrası monitoring scope belirlenebilir.

### Crown Jewel Database'lerden Başlamak

Tüm databases aynı anda DAM kapsamına alınmak zorunda değildir.

Öncelikle:

Customer Databases

HR Databases

Financial Databases

Identity Stores

Payment Databases

gibi crown jewel systems alınabilir.

Bu risk-based rollout sağlar.

### DAM Policy Oluşturma

Her database için important use cases belirlenmelidir.

Örneğin:

Bulk Export

Privileged Activity

Sensitive Table Access

Failed Authentication

Privilege Escalation

Audit Disable

Schema Change

Rules buna göre oluşturulur.

### Monitor Mode

DAM başlangıçta monitoring-only çalışabilir.

Normal activity baseline çıkarılır.

False positives belirlenir.

Daha sonra high-confidence alerts oluşturulur.

Inline blocking kullanılacaksa çok kontrollü geçilmelidir.

### DAM Tuning

Database workload zamanla değişebilir.

Yeni application eklenebilir.

Yeni reporting job oluşabilir.

Bu nedenle DAM policies sürekli tune edilmelidir.

Static rule set zamanla ineffective hale gelebilir.

### DAM Incident Response

High-risk DAM event için playbook oluşturulmalıdır.

Örnek:

Detect

↓

Validate Query

↓

Identify Identity

↓

Check PAM Session

↓

Check Endpoint / EDR

↓

Assess Data Volume

↓

Check DLP

↓

Contain Account

↓

Preserve Logs

↓

Investigate Data Exposure

Bu coordinated response sağlar.

### Bulk Export Incident Playbook

Örneğin DAM 2 milyon customer record export detect etti.

Security Team şu soruları sorabilir:

Bu user authorized mı?

Bu workload normal mi?

Export file nereye yazıldı?

DLP external transfer gördü mü?

PAM session approval var mı?

Identity risk signal var mı?

Bu sorular true incident ile legitimate business operation'ı ayırır.

### DAM KPI'ları

Database Security programı ölçülebilir olmalıdır.

Örnek KPI'lar:

Databases Under Monitoring

Sensitive Databases Covered

Privileged Accounts Monitored

Bulk Export Alerts

Restricted Table Access Alerts

Failed Login Events

Privilege Escalation Attempts

Audit Configuration Changes

High-Risk Query Count

Unusual After-Hours Access

Database Activity Alerts Investigated

False Positive Rate

Mean Time to Investigate

Unused Database Privileges

Shared Database Accounts

Unknown Database Identities

AI Agent Database Activity

gibi metrics olabilir.

### DAM Coverage KPI

Critical databases'in yüzde kaçı monitoring altındadır?

Bu temel maturity göstergesidir.

Örneğin 50 critical database'in yalnız 10'u DAM kapsamındaysa visibility gap vardır.

### Privileged Monitoring Coverage

DBA ve service privileged identities'in ne kadarı izleniyor?

Bu ayrıca ölçülmelidir.

Critical databases monitored olsa bile privileged user attribution yoksa visibility eksik kalabilir.

### False Positive Rate

DAM çok fazla false positive üretirse analyst trust azalır.

Bu nedenle rule tuning önemli KPI'dır.

Amaç minimum alert değil maximum useful signal'dır.

### Mean Time to Investigate

Database security events ne kadar hızlı investigate ediliyor?

Mass data extraction event'i saatlerce açık kalıyorsa damage artabilir.

SOC integration bu süreyi azaltabilir.

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

En yaygın hata DAM'i yalnız audit log toplama projesi olarak görmektir. Gerçek değer behavior, data sensitivity ve identity context ile ortaya çıkar.

İkinci hata yalnız DBA accounts'ı izlemektir. Application accounts, service accounts ve standard users da sensitive data extraction yapabilir.

Üçüncü hata bütün queries'i aynı risk seviyesinde değerlendirmektir.

Dördüncü hata Data Classification ile integration kurmamaktır.

Beşinci hata DAM'i DLP, PAM, SIEM ve DSPM'den izole etmektir.

Altıncı hata shared database accounts kullanmaya devam etmektir.

Yedinci hata cloud databases'i traditional monitoring scope dışında bırakmaktır.

Sekizinci hata AI Agents ve Text-to-SQL applications'ın database access'ini normal service account traffic'i içerisinde kaybetmektir.

Dokuzuncu hata logların kendisini yeterince korumamaktır.

### DAM Kontrol Listesi

- Kurumsal database inventory mevcut mu?
- Critical databases belirlenmiş mi?
- Sensitive data içeren databases sınıflandırılmış mı?
- Database Activity Monitoring uygulanıyor mu?
- Native audit logging etkin mi?
- SQL activity izleniyor mu?
- SELECT queries risk bazlı değerlendiriliyor mu?
- Bulk data export detect ediliyor mu?
- Sensitive tables monitor ediliyor mu?
- Sensitive columns monitor ediliyor mu?
- DBA activities detaylı izleniyor mu?
- Privileged database users inventory'de mi?
- Shared database accounts azaltılmış mı?
- Service accounts monitor ediliyor mu?
- Application accounts baseline altında mı?
- Failed database logins izleniyor mu?
- Privilege escalation alerts mevcut mu?
- User creation events izleniyor mu?
- GRANT/REVOKE aktiviteleri monitor ediliyor mu?
- Schema changes izleniyor mu?
- DROP ve DELETE gibi high-risk queries alert üretiyor mu?
- Audit disable attempts detect ediliyor mu?
- Log tampering kontrolleri var mı?
- DAM logs centralized mı?
- DAM logs encrypted mı?
- PAM integration mevcut mu?
- JIT DBA access kullanılıyor mu?
- SIEM integration var mı?
- SOC use case'leri tanımlı mı?
- DLP integration mevcut mu?
- DSPM sensitive data context sağlıyor mu?
- IGA unused access findings'i kullanıyor mu?
- Database encryption uygulanıyor mu?
- TLS database connections için kullanılıyor mu?
- Production database access sınırlandırılmış mı?
- Test data masking uygulanıyor mu?
- Database backups korunuyor mu?
- Snapshot ve clone creation monitor ediliyor mu?
- Cloud databases scope'ta mı?
- Serverless databases monitor ediliyor mu?
- Data warehouses kapsamda mı?
- AI Agents database activity'si izleniyor mu?
- Text-to-SQL use case'leri için guardrails var mı?
- AI Agent unique identity kullanıyor mu?
- End-user to AI-agent attribution tutuluyor mu?
- Bulk AI queries için limit var mı?
- DAM Incident Response playbook mevcut mu?
- DAM KPI'ları düzenli takip ediliyor mu?

### DAM Olgunluk Modeli

**Seviye 1 – Temel Database Logging:** Native logs sınırlı olarak tutulur. Merkezi security analysis yoktur.

**Seviye 2 – Merkezi Database Monitoring:** Critical databases merkezi DAM veya SIEM kapsamına alınır. DBA ve high-risk SQL activity izlenir.

**Seviye 3 – Data-Aware DAM:** Data Classification, PAM, DLP ve IGA ile integration kurulur. Sensitive table ve column access risk bazlı değerlendirilir.

**Seviye 4 – Behavioral Database Security:** User, service account ve workload baselines oluşturulur. Anomaly detection ve risk scoring uygulanır. Cloud databases kapsamlı şekilde izlenir.

**Seviye 5 – Adaptive Database Data Security:** Human, machine ve AI Agent database activities real-time identity, data sensitivity, behavior ve endpoint risk context'iyle değerlendirilir. Access, query ve exfiltration controls ortak security architecture içerisinde yönetilir.

Bu dönüşüm:

#### Database Logging

↓

#### Database Monitoring

↓

#### Data-Aware Monitoring

↓

#### Behavioral DAM

↓

#### Adaptive Database Security

şeklinde ilerler.

### Sık Sorulan Sorular

#### DAM nedir?

DAM, Database Activity Monitoring ifadesinin kısaltmasıdır ve veritabanları üzerinde gerçekleştirilen kullanıcı, uygulama ve SQL aktivitelerinin izlenmesini sağlayan database security yaklaşımıdır.

#### Database Activity Monitoring nedir?

Database Activity Monitoring; database login, SQL query, table access, bulk export, privilege change ve administrative operations gibi aktivitelerin güvenlik amacıyla izlenmesidir.

#### DAM ne işe yarar?

DAM, hangi kullanıcının hangi database'e eriştiğini, hangi sorguları çalıştırdığını, hangi sensitive data'ya eriştiğini ve olağan dışı data extraction davranışı olup olmadığını görünür hale getirir.

#### Database Audit ile DAM arasındaki fark nedir?

Database Audit native database logs'unu üretir. DAM bu logs ve activity telemetry'yi security context, behavior analytics ve data sensitivity ile analiz eder.

#### DBA Monitoring nedir?

DBA Monitoring, yüksek yetkili Database Administrator hesaplarının login, SQL query, configuration ve data access aktivitelerinin izlenmesidir.

#### SQL Activity Monitoring nedir?

SQL Activity Monitoring, SELECT, INSERT, UPDATE, DELETE, ALTER, DROP ve benzeri SQL statements'in database security açısından izlenmesi ve analiz edilmesidir.

#### Bulk Data Export nedir?

Bulk Data Export, büyük miktarda database record'un kısa sürede dışarı çıkarılmasıdır. Legitimate business use veya data exfiltration göstergesi olabilir.

#### DAM ile PAM arasındaki fark nedir?

PAM privileged session ve account access'ini yönetir. DAM database içerisinde gerçekleştirilen query ve data access aktivitelerini izler.

#### DAM ile DLP arasındaki fark nedir?

DAM database içindeki access ve extraction activity'sini görür. DLP extracted data'nın e-mail, USB, web veya cloud üzerinden nereye taşındığını kontrol eder.

#### DAM ile DSPM arasındaki fark nedir?

DSPM sensitive data'nın nerede bulunduğunu ve hangi exposure risklerini taşıdığını analiz eder. DAM ise bu data'ya yapılan gerçek database access activity'sini izler.

#### DAM ile SIEM birlikte kullanılmalı mı?

Evet. DAM database telemetry sağlar, SIEM bu telemetry'yi identity, EDR, firewall, PAM ve DLP gibi diğer security signals ile correlate edebilir.

#### DAM insider threat'i tespit eder mi?

DAM authorized users tarafından yapılan unusual sensitive data access ve bulk extraction davranışlarını görünür hale getirerek insider threat detection'ı destekleyebilir.

#### Database encryption DAM'in yerine geçer mi?

Hayır. Encryption storage üzerindeki veriyi korur. Authorized query çalıştırıldığında data decrypt edilir. DAM bu active usage'ı izler.

#### AI Agent database erişimleri izlenmeli mi?

Evet. AI Agents büyük miktarda data'yı otomatik sorgulayabildiği için unique identity, Least Privilege, query guardrails ve DAM monitoring uygulanmalıdır.

#### Text-to-SQL güvenlik riski oluşturur mu?

Oluşturabilir. AI tarafından üretilen SQL sorguları beklenenden geniş data erişimi veya dangerous database operations oluşturabilir. Authorization, query validation ve monitoring gereklidir.

### Sonuç: Veritabanına Erişimi Vermek ile Veritabanında Ne Yapıldığını Bilmek Aynı Şey Değildir

Modern database security'nin en önemli yanılgılarından biri, doğru authentication ve authorization uygulandığında veritabanının tamamen güvenli olduğunun düşünülmesidir.

Kullanıcı yetkili olabilir.

DBA yetkili olabilir.

Application account yetkili olabilir.

AI Agent yetkili olabilir.

Ancak yetkili identity'nin yaptığı her işlem otomatik olarak güvenli değildir.

Bu nedenle database security şu iki soruyu birbirinden ayırmalıdır:

**“Bu kişi veya sistem database'e erişebilir mi?”**

ve:

**“Eriştikten sonra ne yapıyor?”**

IAM, RBAC ve PAM ilk soruyu yönetir.

DAM ikinci soruya visibility sağlar.

Bu visibility Data Classification ile birleştiğinde daha değerli hale gelir.

Çünkü:

User accessed table

ile:

Privileged user exported 2 million records from Restricted Customer Data

aynı güvenlik bilgisi değildir.

Modern DAM'in gerçek değeri bu context'tir.

Bu nedenle güçlü Database Security Architecture:

#### Data Discovery

#### Data Classification

#### Database Encryption

#### IAM / PAM

#### Database Activity Monitoring

#### DLP

#### DSPM

#### SIEM / SOC

katmanlarının birlikte çalışmasına dayanır.

Gelecekte bu mimarinin önemi daha da artacaktır.

Çünkü veritabanlarına yalnız insanlar veya klasik applications erişmeyecektir.

AI Agents doğal dil komutlarından SQL queries üretecek, RAG systems database'lerden retrieval yapacak ve automation engines çok büyük miktarda data üzerinde işlem gerçekleştirecektir.

Bu nedenle yeni nesil DAM şu soruyu cevaplayabilmelidir:

**“Hangi insan, application, service account veya AI Agent hangi hassas veriye, hangi sorguyla, ne kadar miktarda, hangi amaçla ve hangi risk bağlamında erişti?”**

Ve bu bölümün en önemli cümlesi:

**Database Activity Monitoring, veritabanına yalnız kimin erişebildiğini değil; insan, uygulama veya AI Agent fark etmeksizin hangi kimliğin hangi hassas tablo ve alanlara eriştiğini, hangi SQL işlemlerini gerçekleştirdiğini ve olağan dışı veri çıkarma davranışlarını gerçek zamanlı güvenlik bağlamında görünür hale getiren modern Data Security'nin temel izleme katmanıdır.**