Cloud IAM: Rol Tabanlı Erişim Yönetimi

Cloud IAM: Rol Tabanlı Erişim Yönetimi

Bulut ortamlarında güvenliğin temel taşı, kimin neye erişebileceğini doğru yönetmektir. IAM (Identity and Access Management), kullanıcıları, grupları ve servis hesaplarını tanımlar; RBAC (Role-Based Access Control) ise bu kimliklere izinleri roller üzerinden atar. Ancak her bulut sağlayıcısı bu kavramları farklı modellerle uygular; bir buluttaki alışkanlıkları diğerine taşımak ciddi güvenlik açıklarına yol açabilir.

1. RBAC'ın Temel Mantığı

RBAC, izinleri doğrudan kullanıcılara atamak yerine rollere bağlar ve kullanıcıları bu rollere atar. Bir rol, belirli eylemleri (okuma, yazma, silme) belirli kaynaklar üzerinde gerçekleştirme yetkisidir.

Temel Bileşenler:

Principal (Kimlik): Kullanıcı, grup veya servis hesabı.
Role (Rol): İzinlerin toplamı (ör. "Storage Reader").
Scope (Kapsam): İznin geçerli olduğu kaynak hiyerarşisi (organizasyon, proje, kaynak grubu, tek kaynak).

Altın Kural: Kullanıcıya değil, gruba rol atayın. Bu, erişim yönetimini ölçeklenebilir ve denetlenebilir kılar .

2. Bulut Sağlayıcıları Arasındaki Temel Farklar

Her sağlayıcı, IAM'i farklı bir zihinsel modelle ele alır. Aynı politikayı kopyalamak çoğu zaman mümkün değildir .

Kriter	AWS	Azure	GCP
Model	Politika merkezli (JSON)	Rol ataması + Entra ID	Kaynak hiyerarşisi + rol
Kapsam	Hesap, OU, kaynak	Yönetim grubu → abonelik → kaynak grubu → kaynak	Organizasyon → klasör → proje → kaynak
Joker İzin	Desteklenir (`s3:*`)	Rol tanımında örtük	Rolde joker yok
Özel Rol	JSON politika	JSON rol tanımı	YAML özel rol
İzin Sınırı (Boundary)	Var (Permissions Boundary)	Yok	Yok

AWS'de Roller ve Politikalar: AWS'de erişim, kimliklere veya kaynaklara eklenen politika belgeleriyle tanımlanır. Roller, güvenilen varlıkların üstlendiği kimliklerdir. Aşırı yetkiyi önlemek için Permissions Boundary kullanılabilir .

Azure'da RBAC: Azure RBAC, Entra ID kimliklerine rol atamaları yapar. Kapsam hiyerarşisi yukarıdan aşağıya miras alınır. Örneğin abonelik düzeyinde "Reader" atanan bir kullanıcı, altındaki tüm kaynak gruplarını okuyabilir .

GCP'de IAM: GCP'de izinler roller aracılığıyla verilir; roller izinlerden oluşur. Erişim, kaynak hiyerarşisinde aşağı doğru miras alınır. Temel roller (Owner, Editor, Viewer) binlerce izin içerdiği için üretimde önerilmez; bunun yerine önceden tanımlı veya özel roller tercih edilmelidir .

3. En Az Ayrıcalık (Least Privilege) Nasıl Uygulanır?

En az ayrıcalık, bir kimliğe yalnızca görevini yerine getirmek için gereken minimum izinleri vermektir. Bu, ihlal durumunda etki alanını (blast radius) daraltır .

Uygulama Adımları:

İş gereksinimini tanımlayın: Kullanıcı/servis tam olarak ne yapmalı?
En dar kapsamı seçin: Tüm abonelik yerine tek bir kaynak grubu; tüm bucket yerine tek bir prefix.
Hazır rolle başlayın: Önce yerleşik/önceden tanımlı rolleri deneyin; yetmezse özel rol oluşturun .
Joker izinlerden kaçının: AWS'de Action: "*" veya Azure'da Microsoft.Compute/* gibi geniş izinler, beklenmeyen erişimlere yol açar .
Sürekli gözden geçirin: Kullanılmayan izinleri ve rolleri periyodik olarak temizleyin .

Servis Hesapları (Service Accounts):

Her servis için ayrı servis hesabı oluşturun .
Uzun ömürlü erişim anahtarları yerine kısa ömürlü kimlik bilgileri (Workload Identity, IAM Roles Anywhere, Managed Identity) kullanın .
Anahtarları asla kaynak koduna koymayın .

4. Sık Yapılan Hatalar

Hata	Risk	Çözüm
Joker izinli politikalar	İhlalde tüm hesap ele geçirilebilir	Eylemleri açıkça listeleyin
Owner/Admin rolünü çok kişiye vermek	Denetim zorlaşır, yetki kötüye kullanımı	Owner sayısını 3 ile sınırlayın
Kullanıcıya doğrudan rol atamak	Yönetim karmaşası, denetim zorluğu	Rolleri gruplara atayın
Root/Global Admin'i günlük kullanmak	En yüksek yetkili hesap hedef olur	Root'u yalnızca acil durum (break-glass) için kullanın
Eski erişim anahtarlarını bırakmak	Sızıntı riski	Anahtarları döndürün (rotate), kullanılmayanları silin

5. Denetim ve Sürekli İyileştirme

IAM bir kez kurulup unutulacak bir yapılandırma değildir. İzin entropisi zamanla artar: projeler biter, ekipler değişir, ancak izinler kalır .

Düzenli Yapılması Gerekenler:

Erişim gözden geçirmeleri (Access Reviews): Aylık veya üç aylık periyotlarla kimin neye eriştiğini kontrol edin .
Kullanılmayan izinleri tespit edin: AWS IAM Access Analyzer, GCP Policy Analyzer/Recommender gibi araçlar kullanın .
Denetim loglarını izleyin: CloudTrail (AWS), Activity Log (Azure), Cloud Audit Logs (GCP) ile politika değişikliklerini takip edin .
Koşullu erişim kullanın: GCP'de CEL tabanlı koşullar, Azure'da Conditional Access ile zamana veya bağlama göre erişim kısıtlayın .

Sonuç

Cloud IAM ve RBAC, bulut güvenliğinin temelidir. Her sağlayıcının modeli farklı olsa da değişmeyen ilkeler vardır: en az ayrıcalık, gruplara rol atama, joker izinlerden kaçınma, kısa ömürlü kimlik bilgileri ve sürekli denetim. IAM'i bir "kur ve unut" yapılandırması olarak görmek, zamanla biriken gereksiz izinlerle saldırı yüzeyini büyütür. Doğru uygulandığında RBAC, hem güvenliği hem de operasyonel netliği artırır.