En az yetki ve politika okuma

En az yetki (least privilege) bir slogan değil, ölçülebilir bir mühendislik hedefidir. Bir kimliğe işini yapması için gereken en dar izni vermek ve fazlasını hiç açmamak demektir.

Kulağa basit gelir ama pratikte tersi olur: kimlikler zamanla şişer, çünkü izin eklemek kolay, kaldırmak korkutucudur. Bu derste bir politikaya bakıp yıldızların nerede durduğunu okuyacak, geniş ve dar iki yazımı yan yana koyacak, kullanılmayan yetkiyi nasıl ölçüp kaldıracağını göreceksin. Amaç bir politikanın genişliğini tahminle değil, kullanım kanıtıyla değerlendirmektir.

Bir politikaya baktığında ilk işin yıldızları bulmaktır. Eylem alanındaki yıldız o servisin tüm çağrılarını açar; s3:* yazmak, okuma ve yazmayla birlikte kova silmeyi ve politika değiştirmeyi de kapsar.

Kaynak alanındaki yıldız ise hesaptaki tüm kaynakları kapsar. İkisi aynı ifadede buluşursa politika neredeyse yönetici yetkisidir. Bu yüzden politika okuma her zaman yıldız avıyla başlar, çünkü tehlikenin çoğu bu iki alanda toplanır. Bir yıldız gördüğünde durup sorarsın: bu yıldız gerçekten gerekli mi, yoksa sadece işi hızlı bitirmek için mi konmuş?

Ama yıldız tek başına kötü değildir. s3:GetObject eylemi tek bir kova yolunda yıldızla biter, çünkü kovadaki nesneleri hedefler ve nesnelerin adı önceden bilinmez. Buradaki yıldız kaynağın en alt seviyesinde ve dardır; yalnız o kovadaki nesneleri kapsar.

Önemli olan yıldızın hangi alanda ve hangi seviyede durduğudur. Nesne yolundaki bir yıldız ile hesap kökündeki bir yıldız aynı şey değildir. Bu yüzden yıldızı görünce panik yapmak yerine, hangi alanda ve ne kadar derinde olduğunu okumak gerekir.

Eylem ile kaynağı her zaman birlikte düşün. Geniş bir eylem listesi dar bir kaynakla kabul edilebilir kalır; tek bir kovada her S3 eylemine izin vermek, o kovanın sahibi için makul olabilir. Dar bir eylem listesi ise yıldızlı kaynakla hesabın tamamına yayılır; tek bir okuma izni bile bütün kovalarda verilirse büyük bir sızıntı kapısı olur.

Tek bir alanı okuyup karar veremezsin. İki alanı birlikte okumak, bir politikanın gerçek etkisini gösteren tek güvenilir yöntemdir.

En az yetkiyi pratikte kurmanın iki yolu var. Birincisi tahmin: geliştirici ne isterse yazarsın, sonra iş bozulunca genişletirsin. Bu yol her zaman gereğinden geniş politikada biter, çünkü kimse çalışan bir sistemi daraltmaya cesaret edemez.

Bir izni silip bir şeyin bozulması riski, o izni bırakmanın belirsiz riskinden her zaman daha somut görünür. Sonuçta politikalar tek yönde, hep genişleme yönünde büyür ve kimse geri almaz.

İkinci yol ölçüme dayanır. Kimliğe önce bir izleme dönemi verilir, çağrıları denetim kaydına (CloudTrail) yazılır ve politika gerçekte kullanılan eylemlerden üretilir. IAM Access Analyzer bu üretimi kendi yapar.

Belirttiğin döneme, en çok doksan güne kadar geriye bakar ve o pencerede kullanılan eylemlerden bir taslak politika çıkarır. Üretilen politikayı yedi gün içinde inceleyip yayımlayabilirsin. Bir uyarı vardır: iam:PassRole eylemi denetim kaydında bu amaçla izlenmediğinden taslağa girmez ve elle eklenir.

Ölçümün tahminden üstün olmasının nedeni basittir. Tahminle yazılan politika ya çok geniş olur ya işi bozar.

Kullanım geçmişi ise hangi eylemin gerçekten çağrıldığını gösterir, tahmine yer bırakmaz. Böylece üretilen politika hem işi yürütecek kadar geniş hem de fazlasını açmayacak kadar dar çıkar. Yine de üretilen taslak son söz değildir; bir insan onu okur, gerekirse kaynak ARN'lerini daraltır ve koşul ekler. Ölçüm işin doğru başlangıç noktasını verir, mühendisin yargısının yerini almaz.

Bu ayrımı pratikte görmenin en hızlı yolu iki örneği yan yana koymaktır. Aynı ihtiyacı geniş ve dar biçimde yazan iki politika, aradaki farkı tek bakışta gösterir. Aşağıdaki örnekte geniş taraf her kovada her S3 eylemini açarken, dar taraf tek kovaya iki eylemle sınırlı kalır ve bir de koşul ekler. İki politika da aynı uygulamayı çalıştırabilir, ama biri hesabın tamamını riske atar, öteki yalnız bir kovaya ve tek bir uç noktaya erişimi bırakır.

// Geniş: her kovada her S3 eylemi
"Action": "s3:*", "Resource": "*"

// Dar: tek kova, iki eylem, uc noktasi kosulu
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": ["arn:aws:s3:::lab-rapor", "arn:aws:s3:::lab-rapor/*"],
"Condition": { "StringEquals": { "aws:SourceVpce": "vpce-0a1b2c3d" } }

Koşul, geniş görünen bir politikayı dar hale getirir. Bu düşünce büyütüldüğünde bir çerçeveye dönüşür: veri çevresi (data perimeter). Amaç üç şeyi aynı anda tutmaktır.

Erişim yalnız güvenilir bir kimlikten gelsin, yalnız güvenilir bir kaynağa gitsin ve yalnız beklenen bir ağdan geçsin. Bu üçü SCP, RCP, kaynak politikaları ve VPC uç nokta politikalarındaki koşul anahtarlarıyla kurulur. Tek başına bir koşul küçük görünür, ama bu üç sınır bir araya geldiğinde çalınmış bir anahtar bile hesabın dışından işe yaramaz hale gelir.

Kaynak tabanlı politikalar ayrı bir dikkat ister. Kova politikası, KMS anahtar politikası ve kuyruk politikası kaynağın kendi kapısında durur.

Dışarıdaki bir hesaba erişim buradan açılır ve kimlik tarafına hiç bakmadan çalışır. Aynı hesap içinde çoğu kaynak için kimlik politikası ile kaynak politikasından biri izin verirse erişim olur; ikisinin izni birleşir. Bu yüzden bir kimliğin yetkisini yalnız kimlik politikasına bakarak ölçmek yanıltır; kaynağın kapısında ona açılmış ayrı bir izin de olabilir.

Bu yüzden hesap dışı paylaşım taraması düzenli yapılır. IAM Access Analyzer, güven çemberinin dışına açılan her kaynağı bir bulgu olarak listeler ve bu dış erişim bulguları ücretsizdir. Liste genelde kısa çıkar ve her satırın bir gerekçesi olmalıdır.

Gerekçesi olmayan bir dış paylaşım, açılıp unutulmuş bir kapıdır; çoğu bulut sızıntısı da tam olarak böyle unutulmuş bir kova ya da anlık görüntü paylaşımından çıkar. Tarama bir kez kurulunca sürekli çalışır ve yeni bir paylaşım açıldığında bir bulgu üretir.

En az yetkinin ölçülebilir bir hali de vardır: kullanılmayan yetkileri saymak. AWS son erişim bilgisini kimlik ve servis bazında raporlar. Servis verisi en az dört yüz günü kapsar ve yeni bir çağrı rapora dört saat içinde yansır.

Doksan gündür hiç çağrılmamış bir servis izni, o kimlikten kaldırılmaya güçlü bir adaydır; büyük olasılıkla o iznin neden verildiğini kimse hatırlamaz bile. Üç ayda bir çalışan bir iş gibi seyrek kullanımları kaldırmadan önce sahibine sorarsın. Kullanılmayan izinleri kaldırmak iyi bir denetim turu için yeterli bir başlangıçtır ve işi bozma riski düşüktür, çünkü zaten çağrılmayan bir eylemi kaldırıyorsundur.

Kullanılmayan kimlikler de aynı listede durur ve bu yaygın bir sorundur. Datadog'un 2025 Bulut Güvenliği Durumu raporuna göre AWS IAM kullanıcılarının yüzde 59'unda bir yıldan eski, hâlâ etkin bir erişim anahtarı var.

Bu kullanıcıların yarısından fazlasında kimlik bilgileri doksan günden uzun süredir hiç kullanılmamış. Böyle bir anahtar iş değiştirmiş bir çalışana ya da unutulmuş bir betiğe aittir, hâlâ geçerlidir ve sızsa çalışır. Bir anahtarı önce devre dışı bırakıp bir süre bekleyip sonra silmek, düzenli yapılan en ucuz iyileştirmedir; devre dışı bırakma bir şeyi bozarsa anahtarı geri açarsın.

İş kimliğini get-service-last-accessed-details komutuna verince asıl rapor gelir. Rapor önce hazırlanır, sonra okunur; büyük hesaplarda bu birkaç saniye sürer. Çıktının iki alanı önemlidir.

JobStatus raporun tamamlanıp tamamlanmadığını söyler; değeri COMPLETED değilse veri henüz eksiktir ve bir süre daha beklenir. ServicesLastAccessed dizisi ise kimliğin izin politikalarının açtığı her servis için ayrı bir satır taşır ve asıl karar bu satırlarda verilir. Hiç kullanılmamış servisler de listede durur, yalnız son erişim ayrıntıları boş gelir. Bir servisin son erişim alanı boşsa ya da tarihi çok eskiyse, o iznin kaldırılma adaylığı başlar.

{
  "JobStatus": "COMPLETED",
  "JobType": "SERVICE_LEVEL",
  "ServicesLastAccessed": [
    {
      "ServiceName": "Amazon S3",
      "ServiceNamespace": "s3",
      "LastAuthenticated": "2026-09-28T07:41:00Z",
      "LastAuthenticatedEntity": "arn:aws:iam::111122223333:user/laborant",
      "TotalAuthenticatedEntities": 1
    },
    {
      "ServiceName": "AWS Lambda",
      "ServiceNamespace": "lambda"
    }
  ],
  "IsTruncated": false
}

Satırları oku. ServiceNamespace servisin kısa adıdır: s3 ve lambda. S3 satırında LastAuthenticated son çağrının zamanını, LastAuthenticatedEntity de çağrıyı yapan kimliği gösterir; tarih yeni olduğu için bu izin kullanılıyor demektir. Lambda satırında bu alanlar hiç yoktur.

Politika Lambda'yı açtığı hâlde izleme döneminde tek bir çağrı yapılmamıştır, yani kaldırılmaya en açık aday odur. TotalAuthenticatedEntities, rapor bir grup ya da politika için üretildiğinde kaç kimliğin o servise dokunduğunu söyler; tek bir kullanıcıda bu değer 1 olur. Bu rapor iam:PassRole eylemini izlemez, o yüzden PassRole izinlerini ayrıca elle gözden geçirirsin.

Politika yazımını insana bırakmak yerine şablona bağlamak hata payını düşürür. Ekip için üç dört hazır kalıp tanımlanır: okuyucu, dağıtımcı, denetçi. Yeni bir ihtiyaç çıktığında şablon genişletilir, yeni bir yıldız eklenmez. Yetki değişiklikleri de kod gibi ele alınır: bir kişi yazar, bir başkası okur ve onaylar.

Onaylayan kişinin soracağı tek soru çoğu geniş politikayı daha yazılırken durdurur: bu yıldız olmadan iş yürür mü? Yürüyorsa yıldız girmez; yürümüyorsa onun yerine hangi dar eylemlerin gerektiği yazılır.