mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-09 11:44:59 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA
This commit is contained in:
Translator
@@ -8,7 +8,7 @@
|
||||
|
||||
### Account
|
||||
|
||||
In AWS c'è un **account root**, che è il **contenitore principale per tutti gli account** della tua **organizzazione**. Tuttavia, non è necessario utilizzare quell'account per distribuire risorse, puoi creare **altri account per separare diverse infrastrutture AWS** tra di loro.
|
||||
In AWS, c'è un **account root**, che è il **contenitore principale per tutti gli account** della tua **organizzazione**. Tuttavia, non è necessario utilizzare quell'account per distribuire risorse, puoi creare **altri account per separare diverse infrastrutture AWS** tra di loro.
|
||||
|
||||
Questo è molto interessante dal punto di vista della **sicurezza**, poiché **un account non sarà in grado di accedere alle risorse di un altro account** (a meno che non vengano create specificamente delle bridge), in questo modo puoi creare confini tra le distribuzioni.
|
||||
|
||||
@@ -24,7 +24,7 @@ Pertanto, ci sono **due tipi di account in un'organizzazione** (stiamo parlando
|
||||
- Abilitare l'integrazione con i servizi AWS supportati per fornire funzionalità di servizio a tutti gli account nell'organizzazione.
|
||||
- È possibile accedere come utente root utilizzando l'email e la password utilizzate per creare questo account/organizzazione root.
|
||||
|
||||
L'account di gestione ha le **responsabilità di un account pagatore** ed è responsabile per il pagamento di tutte le spese accumulate dagli account membri. Non puoi cambiare l'account di gestione di un'organizzazione.
|
||||
L'account di gestione ha le **responsabilità di un account pagatore** ed è responsabile del pagamento di tutte le spese accumulate dagli account membri. Non puoi cambiare l'account di gestione di un'organizzazione.
|
||||
|
||||
- Gli **account membri** costituiscono tutti gli altri account in un'organizzazione. Un account può essere membro di una sola organizzazione alla volta. Puoi allegare una politica a un account per applicare controlli solo a quell'account.
|
||||
- Gli account membri **devono utilizzare un indirizzo email valido** e possono avere un **nome**, in generale non saranno in grado di gestire la fatturazione (ma potrebbero ricevere accesso ad essa).
|
||||
@@ -46,7 +46,7 @@ Questo è l'UNICO modo in cui **anche l'utente root può essere fermato** dal fa
|
||||
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:
|
||||
|
||||
@@ -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:
|
||||
|
||||
@@ -120,7 +120,7 @@ Dal punto di vista della sicurezza, è consigliato creare altri utenti ed evitar
|
||||
|
||||
Un _utente_ IAM è un'entità che crei in AWS per **rappresentare la persona o l'applicazione** che lo utilizza per **interagire con AWS**. Un utente in AWS consiste in un nome e credenziali (password e fino a due chiavi di accesso).
|
||||
|
||||
Quando crei un utente IAM, gli concedi **permessi** rendendolo un **membro di un gruppo di utenti** che ha politiche di permesso appropriate collegate (consigliato), o **allegando direttamente politiche** all'utente.
|
||||
Quando crei un utente IAM, gli concedi **permessi** rendendolo un **membro di un gruppo di utenti** che ha politiche di permesso appropriate collegate (consigliato), o **allegando direttamente le politiche** all'utente.
|
||||
|
||||
Gli utenti possono avere **MFA abilitato per il login** attraverso la console. I token API degli utenti con MFA abilitato non sono protetti da MFA. Se desideri **limitare l'accesso delle chiavi API di un utente utilizzando MFA**, devi indicare nella politica che per eseguire determinate azioni è necessaria la presenza di MFA (esempio [**qui**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)).
|
||||
|
||||
@@ -130,7 +130,7 @@ Gli utenti possono avere **MFA abilitato per il login** attraverso la console. I
|
||||
- **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:\
|
||||
_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_
|
||||
_Crea una nuova chiave di accesso -> Applica la nuova chiave al sistema/applicazione -> segna quella originale come inattiva -> Testa e verifica che la nuova chiave di accesso funzioni -> Elimina la vecchia chiave di accesso_
|
||||
|
||||
### MFA - Multi Factor Authentication
|
||||
|
||||
@@ -150,17 +150,17 @@ aws sts get-session-token --serial-number <arn_device> --token-code <code>
|
||||
```
|
||||
Come [**indicato qui**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), ci sono molti casi diversi in cui **MFA non può essere utilizzato**.
|
||||
|
||||
### [Gruppi utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
|
||||
### [Gruppi di utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
|
||||
|
||||
Un [gruppo utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) è un modo per **allegare politiche a più utenti** contemporaneamente, il che può semplificare la gestione delle autorizzazioni per quegli utenti. **I ruoli e i gruppi non possono far parte di un gruppo**.
|
||||
Un [gruppo di utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) è un modo per **allegare politiche a più utenti** contemporaneamente, il che può semplificare la gestione delle autorizzazioni per quegli utenti. **I ruoli e i gruppi non possono far parte di un gruppo**.
|
||||
|
||||
Puoi allegare una **politica basata sull'identità a un gruppo utenti** in modo che tutti gli **utenti** nel gruppo utenti **ricevano le autorizzazioni della politica**. Non puoi **identificare un gruppo utenti** come un **`Principal`** in una **politica** (come una politica basata sulle risorse) perché i gruppi si riferiscono alle autorizzazioni, non all'autenticazione, e i principali sono entità IAM autenticate.
|
||||
Puoi allegare una **politica basata sull'identità a un gruppo di utenti** in modo che tutti gli **utenti** nel gruppo di utenti **ricevano le autorizzazioni della politica**. Non puoi identificare un **gruppo di utenti** come un **`Principal`** in una **politica** (come una politica basata sulle risorse) perché i gruppi si riferiscono alle autorizzazioni, non all'autenticazione, e i principal sono entità IAM autenticate.
|
||||
|
||||
Ecco alcune caratteristiche importanti dei gruppi utenti:
|
||||
Ecco alcune caratteristiche importanti dei gruppi di utenti:
|
||||
|
||||
- Un **gruppo** utenti può **contenere molti utenti**, e un **utente** può **appartenere a più gruppi**.
|
||||
- **I gruppi utenti non possono essere annidati**; possono contenere solo utenti, non altri gruppi utenti.
|
||||
- Non esiste **un gruppo utenti predefinito che include automaticamente tutti gli utenti nell'account AWS**. Se desideri avere un gruppo utenti di questo tipo, devi crearlo e assegnare ogni nuovo utente ad esso.
|
||||
- Un **gruppo** di utenti può **contenere molti utenti**, e un **utente** può **appartenere a più gruppi**.
|
||||
- **I gruppi di utenti non possono essere annidati**; possono contenere solo utenti, non altri gruppi di utenti.
|
||||
- Non esiste **un gruppo di utenti predefinito che include automaticamente tutti gli utenti nell'account AWS**. Se desideri avere un gruppo di utenti di questo tipo, devi crearlo e assegnare ogni nuovo utente ad esso.
|
||||
- Il numero e la dimensione delle risorse IAM in un account AWS, come il numero di gruppi e il numero di gruppi di cui un utente può essere membro, sono limitati. Per ulteriori informazioni, vedere [IAM e AWS STS quote](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
|
||||
|
||||
### [Ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
|
||||
@@ -175,7 +175,7 @@ Il Servizio di Token di Sicurezza AWS (STS) è un servizio web che facilita l'**
|
||||
|
||||
### [Credenziali temporanee in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
|
||||
|
||||
**Le credenziali temporanee sono utilizzate principalmente con i ruoli IAM**, ma ci sono anche altri usi. Puoi richiedere credenziali temporanee che hanno un insieme di autorizzazioni più ristretto rispetto al tuo utente IAM standard. Questo **previene** che tu **esegua accidentalmente compiti non consentiti** dalle credenziali più ristrette. Un vantaggio delle credenziali temporanee è che scadono automaticamente dopo un periodo di tempo stabilito. Hai il controllo sulla durata per cui le credenziali sono valide.
|
||||
Le **credenziali temporanee sono utilizzate principalmente con i ruoli IAM**, ma ci sono anche altri usi. Puoi richiedere credenziali temporanee che hanno un insieme di autorizzazioni più ristretto rispetto al tuo utente IAM standard. Questo **previene** che tu **esegua accidentalmente compiti non consentiti** dalle credenziali più ristrette. Un vantaggio delle credenziali temporanee è che scadono automaticamente dopo un periodo di tempo stabilito. Hai il controllo sulla durata per cui le credenziali sono valide.
|
||||
|
||||
### Politiche
|
||||
|
||||
@@ -215,18 +215,18 @@ I [campi specifici che possono essere utilizzati per condizioni per servizio son
|
||||
|
||||
#### Politiche Inline
|
||||
|
||||
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.\
|
||||
Questo tipo di politiche è **assegnato 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
|
||||
|
||||
Queste sono **politiche** che possono essere definite in **risorse**. **Non tutte le risorse di AWS le supportano**.
|
||||
Queste sono **politiche** che possono essere definite nelle **risorse**. **Non tutte le risorse di AWS le supportano**.
|
||||
|
||||
Se un principale non ha un diniego esplicito su di esse, e una politica di risorsa concede loro accesso, allora sono autorizzati.
|
||||
|
||||
### Limiti IAM
|
||||
|
||||
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 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 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.
|
||||
|
||||
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.
|
||||
|
||||
@@ -234,7 +234,7 @@ Un limite è semplicemente una politica allegata a un utente che **indica il liv
|
||||
|
||||
### Politiche di Sessione
|
||||
|
||||
Una politica di sessione è una **politica impostata quando un ruolo viene assunto** in qualche modo. Questo sarà come un **limite IAM per quella sessione**: Questo significa che la politica di sessione non concede permessi ma **li restringe a quelli indicati nella politica** (essendo i permessi massimi quelli che ha il ruolo).
|
||||
Una politica di sessione è una **politica impostata quando un ruolo viene assunto** in qualche modo. Questo sarà come un **limite IAM per quella sessione**: Questo significa che la politica di sessione non concede permessi ma **li restringe a quelli indicati nella politica** (essendo i permessi massimi quelli che il ruolo ha).
|
||||
|
||||
Questo è utile per **misure di sicurezza**: Quando un amministratore sta per assumere un ruolo molto privilegiato, potrebbe restringere il permesso solo a quelli indicati nella politica di sessione nel caso in cui la sessione venga compromessa.
|
||||
```bash
|
||||
@@ -251,7 +251,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.\
|
||||
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.
|
||||
Un esempio di un 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** nella **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.
|
||||
|
||||
@@ -279,7 +279,7 @@ Per dare accesso a un utente/gruppo del Centro Identità a un account, verrà cr
|
||||
|
||||
#### 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 che ricevono **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**.
|
||||
|
||||
@@ -315,21 +315,21 @@ AWS Identity and Access Management (IAM) fornisce **controllo degli accessi dett
|
||||
|
||||
In [**questa pagina**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) puoi trovare i **prefissi ID IAM** delle chiavi a seconda della loro natura:
|
||||
|
||||
| Codice Identificatore | Descrizione |
|
||||
| ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| ABIA | [Token bearer del servizio AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
|
||||
| Codice Identificatore | Descrizione |
|
||||
| --------------- | ----------------------------------------------------------------------------------------------------------- |
|
||||
| ABIA | [Token bearer del servizio AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
|
||||
|
||||
| ACCA | Credenziale specifica per contesto |
|
||||
| AGPA | Gruppo utenti |
|
||||
| AIDA | Utente IAM |
|
||||
| AIPA | Profilo istanza Amazon EC2 |
|
||||
| AKIA | Chiave di accesso |
|
||||
| ANPA | Politica gestita |
|
||||
| ANVA | Versione in una politica gestita |
|
||||
| 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 uniche solo in combinazione con la chiave di accesso segreta e il token di sessione. |
|
||||
| ACCA | Credenziale specifica per contesto |
|
||||
| AGPA | Gruppo utente |
|
||||
| AIDA | Utente IAM |
|
||||
| AIPA | Profilo istanza Amazon EC2 |
|
||||
| AKIA | Chiave di accesso |
|
||||
| ANPA | Politica gestita |
|
||||
| ANVA | Versione in una politica gestita |
|
||||
| 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) 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`.\
|
||||
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 delle credenziali con più di 1 profilo:
|
||||
Esempio di file di credenziali con più di 1 profilo:
|
||||
```
|
||||
[default]
|
||||
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
|
||||
|
||||
Reference in New Issue
Block a user