1. GİRİŞ

Yetkilendirme (authorization) — "bir öznenin hangi kaynaklara hangi işlemleri yapabileceğini belirleme" — modern sistemlerin güvenlik sınırlarında kritik bir katmandır. Kimlik doğrulama (authentication) doğru çalışsa bile, yetkilendirme hataları saldırganların izin verilmemiş kaynaklara erişmesine, veri sızıntılarına veya yetki yükseltmesine (privilege escalation) yol açabilir. Mikroservisler, API ekonomisi, client‑heavy uygulamalar ve dinamik cloud ortamları yetkilendirme yüzeyini daha karmaşık hâle getirmiştir. Bu makale yetkilendirme zafiyetlerini teknik detaylarıyla, örneklerle ve önleme stratejileriyle ele alır.

Neden bugün önemli?

• Mikroservis ve API odaklı mimarilerde mikro‑yetkilendirme hataları (service‑to‑service) sıkça görülen bir risk oluşturuyor.
• Client tarafı yetkilendirme kontrollerine güvenirseniz lateral hareket ve veri sızıntıları kaçınılmaz olur.
• Regülasyonlar veriye erişim kontrolünü zorunlu kıldığından, yanlış yetkilendirme uyumluluk ihlallerine sebep olabilir.

Kimler için önemli?

• Çözüm mimarları ve uygulama mimarları — sistem tasarımında yetkilendirme modellerini seçenler
• Geliştiriciler — API ve UI seviyesinde doğru kontrolleri uygulayanlar
• Güvenlik mühendisleri ve pentester'lar — attack surface ve privilege escalation vektörlerini keşfedenler
• DevOps ve SRE ekipleri — servis politikalarını, network segmentation ve identity yönetimini uygulayanlar

2. KAVRAMSAL TEMELLER

2.1. Yetkilendirme nedir — net tanım

Yetkilendirme, doğrulanmış bir kimliğin hangi nesnelere (veri, API, operasyon) hangi eylemleri (read, write, delete, admin) gerçekleştirebileceğini belirler. Bu kararlar genellikle policy'ler, roller, atribütler veya kombinasyonları üzerinden verilir.

2.2. Temel modeller

• RBAC (Role‑Based Access Control): Kullanıcılar rollere atanır; roller izinleri (permissions) tanımlar. Basit ve yaygın.
• ABAC (Attribute‑Based Access Control): Kararlar subject, resource, action ve environment attributelarına dayanır — daha ince granular kontrol sağlar.
• PBAC / Policy‑Based: Politika motorları (Rego/OPA gibi) ile centralize policy evaluation yapılır.
• Capability‑based: Öznelere doğrudan yetki (capability token) verilir; genellikle dağıtık senaryolarda kullanılır.

2.3. Sık rastlanan terminoloji

• IDOR: Insecure Direct Object Reference — resource identifier'larının doğrulanmadan kullanılması ile yetkisiz erişim.
• Privilege Escalation: Düşük yetkili bir kullanıcının daha yüksek yetkiye erişmesi.
• Horizontal vs Vertical Escalation: Horizontal — aynı seviyedeki başka bir kullanıcıya ait veriye erişim; Vertical — admin gibi daha yüksek role erişim.
• Token Tampering / Forgery: JWT veya benzeri token'ların manipüle edilmesi veya yanlış doğrulanması.

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ, AKIŞ VE ZAFİYETLER

3.1. Yetkilendirme karar noktaları

Yetkilendirme kontrolleri tipik olarak üç seviyede uygulanır:

1. API/Service Gateway: İlk satırda erişim kontrolü ve ölçeklenebilir policy enforcement.
2. Application / Service Layer: İş mantığına yakın kararların verildiği yer — resource ownership ve fine‑grained checks burada olmalıdır.
3. Data Layer: Veri tabanı ve storage seviyesinde row‑level veya column‑level policy'ler (row‑level security, VPD).

3.2. Yaygın zafiyet örnekleri

• IDOR (Insecure Direct Object Reference): Bir endpoint /documents/{id} şeklinde resource id ile çalışıyor ve uygulama id parametresini sahibine ilişkin kontrol etmeden döndürüyor.
• Broken Access Control: Server‑side authorization atlanabiliyor; sadece client‑side gösterimle kısıtlanmış kaynaklar erişilebiliyor.
• Token forgery / alg none JWT: İmzalanmamış token'ların kabul edilmesi ya da algoritma değişikliklerinin kontrol edilmemesi.
• Service‑to‑service excessive privileges: Mikroservislerin aşırı geniş IAM rolleri kullanması ve lateral hareket kolaylığı.
• Unchecked admin endpoints: Yönetim API'lerinin erişim kontrollerinin yetersiz olması veya gizlenmiş (security by obscurity) olması.

3.3. Data flow ve zafiyet senaryosu — örnek

Örnek: Bir proje yönetim uygulamasında /projects/{projectId}/tasks endpoint'i var. Eğer backend şu kontrolleri yapmıyorsa: token'ın userId'sini owner ile eşleştirme, rol kontrolü (project viewer/editor/admin), veya team membership check, bir kullanıcı başka bir projenin görevlerini görebilir veya değiştirebilir. Bu IDOR + broken access control kombinasyonu ciddi veri sızıntılarına yol açar.

4. GERÇEK DÜNYA KULLANIMLARI

4.1. SaaS ve multi‑tenant platformlarda yetkilendirme

Multi‑tenant uygulamalarda tenant isolation kritik önemdedir. Yanlış tenant id kullanımından veya shared resource konfigürasyonlarından kaynaklanan zafiyetler tenant'lar arası veri sızıntısına neden olabilir. Örn: tenantId parametresini client doğrulamasına bırakmak veya tenant‑aware RBAC uygulamamak.

4.2. FinTech ve ödeme sistemleri

Ödeme ve finansal sistemlerde authorization hataları doğrudan fon kaybına yol açabilir. Transaction authorization, double‑spend önleme, idempotency ve reconciliation gibi domain‑specific kontroller ile yetkilendirme entegre edilmelidir.

4.3. Public APIs ve developer portals

Public API'ler rate limiting, scope‑based permissions ve OAuth scopes kullanılarak korunmalı; client credentials flow yanlış kullanımı veya excessive scope atama risklerine karşı dikkat edilmelidir.

4.4. Microservices ve platform engineering

Microservices mimarisinde service account'ların uygun IAM rolü olması, least‑privilege ilkesi ve service mesh ile mutual TLS ve policy enforcement önerilir. Merkezi policy engine (OPA) ile tutarlı authorization uygulanabilir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar (iyi bir authorization tasarımının faydaları)

• İnce‑tane yetkilendirme ile veri sızıntısı ve yetki kötüye kullanım riskleri azalır.
• Policy‑as‑code ve merkezi policy engine ile değişiklikler tutarlı ve izlenebilir olur.
• Row‑level veya attribute‑based controls ile compliance (veri segregasyonu) sağlanır.

Sınırlamalar

• Granular authorization performans maliyeti getirebilir; özellikle yüksek trafikli path'lerde caching stratejileri gerekir.
• Complex policy'ler doğru uygulanmadığında yanlış pozitif/negatif kararlar oluşturabilir; test ve doğrulama şarttır.
• Legacy uygulamaların refactor edilmesi maliyetlidir; geçiş stratejileri planlanmalıdır.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Server‑side enforcement: Tüm authorization kararları sunucu tarafında doğrulanmalı; client‑side kontroller sadece UX içindir.
• Ownership checks: Resource erişiminde owner‑based check'leri asla atlamayın (ör. resource.ownerId == user.id).
• Least privilege: Hem kullanıcı hem de servis hesapları için en az ayrıcalık verin; IAM rollerini sıkı tanımlayın.
• Policy as code: Rego/OPA veya benzeri policy engine'lerle politikalarınızı merkezi ve test edilebilir biçimde tanımlayın.
• Row‑level security: Veri tabanı seviyesinde RLS veya VPD uygulamalarını değerlendirin (Postgres RLS, SQL Server VPD gibi).

Performans ve operasyon

• Authorization caching: decision caching ile yüksek trafikli kontrollerin maliyetini azaltın (TTL ve invalidation politikaları ile).
• Telemetry ve audit logs: authorization kararlarını, denied events ve escalations için merkezi log toplayın ve korele edin.
• Test ve otomasyon: unit/integration test'lerde policy'leri doğrulayın; fuzzing ile IDOR benzeri vektörleri tarayın.

Güvenlik

• Token validation: JWT'lerde alg, issuer, audience ve signature doğrulamalarını zorunlu kılın; exp/nbf claim'lerini kontrol edin.
• Service mesh ve mTLS: Microservices içinde service identity ve mutual TLS ile kimlik doğrulama yapan bir yapı kurun.
• Admin endpoints: Yönetim API'lerini network olarak izole edin ve ayrı audit/alerting mekanizmaları kurun.

8. SIK YAPILAN HATALAR

• Client‑side kontrolü tek yetki kapısı sanmak — server tarafında kontroller ihmal edilir.
• IDOR tespiti yapmamak — resource id'leri doğrudan expose edilip sahibine göre kontrol edilmeyebilir.
• JWT validation'ında alg veya issuer doğrulaması atlamak — token forgery riskini artırır.
• Excessive service privileges — mikroservislerin yönetim rollerine veya geniş IAM izinlerine sahip olması lateral hareketi kolaylaştırır.
• Eksik audit ve telemetri — deneme ve hatalı erişim girişimleri kaydedilmezse saldırılar fark edilmez.

9. GELECEK TRENDLER

AI destekli authorization policy synthesis

AI, mevcut access logları, incident verileri ve uygulama modellerini kullanarak öneri‑tabanlı policy üretme ve yanlış yapılandırmaları tespit etmede yardımcı olacaktır. Ancak AI önerilerinin insan tarafından gözden geçirilmesi zorunlu kalacaktır.

Fine‑grained contextual authorization

Context‑aware authorization (time of day, geolocation, device posture, risk signals) daha yaygın kullanılacak; adaptive auth ile birlikte dinamik izinler uygulanacaktır.

Decentralized authorization ve capability system'lar

Dağıtık sistemler için capability tokens, verifiable claims ve decentralized identity ile entegre authorization mekanizmaları popülerleşebilir; bu yaklaşımlar offline senaryolarda avantaj sağlar.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. IDOR nasıl tespit edilir?

   Fuzzing ve parameter tampering testleri, DAST araçları ve özel script'lerle IDOR aranabilir; ayrıca unit/integration test'lerinde owner checks otomatikleştirilmelidir.

2. 2. RBAC ile ABAC arasında nasıl karar veririm?

   Basit uygulamalar için RBAC hızlı ve yeterlidir. Çok sayıda dynamic koşul ve attribute gereksinimi varsa ABAC veya PBAC tercih edilmelidir.

3. 3. JWT neden riskli olabilir?

   Yanlış configuration (alg none), uzun ömürlü token, key management eksiklikleri veya signature validation atlanması JWT'leri riskli kılar.

4. 4. Service account izinlerini nasıl azaltırım?

   Least privilege prensibini izleyin, IAM role scope'unu daraltın, short‑lived credentials ve workload identity kullanın.

5. 5. Policy as code neden öneriliyor?

   Policy as code (Rego/OPA) merkezi yönetim, test edilebilirlik ve audit imkanı sağlar; politikaların version kontrolü ve review süreçleri ile güvenilirliği artar.

6. 6. Row‑level security ne zaman kullanılmalı?

   Tenant isolation, per‑user data segregation veya fine‑grained data access ihtiyaçlarında veri tabanı seviyesinde RLS güçlü bir çözüm sağlar.

7. 7. Authorization testlerini nasıl otomatikleştiririm?

   Unit test'lerde policy evaluation ve mock subject ile testler yazın; integration test'lerde end‑to‑end senaryolar ve fuzzing script'leri kullanın.

8. 8. Yetkilendirme ihlali tespitinde hangi metrikler önemli?

   Denied request rate, privilege escalation attempts, unusual resource access patterns, resource owner mismatch incidents ve admin endpoint erişimleri izlenmelidir.

Anahtar Kavramlar

• IDOR: Insecure Direct Object Reference — doğrudan obje id'sinin kontrolsüz kullanımı.
• RBAC / ABAC: Rol‑temelli ve attribute‑temelli erişim kontrol modelleri.
• RLS: Row Level Security — veri tabanı seviyesinde satır bazlı erişim kontrolü.
• OPA / Rego: Policy as code için kullanılan tooling ve dil.
• Capability token: Doğrudan yetki veren token tipi.

Öğrenme Yol Haritası

1. 0–1 ay: Authorization modelleri (RBAC/ABAC), temel policy kavramları ve OWASP Broken Access Control maddesini çalışın.
2. 1–3 ay: OPA/Rego ile policy as code pratikleri, JWT validation, IDOR testleri ve basic fuzzing araçlarını öğrenin.
3. 3–6 ay: Row‑level security, attribute‑based policies, service mesh ve mTLS ile service‑to‑service authorization uygulamaları üzerinde çalışın.
4. 6–12 ay: Advanced authorization design, policy automation, AI destekli policy önerileri ve enterprise scale authorization governance projelerinde deneyim kazanın.