Turkish - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - Basic Information

htARTE (HackTricks AWS Kırmızı Takım Uzmanı) ile sıfırdan kahraman olmak için AWS hackleme öğrenin!

HackTricks'i desteklemenin diğer yolları:

Kuruluş Hiyerarşisi

Hesaplar

AWS'de, kuruluşunuzun tüm hesaplarının ebeveyn konteyneri olan bir kök hesap bulunmaktadır. Bununla birlikte, kaynakları dağıtmak için bu hesabı kullanmanıza gerek yoktur, farklı AWS altyapılarını birbirinden ayırmak için başka hesaplar oluşturabilirsiniz.

Bu, bir güvenlik açısından çok ilginçtir, çünkü bir hesap diğer hesapların kaynaklarına erişemez (özel olarak oluşturulmadıkça), bu şekilde dağıtımlar arasında sınırlar oluşturabilirsiniz.

Bu nedenle, bir kuruluşta iki tür hesap bulunur (AWS hesaplarından ve Kullanıcı hesaplarından bahsediyoruz): yönetim hesabı olarak belirlenen tek bir hesap ve bir veya daha fazla üye hesap.

  • Yönetim hesabı (kök hesap), kuruluşu oluşturmak için kullandığınız hesaptır. Kuruluşun yönetim hesabından aşağıdaki işlemleri yapabilirsiniz:

  • Kuruluşta hesap oluşturma

  • Kuruluşa diğer mevcut hesapları davet etme

  • Hesapları kuruluştan kaldırma

  • Davetleri yönetme

  • Kuruluş içindeki varlıklara (kökler, OU'lar veya hesaplar) politikalar uygulama

  • Desteklenen AWS hizmetleriyle entegrasyonu etkinleştirerek tüm hesaplarda hizmet işlevselliği sağlama.

  • Bu kök kullanıcı olarak giriş yapmak, bu kök hesap/organizasyonu oluşturmak için kullanılan e-posta ve şifre ile mümkündür.

Yönetim hesabı, bir ödeme hesabının sorumluluklarını üstlenir ve üye hesapların biriktirdiği tüm ücretleri ödemekten sorumludur. Bir kuruluşun yönetim hesabını değiştiremezsiniz.

  • Üye hesaplar, bir kuruluşun geri kalan tüm hesaplarını oluşturur. Bir hesap aynı anda yalnızca bir kuruluşun üyesi olabilir. Bir hesaba bir politika ekleyerek yalnızca o hesaba kontroller uygulayabilirsiniz.

  • Üye hesaplar geçerli bir e-posta adresi kullanmalı ve bir isim sahip olabilir, genel olarak faturalandırmayı yönetemezler (ancak erişime sahip olabilirler).

aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com

Organizasyon Birimleri

Hesaplar Organizasyon Birimleri (OU) içinde gruplandırılabilir. Böylece, Organizasyon Birimi için politikalar oluşturabilir ve bu politikaların tüm alt hesaplara uygulanmasını sağlayabilirsiniz. Unutmayın ki bir OU, diğer OU'ları alt birim olarak içerebilir.

# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU

Hizmet Kontrol Politikası (SCP)

Bir hizmet kontrol politikası (SCP), SCP'nin etkilendiği hesaplardaki kullanıcıların ve rollerin kullanabileceği hizmetleri ve eylemleri belirleyen bir politikadır. SCP'ler, IAM izin politikalarına benzer ancak herhangi bir izin vermezler. Bunun yerine, SCP'ler bir kuruluş, organizasyon birimi (OU) veya hesap için maksimum izinleri belirtir. Bir SCP'yi kuruluş köküne veya bir OU'ya eklediğinizde, SCP, üye hesaplardaki varlıklar için izinleri sınırlar.

Bu, kök kullanıcının bile durdurulabileceği tek yoldur. Örneğin, kullanıcıların CloudTrail'i devre dışı bırakmasını veya yedeklemeleri silmesini engellemek için kullanılabilir. Bunu atlamak için, SCP'leri yapılandıran ana hesabın da ele geçirilmesi gerekmektedir (ana hesap engellenemez).

SCPler yalnızca hesaptaki ilgili kişileri kısıtlar, bu nedenle diğer hesaplar etkilenmez. Bu, bir SCP'nin s3:GetObject reddini kullanmanın, hesabınızdaki genel bir S3 kovasına erişimi durdurmaya yetmeyeceği anlamına gelir.

SCP örnekleri:

  • Kök hesabı tamamen reddet

  • Yalnızca belirli bölgelere izin ver

  • Yalnızca beyaz listelenen hizmetlere izin ver

  • GuardDuty, CloudTrail ve S3 Genel Blok Erişimini devre dışı bırakmayı reddet

  • Güvenlik/olay yanıt rollerinin silinmesini veya değiştirilmesini reddet

  • Yedeklemelerin silinmesini reddet

  • IAM kullanıcıları ve erişim anahtarları oluşturmayı reddet

JSON örneklerini https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html adresinde bulabilirsiniz.

ARN

Amazon Kaynak Adı (ARN), AWS içindeki her kaynağın benzersiz adıdır ve aşağıdaki gibi oluşturulur:

arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env

AWS'de 4 bölüm bulunmaktadır, ancak bunları çağırmak için sadece 3 yol vardır:

  • AWS Standart: aws

  • AWS Çin: aws-cn

  • AWS ABD halka açık İnternet (GovCloud): aws-us-gov

  • AWS Gizli (US Sınıflandırılmış): aws

IAM - Kimlik ve Erişim Yönetimi

IAM, AWS hesabınız içinde Kimlik Doğrulama, Yetkilendirme ve Erişim Kontrolü yönetmenize olanak sağlayan bir hizmettir.

  • Kimlik Doğrulama - Bir kimliği tanımlama ve bu kimliğin doğrulanması sürecidir. Bu süreç, Tanımlama ve Doğrulama olarak alt bölümlere ayrılabilir.

  • Yetkilendirme - Bir kimliğin doğrulandıktan sonra bir sistem içinde neye erişebileceğini belirler.

  • Erişim Kontrolü - Güvenli bir kaynağa erişimin nasıl ve hangi süreçte sağlandığıdır.

IAM, AWS hesabınızdaki kaynaklarınıza kimliklerin kimlik doğrulama, yetkilendirme ve erişim kontrol mekanizmalarını yönetme, kontrol etme ve yönetme yeteneğiyle tanımlanabilir.

AWS hesabı kök kullanıcısı

Amazon Web Services (AWS) hesabı oluşturduğunuzda, hesapta tüm AWS hizmetlerine ve kaynaklarına tam erişime sahip olan tek bir oturum açma kimliğiyle başlarsınız. Bu, AWS hesabının kök kullanıcısı olarak adlandırılır ve hesabı oluşturmak için kullandığınız e-posta adresi ve şifreyle oturum açılarak erişilir.

Yeni bir yönetici kullanıcının, kök kullanıcıdan daha az izne sahip olacağını unutmayın.

Güvenlik açısından, başka kullanıcılar oluşturmanız ve bunu kullanmaktan kaçınmanız önerilir.

IAM kullanıcıları

IAM kullanıcısı, AWS'de oluşturduğunuz ve AWS ile etkileşimde bulunan kişiyi veya uygulamayı temsil eden bir varlıktır. AWS'deki bir kullanıcı adı ve kimlik bilgileri (şifre ve en fazla iki erişim anahtarı) içerir.

Bir IAM kullanıcısı oluşturduğunuzda, uygun izin politikalarına sahip bir kullanıcı grubunun bir üyesi yaparak izinler verirsiniz (önerilen) veya kullanıcıya doğrudan politikalar ekleyerek izinler verirsiniz.

Kullanıcılar, konsol üzerinden giriş yapmak için MFA etkinleştirilebilir. MFA etkinleştirilmiş kullanıcıların API anahtarları MFA tarafından korunmaz. Kullanıcıların API anahtarlarının erişimini MFA kullanarak sınırlamak istiyorsanız, belirli eylemleri gerçekleştirmek için politikada MFA'nın bulunması gerektiğini belirtmeniz gerekir (örnek burada).

CLI

  • Erişim Anahtarı Kimliği: AKHDNAPO86BSHKDIRYT gibi 20 rastgele büyük harf ve sayı kombinasyonu

  • Gizli erişim anahtarı kimliği: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU gibi 40 rastgele büyük ve küçük harf kombinasyonu (kaybolan gizli erişim anahtarı kimlikleri geri alınamaz).

Erişim Anahtarını değiştirmeniz gerektiğinde izlemeniz gereken süreç şudur: Yeni bir erişim anahtarı oluştur -> Yeni anahtarı sisteme/uygulamaya uygula -> orijinalini etkisizleştir olarak işaretle -> Yeni erişim anahtarının çalıştığını test et ve doğrula -> Eski erişim anahtarını sil

MFA - Çoklu Faktör Kimlik Doğrulama

Bu, mevcut yöntemlerinize (şifre gibi) ek olarak kimlik doğrulama için ek bir faktör oluşturmak için kullanılır, böylece çok faktörlü bir kimlik doğrulama seviyesi oluşturulur. Ücretsiz bir sanal uygulama veya fiziksel bir cihaz kullanabilirsiniz. AWS'de bir MFA etkinleştirmek için ücretsiz olarak google kimlik doğrulama gibi uygulamaları kullanabilirsiniz.

MFA koşullarına sahip politikalar aşağıdakilere eklenir:

  • Bir IAM kullanıcısı veya grup

  • Bir Amazon S3 kovası, Amazon SQS kuyruğu veya Amazon SNS konusu gibi bir kaynak

  • Bir kullanıcı tarafından alınabilecek bir IAM rolünün güven politikası

MFA kontrolü yapan bir kaynağa CLI üzerinden erişmek isterseniz, GetSessionToken çağrısı yapmanız gerekir. Bu, MFA hakkında bilgi içeren bir belirteç verir. AssumeRole kimlik bilgileri bu bilgiyi içermez.

aws sts get-session-token --serial-number <arn_device> --token-code <code>

Burada belirtildiği gibi, MFA'nın kullanılamadığı birçok farklı durum vardır.

IAM kullanıcı grupları

IAM kullanıcı grubu, birden fazla kullanıcıya aynı anda politikaları eklemek için bir yol sağlar, bu da bu kullanıcıların izinlerini yönetmeyi kolaylaştırabilir. Roller ve gruplar bir grubun parçası olamaz.

Bir kimlik tabanlı politikayı bir kullanıcı grubuna ekleyebilirsiniz, böylece kullanıcı grubundaki tüm kullanıcılar politikanın izinlerini alır. Bir kullanıcı grubunu (örneğin bir kaynak tabanlı politika gibi) bir Principal olarak tanımlayamazsınız çünkü gruplar izinlerle ilgilidir, kimlik doğrulama ile ilgili değildir ve prensipler kimlik doğrulanan IAM varlıklarıdır.

İşte kullanıcı gruplarının bazı önemli özellikleri:

  • Bir kullanıcı grubu, birçok kullanıcıyı içerebilir ve bir kullanıcı, birden fazla gruba ait olabilir.

  • Kullanıcı grupları iç içe olamaz; sadece kullanıcıları, başka kullanıcı gruplarını içeremezler.

  • AWS hesabındaki tüm kullanıcıları otomatik olarak içeren bir varsayılan kullanıcı grubu yoktur. Böyle bir kullanıcı grubuna sahip olmak istiyorsanız, bunu oluşturmalı ve her yeni kullanıcıyı buna atamalısınız.

  • Bir AWS hesabındaki IAM kaynaklarının sayısı ve boyutu, grupların sayısı ve bir kullanıcının üye olabileceği grupların sayısı gibi, sınırlıdır. Daha fazla bilgi için IAM ve AWS STS kotaları'na bakın.

IAM rolleri

Bir IAM rolü, AWS'de ne yapabileceğini ve yapamayacağını belirleyen izin politikalarına sahip bir kullanıcı gibi çok benzerdir. Ancak, bir rolün herhangi bir kimlik bilgisi (parola veya erişim anahtarları) ile ilişkili değildir. Bir kişiyle benzersiz olarak ilişkilendirilmek yerine, bir rol, ihtiyacı olan herhangi bir kişi tarafından geçici olarak üstlenilebilir (ve yeterli izinlere sahip olabilir). Bir IAM kullanıcısı, belirli bir görev için farklı izinleri geçici olarak üstlenebilir. Bir rol, IAM yerine harici bir kimlik sağlayıcı kullanarak oturum açan bir federasyon kullanıcısına atanabilir.

Bir IAM rolü, iki tür politikadan oluşur: Boş olamayan bir güven politikası, rolü kimin üstlenebileceğini tanımlayan ve boş olamayan bir izin politikası, rolün neye erişebileceğini tanımlayan.

AWS Güvenlik Kimlik Doğrulama Hizmeti (STS)

AWS Güvenlik Kimlik Doğrulama Hizmeti (STS), sınırlı ayrıcalıklı geçici kimlik bilgilerinin verilmesini kolaylaştıran bir web hizmetidir. Özellikle şunlar için uyarlanmıştır:

IAM'deki geçici kimlik bilgileri

Geçici kimlik bilgileri çoğunlukla IAM rolleriyle kullanılır, ancak başka kullanımları da vardır. Standart IAM kullanıcınızın izinlerinden daha kısıtlı bir izin setine sahip geçici kimlik bilgileri isteyebilirsiniz. Bu, daha kısıtlı kimlik bilgileriyle izin verilmeyen görevleri yanlışlıkla gerçekleştirmenizi engeller. Geçici kimlik bilgilerinin bir avantajı, kimlik bilgilerinin belirli bir süre sonra otomatik olarak süresinin dolmasıdır. Kimlik bilgilerinin geçerli olduğu süreyi kontrol edebilirsiniz.

Politikalar

Politika İzinleri

İzinleri atamak için kullanılır. İki tür vardır:

  • AWS tarafından önceden yapılandırılmış yönetilen politikalar

  • Müşteri tarafından yapılandırılan politikalar: Siz tarafından yapılandırılır. AWS tarafından önceden yapılandırılmış politikalara dayalı politikalar oluşturabilirsiniz (birini değiştirerek ve kendi politikanızı oluşturarak), politika oluşturucuyu (izinleri verme ve reddetme konusunda size yardımcı olan bir GUI görünümü) veya kendi politikanızı yazarak.

Varsayılan erişim reddedilir, açık bir rol belirtilmişse erişim sağlanır. Tek bir "Reddetme" varsa, "İzin Ver"i geçersiz kılar, yalnızca AWS hesabının kök güvenlik kimlik bilgilerini kullanan istekler için (varsayılan olarak izin verilenler) geçerlidir.

{
"Version": "2012-10-17",  //Version of the policy
"Statement": [  //Main element, there can be more than 1 entry in this array
{
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
"Effect": "Allow", //Allow or deny
"Action": [  //Actions that will be allowed or denied
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": [ //Resource the action and effect will be applied to
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": { //Optional element that allow to control when the permission will be effective
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
}
}
]
}

Global alanlar, herhangi bir hizmet için koşullar için kullanılabilecek belgeler burada belgelenmiştir. Hizmet başına koşullar için kullanılabilecek belirli alanlar burada belgelenmiştir.

Satır İçi İzinler

Bu tür politikalar, bir kullanıcıya, gruba veya role doğrudan atanır. Ardından, diğerleri gibi Politikalar listesinde görünmezler. Satır içi politikalar, bir politika ile uygulanan kimlik arasında katı bir birbirine karşılık ilişkisini sürdürmek isterseniz kullanışlıdır. Örneğin, bir politikadaki izinlerin yanlışlıkla amaçlanan kimlik yerine başka bir kimliğe atandığından emin olmak istersiniz. Bir satır içi politika kullandığınızda, politikadaki izinler yanlışlıkla yanlış kimliğe eklenemez. Ayrıca, AWS Yönetim Konsolu'nu kullanarak o kimliği silerseniz, kimliğe gömülü politikalar da silinir. Çünkü bunlar temel varlık parçasıdır.

Kaynak Kova Politikaları

Bunlar, kaynaklarda tanımlanabilen politikalardır. AWS'nin tüm kaynakları bunları desteklemez.

Bir ilgiliye açık bir reddi olmadığı ve bir kaynak politikası onlara erişim izni verdiği sürece, izin verilirler.

IAM Sınırları

IAM sınırları, bir kullanıcının veya rolün erişimine sınırlama getirmek için kullanılabilir. Bu şekilde, farklı bir politika tarafından kullanıcıya verilen farklı bir izin kümesi olsa bile, işlem başarısız olur ve kullanmaya çalışırsa.

Bir sınırlama, kullanıcıya eklenen bir politika yalnızca kullanıcının veya rolün sahip olabileceği maksimum izin seviyesini belirtir. Yani, kullanıcının Yönetici erişimi olsa bile, sınırlama onun yalnızca S3 kovalarını okuyabileceğini belirtiyorsa, yapabileceği maksimum budur.

Bu, SCPs ve en az ayrıcalık ilkesini takip etmek, kullanıcıların ihtiyaçlarından daha fazla izne sahip olmadığından emin olmanın yollarıdır.

Oturum Politikaları

Bir oturum politikası, bir rolün bir oturumda varsayıldığı zaman ayarlanan bir politikadır. Bu, oturum politikasının izinleri vermez, ancak politikada belirtilenlere kısıtlar (maksimum izinler rolün sahip olduğu izinlerdir).

Bu, güvenlik önlemleri için kullanışlıdır: Bir yönetici çok ayrıcalıklı bir rolü varsaydığında, oturum politikasında yalnızca politikada belirtilen izinlere sınırlama getirebilir, böylece oturum tehlikeye atıldığında sadece belirtilen izinlere sahip olur.

aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]

Not: Varsayılan olarak, AWS üçüncü nedenlerden dolayı oluşturulacak oturumlar için oturum politikaları ekleyebilir. Örneğin, kimlik doğrulaması yapılmamış cognito varsayılan rollerinde (gelişmiş kimlik doğrulama kullanarak) AWS, oturum politikası ile oturum kimlik bilgileri oluşturur ve bu oturumun erişebileceği hizmetleri aşağıdaki listede sınırlar.

Bu nedenle, "... çünkü hiçbir oturum politikası izin vermiyor ..." hatasıyla karşılaşırsanız ve rolün eylemi gerçekleştirmek için erişimi varsa, bunun nedeni bir oturum politikasının engellemesidir.

Kimlik Federasyonu

Kimlik federasyonu, AWS'ye dış kaynaklı kimlik sağlayıcılardan gelen kullanıcıların AWS kaynaklarına güvenli bir şekilde erişmesine olanak tanırken geçerli bir IAM kullanıcı hesabından AWS kullanıcı kimlik bilgilerini sağlamadan erişmelerini sağlar. Bir kimlik sağlayıcının bir örneği, kendi kurumsal Microsoft Active Directory'niz (SAML aracılığıyla) veya OpenID hizmetleri (örneğin Google) olabilir. Federasyon erişimi, içindeki kullanıcıların AWS'ye erişmesine izin verir.

Bu güveni yapılandırmak için, IAM Kimlik Sağlayıcı oluşturulur (SAML veya OAuth) ve diğer platforma güven sağlar. Ardından, en az bir IAM rolü (güvenen) Kimlik Sağlayıcıya atanır. Güvenilen platformdan bir kullanıcı AWS'ye erişirse, belirtilen rol olarak erişecektir.

Ancak genellikle üçüncü taraf platformdaki kullanıcının grubuna bağlı olarak farklı bir rol vermek isteyeceksiniz. Ardından, birkaç IAM rolü üçüncü taraf Kimlik Sağlayıcıya güvenebilir ve üçüncü taraf platform, kullanıcıların bir rolü veya diğerini üstlenmesine izin veren taraftır.

IAM Kimlik Merkezi

AWS IAM Kimlik Merkezi (AWS Single Sign-On'un halefi), AWS Kimlik ve Erişim Yönetimi (IAM) yeteneklerini genişleterek, kullanıcıların AWS hesaplarına ve bulut uygulamalarına erişimlerini yöneten kullanıcıların yönetimini bir araya getiren merkezi bir yer sağlar.

Giriş alanı <kullanıcı_girişi>.awsapps.com gibi bir şey olacak.

Kullanıcıları giriş yapmak için kullanılabilecek 3 kimlik kaynağı vardır:

  • Kimlik Merkezi Dizini: Normal AWS kullanıcıları

  • Active Directory: Farklı bağlayıcıları destekler

  • Harici Kimlik Sağlayıcı: Tüm kullanıcılar ve gruplar harici bir Kimlik Sağlayıcıdan gelir (IdP)

Kimlik Merkezi dizini durumunda, Kimlik Merkezi bir kullanıcılar ve gruplar listesine sahip olacak ve bunlara kuruluşun tüm hesaplarından herhangi birine politikalar atayabilecektir.

Kimlik Merkezi kullanıcı/grubuna bir hesaba erişim vermek için, Kimlik Merkezine güvenen bir SAML Kimlik Sağlayıcı oluşturulacak ve belirtilen politikalarla birlikte Kimlik Sağlayıcıya güvenen bir rol hedef hesapta oluşturulacaktır.

AwsSSOInlinePolicy

IAM Kimlik Merkezi aracılığıyla oluşturulan roller için inline politikalar aracılığıyla izinler vermek mümkündür. AWS Kimlik Merkezi'nde inline politikalarla verilen hesaplarda oluşturulan roller, bu izinlere sahip olacaktır ve bu izinler AwsSSOInlinePolicy adlı bir inline politikada bulunacaktır.

Bu nedenle, AwsSSOInlinePolicy adında bir inline politikaya sahip 2 rol görürseniz, aynı izinlere sahip olmadığı anlamına gelir.

Hesaplar Arası Güven ve Roller

Bir kullanıcı (güvenen), bazı politikalarla birlikte Hesaplar Arası Rol oluşturabilir ve ardından, başka bir kullanıcıya (güvenilen) hesabına erişim izni verebilir, ancak yalnızca yeni rol politikalarında belirtilen erişime sahip olur. Bunun için sadece yeni bir Rol oluşturmanız ve Hesaplar Arası Rol'ü seçmeniz yeterlidir. Hesaplar Arası Erişim için iki seçenek sunar. Sahip olduğunuz AWS hesapları arasında erişim sağlamak ve sahip olduğunuz bir hesap ile üçüncü taraf bir AWS hesabı arasında erişim sağlamak. Bu güveni oluşturmak için güvenilen kullanıcıyı belirtmek ve bazı genel bir şeyler koymamak önerilir, çünkü aksi takdirde federasyon kullanıcıları gibi diğer kimlik doğrulanan kullanıcılar da bu güveni kötüye kullanabilir.

AWS Basit AD

Desteklenmeyenler:

  • Güven İlişkileri

  • AD Yönetim Merkezi

  • Tam PS API desteği

  • AD Geri Dönüşüm Kutusu

  • Grup Yönetilen Hizmet Hesapları

  • Şema Uzantıları

  • İşletim Sistemine veya Örneklerine Doğrudan Erişim Yok

Web Federasyonu veya OpenID Kimlik Doğrulama

Uygulama, geçici kimlik bilgileri oluşturmak için AssumeRoleWithWebIdentity'yi kullanır. Bununla birlikte, bu, AWS konsoluna erişim sağlamaz, yalnızca AWS içindeki kaynaklara erişim sağlar.

Diğer IAM seçenekleri

  • Minimum uzunluk ve şifre gereksinimleri gibi seçeneklerle bir şifre politikası ayarlayabilirsiniz.

  • Mevcut kimlik bilgileri hakkında bilgi içeren "Kimlik Bilgileri Raporunu" indirebilirsiniz (kullanıcı oluşturma zamanı, şifre etkin mi...). Kimlik bilgileri raporu, en fazla dört saatte bir olmak üzere sık sık oluşturulabilir.

AWS Kimlik ve Erişim Yönetimi (IAM), tüm AWS hizmetlerine yönelik inceden inceye erişim kontrolü sağlar. IAM ile kimin hangi hizmetlere ve kaynaklara erişebileceğini ve hangi koşullar altında belirleyebilirsiniz. IAM politikaları ile iş gücünüz ve sistemlerinizin izinlerini yöneterek en az ayrıcalıklı izinleri sağlarsınız.

IAM Kimlik Önekleri

Bu sayfada anahtarların doğasına bağlı olarak IAM Kimlik Öneklerini bulabilirsiniz:

ABIA

AWS STS hizmet taşıyıcı belirteci

ACCA

Bağlama özgü kimlik bilgisi

AGPA

Kullanıcı grubu

AIDA

IAM kullanıcısı

AIPA

Amazon EC2 örnek profili

AKIA

Erişim anahtarı

ANPA

Yönetilen politika

ANVA

Yönetilen politikadaki sürüm

APKA

Genel anahtar

AROA

Rol

ASCA

Sertifika

ASIA

Geçici (AWS STS) erişim anahtar kimlikleri bu öneki kullanır, ancak yalnızca gizli erişim anahtarı ve oturum belirteciyle birlikte benzersizdir.

Hesapları denetlemek için önerilen izinler

Aşağıdaki yetkiler, çeşitli meta veri okuma erişimini sağlar:

  • arn:aws:iam::aws:policy/SecurityAudit

  • arn:aws:iam::aws:policy/job-function/ViewOnlyAccess

  • codebuild:ListProjects

  • config:Describe*

  • `cloudformation:ListStack

[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
aws_secret_access_key = uOcdhof683fbOUGFYEQug8fUGIf68greoihef

[Admin]
aws_access_key_id = AKIA8YDCu7TGTR356SHYT
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
region = eu-west-2

Eğer farklı AWS hesaplarına erişmeniz gerekiyorsa ve profiliniz bu hesaplarda bir rolü üstlenme yetkisi verildiyse, her seferinde STS'yi manuel olarak çağırmak (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) ve kimlik bilgilerini yapılandırmak zorunda değilsiniz.

~/.aws/config dosyasını kullanarak hangi rollerin üstlenileceğini belirtebilirsiniz ve ardından --profile parametresini kullanarak (kullanıcı için assume-role işlemi şeffaf bir şekilde gerçekleştirilecektir) normal şekilde devam edebilirsiniz. Bir yapılandırma dosyası örneği:

[profile acc2]
region=eu-west-2
role_arn=arn:aws:iam::<account-id>:role/<role-path>
role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional

Bu yapılandırma dosyasıyla aws cli'yi aşağıdaki gibi kullanabilirsiniz:

aws --profile acc2 ...

Eğer tarayıcı için buna benzer bir şey arıyorsanız, AWS Extend Switch Roles adlı eklentiyi kontrol edebilirsiniz.

Referanslar

htARTE (HackTricks AWS Red Team Expert) ile sıfırdan kahraman olmak için AWS hackleme öğrenin!

HackTricks'i desteklemenin diğer yolları:

PreviousAWS PentestingNextAWS - Federation Abuse

Last updated