gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-30 22:50:43 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/README.md', 'src/banners/hacktricks-training.md', 'src/

Browse Source
This commit is contained in:
Translator
2024-12-31 20:29:08 +00:00
parent 2753c75e8b
commit 396dbafaf2
245 changed files with 9878 additions and 12609 deletions
Download Patch File Download Diff File Expand all files Collapse all files

396
src/pentesting-cloud/aws-security/aws-basic-information/README.md
View File

@@ -1,331 +1,313 @@
# AWS - Basic Information
# AWS - Basiese Inligting
{{#include ../../../banners/hacktricks-training.md}}
## Organization Hierarchy
## Organisasie Hiërargie
![](<../../../images/image (151).png>)
### Accounts
### Rekeninge
In AWS there is a **root account,** which is the **parent container for all the accounts** for your **organization**. However, you don't need to use that account to deploy resources, you can create **other accounts to separate different AWS** infrastructures between them.
In AWS is daar 'n **root rekening,** wat die **ouerhouer is vir al die rekening** vir jou **organisasie**. U hoef egter nie daardie rekening te gebruik om hulpbronne te ontplooi nie, u kan **ander rekeninge skep om verskillende AWS** infrastruktuur van mekaar te skei.
This is very interesting from a **security** point of view, as **one account won't be able to access resources from other account** (except bridges are specifically created), so this way you can create boundaries between deployments.
Dit is baie interessant vanuit 'n **veiligheid** oogpunt, aangesien **een rekening nie in staat sal wees om hulpbronne van 'n ander rekening te benader** (behalwe as brûe spesifiek geskep word), so op hierdie manier kan u grense tussen ontplooiings skep.
Therefore, there are **two types of accounts in an organization** (we are talking about AWS accounts and not User accounts): a single account that is designated as the management account, and one or more member accounts.
Daarom is daar **twee tipes rekeninge in 'n organisasie** (ons praat van AWS rekeninge en nie gebruikersrekeninge nie): 'n enkele rekening wat as die bestuurrekening aangewys word, en een of meer lidrekeninge.
- The **management account (the root account)** is the account that you use to create the organization. From the organization's management account, you can do the following:
- Die **bestuurrekening (die root rekening)** is die rekening wat u gebruik om die organisasie te skep. Van die organisasie se bestuurrekening kan u die volgende doen:
- Create accounts in the organization
- Invite other existing accounts to the organization
- Remove accounts from the organization
- Manage invitations
- Apply policies to entities (roots, OUs, or accounts) within the organization
- Enable integration with supported AWS services to provide service functionality across all of the accounts in the organization.
- It's possible to login as the root user using the email and password used to create this root account/organization.
- Skep rekeninge in die organisasie
- Nooi ander bestaande rekeninge na die organisasie
- Verwyder rekeninge uit die organisasie
- Bestuur uitnodigings
- Pas beleide toe op entiteite (wortels, OU's, of rekeninge) binne die organisasie
- Aktiveer integrasie met ondersteunende AWS dienste om diensfunksionaliteit oor al die rekeninge in die organisasie te bied.
- Dit is moontlik om in te log as die root gebruiker met die e-pos en wagwoord wat gebruik is om hierdie root rekening/organisasie te skep.
The management account has the **responsibilities of a payer account** and is responsible for paying all charges that are accrued by the member accounts. You can't change an organization's management account.
- **Member accounts** make up all of the rest of the accounts in an organization. An account can be a member of only one organization at a time. You can attach a policy to an account to apply controls to only that one account.
- Member accounts **must use a valid email address** and can have a **name**, in general they wont be able to manage the billing (but they might be given access to it).
Die bestuurrekening het die **verantwoordelikhede van 'n betaler rekening** en is verantwoordelik vir die betaling van alle koste wat deur die lidrekeninge opgeloop word. U kan nie 'n organisasie se bestuurrekening verander nie.
- **Lidrekeninge** maak al die res van die rekeninge in 'n organisasie uit. 'n Rekening kan slegs 'n lid van een organisasie op 'n slag wees. U kan 'n beleid aan 'n rekening koppel om kontroles slegs op daardie een rekening toe te pas.
- Lidrekeninge **moet 'n geldige e-posadres gebruik** en kan 'n **naam** hê, in die algemeen sal hulle nie in staat wees om die faktuur te bestuur nie (maar hulle mag toegang daartoe gegee word).
```
aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com
```
### **Organisasie-eenhede**
### **Organization Units**
Accounts can be grouped in **Organization Units (OU)**. This way, you can create **policies** for the Organization Unit that are going to be **applied to all the children accounts**. Note that an OU can have other OUs as children.
Rekeninge kan gegroepeer word in **Organisasie-eenhede (OU)**. Op hierdie manier kan jy **beleide** vir die Organisasie-eenheid skep wat gaan wees **toegepas op al die kindrekening**. Let daarop dat 'n OU ander OU's as kinders kan hê.
```bash
# 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)
A **service control policy (SCP)** is a policy that specifies the services and actions that users and roles can use in the accounts that the SCP affects. SCPs are **similar to IAM** permissions policies except that they **don't grant any permissions**. Instead, SCPs specify the **maximum permissions** for an organization, organizational unit (OU), or account. When you attach a SCP to your organization root or an OU, the **SCP limits permissions for entities in member accounts**.
'n **service control policy (SCP)** is 'n beleid wat die dienste en aksies spesifiseer wat gebruikers en rolle in die rekeninge wat die SCP beïnvloed, kan gebruik. SCP's is **soortgelyk aan IAM** toestemmingsbeleide, behalwe dat hulle **nie enige toestemmings toeken nie**. In plaas daarvan spesifiseer SCP's die **maksimum toestemmings** vir 'n organisasie, organisatoriese eenheid (OU), of rekening. Wanneer jy 'n SCP aan jou organisasie wortel of 'n OU heg, **beperk die SCP toestemmings vir entiteite in lid rekeninge**.
This is the ONLY way that **even the root user can be stopped** from doing something. For example, it could be used to stop users from disabling CloudTrail or deleting backups.\
The only way to bypass this is to compromise also the **master account** that configures the SCPs (master account cannot be blocked).
Dit is die ENIGE manier waarop **selfs die wortelgebruiker gestop kan word** om iets te doen. Byvoorbeeld, dit kan gebruik word om gebruikers te stop om CloudTrail te deaktiveer of rugsteun te verwyder.\
Die enigste manier om dit te omseil, is om ook die **master account** wat die SCP's konfigureer, te kompromitteer (master account kan nie geblokkeer word nie).
> [!WARNING]
> Note that **SCPs only restrict the principals in the account**, so other accounts are not affected. This means having an SCP deny `s3:GetObject` will not stop people from **accessing a public S3 bucket** in your account.
> Let daarop dat **SCP's slegs die principals in die rekening beperk**, so ander rekeninge word nie beïnvloed nie. Dit beteken dat 'n SCP wat `s3:GetObject` weier, nie mense sal stop om **toegang te verkry tot 'n openbare S3-bucket** in jou rekening nie.
SCP examples:
SCP voorbeelde:
- Deny the root account entirely
- Only allow specific regions
- Only allow white-listed services
- Deny GuardDuty, CloudTrail, and S3 Public Block Access from
- Weier die wortelrekening heeltemal
- Laat slegs spesifieke streke toe
- Laat slegs witgelysde dienste toe
- Weier GuardDuty, CloudTrail, en S3 Publieke Blok Toegang van
being disabled
om gedeaktiveer te word
- Deny security/incident response roles from being deleted or
- Weier sekuriteit/voorval respons rolle om verwyder of
modified.
gewysig te word.
- Deny backups from being deleted.
- Deny creating IAM users and access keys
- Weier rugsteun om verwyder te word.
- Weier die skep van IAM gebruikers en toegang sleutels
Find **JSON examples** in [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
Vind **JSON voorbeelde** in [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
### ARN
**Amazon Resource Name** is the **unique name** every resource inside AWS has, its composed like this:
**Amazon Resource Name** is die **unieke naam** wat elke hulpbron binne AWS het, dit is soos volg saamgestel:
```
arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env
```
Note that there are 4 partitions in AWS but only 3 ways to call them:
Note dat daar 4 partities in AWS is, maar slegs 3 maniere om hulle te noem:
- AWS Standard: `aws`
- AWS China: `aws-cn`
- AWS US public Internet (GovCloud): `aws-us-gov`
- AWS US publieke Internet (GovCloud): `aws-us-gov`
- AWS Secret (US Classified): `aws`
## IAM - Identity and Access Management
## IAM - Identiteit en Toegang Bestuur
IAM is the service that will allow you to manage **Authentication**, **Authorization** and **Access Control** inside your AWS account.
IAM is die diens wat jou sal toelaat om **Verifikasie**, **Magtiging** en **Toegangsbeheer** binne jou AWS-rekening te bestuur.
- **Authentication** - Process of defining an identity and the verification of that identity. This process can be subdivided in: Identification and verification.
- **Authorization** - Determines what an identity can access within a system once it's been authenticated to it.
- **Access Control** - The method and process of how access is granted to a secure resource
- **Verifikasie** - Proses om 'n identiteit te definieer en die verifikasie van daardie identiteit. Hierdie proses kan onderverdeel word in: Identifikasie en verifikasie.
- **Magtiging** - Bepaal wat 'n identiteit kan toegang tot binne 'n stelsel nadat dit geverifieer is.
- **Toegangsbeheer** - Die metode en proses van hoe toegang tot 'n veilige hulpbron toegestaan word.
IAM can be defined by its ability to manage, control and govern authentication, authorization and access control mechanisms of identities to your resources within your AWS account.
IAM kan gedefinieer word deur sy vermoë om verifikasie, magtiging en toegangsbeheer meganismes van identiteite na jou hulpbronne binne jou AWS-rekening te bestuur, te beheer en te regeer.
### [AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>
### [AWS rekening wortel gebruiker](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>
When you first create an Amazon Web Services (AWS) account, you begin with a single sign-in identity that has **complete access to all** AWS services and resources in the account. This is the AWS account _**root user**_ and is accessed by signing in with the **email address and password that you used to create the account**.
Wanneer jy vir die eerste keer 'n Amazon Web Services (AWS) rekening skep, begin jy met 'n enkele aanmeld identiteit wat **volledige toegang tot alle** AWS dienste en hulpbronne in die rekening het. Dit is die AWS rekening _**wortel gebruiker**_ en word verkry deur in te teken met die **e-posadres en wagwoord wat jy gebruik het om die rekening te skep**.
Note that a new **admin user** will have **less permissions that the root user**.
Let daarop dat 'n nuwe **admin gebruiker** **minder toestemmings sal hê as die wortel gebruiker**.
From a security point of view, it's recommended to create other users and avoid using this one.
Vanuit 'n sekuriteits oogpunt, word dit aanbeveel om ander gebruikers te skep en om hierdie een te vermy.
### [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
### [IAM gebruikers](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
An IAM _user_ is an entity that you create in AWS to **represent the person or application** that uses it to **interact with AWS**. A user in AWS consists of a name and credentials (password and up to two access keys).
'n IAM _gebruiker_ is 'n entiteit wat jy in AWS skep om **die persoon of toepassing** wat dit gebruik om **met AWS te kommunikeer** te **verteenwoordig**. 'n Gebruiker in AWS bestaan uit 'n naam en geloofsbriewe (wagwoord en tot twee toegang sleutels).
When you create an IAM user, you grant it **permissions** by making it a **member of a user group** that has appropriate permission policies attached (recommended), or by **directly attaching policies** to the user.
Wanneer jy 'n IAM gebruiker skep, gee jy dit **toestemmings** deur dit 'n **lid van 'n gebruikersgroep** te maak wat toepaslike toestemming beleide het (aanbeveel), of deur **beleide direk aan die gebruiker te heg**.
Users can have **MFA enabled to login** through the console. API tokens of MFA enabled users aren't protected by MFA. If you want to **restrict the access of a users API keys using MFA** you need to indicate in the policy that in order to perform certain actions MFA needs to be present (example [**here**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)).
Gebruikers kan **MFA geaktiveer hê om in te teken** deur die konsole. API tokens van MFA geaktiveerde gebruikers is nie deur MFA beskerm nie. As jy wil **die toegang van 'n gebruiker se API sleutels met MFA beperk**, moet jy in die beleid aandui dat om sekere aksies uit te voer, MFA teenwoordig moet wees (voorbeeld [**hier**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)).
#### CLI
- **Access Key ID**: 20 random uppercase alphanumeric characters like AKHDNAPO86BSHKDIRYT
- **Secret access key ID**: 40 random upper and lowercase characters: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (It's not possible to retrieve lost secret access key IDs).
- **Toegang Sleutel ID**: 20 ewekansige hoofletters alfanumeriese karakters soos AKHDNAPO86BSHKDIRYT
- **Geheime toegang sleutel ID**: 40 ewekansige hoë en lae letters: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Dit is nie moontlik om verlore geheime toegang sleutel ID's te herstel nie).
Whenever you need to **change the Access Key** this is the process you should follow:\
&#xNAN;_&#x43;reate a new access key -> Apply the new key to system/application -> mark original one as inactive -> Test and verify new access key is working -> Delete old access key_
Wanneer jy die **Toegang Sleutel** moet **verander**, is dit die proses wat jy moet volg:\
&#xNAN;_&#x43;reate 'n nuwe toegang sleutel -> Pas die nuwe sleutel toe op stelsel/toepassing -> merk oorspronklike een as inaktief -> Toets en verifieer dat die nuwe toegang sleutel werk -> Verwyder ou toegang sleutel_
### MFA - Multi Factor Authentication
### MFA - Multi Faktor Verifikasie
It's used to **create an additional factor for authentication** in addition to your existing methods, such as password, therefore, creating a multi-factor level of authentication.\
You can use a **free virtual application or a physical device**. You can use apps like google authentication for free to activate a MFA in AWS.
Dit word gebruik om 'n **addisionele faktor vir verifikasie** te skep benewens jou bestaande metodes, soos wagwoord, en skep dus 'n multi-faktor vlak van verifikasie.\
Jy kan 'n **gratis virtuele toepassing of 'n fisiese toestel** gebruik. Jy kan toepassings soos google verifikasie gratis gebruik om 'n MFA in AWS te aktiveer.
Policies with MFA conditions can be attached to the following:
Beleide met MFA voorwaardes kan aan die volgende geheg word:
- An IAM user or group
- A resource such as an Amazon S3 bucket, Amazon SQS queue, or Amazon SNS topic
- The trust policy of an IAM role that can be assumed by a user
If you want to **access via CLI** a resource that **checks for MFA** you need to call **`GetSessionToken`**. That will give you a token with info about MFA.\
Note that **`AssumeRole` credentials don't contain this information**.
- 'n IAM gebruiker of groep
- 'n hulpbron soos 'n Amazon S3 emmer, Amazon SQS tou, of Amazon SNS onderwerp
- Die vertrouensbeleid van 'n IAM rol wat deur 'n gebruiker aanvaar kan word
As jy 'n hulpbron wil **toegang via CLI** wat **MFA nagaan**, moet jy **`GetSessionToken`** aanroep. Dit sal vir jou 'n token gee met inligting oor MFA.\
Let daarop dat **`AssumeRole` geloofsbriewe nie hierdie inligting bevat nie**.
```bash
aws sts get-session-token --serial-number <arn_device> --token-code <code>
```
As [**hier genoem**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), daar is 'n baie verskillende gevalle waar **MFA nie gebruik kan word** nie.
As [**stated here**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), there are a lot of different cases where **MFA cannot be used**.
### [IAM gebruikersgroepe](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
### [IAM user groups](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
'n IAM [gebruikersgroep](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) is 'n manier om **beleide aan verskeie gebruikers** op een slag te **koppel**, wat dit makliker kan maak om die toestemmings vir daardie gebruikers te bestuur. **Rol en groepe kan nie deel wees van 'n groep** nie.
An IAM [user group](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) is a way to **attach policies to multiple users** at one time, which can make it easier to manage the permissions for those users. **Roles and groups cannot be part of a group**.
Jy kan 'n **identiteitsgebaseerde beleid aan 'n gebruikersgroep** koppel sodat al die **gebruikers** in die gebruikersgroep **die beleid se toestemmings ontvang**. Jy **kan nie** 'n **gebruikersgroep** as 'n **`Principal`** in 'n **beleid** identifiseer (soos 'n hulpbron-gebaseerde beleid) nie, omdat groepe met toestemmings verband hou, nie verifikasie nie, en principals is geverifieerde IAM entiteite.
You can attach an **identity-based policy to a user group** so that all of the **users** in the user group **receive the policy's permissions**. You **cannot** identify a **user group** as a **`Principal`** in a **policy** (such as a resource-based policy) because groups relate to permissions, not authentication, and principals are authenticated IAM entities.
Hier is 'n paar belangrike eienskappe van gebruikersgroepe:
Here are some important characteristics of user groups:
- 'n gebruikers **groep** kan **baie gebruikers** **bevat**, en 'n **gebruiker** kan **tot verskeie groepe behoort**.
- **Gebruikersgroepe kan nie geneste** wees nie; hulle kan slegs gebruikers bevat, nie ander gebruikersgroepe nie.
- Daar is **geen standaard gebruikersgroep wat outomaties al die gebruikers in die AWS-rekening insluit** nie. As jy 'n gebruikersgroep soos dit wil hê, moet jy dit skep en elke nuwe gebruiker daaraan toewys.
- Die aantal en grootte van IAM hulpbronne in 'n AWS-rekening, soos die aantal groepe, en die aantal groepe waarvan 'n gebruiker 'n lid kan wees, is beperk. Vir meer inligting, sien [IAM en AWS STS kwotas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
- A user **group** can **contain many users**, and a **user** can **belong to multiple groups**.
- **User groups can't be nested**; they can contain only users, not other user groups.
- There is **no default user group that automatically includes all users in the AWS account**. If you want to have a user group like that, you must create it and assign each new user to it.
- The number and size of IAM resources in an AWS account, such as the number of groups, and the number of groups that a user can be a member of, are limited. For more information, see [IAM and AWS STS quotas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
### [IAM rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
### [IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
'n IAM **rol** is baie **soortgelyk** aan 'n **gebruiker**, in die sin dat dit 'n **identiteit met toestemmingbeleide is wat bepaal wat** dit kan en nie kan doen in AWS nie. egter, 'n rol **het nie enige geloofsbriewe** (wagwoord of toegang sleutels) wat daarmee geassosieer is nie. In plaas daarvan om uniek aan een persoon geassosieer te wees, is 'n rol bedoel om **aangenome te word deur enigeen wat dit nodig het (en genoeg perms het)**. 'n **IAM gebruiker kan 'n rol aanvaar om tydelik** verskillende toestemmings vir 'n spesifieke taak aan te neem. 'n rol kan **toegeken word aan 'n** [**gefedereerde gebruiker**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) wat aanmeld deur 'n eksterne identiteitsverskaffer te gebruik in plaas van IAM.
An IAM **role** is very **similar** to a **user**, in that it is an **identity with permission policies that determine what** it can and cannot do in AWS. However, a role **does not have any credentials** (password or access keys) associated with it. Instead of being uniquely associated with one person, a role is intended to be **assumable by anyone who needs it (and have enough perms)**. An **IAM user can assume a role to temporarily** take on different permissions for a specific task. A role can be **assigned to a** [**federated user**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) who signs in by using an external identity provider instead of IAM.
'n IAM rol bestaan uit **twee tipes beleide**: 'n **vertrouensbeleid**, wat nie leeg kan wees nie, wat **definieer wie die rol kan aanvaar**, en 'n **toestemmingsbeleid**, wat nie leeg kan wees nie, wat **definieer wat dit kan toegang**.
An IAM role consists of **two types of policies**: A **trust policy**, which cannot be empty, defining **who can assume** the role, and a **permissions policy**, which cannot be empty, defining **what it can access**.
#### AWS Sekuriteits Token Diens (STS)
#### AWS Security Token Service (STS)
AWS Sekuriteits Token Diens (STS) is 'n webdiens wat die **uitreiking van tydelike, beperkte bevoegdhede** fasiliteer. Dit is spesifiek ontwerp vir:
AWS Security Token Service (STS) is a web service that facilitates the **issuance of temporary, limited-privilege credentials**. It is specifically tailored for:
### [Tydelike geloofsbriewe in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
### [Temporary credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
**Tydelike geloofsbriewe word hoofsaaklik gebruik met IAM rolle**, maar daar is ook ander gebruike. Jy kan tydelike geloofsbriewe aan vra wat 'n meer beperkte stel toestemmings het as jou standaard IAM gebruiker. Dit **verhoed** dat jy **per ongeluk take uitvoer wat nie toegelaat word** deur die meer beperkte geloofsbriewe nie. 'n voordeel van tydelike geloofsbriewe is dat hulle outomaties verval na 'n bepaalde tydperk. Jy het beheer oor die duur waarvoor die geloofsbriewe geldig is.
**Temporary credentials are primarily used with IAM roles**, but there are also other uses. You can request temporary credentials that have a more restricted set of permissions than your standard IAM user. This **prevents** you from **accidentally performing tasks that are not permitted** by the more restricted credentials. A benefit of temporary credentials is that they expire automatically after a set period of time. You have control over the duration that the credentials are valid.
### Beleide
### Policies
#### Beleidstoestemmings
#### Policy Permissions
Word gebruik om toestemmings toe te ken. Daar is 2 tipes:
Are used to assign permissions. There are 2 types:
- AWS managed policies (preconfigured by AWS)
- Customer Managed Policies: Configured by you. You can create policies based on AWS managed policies (modifying one of them and creating your own), using the policy generator (a GUI view that helps you granting and denying permissions) or writing your own..
By **default access** is **denied**, access will be granted if an explicit role has been specified.\
If **single "Deny" exist, it will override the "Allow"**, except for requests that use the AWS account's root security credentials (which are allowed by default).
- AWS bestuurde beleide (voorgeskrewe deur AWS)
- Klant bestuurde beleide: Geconfigureer deur jou. Jy kan beleide skep gebaseer op AWS bestuurde beleide (een van hulle wysig en jou eie skep), deur die beleidgenerator te gebruik (n GUI-weergave wat jou help om toestemmings toe te ken en te weier) of jou eie te skryf.
Deur **standaard toegang** is **weggeneem**, toegang sal toegestaan word as 'n eksplisiete rol gespesifiseer is.\
As **enkele "Weier" bestaan, sal dit die "Toelaat" oorskry**, behalwe vir versoeke wat die AWS-rekening se wortel sekuriteitsgeloofsbriewe gebruik (wat standaard toegelaat word).
```javascript
{
"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"}
}
}
]
"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"}
}
}
]
}
```
Die [globale velde wat gebruik kan word vir voorwaardes in enige diens is hier gedokumenteer](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\
Die [spesifieke velde wat gebruik kan word vir voorwaardes per diens is hier gedokumenteer](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html).
The [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).\
The [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).
#### Inline Beleide
#### Inline Policies
Hierdie tipe beleide is **direk toegeken** aan 'n gebruiker, groep of rol. Dan verskyn hulle nie in die Beleide lys nie soos enige ander een kan hulle gebruik.\
Inline beleide is nuttig as jy wil **'n streng een-tot-een verhouding tussen 'n beleid en die identiteit** wat dit toegepas word, handhaaf. Byvoorbeeld, jy wil seker maak dat die toestemmings in 'n beleid nie per ongeluk aan 'n identiteit anders as die een waarvoor hulle bedoel is, toegeken word nie. Wanneer jy 'n inline beleid gebruik, kan die toestemmings in die beleid nie per ongeluk aan die verkeerde identiteit geheg word nie. Boonop, wanneer jy die AWS Bestuurskonsol gebruik om daardie identiteit te verwyder, word die beleide wat in die identiteit ingebed is, ook verwyder. Dit is omdat hulle deel van die hoof entiteit is.
This kind of policies are **directly assigned** to a user, group or role. Then, they do not appear in the Policies list as any other one can use them.\
Inline policies are useful if you want to **maintain a strict one-to-one relationship between a policy and the identity** that it's applied to. For example, you want to be sure that the permissions in a policy are not inadvertently assigned to an identity other than the one they're intended for. When you use an inline policy, the permissions in the policy cannot be inadvertently attached to the wrong identity. In addition, when you use the AWS Management Console to delete that identity, the policies embedded in the identity are deleted as well. That's because they are part of the principal entity.
#### Hulpbron Emmer Beleide
#### Resource Bucket Policies
Hierdie is **beleide** wat in **hulpbronne** gedefinieer kan word. **Nie alle hulpbronne van AWS ondersteun hulle nie**.
These are **policies** that can be defined in **resources**. **Not all resources of AWS supports them**.
As 'n hoof nie 'n eksplisiete weiering op hulle het nie, en 'n hulpbronbeleid hulle toegang gee, dan word hulle toegelaat.
If a principal does not have an explicit deny on them, and a resource policy grants them access, then they are allowed.
### IAM Grense
### IAM Boundaries
IAM grense kan gebruik word om **die toestemmings wat 'n gebruiker of rol toegang tot moet hê, te beperk**. Op hierdie manier, selfs al word 'n ander stel toestemmings aan die gebruiker toegeken deur 'n **ander beleid**, sal die operasie **misluk** as hy probeer om hulle te gebruik.
IAM boundaries can be used to **limit the permissions a user or role should have access to**. This way, even if a different set of permissions are granted to the user by a **different policy** the operation will **fail** if he tries to use them.
'n Grens is net 'n beleid wat aan 'n gebruiker geheg is wat **die maksimum vlak van toestemmings wat die gebruiker of rol kan hê, aandui**. So, **selfs al het die gebruiker Administrateur toegang**, as die grens aandui dat hy slegs S· emmers kan lees, is dit die maksimum wat hy kan doen.
A boundary is just a policy attached to a user which **indicates the maximum level of permissions the user or role can have**. So, **even if the user has Administrator access**, if the boundary indicates he can only read S· buckets, that's the maximum he can do.
**Dit**, **SCPs** en **die beginsel van die minste voorreg** is die maniere om te beheer dat gebruikers nie meer toestemmings het as wat hulle nodig het nie.
**This**, **SCPs** and **following the least privilege** principle are the ways to control that users doesn't have more permissions than the ones he needs.
### Sessie Beleide
### Session Policies
A session policy is a **policy set when a role is assumed** somehow. This will be like an **IAM boundary for that session**: This means that the session policy doesn't grant permissions but **restrict them to the ones indicated in the policy** (being the max permissions the ones the role has).
This is useful for **security meassures**: When an admin is going to assume a very privileged role he could restrict the permission to only the ones indicated in the session policy in case the session gets compromised.
'n Sessie beleid is 'n **beleid wat ingestel word wanneer 'n rol aanvaar word** op een of ander manier. Dit sal soos 'n **IAM grens vir daardie sessie wees**: Dit beteken dat die sessie beleid nie toestemmings toeken nie, maar **beperk hulle tot diegene wat in die beleid aangedui word** (met die maksimum toestemmings wat die rol het).
Dit is nuttig vir **veiligheidsmaatreëls**: Wanneer 'n admin 'n baie bevoorregte rol gaan aanvaar, kan hy die toestemming beperk tot slegs diegene wat in die sessie beleid aangedui word in die geval dat die sessie gecompromitteer word.
```bash
aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]
```
Note dat **AWS dalk sessiebeleide aan sessies kan voeg** wat gegenereer gaan word weens derde redes. Byvoorbeeld, in [nie-geverifieerde cognito aangeneemde rolle](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) sal AWS standaard (met verbeterde verifikasie) **sessie-akkrediteer met 'n sessiebeleid** genereer wat die dienste wat die sessie kan toegang hê, beperk [**tot die volgende lys**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
Note that by default **AWS might add session policies to sessions** that are going to be generated because of third reasons. For example, in [unauthenticated cognito assumed roles](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) by default (using enhanced authentication), AWS will generate **session credentials with a session policy** that limits the services that session can access [**to the following list**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
As jy dus op 'n stadium die fout "… omdat geen sessiebeleid dit toelaat nie …" teëkom, en die rol toegang het om die aksie uit te voer, is dit omdat **daar 'n sessiebeleid is wat dit verhinder**.
Therefore, if at some point you face the error "... because no session policy allows the ...", and the role has access to perform the action, it's because **there is a session policy preventing it**.
### Identiteitsfederasie
### Identity Federation
Identiteitsfederasie **laat gebruikers van identiteitsverskaffers wat eksterne** is tot AWS toe om AWS-hulpbronne veilig te benader sonder om AWS-gebruikersakkrediteer van 'n geldige IAM-gebruikersrekening te verskaf.\
'n Voorbeeld van 'n identiteitsverskaffer kan jou eie korporatiewe **Microsoft Active Directory** (via **SAML**) of **OpenID** dienste (soos **Google**) wees. Gefedereerde toegang sal dan die gebruikers binne dit toelaat om AWS te benader.
Identity federation **allows users from identity providers which are external** to AWS to access AWS resources securely without having to supply AWS user credentials from a valid IAM user account.\
An example of an identity provider can be your own corporate **Microsoft Active Directory** (via **SAML**) or **OpenID** services (like **Google**). Federated access will then allow the users within it to access AWS.
Om hierdie vertroue te konfigureer, word 'n **IAM Identiteitsverskaffer gegenereer (SAML of OAuth)** wat die **ander platform** sal **vertrou**. Dan word ten minste een **IAM rol (wat vertrou) aan die Identiteitsverskaffer toegeken**. As 'n gebruiker van die vertroude platform AWS benader, sal hy as die genoemde rol toegang hê.
To configure this trust, an **IAM Identity Provider is generated (SAML or OAuth)** that will **trust** the **other platform**. Then, at least one **IAM role is assigned (trusting) to the Identity Provider**. If a user from the trusted platform access AWS, he will be accessing as the mentioned role.
### IAM Identiteitsentrum
However, you will usually want to give a **different role depending on the group of the user** in the third party platform. Then, several **IAM roles can trust** the third party Identity Provider and the third party platform will be the one allowing users to assume one role or the other.
AWS IAM Identiteitsentrum (opvolger van AWS Enkelteken) brei die vermoëns van AWS Identiteits- en Toegangsbestuur (IAM) uit om 'n **sentraal plek** te bied wat die **administrasie van gebruikers en hul toegang tot AWS** rekeninge en wolktoepassings saambring.
<figure><img src="../../../images/image (247).png" alt=""><figcaption></figcaption></figure>
Die aanmelddomein gaan iets soos `<user_input>.awsapps.com` wees.
### IAM Identity Center
Om gebruikers aan te meld, is daar 3 identiteitsbronne wat gebruik kan word:
AWS IAM Identity Center (successor to AWS Single Sign-On) expands the capabilities of AWS Identity and Access Management (IAM) to provide a **central plac**e that brings together **administration of users and their access to AWS** accounts and cloud applications.
- Identiteitsentrum Gids: Gereelde AWS gebruikers
- Aktiewe Gids: Ondersteun verskillende konnektore
- Eksterne Identiteitsverskaffer: Alle gebruikers en groepe kom van 'n eksterne Identiteitsverskaffer (IdP)
The login domain is going to be something like `<user_input>.awsapps.com`.
In die eenvoudigste geval van die Identiteitsentrum gids, sal die **Identiteitsentrum 'n lys van gebruikers & groepe hê** en sal in staat wees om **beleide** aan hulle toe te ken vir **enige van die rekeninge** van die organisasie.
To login users, there are 3 identity sources that can be used:
- Identity Center Directory: Regular AWS users
- Active Directory: Supports different connectors
- External Identity Provider: All users and groups come from an external Identity Provider (IdP)
<figure><img src="../../../images/image (279).png" alt=""><figcaption></figcaption></figure>
In the simplest case of Identity Center directory, the **Identity Center will have a list of users & groups** and will be able to **assign policies** to them to **any of the accounts** of the organization.
In order to give access to a Identity Center user/group to an account a **SAML Identity Provider trusting the Identity Center will be created**, and a **role trusting the Identity Provider with the indicated policies will be created** in the destination account.
Om toegang aan 'n Identiteitsentrum gebruiker/groep tot 'n rekening te gee, sal 'n **SAML Identiteitsverskaffer wat die Identiteitsentrum vertrou, geskep word**, en 'n **rol wat die Identiteitsverskaffer met die aangeduide beleide vertrou, sal in die bestemmingsrekening geskep word**.
#### AwsSSOInlinePolicy
It's possible to **give permissions via inline policies to roles created via IAM Identity Center**. The roles created in the accounts being given **inline policies in AWS Identity Center** will have these permissions in an inline policy called **`AwsSSOInlinePolicy`**.
Dit is moontlik om **toestemmings via inline beleide aan rolle wat via IAM Identiteitsentrum geskep is, te gee**. Die rolle wat in die rekeninge geskep word wat **inline beleide in AWS Identiteitsentrum** ontvang, sal hierdie toestemmings in 'n inline beleid genaamd **`AwsSSOInlinePolicy`** hê.
Therefore, even if you see 2 roles with an inline policy called **`AwsSSOInlinePolicy`**, it **doesn't mean it has the same permissions**.
Daarom, selfs al sien jy 2 rolle met 'n inline beleid genaamd **`AwsSSOInlinePolicy`**, beteken dit **nie dat dit dieselfde toestemmings het nie**.
### Cross Account Trusts and Roles
### Kruisrekening Vertroue en Rolle
**A user** (trusting) can create a Cross Account Role with some policies and then, **allow another user** (trusted) to **access his account** but only **having the access indicated in the new role policies**. To create this, just create a new Role and select Cross Account Role. Roles for Cross-Account Access offers two options. Providing access between AWS accounts that you own, and providing access between an account that you own and a third party AWS account.\
It's recommended to **specify the user who is trusted and not put some generic thing** because if not, other authenticated users like federated users will be able to also abuse this trust.
**'n gebruiker** (wat vertrou) kan 'n Kruisrekening Rol met sommige beleide skep en dan **'n ander gebruiker** (wat vertrou) toelaat om **sy rekening te benader** maar slegs **met die toegang wat in die nuwe rolbeleide aangedui is**. Om dit te skep, skep eenvoudig 'n nuwe Rol en kies Kruisrekening Rol. Rolle vir Kruisrekening Toegang bied twee opsies. Om toegang te bied tussen AWS rekeninge wat jy besit, en om toegang te bied tussen 'n rekening wat jy besit en 'n derdeparty AWS rekening.\
Dit word aanbeveel om **die gebruiker wat vertrou is spesifiek aan te dui en nie 'n generiese ding te plaas nie**, want anders kan ander geverifieerde gebruikers soos gefedereerde gebruikers ook hierdie vertroue misbruik.
### AWS Simple AD
### AWS Eenvoudige AD
Not supported:
Nie ondersteun nie:
- Trust Relations
- AD Admin Center
- Full PS API support
- AD Recycle Bin
- Group Managed Service Accounts
- Schema Extensions
- No Direct access to OS or Instances
- Vertrouensverhoudings
- AD Admin Sentrum
- Volledige PS API ondersteuning
- AD Herwinningsblik
- Groep Gemanagte Diensrekeninge
- Skema-uitbreidings
- Geen Direkte toegang tot OS of Instansies nie
#### Web Federation or OpenID Authentication
#### Web Federasie of OpenID Verifikasie
The app uses the AssumeRoleWithWebIdentity to create temporary credentials. However, this doesn't grant access to the AWS console, just access to resources within AWS.
Die toepassing gebruik die AssumeRoleWithWebIdentity om tydelike akkrediteer te skep. Dit gee egter nie toegang tot die AWS-konsol nie, net toegang tot hulpbronne binne AWS.
### Other IAM options
### Ander IAM opsies
- You can **set a password policy setting** options like minimum length and password requirements.
- You can **download "Credential Report"** with information about current credentials (like user creation time, is password enabled...). You can generate a credential report as often as once every **four hours**.
- Jy kan **'n wagwoordbeleid instelling** opsies soos minimum lengte en wagwoordvereistes stel.
- Jy kan **"Akkrediteer Verslag" aflaai** met inligting oor huidige akkrediteer (soos gebruikers skeppingstyd, is wagwoord geaktiveer...). Jy kan 'n akkrediteer verslag genereer so dikwels as een keer elke **vier uur**.
AWS Identity and Access Management (IAM) provides **fine-grained access control** across all of AWS. With IAM, you can specify **who can access which services and resources**, and under which conditions. With IAM policies, you manage permissions to your workforce and systems to **ensure least-privilege permissions**.
AWS Identiteits- en Toegangsbestuur (IAM) bied **fyn-graad toegangbeheer** oor al die AWS. Met IAM kan jy spesifiseer **wie toegang het tot watter dienste en hulpbronne**, en onder watter omstandighede. Met IAM beleide bestuur jy toestemmings aan jou werksmag en stelsels om **minste-bevoegdheidstoestemmings** te verseker.
### IAM ID Prefixes
### IAM ID Vooraf
In [**this page**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) you can find the **IAM ID prefixe**d of keys depending on their nature:
In [**hierdie bladsy**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) kan jy die **IAM ID vooraf** van sleutels vind, afhangende van hul aard:
| ABIA | [AWS STS service bearer token](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
| ABIA | [AWS STS diens draer token](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
| ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ACCA | Context-specific credential |
| AGPA | User group |
| AIDA | IAM user |
| AIPA | Amazon EC2 instance profile |
| AKIA | Access key |
| ANPA | Managed policy |
| ANVA | Version in a managed policy |
| APKA | Public key |
| AROA | Role |
| ASCA | Certificate |
| ASIA | [Temporary (AWS STS) access key IDs](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) use this prefix, but are unique only in combination with the secret access key and the session token. |
| ACCA | Konteks-spesifieke akkrediteer |
| AGPA | Gebruikersgroep |
| AIDA | IAM gebruiker |
| AIPA | Amazon EC2 instansieprofiel |
| AKIA | Toegangssleutel |
| ANPA | Gemanagte beleid |
| ANVA | Weergawe in 'n gemanagte beleid |
| APKA | Publieke sleutel |
| AROA | Rol |
| ASCA | Sertifikaat |
| ASIA | [Tydelike (AWS STS) toegangssleutel ID's](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) gebruik hierdie vooraf, maar is uniek slegs in kombinasie met die geheime toegangssleutel en die sessietoken. |
### Recommended permissions to audit accounts
### Aanbevole toestemmings om rekeninge te oudit
The following privileges grant various read access of metadata:
Die volgende voorregte bied verskeie lees toegang van metadata:
- `arn:aws:iam::aws:policy/SecurityAudit`
- `arn:aws:iam::aws:policy/job-function/ViewOnlyAccess`
@@ -336,14 +318,13 @@ The following privileges grant various read access of metadata:
- `directconnect:DescribeConnections`
- `dynamodb:ListTables`
## Misc
## Verskeie
### CLI Authentication
In order for a regular user authenticate to AWS via CLI you need to have **local credentials**. By default you can configure them **manually** in `~/.aws/credentials` or by **running** `aws configure`.\
In that file you can have more than one profile, if **no profile** is specified using the **aws cli**, the one called **`[default]`** in that file will be used.\
Example of credentials file with more than 1 profile:
### CLI Verifikasie
Om 'n gereelde gebruiker te laat verifieer by AWS via CLI, moet jy **lokale akkrediteer** hê. Standaard kan jy dit **handmatig** in `~/.aws/credentials` konfigureer of deur **te loop** `aws configure`.\
In daardie lêer kan jy meer as een profiel hê, as **geen profiel** gespesifiseer word met die **aws cli**, sal die een genaamd **`[default]`** in daardie lêer gebruik word.\
Voorbeeld van akkrediteer lêer met meer as 1 profiel:
```
[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
@@ -354,12 +335,10 @@ aws_access_key_id = AKIA8YDCu7TGTR356SHYT
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
region = eu-west-2
```
If you need to access **different AWS accounts** and your profile was given access to **assume a role inside those accounts**, you don't need to call manually STS every time (`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`) and configure the credentials.
You can use the `~/.aws/config` file to[ **indicate which roles to assume**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html), and then use the `--profile` param as usual (the `assume-role` will be performed in a transparent way for the user).\
You can use the `~/.aws/config` file to[ **aandui watter rolle om aan te neem**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html), and then use the `--profile` param as usual (the `assume-role` will be performed in a transparent way for the user).\
A config file example:
```
[profile acc2]
region=eu-west-2
@@ -368,23 +347,16 @@ role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional
```
With this config file you can then use aws cli like:
Met hierdie konfigurasie-lêer kan jy dan aws cli gebruik soos:
```
aws --profile acc2 ...
```
As jy op soek is na iets **soortgelyks** soos dit, maar vir die **blaaier**, kan jy die **uitbreiding** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en) kyk.
If you are looking for something **similar** to this but for the **browser** you can check the **extension** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en).
## References
## Verwysings
- [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)
- [https://aws.amazon.com/iam/](https://aws.amazon.com/iam/)
- [https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)
{{#include ../../../banners/hacktricks-training.md}}