# Veri Erişim Güvenliği: Least Privilege, RBAC, ABAC ve Hassas Veriye Yetkisiz Erişimin Önlenmesi

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/veri-guvenligi-siniflandirma/veri-erisim-guvenligi-least-privilege-rbac-abac

![Veri Erişim Güvenliği: Least Privilege, RBAC, ABAC ve Hassas Veriye Yetkisiz Erişimin Önlenmesi](/images/bilgi-merkezi/covers/cover-veriguv-05.webp)

Veri erişim güvenliği, kurum içerisindeki hassas ve kritik verilere yalnız doğru kullanıcıların, doğru yetki seviyesinde, doğru zamanda ve iş ihtiyacı kapsamında erişebilmesini sağlayan güvenlik yaklaşımıdır. İngilizcede **Data Access Security** veya daha geniş kapsamda **Data Access Governance** olarak kullanılan bu yaklaşım, modern Data Security Architecture'ın en kritik katmanlarından biridir.

Bir kurum verilerini keşfetmiş, sınıflandırmış ve DLP politikalarıyla kurum dışına çıkmasını kontrol altına almış olabilir. Ancak hassas veriye kurum içerisinde gereğinden fazla kişi erişebiliyorsa önemli bir güvenlik riski devam ediyor demektir.

Bu nedenle veri güvenliğinde temel soru yalnızca:

**“Veri dışarı çıkıyor mu?”**

değildir.

Aynı zamanda:

**“Bu veriye kim erişebiliyor ve gerçekten erişmesi gerekiyor mu?”**

sorusu da cevaplanmalıdır.

Modern veri erişim güvenliği; **Least Privilege, Need-to-Know, RBAC, ABAC, Identity Governance, Access Review, Permission Management, Zero Trust ve Continuous Authorization** gibi prensiplerin birlikte uygulanmasını gerektirir.

### Veri Erişim Güvenliği Nedir?

Veri erişim güvenliği, kullanıcıların, uygulamaların, service account'ların ve AI Agent'ların kurumsal verilere hangi şartlar altında erişebileceğini belirleyen güvenlik mekanizmalarının bütünüdür.

Amaç yalnız login işlemini kontrol etmek değildir.

Authentication:

**“Sen kimsin?”**

sorusunu cevaplar.

Authorization ise:

**“Neye erişebilirsin?”**

sorusunu cevaplar.

Data Access Security bu ikinci soruya odaklanır.

Bir kullanıcı sisteme başarıyla giriş yapmış olabilir ancak bu durum bütün verilere erişebileceği anlamına gelmez.

### Authentication ile Authorization Arasındaki Fark

Authentication, kullanıcının kimliğini doğrular.

Örneğin:

Password

MFA

Passkey

Certificate

kullanılabilir.

Authorization ise doğrulanmış kullanıcının hangi resource ve data'ya erişebileceğini belirler.

Örneğin employee:

CRM'e login olabilir.

Ancak yalnız kendisine atanmış customer records'ı görebilir.

Bu authorization'dır.

Modern Data Security için authentication ve authorization birlikte kullanılmalıdır.

### Least Privilege Nedir?

Least Privilege, yani en az ayrıcalık prensibi, kullanıcı veya sistemlere yalnız görevlerini yerine getirmek için gerekli minimum yetkinin verilmesini ifade eder.

Bu prensip yalnız administrator accounts için geçerli değildir.

Data access için de uygulanmalıdır.

Örneğin HR employee:

employee records

görebilir.

Ancak source code repository'ye erişmesine gerek olmayabilir.

Developer:

source code

görebilir.

Ancak payroll database'e erişmesi gerekmeyebilir.

Bu görev bazlı yetkilendirme yaklaşımıdır.

### Least Privilege Neden Veri Güvenliğinin Temelidir?

Bir attacker employee account'u ele geçirirse yalnız o account'un sahip olduğu permissions kadar hareket edebilir.

Eğer account gereğinden fazla data access'e sahipse attacker da aynı access'i elde eder.

Bu nedenle excessive permissions breach impact'i büyütür.

Least Privilege attack surface'i azaltır.

Örneğin bir kullanıcı yalnız 500 customer record'a ihtiyaç duyuyorsa 5 milyon customer record'a erişmesi gereksiz risk oluşturur.

### Need-to-Know Nedir?

Need-to-Know, kullanıcının yalnız işini yapması için gerçekten gerekli bilgileri görebilmesi prensibidir.

Bu Least Privilege'e benzer ancak daha data-centric bir yaklaşımdır.

Örneğin Finance Department bütün financial documents'a erişmek zorunda olmayabilir.

Payroll team salary data'yı görebilir.

Accounting team invoice data'yı görebilir.

Bu separation sensitive data exposure'ı azaltır.

### Least Privilege ile Need-to-Know Arasındaki Fark

Least Privilege daha geniş olarak systems ve permissions için kullanılır.

Need-to-Know ise özellikle information access'e odaklanır.

Örneğin user database'e read permission alabilir.

Bu Least Privilege olabilir.

Ancak database içerisindeki bütün tables'ı görebilmesi gerekmez.

Need-to-Know burada daha granular restriction sağlar.

İki prensip birlikte kullanılmalıdır.

### Data Access Governance Nedir?

Data Access Governance, kullanıcıların hangi data'ya eriştiğini, neden eriştiğini, bu access'in kim tarafından onaylandığını ve halen gerekli olup olmadığını yöneten süreçtir.

Bu yaklaşım IAM ve Data Security'nin kesişiminde bulunur.

Amaç access lifecycle'ı yönetmektir.

Örneğin employee Finance Department'a katılır.

Relevant permissions verilir.

Bir yıl sonra Sales Department'a geçer.

Eski Finance permissions kaldırılmalıdır.

Aksi halde Permission Creep oluşur.

### Permission Creep Nedir?

Permission Creep, kullanıcının zaman içerisinde farklı rollerden yetkiler biriktirmesi durumudur.

Örneğin employee:

önce HR'da çalışır.

Sonra Finance'a geçer.

Daha sonra Operations'a geçer.

Eski permissions kaldırılmazsa üç department'ın da data'sına erişebilir.

Bu security riskidir.

Permission Creep özellikle uzun süre çalışan employees için yaygındır.

### Excessive Permissions Nedir?

Excessive Permissions, kullanıcının business need'in üzerinde permissions'a sahip olmasıdır.

Örneğin normal employee:

Entire Customer Database

görebiliyor olabilir.

Ancak yalnız assigned accounts'a erişmesi gerekiyordur.

Bu unnecessary exposure oluşturur.

Attackers compromised account üzerinden bu permissions'ı kullanabilir.

### Overprivileged User Nedir?

Overprivileged User, ihtiyaç duyduğundan daha fazla yetkiye sahip kullanıcıdır.

Bu administrator olmak zorunda değildir.

Standard business user da overprivileged olabilir.

Örneğin:

Company-wide file share

üzerinde read access

gereksiz olabilir.

Bu nedenle Data Access Governance yalnız privileged accounts ile sınırlı tutulmamalıdır.

### RBAC Nedir?

RBAC, yani **Role-Based Access Control**, erişim yetkilerinin kullanıcı yerine role atanmasını sağlayan access control modelidir.

Örneğin roles:

Finance Analyst

HR Specialist

Sales Manager

Database Administrator

olabilir.

Permissions roles'a atanır.

Users uygun role eklenir.

Bu access management'ı basitleştirir.

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

Örneğin:

Finance Analyst Role

şu permissions'a sahip olabilir:

Read Financial Reports

View Invoices

Access Finance SharePoint

Employee bu role'a atandığında permissions otomatik kazanır.

Role'dan çıkarıldığında permissions kaybolur.

Bu doğrudan individual permission vermeye göre daha yönetilebilir olabilir.

### RBAC Avantajları Nelerdir?

RBAC access management'ı standardize eder.

Onboarding kolaylaşır.

Employee role'a atanır.

Gerekli permissions hazırdır.

Offboarding veya role change sırasında permissions merkezi olarak kaldırılabilir.

Bu scalability sağlar.

### RBAC'in Zorlukları

RBAC environments zaman içerisinde çok fazla role üretebilir.

Bu **Role Explosion** olarak adlandırılabilir.

Örneğin:

Finance Analyst Turkey

Finance Analyst Europe

Finance Analyst Senior

Finance Analyst Remote

gibi yüzlerce role oluşabilir.

Bu governance complexity yaratır.

Bu nedenle daha dynamic environments'da ABAC kullanılabilir.

### ABAC Nedir?

ABAC, yani **Attribute-Based Access Control**, access decision'ı kullanıcı, resource, device ve context attributes üzerinden verir.

Örneğin:

User Department = Finance

Data Classification = Confidential

Device = Managed

Location = Turkey

ise access allowed olabilir.

Bu daha dynamic ve granular bir authorization modelidir.

### RBAC ile ABAC Arasındaki Fark

RBAC:

**Role üzerinden karar verir.**

ABAC:

**Attributes üzerinden karar verir.**

Örneğin RBAC:

Finance Role → Finance Data.

ABAC ise:

Department = Finance

AND

Employment Status = Active

AND

Device = Managed

AND

Data Classification = Confidential

ise Allow.

Bu daha context-aware security sağlar.

### Hangi Model Daha İyidir: RBAC mi ABAC mi?

Tek bir doğru model yoktur.

RBAC basit ve predictable environments için güçlüdür.

ABAC ise dynamic, cloud ve Zero Trust environments için daha granular olabilir.

Birçok kurum hybrid model kullanabilir.

Örneğin:

RBAC temel access'i belirler.

ABAC runtime context'e göre final decision verir.

Bu modern access control architecture için etkili bir yaklaşımdır.

### Policy-Based Access Control Nedir?

Policy-Based Access Control, access decisions'ın centrally defined policies üzerinden yönetilmesini ifade eder.

Örneğin policy:

“Restricted Data yalnız managed corporate devices üzerinden erişilebilir.”

Bu policy bütün applications'a uygulanabilir.

Bu yaklaşım Zero Trust ile uyumludur.

### Data Classification Access Kararını Nasıl Etkiler?

Data Classification access control için önemli context sağlar.

Örneğin:

Public Data → Broad Access

Internal Data → Employees

Confidential Data → Approved Roles

Restricted Data → Explicit Authorization

modeli oluşturulabilir.

Bu data-centric authorization'dır.

### Classification-Aware Access Control

Classification label access engine'e security signal sağlayabilir.

Örneğin document:

Restricted

olarak işaretlenmişse access için:

MFA

Managed Device

Corporate Network

Explicit Group Membership

gerekebilir.

Bu dynamic data protection sağlar.

### Access Control List – ACL Nedir?

ACL, yani Access Control List, belirli resource üzerinde hangi users veya groups'un hangi permissions'a sahip olduğunu tanımlar.

Örneğin file folder üzerinde:

User A → Read

User B → Modify

Group C → Full Control

tanımlanabilir.

ACL traditional file permission models'in temelidir.

Ancak large environments'da ACL management karmaşıklaşabilir.

### File Permission Security

File shares yıllar boyunca permissions biriktirebilir.

Örneğin folder:

Everyone

Authenticated Users

Domain Users

gibi broad groups'a açık olabilir.

Bu sensitive data exposure riskidir.

Bu nedenle file permission reviews yapılmalıdır.

### Everyone Permission Neden Risklidir?

Sensitive folder üzerinde Everyone Read gibi permission varsa kurum içerisindeki birçok user data'ya erişebilir.

Bu internal attack surface'i artırır.

DLP dışarı çıkışı engellese bile internal confidentiality ihlal edilmiş olabilir.

Bu nedenle Data Access Security DLP'den bağımsız olarak kritik öneme sahiptir.

### Shared Folder Güvenliği

Shared folders çoğu zaman Shadow Data ve excessive permissions problemlerinin kesiştiği alanlardır.

Örneğin HR Excel exports shared folder içerisinde tutulabilir.

Folder geniş user group'a açık olabilir.

Bu nedenle discovery + classification + access analysis birlikte uygulanmalıdır.

### Access Review Nedir?

Access Review, kullanıcıların sahip olduğu permissions'ın belirli aralıklarla gözden geçirilmesidir.

Amaç şu soruyu cevaplamaktır:

**“Bu kullanıcının bu access'e hâlâ ihtiyacı var mı?”**

Manager, Data Owner veya Application Owner access'i approve veya revoke edebilir.

Bu Permission Creep'i azaltır.

### Access Certification Nedir?

Access Certification genellikle periodic review process'i ifade eder.

Örneğin her 3 veya 6 ayda manager:

team members'ın access rights'ını gözden geçirir.

Unused veya unnecessary permissions kaldırılır.

Bu Identity Governance için temel capability'dir.

### Data Owner Access Review'da Neden Önemlidir?

Manager user'ın role'ünü bilir.

Ancak data'nın sensitivity'sini Data Owner daha iyi değerlendirebilir.

Bu nedenle Restricted datasets için Data Owner approval gerekebilir.

Örneğin Finance Director financial data access'i certify edebilir.

### Joiner, Mover, Leaver Süreci

Access Governance user lifecycle ile yakından ilişkilidir.

**Joiner:** Yeni employee gelir.

Appropriate access verilir.

**Mover:** Role veya department değişir.

Permissions güncellenir.

**Leaver:** Employee ayrılır.

Access tamamen kaldırılır.

Bu üç process doğru yönetilmezse excessive access oluşur.

### Leaver Access Neden Kritik?

İşten ayrılan user'ın account'u aktif kalırsa ciddi risk oluşur.

Ancak yalnız account disable etmek yetmez.

API tokens

Shared Accounts

Cloud Permissions

Local Credentials

gibi secondary access'ler de kaldırılmalıdır.

Bu identity offboarding'in parçasıdır.

### Orphaned Account Nedir?

Orphaned Account, artık aktif owner'ı bulunmayan ancak sistemde halen mevcut olan account'tur.

Örneğin eski employee account'u disable edilmemiş olabilir.

Attacker bu accounts'ı kullanabilir.

Data Access Governance orphaned identities'i detect etmelidir.

### Dormant Account Nedir?

Dormant Account uzun süredir kullanılmayan account'tur.

Bu account legitimate olabilir ancak risk taşır.

Özellikle broad data access'e sahipse review edilmelidir.

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

### Shared Account Neden Risklidir?

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

Örneğin:

financeadmin

hesabı 5 kişi tarafından kullanılıyorsa hangi user's data access yaptığı belirlenemeyebilir.

Bu nedenle individual identities tercih edilmelidir.

PAM shared privileged accounts için kontrol sağlayabilir.

### Data Access Governance ile IAM Arasındaki İlişki

IAM identities ve access lifecycle'ı yönetir.

Data Access Governance ise bunu data context ile zenginleştirir.

IAM:

“User hangi group'ta?”

sorusunu cevaplar.

Data Access Governance:

“Bu group hangi sensitive data'ya erişiyor ve bu access gerçekten gerekli mi?”

sorusunu cevaplar.

Bu nedenle modern Identity Security data-aware olmalıdır.

### IGA Nedir ve Veri Erişiminde Nasıl Kullanılır?

IGA, yani Identity Governance and Administration, access request, approval, certification ve lifecycle management süreçlerini yönetir.

Data Access Security için IGA:

Access Request

Approval

Provisioning

Review

Revocation

workflow sağlayabilir.

Özellikle large organizations için önemlidir.

### Access Request Süreci Nasıl Olmalı?

User sensitive data'ya access istediğinde süreç kontrollü olmalıdır.

Örnek workflow:

User Requests Access

↓

Manager Approval

↓

Data Owner Approval

↓

Risk Check

↓

Provision Access

↓

Set Expiry Date

↓

Periodic Review

Bu access governance maturity'sini artırır.

### Permanent Access Her Zaman Gerekli mi?

Hayır.

Bazı access yalnız belirli süre gereklidir.

Örneğin auditor 2 hafta financial data'ya access isteyebilir.

Permanent access yerine time-bound access verilebilir.

Bu Just-in-Time Access yaklaşımına benzer.

### Time-Bound Data Access

Access permission'a expiration date eklemek unnecessary standing access'i azaltır.

Örneğin:

Project User

Restricted Data Access

Expiry: 30 Days.

Project tamamlandığında access otomatik kalkar.

Bu Zero Standing Privilege yaklaşımının data tarafındaki yansımasıdır.

### Just-in-Time Data Access Nedir?

Just-in-Time Access, user'a sürekli access vermek yerine ihtiyaç anında ve belirli süre için access sağlamaktır.

Örneğin administrator production database'e yalnız approved change window sırasında erişebilir.

Bu privileged data exposure'ı azaltır.

### Zero Standing Privilege ve Veri Güvenliği

Zero Standing Privilege, permanent privileged access'in mümkün olduğunca ortadan kaldırılmasını hedefler.

Data Security açısından bu yaklaşım Restricted datasets'e erişimde uygulanabilir.

Access:

on-demand,

approved,

time-limited,

monitored

olabilir.

### Separation of Duties Nedir?

Separation of Duties, kritik işlemlerin tek kişinin kontrolünde olmamasını sağlar.

Örneğin user:

payment request oluşturabilir

ancak:

payment approval yapamaz.

Data access açısından da uygulanabilir.

Örneğin DBA database'i yönetir.

Ancak sensitive data export için ayrı approval gerekebilir.

### Toxic Combination Nedir?

Toxic Combination, ayrı ayrı normal görünen permissions'ın birlikte ciddi risk oluşturmasıdır.

Örneğin user:

Customer Database Read

External Storage Upload

permissions'a sahipse data exfiltration riski artabilir.

DSPM ve IGA bu kombinasyonları analiz edebilir.

### Access Path Nedir?

Access Path, user'ın data'ya hangi groups ve permissions zinciri üzerinden erişebildiğini gösterir.

Örneğin:

User

↓

Group A

↓

Nested Group B

↓

Share Permission

↓

Confidential Folder

Bu complex path manual olarak görülmeyebilir.

Data Access Governance tools bu visibility'yi sağlayabilir.

### Nested Group Riski

Nested groups access management'ı karmaşıklaştırabilir.

User doğrudan sensitive folder permission'a sahip olmayabilir.

Ancak birkaç nested group üzerinden access kazanabilir.

Bu excessive access detection'ı zorlaştırır.

Bu nedenle effective permission analysis yapılmalıdır.

### Effective Permissions Nedir?

Effective Permissions, user'ın bütün direct ve indirect permissions dikkate alındığında gerçekte neye erişebildiğini gösterir.

Security teams yalnız configured permissions'a değil effective access'e bakmalıdır.

Çünkü group inheritance unexpected access oluşturabilir.

### Public Link ile Data Access

Cloud collaboration tools anonymous veya public links oluşturabilir.

Bu durumda normal IAM controls bypass edilebilir.

Sensitive data public link üzerinden erişilebilir hale gelebilir.

Bu nedenle Data Access Governance external links'i de kapsamalıdır.

### External User Access

Guest users ve partners sensitive data'ya erişebilir.

Bu business için gerekli olabilir.

Ancak external access:

Owner

Purpose

Expiry

Classification

ile yönetilmelidir.

Guest access sonsuza kadar açık bırakılmamalıdır.

### B2B Access Governance

Partners, consultants ve suppliers için B2B access gerekebilir.

Bu identities employee olmadıkları için daha sıkı governance gerekebilir.

Örneğin access:

Project-Based

Time-Limited

MFA Protected

Restricted to Specific Data

olabilir.

### Third-Party Data Access

Third-party vendors kurumsal systems'a remote access sağlayabilir.

Bu access sensitive data exposure oluşturabilir.

Vendor account yalnız required systems ve datasets ile sınırlandırılmalıdır.

Vendor contracts security expectations içerebilir.

### Data Access Governance ve Cloud

Cloud platforms access permissions'ı hızlı ve dynamic hale getirmiştir.

IAM policies birkaç satır configuration ile binlerce resource'a access verebilir.

Bu nedenle cloud data access security critical hale gelmiştir.

Misconfigured IAM policy sensitive cloud data'yı geniş erişime açabilir.

### Cloud IAM Permissions

Cloud IAM granular permissions sağlar ancak complexity yüksektir.

Örneğin user:

ReadObject

ListBucket

DecryptKey

permissions'ın birleşimiyle sensitive data'ya erişebilir.

Tek tek bakıldığında permissions normal görünebilir.

Birlikte değerlendirildiğinde high-risk access ortaya çıkabilir.

### CIEM Nedir?

CIEM, yani Cloud Infrastructure Entitlement Management, cloud environments içerisindeki permissions ve entitlements'ı analiz etmeye odaklanır.

Amaç excessive cloud permissions'ı tespit etmektir.

Data Security açısından CIEM şu soruya yardımcı olur:

**“Hangi identity hangi cloud data resource'una gerçekte erişebilir?”**

Bu Least Privilege için önemlidir.

### DSPM ile Data Access Governance

DSPM sensitive data'yı bulur ve exposure riskini analiz eder.

Data Access Governance ise kimlerin bu data'ya erişebildiğini yönetir.

Örneğin DSPM:

Restricted Data in Storage

bulur.

Access analysis:

3,000 Users Have Read Access

gösterir.

Bu critical risk olabilir.

### Data Sensitivity + Access Count

Data risk yalnız classification ile belirlenmemelidir.

Örneğin Restricted data yalnız 2 authorized user tarafından erişilebiliyorsa risk daha kontrollüdür.

Aynı Restricted data 5.000 user'a açıksa risk çok daha yüksektir.

Bu nedenle modern risk scoring:

Data Sensitivity

Access Exposure

birlikte değerlendirilmelidir.

### Data Access Monitoring Nedir?

Authorization yalnız access verme aşamasında kontrol edilmemelidir.

Access sonrası usage da monitor edilmelidir.

Örneğin user authorized olabilir.

Ancak normalde 50 record okurken bir anda 500.000 record indiriyorsa unusual activity olabilir.

Bu nedenle authorization + monitoring birlikte gereklidir.

### Authorized User Her Zaman Güvenli midir?

Hayır.

User account compromise edilmiş olabilir.

Employee malicious olabilir.

Credential stolen olabilir.

Bu nedenle legitimate identity tarafından yapılan access otomatik olarak güvenli kabul edilmemelidir.

Zero Trust yaklaşımı burada önemlidir.

### Zero Trust Data Access Nedir?

Zero Trust Data Access, data access decision'ın yalnız network location veya initial login'e güvenmemesini ifade eder.

Her request context üzerinden değerlendirilmelidir.

Örneğin:

Who is the user?

Which device?

What data?

What classification?

What action?

What risk level?

What location?

Bu bilgiler final access decision'a dahil edilir.

### **“Never Trust, Always Verify” Veri İçin Ne Anlama Gelir?**

Zero Trust:

“Kimseye güvenme.”

anlamına gelmez.

Doğru yaklaşım:

**“Trust'i varsayma; access'i açıkça doğrula.”**

Veri tarafında bu şu anlama gelir:

Internal network'te olmak Restricted data access için yeterli değildir.

User identity ve context doğrulanmalıdır.

### Continuous Authorization Nedir?

Traditional model login sırasında authorization yapar.

User 8 saat boyunca session kullanabilir.

Continuous Authorization ise session boyunca risk signals'ı değerlendirmeye devam eder.

Örneğin:

Device becomes compromised.

Identity risk rises.

User requests Restricted Data.

Access yeniden değerlendirilebilir.

Bu adaptive access modelidir.

### Step-Up Authentication

High-risk data access sırasında additional authentication istenebilir.

Örneğin user Internal data'ya normal session ile erişebilir.

Ancak Restricted document açarken MFA yeniden istenebilir.

Bu Step-Up Authentication'dır.

### Risk-Based Access Control

Risk-Based Access Control, access decision'a risk score ekler.

Örneğin:

User Risk = High

Device Risk = Medium

Data Classification = Restricted

sonucunda access block olabilir.

Bu Adaptive Data Security yaklaşımıdır.

### Device Trust Neden Önemlidir?

Authorized user personal unmanaged laptop üzerinden sensitive data'ya erişiyorsa risk artabilir.

Bu nedenle data access policy:

Managed Device Required

şeklinde olabilir.

Bu endpoint security ile data security'nin kesişimidir.

### Location-Based Access

Geographic veya network location bazı access decisions'da context sağlayabilir.

Örneğin Restricted data yalnız corporate network veya approved countries üzerinden erişilebilir olabilir.

Ancak location tek başına trust signal olarak kullanılmamalıdır.

### Session Risk

User legitimate şekilde login olmuş olabilir.

Ancak session token stolen olabilir.

Bu nedenle session behavior ve device posture monitor edilmelidir.

Identity Threat Detection and Response bu riskleri tespit etmeye yardımcı olabilir.

### ITDR ile Data Access Security

ITDR identity attacks'i detect eder.

Örneğin:

Impossible Travel

Token Theft

Credential Abuse

Privilege Escalation

detect edildiğinde Data Access Policy daha sıkı hale gelebilir.

Bu Identity Security ile Data Security'nin entegrasyonudur.

### PAM ile Data Access Security

Privileged users sensitive data'ya yüksek access sağlayabilir.

PAM bu access'i:

vault,

approval,

session monitoring,

JIT

ile yönetebilir.

Özellikle database, server ve critical applications için önemlidir.

### DAM ile Access Security

DAM database activities'i izler.

Authorization user'a database access vermiş olabilir.

DAM ise user'ın gerçekte hangi queries'i çalıştırdığını izler.

Bu accountability sağlar.

Örneğin:

Authorized DBA

Bulk Customer Export

alert oluşturabilir.

### DLP ile Access Governance

Access Control data'ya kimin erişeceğini belirler.

DLP data'nın erişim sonrası nereye taşınabileceğini kontrol eder.

Örneğin user Confidential data'yı görmeye authorized olabilir.

Ancak personal e-mail'e gönderemez.

Bu nedenle:

#### Access Governance + DLP

birlikte kullanılmalıdır.

### Access Verildi, DLP Neden Hâlâ Gerekli?

Çünkü authorization:

“Bu user data'yı görebilir.”

der.

Ancak:

“Data'yı istediği yere gönderebilir.”

demez.

Bu iki permission farklıdır.

Data Security bu ayrımı korumalıdır.

### Masking ile Access Control

Bazı users data'ya access etmeli ancak full values'i görmemelidir.

Örneğin customer support user:

Credit Card Last 4 Digits

görebilir.

Full number göremez.

Bu Data Masking ile uygulanabilir.

Bu field-level Least Privilege'dir.

### Row-Level Security

Row-Level Security user'ın yalnız belirli records'a erişmesini sağlar.

Örneğin sales employee yalnız kendi region customers'ını görebilir.

Database bütün table'a access vermek yerine row-based filtering uygular.

Bu granular data access security'dir.

### Column-Level Security

Column-Level Security belirli fields'a erişimi kontrol eder.

Örneğin user:

Name

Email

görebilir.

Ancak:

Salary

Identity Number

göremez.

Bu sensitive fields için önemlidir.

### Field-Level Encryption ve Access Control

Sensitive fields encrypted tutulabilir.

Only authorized applications veya users decryption rights'a sahip olabilir.

Bu authorization ile encryption'ın birleşimidir.

### Data Tokenization ve Access Security

Tokenized data normal users tarafından kullanılabilir ancak actual sensitive value yalnız authorized service tarafından çözülebilir.

Bu exposure'ı azaltır.

Özellikle payment ve sensitive identifiers için değerlidir.

### Temporary Access Neden Daha Güvenlidir?

Bir permission ne kadar uzun süre aktifse abuse window o kadar büyüktür.

Bu nedenle sensitive data access mümkün olduğunca temporary olmalıdır.

Access expiry automation security hygiene'i artırır.

### Emergency Access Nedir?

Critical incident sırasında normal access flow yeterli olmayabilir.

Emergency access veya Break Glass mechanism kullanılabilir.

Ancak bu access:

Strong Authentication

Logging

Approval

Post-Review

ile kontrol edilmelidir.

Emergency access permanent bypass olmamalıdır.

### Break Glass Account Riski

Break Glass account geniş permissions taşıyabilir.

Bu account attacker için high-value target'tır.

Bu nedenle credentials secure vault'ta tutulmalı ve usage alert edilmelidir.

### Service Account Data Access

Service accounts applications arasında data access sağlar.

Bu accounts çoğu zaman human users'dan daha fazla permissions taşır.

Ayrıca passwords uzun süre rotate edilmeyebilir.

Bu nedenle Non-Human Identity Security önemlidir.

### Machine Identity ve Data Access

Modern systems data'ya yalnız humans üzerinden erişmez.

Applications

APIs

Services

Bots

AI Agents

machine identities kullanır.

Bu identities de Least Privilege'e tabi olmalıdır.

### API Data Authorization

API endpoint authorized user'a veya application'a yalnız required data'yı döndürmelidir.

Broken Object Level Authorization gibi API security issues unauthorized data access'e neden olabilir.

Bu nedenle application-level authorization Data Access Security'nin önemli parçasıdır.

### Object-Level Authorization

User /customer/123 record'una erişebilir.

Ancak URL'yi /customer/124 yaparak başka customer record'una erişememelidir.

Bu object-level access control'dür.

API ve web applications için kritik öneme sahiptir.

### AI Agent Data Access Güvenliği

AI Agents enterprise systems'a bağlandıkça yeni authorization problemleri ortaya çıkmaktadır.

Agent:

database okuyabilir,

e-mail gönderebilir,

documents düzenleyebilir,

API çağrısı yapabilir.

Bu nedenle agent'a broad permissions verilmemelidir.

### AI Agent Least Privilege

AI Agent yalnız görevini gerçekleştirmek için gerekli permissions'a sahip olmalıdır.

Örneğin reporting agent:

Read Financial Metrics

permission'a ihtiyaç duyabilir.

Ancak:

Delete Records

veya:

Modify Payments

permission'a ihtiyacı olmayabilir.

Bu Agentic Least Privilege'dir.

### AI Agent İçin Ayrı Kimlik Gerekir mi?

Evet, mümkün olduğunda AI Agent unique machine identity kullanmalıdır.

Shared user account kullanılması accountability'yi azaltır.

Unique identity sayesinde:

Which Agent

Accessed Which Data

At What Time

bilgisi izlenebilir.

### RAG Sistemlerinde Data Authorization

RAG systems documents retrieve eder.

Ancak retrieval user permissions'ı dikkate almalıdır.

User HR documents'a erişemiyorsa RAG system da bu documents'ı answer generation sırasında kullanmamalıdır.

Bu Permission-Aware Retrieval'dır.

### Permission-Aware RAG

Permission-Aware RAG modelinde retrieval query şu context'i içerir:

User Identity

Group Membership

Document ACL

Classification

Business Role

Böylece model yalnız authorized content'i retrieve eder.

Bu AI Data Security için kritik öneme sahiptir.

### AI Agent Delegation Riski

User agent'a:

“Bana tüm customer records'ı indir.”

diyebilir.

Agent user'ın permissions'ını inherit edebilir.

Ancak task legitimate olmayabilir.

Bu nedenle delegated access için action-level controls gerekir.

### Human Approval for High-Risk AI Actions

AI Agent Restricted data üzerinde yüksek riskli işlem yapacaksa human approval istenebilir.

Örneğin:

Export Customer Database

Send External Email

Delete Records

işlemleri approval gerektirebilir.

Bu Human-in-the-Loop authorization'dır.

### Data Access Logging

Her critical access loglanmalıdır.

Log içerisinde:

Identity

Timestamp

Resource

Action

Source

Result

bulunabilir.

Bu audit ve incident response açısından önemlidir.

### Access Logs SIEM'e Aktarılmalı mı?

High-value systems için evet.

SIEM access logs'ı identity ve endpoint signals ile correlate edebilir.

Örneğin:

High-Risk Login

Restricted Data Access

Large Download

critical incident gösterebilir.

### UEBA ve Data Access

UEBA normal data access behavior'ını modelleyebilir.

Örneğin employee genellikle 10 documents açar.

Bir gecede 2.000 Confidential documents erişirse anomali olabilir.

Bu insider threat veya account compromise signal'i olabilir.

### Data Access Analytics

Modern access governance yalnız configured permissions'a değil actual usage'a da bakmalıdır.

Örneğin user 2 yıldır bir folder'a erişebiliyor ancak hiç kullanmamış.

Bu access revoke candidate olabilir.

Bu **Usage-Based Access Optimization** yaklaşımıdır.

### Unused Permissions

Kullanılmayan permissions gereksiz attack surface'tir.

Örneğin user'ın cloud storage access'i var ancak 12 aydır kullanmamış.

Access review sırasında kaldırılabilir.

Bu Least Privilege'i sürekli hale getirir.

### Entitlement Right-Sizing

Entitlement Right-Sizing, user permissions'ı actual usage ve business need'e göre küçültmeyi ifade eder.

Bu özellikle cloud environments'da önemlidir.

Overprivileged roles zamanla optimize edilebilir.

### Data Access Governance Projesi Nasıl Başlatılır?

İlk adım mevcut access landscape'i anlamaktır.

Sorular:

Hangi critical datasets var?

Kimler erişiyor?

Access nasıl verildi?

Owner kim?

Ne kadar süredir mevcut?

Gerçekten kullanılıyor mu?

External users var mı?

Bu visibility elde edilmeden access cleanup yapmak riskli olabilir.

### Crown Jewel Data'dan Başlamak

Bütün data access'i aynı anda review etmek yerine high-value datasets önceliklendirilebilir.

Örneğin:

Customer Database

HR Data

Financial Data

Source Code

Privileged Credentials

ilk scope olabilir.

Bu risk-based rollout sağlar.

### Access Baseline

Her critical dataset için expected access model belirlenmelidir.

Örneğin:

HR Payroll Data

Expected Access:

5 HR Users

1 Payroll Application

1 Backup Service

Bu baseline dışındaki access'ler investigation gerektirebilir.

### Access Cleanup

Discovery sonrası unnecessary access revoke edilir.

Ancak mass permission removal business disruption oluşturabilir.

Bu nedenle:

Owner Validation

Usage Analysis

Staged Revocation

uygulanmalıdır.

### Access Review Otomasyonu

Large organizations manual access review'da zorlanabilir.

Automation:

review campaign oluşturabilir,

managers'a tasks gönderebilir,

unused permissions highlight edebilir,

approved actions'ı provision edebilir.

Bu IGA'nın önemli use case'idir.

### Access Governance KPI'ları

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

Örnek KPI'lar:

Excessive Access Count

Unused Permission Count

Orphaned Accounts

Dormant Accounts

Shared Accounts

Access Review Completion Rate

Revoked Access Count

Temporary Access Percentage

Permanent Privileged Access Count

External User Access Count

Unknown Data Owner Count

Time to Revoke Leaver Access

High-Risk Data Access Events

gibi metrics olabilir.

### Access Review Completion Rate

Access Review campaigns zamanında tamamlanmıyorsa governance etkin çalışmıyor olabilir.

Bu nedenle review completion ve overdue items takip edilmelidir.

### Mean Time to Revoke Access

Employee role change veya separation sonrası permissions ne kadar sürede kaldırılıyor?

Bu önemli security KPI'dır.

Leaver account birkaç gün aktif kalıyorsa serious gap oluşabilir.

Automation bu süreyi azaltabilir.

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

En yaygın hata login olan kullanıcıyı otomatik olarak güvenilir kabul etmektir. Authentication access'in yalnız ilk adımıdır.

İkinci hata groups ve roles'ı yıllarca review etmemektir. Bu Permission Creep oluşturur.

Üçüncü hata yalnız administrators'a odaklanmaktır. Standard users da büyük miktarda sensitive data'ya erişebilir.

Dördüncü hata data classification bilgisini authorization'a dahil etmemektir.

Beşinci hata external guests ve third-party identities'i göz ardı etmektir.

Altıncı hata service accounts ve machine identities'i governance kapsamı dışında bırakmaktır.

Yedinci hata access verildikten sonra actual data usage'ı monitor etmemektir.

Sekizinci hata AI Agents'a human user credentials veya broad permissions vermektir.

Dokuzuncu hata RAG systems'da document-level permissions'ı retrieval aşamasında enforce etmemektir.

### Veri Erişim Güvenliği Kontrol Listesi

- Critical data assets belirlenmiş mi?
- Data Owners tanımlı mı?
- Data Classification access policies'e bağlı mı?
- Least Privilege uygulanıyor mu?
- Need-to-Know prensibi kullanılıyor mu?
- RBAC modeli tanımlı mı?
- ABAC gerekli alanlarda kullanılıyor mu?
- ACL'ler düzenli review ediliyor mu?
- Effective permissions analiz ediliyor mu?
- Excessive permissions tespit ediliyor mu?
- Permission Creep kontrol ediliyor mu?
- Access Reviews yapılıyor mu?
- Access Certifications uygulanıyor mu?
- Joiner süreçleri tanımlı mı?
- Mover süreçleri tanımlı mı?
- Leaver access hızlı kaldırılıyor mu?
- Dormant accounts izleniyor mu?
- Orphaned accounts tespit ediliyor mu?
- Shared accounts azaltılıyor mu?
- External guest access review ediliyor mu?
- B2B access expiry date içeriyor mu?
- Third-party access sınırlandırılmış mı?
- Temporary access kullanılıyor mu?
- JIT access uygulanıyor mu?
- Sensitive access approval gerektiriyor mu?
- Separation of Duties tanımlı mı?
- Toxic permission combinations analiz ediliyor mu?
- Cloud entitlements review ediliyor mu?
- CIEM kullanılıyor veya değerlendiriliyor mu?
- DSPM access exposure analiz ediyor mu?
- DAM database access'i izliyor mu?
- DLP access sonrası data movement'ı kontrol ediyor mu?
- High-risk access SIEM'e aktarılıyor mu?
- UEBA abnormal access'i detect ediyor mu?
- Device trust access decision'a dahil mi?
- Step-Up Authentication kullanılıyor mu?
- Continuous Authorization değerlendiriliyor mu?
- Service accounts inventory'de mi?
- Machine identities Least Privilege kullanıyor mu?
- API authorization test ediliyor mu?
- AI Agents unique identity kullanıyor mu?
- AI Agent permissions task-specific mi?
- RAG systems permission-aware mı?
- High-risk AI actions human approval gerektiriyor mu?
- Access Governance KPI'ları izleniyor mu?

### Veri Erişim Güvenliği Olgunluk Modeli

**Seviye 1 – Kontrolsüz Erişim:** Permissions manuel verilir. Broad groups ve shared accounts yaygındır. Periodic review sınırlıdır.

**Seviye 2 – Role-Based Access:** RBAC uygulanır. Joiner-Mover-Leaver süreçleri oluşturulur. Access Reviews başlatılır.

**Seviye 3 – Data-Aware Governance:** Data Classification, IGA, PAM ve Data Owners access decisions'a dahil edilir. Excessive access düzenli tespit edilir.

**Seviye 4 – Risk-Based Access:** Identity risk, device trust, data sensitivity, usage analytics ve cloud entitlements birlikte değerlendirilir. JIT ve temporary access yaygınlaşır.

**Seviye 5 – Adaptive Zero Trust Data Access:** Human, machine ve AI identities için authorization sürekli değerlendirilir. Access decisions real-time risk, data classification ve behavior context'e göre değişir.

Bu dönüşüm:

#### Static Permissions

↓

#### Role-Based Access

↓

#### Governed Access

↓

#### Risk-Based Authorization

↓

#### Adaptive Zero Trust Data Access

şeklinde ilerler.

### Sık Sorulan Sorular

#### Veri erişim güvenliği nedir?

Veri erişim güvenliği, hassas verilere yalnız yetkili kullanıcı, uygulama veya sistemlerin uygun şartlar altında erişmesini sağlayan güvenlik yaklaşımıdır.

#### Least Privilege nedir?

Least Privilege, kullanıcı veya sisteme yalnız görevini yapmak için gerekli minimum yetkinin verilmesi prensibidir.

#### Need-to-Know nedir?

Need-to-Know, kullanıcının yalnız işi için gerçekten ihtiyaç duyduğu bilgileri görebilmesi prensibidir.

#### RBAC nedir?

RBAC, Role-Based Access Control anlamına gelir ve permissions'ın users yerine roles üzerinden yönetilmesini sağlar.

#### ABAC nedir?

ABAC, Attribute-Based Access Control anlamına gelir ve access decisions'ı user, data, device ve context attributes üzerinden verir.

#### RBAC ile ABAC arasındaki fark nedir?

RBAC role bazlı, ABAC attribute ve context bazlı authorization sağlar. Hybrid kullanılabilir.

#### Data Access Governance nedir?

Data Access Governance, kimlerin hangi data'ya neden eriştiğini ve bu access'in halen gerekli olup olmadığını yöneten süreçtir.

#### Permission Creep nedir?

Permission Creep, kullanıcının role değişiklikleri sırasında eski permissions'ın kaldırılmaması sonucu zamanla gereğinden fazla access biriktirmesidir.

#### Excessive Permissions nedir?

Business need'in üzerinde sahip olunan gereksiz access rights'tır.

#### Access Review nedir?

Access Review, kullanıcı permissions'ının belirli periyotlarda kontrol edilerek gerekli olmayan access'in kaldırılması sürecidir.

#### Data Owner kimdir?

Data Owner, verinin business sensitivity, access approval ve governance kararlarından sorumlu iş rolüdür.

#### Zero Trust Data Access nedir?

Data access'in network location'a güvenmek yerine identity, device, data sensitivity ve risk context üzerinden sürekli doğrulandığı authorization yaklaşımıdır.

#### Continuous Authorization nedir?

Kullanıcı login olduktan sonra da session boyunca risk ve context değişimlerine göre access'in yeniden değerlendirilmesidir.

#### CIEM nedir?

CIEM, cloud environments içerisindeki identities ve permissions'ı analiz ederek excessive entitlements'ı azaltmayı amaçlayan Cloud Infrastructure Entitlement Management yaklaşımıdır.

#### DLP ile Access Control arasındaki fark nedir?

Access Control data'ya kimin erişebileceğini belirler. DLP ise erişilen data'nın nereye taşınabileceğini kontrol eder.

#### PAM veri erişim güvenliğinde neden önemlidir?

PAM privileged users'ın kritik systems ve sensitive data'ya erişimini vault, approval, JIT ve session monitoring ile kontrol eder.

#### AI Agent için Least Privilege gerekli midir?

Evet. AI Agent yalnız görevi için gerekli systems, APIs ve data'ya erişebilmelidir. Broad veya shared permissions data leakage ve unauthorized action riskini artırır.

#### Permission-Aware RAG nedir?

Permission-Aware RAG, AI retrieval sürecinde user'ın document permissions'ını dikkate alarak yalnız authorized content'i model context'ine dahil eden yaklaşımdır.

### Sonuç: Hassas Veriye Erişim Yetkisi Sürekli Sorgulanmalıdır

Modern Data Security'de verinin şifrelenmiş olması tek başına yeterli değildir.

DLP'nin kurulu olması da tek başına yeterli değildir.

Eğer gereğinden fazla user aynı sensitive data'ya erişebiliyorsa security exposure devam eder.

Bu nedenle veri güvenliğinin temel prensiplerinden biri:

**“Doğru kimlik, doğru veri, doğru yetki, doğru zaman.”**

olmalıdır.

Kurumsal Data Access Security şu sorulara sürekli cevap vermelidir:

#### Kim erişiyor?

#### Neye erişiyor?

#### Neden erişiyor?

#### Ne zamandır erişiyor?

#### Hâlâ ihtiyacı var mı?

#### Hangi device üzerinden erişiyor?

#### Data ne kadar hassas?

#### Access sonrası ne yapıyor?

Bu soruların cevapları IAM, IGA, PAM, DSPM, DAM, DLP, SIEM ve Zero Trust controls ile birlikte yönetilmelidir.

Geleneksel authorization modeli genellikle static permissions üzerine kuruluydu.

Modern model ise:

**Identity + Role + Attributes + Device + Data Sensitivity + Risk + Behavior**

kombinasyonuna doğru ilerlemektedir.

Bu değişim özellikle cloud, SaaS ve AI environments ile daha önemli hale gelmektedir.

Artık bir kullanıcı dışında:

Service Account

Application

API Client

Automation Bot

AI Agent

da sensitive data'ya erişebilmektedir.

Bu nedenle Data Access Governance yalnız human identity yönetimi olmaktan çıkmaktadır.

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

**Modern veri erişim güvenliği, bir kullanıcının sisteme giriş yapabilmesini değil; insan, uygulama veya AI Agent fark etmeksizin her kimliğin yalnız ihtiyaç duyduğu veriye, yalnız ihtiyaç duyduğu yetkiyle, yalnız ihtiyaç duyduğu süre boyunca ve sürekli doğrulanan bir risk bağlamında erişebilmesini sağlamaktır.**