Harici ID ve Kafası Karışmış Vekil

Bir üçüncü tarafın hesabınızdaki bir rolü üstlenmesine izin verdiğinizde, şaşkın vekil sorunu adı verilen bir güvenlik riski ortaya çıkabilir. Dış kimlik, bunu önleyen basit ama hayati bir denetimdir. Bu model, bir SaaS sağlayıcısının AWS hesabınıza erişmesi gerektiğinde sınavda karşınıza çıkar.

Şaşkın vekil, bir saldırgan tarafından yetkisini onun adına kullanması için kandırılan güvenilir bir varlıktır (vekil). AWS'de üçüncü taraf bir hizmet, birçok müşteri hesabında rol üstlenme iznine sahip olabilir; isteği meşru müşteri ilişkisine bağlayan hiçbir şey yoksa saldırgan, hizmeti sizin rolünüzü üstlenmesi için kandırabilir.

Her müşteri hesabında bir rol üstlenen bir izleme SaaS hizmeti düşünün. SaaS, herkes için tek bir AWS kimliği kullanıyor. Aynı zamanda müşteri olan bir saldırgan rol ARN'nizi tahmin ederse, SaaS güvenilir sorumlu varlık olduğundan onu sizin rolünüzü üstlenmeye ikna edebilir. Bunu önlemek için yalnızca hesap kimliği yeterli değildir.

Dış kimlik, sağlayıcının sizin ilişkiniz için atadığı benzersiz ve gizli bir değerdir. Bu değeri rolünüzün güven politikasına koşul olarak eklersiniz ve sağlayıcı AssumeRole çağrısı yaparken aynı değeri eksiksiz biçimde sağlamalıdır. Saldırgan dış kimliğinizi bilmediği için sağlayıcıyı rolünüzü üstlenmesi için kandıramaz.

Bu güven politikası, eşleşen dış kimliği gerektirir. AssumeRole yalnızca sağlayıcı aynı değeri gönderdiğinde başarılı olur ve şaşkın vekil saldırısını engeller.

En önemli nokta şudur: sağlayıcı dış kimliği oluşturur ve denetler; müşteri değil. Bu, müşterilerin aynı değeri yeniden kullanmak üzere iş birliği yapmasını önler. AWS kılavuzu açıktır: üçüncü taraf olarak her müşteriye benzersiz bir dış kimlik atamalı ve her rol üstlenme işleminde bunun kullanılmasını zorunlu kılmalısınız.

Dış kimliğin parola gibi gizli tutulması amaçlanmaz; kurulum talimatlarında yer alabilir. Güvenlik değeri, her müşteri için benzersiz olmasından ve sağlayıcı tarafından denetlenmesinden gelir; böylece saldırgan vekile başka bir müşterinin değerini kullandıramaz. Bu değeri bir kimlik bilgisi olarak değil, kimliğe bürünmeyi önleyen bir belirteç olarak değerlendirin.

Dış kimlik, kimlerin rolü üstlenebileceğini denetler; ancak yine de rolün neler yapabileceğini sıkı izin politikalarıyla sınırlandırmanız gerekir. Doğru şekilde yetkilendirilmiş bir sağlayıcıya bile yalnızca gereken asgari izinleri verin. Güvenli üçüncü taraf erişimi için dış kimliği, belirli bir sorumlu varlığı ve en az ayrıcalıklı izinleri birlikte kullanın.

Şaşkın vekil modeli, sizin adınıza hareket eden AWS hizmetleri için de geçerlidir. Hizmetler arası güven, çağrıyı yapan hizmetin sizin kaynağınız adına hareket ettiğinden emin olmak için kaynak politikalarında genellikle aws:SourceArn ve aws:SourceAccount gibi koşul anahtarlarını kullanır. Bu, farklı bir biçimde uygulanan aynı savunma fikridir.

Bir soru, hesaplar arasında rol üstlenen bir üçüncü tarafı veya SaaS hizmetini anlatıyorsa güvenli yanıt neredeyse her zaman güven politikasında bir dış kimlik kullanılmasını içerir. Senaryo hizmetler arasındaysa bunun yerine aws:SourceArn/aws:SourceAccount koşullarını arayın. İpucunu tanımak sizi doğrudan doğru denetime yönlendirir.

Şaşkın vekil sorunu, saldırganın güvenilir bir üçüncü tarafı erişimini kötüye kullanması için kandırmasına olanak tanır. Her müşteri için benzersiz olan ve sağlayıcı tarafından denetlenen dış kimlik, AssumeRole çağrısında eşleşen bir değer gerektirerek bunu önler. AWS hizmetleri için aws:SourceArn ve aws:SourceAccount kullanın. Bunları her zaman en az ayrıcalıklı izinlerle birleştirin.

Şaşkın vekil kavramını test edin.

Şaşkın vekil sorunu, güvenilir bir üçüncü tarafın hesaplar arası erişimini kötüye kullanması için kandırılmasıyla ortaya çıkar. Her müşteri için benzersiz olan ve sağlayıcı tarafından denetlenen dış kimlik, sts:ExternalId için güven politikası koşulu kullanılarak bunu önler. AWS hizmetleri arasındaki güven için aws:SourceArn ve aws:SourceAccount kullanın ve her zaman en az ayrıcalık ilkesini uygulayın.