IAM: kullanıcı, rol ve politika

Bulut güvenliğinin kalbi kimlik ve yetki yönetimidir, kısa adıyla IAM (Identity and Access Management). Klasik veri merkezinde güvenilir bir iç ağ vardı ve o ağa giren çoğu şey güvenilir sayılırdı. Bulutta böyle bir iç ağ yok.

Bir depoya, bir sanal makineye ya da bir gizli anahtara yapılan her istek tek tek doğrulanır ve yetkilendirilir. Bu yüzden yanlış yazılmış tek bir politika bütün bir hesabı açabilir. Bu derste IAM'in üç temel nesnesini kuracak, bir politikayı satır satır okuyacak ve iznin hangi sırayla verildiğini göreceksin. Sonunda bir politikaya bakıp neyi kime açtığını tek cümleyle söyleyebileceksin.

Neden ayrı bir kimlik katmanı var? Çünkü bulutta ağ sınırı artık güvenlik sınırı değildir. Bir depo internete kapalı olsa bile ona erişim ağ kuralıyla değil politikayla açılır.

Sağlayıcının arayüzüne gelen her çağrı üç adımdan geçer. Önce istek imzalanır, yani çağrının bir kimliğe ait olduğu kanıtlanır. Sonra o imzanın hangi kullanıcıya ya da role ait olduğu bulunur.

En sonda o kimliğin bu isteği yapıp yapamayacağı, ilgili bütün politikalar okunarak kararlaştırılır. Kimlik doğrulama kim olduğunu, yetkilendirme ne yapabileceğini söyler. IAM ikinci ve üçüncü adımın tamamını yönetir.

IAM üç nesne üstünde durur. Kimlik, isteği yapan taraftır: bir kullanıcı, bir rol ya da bir servis. Politika, o kimliğin hangi eylemi hangi kaynakta yapabileceğini yazan kuraldır ve JSON biçiminde tutulur. Güven ise bir rolün kapısındaki bekçidir, yani o role kimin bürünebileceğini söyler ve rolün kendi içinde durur.

Kısaca kimlik kim, politika ne, güven kim olabilir sorusuna cevap verir. Bir yetki karışıklığını çözerken bu üç soruyu ayrı sormak neredeyse her zaman sorunu daraltır.

Bu üç soruyu gerçek bir olayın içinde düşün. Altay Kargo'nun güvenlik ekibi, gece yarısı bir rapor kovasından toplu indirme yapıldığını fark eder. İlk soru kimliktir: çağrı bir kullanıcı anahtarıyla mı, yoksa üstlenilmiş bir rolle mi gelmiş?

İkinci soru politikadır: bu kimliğe kovayı okuma iznini hangi belge veriyor? Üçüncü soru güvendir: kimlik bir rolse, o role kim bürünebiliyor? Üç cevap yan yana gelince sızıntının girdiği kapı da, kapatılacak yer de görünür. Karmaşık görünen çoğu kurulum, aynı üç parçanın farklı bileşimlerinden ibarettir.

Politika, bir kimliğe hangi eylemleri hangi kaynaklarda yapabileceğini söyleyen bir JSON belgesidir. Dört alandan kurulur. Effect iznin yönünü söyler: izin (Allow) ya da ret (Deny). Action hangi arayüz çağrısını kapsar, örneğin s3:GetObject; buradaki s3 servis, GetObject ise o servisteki tek bir işlemdir.

Resource eylemin hangi kaynakta geçerli olduğunu ARN biçiminde belirtir; ARN bir kaynağın buluttaki tam adresidir. Condition ise kuralın hangi koşulda çalışacağını daraltır. Belge tek bir ifadeden oluşabilir ya da her biri kendi kararını üreten birden çok ifadeyi bir arada tutabilir.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "RaporlariOku",
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": [
      "arn:aws:s3:::lab-raporlar",
      "arn:aws:s3:::lab-raporlar/*"
    ]
  }]
}

Bu örnekte iki ARN yazılmış ve nedeni öğreticidir. s3:ListBucket eylemi kovanın kendisini hedefler, çünkü listeleme kovanın üstünde yapılan bir işlemdir; kaynağı arn:aws:s3:::lab-raporlar biçiminde, sonunda yıldız olmadan yazılır. s3:GetObject ise kovanın içindeki nesneleri hedefler, bu yüzden kaynağı /* ile biter ve kovadaki her nesneyi kapsar.

Kovanın adı ile kovanın içindekiler bulutta iki ayrı kaynaktır. Yalnız kova ARN'sini yazarsan nesneleri okuyamazsın; yalnız /* yazarsan kovayı listeleyemezsin. Bu ayrımı görmek, en sık yapılan izin hatalarının çoğunu daha başında yakalar.

Dört alan içinde en güçlü daraltmayı Condition verir ama çoğu ekipte boş kalır. Koşulla neler yapılır? İsteği belirli bir VPC uç noktasından gelmeye, belirli bir IP aralığına, çok adımlı doğrulamanın yapılmış olmasına ya da kaynakta belirli bir etiketin bulunmasına bağlayabilirsin.

Örneğin aws:MultiFactorAuthPresent koşulu bir eylemi yalnız çok adımlı doğrulamadan geçmiş oturumlara açar. Aynı politika koşul eklendiğinde çok daha dar hale gelir. Koşul alanını okumadan bir politikanın gerçek genişliğini bilemezsin, çünkü geniş görünen bir izin tek bir koşulla iğne deliğine inebilir.

Politika okumanın en iyi alışkanlığı sesli okumaktır. Şu kimlik, şu eylemleri, şu kaynaklarda, şu koşulla yapabilir. Bu cümleyi kurabiliyorsan politikayı anlamışsındır. Cümle kurulamıyorsa politika ya çok geniştir ya da yanlış yazılmıştır.

Cümleye dökülemeyen bir kural, denetimde de savunulamaz. Denetimde en tehlikeli politikalar, kimsenin ne işe yaradığını hatırlamadığı için silmeye çekinilen eski politikalardır. Bir politikayı tek cümleyle anlatamıyorsan, önce onu anlamaya, sonra daraltmaya çalış; anlamadığın bir kuralı güvenle daraltamazsın.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::lab-raporlar/*"
  }]
}

Kullanıcı kalıcı bir kimliktir. Kendi parolası ve erişim anahtarı olur. Bu yüzden bir insan için ya da bulut dışındaki eski bir sistem için kullanılır. Sorun anahtarın nerede durduğudur: bir diskte, bir yapılandırma dosyasında ya da bir betiğin içinde.

Anahtar çalınırsa, çalan taraf onu dünyanın herhangi bir yerinden kullanabilir ve anahtarın kendiliğinden düşen bir ömrü yoktur. Bir kullanıcı anahtarı sızdığında elle iptal edilene kadar geçerli kalır. Bu yüzden kalıcı kullanıcı anahtarları bulutta en sık sızan ve en uzun süre tehlike taşıyan kimlik bilgileridir.

Rol kimseye ait değildir. Bir makine, bir servis ya da bir kişi onu üstlenir (assume role) ve karşılığında geçici bir kimlik alır. Bu geçici anahtar birkaç saatte düşer, yani bir sızıntının ömrü kısa kalır.

Bir makinenin rolü, makinenin kendi kimlik hizmetinden otomatik yenilenir; kimse diske anahtar yazmaz. Aynı rolü birçok kişi ya da makine sırayla üstlenebilir, çünkü rol bir kalıp gibidir ve sahibi yoktur. Bulut mimarisinde kalıcı anahtar yerine rol üstlenmek temel reflekstir.

Grup bir kimlik değildir, yalnız bir kolaylıktır. Kullanıcıları toplar ve politikayı bir kez bağlarsın; grup değişince üyelerin yetkisi topluca değişir. Rolün aksine grup üstlenilmez ve kendi anahtarı olmaz, bir istek grubun adına gelmez.

Bir kullanıcının gerçek yetkisi, doğrudan bağlı politikalarının yanında bağlı olduğu bütün grupların politikalarını da içerir. Bu yüzden bir kullanıcıyı denetlerken yalnız kendi politikalarına bakmak yanıltır; grup üyeliklerini de saymak gerekir.

Kimlik sayısı büyüdükçe elle yönetim biter. İnsanlar için doğru yol kalıcı kullanıcı açmak değil, tek bir kimlik sağlayıcısından federasyondur. Kişiler kurum hesabıyla giriş yapar, o hesabın çok adımlı doğrulamasından geçer, kısa süreli bir rol üstlenir ve iş biter.

Ayrılan bir çalışanın erişimi tek yerden, kurum dizininden kapanır; onlarca hesapta ayrı ayrı kullanıcı silmek gerekmez. AWS tarafında bu işi IAM Identity Center üstlenir, eski adıyla AWS SSO. Federasyonun özü kalıcı anahtarı ortadan kaldırmaktır.

Bir istek geldiğinde varsayılan cevap rettir. Hiçbir politika bir eyleme açıkça izin vermiyorsa, o eylem örtük olarak (implicit deny) reddedilir.

Tek istisna hesabın kök kullanıcısıdır, onun tam erişimi vardır. Yani bir kimliğe bir izni hiç vermemek, o eylemi yasaklamakla aynı sonucu verir. Bu varsayım güvenli tarafta durmayı kolaylaştırır: unuttuğun ya da hiç düşünmediğin her eylem kapalıdır. Bir kimlik ancak bir politika onu açıkça izinli kıldığında iş yapabilir, bu yüzden yeni bir kimlik hiçbir şey yapamayan boş bir sayfa olarak başlar.

Karar sırası sabittir ve ezberlenmeye değer. Önce açık ret aranır. Değerlendirilen katmanların herhangi birinde isteğe uyan bir ret ifadesi varsa, tartışma orada biter ve istek reddedilir.

Açık ret yoksa açık izin aranır. Açık izin de yoksa örtük ret uygulanır. Buradaki kilit kural şudur: açık ret her açık izni bastırır, yani geri alınamaz bir tavandır. Bir eylemi kesin kapatmak istiyorsan izni kaldırmak yetmez, çünkü başka bir politika onu geri açabilir; onu açıkça reddedersin ki hiçbir izin bu reddi delemesin.

Gerçek yetki tek bir politikadan değil, dört katmanın kesişiminden çıkar. Kimlik politikası kimliğe bağlanır ve ne yapabileceğini yazar. Kaynak politikası kaynağın kendi kapısında durur; bir kova politikası, kimlik tarafına hiç bakmadan erişim açabilir.

Yetki sınırı (permissions boundary) kimliğin ulaşabileceği en geniş yetkiyi tavandan kısar ama kendi başına izin vermez. En üstte organizasyon politikaları vardır: servis kontrol politikası (SCP) ve kaynak kontrol politikası (RCP). Bir eylemin geçmesi için, aynı hesap içinde kimlik ya da kaynak politikasının izin vermesi ve üstteki tavanların da engellememesi gerekir.

Bu yapı yüzünden en sık duyulan yakınma şudur: izin politikam var ama erişemiyorum. Sorun çoğu zaman kimlik politikasında değil, üstteki tavandadır.

SCP tüm hesabın üstünde durur; bir servisi kapatmışsa, alttaki hiçbir izin onu açamaz. RCP ise 2024 sonunda gelen daha yeni bir tavandır ve kaynak tarafında çalışır, örneğin bir kovaya organizasyon dışından erişimi topluca keser. İkisi de asla izin vermez, yalnız sınır koyar. Bir eksik izin sorununu çözerken önce hangi katmanın engellediğini bulmak gerekir, yoksa kimlik politikasına boş yere satır eklersin.

Politikalar iki biçimde bağlanır. Yönetilen politika ayrı bir nesnedir, bir kez yazılır ve birçok kimliğe bağlanır. Değişince eskisinin üstüne yazmaz, yeni bir sürüm üretir ve en çok beş sürüm saklar; bu, bozuk bir değişikliği eski sürüme dönerek geri almanı kolaylaştırır.

Satır içi (inline) politika ise tek bir kimliğin içinde gömülü durur, o kimlik silinince o da gider. Listeleme komutlarında ayrı sorulur, bu yüzden denetimde en sık atlanan yer orasıdır. Bir kimliğin gerçek yetkisini görmek için hem bağlı yönetilen politikalara hem de satır içi politikalara bakman gerekir.

Her ifadeye açıklayıcı bir kimlik yazmak küçük ama değerli bir alışkanlıktır. Sid alanı zorunlu değildir ama ifadeye bir ad verir. Altı ay sonra o politikaya bakan kişi, hangi ihtiyacın hangi satırı doğurduğunu bu ad üstünden anlar ve gereksiz bir satırı silmeye cesaret eder. Aynı mantık rol ve kova adlarında da geçerlidir.

Adında ortam, ekip ve işlev geçen bir kaynak, listeye bakan kişiye kendini anlatır. Adlandırma kuralı olmayan bir hesapta ise yüzlerce rolün hangisinin hâlâ kullanıldığını kimse söyleyemez ve kullanılmayan rol silinmeden birikir.

Kök hesap (root user) ayrı bir konudur. Fatura ve hesap kapatma gibi az sayıda iş dışında hiç kullanılmaz. Donanım tabanlı çok adımlı doğrulamayla korunur ve ona programatik erişim anahtarı üretilmez, çünkü kök anahtarı sızarsa hesabın tamamı gider. Kök kullanıcının bir işlem yapması nadir bir olaydır, bu yüzden kök girişi gerçekleştiği anda bir uyarı üretmelidir.

Çok hesaplı bir kurulumda üye hesapların kök kimlik bilgileri AWS Organizations üstünden merkezi olarak kaldırılabilir. Bu özellik açıkken yeni açılan üye hesaplarda kök parolası ya da anahtarı hiç oluşmaz. Kök erişimi gerçekten gerekirse parola kurtarmayı yönetim hesabı açar.

Bütün bunların altında tek bir ilke yatar: okunamayan politika denetlenemeyen politikadır. Okunabilir bir yapıda denetçi önce yıldızlı Resource satırlarına bakar, çünkü kaynak alanındaki tek bir yıldız o eylemi hesaptaki bütün kaynaklara açar. Federasyon, açık ret tavanları, anlamlı adlar ve az sayıda ifade hep aynı amaca hizmet eder: erişimi tek bir yerden görebilmek ve gerektiğinde tek bir yerden kapatabilmek. Bir olay anında en değerli şey, kimin neye eriştiğini dakikalar içinde çıkarabilmektir ve bu ancak yapı sade tutulursa mümkün olur.