Örnek sorular
Aws Iam SecurityZorluk 1
Bir IAM role'ü kimlerin assume edebileceğini hangi policy belirler?
- aRole'ün permissions boundary'si
- bTek başına, çağırana ekli herhangi bir identity policy
- cRole'ün trust policy'si✓
- dHesabın password policy'si
Açıklama:Bir role'ün trust policy'si, o role için bir STS role-assumption işlemini çağırmasına izin verilen principal veya servisleri adlandıran resource-based policy'dir. Role'ün identity policy'leri, assume edilmiş session'ın sonradan ne yapabileceğini belirler; permissions boundary izinleri sınırlar fakat güven ilişkisi kurmaz.
Aws Iam SecurityZorluk 1
Identity-based bir IAM policy statement'ında neye izin verildiğini veya neyin reddedildiğini hangi öğeler tanımlar?
- aRegion, hesap alias'ı, servis endpoint'i ve credential profili
- bUser, Group, Role, Policy
- cEffect, Action, Resource ve isteğe bağlı Condition✓
- dEncrypt, Decrypt, Sign, Verify
Açıklama:Identity-based bir policy statement Effect, Action ve Resource ile isteğe bağlı Condition kullanır. Bağlı kimlik zaten principal olduğu için Principal kullanılmaz; bu öğe resource-based policy ve role trust policy içinde kullanılır.
Aws Iam SecurityZorluk 2
Aynı erişime ihtiyaç duyan 30 geliştiriciye aynı IAM izin setini vermenin önerilen yolu nedir?
- aIAM Identity Center üzerinden federasyon kullanmak ve geliştiricilere hesap için paylaşılan bir permission set atamak✓
- bAynı inline policy'yi 30 ayrı IAM user'ın her birine kopyala
- cBir IAM user'ın access key'lerini 30 geliştirici arasında paylaş
- dPolicy'yi doğrudan AWS hesap root user'ına bağlamak ve her geliştiricinin aynı root hesabıyla giriş yapmasını sağlamak
Açıklama:AWS, insan kullanıcıların AWS'e federasyon ve geçici credential'larla erişmesini önerir; IAM Identity Center bu amaçla merkezi hesap erişimi ve yeniden kullanılabilir permission set'ler sağlar. Inline policy'leri 30 IAM user'a kopyalamak bakımı zorlaştırır, credential paylaşmak kişi bazında denetlenebilirliği yok eder ve root'u günlük kullanmak güvenli değildir.
Aws Iam SecurityZorluk 1
AWS hesabının root user'ı için TEK en önemli güvenlik adımı hangisidir?
- aRoot user'ın parolasını her 24 saatte bir değiştirmek
- bOtomasyonun kullanabilmesi için root user'a uzun-ömürlü access key'ler oluşturmak
- c
AdministratorAccess managed policy'sini doğrudan root user'a eklemek - dMFA'yı etkinleştirip root user'ı günlük işlerde kullanmamak✓
Açıklama:AWS, root user'da MFA'yı etkinleştirmeyi, root access key oluşturmaktan kaçınmayı ve root'u yalnızca onu gerektiren az sayıdaki hesap-seviyesi görev için kullanmayı önerir. İnsan kullanıcılar normalde federasyonla, tercihen IAM Identity Center üzerinden merkezi olarak erişmeli ve least-privilege izinli geçici role credential'ları almalıdır. Root zaten tam hesap erişimine sahiptir; AdministratorAccess eklemek gereksiz, root access key'i oluşturmak ise ek risktir.
Aws Iam SecurityZorluk 2
Uygulamaların instance metadata servisinden geçici credential alabilmesi için bir IAM role, EC2 instance'a nasıl eklenir?
- aIAM role'ü içeren bir instance profile aracılığıyla✓
- bYalnızca role ARN'ini instance'ın user-data script'ine koyarak
- cRole'ün trust policy'sini doğrudan network interface'e ekleyerek
- dInstance başladıktan sonra role'ü bir IAM user'a dönüştürerek
Açıklama:EC2, bir role'ü instance ile instance profile aracılığıyla ilişkilendirir. EC2 metadata servisi daha sonra instance üzerindeki SDK'lara bu role için geçici credential sağlayabilir. User data ve network interface bu IAM ilişkisini kurmaz; role'ler user'a dönüştürülmez.
Aws Iam SecurityZorluk 1
Varsayılan olarak, hiç policy eklenmemiş bir IAM user herhangi bir AWS API'sini çağırmaya çalıştığında ne olur?
- aBir policy açıkça izin vermedikçe istek reddedilir✓
- bİstek varsayılan olarak salt-okunur erişimle başarılı olur
- cİstek başarılı olur çünkü IAM bir Deny eklenene kadar tüm eylemlere izin vermeyi varsayar
- dİstek otomatik olarak hesap root user'ının izinlerine yönlendirilir
Açıklama:IAM'in temel kuralı varsayılan-deny'dir: bir policy açıkça bir eylemi izin vermedikçe reddedilir. Örtük salt-okunur veya tam-erişim varsayılanı yoktur (b, c yanlış), ve izinler asla sessizce root user'dan miras alınmaz (d yanlış) — her principal'ın erişimi kendi eklenmiş/inline policy'leriyle tanımlanır.