Güven İlişkisi İlkeleri ve Kimlerin AssumeRole Kullanabileceği

Güven politikası, bir role eklenen ve hangi asıl varlıkların rolü üstlenmesine izin verildiğini tam olarak tanımlayan belgedir. Bu politika kapı bekçisi görevi görür: bir izin politikası güçlü erişim verse bile güven politikası onları adlandırmadıkça hiç kimse rolü kullanamaz. Sınavda güven politikası hataları, hem erişimin bozulmasının hem de tehlikeli ölçüde geniş izinler verilmesinin sık görülen nedenlerindendir.

Bir güven politikasının Principal öğesi şunlara başvurabilir:

• AWS — bir hesap, kullanıcı veya rol ARN'si (Amazon Resource Name).
• Service — lambda.amazonaws.com gibi bir AWS hizmeti.
• Federated — bir SAML sağlayıcısı veya web kimliği sağlayıcısı.

Doğru asıl varlık türünü seçmek ve yeterince belirli olmak, amaçlanandan daha geniş bir güven ilişkisi vermemek için çok önemlidir.

Hesaplar arası rol üstlenme için her iki tarafın da onay vermesi gerekir. Hedef hesaptaki rolün güven politikası çağrıyı yapan asıl varlığa izin vermeli ve bu asıl varlığın kimlik politikası da rolün ARN'si üzerinde sts:AssumeRole eylemine izin vermelidir. Bu iki parçadan biri eksikse istek engellenir. Bu iki yönlü el sıkışma, klasik bir sınav tuzağıdır.

Bu güven politikası, 111122223333 hesabındaki belirli bir rolün bu rolü üstlenmesine izin verir. Tüm hesap yerine tam ARN'yi belirtmek daha sıkı ve daha güvenlidir.

Bir asıl varlığı arn:aws:iam::ACCOUNT:root olarak belirtmek, hesabın tamamına güvenmek anlamına gelir: orada bulunan ve sts:AssumeRole iznine de sahip olan herhangi bir asıl varlık rolü üstlenebilir. Bu kapsamlı bir yetkidir. Mümkün olduğunda, en az ayrıcalık ilkesine uymak ve güven yüzeyini daraltmak için tam kullanıcı veya rol ARN'sini adlandırın.

Güven politikaları, rolü kimin ve hangi koşullarda üstlenebileceğini sıkılaştıran Condition bloklarını destekler. Yaygın anahtarlar arasında sts:ExternalId (şaşkın vekil sorununu önlemek için), aws:MultiFactorAuthPresent (MFA gerektirmek için) ve aws:SourceIp bulunur. Koşullar, rol üstlenme iznini yalnızca belirli ve doğrulanabilir durumlarda vermenizi sağlar.

Güçlü bir yaklaşım, hassas bir rol üstlenilmeden önce MFA gerektirmektir. Güven politikası koşulu, çağrıyı yapan oturumun MFA ile doğrulanıp doğrulanmadığını denetler. Böylece çalınmış uzun süre geçerli bir kimlik bilgisi bile ikinci faktör olmadan ayrıcalıklı rolü üstlenemez ve saldırganlar için çıta önemli ölçüde yükselir.

Bazı roller, AWS tarafından önceden tanımlanan ve güven politikasını düzenleyemediğiniz hizmete bağlı rollerdir. Bir hizmetin kaynakları, AWS'nin gerektirdiği güven ilişkisiyle tam olarak yönetmesine olanak tanırlar. İzinleri ve güven ilişkileri sıkı biçimde denetlendiği ve hizmetin yaşam döngüsüne bağlı olduğu için bu rolleri tanımak önemlidir.

Dahili bir asıl varlığa (aynı hesap içindeki bir varlığa) güvenmek, genellikle harici bir hesaba veya üçüncü taraf bir SaaS sağlayıcısına güvenmekten daha düşük risklidir. Harici güven ilişkilerinde, belirli bir asıl varlığı her zaman ExternalId gibi koşullarla birlikte kullanın. Her harici güven ifadesini, saldırganların istismar etmeyi çok isteyeceği bir giriş noktası olarak değerlendirin.

IAM Access Analyzer, harici hesapların veya genel kullanıcıların üstlenebileceği rolleri bulmak için güven politikalarını ve kaynak politikalarını otomatik olarak inceler. İstenmeyen hesaplar arası veya genel güven ilişkilerini işaretleyerek bunları sıkılaştırmanıza yardımcı olur. Access Analyzer bulgularını incelemek, aşırı geniş güven ilişkilerini yakalamak için önerilen ve sınav açısından önemli bir denetimdir.

Güveni güvenli biçimde tasarlamak için mümkün olan en belirli asıl varlığı adlandırın, uygun olduğunda ExternalId ve MFA gibi koşullar ekleyin, hesap köküne güvenmek yerine rolleri tercih edin ve Access Analyzer ile inceleyin. Güven politikasının kim sorusunu, izin politikalarının ise ne sorusunu yanıtladığını unutmayın; erişimin çalışması ve en az ayrıcalıkla sınırlı kalması için ikisi de uyumlu olmalıdır.

Güven politikaları konusundaki bilginizi sınayın.

Bir güven politikası, hangi asıl varlıkların bir rolü üstlenebileceğini tanımlar ve izin politikalarından bağımsız olarak kapı bekçisi görevi görür. Hesaplar arası rol üstlenme, iki yönlü el sıkışma gerektirir: güven politikası ve çağrıyı yapan tarafın sts:AssumeRole izni. Hesap kökü yerine belirli asıl varlık ARN'lerini tercih edin, ExternalId ve MFA gibi koşullar ekleyin ve IAM Access Analyzer ile denetim yapın.