# Kurumsal Veri Güvenliği Mimarisi Nasıl Kurulur? Classification + DLP + DSPM + DAM + DDR + Encryption + Zero Trust

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/veri-guvenligi-siniflandirma/kurumsal-veri-guvenligi-mimarisi

![Kurumsal Veri Güvenliği Mimarisi Nasıl Kurulur? Classification + DLP + DSPM + DAM + DDR + Encryption + Zero Trust](/images/bilgi-merkezi/covers/cover-veriguv-12.webp)

Kurumsal veri güvenliği mimarisi, bir organizasyonun sahip olduğu hassas verileri keşfetmek, sınıflandırmak, kimlerin bu verilere erişebileceğini kontrol etmek, veriyi şifrelemek, veri hareketlerini izlemek, veri sızıntısını önlemek, veritabanı aktivitelerini denetlemek ve aktif veri tehditlerine mümkün olduğunca erken müdahale etmek amacıyla oluşturulan bütünleşik güvenlik yapısıdır. Modern bir **Data Security Architecture**, tek bir DLP, encryption veya database security ürününden oluşmaz; Data Discovery, Data Classification, IAM, PAM, Encryption, DLP, DSPM, DAM, DDR, SIEM, SOC ve Zero Trust gibi farklı güvenlik katmanlarının birlikte çalışmasını gerektirir.

Kurumsal veri güvenliğinde temel amaç artık yalnızca:

**“Veriyi şifreleyelim.”**

veya:

**“Verinin dışarı çıkmasını engelleyelim.”**

değildir.

Modern yaklaşım şu soruların tamamına cevap verebilmelidir:

#### Hangi veriye sahibiz?

#### Hassas veriler nerede bulunuyor?

#### Bu veriler nasıl sınıflandırıldı?

#### Verilerin sahibi kim?

#### Kimler bu verilere erişebiliyor?

#### Gerçekten erişmeleri gerekiyor mu?

#### Veri şifreleniyor mu?

#### Kim hangi veritabanı sorgusunu çalıştırıyor?

#### Veri USB, e-posta, web, SaaS veya AI platformuna taşınıyor mu?

#### Sensitive data üzerinde normal dışı davranış gerçekleşiyor mu?

#### Bir AI Agent hangi veriye erişiyor ve hangi işlemleri gerçekleştiriyor?

#### Aktif veri tehdidi oluştuğunda bunu ne kadar hızlı tespit edebiliyoruz?

#### Riskli davranış tespit edildiğinde otomatik veya yarı otomatik müdahale edebiliyor muyuz?

Bu soruların tamamının birlikte cevaplanması gerçek anlamda **Enterprise Data Security Architecture** oluşturur.

### Kurumsal Veri Güvenliği Nedir?

Kurumsal veri güvenliği, organizasyonun sahip olduğu verilerin yalnız yetkisiz erişime karşı değil; yanlış kullanım, veri sızıntısı, aşırı yetkilendirme, insider threat, ransomware, credential compromise, cloud misconfiguration, Shadow Data, Shadow AI ve AI Agent kaynaklı risklere karşı korunmasıdır.

Bu nedenle Data Security yalnız storage security değildir.

Veri:

Database içerisinde,

File Server üzerinde,

Endpoint'te,

Microsoft 365 ortamında,

Cloud Storage üzerinde,

SaaS uygulamasında,

Backup içerisinde,

Data Lake'te,

Source Code Repository'de,

E-Mail içerisinde,

AI Knowledge Base'te,

Vector Database içerisinde,

RAG sisteminde,

AI Agent Memory içerisinde

bulunabilir.

Modern Data Security Architecture bu dağıtık veri yapısını tek güvenlik perspektifinde değerlendirebilmelidir.

### Veri Güvenliğinde En Büyük Problem: Görünmeyen Veriyi Koruyamazsınız

Kurumsal veri güvenliği mimarisinin ilk prensibi oldukça basittir:

**You Cannot Protect What You Cannot See.**

Bir kurum sahip olduğu sensitive data'nın nerede olduğunu bilmiyorsa bu veriye doğru security controls uygulaması son derece zordur.

Örneğin kurumun müşteri database'i korunuyor olabilir.

Ancak aynı database'in:

Excel export'u,

eski backup'ı,

developer test copy'si,

SharePoint kopyası,

cloud storage kopyası

farklı ortamlarda bulunabilir.

Bu nedenle Data Security Architecture'ın ilk katmanı **Data Discovery** olmalıdır.

### \1. Katman: Data Discovery – Hassas Veriyi Bulmak

Data Discovery, kurum içerisindeki data repositories'i tarayarak sensitive information'ın nerede bulunduğunu tespit etmeyi amaçlar.

Bu taramalar:

Databases

File Servers

Endpoints

Cloud Storage

SaaS

Microsoft 365

Data Lakes

Backups

Repositories

AI Data Stores

gibi farklı environments üzerinde gerçekleştirilebilir.

Amaç yalnız file inventory oluşturmak değildir.

Asıl amaç:

**“Hangi hassas veri nerede?”**

sorusunu cevaplamaktır.

### Sensitive Data Discovery

Sensitive Data Discovery sırasında:

Personal Data

Financial Data

Customer Data

Credentials

Source Code

Trade Secrets

HR Data

Health Data

Contracts

Intellectual Property

gibi information types tespit edilebilir.

Bu discovery sonuçları diğer security controls için temel oluşturur.

### Shadow Data Nedir?

Security veya IT ekiplerinin bilmediği, yönetilmeyen veya kontrol dışına çıkmış veri kopyaları **Shadow Data** olarak adlandırılabilir.

Örneğin production database'in eski export'u unutulmuş cloud bucket içerisinde bulunabilir.

Bu data aktif sistemden daha az korunuyor olabilir.

DSPM açısından Shadow Data önemli risk alanıdır.

### Dark Data

Uzun süredir kullanılmayan ancak hâlâ saklanan data **Dark Data** olarak değerlendirilebilir.

Dark Data business value üretmeyebilir ancak breach sırasında exposure oluşturabilir.

Bu nedenle Data Minimization güvenliğin önemli parçasıdır.

### \2. Katman: Data Classification – Verinin Değerini Anlamak

Data Discovery veriyi bulur.

Data Classification ise:

**“Bu veri ne kadar hassas?”**

sorusunu cevaplar.

Örnek classification modeli:

#### Public

#### Internal

#### Confidential

#### Restricted

şeklinde olabilir.

Her classification level farklı security policy gerektirir.

### Public Data

Public Data kamuya açıklanmasında sakınca bulunmayan veridir.

Örneğin yayınlanmış corporate brochure.

Security controls diğer seviyelere göre daha hafif olabilir.

### Internal Data

Internal Data kurum içerisinde kullanılmak üzere oluşturulmuş ancak public olmayan veridir.

Örneğin internal procedures veya internal announcements.

### Confidential Data

Confidential Data yetkisiz disclosure durumunda kuruma zarar verebilecek information'dır.

Örneğin:

Contracts

Financial Reports

Customer Information

Business Plans.

### Restricted Data

Restricted Data en yüksek protection gerektiren data category olabilir.

Örneğin:

Critical Personal Data

Authentication Secrets

Private Keys

Highly Sensitive Financial Data

Strategic Trade Secrets.

Bu data için daha sıkı access, encryption ve monitoring controls uygulanmalıdır.

### Classification Policy Enforcement

Classification yalnız label olmamalıdır.

Label security behavior değiştirmelidir.

Örneğin:

#### Restricted

↓

Encryption Required

External Sharing Blocked

USB Copy Blocked

Privileged Access Monitored

DDR High-Sensitivity Monitoring

gibi policies tetiklenebilir.

Bu **Classification-Driven Security** yaklaşımıdır.

### \3. Katman: Data Ownership – Verinin Sahibini Belirlemek

Her kritik dataset'in business owner'ı bulunmalıdır.

Security team tek başına:

“Kim erişmeli?”

kararı veremez.

Data Owner business context'i bilir.

Örneğin HR Data Owner:

HR Director.

Finance Data Owner:

Finance Department.

Customer Data Owner:

Relevant Business Unit.

Data Ownership access governance'ın temelidir.

### Data Owner Ne Yapar?

Data Owner:

Classification belirleyebilir.

Access approval verebilir.

Retention requirement belirleyebilir.

Access Reviews gerçekleştirebilir.

Data sharing policies'e katkı sağlar.

Böylece Data Security yalnız IT responsibility olmaktan çıkar.

### \4. Katman: IAM ve IGA – Kim Hangi Veriye Erişebilir?

Data keşfedildi.

Classify edildi.

Owner belirlendi.

Şimdi kritik soru:

#### Kim erişebilir?

IAM ve IGA burada devreye girer.

Identity and Access Management kullanıcı identities ve authentication süreçlerini yönetirken Identity Governance and Administration access lifecycle ve governance süreçlerini destekler.

### Least Privilege

Kullanıcı yalnız görevini yapmak için gerekli minimum permissions'a sahip olmalıdır.

Bu **Least Privilege** prensibidir.

Örneğin Finance user bütün customer database'e erişmek zorunda olmayabilir.

Access scope business need'e göre sınırlandırılmalıdır.

### Need-to-Know

User'ın teknik olarak access edebilmesi business açısından access etmesi gerektiği anlamına gelmez.

Need-to-Know yaklaşımı:

**“Bu kullanıcının bu veriyi gerçekten bilmesi gerekiyor mu?”**

sorusunu sorar.

### RBAC

Role-Based Access Control permissions'ı role üzerinden yönetir.

Örneğin:

HR Specialist

Finance Analyst

Sales Manager.

Bu operational simplicity sağlar.

Ancak çok geniş roles excessive access oluşturabilir.

### ABAC

Attribute-Based Access Control karar verirken:

User Attribute

Data Classification

Department

Device

Location

Time

Risk

gibi attributes kullanabilir.

Örneğin:

User = Finance

Data = Restricted

Device = Managed

Location = Corporate

MFA = Strong

ise access allow edilebilir.

### Access Review

Permissions permanent kabul edilmemelidir.

Periodic Access Review ile Data Owner:

“Bu user hâlâ bu data'ya erişmeli mi?”

sorusunu değerlendirmelidir.

Unused permissions revoke edilmelidir.

### Permission Creep

User department değiştirdikçe eski permissions kaldırılmazsa zaman içerisinde geniş access oluşur.

Bu **Permission Creep** olarak bilinir.

AI adoption ile Permission Creep daha ciddi risk oluşturabilir çünkü AI user'ın erişebildiği fakat daha önce bulamadığı data'yı saniyeler içerisinde keşfedebilir.

### \5. Katman: PAM – Ayrıcalıklı Veri Erişimlerini Kontrol Etmek

Database Administrator,

System Administrator,

Cloud Administrator

gibi privileged users kritik data üzerinde geniş permissions'a sahip olabilir.

Bu nedenle privileged access ayrı kontrol katmanı gerektirir.

PAM – Privileged Access Management bu ihtiyacı karşılar.

### PAM Data Security İçin Ne Sağlar?

PAM:

Credential Vaulting

Session Management

Session Recording

Approval

JIT Access

Password Rotation

gibi controls sağlayabilir.

Böylece privileged access daha görünür ve kontrollü hale gelir.

### Just-in-Time Access

Privileged permission sürekli açık tutulmak yerine gerektiğinde temporary olarak verilebilir.

Örneğin DBA yalnız maintenance sırasında elevated privilege alır.

Task bittiğinde permission revoke edilir.

Bu standing privilege riskini azaltır.

### Zero Standing Privilege

Zero Standing Privilege permanent privileged permissions'ın mümkün olduğunca kaldırılmasını hedefler.

Bu compromised privileged account impact'ini azaltabilir.

### \6. Katman: Encryption – Veriyi Okunamaz Hale Getirmek

Encryption Data Security Architecture'ın temel teknik kontrollerinden biridir.

Encryption:

#### Data at Rest

#### Data in Transit

ve uygun architectures'da:

#### Data in Use

için değerlendirilebilir.

Ama encryption tek başına Data Security değildir.

### Data at Rest Encryption

Disk, database, backup ve cloud storage üzerinde saklanan data encrypted olabilir.

Örneğin:

Full Disk Encryption

Database Encryption

TDE

Object Storage Encryption

Backup Encryption.

### Data in Transit Encryption

Network üzerinden taşınan data TLS gibi secure protocols ile korunmalıdır.

Bu interception riskini azaltır.

### Data in Use

Data processing sırasında protection daha karmaşıktır.

Confidential Computing ve Trusted Execution Environment gibi technologies belirli use case'lerde Data in Use protection sağlayabilir.

### KMS ve HSM

Encryption'ın güvenliği yalnız algorithm'e bağlı değildir.

Keys nasıl yönetiliyor?

KMS ve HSM burada kritik rol oynar.

Key Lifecycle:

Generation

Storage

Distribution

Rotation

Revocation

Destruction

aşamalarını kapsamalıdır.

### Encryption Neden Tek Başına Yetmez?

User database'e authorized access'e sahipse TDE encrypted database'i query edebilir.

Database engine data'yı user için decrypt eder.

Bu nedenle:

Encryption

Access Control

DAM

DDR

birlikte değerlendirilmelidir.

### \7. Katman: DLP – Verinin Nereye Gittiğini Kontrol Etmek

DLP – Data Loss Prevention sensitive data'nın kurum dışına veya yetkisiz destination'a taşınmasını detect ve prevent etmeyi amaçlar.

DLP:

Endpoint

E-Mail

Web

Network

Cloud

SaaS

channels üzerinde uygulanabilir.

### Endpoint DLP

Endpoint DLP:

USB Copy

Clipboard

Print

Browser Upload

File Copy

gibi user actions'ını monitor edebilir.

Örneğin:

Restricted File

USB Copy

=

Block.

### E-Mail DLP

Sensitive attachment external recipient'a gönderiliyorsa policy:

Warn

Justify

Encrypt

Quarantine

Block

uygulayabilir.

### Cloud DLP

Microsoft 365 ve diğer SaaS platforms üzerindeki sensitive data sharing kontrol edilebilir.

Örneğin:

Confidential File

Anonymous Public Link

=

Blocked.

### AI DLP

Modern DLP architectures AI channels'ı da kapsamalıdır.

Örneğin:

Restricted Source Code

Public Generative AI

=

Block.

Prompt,

file upload,

clipboard

ve AI tool usage Data Security scope'una alınmalıdır.

### DLP'nin Sınırı Nedir?

DLP çoğunlukla policy violation veya data movement üzerinde güçlüdür.

Ancak user authorized olarak sensitive data'ya erişiyorsa ve henüz data'yı dışarı çıkarmadıysa DLP her zaman threat'i erken aşamada göremeyebilir.

Burada DDR önem kazanır.

### \8. Katman: DSPM – Data Security Posture Management

**DSPM – Data Security Posture Management**, kurumun sensitive data posture'unu sürekli analiz etmeyi amaçlayan modern Data Security yaklaşımıdır.

DSPM şu sorulara cevap arar:

Sensitive Data nerede?

Kim erişebilir?

Public exposure var mı?

Excessive permissions mevcut mu?

Data encrypted mı?

Shadow Data var mı?

Misconfiguration mevcut mu?

### DSPM Neden Önemlidir?

Traditional security asset-centric olabilir.

DSPM ise data-centric perspective getirir.

Örneğin:

Cloud Bucket Public.

Bu bir configuration issue'dur.

Ancak bucket içerisinde Restricted Customer Data bulunuyorsa risk çok daha yüksektir.

DSPM configuration risk ile data sensitivity'yi birleştirir.

### DSPM + IAM

DSPM:

“Bu sensitive dataset'e 800 users erişebiliyor.”

diyebilir.

IGA:

“Bu users'ın hangisinin access'i gerçekten gerekli?”

sorusunu yönetebilir.

Bu integration excessive access reduction sağlar.

### DSPM + DLP

DSPM sensitive data'yı bulur.

DLP bu data'nın hareketini kontrol eder.

Basit model:

**DSPM → Where is the Data?**

**DLP → Where is the Data Going?**

Ancak aktif threat detection için bir katman daha gerekir:

**DDR → What Is Happening to the Data Right Now?**

### \9. Katman: DAM – Database Activity Monitoring

Kurumsal kritik verinin önemli bölümü databases içerisinde bulunur.

Bu nedenle database activity ayrı visibility gerektirir.

DAM – Database Activity Monitoring, database üzerinde gerçekleştirilen:

Queries

Logins

Privilege Changes

Schema Changes

Bulk Exports

Administrative Actions

gibi aktiviteleri monitor eder.

### DAM Neden Gereklidir?

DBA authorized olabilir.

Ancak gece saat 03:00'te bütün customer table'ını export etmesi normal olmayabilir.

Authentication:

Valid.

Permission:

Allowed.

Behavior:

Suspicious.

DAM bu activity'yi görünür hale getirir.

### DAM + PAM

PAM:

“DBA session'ını kim açtı?”

sorusunu cevaplar.

DAM:

“Bu session database üzerinde hangi SQL queries'i çalıştırdı?”

sorusunu cevaplar.

Birlikte privileged database security güçlenir.

### DAM + Classification

DAM event'i yalnız:

“SELECT executed.”

olarak değerlendirilmemelidir.

Classification context eklenirse:

“User executed bulk SELECT on Restricted Customer Data.”

haline gelir.

Bu çok daha meaningful security event'tir.

### \10. Katman: DDR – Data Detection and Response

Modern Data Security Architecture'ın en kritik gelişim alanlarından biri **DDR – Data Detection and Response** yaklaşımıdır.

DDR, sensitive data üzerinde gerçekleşen riskli davranışları runtime sırasında tespit etmeyi ve gerektiğinde response actions tetiklemeyi amaçlar.

DSPM posture'u analiz eder.

DLP data movement'ı kontrol eder.

DAM database activity'yi izler.

DDR ise bunlardan gelen data context ve behavior signals'ını kullanarak:

**“Şu anda hassas veriye yönelik gerçek bir tehdit davranışı gerçekleşiyor mu?”**

sorusuna odaklanır.

### DDR Nedir?

Data Detection and Response, sensitive data access ve usage behavior'larını sürekli analiz ederek:

Unusual Data Access

Bulk Download

Mass Retrieval

Data Exfiltration

Suspicious Database Query

Insider Threat

Compromised Identity Data Access

AI Agent Data Abuse

gibi scenarios'u detect etmeye yönelik Data Security yaklaşımıdır.

DDR'ın temel farkı threat detection'ın merkezine **data** koymasıdır.

### Traditional Detection ile DDR Arasındaki Fark

Traditional security alert:

“User unusual login yaptı.”

DDR perspective:

“User unusual login sonrasında Restricted Customer Data üzerinde normalin 100 katı download gerçekleştirdi.”

İkinci event business impact açısından daha anlamlıdır.

### DDR'ın Temel Soruları

DDR şu soruları cevaplamaya çalışır:

Hangi identity?

Hangi sensitive data?

Ne kadar data?

Hangi action?

Hangi source?

Hangi destination?

Behavior normal mi?

Identity riskli mi?

Data dışarı çıkıyor mu?

Response gerekiyor mu?

Bu context birleşimi Data-Centric Threat Detection oluşturur.

### DSPM + DDR

DSPM posture'u gösterir.

DDR runtime activity'yi gösterir.

Örneğin:

DSPM:

Restricted Data in Cloud Storage.

Access:

350 Users.

DDR:

User X suddenly downloads 25.000 files.

Bu high-risk data threat olabilir.

### DLP + DDR

DLP:

User external upload yapıyor.

DDR:

Aynı user son 15 dakikada 40.000 sensitive records access etti.

Birlikte Data Exfiltration confidence yükselir.

### DAM + DDR

DAM:

DBA executes bulk customer query.

DDR:

Query volume user baseline'ından 200 kat yüksek.

Bu Insider Threat veya compromised DBA account göstergesi olabilir.

### ITDR + DDR

ITDR:

Identity compromised olabilir.

DDR:

Compromised identity Restricted Data üzerinde mass retrieval gerçekleştiriyor.

Bu identity threat'in data impact'ini gösterir.

### EDR + DDR

EDR:

Endpoint üzerinde malicious process detect etti.

DDR:

Aynı endpoint sensitive files üzerinde mass access gerçekleştiriyor.

Bu ransomware veya exfiltration incident olabilir.

### DDR + SIEM

DDR events SIEM'e aktarılabilir.

SIEM:

Identity

Endpoint

Network

Cloud

DLP

DAM

PAM

DDR

signals'ını correlate ederek attack story oluşturabilir.

### DDR + SOAR

High-confidence DDR event automatic response tetikleyebilir.

Örneğin:

Bulk Restricted Data Access

Compromised Identity

External Upload

=

Revoke Session

Block Upload

Isolate Endpoint

Open Incident.

Bu Data Detection'dan Data Response'a geçiştir.

### \11. Katman: Insider Threat Protection

İç tehdit Data Security Architecture'ın doğal parçasıdır.

Malicious Employee,

Negligent User,

Compromised Account,

Privileged Insider,

Third-Party User,

Service Account,

AI Agent

sensitive data riskine neden olabilir.

Bu nedenle Insider Threat ayrı bir ürün yerine bütün mimarinin ortak use case'i olarak ele alınmalıdır.

### Insider Threat Detection

Güçlü model:

#### Identity Context

#### Data Sensitivity

#### Behavior

#### Data Volume

#### Destination

#### Privilege

=

#### Insider Data Risk

şeklinde düşünülebilir.

### Low-and-Slow Exfiltration

Insider her zaman milyonlarca records tek seferde indirmez.

Her gün küçük miktarda data çıkarabilir.

Historical behavior analysis ve DDR bu pattern'i tespit etmeye yardımcı olabilir.

### Departing Employee Risk

İşten ayrılma dönemindeki users için risk-based monitoring uygulanabilir.

Örneğin user daha önce hiç erişmediği source code repositories'i clone etmeye başlarsa investigation gerekebilir.

Ancak monitoring privacy ve legal governance kapsamında yürütülmelidir.

### \12. Katman: Zero Trust Data Security

Zero Trust yalnız network architecture değildir.

Data Security'ye de uygulanmalıdır.

Temel prensip:

**Never Trust, Always Verify.**

User internal network'te olduğu için otomatik trusted kabul edilmez.

Access:

Identity

Device

Data

Context

Behavior

Risk

üzerinden değerlendirilir.

### Zero Trust Data Access

Örnek policy:

User = Finance Analyst.

Data = Restricted.

Device = Managed.

MFA = Phishing-Resistant.

Location = Trusted.

Risk = Low.

Action = Read.

Result:

Allow.

Ancak:

Device = Unmanaged.

Risk = High.

Action = Export.

Result:

Deny.

Bu context-aware Data Security'dir.

### Continuous Authorization

User login olduktan sonra bütün session boyunca trusted kabul edilmemelidir.

Risk değişirse access yeniden değerlendirilebilir.

Örneğin DDR high-risk behavior detect ettiğinde:

Step-Up Authentication

Session Revocation

Data Access Restriction

uygulanabilir.

### \13. Katman: SIEM ve SOC – Data Security Operations

Data Security controls çok sayıda telemetry üretir.

Bu events operational security process'e bağlanmalıdır.

SIEM:

DLP

DSPM

DAM

DDR

IAM

PAM

ITDR

EDR

Cloud

SaaS

events'ini merkezi olarak correlate edebilir.

### Data Security SOC Use Case'leri

SOC için önemli scenarios:

Sensitive Data Bulk Download

Database Bulk Export

Restricted File External Sharing

USB Data Copy

Personal Cloud Upload

Sensitive Data to Public AI

Compromised Identity + Sensitive Data Access

Privileged User Anomaly

Service Account Data Access Spike

AI Agent Bulk Retrieval

AI Agent External Data Transfer

Shadow Data Exposure

Public Sensitive Cloud Storage

gibi use case'lerdir.

### Data-Centric SOC

Traditional SOC:

IP,

Endpoint,

Malware,

Account

üzerinden investigation yapabilir.

Data-Centric SOC şu soruyu ekler:

**“Bu incident sırasında hangi data risk altındaydı?”**

Bu business impact analysis'i güçlendirir.

### \14. Katman: SOAR ve Automated Data Response

Her Data Security incident manuel response beklememelidir.

High-confidence incidents için automated actions uygulanabilir.

Örneğin:

Revoke Session

Disable Sharing Link

Block USB

Block Upload

Terminate Database Session

Revoke API Token

Disable AI Agent

Isolate Endpoint

Require MFA

gibi actions uygulanabilir.

### Adaptive Data Security

En ileri Data Security Architecture static policy yerine risk-adaptive policies kullanır.

Örneğin:

Normal User + Internal Data → Allow.

High-Risk User + Confidential Data → Step-Up MFA.

Compromised User + Restricted Data → Block.

High-Risk AI Agent + External Destination → Disable Tool.

Bu **Adaptive Data Security** modelidir.

### \15. Katman: AI Data Security

Modern Data Security Architecture artık AI'yı ayrı değerlendiremez.

LLM,

RAG,

Vector Database,

AI Agent,

Prompt Logs,

Agent Memory,

AI Tools

Data Security scope'una alınmalıdır.

### AI Data Flow

Örnek:

User

↓

Prompt

↓

AI Agent

↓

RAG

↓

Vector Database

↓

Corporate Data

↓

LLM

↓

Tool Call

↓

External / Internal System.

Bu chain içerisindeki her hop security control gerektirir.

### Permission-Aware RAG

AI user'ın access edemediği document'ı retrieve etmemelidir.

Original permissions retrieval layer'da korunmalıdır.

Bu AI Data Security'nin en önemli controls'ından biridir.

### AI Agent Least Privilege

Agent yalnız gerekli:

Tools

Data

Actions

Destinations

üzerinde permissions'a sahip olmalıdır.

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

### AI Agent + DDR

DDR AI Agent'ın data behavior'ını monitor edebilir.

Örneğin:

Agent normalde 500 records retrieve ediyor.

Bir anda:

500.000 records.

Bu anomaly high-risk olabilir.

### AI Agent + DLP

Agent Restricted Data'yı external API'ye göndermeye çalışıyorsa DLP policy bunu block edebilir.

Bu machine-to-machine Data Loss Prevention use case'idir.

### AI Agent Kill Switch

Critical agents için emergency disable capability bulunmalıdır.

Security Team gerektiğinde:

Agent Identity

Token

Tool Access

Data Access

External Connectivity

yetkilerini revoke edebilmelidir.

### Kurumsal Veri Güvenliği Mimarisi Nasıl Görünmelidir?

Modern architecture'ı basitleştirirsek:

#### DATA SOURCES

Database

File Server

Endpoint

Microsoft 365

SaaS

Cloud

Backup

Data Lake

Source Code

AI / RAG / Vector DB

↓

#### DATA DISCOVERY

↓

#### DATA CLASSIFICATION

↓

#### DSPM

↓

#### DATA OWNERSHIP & GOVERNANCE

↓

#### IAM / IGA / PAM

↓

#### ENCRYPTION / KMS / HSM

↓

#### DLP + DAM

↓

#### DDR

↓

#### ZERO TRUST / CONTINUOUS AUTHORIZATION

↓

#### SIEM / SOC

↓

#### SOAR / AUTOMATED RESPONSE

şeklinde düşünülebilir.

Ancak bu tamamen linear bir architecture değildir.

Katmanlar sürekli birbirleriyle data paylaşmalıdır.

### Modern Data Security Control Loop

Daha doğru model bir feedback loop'tur:

#### Discover

↓

#### Classify

↓

#### Understand Exposure

↓

#### Control Access

↓

#### Protect Data

↓

#### Monitor Usage

↓

#### Detect Threat

↓

#### Respond

↓

#### Reassess

↓

#### Improve

Bu sürekli çalışan Data Security lifecycle'dır.

### Discover

Hangi data mevcut?

Shadow Data var mı?

Yeni SaaS repository oluştu mu?

Yeni AI vector store oluşturuldu mu?

Discovery sürekli olmalıdır.

### Classify

Yeni data'nın sensitivity'si belirlenmelidir.

Classification dynamic olabilir.

Örneğin document içerisine customer data eklendiğinde classification değişebilir.

### Understand Exposure

DSPM:

Kim erişebilir?

Public exposure var mı?

Excessive permissions var mı?

Encryption eksik mi?

sorularını değerlendirir.

### Control Access

IAM, IGA ve PAM:

Kim erişebilir?

Ne kadar süre?

Hangi privilege?

sorularını yönetir.

### Protect

Encryption ve DLP:

Data storage ve movement üzerinde protection sağlar.

### Monitor

DAM, DLP, Cloud Audit ve application telemetry data usage visibility sağlar.

### Detect

DDR, UEBA, ITDR ve SIEM riskli behavior'ı tespit eder.

### Respond

DLP, IAM, PAM, SOAR ve endpoint controls üzerinden response uygulanabilir.

### Reassess

Incident sonrası:

Permissions,

Policies,

Classification,

Data Location,

Risk Score

yeniden değerlendirilir.

Bu continuous improvement sağlar.

### Data Security Architecture'da Risk-Based Yaklaşım

Her data aynı seviyede korunmamalıdır.

Public brochure ile customer identity database aynı controls'a sahip olmak zorunda değildir.

Security investment data value ve risk'e göre önceliklendirilmelidir.

Basit model:

**Risk = Data Sensitivity × Exposure × Threat × Business Impact**

şeklinde düşünülebilir.

Bu matematiksel standart formül olmak zorunda değildir; risk prioritization mantığını ifade eder.

### Crown Jewels Yaklaşımı

İlk olarak kurumun **Crown Jewels** olarak tanımlanan en kritik data assets'i belirlenebilir.

Örneğin:

Customer Database

Source Code

Financial Systems

Authentication Secrets

Strategic Documents

Personal Data

Critical Operational Data.

Data Security programı önce bu assets üzerinde olgunlaştırılabilir.

### Data Security Programı Nereden Başlamalıdır?

En sık yapılan hata onlarca security technology'yi aynı anda deploy etmeye çalışmaktır.

Daha doğru başlangıç:

**\1. Critical Data'yı belirle.**

**\2. Data Discovery yap.**

**\3. Classification oluştur.**

**\4. Data Owners belirle.**

**\5. Access Exposure analiz et.**

**\6. Excessive permissions azalt.**

**\7. Encryption baseline oluştur.**

**\8. DLP ile movement control et.**

**\9. DAM ile database activity izle.**

**\10. DSPM ile posture'u sürekli değerlendir.**

**\11. DDR ile active data threats'i tespit et.**

**\12. SIEM/SOC ile operationalize et.**

**\13. SOAR ile response'u hızlandır.**

**\14. AI data flows'u aynı modele dahil et.**

Bu phased approach daha sürdürülebilirdir.

### Phase 1 – Visibility

Amaç:

**“Data nerede?”**

Data Discovery

Data Inventory

Classification

DSPM.

### Phase 2 – Access Governance

Amaç:

**“Kim erişebilir?”**

IAM

IGA

Access Review

Least Privilege

PAM.

### Phase 3 – Protection

Amaç:

**“Data nasıl korunuyor?”**

Encryption

KMS

DLP

Masking

Tokenization.

### Phase 4 – Monitoring

Amaç:

**“Data üzerinde ne oluyor?”**

DAM

DLP Telemetry

Cloud Audit

SaaS Activity.

### Phase 5 – Detection & Response

Amaç:

**“Aktif tehdit var mı?”**

DDR

UEBA

ITDR

SIEM

SOC

SOAR.

### Phase 6 – Adaptive Data Security

Amaç:

**“Risk değiştiğinde security controls otomatik adapte olabilir mi?”**

Continuous Authorization

Risk-Based DLP

Dynamic Access

Automated Response

AI Agent Controls.

Bu yüksek maturity seviyesidir.

### Data Security ve Ransomware

Ransomware yalnız endpoint security problemi değildir.

Attacker sensitive data'yı encryption öncesinde exfiltrate edebilir.

Bu double extortion riskidir.

Data Security Architecture:

Mass File Access

Bulk Download

Unusual SMB Activity

Sensitive Data Exfiltration

gibi behaviors'ı detect etmelidir.

DDR burada önemli context sağlayabilir.

### Data Security ve Backup

Backup Data Security'nin parçasıdır.

Backup içerisinde production data'nın tam kopyası bulunabilir.

Bu nedenle backup:

Encrypted

Access-Controlled

Immutable

Monitored

olmalıdır.

Backup credentials privileged security kapsamında korunmalıdır.

### Data Security ve Disaster Recovery

DR environment production ile aynı data'yı içerebilir.

Ancak security controls bazen daha zayıf olabilir.

DR databases ve backups Data Discovery scope'una alınmalıdır.

### Data Security ve DevSecOps

Developers production data'yı test environment'a kopyalayabilir.

Bu risklidir.

Test environments için:

Masking

Synthetic Data

Tokenization

uygulanabilir.

Source code içerisindeki secrets ayrıca scan edilmelidir.

### Data Security ve API Security

API modern data access layer'dır.

API authorization zayıfsa sensitive data exposure oluşabilir.

API security:

Authentication

Authorization

Rate Limiting

Data Filtering

Logging

DLP

ile birlikte değerlendirilmelidir.

### Data Security ve SaaS

SaaS platforms büyük miktarda corporate data saklayabilir.

Security teams:

External Sharing

Public Links

OAuth Apps

Third-Party Integrations

Data Downloads

Shadow SaaS

konularını monitor etmelidir.

### Data Security ve Cloud

Cloud Data Security shared responsibility gerektirir.

Cloud provider infrastructure security sağlayabilir.

Ancak customer:

Data Classification

IAM

Encryption Configuration

Public Exposure

DLP

Monitoring

gibi alanlardan sorumlu olabilir.

DSPM cloud data posture visibility'sini artırabilir.

### Multi-Cloud Data Security

AWS,

Azure,

Google Cloud,

SaaS

ve on-prem environments birlikte kullanılabilir.

Her platform için ayrı data visibility oluşursa blind spots meydana gelebilir.

Data Security Architecture mümkün olduğunca unified visibility sağlamalıdır.

### Data Security ve Third-Party Risk

Data suppliers, consultants ve business partners ile paylaşılabilir.

Bu nedenle Third-Party Data Access:

Time-Bound

Purpose-Limited

Monitored

olmalıdır.

Contract bittiğinde access revoke edilmelidir.

### Data Security ve Privacy

Data Security ile Data Privacy aynı kavram değildir.

Data Security:

Veriyi korur.

Data Privacy:

Personal data'nın hangi amaçlarla ve hangi kurallar çerçevesinde işlendiğini ele alır.

Ancak iki disiplin güçlü şekilde kesişir.

### KVKK ve Veri Güvenliği

Kişisel verilerin korunması açısından access control, logging, encryption, data minimization, secure disposal ve monitoring gibi teknik ve organizasyonel tedbirler önemli olabilir.

Ancak belirli bir teknolojinin kullanılması tek başına KVKK uyumluluğu anlamına gelmez.

Data Security controls risk ve işleme faaliyetlerinin niteliğine göre değerlendirilmelidir.

### GDPR ve Data Security

GDPR kapsamında da personal data protection için appropriate technical and organizational measures yaklaşımı önemlidir.

Encryption, access control ve monitoring gibi controls risk-based security programının parçası olabilir.

Ancak compliance yalnız technology deployment ile sağlanmaz.

### PCI DSS ve Data Security

Payment card data bulunan environments için access control, encryption, logging ve monitoring kritik önem taşır.

DLP ve DAM gibi technologies cardholder data exposure'ının kontrol edilmesine katkı sağlayabilir.

Exact requirements ilgili kapsam ve standardın geçerli sürümüne göre ayrıca değerlendirilmelidir.

### Data Security Governance

Technology olmadan governance eksik kalır.

Governance olmadan technology kontrolsüz büyür.

Bu nedenle Data Security Steering structure oluşturulabilir.

Participants:

Information Security

IT

Data Owners

Privacy

Legal

Risk

Internal Audit

Business Units

AI Governance

olabilir.

### Data Security Policy

Kurumsal Data Security Policy en azından şu alanları kapsayabilir:

Data Classification

Data Ownership

Access Control

Encryption

Data Sharing

DLP

Retention

Backup

Third-Party Sharing

Cloud

AI Usage

Incident Response

Secure Disposal.

### Data Security Standards

Policy üst seviye kuraldır.

Standard ise uygulanabilir technical requirements belirler.

Örneğin:

Restricted Data must be encrypted at rest.

Restricted Data external sharing prohibited.

Privileged database activity monitored.

Public AI upload prohibited for Restricted Data.

Bu measurable security requirements oluşturur.

### Exception Management

Business her zaman security standard'a tam uyamayabilir.

Exception process olmalıdır.

Exception:

Owner

Reason

Risk

Compensating Control

Expiration Date

Approval

içermelidir.

Permanent exceptions oluşmamalıdır.

### Data Security Metrics

Ölçemediğiniz programı yönetmek zordur.

Data Security KPI'ları:

Sensitive Data Coverage

Classification Coverage

Unknown Data Owners

Public Sensitive Data Stores

Unencrypted Sensitive Data

Excessive Permissions

Dormant Access

DLP Violations

External Sharing

DAM High-Risk Queries

DDR High-Risk Alerts

Bulk Download Events

Data Exfiltration Attempts

AI Sensitive Prompt Events

AI Agent Risk Events

Mean Time to Detect

Mean Time to Respond

gibi metrics olabilir.

### Sensitive Data Coverage

Critical data'nın yüzde kaçı discovery kapsamındadır?

Örneğin:

Databases %100.

Cloud Storage %95.

SaaS %60.

Bu coverage gaps'i gösterir.

### Classification Coverage

Sensitive data'nın ne kadarı doğru classify edilmiştir?

Unknown veya unlabeled data risk oluşturabilir.

### Access Exposure Metric

Restricted data'ya kaç user erişebilir?

Bu sayı zaman içerisinde azalıyor mu?

Bu Least Privilege programının önemli metric'idir.

### DDR Detection Coverage

Hangi critical data sources runtime threat monitoring kapsamındadır?

Database?

Cloud?

SaaS?

Endpoint?

AI?

Coverage ölçülmelidir.

### False Positive Rate

DDR ve DLP çok fazla false positive üretirse analyst fatigue oluşur.

Policy tuning ve behavior baselines sürekli optimize edilmelidir.

### MTTD ve MTTR

Mean Time to Detect:

Data threat ne kadar hızlı detect ediliyor?

Mean Time to Respond:

Threat tespit edildikten sonra ne kadar hızlı containment uygulanıyor?

Bu iki metric Data Security Operations maturity'sini gösterebilir.

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

Birinci hata Data Security'yi yalnız DLP olarak görmektir.

İkinci hata hassas verinin nerede olduğunu bilmeden security controls deploy etmektir.

Üçüncü hata Data Classification'ı yalnız document label projesi olarak değerlendirmektir.

Dördüncü hata bütün users'a broad permissions vermektir.

Beşinci hata privileged users'ı yeterince monitor etmemektir.

Altıncı hata encryption uygulayıp key management'i ihmal etmektir.

Yedinci hata database activity'yi yalnız native logs ile sınırlı değerlendirmektir.

Sekizinci hata DSPM ile posture bulunmasına rağmen remediation yapmamaktır.

Dokuzuncu hata DLP'yi yalnız e-mail üzerinde uygulamaktır.

Onuncu hata DDR olmadan active data threat visibility'sinin yeterli olduğunu düşünmektir.

On birinci hata Shadow Data'yı görmezden gelmektir.

On ikinci hata backups ve DR copies'i Data Security scope'u dışında bırakmaktır.

On üçüncü hata AI, RAG, vector databases ve Agent Memory'yi Data Security scope'una almamaktır.

On dördüncü hata AI Agents'a broad permissions vermektir.

On beşinci hata SIEM/SOC integration olmadan Data Security tools'u silo halinde işletmektir.

On altıncı hata her security event'e aynı risk seviyesini vermektir.

On yedinci hata Data Owner sorumluluğunu tanımlamamaktır.

On sekizinci hata security architecture'ı bir kere kurup tamamlanmış kabul etmektir.

### Kurumsal Veri Güvenliği Kontrol Listesi

- Data Security Strategy mevcut mu?
- Data Security Policy mevcut mu?
- Data Owners tanımlı mı?
- Critical Data belirlenmiş mi?
- Crown Jewels inventory mevcut mu?
- Data Discovery uygulanıyor mu?
- Structured Data taranıyor mu?
- Unstructured Data taranıyor mu?
- Cloud Data taranıyor mu?
- SaaS Data taranıyor mu?
- Shadow Data detect ediliyor mu?
- Dark Data belirleniyor mu?
- Data Classification uygulanıyor mu?
- Public/Internal/Confidential/Restricted modeli mevcut mu?
- Classification security policies'i tetikliyor mu?
- IAM uygulanıyor mu?
- IGA uygulanıyor mu?
- Least Privilege uygulanıyor mu?
- Need-to-Know uygulanıyor mu?
- Access Reviews gerçekleştiriliyor mu?
- Permission Creep ölçülüyor mu?
- Dormant Access kaldırılıyor mu?
- PAM mevcut mu?
- Privileged credentials vault içerisinde mi?
- JIT Access uygulanıyor mu?
- Zero Standing Privilege değerlendiriliyor mu?
- Data at Rest encrypted mı?
- Data in Transit encrypted mı?
- Encryption Keys merkezi yönetiliyor mu?
- KMS/HSM kullanımı değerlendiriliyor mu?
- Key Rotation uygulanıyor mu?
- Backup encrypted mı?
- DLP endpoint üzerinde aktif mi?
- E-Mail DLP mevcut mu?
- Web Upload kontrol ediliyor mu?
- USB controls uygulanıyor mu?
- SaaS DLP mevcut mu?
- AI DLP uygulanıyor mu?
- DSPM sensitive data posture'u izliyor mu?
- Public Sensitive Data detect ediliyor mu?
- Excessive Permissions DSPM ile bulunuyor mu?
- DAM critical databases üzerinde aktif mi?
- Privileged SQL activity izleniyor mu?
- Bulk Queries detect ediliyor mu?
- DDR uygulanıyor mu?
- DDR sensitive data behavior'ını izliyor mu?
- Bulk Downloads detect ediliyor mu?
- Mass Retrieval detect ediliyor mu?
- Data Exfiltration use case'leri mevcut mu?
- Low-and-Slow Exfiltration izleniyor mu?
- DDR DLP ile entegre mi?
- DDR DSPM ile entegre mi?
- DDR DAM ile entegre mi?
- DDR ITDR ile entegre mi?
- DDR EDR context kullanıyor mu?
- Insider Threat use case'leri mevcut mu?
- Service Accounts izleniyor mu?
- Machine Identities inventory'de mi?
- Third-Party Access monitor ediliyor mu?
- Zero Trust Data Access uygulanıyor mu?
- Continuous Authorization değerlendiriliyor mu?
- SIEM Data Security telemetry alıyor mu?
- SOC Data-Centric use case'lere sahip mi?
- SOAR Data Security response playbook'larına sahip mi?
- Automated Session Revocation mümkün mü?
- Automated Upload Blocking mümkün mü?
- AI Systems inventory'de mi?
- Shadow AI detect ediliyor mu?
- RAG Data Sources inventory'de mi?
- Permission-Aware RAG uygulanıyor mu?
- Vector Databases Data Security scope'unda mı?
- AI Agent identities tanımlı mı?
- AI Agent permissions Least Privilege mı?
- Agent Tool Access sınırlı mı?
- Agent Data Access sınırlı mı?
- Agent External Destinations kontrol ediliyor mu?
- AI Agent DDR monitoring mevcut mu?
- AI Agent Kill Switch mevcut mu?
- Prompt Logs korunuyor mu?
- Agent Memory korunuyor mu?
- AI Data Lineage biliniyor mu?
- Data Retention uygulanıyor mu?
- Secure Disposal uygulanıyor mu?
- Data Security KPIs ölçülüyor mu?
- MTTD ölçülüyor mu?
- MTTR ölçülüyor mu?
- Data Security Architecture düzenli review ediliyor mu?

### Kurumsal Veri Güvenliği Olgunluk Modeli

**Seviye 1 – Reactive Data Security:** Kurum verilerin nerede olduğunu tam olarak bilmez. Security olay sonrası devreye girer. Access ve sharing controls dağınıktır.

**Seviye 2 – Controlled Data Security:** Data Classification, encryption, IAM ve temel DLP uygulanır. Kritik data için temel protection oluşturulur.

**Seviye 3 – Data-Centric Security:** Data Discovery, DSPM, IGA, PAM ve DAM ile data location, sensitivity, access ve usage daha görünür hale gelir. Least Privilege sistematik uygulanmaya başlanır.

**Seviye 4 – Data Detection and Response:** DDR, UEBA, ITDR, SIEM ve SOC entegrasyonları ile sensitive data üzerindeki runtime threats tespit edilir. Human ve machine identities birlikte izlenir.

**Seviye 5 – Adaptive Zero Trust Data Security:** Classification, DSPM, IAM/PAM, DLP, DAM, DDR, AI Data Security, SIEM ve SOAR gerçek zamanlı risk context'i paylaşır. Access ve protection policies identity, data sensitivity, behavior ve destination riskine göre dinamik olarak değişir.

Olgunluk yolculuğu:

#### Know the Data

↓

#### Classify the Data

↓

#### Control Access

↓

#### Protect the Data

↓

#### Monitor the Data

↓

#### Detect Data Threats

↓

#### Respond

↓

#### Adapt

şeklinde ilerler.

### Sık Sorulan Sorular

#### Kurumsal veri güvenliği nedir?

Kurumsal veri güvenliği; kurumun sahip olduğu verilerin keşfedilmesi, sınıflandırılması, erişimlerinin kontrol edilmesi, şifrelenmesi, hareketlerinin izlenmesi ve aktif tehditlere karşı korunmasını sağlayan teknik ve yönetişim süreçlerinin bütünüdür.

#### Data Security Architecture nedir?

Data Security Architecture; Data Discovery, Classification, IAM, PAM, Encryption, DLP, DSPM, DAM, DDR, SIEM, SOC ve Zero Trust gibi güvenlik katmanlarının entegre şekilde çalıştığı veri merkezli güvenlik mimarisidir.

#### Veri güvenliği projesine nereden başlanmalıdır?

İlk adım çoğu kurum için kritik verilerin belirlenmesi ve Data Discovery yapılmasıdır. Nerede bulunduğu bilinmeyen data için etkili security policy oluşturmak zordur.

#### Data Classification neden önemlidir?

Classification, verinin sensitivity seviyesini belirler ve encryption, access, DLP, sharing ve monitoring gibi security controls'ın risk seviyesine göre uygulanmasını sağlar.

#### DSPM nedir?

Data Security Posture Management, sensitive data'nın nerede olduğunu, kimlerin erişebildiğini ve hangi exposure veya configuration risks'in bulunduğunu sürekli analiz eden veri güvenliği yaklaşımıdır.

#### DLP nedir?

Data Loss Prevention, sensitive data'nın e-mail, endpoint, USB, web, SaaS, cloud veya AI gibi kanallar üzerinden kontrolsüz biçimde taşınmasını tespit ve engellemeye yönelik güvenlik yaklaşımıdır.

#### DAM nedir?

Database Activity Monitoring, database üzerinde gerçekleştirilen queries, logins, privilege changes, bulk exports ve administrative activities'i izleyen güvenlik teknolojisidir.

#### DDR nedir?

Data Detection and Response, sensitive data üzerinde gerçekleşen olağan dışı erişim, bulk download, mass retrieval, data exfiltration ve benzeri aktif tehdit davranışlarını data context içerisinde tespit etmeyi ve response süreçlerini tetiklemeyi amaçlayan veri güvenliği yaklaşımıdır.

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

DSPM ağırlıklı olarak Data Security Posture'a odaklanır: hassas veri nerede, kim erişebilir ve exposure nedir? DDR ise runtime behavior'a odaklanır: hassas veri üzerinde şu anda şüpheli bir activity gerçekleşiyor mu?

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

DLP çoğunlukla sensitive data'nın belirli channels üzerinden hareketini policy bazlı kontrol eder. DDR ise data access ve usage behavior'ını analiz ederek normal dışı ve potansiyel tehdit oluşturan davranışları tespit etmeye odaklanır.

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

DAM database activity visibility sağlar. DDR ise database activity dahil farklı data signals'ını behavior ve sensitivity context'iyle değerlendirerek aktif veri tehdidini anlamaya çalışır.

#### Encryption varsa DLP gerekir mi?

Çoğu kurumsal ortamda evet. Encryption stored veya transmitted data'yı koruyabilir ancak authorized user data'yı açtıktan sonra dışarı aktarabilir. DLP bu data movement'ı kontrol etmeye yardımcı olur.

#### Encryption varsa DAM gerekir mi?

Encryption authorized database queries'i engellemez. DAM authorized veya privileged users'ın database üzerinde hangi işlemleri gerçekleştirdiğini izlemek için kullanılabilir.

#### Zero Trust Data Security nedir?

Identity, device, data sensitivity, behavior ve risk context'ini sürekli değerlendirerek data access kararlarının dinamik olarak verilmesini amaçlayan Data Security yaklaşımıdır.

#### AI Data Security nedir?

LLM, RAG, AI Agent, vector database, prompt logs ve Agent Memory gibi AI components'ın eriştiği ve işlediği verilerin korunmasına yönelik Data Security disiplinidir.

#### AI Agent için DDR kullanılabilir mi?

Evet. DDR yaklaşımı AI Agent'ın sensitive data üzerinde gerçekleştirdiği olağan dışı bulk retrieval, unexpected repository access veya external data transfer gibi behaviors'ın tespitinde kullanılabilir.

#### DLP, DSPM, DAM ve DDR birlikte kullanılmalı mı?

Her kurumun ihtiyacı farklıdır ancak bu technologies farklı problemleri çözer. DSPM data posture'u, DLP data movement'ı, DAM database activity'yi, DDR ise runtime data threats'i ele alır. Birlikte kullanıldıklarında daha bütünsel Data Security visibility sağlanabilir.

#### SIEM Data Security için neden önemlidir?

SIEM DLP, DAM, DDR, IAM, PAM, EDR ve cloud gibi farklı sources'dan gelen security events'i correlate ederek incident'in bütününü anlamaya yardımcı olur.

#### SOC Data Security'de ne yapar?

SOC data threats'i izler, alerts'i investigate eder, identity ve data context'i değerlendirir ve gerektiğinde containment ve incident response süreçlerini yürütür.

### Sonuç: Modern Veri Güvenliği Veriyi Saklamak Değil, Verinin Tüm Yaşam Döngüsünü Kontrol Etmektir

Kurumsal Data Security geçmişte çoğunlukla encryption, database permissions ve DLP gibi bağımsız security controls üzerinden ele alınıyordu.

Ancak modern IT environments çok daha karmaşıktır.

Data artık yalnız database içerisinde değildir.

Data:

Cloud'dadır.

SaaS'tadır.

Endpoint'tedir.

Backup'tadır.

Developer environment'ındadır.

Microsoft 365 içerisindedir.

API üzerinden hareket etmektedir.

AI prompt'undadır.

Vector database içerisindedir.

RAG context'indedir.

AI Agent Memory içerisindedir.

Ve bu data'ya yalnız employees değil:

Applications,

Service Accounts,

Third Parties,

Automation Bots,

Machine Identities

ve:

#### AI Agents

erişmektedir.

Bu nedenle modern Data Security Architecture'ın merkezine artık yalnız firewall veya storage değil:

#### DATA

yerleştirilmelidir.

Kurumsal veri güvenliği mimarisinin temel zinciri:

#### Data Discovery

↓

#### Data Classification

↓

#### Data Ownership

↓

#### DSPM

↓

#### IAM / IGA / PAM

↓

#### Encryption / KMS

↓

#### DLP

↓

#### DAM

↓

#### DDR

↓

#### Zero Trust

↓

#### SIEM / SOC

↓

#### SOAR / Automated Response

şeklinde düşünülebilir.

Bu zincirde her katmanın görevi farklıdır.

**Data Discovery:** Hangi veriye sahibiz?

**Data Classification:** Veri ne kadar hassas?

**Data Ownership:** Bu veriden kim sorumlu?

**DSPM:** Veri nerede ve ne kadar exposed?

**IAM / IGA:** Kim erişebilir?

**PAM:** Ayrıcalıklı erişimler nasıl kontrol ediliyor?

**Encryption:** Veri okunamaz hale getiriliyor mu?

**DLP:** Veri nereye gidiyor?

**DAM:** Database üzerinde ne yapılıyor?

**DDR:** Hassas veri üzerinde şu anda tehdit davranışı var mı?

**Zero Trust:** Bu erişime hâlâ güvenmeli miyiz?

**SIEM / SOC:** Olayın bütünü ne anlatıyor?

**SOAR:** Tehdide ne kadar hızlı müdahale edebiliriz?

İşte modern Data Security'nin özü bu soruların birbirinden bağımsız değil, **aynı veri bağlamı içerisinde cevaplanmasıdır.**

Bir user'ın gece saat 02:00'de login olması tek başına incident olmayabilir.

Ancak:

Identity Risk = High

Data Classification = Restricted

Bulk Database Query

25.000 File Download

External Cloud Upload

olduğunda tamamen farklı bir security picture ortaya çıkar.

Data-Centric Security bu resmi oluşturmayı amaçlar.

AI ile birlikte bu model daha da önemli hale gelmektedir.

Çünkü geleceğin veri erişim zinciri yalnız:

**Human → Application → Data**

olmayacaktır.

Yeni model:

**Human → AI Agent → Tool → API → Application → Data**

ve hatta:

**AI Agent → AI Agent → Tool → Data**

şeklinde ilerleyebilir.

Bu nedenle geleceğin Data Security Architecture'ı yalnız human users'ı değil **Human + Machine + AI identities** bütününü kapsamak zorundadır.

Kurumsal veri güvenliğinin nihai hedefi bütün veriyi kilitlemek değildir.

Aşırı security business'ı çalışamaz hale getirebilir.

Asıl hedef:

**Doğru kimliğin, doğru zamanda, doğru cihaz ve risk koşulları altında, doğru amaç için, yalnız gerekli hassas veriye, gerekli minimum yetkiyle erişmesini; verinin yaşam döngüsü boyunca korunmasını; bütün kritik veri aktivitelerinin görünür olmasını ve normal dışı davranış gerçekleştiğinde tehdidin veri dışarı çıkarılmadan mümkün olduğunca erken tespit edilerek müdahale edilebilmesini sağlamaktır.**

Bu nedenle serinin tamamını tek cümlede özetlemek gerekirse:

**Modern Kurumsal Veri Güvenliği; hassas veriyi Data Discovery ile bulan, Data Classification ile anlamlandıran, DSPM ile exposure'ı görünür hale getiren, IAM/IGA/PAM ile erişimi yöneten, Encryption ile veriyi koruyan, DLP ile veri hareketini kontrol eden, DAM ile veritabanı aktivitelerini izleyen, DDR ile aktif veri tehditlerini tespit eden, Zero Trust ile erişimi sürekli doğrulayan ve SIEM/SOC/SOAR ile olayları analiz edip müdahale eden sürekli, veri merkezli ve risk tabanlı bir güvenlik mimarisidir.**