AWS - Temel Bilgiler

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

Organizasyon Hiyerarşisi

Hesaplar

AWS’de, tüm hesapların ebeveyn konteyneri olan bir root hesabı vardır. Ancak, kaynakları dağıtmak için bu hesabı kullanmanız gerekmez, farklı AWS altyapılarını birbirinden ayırmak için diğer hesaplar oluşturabilirsiniz.

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

Bu nedenle, bir organizasyonda iki tür hesap vardır (AWS hesaplarından bahsediyoruz, Kullanıcı hesaplarından değil): yönetim hesabı olarak belirlenen tek bir hesap ve bir veya daha fazla üye hesabı.

  • Yönetim hesabı (root hesabı), organizasyonu oluşturmak için kullandığınız hesaptır. Organizasyonun yönetim hesabından aşağıdakileri yapabilirsiniz:

  • Organizasyonda hesaplar oluşturun

  • Diğer mevcut hesapları organizasyona davet edin

  • Organizasyondan hesapları kaldırın

  • Davetleri yönetin

  • Organizasyon içindeki varlıklara (root’lar, OU’lar veya hesaplar) politikalar uygulayın

  • Organizasyondaki tüm hesaplar arasında hizmet işlevselliği sağlamak için desteklenen AWS hizmetleriyle entegrasyonu etkinleştirin.

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

Yönetim hesabı, ödeyici hesabının sorumluluklarına sahiptir ve üye hesaplar tarafından biriken tüm ücretleri ödemekten sorumludur. Bir organizasyonun yönetim hesabını değiştiremezsiniz.

  • Üye hesaplar, bir organizasyondaki tüm diğer hesapları oluşturur. Bir hesap aynı anda yalnızca bir organizasyonun üyesi olabilir. Bir hesaba yalnızca o hesaba kontroller uygulamak için bir politika ekleyebilirsiniz.
  • Üye hesaplar geçerli bir e-posta adresi kullanmalıdır ve bir isim alabilir, genellikle faturalandırmayı yönetemezler (ancak buna erişim verilebilir).
aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com

Organizasyon Birimleri

Hesaplar Organizasyon Birimleri (OU) içinde gruplandırılabilir. Bu şekilde, Organizasyon Birimi için tüm alt hesaplara uygulanacak politikalar oluşturabilirsiniz. Bir OU’nun altı olarak başka OU’lar da olabileceğini unutmayın.

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

Service Control Policy (SCP)

Bir service control policy (SCP), SCP’nin etkilediği hesaplarda kullanıcıların ve rollerin kullanabileceği hizmetleri ve eylemleri belirten bir politikadır. SCP’ler, IAM izin politikalarına benzer, ancak hiçbir izin vermezler. Bunun yerine, SCP’ler bir organizasyon, organizasyonel birim (OU) veya hesap için maksimum izinleri belirtir. Bir SCP’yi organizasyon kökünüze veya bir OU’ya eklediğinizde, SCP, üye hesaplardaki varlıkların izinlerini sınırlar.

Bu, root kullanıcının bile bir şey yapmasını durdurmanın TEK yoludur. Örneğin, kullanıcıların CloudTrail’i devre dışı bırakmasını veya yedekleri silmesini engellemek için kullanılabilir.
Bunu aşmanın tek yolu, SCP’leri yapılandıran master hesabı da tehlikeye atmaktır (master hesap engellenemez).

Warning

SCP’ler yalnızca hesap içindeki ilkeleri kısıtlar, bu nedenle diğer hesaplar etkilenmez. Bu, bir SCP’nin s3:GetObject iznini reddetmesinin, insanların hesabınızdaki bir genel S3 bucket’a erişmesini durdurmayacağı anlamına gelir.

SCP örnekleri:

  • Root hesabını tamamen reddet

  • Sadece belirli bölgeleri izin ver

  • Sadece beyaz listeye alınmış hizmetlere izin ver

  • GuardDuty, CloudTrail ve S3 Genel Erişim Engeli’nin devre dışı bırakılmasını reddet

  • Güvenlik/olay yanıtı rollerinin silinmesini veya

değiştirilmesini reddet.

  • Yedeklerin 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.

Resource Control Policy (RCP)

Bir resource control policy (RCP), AWS organizasyonunuz içindeki kaynaklar için maksimum izinleri tanımlayan bir politikadır. RCP’ler, sözdizimi açısından IAM politikalarına benzer, ancak izin vermezler—sadece diğer politikalar tarafından kaynaklara uygulanabilecek izinleri sınırlar. Bir RCP’yi organizasyon kökünüze, bir organizasyonel birime (OU) veya bir hesaba eklediğinizde, RCP, etkilenen kapsamda tüm kaynaklar üzerindeki kaynak izinlerini sınırlar.

Bu, kaynakların önceden tanımlanmış erişim seviyelerini aşmasını sağlamanın TEK yoludur—bir kimlik tabanlı veya kaynak tabanlı politika çok izin verici olsa bile. Bu sınırlamaları aşmanın tek yolu, organizasyonunuzun yönetim hesabı tarafından yapılandırılan RCP’yi de değiştirmektir.

Warning

RCP’ler yalnızca kaynakların sahip olabileceği izinleri kısıtlar. Doğrudan ilkelerin ne yapabileceğini kontrol etmezler. Örneğin, bir RCP bir S3 bucket’a dış erişimi reddederse, bu, bucket’ın izinlerinin belirlenen sınırın ötesinde eylemlere asla izin vermeyeceğini garanti eder—bir kaynak tabanlı politika yanlış yapılandırılmış olsa bile.

RCP örnekleri:

  • S3 bucket’larını, yalnızca organizasyonunuz içindeki ilkeler tarafından erişilebilecek şekilde kısıtlayın
  • KMS anahtar kullanımını yalnızca güvenilir organizasyonel hesaplardan gelen işlemlerle sınırlayın
  • Yetkisiz değişiklikleri önlemek için SQS kuyruklarındaki izinleri sınırlandırın
  • Hassas verileri korumak için Secrets Manager sırlarında erişim sınırlarını zorlayın

Örnekleri AWS Organizations Resource Control Policies belgelerinde bulabilirsiniz.

ARN

Amazon Resource Name, AWS içindeki her kaynağın benzersiz adıdır, bu şekilde oluşur:

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

Not edin ki AWS’de 4 bölüm vardır ancak bunları çağırmanın yalnızca 3 yolu vardır:

  • AWS Standard: aws
  • AWS China: aws-cn
  • AWS US public Internet (GovCloud): aws-us-gov
  • AWS Secret (US Classified): aws

IAM - Kimlik ve Erişim Yönetimi

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

  • Kimlik Doğrulama - Bir kimliğin tanımlanması ve o kimliğin doğrulanması süreci. Bu süreç, Tanımlama ve doğrulama olarak alt bölümlere ayrılabilir.
  • Yetkilendirme - Bir kimliğin, sisteme kimlik doğrulaması yapıldıktan sonra neye erişebileceğini belirler.
  • Erişim Kontrolü - Güvenli bir kaynağa erişimin nasıl verileceği ile ilgili yöntem ve süreçtir.

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ği ile tanımlanabilir.

AWS hesap kök kullanıcısı

Amazon Web Services (AWS) hesabınızı ilk oluşturduğunuzda, hesabınızdaki tüm AWS hizmetlerine ve kaynaklarına tam erişime sahip tek bir oturum açma kimliği ile başlarsınız. Bu, AWS hesap kök kullanıcısıdır ve hesabı oluşturmak için kullandığınız e-posta adresi ve şifre ile oturum açarak erişilir.

Yeni bir admin kullanıcısının kök kullanıcıdan daha az izin alacağını unutmayın.

Güvenlik açısından, diğer kullanıcıları oluşturmanız ve bu kullanıcıyı kullanmaktan kaçınmanız önerilir.

IAM kullanıcıları

IAM kullanıcısı, AWS’de onu kullanan kişi veya uygulamayı temsil etmek için oluşturduğunuz bir varlıktır. AWS’deki bir kullanıcı, bir isim ve kimlik bilgileri (şifre ve en fazla iki erişim anahtarı) içerir.

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

Kullanıcılar, konsoldan giriş yapmak için MFA etkinleştirilebilir. MFA etkin kullanıcıların API token’ları MFA ile korunmaz. Eğer MFA kullanarak bir kullanıcının API anahtarlarının erişimini kısıtlamak istiyorsanız, belirli eylemleri gerçekleştirmek için MFA’nın mevcut olması gerektiğini politikada belirtmeniz gerekir (örnek burada).

CLI

  • Erişim Anahtarı ID’si: 20 rastgele büyük harfli alfanümerik karakter, örneğin AKHDNAPO86BSHKDIRYT
  • Gizli erişim anahtarı ID’si: 40 rastgele büyük ve küçük harf karakteri: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (kayıp gizli erişim anahtarı ID’leri geri alınamaz).

Herhangi bir zamanda Erişim Anahtarını değiştirmek istediğinizde izlemeniz gereken süreç:
Yeni bir erişim anahtarı oluştur -> Yeni anahtarı sistem/uygulamaya uygula -> Orijinalini pasif olarak işaretle -> Yeni erişim anahtarının çalıştığını test et ve doğrula -> Eski erişim anahtarını sil

MFA - Çok Faktörlü Kimlik Doğrulama

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

MFA koşulları olan politikalar aşağıdakilere eklenebilir:

  • Bir IAM kullanıcısı veya grubu
  • Amazon S3 bucket, Amazon SQS kuyruğu veya Amazon SNS konusu gibi bir kaynak
  • Bir kullanıcının üstlenebileceği bir IAM rolünün güven politikası

Eğer CLI üzerinden MFA kontrolü yapan bir kaynağa erişmek istiyorsanız, GetSessionToken çağrısı yapmanız gerekir. Bu, MFA hakkında bilgi içeren bir token verecektir.
Unutmayın ki AssumeRole kimlik bilgileri bu bilgiyi içermez.

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

As burada belirtilmiştir, MFA’nın kullanılamayacağı birçok farklı durum vardır.

IAM kullanıcı grupları

Bir IAM kullanıcı grubu, birden fazla kullanıcıya aynı anda politika eklemenin bir yoludur, bu da o 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 bir Principal olarak tanımlayamazsınız (örneğin, kaynak tabanlı bir politika gibi) çünkü gruplar izinlerle, kimlik doğrulama ile değil, ilişkilidir ve prensipler kimlik doğrulaması yapılmış IAM varlıklarıdır.

Kullanıcı gruplarının bazı önemli özellikleri şunlardır:

  • Bir kullanıcı grubu birçok kullanıcı içerebilir ve bir kullanıcı birden fazla gruba ait olabilir.
  • Kullanıcı grupları iç içe olamaz; yalnızca kullanıcıları içerebilir, diğer kullanıcı gruplarını değil.
  • AWS hesabındaki tüm kullanıcıları otomatik olarak içeren varsayılan bir kullanıcı grubu yoktur. Böyle bir kullanıcı grubuna sahip olmak istiyorsanız, onu oluşturmalı ve her yeni kullanıcıyı ona atamalısınız.
  • AWS hesabındaki IAM kaynaklarının sayısı ve boyutu, grupların sayısı ve bir kullanıcının üyesi olabileceği grup sayısı ile sınırlıdır. Daha fazla bilgi için IAM ve AWS STS kotalarına bakın.

IAM rolleri

Bir IAM rolü, bir kullanıcıya çok benzer olup, AWS’de ne yapabileceğini ve ne yapamayacağını belirleyen izin politikaları ile bir kimliktir. Ancak, bir rolün kendisiyle ilişkili herhangi bir kimlik bilgisi (şifre veya erişim anahtarları) yoktur. Bir kişiye özgü olarak değil, bir rolün ihtiyacı olan herkes tarafından üstlenilmesi amaçlanmıştır (ve yeterli izinlere sahip olunmalıdır). Bir IAM kullanıcısı, belirli bir görev için geçici olarak farklı izinler almak üzere bir rolü ü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 politika içerir: boş olamaz olan bir güven politikası, rolü kimin üstlenebileceğini tanımlar ve boş olamaz olan bir izin politikası, neye erişebileceğini tanımlar.

AWS Güvenlik Token Servisi (STS)

AWS Güvenlik Token Servisi (STS), geçici, sınırlı ayrıcalıklı kimlik bilgileri vermeyi kolaylaştıran bir web hizmetidir. Özellikle aşağıdakiler için tasarlanmıştır:

IAM’de Geçici Kimlik Bilgileri

Geçici kimlik bilgileri esas olarak IAM rolleri ile kullanılır, ancak başka kullanımları da vardır. Standart IAM kullanıcınızdan daha kısıtlı bir izin setine sahip geçici kimlik bilgileri talep edebilirsiniz. Bu, daha kısıtlı kimlik bilgileri tarafından izin verilmeyen görevleri kazara gerçekleştirmenizi önler. Geçici kimlik bilgilerinin bir avantajı, belirli bir süre sonra otomatik olarak süresinin dolmasıdır. Kimlik bilgilerinin geçerli olduğu süre üzerinde kontrol sahibisiniz.

Politikalar

Politika İzinleri

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

  • AWS yönetilen politikaları (AWS tarafından önceden yapılandırılmış)
  • Müşteri Yönetilen Politikalar: Siz tarafından yapılandırılmıştır. AWS yönetilen politikalarına (birini değiştirerek ve kendi politikanızı oluşturarak), politika oluşturucu kullanarak (izinleri vermenize ve reddetmenize yardımcı olan bir GUI görünümü) veya kendi yazdığınız politikalarla dayalı politikalar oluşturabilirsiniz.

Varsayılan erişim reddedilir, açık bir rol belirtilirse erişim verilecektir.
Eğer tek bir “Deny” varsa, “Allow“u geçersiz kılacaktır, AWS hesabının kök güvenlik kimlik bilgilerini kullanan talepler hariç (varsayılan olarak izin verilir).

{
"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"}
}
}
]
}

Herhangi bir hizmette koşullar için kullanılabilecek global alanlar burada belgelenmiştir.
Her hizmet için koşullar için kullanılabilecek özel alanlar burada belgelenmiştir.

Inline Politika

Bu tür politikalar doğrudan bir kullanıcıya, gruba veya role atanır. Bu nedenle, başka birinin kullanabileceği Politika listesinde görünmezler.
Inline politikalar, bir politikanın uygulandığı kimlik ile katı bir birebir ilişkiyi sürdürmek istiyorsanız faydalıdır. Örneğin, bir politikanın izinlerinin, amaçlandığı kimlik dışında başka bir kimliğe yanlışlıkla atanmadığından emin olmak istersiniz. Inline politika kullandığınızda, politikanın izinleri yanlış bir kimliğe yanlışlıkla eklenemez. Ayrıca, AWS Yönetim Konsolu’nu kullanarak o kimliği sildiğinizde, kimliğe gömülü politikalar da silinir. Bunun nedeni, bunların ana varlığın bir parçası olmasıdır.

Kaynak Bucket Politikaları

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

Eğer bir anahtarın üzerinde açık bir reddetme yoksa ve bir kaynak politikası onlara erişim veriyorsa, o zaman izin verilir.

IAM Sınırları

IAM sınırları, bir kullanıcının veya rolün erişim sağlaması gereken izinleri sınırlamak için kullanılabilir. Bu şekilde, eğer kullanıcıya farklı bir politika tarafından farklı bir izin seti verilirse, bunları kullanmaya çalıştığında işlem başarısız olur.

Bir sınır, bir kullanıcıya eklenen bir politikadır ve kullanıcının veya rolün sahip olabileceği maksimum izin seviyesini gösterir. Yani, kullanıcı Yönetici erişimine sahip olsa bile, eğer sınır yalnızca S· bucket’larını okuyabileceğini gösteriyorsa, yapabileceği maksimum şey budur.

Bu, SCP’ler ve en az ayrıcalık ilkesine uymak, kullanıcıların ihtiyaç duyduğundan daha fazla izne sahip olmalarını kontrol etmenin yollarıdır.

Oturum Politikaları

Oturum politikası, bir rolün üstlenildiği zaman ayarlanan bir politikadır. Bu, o oturum için bir IAM sınırı gibi olacaktır: Bu, oturum politikasının izin vermediği, ancak politikada belirtilenlerle sınırladığı anlamına gelir (maksimum izinler rolün sahip olduğu izinlerdir).

Bu, güvenlik önlemleri için faydalıdır: Bir yönetici çok ayrıcalıklı bir rol üstleneceği zaman, oturumun tehlikeye girmesi durumunda izinleri yalnızca oturum politikasında belirtilenlerle sınırlayabilir.

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

Not edin ki varsayılan olarak AWS, üçüncü nedenlerden dolayı oluşturulacak oturumlara oturum politikaları ekleyebilir. Örneğin, kimlik doğrulaması yapılmamış cognito varsayılan rolleri için (gelişmiş kimlik doğrulaması kullanarak) AWS, oturum politikası ile oturum kimlik bilgileri oluşturacaktır; bu, oturumun erişebileceği hizmetleri aşağıdaki liste ile sınırlamaktadır.

Bu nedenle, bir noktada “… çünkü hiçbir oturum politikası …’ya izin vermiyor” hatası ile karşılaşırsanız ve rol, eylemi gerçekleştirme erişimine sahipse, bunun nedeni bunu engelleyen bir oturum politikası olmasıdır.

Kimlik Federasyonu

Kimlik federasyonu, AWS’ye dışarıdan gelen kimlik sağlayıcılarından kullanıcıların AWS kaynaklarına güvenli bir şekilde erişmesini sağlar; bu, geçerli bir IAM kullanıcı hesabından AWS kullanıcı kimlik bilgilerini sağlamayı gerektirmez.
Bir kimlik sağlayıcı örneği, kendi kurumsal Microsoft Active Directory’niz ( SAML aracılığıyla) veya OpenID hizmetleri ( Google gibi) olabilir. Federasyon erişimi, içindeki kullanıcıların AWS’ye erişmesine izin verecektir.

Bu güveni yapılandırmak için, diğer platforma güvenen bir IAM Kimlik Sağlayıcı (SAML veya OAuth) oluşturulur. Ardından, en az bir IAM rolü (kimlik sağlayıcıya güvenen) 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 istersiniz. Bu durumda, 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 verecektir.

IAM Kimlik Merkezi

AWS IAM Kimlik Merkezi (AWS Tek Oturum Açma’nın halefidir), AWS Kimlik ve Erişim Yönetimi (IAM) yeteneklerini genişleterek, AWS hesaplarına ve bulut uygulamalarına kullanıcıların ve erişimlerinin yönetimini bir araya getiren merkezi bir yer sağlar.

Giriş alanı, <user_input>.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ğlantıları destekler
  • Dış Kimlik Sağlayıcı: Tüm kullanıcılar ve gruplar bir dış Kimlik Sağlayıcıdan (IdP) gelir

Kimlik Merkezi dizininin en basit durumunda, Kimlik Merkezi bir kullanıcı ve grup listesine sahip olacak ve onlara herhangi bir hesabın politikalarını atama yeteneğine sahip olacaktır.

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

AwsSSOInlinePolicy

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

Bu nedenle, AwsSSOInlinePolicy adlı bir satır içi politikaya sahip 2 rol görseniz bile, bu aynı izinlere sahip olduğu anlamına gelmez.

Hesaplar Arası Güvenler ve Roller

Bir kullanıcı (güvenen) bazı politikalarla bir 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şimle. Bunu oluşturmak için, yeni bir Rol oluşturun ve Hesaplar Arası Rolü seçin. Hesaplar Arası Erişim için roller 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.
Güvenilen kullanıcıyı belirtmek ve genel bir şey koymamak önerilir; aksi takdirde, diğer kimlik doğrulaması yapılmış kullanıcılar, federasyon kullanıcıları gibi, bu güveni kötüye kullanabilir.

AWS Basit AD

Desteklenmiyor:

  • Güven İlişkileri
  • AD Yönetim Merkezi
  • Tam PS API desteği
  • AD Geri Dönüş Kutusu
  • Grup Yönetilen Hizmet Hesapları
  • Şema Uzantıları
  • OS veya Örnekler için Doğrudan erişim yok

Web Federasyonu veya OpenID Kimlik Doğrulaması

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

Diğer IAM seçenekleri

  • Şifre politikası ayarlarını minimum uzunluk ve şifre gereksinimleri gibi seçeneklerle ayarlayabilirsiniz.
  • Mevcut kimlik bilgileri hakkında bilgi içeren bir “Kimlik Bilgisi Raporu” indirebilirsiniz (kullanıcı oluşturma zamanı, şifrenin etkin olup olmadığı gibi…). Bir kimlik bilgisi raporu, her dört saatte bir kadar sık oluşturulabilir.

AWS Kimlik ve Erişim Yönetimi (IAM), AWS genelinde ince ayarlanmış erişim kontrolü sağlar. IAM ile, kimin hangi hizmetlere ve kaynaklara erişebileceğini ve hangi koşullar altında erişebileceğini belirtebilirsiniz. IAM politikaları ile, iş gücünüze ve sistemlerinize en az ayrıcalık izinlerini sağlamak için izinleri yönetirsiniz.

IAM ID Ön Ekleri

bu sayfada anahtarların doğasına bağlı olarak IAM ID ön eklerini bulabilirsiniz:

Tanımlayıcı KoduAçıklama
ABIAAWS STS hizmet taşıyıcı belirteci

| ACCA | Bağlama özel 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 ön eki kullanır, ancak yalnızca gizli erişim anahtarı ve oturum belirteci ile kombinasyon halinde benzersizdir. |

Hesapları denetlemek için önerilen izinler

Aşağıdaki ayrıcalıklar, çeşitli meta verilerin okunmasına izin verir:

  • arn:aws:iam::aws:policy/SecurityAudit
  • arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
  • codebuild:ListProjects
  • config:Describe*
  • cloudformation:ListStacks
  • logs:DescribeMetricFilters
  • directconnect:DescribeConnections
  • dynamodb:ListTables

Çeşitli

CLI Kimlik Doğrulaması

Bir normal kullanıcının CLI aracılığıyla AWS’ye kimlik doğrulaması yapabilmesi için yerel kimlik bilgilerine sahip olması gerekir. Varsayılan olarak, bunları ~/.aws/credentials dosyasında manuel olarak yapılandırabilir veya çalıştırarak aws configure yapabilirsiniz.
O dosyada birden fazla profil bulundurabilirsiniz; eğer hiçbir profil belirtilmezse, aws cli kullanarak o dosyadaki [default] adlı profil kullanılacaktır.
Birden fazla profil içeren kimlik bilgileri dosyası örneği:

[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 profilinize bu hesaplar içinde bir rol üstlenme yetkisi verildiyse, her seferinde STS’yi manuel olarak çağırmanıza gerek yoktur (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) ve kimlik bilgilerini yapılandırmanıza gerek yoktur.

~/.aws/config dosyasını kullanarak üstlenilecek rolleri belirtmek mümkündür ve ardından --profile parametresini her zamanki gibi kullanabilirsiniz (rol üstlenme işlemi kullanıcı için şeffaf bir şekilde gerçekleştirilecektir).
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ı ile aws cli’yi şu şekilde kullanabilirsiniz:

aws --profile acc2 ...

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

Geçici kimlik bilgilerini otomatikleştirme

Geçici kimlik bilgileri üreten bir uygulamayı istismar ediyorsanız, her birkaç dakikada bir sona erdiklerinde terminalinizde güncellemeleri yapmak zahmetli olabilir. Bu, yapılandırma dosyasında bir credential_process direktifi kullanılarak düzeltilebilir. Örneğin, bazı savunmasız web uygulamanız varsa, şunu yapabilirsiniz:

[victim]
credential_process = curl -d 'PAYLOAD' https://some-site.com

Şunu unutmayın ki kimlik bilgileri şu formatta STDOUT’a döndürülmelidir:

{
"Version": 1,
"AccessKeyId": "an AWS access key",
"SecretAccessKey": "your AWS secret access key",
"SessionToken": "the AWS session token for temporary credentials",
"Expiration": "ISO8601 timestamp when the credentials expire"
}

Referanslar

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin