Bir güvenlik mühendisi, tüm kullanıcıların erişimini engelleyen açık bir reddetme (explicit deny) içeren bir Amazon S3 bucket policy'si oluşturdu. Birkaç gün sonra, mühendis belirli bir çalışana salt okunur erişim izni veren yeni bir ifade (statement) ekledi. Çalışan hala Access Denied hatası alıyor. Bunun en olası nedeni nedir?

Doğru cevap, "Bucket policy'deki açık reddetme (explicit deny), izin verme ifadesini (allow statement) geçersiz kılar." çünkü AWS IAM değerlendirme mantığında, açık bir reddetme (explicit deny) her zaman açık bir izne (explicit allow) göre önceliklidir. Mühendis başlangıçta tüm erişimi engelleyen bir açık reddetme oluşturduğu için, daha sonra eklenen salt okunur izin verme ifadesi bu reddetmeyi geçersiz kılamaz. Çalışan hala reddetme kuralına takılmaktadır. Diğer seçenekler şunlardır: "Bucket ACL'sinin güncellenmesi gerekir." S3 bucket policy'leri genellikle ACL'lerden daha kapsamlıdır ve çoğu erişim kontrolü senaryosunda ACL'leri geçersiz kılar veya onlarla birlikte çalışır. Bu durumda bucket policy'deki bir çakışma daha olasıdır. "Kullanıcının IAM policy'si bucket'a erişime izin vermiyor." Bu mümkün olsa da, sorun bucket policy'nin kendisinde bir çakışma olduğu için birincil neden bu değildir. Bucket policy'deki açık reddetme, kullanıcının IAM policy'sinde izin olsa bile erişimi engelleyecektir. "Bucket policy değişikliklerinin yayılması (propagate) birkaç dakika sürer." AWS politikaları genellikle çok hızlı bir şekilde yayılır. Birkaç dakika bekleme süresi nadiren bu tür bir kalıcı "Access Denied" hatasının nedeni olur.