AWS - Basic Information
Last updated
Last updated
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Eğitim AWS Kırmızı Takım Uzmanı (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Eğitim GCP Kırmızı Takım Uzmanı (GRTE)
AWS'de root hesabı vardır, bu da organizasyonunuz için tüm hesapların ana konteyneridir. Ancak, kaynakları dağıtmak için bu hesabı kullanmanıza gerek yoktur, 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 ve kullanıcı hesaplarından bahsediyoruz): 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
Organizasyondaki 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. Sadece o hesaba kontroller uygulamak için bir hesaba politika ekleyebilirsiniz.
Üye hesaplar geçerli bir e-posta adresi kullanmalıdır ve bir isim alabilir, genellikle faturalamayı yönetemezler (ancak buna erişim verilebilir).
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 OUlardan oluşabileceğini unutmayın.
Bir service control policy (SCP), SCP'nin etki ettiğ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 account'u da tehlikeye atmaktır (master account engellenemez).
SCP'lerin yalnızca hesap içindeki ilkeleri kısıtladığını unutmayın, bu nedenle diğer hesaplar etkilenmez. Bu, bir SCP'nin s3:GetObject iznini reddetmesinin, insanların hesabınızdaki bir kamu S3 bucket'ına 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 Public Block Access'in 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.
Amazon Resource Name, AWS içindeki her kaynağın benzersiz adıdır, bu şekilde oluşturulmuştur:
Not edin ki AWS'de 4 bölüm vardır ama bunları çağırmanın sadece 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, 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.
Amazon Web Services (AWS) hesabı 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ısı, AWS'de kullanıcıyı temsil eden kişi veya uygulama için oluşturduğunuz bir varlıktır. AWS'deki bir kullanıcı, bir isim ve kimlik bilgileri (şifre ve iki erişim anahtarına kadar) 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 belirtmelisiniz (örnek burada).
Erişim Anahtarı Kimliği: 20 rastgele büyük harfli alfanümerik karakter, örneğin AKHDNAPO86BSHKDIRYT
Gizli erişim anahtarı kimliği: 40 rastgele büyük ve küçük harf karakteri: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Kayıp gizli erişim anahtarı kimlikleri geri alınamaz).
Herhangi bir zamanda Erişim Anahtarını değiştirmek istediğinizde izlemeniz gereken süreç: &#xNAN;C 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
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ı yapmalısınız. Bu, MFA hakkında bilgi içeren bir token verecektir.
AssumeRole kimlik bilgileri bu bilgiyi içermez olduğunu unutmayın.
As burada belirtilmiştir, MFA'nın kullanılamayacağı birçok farklı durum vardır.
Bir IAM kullanıcı grubu, birden fazla kullanıcıya aynı anda politika eklemenin bir yoludur, 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 bir Principal olarak bir politikada (örneğin, kaynak tabanlı bir politika) tanımlayamazsınız çü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ı gibi sınırlıdır. Daha fazla bilgi için IAM ve AWS STS kotaları sayfasına bakın.
Bir IAM rolü, kullanıcı ile çok benzer olup, AWS'de ne yapabileceğini ve ne yapamayacağını belirleyen izin politikalarına sahip bir kimliktir. Ancak, bir rolün ilişkili olduğu 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ısı kullanarak oturum açan bir federasyon kullanıcısına atanabilir.
Bir IAM rolü, iki tür politikadan oluşur: 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), 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:
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 yerine getirmenizi engeller. 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.
İ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 (onlardan birini değiştirerek ve kendi politikanızı oluşturarak) dayalı politikalar oluşturabilir, politika oluşturucu (izinleri vermenize ve reddetmenize yardımcı olan bir GUI görünümü) kullanabilir veya kendi politikanızı yazabilirsiniz.
Varsayılan erişim reddedilir, açık bir rol belirtilirse erişim verilecektir. Eğer tek bir "Reddet" varsa, "İzin Ver"i geçersiz kılacaktır, AWS hesabının kök güvenlik kimlik bilgilerini kullanan talepler hariç (varsayılan olarak izin verilir).
The global fields that can be used for conditions in any service are documented here. The specific fields that can be used for conditions per service are documented here.
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, kimlikte yer alan politikalar da silinir. Bunun nedeni, bunların ana varlığın bir parçası olmasıdır.
Bunlar, kaynaklarda tanımlanabilen politikalardır. AWS'nin tüm kaynakları bunları desteklemez.
Eğer bir ana varlığın bunlar üzerinde açık bir reddi yoksa ve bir kaynak politikası onlara erişim veriyorsa, o zaman izin verilir.
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, bu izinleri kullanmaya çalıştığında işlem başarısız olur.
Bir sınır, bir kullanıcıya eklenen bir politikadır ve bu, 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 sadece S· bucket'larını okuyabileceğini gösteriyorsa, yapabileceği maksimum 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.
Bir 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.
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 kullanıldığında (gelişmiş kimlik doğrulaması ile), 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, 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ısına örnek, kendi kurumsal Microsoft Active Directory'niz ( SAML aracılığıyla) veya OpenID hizmetleridir ( Google gibi). 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ısı (SAML veya OAuth) oluşturulur. Ardından, en az bir IAM rolü (güvenen) Kimlik Sağlayıcısına 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ısına güvenebilir ve üçüncü taraf platform, kullanıcılara bir rolü veya diğerini üstlenme izni verecektir.
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ı 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 kullanıcılar ve gruplar 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ısı oluşturulacak ve belirtilen politikalarla Kimlik Sağlayıcısına güvenen bir rol, hedef hesapta oluşturulacaktır.
IAM Kimlik Merkezi aracılığıyla oluşturulan rollere satır içi politikalarla izin 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.
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, federasyon kullanıcıları gibi diğer kimlik doğrulama yapılmış kullanıcılar da bu güveni kötüye kullanabilir.
Desteklenmiyor:
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ı
OS veya Örnekler için Doğrudan erişim yok
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.
Ş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ı, şifre etkin mi...). 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.
bu sayfada anahtarların doğasına bağlı olarak IAM ID ön eklerini bulabilirsiniz:
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.
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
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ı elle ~/.aws/credentials dosyasında yapılandırabilir veya çalıştırarak aws configure yapabilirsiniz.
O dosyada birden fazla profil bulundurabilirsiniz; eğer profil belirtilmezse, o dosyada [default] olarak adlandırılan profil kullanılacaktır.
Birden fazla profil içeren kimlik bilgileri dosyası örneği:
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 (kullanıcı için assume-role şeffaf bir şekilde gerçekleştirilecektir).
Bir yapılandırma dosyası örneği:
Bu yapılandırma dosyası ile aws cli'yi şu şekilde kullanabilirsiniz:
Eğer tarayıcı için buna benzer bir şey arıyorsanız, uzantı AWS Extend Switch Roles sayfasına göz atabilirsiniz.
AWS Hacking öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
