Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA

This commit is contained in:
Translator
2025-04-07 01:11:30 +00:00
parent 7470ef064c
commit a80a7f9e97

View File

@@ -33,7 +33,7 @@ aws organizations create-account --account-name testingaccount --email testingac
```
### **Unità Organizzative**
Gli account possono essere raggruppati in **Unità Organizzative (OU)**. In questo modo, puoi creare **politiche** per l'Unità Organizzativa che verranno **applicate a tutti gli account figli**. Nota che un'OU può avere altre OU come figli.
Gli account possono essere raggruppati in **Unità Organizzative (OU)**. In questo modo, puoi creare **politiche** per l'Unità Organizzativa che verranno **applicate a tutti gli account figli**. Tieni presente che un'OU può avere altre OU come figli.
```bash
# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
@@ -42,18 +42,18 @@ aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
Una **service control policy (SCP)** è una politica che specifica i servizi e le azioni che gli utenti e i ruoli possono utilizzare negli account che la SCP influisce. Le SCP sono **simili alle politiche di autorizzazione IAM** tranne per il fatto che **non concedono alcuna autorizzazione**. Invece, le SCP specificano le **autorizzazioni massime** per un'organizzazione, un'unità organizzativa (OU) o un account. Quando si allega una SCP alla radice dell'organizzazione o a un'OU, la **SCP limita le autorizzazioni per le entità negli account membri**.
Questo è l'UNICO modo in cui **anche l'utente root può essere fermato** dal fare qualcosa. Ad esempio, potrebbe essere utilizzato per impedire agli utenti di disabilitare CloudTrail o di eliminare i backup.\
Questo è l'UNICO modo in cui **anche l'utente root può essere bloccato** dal fare qualcosa. Ad esempio, potrebbe essere utilizzato per impedire agli utenti di disabilitare CloudTrail o eliminare backup.\
L'unico modo per bypassare questo è compromettere anche l'**account master** che configura le SCP (l'account master non può essere bloccato).
> [!WARNING]
> Nota che **le SCP limitano solo i principi nell'account**, quindi altri account non sono influenzati. Questo significa che avere una SCP che nega `s3:GetObject` non fermerà le persone dall'**accedere a un bucket S3 pubblico** nel tuo account.
> Nota che **le SCP limitano solo i principi nell'account**, quindi altri account non sono influenzati. Ciò significa che avere una SCP che nega `s3:GetObject` non fermerà le persone dall'**accedere a un bucket S3 pubblico** nel tuo account.
Esempi di SCP:
- Negare completamente l'account root
- Consentire solo regioni specifiche
- Consentire solo servizi in whitelist
- Negare a GuardDuty, CloudTrail e S3 Public Block Access di
- Negare l'accesso a GuardDuty, CloudTrail e S3 Public Block Access da
essere disabilitati
@@ -68,12 +68,12 @@ Trova **esempi JSON** in [https://docs.aws.amazon.com/organizations/latest/userg
### Resource Control Policy (RCP)
Una **resource control policy (RCP)** è una politica che definisce le **autorizzazioni massime per le risorse all'interno della tua organizzazione AWS**. Le RCP sono simili alle politiche IAM nella sintassi ma **non concedono autorizzazioni**—limitano solo le autorizzazioni che possono essere applicate alle risorse da altre politiche. Quando si allega una RCP alla radice dell'organizzazione, a un'unità organizzativa (OU) o a un account, la RCP limita le autorizzazioni delle risorse su tutte le risorse nell'ambito interessato.
Una **resource control policy (RCP)** è una politica che definisce le **autorizzazioni massime per le risorse all'interno della tua organizzazione AWS**. Le RCP sono simili alle politiche IAM nella sintassi ma **non concedono autorizzazioni**—limitano solo le autorizzazioni che possono essere applicate alle risorse da altre politiche. Quando si allega un RCP alla radice dell'organizzazione, a un'unità organizzativa (OU) o a un account, l'RCP limita le autorizzazioni delle risorse su tutte le risorse nell'ambito interessato.
Questo è l'UNICO modo per garantire che **le risorse non possano superare i livelli di accesso predefiniti**—anche se una politica basata su identità o risorsa è troppo permissiva. L'unico modo per bypassare questi limiti è modificare anche la RCP configurata dall'account di gestione della tua organizzazione.
Questo è l'UNICO modo per garantire che **le risorse non possano superare i livelli di accesso predefiniti**—anche se una politica basata su identità o risorsa è troppo permissiva. L'unico modo per bypassare questi limiti è modificare anche l'RCP configurato dall'account di gestione della tua organizzazione.
> [!WARNING]
> Le RCP limitano solo le autorizzazioni che le risorse possono avere. Non controllano direttamente cosa possono fare i principi. Ad esempio, se una RCP nega l'accesso esterno a un bucket S3, garantisce che le autorizzazioni del bucket non consentano mai azioni oltre il limite impostato—anche se una politica basata su risorsa è configurata in modo errato.
> Le RCP limitano solo le autorizzazioni che le risorse possono avere. Non controllano direttamente cosa possono fare i principi. Ad esempio, se un RCP nega l'accesso esterno a un bucket S3, garantisce che le autorizzazioni del bucket non consentano mai azioni oltre il limite impostato—anche se una politica basata su risorse è configurata in modo errato.
Esempi di RCP:
@@ -82,7 +82,7 @@ Esempi di RCP:
- Limitare le autorizzazioni sulle code SQS per prevenire modifiche non autorizzate
- Applicare confini di accesso sui segreti di Secrets Manager per proteggere dati sensibili
Trova esempi in [AWS Organizations Resource Control Policies documentation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)
Trova esempi nella [documentazione delle Resource Control Policies di AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)
### ARN
@@ -102,9 +102,9 @@ Nota che ci sono 4 partizioni in AWS ma solo 3 modi per chiamarle:
IAM è il servizio che ti permetterà di gestire **Autenticazione**, **Autorizzazione** e **Controllo degli Accessi** all'interno del tuo account AWS.
- **Autenticazione** - Processo di definizione di un'identità e la verifica di quell'identità. Questo processo può essere suddiviso in: Identificazione e verifica.
- **Autenticazione** - Processo di definizione di un'identità e verifica di quell'identità. Questo processo può essere suddiviso in: Identificazione e verifica.
- **Autorizzazione** - Determina a cosa un'identità può accedere all'interno di un sistema una volta che è stata autenticata.
- **Controllo degli Accessi** - Il metodo e il processo di come l'accesso è concesso a una risorsa sicura.
- **Controllo degli Accessi** - Il metodo e il processo di come viene concesso l'accesso a una risorsa sicura.
IAM può essere definito dalla sua capacità di gestire, controllare e governare i meccanismi di autenticazione, autorizzazione e controllo degli accessi delle identità alle tue risorse all'interno del tuo account AWS.
@@ -114,7 +114,7 @@ Quando crei per la prima volta un account Amazon Web Services (AWS), inizi con u
Nota che un nuovo **utente admin** avrà **meno permessi dell'utente root**.
Dal punto di vista della sicurezza, è consigliato creare altri utenti ed evitare di utilizzare questo.
Da un punto di vista della sicurezza, è consigliato creare altri utenti ed evitare di utilizzare questo.
### [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
@@ -129,7 +129,7 @@ Gli utenti possono avere **MFA abilitato per il login** attraverso la console. I
- **Access Key ID**: 20 caratteri alfanumerici casuali in maiuscolo come AKHDNAPO86BSHKDIRYT
- **Secret access key ID**: 40 caratteri casuali in maiuscolo e minuscolo: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Non è possibile recuperare gli ID delle chiavi di accesso segrete perse).
Ogni volta che hai bisogno di **cambiare la Access Key**, questo è il processo che dovresti seguire:\
Ogni volta che hai bisogno di **cambiare la chiave di accesso**, questo è il processo che dovresti seguire:\
_Crea una nuova chiave di accesso -> Applica la nuova chiave al sistema/applicazione -> contrassegna quella originale come inattiva -> Testa e verifica che la nuova chiave di accesso funzioni -> Elimina la vecchia chiave di accesso_
### MFA - Multi Factor Authentication
@@ -165,7 +165,7 @@ Ecco alcune caratteristiche importanti dei gruppi utenti:
### [Ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
Un **ruolo IAM** è molto **simile** a un **utente**, in quanto è un **identità con politiche di permesso che determinano cosa** può e non può fare in AWS. Tuttavia, un ruolo **non ha alcuna credenziale** (password o chiavi di accesso) associata. Invece di essere associato in modo univoco a una persona, un ruolo è destinato a essere **assumibile da chiunque ne abbia bisogno (e abbia abbastanza permessi)**. Un **utente IAM può assumere un ruolo per temporaneamente** acquisire permessi diversi per un compito specifico. Un ruolo può essere **assegnato a un** [**utente federato**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) che accede utilizzando un provider di identità esterno invece di IAM.
Un **ruolo IAM** è molto **simile** a un **utente**, in quanto è un **identità con politiche di permesso che determinano cosa** può e non può fare in AWS. Tuttavia, un ruolo **non ha alcuna credenziale** (password o chiavi di accesso) associata. Invece di essere associato in modo univoco a una persona, un ruolo è destinato a essere **assunto da chiunque ne abbia bisogno (e abbia abbastanza permessi)**. Un **utente IAM può assumere un ruolo per temporaneamente** acquisire permessi diversi per un compito specifico. Un ruolo può essere **assegnato a un** [**utente federato**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) che accede utilizzando un provider di identità esterno invece di IAM.
Un ruolo IAM consiste in **due tipi di politiche**: una **politica di fiducia**, che non può essere vuota, che definisce **chi può assumere** il ruolo, e una **politica di permessi**, che non può essere vuota, che definisce **cosa può accedere**.
@@ -210,12 +210,12 @@ Se **esiste un singolo "Deny", sovrascriverà il "Allow"**, tranne per le richie
]
}
```
I [campi globali che possono essere utilizzati per condizioni in qualsiasi servizio sono documentati qui](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\
I [campi specifici che possono essere utilizzati per condizioni per servizio sono documentati qui](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html).
I [campi globali che possono essere utilizzati per le condizioni in qualsiasi servizio sono documentati qui](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\
I [campi specifici che possono essere utilizzati per le condizioni per servizio sono documentati qui](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html).
#### Politiche Inline
Questo tipo di politiche è **assegnato direttamente** a un utente, gruppo o ruolo. Quindi, non appaiono nell'elenco delle Politiche poiché nessun altro può usarle.\
Questo tipo di politiche sono **assegnate direttamente** a un utente, gruppo o ruolo. Quindi, non appaiono nell'elenco delle Politiche poiché nessun altro può usarle.\
Le politiche inline sono utili se si desidera **mantenere una relazione rigorosa uno a uno tra una politica e l'identità** a cui è applicata. Ad esempio, si vuole essere certi che i permessi in una politica non siano assegnati inavvertitamente a un'identità diversa da quella per cui sono destinati. Quando si utilizza una politica inline, i permessi nella politica non possono essere attaccati inavvertitamente all'identità sbagliata. Inoltre, quando si utilizza la Console di gestione AWS per eliminare quell'identità, le politiche incorporate nell'identità vengono eliminate anch'esse. Questo perché fanno parte dell'entità principale.
#### Politiche dei Bucket di Risorse
@@ -226,7 +226,7 @@ Se un principale non ha un diniego esplicito su di esse, e una politica di risor
### Limiti IAM
I limiti IAM possono essere utilizzati per **limitare i permessi a cui un utente o ruolo dovrebbe avere accesso**. In questo modo, anche se un diverso insieme di permessi viene concesso all'utente da una **politica diversa**, l'operazione **fallirà** se tenta di usarli.
I limiti IAM possono essere utilizzati per **limitare i permessi a cui un utente o un ruolo dovrebbe avere accesso**. In questo modo, anche se un insieme diverso di permessi viene concesso all'utente da una **politica diversa**, l'operazione **fallirà** se tenta di usarli.
Un limite è semplicemente una politica allegata a un utente che **indica il livello massimo di permessi che l'utente o il ruolo può avere**. Quindi, **anche se l'utente ha accesso da Amministratore**, se il limite indica che può solo leggere i bucket S·, questo è il massimo che può fare.
@@ -250,7 +250,7 @@ Pertanto, se a un certo punto ti trovi di fronte all'errore "... perché nessuna
### Federazione dell'Identità
La federazione dell'identità **consente agli utenti di provider di identità che sono esterni** ad AWS di accedere alle risorse AWS in modo sicuro senza dover fornire le credenziali di un utente AWS da un account IAM valido.\
La federazione dell'identità **consente agli utenti di provider di identità esterni** ad AWS di accedere in modo sicuro alle risorse AWS senza dover fornire le credenziali di un utente AWS da un account IAM valido.\
Un esempio di provider di identità può essere il tuo **Microsoft Active Directory** aziendale (tramite **SAML**) o i servizi **OpenID** (come **Google**). L'accesso federato consentirà quindi agli utenti al suo interno di accedere ad AWS.
Per configurare questa fiducia, viene generato un **Provider di Identità IAM (SAML o OAuth)** che **fiducia** la **altra piattaforma**. Poi, almeno un **ruolo IAM è assegnato (fiducioso) al Provider di Identità**. Se un utente della piattaforma fidata accede ad AWS, accederà come il ruolo menzionato.
@@ -273,13 +273,13 @@ Per accedere agli utenti, ci sono 3 fonti di identità che possono essere utiliz
<figure><img src="../../../images/image (279).png" alt=""><figcaption></figcaption></figure>
Nel caso più semplice della directory del Centro Identità, il **Centro Identità avrà un elenco di utenti e gruppi** e sarà in grado di **assegnare politiche** a loro per **uno qualsiasi degli account** dell'organizzazione.
Nel caso più semplice della directory del Centro Identità, il **Centro Identità avrà un elenco di utenti e gruppi** e sarà in grado di **assegnare politiche** a loro per **qualsiasi degli account** dell'organizzazione.
Per dare accesso a un utente/gruppo del Centro Identità a un account, verrà creato un **Provider di Identità SAML che fida il Centro Identità**, e verrà creato un **ruolo che fida il Provider di Identità con le politiche indicate** nell'account di destinazione.
Per dare accesso a un utente/gruppo del Centro Identità a un account, verrà creato un **Provider di Identità SAML che fida il Centro Identità**, e un **ruolo che fida il Provider di Identità con le politiche indicate sarà creato** nell'account di destinazione.
#### AwsSSOInlinePolicy
È possibile **dare permessi tramite politiche inline ai ruoli creati tramite IAM Identity Center**. I ruoli creati negli account a cui vengono date **politiche inline in AWS Identity Center** avranno questi permessi in una politica inline chiamata **`AwsSSOInlinePolicy`**.
È possibile **dare permessi tramite politiche inline ai ruoli creati tramite IAM Identity Center**. I ruoli creati negli account a cui vengono dati **politiche inline in AWS Identity Center** avranno questi permessi in una politica inline chiamata **`AwsSSOInlinePolicy`**.
Pertanto, anche se vedi 2 ruoli con una politica inline chiamata **`AwsSSOInlinePolicy`**, **non significa che abbia gli stessi permessi**.
@@ -329,7 +329,7 @@ In [**questa pagina**](https://docs.aws.amazon.com/IAM/latest/UserGuide/referenc
| APKA | Chiave pubblica |
| AROA | Ruolo |
| ASCA | Certificato |
| ASIA | [ID chiavi di accesso temporanee (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) usano questo prefisso, ma sono unici solo in combinazione con la chiave di accesso segreta e il token di sessione. |
| ASIA | [ID chiavi di accesso temporanee (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) utilizzano questo prefisso, ma sono uniche solo in combinazione con la chiave di accesso segreta e il token di sessione. |
### Permessi raccomandati per audit degli account
@@ -348,9 +348,9 @@ I seguenti privilegi concedono vari accessi in lettura ai metadati:
### Autenticazione CLI
Affinché un utente regolare si autentichi ad AWS tramite CLI, è necessario avere **credenziali locali**. Per impostazione predefinita, puoi configurarle **manualmente** in `~/.aws/credentials` o **eseguendo** `aws configure`.\
In quel file puoi avere più di un profilo; se **nessun profilo** è specificato utilizzando il **aws cli**, verrà utilizzato quello chiamato **`[default]`** in quel file.\
Esempio di file delle credenziali con più di 1 profilo:
Affinché un utente normale si autentichi ad AWS tramite CLI, è necessario avere **credenziali locali**. Per impostazione predefinita, puoi configurarle **manualmente** in `~/.aws/credentials` o **eseguendo** `aws configure`.\
In quel file puoi avere più di un profilo, se **nessun profilo** è specificato utilizzando il **aws cli**, verrà utilizzato quello chiamato **`[default]`** in quel file.\
Esempio di file di credenziali con più di 1 profilo:
```
[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
@@ -379,6 +379,23 @@ aws --profile acc2 ...
```
Se stai cercando qualcosa di **simile** a questo ma per il **browser**, puoi controllare l'**estensione** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en).
#### Automazione delle credenziali temporanee
Se stai sfruttando un'applicazione che genera credenziali temporanee, può essere noioso aggiornarle nel tuo terminale ogni pochi minuti quando scadono. Questo può essere risolto utilizzando una direttiva `credential_process` nel file di configurazione. Ad esempio, se hai qualche webapp vulnerabile, potresti fare:
```toml
[victim]
credential_process = curl -d 'PAYLOAD' https://some-site.com
```
Nota che le credenziali _devono_ essere restituite a STDOUT nel seguente formato:
```json
{
"Version": 1,
"AccessKeyId": "an AWS access key",
"SecretAccessKey": "your AWS secret access key",
"SessionToken": "the AWS session token for temporary credentials",
"Expiration": "ISO8601 timestamp when the credentials expire"
}
```
## Riferimenti
- [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)