AWS Limitlerine Takılmadan Ölçekte IAM Politika ve Rol Yönetimi

IAM’in sessiz ve katı tavanları var. Bir yönetilen politika ancak belli sayıda karakter tutabilir. Bir role ancak belli sayıda politika ekleyebilirsiniz. Satır içi politikalar, uyarı vermeden dolan bir varlık başına boyut bütçesini paylaşır. Hesapların varsayılan bir rol kotası vardır. Tek bir paylaşılan mega-role yaslanıp izinleri konsoldan yapıştıran ekipler bu tavanlara doğru sürüklenir ve bir dağıtımın ortasında anlaşılması güç bir hatayla engellenir. Çıkış yolu yapısal: varsayılan olarak en az ayrıcalık, sorumluluk başına tek politika, paylaşılan mega-role yerine dar kapsamlı roller ve koruma katmanı olarak izin sınırları ile SCP’ler.

Her şeyi düzenleyen tek fikir şu: vermek mi yoksa sınırlamak mı istediğinize karar verin. IAM kimlik ve kaynak politikaları izin verir. İzin sınırları ile SCP’ler yalnızca sınırlar koyar. Bu iki işi ayrı tutarsanız çoğu limit sorunu hiç oluşmaz.

Gerçekten karşılaşacağınız limitler

IAM limitleri iki kategoriye ayrılır ve bunları karıştırmak ciddi zaman kaybettirir. Bir kısmı Service Quotas üzerinden yükseltebileceğiniz kotalardır. Diğerleri hiçbir destek talebinin oynatamayacağı sabit karakter limitleridir. Mühendisler sabit olanlar için artış talebi açar ve baştan onay olmayacak bir talebin reddedilmesini bekler.

Ayarlanabilir kotalar (varsayılan, ardından Service Quotas’ın otomatik onaylayacağı maksimum):

Kota	Varsayılan	Maksimum
Rol başına yönetilen politika	10	25
Kullanıcı başına yönetilen politika	10	20
Grup başına yönetilen politika	10	10 (varsayılanda sabit)
Hesap başına müşteri yönetilen politika	1.500	10.000
Hesap başına rol	1.000	10.000
Hesap başına grup	300	500
Rol güven politikası uzunluğu	2.048 karakter	8.192 karakter

Sabit boyut limitleri (kota sayfası bunlar için artış talep edemeyeceğinizi açıkça belirtir):

Limit	Değer
Müşteri yönetilen politika boyutu	6.144 karakter
Kullanıcı başına satır içi politika toplamı	2.048 karakter
Grup başına satır içi politika toplamı	5.120 karakter
Rol başına satır içi politika toplamı	10.240 karakter
Saklanan yönetilen politika sürümü	5

Üç satır içi toplam, insanların en çok yanlış hatırladığı değerlerdir. Sıralama sezgiye ters işler: rol bütçesi 10.240 ile en büyük, kullanıcı bütçesi 2.048 ile en küçüktür. Değer, o tek varlıktaki tüm satır içi politikaların toplamıdır, politika başına bir limit değildir.

Bilmeye değer bir ayrıntı daha, kota sayfasından alıntı: “IAM, bir politikanın boyutunu bu limitlere göre hesaplarken boşlukları saymaz.” JSON’u sıkıştırmak (minify) 6.144 ve satır içi tavanlara karşı biraz alan kazandırır. Ama sığdırmak için sıkıştırmaya başvuruyorsanız, o politika çok fazla iş yapıyordur. Çözüm onu sıkıştırmak değil, bölmektir.

Limiti aştığınızda ne olur

Bu limitlerin hiçbiri kendini erkenden duyurmaz. Onları aştığınız anda başarısız bir dağıtım ya da başarısız bir API çağrısı olarak yüzeye çıkar.

• Bir müşteri yönetilen politika 6.144 karakteri geçer, çoğu zaman biri bir kaynak ARN’ı daha eklediğinde. CloudFormation LimitExceeded ile geri alır ve CDK dağıtımı bununla başarısız olur.
• Hâlâ varsayılan kotadaki bir role on birinci yönetilen politikayı eklersiniz. AttachRolePolicy çağrısı başarısız olur; CloudFormation’da bu bir politika ekleme limiti hatası olarak okunur.
• Bir roldeki satır içi politika, toplam 10.240 karakteri geçene kadar büyümeye devam eder. Sonraki PutRolePolicy LimitExceeded döner.
• Bir hesap 1.000 rollük varsayılan kotasına yaklaşır. Her biri yeni roller üreten dal başına önizleme ortamları bunun sık görülen bir nedenidir. Bayat roller silinene ya da kota yükseltilene kadar yeni yığınlar rol oluşturamaz.

Örüntü her seferinde aynıdır: aylarca görünmez kalan bir limit, bir cuma dağıtımında duvara dönüşür. Sizi önceden uyaracak bir izleme alarmı yok; her duvardan uzak durmayı politika ve rol yapısının kendisi sağlamak zorunda.

En az ayrıcalık politikaları küçük tutar

En az ayrıcalık genellikle bir güvenlik erdemi olarak çerçevelenir. Ölçekte ise politikaları 6.144 karakterin altında tutan şeyin de kendisidir. Kapsamı, adlandırılmış kaynaklar üzerindeki adlandırılmış eylemlerle sınırlanmış bir politika küçüktür. Kapsam düşünmemek için joker karakterlere uzanan bir politika sınırsızca büyür, çünkü her “sadece bir tane daha ekle” aynı belgeye düşer.

Dar kapsamlı bir politika eylemleri ve tam kaynakları adlandırır:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadWriteUploadsBucket",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": [
        "arn:aws:s3:::acme-uploads",
        "arn:aws:s3:::acme-uploads/*"
      ]
    }
  ]
}

Tembel sürüm kâğıt üstünde aynı işi yapar ve diğer her eksende başarısız olur:

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": "s3:*", "Resource": "*" }
  ]
}

Joker karakter, hesaptaki her bucket üzerinde her S3 eylemine izin verir. Etki alanını şişirir, IAM Access Analyzer’ın işaretlediği tam da bu şekildir ve sonunda boyut limitini patlatan “bir tane daha ekle” büyümesini davet eder. Eylemleri ve ARN’leri ilk satırdan sınırlandırın; politika hem güvenli hem küçük kalır.

Tek politika, tek sorumluluk

Her yönetilen politikaya tek bir iş ve onu ifade eden bir ad verin: s3-read-uploads-bucket, dynamodb-crud-orders-table, sqs-consume-orders-queue. Bir rolün izinlerini, tek bir büyük satır içi bloğu tavana doğru büyüterek değil, bu küçük politikalardan birkaçını ekleyerek kurun.

Bu üç şey kazandırır. Her belge, okunacak ve denetlenecek kadar küçük kalır. Her biri, gerçek bir ortak ihtiyacı paylaşan roller arasında yeniden kullanılabilir. Her biri kendi başına sürümlenir. Kompozisyon matematiği de rahattır: dört ila altı tek amaçlı yönetilen politikadan kurulan bir rol, on eklenen politikalık varsayılan sınırın epey altındadır ve hiç satır içi politika kullanmaz, dolayısıyla satır içi toplam hiç devreye girmez.

Bunun önlediği başarısızlık türü, PutRolePolicy reddedene kadar birer birer büyüyen satır içi politikadır. Adlandırılmış yönetilen politikalardan kurulan bir rolün, taşacak tek bir belgesi yoktur.

Servis ve ortam başına ayrı bir rol

Mega-role, tasarımla uzaklaşmanız gereken örüntüdür. Dev, staging ve prod’daki her fonksiyona eklenen tek bir app-lambda-role, sonunda her fonksiyonun ihtiyaçlarının birleşimini taşır. Bu politika kümesi büyüktür, joker karakterlere kayar ve ekleme sınırına dayanır. Ele geçirilen tek bir fonksiyon, rolün erişebildiği her servisin anahtarlarını elinde tutar.

Serverless Framework, mega-role’ü en az dirençli yol haline getirir. Bir projede, provider seviyesinde bildirdiğimiz her ifade, framework’ün tüm servis için oluşturduğu tek execution role’e ekleniyordu. Her fonksiyon servisin izinlerinin birleşimini taşıyordu; DynamoDB’ye hiç dokunmayan fonksiyonlar tablo izinleri tutuyordu. Rolün tek satır içi politikası, tam da 10.240 karakterlik toplamla buluşan türden bir belgeye dönüştü. Çözüm serverless-iam-roles-per-function eklentisi oldu: her fonksiyon kendi iamRoleStatements bloğunu bildirir ve eklenti fonksiyon başına dar kapsamlı bir rol oluşturur. Trade-off da gerçek: fonksiyon başına her rol, CloudFormation yığınında bir kaynak daha demek; çok fonksiyonlu bir servis 500 kaynak tavanına daha erken yaklaşır (tam da hemen aşağıda çözülen gerilim).

Alternatif, servis başına ve ortam başına bir roldür: orders-api-prod, orders-api-dev, billing-worker-prod. Her rolün politika kümesi küçük kalır. Ele geçirilen bir fonksiyon yalnızca kendi servisinin kaynaklarına ulaşabilir. Denetim izi, hangi iş yükünün hangi izni tuttuğunu tam olarak adlandırır. Bu disiplinin bedeli daha fazla roldür; bu yüzden 1.000’lik hesap başına varsayılanı izleyin, özellikle dal başına rol üreten geçici önizleme ortamlarıyla. Artışı bir dağıtımın başarısız olduğu anda değil, erkenden talep edin.

Paylaşılan rol gerilimi ve çözümü

Burada yüzleşilecek gerçek bir çelişki var ve bu sitede ikisi de mevcut. CloudFormation’ın 500 kaynak limitini aşma rehberi, bir birleştirme taktiği olarak paylaşılan IAM rollerini önerir: elli yerine tek bir rol, düzinelerce CloudFormation kaynağı tasarruf eder ve bir yığını 500 tavanının altında tutabilir. Öte yandan Lambda fonksiyon granülaritesi yönlendirmesi ve AWS en iyi uygulaması, etki alanını daraltmak için servis başına rolü savunur. İkisi de farklı baskılar altında doğrudur.

Çözüm, seçim yapmadan önce bağlayıcı kısıtı adlandırmaktır:

• Kısıt CloudFormation kaynak sayısı olduğunda, birleştirme doğru hamledir. Daha az rol, şablonda daha az kaynak demektir.
• Kısıt etki alanı ya da politika boyutu olduğunda, ayırma doğru hamledir. Daha fazla rol, daha küçük ve sıkı politikalar ile sınırlanmış hasar demektir.

Kapsamı daraltılmış paylaşılan bir örüntü ikisini de karşılar. Hizmet verdiği her iş yükünde gerçekten ortak olan izinleri taşıyan paylaşılan bir rol (diyelim dar, salt okunur bir gözlemlenebilirlik politikası) küçük ve düşük riskli kalırken yine de kaynak sayısını düşürür. Hiçbirini karşılamayan örüntü, herkesin ihtiyaçlarının birleşimini taşıyan mega-role’dür. Hem büyüktür, hem tehlikelidir, hem de yalnızca bir kaynak eksik sayılır. Gerçekten ortak olanı birleştirin; birleşimi asla birleştirmeyin.

Vermek mi, sınır koymak mı: izin sınırları ve SCP’ler

Yalnızca IAM kimlik ve kaynak politikaları izin verir. İzin sınırları ve SCP’ler asla izin vermez; verici politikaların aşamayacağı bir maksimum belirler. Etkin izin, uygulanan her katmanın kesişimidir ve bunlardan herhangi birindeki açık bir Deny kazanır.

İzin sınırları tek bir varlığı sınırlar. En değerli kullanımları yetki devriyle oluşturmadır: bir pipeline’a ya da ekibe rol ve kullanıcı oluşturma izni verdiğinizde, oluşturulan varlık birine AdministratorAccess eklense bile bir tavanı aşamasın diye bir sınır ekleyin. IAM belgeleri açıktır: bir izin sınırı “tek başına izin sağlamaz” ve etkin izinler, kimlik tabanlı politika ile sınırın kesişimidir.

Zorlama, yetki devredilen oluşturucunun kendi politikasındaki bir koşuldan gelir. Oluşturucu yalnızca sınırı taşıyan varlıklar oluşturabilir:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CreateRolesWithBoundary",
      "Effect": "Allow",
      "Action": ["iam:CreateRole", "iam:CreateUser"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::111122223333:policy/DelegatedBoundary"
        }
      }
    },
    {
      "Sid": "DenyBoundaryTampering",
      "Effect": "Deny",
      "Action": [
        "iam:DeleteRolePermissionsBoundary",
        "iam:DeleteUserPermissionsBoundary",
        "iam:PutRolePermissionsBoundary",
        "iam:PutUserPermissionsBoundary"
      ],
      "Resource": "*"
    }
  ]
}

StringEquals koşulu, oluşturulan her varlığı DelegatedBoundary taşımaya zorlar. Açık Deny, yetki devredilenin o sınırı sonradan kaldırmasını ya da yeniden yazmasını durdurur. Bir sınırın geniş olmasına meşru şekilde izin verilir, çünkü o kendi başına izin vermez, yalnızca tavan koyar. Dolayısıyla sınırın içindeki bir joker, kimlik politikasının içindeki bir jokerle aynı hata değildir.

SCP’ler bütün bir hesabı ya da organizasyon birimini (OU) sınırlar. AWS Organizations’ta bir SCP, her üye hesap genelinde mevcut maksimum izni belirler. Belgeler bunu doğrudan söyler: “Bir SCP tarafından hiçbir izin verilmez.” İzin vermek için yine IAM politikalarına ihtiyacınız var; SCP yalnızca seçenekleri kaldırır. Yazmaya değer iki istisna: SCP’ler yönetim hesabını etkilemez ve servise bağlı rolleri etkilemez.

SCP’ler, hiçbir hesabın asla geçersiz kılamayacağı organizasyon çapındaki kurallar için doğru katmandır: bir bölgeyi engellemek, bir hesabın organizasyondan ayrılmasını önlemek, CloudTrail’in devre dışı bırakılmasını reddetmek. Onları dikkatle ele alın. FullAWSAccess’i kaldırmak ya da org köküne test etmeden bir SCP eklemek, tüm organizasyon genelinde servis erişimini kilitleyebilir. Bir sandbox OU’su oluşturun, tek bir hesabı içeri taşıyın ve daha geniş açmadan önce doğrulayın.

Boyut baskısını gruplarla hafifletmek

Kullanıcı başına satır içi bütçe 2.048 karakterle küçüktür ve onu tüketmenin en hızlı yolu, aynı satır içi politikayı kırk kullanıcıya yapıştırmaktır. Her biri o kullanıcının bütçesini yiyen kırk kopya ve izin değiştiğinde hepsi aynı düzenlemeye ihtiyaç duyar.

Bunun yerine tek bir yönetilen politikayı bir IAM grubuna ekleyin ve kullanıcıları o gruba koyun. Güncellenecek tek bir belge ve hiçbir kullanıcıda satır içi boyut baskısı yok. Açıkça belirtilecek trade-off: gruplar yalnızca insan kullanıcılar içindir. Bir rol bir grubun üyesi olamaz ve servisler ile Lambda fonksiyonları kullanıcı değil rol üstlenir. Yani gruplar insan operatör yayılmasını çözer; iş yükleri için cevap yine aynı: dar kapsamlı rollerde sorumluluk başına politika.

Access Analyzer ile doğrulama

Yapı sizi limitlerden uzak tutar; doğrulama ise en az ayrıcalık konusunda dürüst tutar. IAM Access Analyzer’ın devreye almaya değer üç yeteneği var.

Politika doğrulaması bir politikayı dilbilgisi ve en iyi uygulamaya karşı denetler; bulgular, uyarılar, güvenlik uyarıları ve öneriler döndürür. Onu her politikada, tercihen CI içinde çalıştırın.

Özel politika kontrolleri bir pipeline içinde çalışır. check-no-new-access, önerilen bir değişikliğin bir referans politikadan daha fazlasını verip vermediğini yanıtlar; check-access-not-granted, bir politikanın listelenmiş kritik bir eyleme izin verip vermediğini yanıtlar. Bir pull request’e sızan bir jokeri yakalayan kontroller bunlardır. API çağrısı başına $0,0020 ücretlendirilir.

Kullanılmayan erişim analizörleri, kimsenin kullanmadığı rolleri, izinleri ve kimlik bilgilerini işaretler; böylece yıllık bir denetimde değil, sürekli olarak en az ayrıcalığa doğru budayabilirsiniz. Bu, analiz edilen IAM rolü ya da kullanıcısı başına ayda $0,20 ile varlık başına bir kalemdir; bu yüzden hangi hesaplarda çalışacağını sınırlayın. Dış erişim analizi (hesaplar arası ve genel maruziyet bulguları) ek ücret olmadan sağlanır.

Karar ağacı

Her IAM değişikliği aynı iki soruyla başlar: vermek mi sınırlamak mı, ve nereye ait. Aşağıdaki ağaç buradan köklenir.

Ağacın sıkıştırdığı birkaç dal durumu:

• Mevcut bir rolü başka bir serviste ya da ortamda yeniden mi kullanacaksınız? Varsayılan olarak yeni, dar kapsamlı bir role gidin. Yalnızca gerçek bir ortak salt okunur ihtiyaç için yeniden kullanın ve o zaman bile paylaşılan bir yazma rolü yerine paylaşılan bir politikayı tercih edin.
• Bir politika 6.144’e ya da bir varlık satır içi toplamına mı yaklaşıyor? Tek amaçlı yönetilen politikalara bölün ve tekrarlanan kullanıcı başına satır içi politikaları grup üzerinden eklenen bir yönetilen politikaya taşıyın.
• Bir rolde on eklenen yönetilen politikaya mı yaklaşıyorsunuz? Önce ilgili ifadeleri daha sıkı politikalarda birleştirin; yalnızca birleştirme gerçekten tükendiğinde yirmi beşe doğru artış talep edin.

Sık yapılan hatalar

Hata	Çözüm
Satır içi politika PutRolePolicy başarısız olana kadar büyür	Yönetilen politikalara bölün; rol satır içi toplamı 10.240 karakter
On birinci yönetilen politikanın eklenmesi başarısız olur	İlgili ifadeleri birleştirin; yalnızca gerçekten gerekliyse sınırı 25’e yükseltin
Bir SCP’nin izin verdiğini varsaymak	SCP yalnızca kaldırır; eşleşen IAM iznini ekleyin
”Şimdilik” joker Resource: "*"	ARN’leri baştan sınırlandırın; Access Analyzer nasılsa işaretler
Yetki devirli oluşturmada sınırı unutmak	Oluşturucuda iam:PermissionsBoundary koşuluyla zorlayın
Konsoldan elle verilen izinler	IaC’ye taşıyın; konsol kayması görünmez ve denetlenemezdir
Önizleme ortamlarının rol kotasını tüketmesi	Kotayı erkenden yükseltin ve bayat rolleri silin

Varsayılan belli: servis ve ortam başına dar kapsamlı birer rol ve üzerlerinde küçük, tek amaçlı politikalar. Bu varsayılanı esnetmeyi haklı çıkaran tek baskı CloudFormation kaynak sayısıdır; yukarıdaki kapsamı daraltılmış paylaşılan örüntü, mega-role’ü diriltmeden o durumu da karşılar. Geri kalan her yerde varsayılanı koruyun; ilk tablodaki limitler rahatça uzağınızda kalır.

Kaynaklar

• IAM and AWS STS quotas - Yönetilen politika 6.144 karakter limiti, satır içi toplamlar (kullanıcı 2.048 / grup 5.120 / rol 10.240), ekleme sınırları, hesap başına rol ve boşluk kuralı için yetkili kaynak
• Security best practices in IAM - En az ayrıcalık, yönetilen politikalarla başlayıp sıkılaştırma ve izin sınırları ile koşulları kullanma
• Permissions boundaries for IAM entities - Sınır bir grant değil bir tavandır; etkin izin kesişimdir; iam:PermissionsBoundary koşullu yetki devri örüntüsü
• Service control policies (SCPs) - “Bir SCP tarafından hiçbir izin verilmez”; yönetim hesabı ve servise bağlı rol istisnaları; FullAWSAccess uyarısı
• Managed policies and inline policies - Hangisinin ne zaman kullanılacağı ve yönetilen politikaların neden satır içine göre daha iyi ölçeklendiği
• IAM JSON policy evaluation logic - Kimlik, kaynak, sınır, SCP ve oturum politikaları genelinde izin ve reddin nasıl birleştiği ve açık reddin neden kazandığı
• Using IAM Access Analyzer - Dış erişim, kullanılmayan erişim, özel politika kontrolleri ve politika doğrulaması genel bakışı
• IAM Access Analyzer policy validation - CI içinde çalıştırılacak bulgular, uyarılar ve öneriler
• Creating an unused access analyzer - Kullanılmayan erişim bulgularının roller, izinler ve kimlik bilgileri genelinde neyi kapsadığı
• IAM Access Analyzer pricing - Dış erişim ücretsiz; kullanılmayan erişim IAM rolü ya da kullanıcısı başına ayda $0,20; özel politika kontrolleri API çağrısı başına $0,0020
• AWS Well-Architected Security Pillar: permissions management - En az ayrıcalık, izin korumaları ve izinleri sürekli azaltma
• IAM user groups - Kullanıcı başına satır içi yayılmayı hafifletmek için bir gruba yönetilen politika ekleme ve rollerin neden grup üyesi olamayacağı
• serverless-iam-roles-per-function eklentisi - Serverless Framework’te tek paylaşılan servis geneli execution role yerine fonksiyon seviyesinde IAM rol ifadeleri tanımlayan eklenti