# Cloud Data Security Nedir? Microsoft 365, SaaS, AWS, Azure ve Google Cloud Üzerinde Veri Koruma

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/veri-guvenligi-siniflandirma/cloud-data-security-nedir

![Cloud Data Security Nedir? Microsoft 365, SaaS, AWS, Azure ve Google Cloud Üzerinde Veri Koruma](/images/bilgi-merkezi/covers/cover-veriguv-08.webp)

Cloud Data Security, bulut ortamlarında oluşturulan, saklanan, işlenen ve paylaşılan kurumsal verilerin yetkisiz erişim, veri sızıntısı, yanlış yapılandırma, hesap ele geçirme, kötü amaçlı iç kullanıcı, kontrolsüz paylaşım ve veri kaybı gibi risklere karşı korunmasını sağlayan güvenlik yaklaşımıdır. Türkçede **bulut veri güvenliği** olarak ifade edilen Cloud Data Security; yalnızca cloud storage üzerinde encryption açmak anlamına gelmez. Veri keşfi, veri sınıflandırma, kimlik ve erişim yönetimi, DLP, DSPM, cloud security posture, paylaşım kontrolleri, encryption, logging ve incident response gibi birçok güvenlik katmanının birlikte çalışmasını gerektirir.

Kurumsal verinin bulunduğu yer son yıllarda önemli ölçüde değişmiştir. Geçmişte kritik verilerin büyük bölümü kurumun kendi veri merkezindeki file server, database ve uygulamalarda bulunurken bugün aynı veri Microsoft 365, SharePoint, OneDrive, Teams, SaaS uygulamaları, AWS, Microsoft Azure, Google Cloud ve çok sayıda üçüncü taraf platform arasında hareket edebilmektedir.

Bir Excel dosyası sabah şirket bilgisayarında oluşturulabilir, birkaç dakika sonra OneDrive'a yüklenebilir, Teams üzerinden paylaşılabilir, daha sonra bir SaaS uygulamasına aktarılabilir ve son olarak bir AI uygulamasının prompt'una eklenebilir.

Bu nedenle modern veri güvenliğinde fiziksel veya mantıksal network perimeter artık tek başına yeterli değildir.

Asıl güvenlik sınırı **verinin kendisi** haline gelmektedir.

Cloud Data Security'nin temel sorusu bu nedenle:

**“Verimiz hangi cloud platformunda?”**

sorusundan çok daha geniştir.

Kurum aynı zamanda şu soruların cevaplarını bilmelidir:

#### Hangi hassas veriler cloud ortamlarında bulunuyor?

#### Bu verilere kimler erişebiliyor?

#### Kimlerle paylaşılıyor?

#### Public access var mı?

#### External users erişebiliyor mu?

#### Veri encrypted mı?

#### Hangi kullanıcı veriyi indirdi?

#### Hangi SaaS uygulaması veriye erişiyor?

#### AI uygulamaları bu veriyi kullanabiliyor mu?

#### Verinin kontrolsüz kopyaları başka cloud ortamlarında bulunuyor mu?

Bu sorular cevaplanamıyorsa kurum cloud kullanıyor olabilir ancak cloud data security açısından yeterli visibility'ye sahip değildir.

### Cloud Data Security Nedir?

Cloud Data Security; IaaS, PaaS ve SaaS ortamlarında bulunan verilerin tüm yaşam döngüsü boyunca korunmasına yönelik politika, süreç ve teknolojilerin bütünüdür.

Amaç yalnızca saldırganların veriye erişmesini engellemek değildir.

Cloud Data Security aynı zamanda yanlışlıkla yapılan paylaşımları, gereğinden fazla kullanıcı yetkilerini, public storage configurations, unmanaged SaaS kullanımını, forgotten data copies ve Shadow Data gibi riskleri de yönetmeye çalışır.

Bu nedenle modern Cloud Data Security üç temel soruya cevap vermelidir:

#### Veri nerede?

#### Kim erişebiliyor?

#### Veriyle ne yapılıyor?

Bu üç sorunun birlikte cevaplanması cloud data visibility'nin temelini oluşturur.

### Cloud Security ile Cloud Data Security Aynı Şey midir?

Hayır.

Cloud Security daha geniş bir kavramdır.

Cloud infrastructure içerisinde:

Network Security

Workload Security

IAM

Container Security

Cloud Configuration

API Security

gibi alanları kapsayabilir.

Cloud Data Security ise özellikle veriye odaklanır.

Örneğin bir cloud storage resource teknik olarak doğru yapılandırılmış olabilir ancak içerisinde gereksiz şekilde milyonlarca kişisel veri tutuluyorsa Data Security problemi devam eder.

Cloud Security:

**“Resource güvenli mi?”**

sorusunu sorarken Cloud Data Security buna ek olarak:

**“Resource içerisinde hangi veri var ve bu verinin burada bulunması güvenli mi?”**

sorusunu sorar.

Bu ayrım modern cloud security mimarisinin anlaşılması açısından önemlidir.

### Shared Responsibility Model ve Veri Güvenliği

Cloud security konusunda en önemli kavramlardan biri **Shared Responsibility Model**, yani paylaşılan sorumluluk modelidir.

Cloud provider fiziksel infrastructure, underlying platform ve belirli security controls'den sorumlu olabilir.

Ancak customer kendi:

Data

Identity

Permissions

Configurations

Applications

Security Policies

üzerinde önemli sorumluluk taşımaya devam eder.

Cloud provider'ın infrastructure'ının güvenli olması, customer data'nın otomatik olarak güvenli olduğu anlamına gelmez.

Örneğin kullanıcı yanlışlıkla sensitive storage'ı public yaparsa provider infrastructure compromise olmadan data breach meydana gelebilir.

### Cloud'da En Büyük Risk Her Zaman Hacker mıdır?

Hayır.

Cloud Data Security incidents yalnız external attackers nedeniyle oluşmaz.

Çok yaygın risklerden bazıları:

Misconfiguration

Excessive Permissions

Public Sharing

Stolen Credentials

Unmanaged SaaS

Shadow Data

Human Error

Third-Party Access

Insider Threat

olabilir.

Örneğin employee Confidential document için “Anyone with the link” sharing oluşturabilir.

Bu durumda sophisticated cyber attack gerekmeyebilir.

Tek bir yanlış sharing configuration data exposure oluşturabilir.

### Cloud Misconfiguration Nedir?

Cloud Misconfiguration, cloud resource'un güvenlik açısından yanlış veya riskli şekilde yapılandırılmasıdır.

Örneğin:

Public Storage

Overly Permissive IAM

Unencrypted Database

Open Network Access

Anonymous Sharing

gibi durumlar misconfiguration olarak değerlendirilebilir.

Cloud environments çok dynamic olduğu için bu configurations sürekli değişebilir.

Bu nedenle yalnız yıllık audit yeterli olmayabilir.

### Public Cloud Storage Riski

Cloud storage yanlışlıkla internet üzerinden erişilebilir hale getirilebilir.

Storage içerisinde sensitive data varsa bu kritik exposure oluşturabilir.

Bu nedenle security team yalnız:

“Storage public mı?”

sorusunu değil:

**“Public storage içerisinde hangi data bulunuyor?”**

sorusunu da sormalıdır.

Public storage içerisinde marketing images bulunması ile customer personal data bulunması aynı risk değildir.

### Data Context Neden Önemlidir?

Cloud security finding'leri data context olmadan yanlış prioritize edilebilir.

Örneğin iki storage resource public olabilir.

Birincisi public website images içeriyor.

İkincisi customer database export içeriyor.

Configuration finding aynı görünse de business risk tamamen farklıdır.

DSPM bu nedenle Cloud Data Security içerisinde önemli hale gelmektedir.

### Microsoft 365 Veri Güvenliği

Microsoft 365 birçok kurumda en büyük unstructured data repositories'den biri haline gelmiştir.

E-mail,

Word,

Excel,

PowerPoint,

Teams messages,

SharePoint documents,

OneDrive files

çok büyük miktarda corporate data barındırabilir.

Bu nedenle Microsoft 365 yalnız collaboration platform değil aynı zamanda kritik Data Security environment olarak değerlendirilmelidir.

### Microsoft 365'te Hassas Veri Nerelerde Bulunabilir?

Sensitive information farklı services içerisinde bulunabilir.

Örneğin:

Exchange Online → E-mails

SharePoint Online → Corporate Documents

OneDrive → Personal Work Files

Teams → Messages and Shared Files

Office Documents → Embedded Sensitive Data

Bu nedenle yalnız e-mail DLP uygulamak yeterli değildir.

Data protection bütün collaboration ecosystem'i kapsamalıdır.

### SharePoint Veri Güvenliği

SharePoint document collaboration için güçlü bir platformdur.

Ancak permissions zaman içerisinde karmaşıklaşabilir.

Site permissions,

folder permissions,

file permissions,

sharing links,

guest users

bir araya geldiğinde effective access'i anlamak zorlaşabilir.

Bu nedenle SharePoint security'nin önemli sorusu:

**“Hangi sensitive document'a gerçekte kim erişebiliyor?”**

olmalıdır.

### SharePoint Permission Creep

Employee farklı projects ve departments içerisinde çalıştıkça SharePoint sites access'leri birikebilir.

Project bittikten sonra access kaldırılmazsa Permission Creep oluşabilir.

Yıllar içerisinde user yüzlerce site'a erişebilir hale gelebilir.

Bu nedenle periodic access review önemlidir.

### OneDrive Veri Güvenliği

OneDrive kullanıcı merkezli cloud storage olduğu için büyük miktarda corporate data barındırabilir.

Employee:

customer list,

contract,

financial spreadsheet,

source code,

personal data

gibi documents saklayabilir.

Bu nedenle OneDrive yalnız personal workspace olarak görülmemelidir.

Kurumsal Data Governance kapsamına alınmalıdır.

### OneDrive External Sharing Riski

User bir document için external sharing link oluşturabilir.

Bu legitimate collaboration için gerekli olabilir.

Ancak link uzun süre açık kalabilir.

Bu nedenle external links:

Owner

Creation Date

Expiry

Data Classification

Guest Identity

ile değerlendirilmelidir.

### **“Anyone with the Link” Neden Risklidir?**

Anonymous sharing links identity-based access control'u zayıflatabilir.

Link başka kişilere forward edilebilir.

Bu nedenle Confidential veya Restricted documents için anonymous links sınırlandırılabilir.

Classification-aware sharing policies burada önemlidir.

### Microsoft Teams Veri Güvenliği

Teams yalnız messaging platform değildir.

Teams üzerinden paylaşılan files çoğunlukla SharePoint veya OneDrive infrastructure'ında saklanabilir.

Bu nedenle Teams Data Security aslında:

Identity

Sharing

SharePoint

OneDrive

DLP

Retention

gibi controls'ün birleşimidir.

### Teams Üzerinden Veri Sızıntısı

User sensitive document'ı external participant bulunan Teams conversation içerisinde paylaşabilir.

Bu accidental data leakage olabilir.

DLP policy data classification ve recipient context'e göre action alabilir.

Örneğin Restricted document external user'a gönderildiğinde block veya warning uygulanabilir.

### Microsoft Purview ve Data Security Yaklaşımı

Microsoft ekosisteminde data classification, information protection, DLP, audit ve governance gibi kontroller Microsoft Purview gibi çözümler üzerinden merkezi şekilde ele alınabilir.

Ancak teknoloji tek başına yeterli değildir.

Öncelikle:

Data Classification Model

Data Owners

Protection Policies

Exception Process

Incident Response

tanımlanmalıdır.

Araç, bu governance modelinin teknik uygulama katmanıdır.

### SaaS Data Security Nedir?

SaaS Data Security, kurumun kullandığı Software-as-a-Service applications içerisinde bulunan data'nın korunmasını ifade eder.

Örneğin kurum:

CRM

HR SaaS

Project Management

File Sharing

Marketing Platform

Support Platform

kullanabilir.

Her SaaS application yeni bir data repository oluşturur.

Bu da Data Security attack surface'ini genişletir.

### SaaS Sprawl Nedir?

SaaS Sprawl, kurum içerisinde çok fazla SaaS application'ın kontrolsüz şekilde kullanılmaya başlamasıdır.

Bir department IT'den habersiz yeni SaaS satın alabilir.

Employees free cloud tools kullanabilir.

Sonuç olarak sensitive data dozens of external services'a dağılabilir.

Bu visibility problemi oluşturur.

### Shadow SaaS Nedir?

Security veya IT team tarafından resmi olarak onaylanmamış SaaS applications Shadow SaaS olarak düşünülebilir.

Örneğin employee corporate document'ı free online converter'a upload edebilir.

Bu application security assessment'ten geçmemiş olabilir.

Data retention policy bilinmeyebilir.

Bu nedenle Shadow SaaS Data Security açısından önemli risktir.

### Shadow IT ile Shadow Data Arasındaki Fark

Shadow IT kurum tarafından yönetilmeyen technology veya application kullanımını ifade eder.

Shadow Data ise security veya governance team'in farkında olmadığı data copies veya repositories'i ifade eder.

Bir Shadow SaaS application Shadow Data oluşturabilir.

Ancak approved cloud platform içerisinde forgotten storage da Shadow Data olabilir.

Bu nedenle iki kavram ilişkilidir fakat aynı değildir.

### SaaS Uygulamalarına OAuth Erişimi

Modern SaaS applications diğer cloud platforms'a OAuth üzerinden bağlanabilir.

Örneğin third-party application:

Read Mail

Read Files

Access Contacts

permissions isteyebilir.

User izin verdiğinde application corporate data'ya sürekli access elde edebilir.

Bu nedenle OAuth application governance Cloud Data Security için kritik hale gelmiştir.

### Riskli OAuth Uygulamaları

Attacker malicious application oluşturup user'dan permissions isteyebilir.

User consent verirse password çalınmadan data access sağlanabilir.

Bu OAuth consent phishing olarak değerlendirilebilir.

Bu nedenle:

Application Permissions

Publisher Trust

Requested Scopes

Consent Activity

izlenmelidir.

### SaaS-to-SaaS Data Movement

Data yalnız user tarafından taşınmaz.

Bir SaaS application diğer SaaS application'a API üzerinden data aktarabilir.

Örneğin CRM → Marketing Platform.

Bu machine-to-machine data flow inventory'de olmalıdır.

Aksi halde kurum verisinin nerelere gittiğini tam olarak bilemez.

### CASB Nedir?

CASB, yani **Cloud Access Security Broker**, kullanıcılar ile cloud services arasındaki security controls'ü destekleyen çözüm kategorisidir.

CASB:

Cloud Application Visibility

DLP

Access Control

Shadow IT Discovery

Threat Protection

gibi use case'lerde kullanılabilir.

CASB özellikle SaaS adoption'ın hızlandığı dönemlerde önemli bir cloud security control haline gelmiştir.

### CASB ile DLP Arasındaki İlişki

DLP sensitive data'yı detect eder ve movement policy uygular.

CASB cloud applications context'i sağlar.

Örneğin:

Confidential Data

Upload to Unsanctioned SaaS

=

Block.

Bu cloud-aware DLP yaklaşımıdır.

### Inline CASB ve API-Based CASB

CASB farklı architectures kullanabilir.

Inline approach user traffic'i real-time inspect edebilir.

API-based approach cloud application içerisindeki stored data'yı scan edebilir.

Bu iki yaklaşım farklı visibility sağlar.

Bazı environments ikisini birlikte kullanabilir.

### Cloud DLP Nedir?

Cloud DLP, sensitive data'nın cloud services içerisinde veya cloud services arasında hareketini kontrol etmeyi amaçlayan Data Loss Prevention yaklaşımıdır.

Örneğin:

Personal Data uploaded to public cloud

Confidential document shared externally

Restricted file downloaded to unmanaged device

gibi events policy kapsamına alınabilir.

### DLP Cloud'da Neden Daha Zordur?

On-premise environments'da data flows daha predictable olabilir.

Cloud'da ise data:

Browser

Mobile App

API

Sync Client

SaaS Integration

AI Application

üzerinden hareket edebilir.

Bu nedenle enforcement points çeşitlenir.

Modern DLP cloud-aware olmalıdır.

### AWS Cloud Data Security

AWS ortamlarında data farklı services içerisinde bulunabilir.

Object Storage

Managed Databases

Data Warehouses

Block Storage

Backups

Logs

Secrets

gibi birçok data repository vardır.

Cloud Data Security programı bu repositories'in inventory'sini oluşturmalıdır.

### Object Storage Güvenliği

Object storage büyük miktarda structured ve unstructured data barındırabilir.

Riskler:

Public Access

Overly Broad IAM

Unencrypted Objects

Old Backups

Unknown Data

Cross-Account Sharing

olabilir.

Data Discovery object storage üzerinde sensitive information taraması yapabilir.

### Cloud Bucket Exposure

“Public bucket” cloud security'nin en bilinen risklerinden biridir.

Ancak modern security yalnız public/private binary kontrolünden ibaret değildir.

Örneğin bucket public olmayabilir ancak:

10.000 internal identities

veya:

multiple external accounts

erişebiliyor olabilir.

Bu da excessive exposure oluşturabilir.

### Azure Data Security

Microsoft Azure environments'da storage, databases, analytics services ve application platforms farklı sensitive data repositories oluşturabilir.

Azure Data Security yalnız resource configuration değil:

Identity

RBAC

Encryption

Network Access

Data Classification

Monitoring

gibi katmanların birlikte değerlendirilmesini gerektirir.

### Azure RBAC ve Veri Erişimi

Azure RBAC cloud resources'a access control sağlar.

Ancak broad roles excessive permissions oluşturabilir.

User yalnız storage listesi görmek için broad administrative role almamalıdır.

Least Privilege uygulanmalıdır.

Cloud permissions düzenli review edilmelidir.

### Google Cloud Data Security

Google Cloud environments'da da object storage, managed databases, analytics platforms ve data processing services sensitive data barındırabilir.

Temel security prensipleri provider'dan bağımsızdır:

Know Your Data.

Know Your Identities.

Control Access.

Encrypt Data.

Monitor Usage.

Reduce Exposure.

### Multi-Cloud Data Security

Birçok kurum yalnız tek cloud provider kullanmaz.

AWS,

Azure,

Google Cloud,

Microsoft 365,

ve farklı SaaS platforms aynı anda kullanılabilir.

Bu durumda Data Security visibility parçalanabilir.

Her platformun kendi dashboard'u vardır.

Ancak kurumun ihtiyacı provider-centric değil **data-centric visibility**'dir.

### Multi-Cloud Data Visibility

Security Team şu soruyu merkezi olarak cevaplamak isteyebilir:

“Bütün cloud environments içerisinde Restricted data nerede?”

Bu sorunun cevabı yalnız provider configuration tools ile zor olabilir.

DSPM bu nedenle multi-cloud environments'da önem kazanmıştır.

### DSPM Nedir ve Cloud Data Security'de Neden Önemlidir?

DSPM, yani **Data Security Posture Management**, cloud ve data environments içerisinde sensitive data'yı keşfetmeye, classify etmeye, access exposure'ı analiz etmeye ve riskli configurations'ı data context ile ilişkilendirmeye odaklanan security yaklaşımıdır.

DSPM şu sorulara cevap vermeye çalışır:

Hangi sensitive data nerede?

Kim erişebiliyor?

Public exposure var mı?

Encryption var mı?

Unused copies bulunuyor mu?

Data başka environments'a kopyalanmış mı?

Bu nedenle DSPM modern Cloud Data Security'nin önemli visibility katmanlarından biridir.

### DSPM ile CSPM Arasındaki Fark

CSPM cloud infrastructure configuration posture'a odaklanır.

DSPM data posture'a odaklanır.

Örneğin CSPM:

Storage Public.

DSPM:

Storage contains 250.000 Restricted Personal Records and is Public.

İkinci finding business risk'i daha açık ifade eder.

Bu nedenle CSPM ve DSPM tamamlayıcıdır.

### CNAPP ile Data Security

CNAPP cloud-native applications'ın infrastructure ve workload security'sine geniş perspektiften yaklaşabilir.

DSPM ise data context sağlar.

Örneğin vulnerable cloud workload'un erişebildiği sensitive data miktarı risk priority'sini değiştirebilir.

Bu nedenle gelecekte workload security ve data security'nin daha fazla birleşmesi beklenebilir.

### Cloud IAM ve Data Security

Cloud environments'da identity çoğu zaman yeni security perimeter olarak görülür.

User veya service account cloud resource'a permission aldığında data access kazanabilir.

Bu nedenle Cloud IAM Data Security'nin temel katmanıdır.

### Excessive Cloud Permissions

Cloud IAM policies zaman içerisinde genişleyebilir.

Developers temporary permissions alabilir.

Project bittikten sonra permissions kaldırılmayabilir.

Bu Permission Creep oluşturur.

CIEM veya access governance processes excessive entitlements'ı azaltmaya yardımcı olabilir.

### CIEM ve Cloud Data Security

CIEM cloud identities'in permissions ve entitlements'ını analiz eder.

DSPM sensitive data'yı analiz eder.

İki yaklaşım birlikte:

#### Which identity can access which sensitive data?

sorusunu cevaplamaya yardımcı olur.

Bu Data Access Governance için güçlü context sağlar.

### Human ve Machine Identity

Cloud data'ya yalnız employees erişmez.

Service Accounts

Managed Identities

API Keys

Applications

Automation Tools

AI Agents

da erişebilir.

Bu nedenle identity inventory human accounts ile sınırlı olmamalıdır.

### Service Account Riski

Service accounts genellikle long-lived permissions taşır.

Bazıları yıllarca kullanılabilir.

Bir service credential compromise edilirse attacker büyük miktarda cloud data'ya erişebilir.

Bu nedenle machine identities Least Privilege altında tutulmalıdır.

### Cloud Secrets Management

API keys, database credentials ve encryption keys source code içerisinde saklanmamalıdır.

Secrets manager veya vault kullanılmalıdır.

Secret rotation automation mümkün olduğunca uygulanmalıdır.

Bu özellikle CI/CD ve cloud-native applications için önemlidir.

### Cloud Encryption

Cloud Data Security'nin önemli katmanlarından biri encryption'dır.

Sensitive data:

At Rest

In Transit

uygun şekilde korunmalıdır.

Ancak encryption tek başına excessive permissions problemini çözmez.

Authorized identity data'yı decrypt edebilir.

Bu nedenle IAM ve encryption birlikte tasarlanmalıdır.

### Customer-Managed Encryption Keys

Bazı high-sensitivity workloads için customer-managed keys kullanılabilir.

Bu kurumun key policy üzerinde daha fazla control sahibi olmasını sağlayabilir.

Ancak key management operational responsibility getirir.

Key loss availability riskine dönüşebilir.

### Cloud KMS

Cloud Key Management Services encryption keys'in centralized management'ını sağlayabilir.

Key access logs security monitoring açısından önemlidir.

Unusual decrypt operations security incident göstergesi olabilir.

### Cloud Backup Security

Cloud backups da sensitive data içerir.

Backup storage:

Encrypted

Immutable

Access-Controlled

Monitored

olmalıdır.

Production environment secure olsa bile weak backup permissions data breach oluşturabilir.

### Snapshot Güvenliği

Cloud snapshots database veya virtual machine data'nın büyük copy'sini içerebilir.

Snapshots yanlışlıkla external account ile paylaşılabilir.

Bu nedenle snapshot permissions ve lifecycle yönetilmelidir.

### Orphaned Snapshots

Resource silinse bile snapshot kalabilir.

Bu forgotten copy Shadow Data haline gelebilir.

Sensitive data retention süresinden daha uzun süre saklanabilir.

Data Discovery bu copies'i tespit etmelidir.

### Shadow Data Nedir?

Shadow Data, security veya governance ekiplerinin yeterli visibility'sine sahip olmadığı data copies, repositories veya datasets'tir.

Örneğin:

Old Database Snapshot

Forgotten Backup

Developer Copy

Temporary Export

Unmanaged SaaS Upload

Abandoned Storage

Shadow Data olabilir.

Cloud environments Shadow Data'nın hızlı büyümesine neden olabilir.

### Dark Data Nedir?

Dark Data, kurumun sakladığı ancak aktif olarak kullanmadığı veya business value'su belirsiz data'yı ifade edebilir.

Dark Data ile Shadow Data farklı kavramlardır.

Dark Data biliniyor ancak kullanılmıyor olabilir.

Shadow Data ise security visibility dışında olabilir.

Her ikisi de unnecessary exposure oluşturabilir.

### ROT Data Nedir?

ROT:

#### Redundant, Obsolete, Trivial

data anlamına gelir.

Yani:

gereksiz kopyalar,

eski data,

iş değeri olmayan data.

Cloud storage ucuz ve kolay olduğu için ROT Data zamanla büyüyebilir.

Bu hem cost hem security riskidir.

### Data Minimization Cloud İçin Neden Önemli?

Korunması en kolay data, gereksiz yere tutulmayan data'dır.

Cloud adoption ile storage capacity kolaylaştığı için kurumlar gereğinden fazla data saklayabilir.

Data Minimization ve Retention policies attack surface'i azaltır.

### Data Retention

Her data sonsuza kadar saklanmamalıdır.

Business, legal ve regulatory requirements doğrultusunda retention periods tanımlanmalıdır.

Retention süresi dolan data secure şekilde silinmelidir.

Bu Data Lifecycle Management'ın parçasıdır.

### Secure Deletion Cloud'da Nasıl Ele Alınır?

Cloud storage abstraction nedeniyle traditional disk wiping yaklaşımı her zaman uygulanabilir değildir.

Bu nedenle provider deletion mechanisms, encryption key destruction ve lifecycle policies kullanılabilir.

Kurum provider'ın deletion modelini anlamalıdır.

### Data Residency Nedir?

Data Residency, verinin hangi ülke veya coğrafi bölgede fiziksel veya mantıksal olarak saklandığıyla ilgilidir.

Cloud architecture tasarlanırken regulatory, contractual ve business requirements dikkate alınabilir.

Ancak Data Residency ile Data Security aynı şey değildir.

Data belirli ülkede bulunabilir ancak yanlış permissions nedeniyle exposed olabilir.

### Data Sovereignty Nedir?

Data Sovereignty, data'nın bulunduğu jurisdiction'ın hukuki kurallarına tabi olabilmesiyle ilişkilidir.

Global cloud architectures için önemli governance konusudur.

Security teams legal ve privacy teams ile birlikte çalışmalıdır.

### Cross-Border Data Transfer

SaaS ve multi-cloud architectures data'nın farklı regions arasında hareket etmesine neden olabilir.

Bu nedenle data flow mapping önemlidir.

Kurum yalnız data'nın nerede saklandığını değil nereye aktarıldığını da bilmelidir.

### Data Lineage Cloud'da Neden Önemlidir?

Data Lineage, data'nın source'dan destination'a nasıl hareket ettiğini gösterir.

Örneğin:

CRM

↓

Data Warehouse

↓

BI Platform

↓

Export

↓

SaaS Analytics

Bu flow bilinmiyorsa sensitive data'nın kontrolü zorlaşır.

### Cloud Data Flow Mapping

Data Flow Mapping ile:

Source

Destination

Data Type

Transfer Method

Owner

Purpose

belirlenebilir.

Bu privacy, security ve architecture ekipleri için ortak visibility sağlar.

### External Sharing Governance

Cloud collaboration'ın en büyük avantajlarından biri kolay sharing'dir.

Ancak bu aynı zamanda data leakage riskidir.

External sharing:

Business Purpose

Recipient Identity

Expiry

Classification

ile yönetilmelidir.

### Guest User Lifecycle

External guest project tamamlandıktan sonra sistemde kalabilir.

Bu orphaned external access oluşturur.

Guest identities periodic review edilmelidir.

Inactive guests kaldırılmalıdır.

### Download Control

Bazı sensitive data use case'lerinde user document'ı görüntüleyebilir ancak download edememelidir.

Bu browser-only veya controlled access models ile sağlanabilir.

Amaç endpoint üzerinde uncontrolled copy oluşmasını azaltmaktır.

### Unmanaged Device Access

User personal device üzerinden corporate cloud data'ya erişebilir.

Bu durumda data endpoint security controls dışında kalabilir.

Policy:

Allow Browser View

Block Download

Require Managed Device

gibi controls uygulayabilir.

### Conditional Access ve Data Security

Conditional Access identity, device, location ve risk context'e göre cloud access'i kontrol edebilir.

Örneğin:

Restricted Data

Unmanaged Device

=

Block Download.

Bu Zero Trust Data Security'nin önemli uygulamalarından biridir.

### Zero Trust Cloud Data Security

Zero Trust yaklaşımı cloud data access'te network location'a güvenmez.

Access decision:

Identity

Device

Application

Data Sensitivity

Risk

Context

üzerinden verilir.

Bu data-centric authorization modelidir.

### Cloud Data Security ve DLP

DLP data movement control sağlar.

Örneğin user Confidential document'ı personal cloud storage'a upload etmeye çalışabilir.

DLP bunu detect ve block edebilir.

Ancak DLP'nin başarılı olması için classification ve business context önemlidir.

### Cloud Data Security ve DAM

Cloud databases için DAM database activity'yi izleyebilir.

DSPM data location ve exposure'ı gösterir.

DLP data movement'ı kontrol eder.

Bu üç katman birlikte farklı stages'i kapsar:

**DSPM → Where is the data?**

**DAM → Who is querying it?**

**DLP → Where is it going?**

Bu modern Data Security Architecture açısından güçlü bir ayrımdır.

### Cloud Data Security ve SIEM

Cloud security events merkezi SIEM'e aktarılabilir.

Örneğin:

Public Sharing

Sensitive File Download

OAuth Consent

KMS Activity

Database Export

Guest Access

gibi events correlate edilebilir.

Bu SOC visibility sağlar.

### Cloud Data Security ve UEBA

User behavior analytics cloud data access patterns'ını analiz edebilir.

Örneğin employee normalde günde 20 documents açıyor.

Bir gece 5.000 documents download ederse anomaly oluşabilir.

Bu insider threat veya compromised account göstergesi olabilir.

### Impossible Travel + Data Download

Identity platform user için impossible travel alert üretebilir.

Aynı anda large SharePoint download gerçekleşiyorsa risk yükselir.

Bu nedenle identity ve data signals birlikte analiz edilmelidir.

### Ransomware ve Cloud Data

Ransomware yalnız local file servers'ı etkilemez.

Compromised cloud account:

files encrypt,

delete,

overwrite

edebilir.

Cloud sync nedeniyle destructive changes hızla yayılabilir.

Versioning ve backup bu nedenle önemlidir.

### Cloud Backup Ransomware'e Karşı Yeterli mi?

Yalnız backup olması yeterli değildir.

Attacker aynı account üzerinden backup'ı silebiliyorsa recovery riske girer.

Backup isolation ve immutable recovery copies önemlidir.

Bu Data Resilience yaklaşımıdır.

### Cloud Data Security ve Insider Threat

Authorized employee large amounts of data download edebilir.

Bu nedenle internal user activity de monitor edilmelidir.

Özellikle:

Bulk Download

External Sharing

Mass Copy

Unusual SaaS Upload

gibi behaviors değerlidir.

### Cloud Data Exfiltration

Cloud Data Exfiltration farklı kanallardan gerçekleşebilir:

Download

External Share

API

OAuth Application

Sync Client

SaaS Integration

AI Prompt

Bu nedenle yalnız network egress monitoring yeterli değildir.

### API-Based Data Exfiltration

Attacker stolen OAuth token ile API üzerinden thousands of files indirebilir.

Traditional browser monitoring bunu görmeyebilir.

Cloud audit logs ve API telemetry önemlidir.

### Token Theft ve Cloud Data

Modern attackers password yerine session token veya OAuth token ele geçirebilir.

MFA kullanılsa bile stolen token active session sağlayabilir.

Bu nedenle token protection ve ITDR önemlidir.

### Cloud Data Security ve ITDR

ITDR compromised identity signals üretir.

DSPM sensitive data context sağlar.

Örneğin:

High-Risk Identity

Access to Restricted Data

=

Critical Priority.

Bu Identity Security ile Data Security'nin birleşimidir.

### AI ve Cloud Data Security

Generative AI adoption cloud data security'nin sınırlarını yeniden değiştirmektedir.

Employees cloud documents'ı AI tools'a yükleyebilir.

AI applications SaaS data'ya API ile bağlanabilir.

AI Agents corporate cloud environments üzerinde autonomous actions gerçekleştirebilir.

Bu nedenle **AI Data Security** artık Cloud Data Security'nin önemli parçasıdır.

### Shadow AI Nedir?

Shadow AI, kurum tarafından onaylanmamış AI tools'un employees tarafından kullanılmasıdır.

Employee confidential document'ı public AI service'e upload edebilir.

Bu data governance problemi oluşturabilir.

Shadow AI, Shadow SaaS'ın yeni ve daha hızlı büyüyen bir alt kategorisi olarak değerlendirilebilir.

### AI Prompt Data Leakage

User prompt içerisine:

Customer Data

Source Code

Contract

Financial Information

Personal Data

ekleyebilir.

Bu information external AI platform'a aktarılabilir.

Bu nedenle DLP AI traffic için de önem kazanmaktadır.

### AI SaaS Governance

AI applications için security assessment yapılmalıdır.

Sorular:

Data retained mı?

Training için kullanılıyor mu?

Data location nedir?

Access controls var mı?

Enterprise isolation mevcut mu?

Audit logs sağlanıyor mu?

Bu değerlendirme procurement ve security süreçlerine eklenebilir.

### Microsoft 365 Copilot ve Kurumsal Veri Yetkileri

Enterprise AI assistants kurum içerisindeki existing permissions üzerinden documents retrieve edebilir.

Bu durumda eski SharePoint permission problemleri AI tarafından daha görünür hale gelebilir.

AI yanlış permission oluşturmayabilir ancak mevcut excessive permissions'ın etkisini büyütebilir.

Bu nedenle AI deployment öncesi Data Access Governance önemlidir.

### AI Neden Permission Creep Problemini Büyütebilir?

Employee geçmişte erişebildiği binlerce document'ı tek tek bulamayabilir.

AI search veya assistant bu documents'ı saniyeler içinde surface edebilir.

Bu nedenle yıllardır görünmeyen excessive permissions artık daha yüksek business risk oluşturabilir.

AI readiness aslında Data Governance readiness gerektirir.

### RAG ve Cloud Data Security

RAG systems SharePoint, OneDrive, cloud storage ve databases'ten content retrieve edebilir.

Retrieval sırasında document permissions korunmalıdır.

User access'i olmayan data AI answer'a dahil edilmemelidir.

Bu **Permission-Aware RAG** yaklaşımıdır.

### Vector Database Cloud Security

RAG pipelines cloud vector databases oluşturabilir.

Bu databases sensitive content'in embeddings ve metadata'sını tutabilir.

Encryption, access control, tenant isolation ve monitoring uygulanmalıdır.

Vector store “AI component” olduğu için Data Security scope dışında bırakılmamalıdır.

### AI Agent Cloud Permissions

AI Agent:

Read Files

Send Email

Create Documents

Query Database

Call APIs

gibi permissions alabilir.

Broad permissions verilirse agent büyük data exposure oluşturabilir.

Bu nedenle AI Agent Least Privilege uygulanmalıdır.

### AI Agent + OAuth

AI Agents SaaS platforms'a OAuth üzerinden bağlanabilir.

Agent'ın scopes'u task-specific olmalıdır.

Örneğin reporting agent yalnız read permission'a ihtiyaç duyuyorsa write/delete scopes verilmemelidir.

### AI Agent Data Exfiltration

Prompt Injection veya malicious instruction agent'ın sensitive cloud data'yı external destination'a göndermesine neden olabilir.

Bu nedenle:

Tool Permissions

DLP

Destination Controls

Human Approval

Monitoring

birlikte kullanılmalıdır.

### Human-in-the-Loop

High-risk AI actions için human approval gerekebilir.

Örneğin:

Share Restricted Document Externally

Export Customer Database

Send Confidential Attachment

gibi actions autonomous yapılmamalıdır.

Bu Agentic Data Security için önemli guardrail'dir.

### Cloud Data Security Architecture Nasıl Kurulur?

Modern architecture tek bir ürün üzerinden kurulmaz.

Örnek data security flow:

#### Cloud & SaaS Data Sources

↓

#### Data Discovery

↓

#### Data Classification

↓

#### Identity & Access Analysis

↓

#### DSPM / Exposure Analysis

↓

#### Encryption

↓

#### DLP / Sharing Controls

↓

#### DAM / Activity Monitoring

↓

#### SIEM / UEBA / SOC

↓

#### Incident Response

↓

#### Retention & Secure Deletion

Bu model data lifecycle boyunca protection sağlar.

### Data Discovery İlk Adım Olmalı mı?

Çoğu kurum için evet.

Bilmediğiniz data'yı korumak zordur.

Öncelikle sensitive data repositories bulunmalıdır.

Ardından classification ve access exposure değerlendirilmelidir.

Bu nedenle Data Discovery Cloud Data Security'nin foundation layer'ıdır.

### Cloud Data Security Projesi Nasıl Başlatılır?

İlk aşamada cloud ve SaaS inventory oluşturulmalıdır.

Hangi cloud providers kullanılıyor?

Hangi SaaS applications mevcut?

Hangi repositories sensitive data içeriyor?

Hangi external sharing aktif?

Hangi identities erişebiliyor?

Hangi data encrypted?

Hangi public exposure mevcut?

Bu baseline oluşturulduktan sonra risk-based remediation yapılabilir.

### Crown Jewel Data'dan Başlamak

Bütün cloud data'yı aynı anda düzeltmeye çalışmak yerine critical data prioritize edilebilir.

Örneğin:

Customer Data

Financial Data

HR Data

Source Code

Credentials

Contracts

öncelikli olabilir.

Bu approach hızlı risk reduction sağlar.

### Cloud Data Risk Scoring

Risk yalnız vulnerability üzerinden hesaplanmamalıdır.

Örnek model:

#### Data Sensitivity

#### Access Exposure

#### Configuration Risk

#### Identity Risk

#### Business Criticality

=

#### Data Risk

Bu Data-Centric Risk Management yaklaşımıdır.

### Sensitive Data + Public Exposure

Restricted Data public storage üzerinde bulunuyorsa critical risk olabilir.

Public marketing images ise aynı severity'yi taşımayabilir.

Bu nedenle data context prioritization'ı değiştirir.

### Sensitive Data + Excessive Internal Access

Data public olmayabilir.

Ancak 20.000 employee erişebiliyorsa risk devam eder.

Bu nedenle internal exposure da ölçülmelidir.

### Sensitive Data + Dormant Repository

10 yıldır kullanılmayan old backup sensitive data içeriyor olabilir.

Business value düşük ancak breach impact yüksek olabilir.

Bu data delete candidate olabilir.

Bu Data Minimization'ın güvenlik faydasıdır.

### Cloud Data Security KPI'ları

Programın başarısı ölçülmelidir.

Örnek KPI'lar:

Sensitive Data Discovered

Classified Data Coverage

Public Sensitive Repositories

External Sharing Count

Anonymous Links

Excessive Access Count

Dormant Guest Users

Shadow SaaS Applications

Shadow Data Repositories

Unencrypted Sensitive Data

Data Without Owner

Sensitive Data DLP Incidents

Bulk Downloads

OAuth High-Risk Applications

Cloud Data Exposure Remediation Time

ROT Data Volume

AI Tool Data Upload Events

AI Agents with Broad Permissions

gibi metrics kullanılabilir.

### Public Sensitive Data KPI

Toplam public resources sayısı tek başına yeterli değildir.

Asıl önemli metric:

#### Public Resources Containing Sensitive Data

olabilir.

Bu risk-based measurement sağlar.

### External Sharing KPI

Kaç document external share edilmiş?

Bunların kaçı Confidential?

Kaçında expiry yok?

Bu daha meaningful governance sağlar.

### Shadow Data KPI

Security inventory dışında bulunan sensitive repositories'in sayısı ölçülebilir.

Bu visibility maturity göstergesidir.

Shadow Data azaldıkça governance artar.

### Cloud Data Security'de En Sık Yapılan Hatalar

En yaygın hata cloud provider'ın data security'yi tamamen yönettiğini düşünmektir. Shared Responsibility Model nedeniyle customer configuration, identity ve data governance sorumluluğu devam eder.

İkinci hata yalnız cloud infrastructure'a odaklanıp SaaS applications'ı görmezden gelmektir.

Üçüncü hata public exposure kontrol edip excessive internal permissions'ı göz ardı etmektir.

Dördüncü hata DLP'yi classification olmadan uygulamaktır.

Beşinci hata old backups, snapshots ve forgotten data copies'i inventory dışında bırakmaktır.

Altıncı hata OAuth applications ve SaaS integrations'ı identity governance kapsamına almamaktır.

Yedinci hata external guest access'i project bittikten sonra kaldırmamaktır.

Sekizinci hata AI tools'u Data Security programından ayrı değerlendirmektir.

Dokuzuncu hata RAG ve AI Agents'ın existing cloud permissions üzerinden sensitive data'ya erişebileceğini gözden kaçırmaktır.

Onuncu hata yalnız configuration riskine bakıp data sensitivity'yi risk scoring'e dahil etmemektir.

### Cloud Data Security Kontrol Listesi

- Cloud ve SaaS inventory mevcut mu?
- Microsoft 365 Data Security kapsamda mı?
- SharePoint permissions review ediliyor mu?
- OneDrive external sharing izleniyor mu?
- Teams data sharing kontrol ediliyor mu?
- Sensitive data discovery yapılıyor mu?
- Data Classification uygulanıyor mu?
- Public cloud storage detect ediliyor mu?
- Public storage içerisindeki data sensitivity analiz ediliyor mu?
- Anonymous sharing links izleniyor mu?
- External sharing expiry uygulanıyor mu?
- Guest users periodic review ediliyor mu?
- Shadow SaaS tespit ediliyor mu?
- OAuth applications inventory'de mi?
- OAuth scopes review ediliyor mu?
- SaaS-to-SaaS integrations görünür mü?
- CASB kullanılıyor veya değerlendiriliyor mu?
- Cloud DLP uygulanıyor mu?
- DSPM kullanılıyor veya değerlendiriliyor mu?
- CSPM ile data context ilişkilendiriliyor mu?
- Cloud IAM Least Privilege altında mı?
- Excessive permissions tespit ediliyor mu?
- CIEM capabilities değerlendiriliyor mu?
- Service accounts inventory'de mi?
- Machine identities izleniyor mu?
- Secrets centralized vault içerisinde mi?
- Cloud storage encrypted mı?
- Customer-managed keys gerekli workloads'da değerlendiriliyor mu?
- Cloud KMS logs izleniyor mu?
- Cloud backups encrypted mı?
- Immutable backups mevcut mu?
- Snapshots governance altında mı?
- Orphaned snapshots detect ediliyor mu?
- Database clones izleniyor mu?
- Shadow Data discovery yapılıyor mu?
- Dark Data analiz ediliyor mu?
- ROT Data temizleniyor mu?
- Data Retention uygulanıyor mu?
- Secure Deletion süreci var mı?
- Data Residency requirements belirlenmiş mi?
- Cross-Border Data Flows inventory'de mi?
- Data Lineage görünür mü?
- Unmanaged Device Access kontrol ediliyor mu?
- Conditional Access uygulanıyor mu?
- Bulk cloud downloads detect ediliyor mu?
- Cloud audit logs SIEM'e aktarılıyor mu?
- UEBA data access behavior'ını analiz ediyor mu?
- Token theft use case'leri izleniyor mu?
- Shadow AI tespit ediliyor mu?
- AI platformlarına sensitive data upload kontrol ediliyor mu?
- RAG permission-aware mı?
- Vector databases security kapsamına alınmış mı?
- AI Agents unique identity kullanıyor mu?
- AI Agent OAuth scopes Least Privilege mi?
- High-risk AI actions human approval gerektiriyor mu?
- Cloud Data Security KPI'ları takip ediliyor mu?

### Cloud Data Security Olgunluk Modeli

**Seviye 1 – Cloud Visibility Eksikliği:** Kurum hangi SaaS applications ve cloud repositories içerisinde sensitive data bulunduğunu tam olarak bilmez. External sharing ve Shadow Data görünürlüğü sınırlıdır.

**Seviye 2 – Temel Cloud Protection:** Encryption, MFA, basic DLP ve cloud configuration controls uygulanır. Public resources ve major sharing risks izlenmeye başlanır.

**Seviye 3 – Data-Aware Cloud Security:** Data Discovery, Classification, CASB, DSPM ve access governance entegre edilir. Sensitive data exposure risk bazlı yönetilir.

**Seviye 4 – Multi-Cloud Data Security:** Microsoft 365, SaaS, AWS, Azure ve Google Cloud gibi farklı environments merkezi data-centric risk modelinde değerlendirilir. Identity, data sensitivity ve behavior birlikte analiz edilir.

**Seviye 5 – Adaptive Cloud & AI Data Security:** Human, machine ve AI Agent access'leri sürekli doğrulanır. DLP, DSPM, DAM, IAM, CIEM, SIEM ve AI security controls ortak policy framework içerisinde çalışır.

Bu dönüşüm:

#### Cloud Visibility

↓

#### Cloud Protection

↓

#### Data-Aware Security

↓

#### Multi-Cloud Data Security

↓

#### Adaptive Cloud & AI Data Security

şeklinde ilerler.

### Sık Sorulan Sorular

#### Cloud Data Security nedir?

Cloud Data Security, cloud ve SaaS ortamlarında saklanan, işlenen ve paylaşılan verilerin yetkisiz erişim, veri sızıntısı, yanlış yapılandırma ve veri kaybına karşı korunmasını sağlayan güvenlik yaklaşımıdır.

#### Cloud Security ile Cloud Data Security arasındaki fark nedir?

Cloud Security infrastructure, workloads, network ve identity gibi geniş güvenlik alanlarını kapsar. Cloud Data Security özellikle cloud içerisindeki verinin sensitivity, access, exposure ve movement risklerine odaklanır.

#### SaaS Data Security nedir?

SaaS Data Security, Microsoft 365, CRM, HR, collaboration ve diğer SaaS applications içerisinde bulunan corporate data'nın korunmasıdır.

#### Microsoft 365 veri güvenliği nasıl sağlanır?

Data Classification, DLP, identity security, SharePoint ve OneDrive permission governance, external sharing controls, audit, Conditional Access ve monitoring birlikte uygulanmalıdır.

#### SharePoint veri güvenliğinde en önemli risk nedir?

Excessive permissions, anonymous sharing links, external users ve Permission Creep önemli riskler arasındadır.

#### OneDrive veri sızıntısı nasıl önlenir?

Classification, DLP, external sharing controls, managed device policies, access reviews ve activity monitoring birlikte kullanılabilir.

#### CASB nedir?

Cloud Access Security Broker, cloud applications üzerinde visibility, access control, DLP ve Shadow IT/SaaS monitoring sağlayabilen security solution category'sidir.

#### Cloud DLP nedir?

Cloud DLP, sensitive data'nın cloud applications içerisinde veya cloud services arasında kontrolsüz paylaşılmasını ve taşınmasını detect veya prevent etmeye odaklanır.

#### DSPM nedir?

Data Security Posture Management, sensitive data'nın nerede bulunduğunu, kimlerin erişebildiğini ve hangi exposure risklerine sahip olduğunu analiz eden data-centric security yaklaşımıdır.

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

CSPM cloud configuration posture'a, DSPM ise data sensitivity ve data exposure posture'a odaklanır. Birlikte kullanıldıklarında risk daha doğru prioritize edilebilir.

#### Shadow Data nedir?

Shadow Data, security veya governance ekiplerinin yeterli visibility'sine sahip olmadığı data copies, backups, snapshots, repositories veya datasets'tir.

#### Shadow SaaS nedir?

Kurum tarafından resmi olarak yönetilmeyen veya onaylanmayan SaaS applications'ın employees tarafından kullanılmasıdır.

#### Shadow AI nedir?

Kurum tarafından onaylanmamış AI applications'ın corporate data ile kullanılmasıdır ve sensitive data leakage riski oluşturabilir.

#### Cloud IAM veri güvenliği için neden önemlidir?

Cloud IAM hangi human veya machine identity'nin hangi cloud resource ve data'ya erişebileceğini belirler. Excessive permissions data exposure riskini artırır.

#### Cloud encryption yeterli midir?

Hayır. Encryption storage veya transmission compromise'e karşı koruma sağlar ancak authorized veya compromised identity decrypted data'ya erişebilir. IAM, DLP ve monitoring de gereklidir.

#### AI sistemleri Cloud Data Security'yi nasıl etkiler?

AI applications, RAG systems ve AI Agents cloud data'ya çok daha hızlı erişebilir ve işleyebilir. Bu nedenle Permission-Aware Retrieval, Agent Least Privilege, DLP ve AI activity monitoring önem kazanır.

#### Microsoft 365 Copilot gibi kurumsal AI sistemleri için veri erişimlerinin gözden geçirilmesi neden önemlidir?

Kurumsal AI assistants mevcut user permissions üzerinden büyük miktarda içeriği hızlı biçimde keşfedebilir. Yıllar içinde oluşmuş excessive SharePoint veya cloud permissions bu nedenle daha görünür ve daha yüksek etkili hale gelebilir.

### Sonuç: Cloud Güvenliğini Değil, Cloud İçerisindeki Veriyi Merkeze Almak Gerekir

Cloud Data Security'nin temel problemi cloud'un güvenli olup olmaması değildir.

Modern cloud providers çok güçlü infrastructure security controls sağlayabilir.

Asıl problem kurumun kendi data'sını nasıl yönettiğidir.

Sensitive data nerede?

Kim erişebiliyor?

Kimlerle paylaşılıyor?

Hangi copies mevcut?

Hangi SaaS applications data'yı kullanıyor?

Hangi OAuth applications erişebiliyor?

Hangi service accounts data'yı okuyabiliyor?

Hangi AI Agents aynı data'ya erişebiliyor?

Bu sorular cevaplanmadan gerçek Cloud Data Security visibility'sinden söz etmek zordur.

Bu nedenle modern cloud security yaklaşımı:

#### Resource-Centric Security

modelinden:

#### Data-Centric Security

modeline doğru ilerlemektedir.

Artık yalnız:

“Bu bucket public mı?”

sorusunu sormak yeterli değildir.

Şunu sormak gerekir:

**“Bu bucket public ve içerisinde ne var?”**

Yalnız:

“Bu user'ın SharePoint access'i var mı?”

değil:

**“Bu user hangi Restricted documents'a erişebiliyor?”**

Yalnız:

“Bu AI Agent'a OAuth permission verilmiş mi?”

değil:

**“Bu permission üzerinden hangi sensitive data'ya ulaşabilir ve bu data ile hangi actions'ı gerçekleştirebilir?”**

soruları sorulmalıdır.

Bu nedenle modern Cloud Data Security Architecture:

**Data Discovery + Classification + DSPM + IAM + CIEM + Encryption + DLP + DAM + CASB + SIEM + Zero Trust**

yaklaşımlarının birlikte çalışmasını gerektirir.

Özellikle Generative AI ve Agentic AI adoption ile bu ihtiyaç daha da büyümektedir.

Çünkü cloud data artık yalnız users tarafından açılan files veya applications tarafından yapılan API calls üzerinden kullanılmamaktadır.

AI systems aynı anda binlerce document içerisinde search yapabilir, databases'e query gönderebilir, SaaS platforms arasında data taşıyabilir ve autonomous actions gerçekleştirebilir.

Bu nedenle geleceğin Cloud Data Security modeli yalnız:

#### Human Access

değil:

**Human + Machine + AI Agent Access**

modelini yönetmek zorundadır.

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

**Modern Cloud Data Security; Microsoft 365, SaaS, AWS, Azure veya Google Cloud üzerinde bulunan veriyi yalnız şifrelemek değil, hassas verinin nerede olduğunu, kimlerin erişebildiğini, kimlerle paylaşıldığını, hangi uygulama ve AI Agent'ların kullandığını, nereye taşındığını ve yaşam döngüsünün her aşamasında hangi risklere maruz kaldığını sürekli görünür ve kontrol edilebilir hale getirmektir.**