mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-29 07:00:29 -07:00
Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA
This commit is contained in:
@@ -10,7 +10,7 @@
|
||||
|
||||
W AWS istnieje **konto główne**, które jest **rodzicem dla wszystkich kont** w Twojej **organizacji**. Jednak nie musisz używać tego konta do wdrażania zasobów, możesz utworzyć **inne konta, aby oddzielić różne infrastruktury AWS** między sobą.
|
||||
|
||||
Jest to bardzo interesujące z punktu widzenia **bezpieczeństwa**, ponieważ **jedno konto nie będzie mogło uzyskać dostępu do zasobów innego konta** (chyba że mosty zostaną specjalnie utworzone), dzięki czemu możesz stworzyć granice między wdrożeniami.
|
||||
Jest to bardzo interesujące z punktu widzenia **bezpieczeństwa**, ponieważ **jedno konto nie będzie mogło uzyskać dostępu do zasobów innego konta** (chyba że specjalnie utworzone są mosty), dzięki czemu możesz tworzyć granice między wdrożeniami.
|
||||
|
||||
Dlatego w organizacji istnieją **dwa typy kont** (mówimy o kontach AWS, a nie kontach użytkowników): jedno konto, które jest wyznaczone jako konto zarządzające, oraz jedno lub więcej kont członkowskich.
|
||||
|
||||
@@ -46,7 +46,7 @@ To jest JEDYNY sposób, aby **nawet użytkownik root mógł być powstrzymany**
|
||||
Jedynym sposobem na obejście tego jest również skompromitowanie **konta głównego**, które konfiguruje SCP (konto główne nie może być zablokowane).
|
||||
|
||||
> [!WARNING]
|
||||
> Zauważ, że **SCP tylko ograniczają uprawnienia w koncie**, więc inne konta nie są dotknięte. Oznacza to, że posiadanie SCP, które odmawia `s3:GetObject`, nie powstrzyma ludzi przed **uzyskiwaniem dostępu do publicznego koszyka S3** w twoim koncie.
|
||||
> Zauważ, że **SCP ograniczają tylko podmioty w koncie**, więc inne konta nie są dotknięte. Oznacza to, że posiadanie SCP, które odmawia `s3:GetObject`, nie powstrzyma ludzi przed **uzyskiwaniem dostępu do publicznego koszyka S3** w twoim koncie.
|
||||
|
||||
Przykłady SCP:
|
||||
|
||||
@@ -57,9 +57,9 @@ Przykłady SCP:
|
||||
|
||||
byciem wyłączonym
|
||||
|
||||
- Zablokować role odpowiedzialne za bezpieczeństwo/reakcję na incydenty przed usunięciem lub
|
||||
- Zablokować role odpowiedzialności za bezpieczeństwo/incydenty przed usunięciem lub
|
||||
|
||||
zmodyfikowaniem.
|
||||
zmianą.
|
||||
|
||||
- Zablokować usuwanie kopii zapasowych.
|
||||
- Zablokować tworzenie użytkowników IAM i kluczy dostępu
|
||||
@@ -73,7 +73,7 @@ Znajdź **przykłady JSON** w [https://docs.aws.amazon.com/organizations/latest/
|
||||
To jest JEDYNY sposób, aby zapewnić, że **zasoby nie mogą przekroczyć zdefiniowanych poziomów dostępu**—nawet jeśli polityka oparta na tożsamości lub zasobach jest zbyt liberalna. Jedynym sposobem na obejście tych ograniczeń jest również modyfikacja RCP skonfigurowanej przez konto zarządzające twojej organizacji.
|
||||
|
||||
> [!WARNING]
|
||||
> RCP tylko ograniczają uprawnienia, które mogą mieć zasoby. Nie kontrolują bezpośrednio, co mogą robić podmioty. Na przykład, jeśli RCP odmawia dostępu zewnętrznego do koszyka S3, zapewnia, że uprawnienia koszyka nigdy nie pozwalają na działania wykraczające poza ustalony limit—nawet jeśli polityka oparta na zasobach jest źle skonfigurowana.
|
||||
> RCP ograniczają tylko uprawnienia, które zasoby mogą mieć. Nie kontrolują bezpośrednio, co podmioty mogą robić. Na przykład, jeśli RCP odmawia dostępu zewnętrznego do koszyka S3, zapewnia, że uprawnienia koszyka nigdy nie pozwalają na działania wykraczające poza ustalony limit—nawet jeśli polityka oparta na zasobach jest źle skonfigurowana.
|
||||
|
||||
Przykłady RCP:
|
||||
|
||||
@@ -86,7 +86,7 @@ Znajdź przykłady w [dokumentacji Polityk Kontroli Zasobów AWS Organizations](
|
||||
|
||||
### ARN
|
||||
|
||||
**Amazon Resource Name** to **unikalna nazwa**, którą ma każdy zasób w AWS, składa się z tego:
|
||||
**Amazon Resource Name** to **unikalna nazwa**, jaką ma każdy zasób w AWS, składa się z tego:
|
||||
```
|
||||
arn:partition:service:region:account-id:resource-type/resource-id
|
||||
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env
|
||||
@@ -127,7 +127,7 @@ Użytkownicy mogą mieć **włączone MFA do logowania** przez konsolę. Tokeny
|
||||
#### CLI
|
||||
|
||||
- **ID klucza dostępu**: 20 losowych wielkich liter i cyfr, np. AKHDNAPO86BSHKDIRYT
|
||||
- **ID tajnego klucza dostępu**: 40 losowych wielkich i małych liter: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Nie można odzyskać utraconych ID tajnych kluczy dostępu).
|
||||
- **ID tajnego klucza dostępu**: 40 losowych wielkich i małych liter: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Nie ma możliwości odzyskania utraconych ID tajnego klucza dostępu).
|
||||
|
||||
Kiedy musisz **zmienić klucz dostępu**, powinieneś postępować według tego procesu:\
|
||||
_Utwórz nowy klucz dostępu -> Zastosuj nowy klucz do systemu/aplikacji -> oznacz oryginalny jako nieaktywny -> Przetestuj i zweryfikuj, że nowy klucz dostępu działa -> Usuń stary klucz dostępu_
|
||||
@@ -161,7 +161,7 @@ Oto kilka ważnych cech grup użytkowników:
|
||||
- Grupa **użytkowników** może **zawierać wielu użytkowników**, a **użytkownik** może **należeć do wielu grup**.
|
||||
- **Grupy użytkowników nie mogą być zagnieżdżone**; mogą zawierać tylko użytkowników, a nie inne grupy użytkowników.
|
||||
- Nie ma **domyślnej grupy użytkowników, która automatycznie obejmuje wszystkich użytkowników w koncie AWS**. Jeśli chcesz mieć taką grupę użytkowników, musisz ją utworzyć i przypisać do niej każdego nowego użytkownika.
|
||||
- Liczba i rozmiar zasobów IAM w koncie AWS, takich jak liczba grup oraz liczba grup, do których użytkownik może należeć, są ograniczone. Aby uzyskać więcej informacji, zobacz [Limity IAM i AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
|
||||
- Liczba i rozmiar zasobów IAM w koncie AWS, takich jak liczba grup oraz liczba grup, do których użytkownik może należeć, są ograniczone. Aby uzyskać więcej informacji, zobacz [kwoty IAM i AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
|
||||
|
||||
### [Role IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
|
||||
|
||||
@@ -171,7 +171,7 @@ Rola IAM składa się z **dwóch typów polityk**: **polityki zaufania**, która
|
||||
|
||||
#### Usługa AWS Security Token Service (STS)
|
||||
|
||||
AWS Security Token Service (STS) to usługa internetowa, która ułatwia **wydawanie tymczasowych, ograniczonych poświadczeń**. Jest specjalnie dostosowana do:
|
||||
AWS Security Token Service (STS) to usługa internetowa, która ułatwia **wydawanie tymczasowych, ograniczonych uprawnień**. Jest specjalnie dostosowana do:
|
||||
|
||||
### [Tymczasowe poświadczenia w IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
|
||||
|
||||
@@ -187,7 +187,7 @@ Służą do przypisywania uprawnień. Istnieją 2 typy:
|
||||
- Polityki zarządzane przez klienta: skonfigurowane przez Ciebie. Możesz tworzyć polityki na podstawie polityk zarządzanych przez AWS (modyfikując jedną z nich i tworząc własną), korzystając z generatora polityk (widok GUI, który pomaga w przyznawaniu i odmawianiu uprawnień) lub pisząc własne.
|
||||
|
||||
Zgodnie z **domyślnym dostępem** jest **odmowa**, dostęp zostanie przyznany, jeśli określono wyraźną rolę.\
|
||||
Jeśli **istnieje pojedyncza "Odmowa", nadpisze ona "Zezwól"**, z wyjątkiem żądań, które używają poświadczeń bezpieczeństwa głównego konta AWS (które są dozwolone domyślnie).
|
||||
Jeśli **istnieje pojedyncza "Odmowa", nadpisze "Zezwól"**, z wyjątkiem żądań, które używają poświadczeń bezpieczeństwa głównego konta AWS (które są dozwolone domyślnie).
|
||||
```javascript
|
||||
{
|
||||
"Version": "2012-10-17", //Version of the policy
|
||||
@@ -210,29 +210,29 @@ Jeśli **istnieje pojedyncza "Odmowa", nadpisze ona "Zezwól"**, z wyjątkiem ż
|
||||
]
|
||||
}
|
||||
```
|
||||
Globalne pola, które mogą być używane do warunków w każdej usłudze, są udokumentowane tutaj.\
|
||||
Specyficzne pola, które mogą być używane do warunków w każdej usłudze, są udokumentowane tutaj.
|
||||
[global fields that can be used for conditions in any service are documented here](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\
|
||||
[specific fields that can be used for conditions per service are documented here](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html).
|
||||
|
||||
#### Polityki Inline
|
||||
#### Inline Policies
|
||||
|
||||
Ten rodzaj polityk jest **bezpośrednio przypisany** do użytkownika, grupy lub roli. Wtedy nie pojawiają się one na liście Polityk, ponieważ nikt inny nie może ich używać.\
|
||||
Polityki inline są przydatne, jeśli chcesz **utrzymać ścisłą relację jeden do jednego między polityką a tożsamością**, do której jest zastosowana. Na przykład, chcesz mieć pewność, że uprawnienia w polityce nie są przypadkowo przypisane do tożsamości innej niż ta, dla której są przeznaczone. Kiedy używasz polityki inline, uprawnienia w polityce nie mogą być przypadkowo przypisane do niewłaściwej tożsamości. Dodatkowo, gdy używasz konsoli zarządzania AWS do usunięcia tej tożsamości, polityki osadzone w tożsamości są również usuwane. To dlatego, że są częścią głównego podmiotu.
|
||||
Ten rodzaj polityk jest **bezpośrednio przypisany** do użytkownika, grupy lub roli. W związku z tym nie pojawiają się one na liście Polityk, ponieważ nikt inny nie może ich używać.\
|
||||
Polityki inline są przydatne, jeśli chcesz **utrzymać ścisłą relację jeden do jednego między polityką a tożsamością**, do której są stosowane. Na przykład, chcesz mieć pewność, że uprawnienia w polityce nie są przypadkowo przypisane do tożsamości innej niż ta, dla której są przeznaczone. Kiedy używasz polityki inline, uprawnienia w polityce nie mogą być przypadkowo przypisane do niewłaściwej tożsamości. Dodatkowo, gdy używasz konsoli zarządzania AWS do usunięcia tej tożsamości, polityki osadzone w tożsamości są również usuwane. Dzieje się tak, ponieważ są częścią głównego podmiotu.
|
||||
|
||||
#### Polityki Koszyków Zasobów
|
||||
#### Resource Bucket Policies
|
||||
|
||||
To są **polityki**, które mogą być definiowane w **zasobach**. **Nie wszystkie zasoby AWS je wspierają**.
|
||||
|
||||
Jeśli główny podmiot nie ma wyraźnego odmowy dostępu do nich, a polityka zasobów przyznaje im dostęp, to są dozwolone.
|
||||
Jeśli główny podmiot nie ma wyraźnego odmowy dostępu do nich, a polityka zasobów przyznaje im dostęp, to są one dozwolone.
|
||||
|
||||
### Granice IAM
|
||||
### IAM Boundaries
|
||||
|
||||
Granice IAM mogą być używane do **ograniczenia uprawnień, do których użytkownik lub rola powinny mieć dostęp**. W ten sposób, nawet jeśli inny zestaw uprawnień jest przyznawany użytkownikowi przez **inną politykę**, operacja **nie powiedzie się**, jeśli spróbuje ich użyć.
|
||||
|
||||
Granica to po prostu polityka przypisana do użytkownika, która **wskazuje maksymalny poziom uprawnień, jakie użytkownik lub rola mogą mieć**. Tak więc, **nawet jeśli użytkownik ma dostęp Administratora**, jeśli granica wskazuje, że może tylko czytać koszyki S·, to jest to maksymalne, co może zrobić.
|
||||
Granica to po prostu polityka przypisana do użytkownika, która **wskazuje maksymalny poziom uprawnień, jakie użytkownik lub rola mogą mieć**. Tak więc, **nawet jeśli użytkownik ma dostęp administratora**, jeśli granica wskazuje, że może tylko czytać kosze S·, to jest to maksymalne, co może zrobić.
|
||||
|
||||
**To**, **SCP** i **przestrzeganie zasady najmniejszych uprawnień** to sposoby kontrolowania, aby użytkownicy nie mieli więcej uprawnień niż te, których potrzebują.
|
||||
**To**, **SCPs** i **przestrzeganie zasady najmniejszych uprawnień** to sposoby kontrolowania, aby użytkownicy nie mieli więcej uprawnień niż te, których potrzebują.
|
||||
|
||||
### Polityki Sesji
|
||||
### Session Policies
|
||||
|
||||
Polityka sesji to **polityka ustawiana, gdy rola jest przyjmowana** w jakiś sposób. Będzie to jak **granica IAM dla tej sesji**: Oznacza to, że polityka sesji nie przyznaje uprawnień, ale **ogranicza je do tych wskazanych w polityce** (maksymalne uprawnienia to te, które ma rola).
|
||||
|
||||
@@ -244,18 +244,18 @@ aws sts assume-role \
|
||||
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
|
||||
[--policy <file://policy.json>]
|
||||
```
|
||||
Zauważ, że domyślnie **AWS może dodawać polityki sesji do sesji**, które będą generowane z powodu innych przyczyn. Na przykład, w przypadku [nieautoryzowanych ról przyjętych przez Cognito](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) domyślnie (korzystając z ulepszonej autoryzacji), AWS wygeneruje **poświadczenia sesji z polityką sesji**, która ogranicza usługi, do których sesja ma dostęp [**do następującej listy**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
|
||||
Zauważ, że domyślnie **AWS może dodać polityki sesji do sesji**, które będą generowane z powodu innych przyczyn. Na przykład, w przypadku [nieautoryzowanych ról przyjętych przez Cognito](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) domyślnie (korzystając z ulepszonej autoryzacji), AWS wygeneruje **poświadczenia sesji z polityką sesji**, która ogranicza usługi, do których sesja ma dostęp [**do następującej listy**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
|
||||
|
||||
Dlatego, jeśli w pewnym momencie napotkasz błąd "... ponieważ żadna polityka sesji nie zezwala na ...", a rola ma dostęp do wykonania akcji, to dlatego, że **istnieje polityka sesji, która to uniemożliwia**.
|
||||
|
||||
### Federacja Tożsamości
|
||||
|
||||
Federacja tożsamości **pozwala użytkownikom z dostawców tożsamości, którzy są zewnętrzni** dla AWS, na bezpieczny dostęp do zasobów AWS bez konieczności podawania poświadczeń użytkownika AWS z ważnego konta IAM.\
|
||||
Przykładem dostawcy tożsamości może być twoja własna korporacyjna **Microsoft Active Directory** (poprzez **SAML**) lub usługi **OpenID** (takie jak **Google**). Dostęp federacyjny pozwoli użytkownikom w nim na dostęp do AWS.
|
||||
Przykładem dostawcy tożsamości może być twoje własne korporacyjne **Microsoft Active Directory** (poprzez **SAML**) lub usługi **OpenID** (jak **Google**). Dostęp federacyjny pozwoli użytkownikom w nim na dostęp do AWS.
|
||||
|
||||
Aby skonfigurować to zaufanie, generowany jest **dostawca tożsamości IAM (SAML lub OAuth)**, który **ufa** **innej platformie**. Następnie co najmniej jedna **rola IAM jest przypisywana (ufająca) do dostawcy tożsamości**. Jeśli użytkownik z zaufanej platformy uzyskuje dostęp do AWS, uzyskuje dostęp jako wspomniana rola.
|
||||
Aby skonfigurować to zaufanie, generowany jest **dostawca tożsamości IAM (SAML lub OAuth)**, który **ufa** **innej platformie**. Następnie przynajmniej jedna **rola IAM jest przypisywana (ufająca) do dostawcy tożsamości**. Jeśli użytkownik z zaufanej platformy uzyskuje dostęp do AWS, uzyskuje dostęp jako wspomniana rola.
|
||||
|
||||
Jednak zazwyczaj chcesz nadać **inną rolę w zależności od grupy użytkownika** na zewnętrznej platformie. Wtedy kilka **ról IAM może ufać** zewnętrznemu dostawcy tożsamości, a zewnętrzna platforma będzie tą, która pozwoli użytkownikom przyjąć jedną rolę lub inną.
|
||||
Jednak zazwyczaj będziesz chciał nadać **inną rolę w zależności od grupy użytkownika** na zewnętrznej platformie. Wtedy kilka **ról IAM może ufać** zewnętrznemu dostawcy tożsamości, a zewnętrzna platforma będzie tą, która pozwoli użytkownikom na przyjęcie jednej lub drugiej roli.
|
||||
|
||||
<figure><img src="../../../images/image (247).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -267,7 +267,7 @@ Domena logowania będzie wyglądać jak `<user_input>.awsapps.com`.
|
||||
|
||||
Aby zalogować użytkowników, można użyć 3 źródeł tożsamości:
|
||||
|
||||
- Directory Identity Center: Zwykli użytkownicy AWS
|
||||
- Katalog Identity Center: Zwykli użytkownicy AWS
|
||||
- Active Directory: Obsługuje różne konektory
|
||||
- Zewnętrzny dostawca tożsamości: Wszyscy użytkownicy i grupy pochodzą z zewnętrznego dostawcy tożsamości (IdP)
|
||||
|
||||
@@ -275,7 +275,7 @@ Aby zalogować użytkowników, można użyć 3 źródeł tożsamości:
|
||||
|
||||
W najprostszym przypadku katalogu Identity Center, **Identity Center będzie miał listę użytkowników i grup** i będzie mógł **przypisywać polityki** do nich do **dowolnych kont** organizacji.
|
||||
|
||||
Aby nadać dostęp użytkownikowi/grupie Identity Center do konta, **zostanie utworzony zaufany dostawca tożsamości SAML**, a **rola zaufana dostawcy tożsamości z wskazanymi politykami zostanie utworzona** w docelowym koncie.
|
||||
Aby nadać dostęp użytkownikowi/grupie Identity Center do konta, **zostanie utworzony zaufany dostawca tożsamości SAML**, a **rola ufająca dostawcy tożsamości z wskazanymi politykami zostanie utworzona** w docelowym koncie.
|
||||
|
||||
#### AwsSSOInlinePolicy
|
||||
|
||||
@@ -294,7 +294,7 @@ Nieobsługiwane:
|
||||
|
||||
- Relacje zaufania
|
||||
- Centrum administracyjne AD
|
||||
- Pełne wsparcie PS API
|
||||
- Pełne wsparcie dla PS API
|
||||
- Kosz na śmieci AD
|
||||
- Zarządzane konta usług grupowych
|
||||
- Rozszerzenia schematu
|
||||
@@ -333,7 +333,7 @@ Na [**tej stronie**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_
|
||||
|
||||
### Zalecane uprawnienia do audytu kont
|
||||
|
||||
Następujące uprawnienia przyznają różny dostęp do odczytu metadanych:
|
||||
Następujące uprawnienia przyznają różny dostęp do metadanych:
|
||||
|
||||
- `arn:aws:iam::aws:policy/SecurityAudit`
|
||||
- `arn:aws:iam::aws:policy/job-function/ViewOnlyAccess`
|
||||
@@ -361,7 +361,7 @@ aws_access_key_id = AKIA8YDCu7TGTR356SHYT
|
||||
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
|
||||
region = eu-west-2
|
||||
```
|
||||
Jeśli musisz uzyskać dostęp do **różnych kont AWS** i Twój profil ma przyznany dostęp do **przyjęcia roli w tych kontach**, nie musisz ręcznie wywoływać STS za każdym razem (`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`) i konfigurować poświadczeń.
|
||||
Jeśli musisz uzyskać dostęp do **różnych kont AWS** i Twój profil ma dostęp do **przyjęcia roli w tych kontach**, nie musisz ręcznie wywoływać STS za każdym razem (`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`) i konfigurować poświadczeń.
|
||||
|
||||
Możesz użyć pliku `~/.aws/config`, aby [**wskazać, które role przyjąć**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html), a następnie użyć parametru `--profile` jak zwykle (operacja `assume-role` zostanie wykonana w sposób przezroczysty dla użytkownika).\
|
||||
Przykład pliku konfiguracyjnego:
|
||||
|
||||
+1
-1
@@ -26,7 +26,7 @@ aws-warm-lambda-persistence.md
|
||||
|
||||
### Kradzież żądań URL innych Lambda i żądań rozszerzeń
|
||||
|
||||
Wykorzystując Lambda Layers, możliwe jest również nadużywanie rozszerzeń i utrzymywanie się w lambda, ale także kradzież i modyfikacja żądań.
|
||||
Wykorzystując Lambda Layers, możliwe jest również nadużywanie rozszerzeń i utrzymywanie się w lambda, ale także kradzież i modyfikowanie żądań.
|
||||
|
||||
{{#ref}}
|
||||
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
|
||||
|
||||
+3
-3
@@ -24,7 +24,7 @@ Na poniższej stronie masz **przykład eksploatacji** z dodatkowym uprawnieniem
|
||||
iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md
|
||||
{{#endref}}
|
||||
|
||||
**Potencjalny wpływ:** Privesc do roli usługi cloudformation, która została określona.
|
||||
**Potencjalny wpływ:** Privesc do roli usługi cloudformation określonej.
|
||||
|
||||
### `iam:PassRole`, (`cloudformation:UpdateStack` | `cloudformation:SetStackPolicy`)
|
||||
|
||||
@@ -79,7 +79,7 @@ aws cloudformation describe-stacks \
|
||||
--stack-name privesc \
|
||||
--region eu-west-1
|
||||
```
|
||||
Uprawnienie `cloudformation:SetStackPolicy` może być użyte do **przyznania sobie uprawnień `ChangeSet`** nad stosem i przeprowadzenia ataku.
|
||||
Uprawnienie `cloudformation:SetStackPolicy` może być użyte do **nadania sobie uprawnień `ChangeSet`** nad stosem i przeprowadzenia ataku.
|
||||
|
||||
**Potencjalny wpływ:** Privesc do ról serwisowych cloudformation.
|
||||
|
||||
@@ -105,7 +105,7 @@ Napastnik mógłby nadużyć tego uprawnienia bez uprawnienia passRole, aby aktu
|
||||
|
||||
## AWS CDK
|
||||
|
||||
AWS cdk to zestaw narzędzi umożliwiający użytkownikom definiowanie ich infrastruktury jako kodu w językach, które już znają, a także łatwe ponowne używanie sekcji. CDK następnie przekształca kod wysokiego poziomu (tj. python) w szablony Cloudformation (yaml lub json).
|
||||
AWS cdk to zestaw narzędzi umożliwiający użytkownikom definiowanie swojej infrastruktury jako kodu w językach, które już znają, a także łatwe ponowne używanie sekcji. CDK następnie przekształca kod wysokiego poziomu (tj. python) w szablony Cloudformation (yaml lub json).
|
||||
|
||||
Aby używać CDK, użytkownik administracyjny musi najpierw uruchomić bootstrap konta, co tworzy kilka ról IAM, w tym *rolę exec*, która ma uprawnienia \*/\*. Te role mają strukturę nazewnictwa `cdk-<qualifier>-<name>-<account-id>-<region>`. Bootstrap musi być wykonany raz na region na konto.
|
||||
|
||||
|
||||
+2
-2
@@ -4,7 +4,7 @@
|
||||
|
||||
## CloudFormation
|
||||
|
||||
AWS CloudFormation to usługa zaprojektowana w celu **usprawnienia zarządzania zasobami AWS**. Umożliwia użytkownikom skupienie się bardziej na ich aplikacjach działających w AWS, **minimalizując czas poświęcony na zarządzanie zasobami**. Główną cechą tej usługi jest **szablon**—opisowy model pożądanych zasobów AWS. Po dostarczeniu tego szablonu, CloudFormation jest odpowiedzialny za **provisioning i konfigurację** określonych zasobów. Ta automatyzacja ułatwia bardziej efektywne i bezbłędne zarządzanie infrastrukturą AWS.
|
||||
AWS CloudFormation to usługa zaprojektowana w celu **usprawnienia zarządzania zasobami AWS**. Umożliwia użytkownikom skupienie się bardziej na ich aplikacjach działających w AWS, **minimalizując czas poświęcony na zarządzanie zasobami**. Główna cecha tej usługi to **szablon**—opisowy model pożądanych zasobów AWS. Po dostarczeniu tego szablonu, CloudFormation jest odpowiedzialny za **provisioning i konfigurację** określonych zasobów. Ta automatyzacja ułatwia bardziej efektywne i bezbłędne zarządzanie infrastrukturą AWS.
|
||||
|
||||
### Enumeration
|
||||
```bash
|
||||
@@ -49,7 +49,7 @@ Sprawdź **sekrety** lub wrażliwe informacje w **szablonie, parametrach i wyjś
|
||||
|
||||
## Codestar
|
||||
|
||||
AWS CodeStar to usługa do tworzenia, zarządzania i pracy z projektami rozwoju oprogramowania na AWS. Możesz szybko rozwijać, budować i wdrażać aplikacje na AWS za pomocą projektu AWS CodeStar. Projekt AWS CodeStar tworzy i **integruje usługi AWS** dla twojego narzędzia do rozwoju projektu. W zależności od wybranego szablonu projektu AWS CodeStar, to narzędzie może obejmować kontrolę wersji, budowanie, wdrażanie, wirtualne serwery lub zasoby bezserwerowe i inne. AWS CodeStar również **zarządza uprawnieniami wymaganymi dla użytkowników projektu** (nazywanych członkami zespołu).
|
||||
AWS CodeStar to usługa do tworzenia, zarządzania i pracy z projektami rozwoju oprogramowania na AWS. Możesz szybko rozwijać, budować i wdrażać aplikacje na AWS za pomocą projektu AWS CodeStar. Projekt AWS CodeStar tworzy i **integruje usługi AWS** dla twojego narzędzia do rozwoju projektu. W zależności od wybranego szablonu projektu AWS CodeStar, to narzędzie może obejmować kontrolę wersji, budowę, wdrożenie, serwery wirtualne lub zasoby bezserwerowe i inne. AWS CodeStar również **zarządza uprawnieniami wymaganymi dla użytkowników projektu** (nazywanych członkami zespołu).
|
||||
|
||||
### Enumeration
|
||||
```bash
|
||||
|
||||
Reference in New Issue
Block a user