Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/

This commit is contained in:
Translator
2025-01-02 01:27:43 +00:00
parent 5dd38218dd
commit 38e365814e
209 changed files with 1699 additions and 1697 deletions

View File

@@ -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 le 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.
@@ -21,8 +21,8 @@ Pertanto, ci sono **due tipi di account in un'organizzazione** (stiamo parlando
- Rimuovere account dall'organizzazione
- Gestire inviti
- Applicare politiche a entità (root, OU o account) all'interno dell'organizzazione
- 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 root/organizzazione.
- Abilitare l'integrazione con i servizi AWS supportati per fornire funzionalità di servizio a tutti gli account dell'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 del pagamento di tutte le spese accumulate dagli account membri. Non puoi cambiare l'account di gestione di un'organizzazione.
@@ -57,7 +57,7 @@ Esempi di SCP:
essere disabilitati
- Negare ai ruoli di sicurezza/riposta agli incidenti di essere eliminati o
- Negare ai ruoli di sicurezza/risposta agli incidenti di essere eliminati o
modificati.
@@ -92,34 +92,34 @@ IAM può essere definito dalla sua capacità di gestire, controllare e governare
### [Utente root dell'account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>
Quando crei per la prima volta un account Amazon Web Services (AWS), inizi con un'unica identità di accesso che ha **accesso completo a tutti** i servizi e le risorse AWS nell'account. Questo è l'utente _**root**_ dell'account AWS e si accede effettuando il login con **l'indirizzo email e la password che hai usato per creare l'account**.
Quando crei per la prima volta un account Amazon Web Services (AWS), inizi con un'unica identità di accesso che ha **accesso completo a tutti** i servizi e le risorse AWS nell'account. Questo è l'utente _**root**_ dell'account AWS e viene accesso effettuando il login con **l'indirizzo email e la password che hai usato per creare l'account**.
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.
### [Utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
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 allegate (consigliato), o **allegando direttamente le politiche** all'utente.
Gli utenti possono avere **MFA abilitato per il login** tramite 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)).
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)).
#### CLI
- **ID chiave di accesso**: 20 caratteri alfanumerici casuali in maiuscolo come AKHDNAPO86BSHKDIRYT
- **ID chiave di accesso segreta**: 40 caratteri casuali in maiuscolo e minuscolo: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Non è possibile recuperare gli ID chiave di accesso segreta persi).
- **ID chiave di accesso segreta**: 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 Chiave di Accesso**, questo è il processo che dovresti seguire:\
Ogni volta che hai bisogno di **cambiare la chiave di accesso**, questo è il processo che dovresti seguire:\
&#xNAN;_&#x43;rea 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
Viene utilizzato per **creare un fattore aggiuntivo per l'autenticazione** oltre ai tuoi metodi esistenti, come la password, creando quindi un livello di autenticazione multi-fattore.\
Puoi utilizzare un **applicazione virtuale gratuita o un dispositivo fisico**. Puoi utilizzare app come Google Authenticator gratuitamente per attivare un MFA in AWS.
Puoi utilizzare un **applicazione virtuale gratuita o un dispositivo fisico**. Puoi utilizzare app come google authentication gratuitamente per attivare un MFA in AWS.
Le politiche con condizioni MFA possono essere collegate ai seguenti:
Le politiche con condizioni MFA possono essere allegate ai seguenti:
- Un utente o gruppo IAM
- Una risorsa come un bucket Amazon S3, una coda Amazon SQS o un argomento Amazon SNS
@@ -130,43 +130,43 @@ Nota che **le credenziali di `AssumeRole` non contengono queste informazioni**.
```bash
aws sts get-session-token --serial-number <arn_device> --token-code <code>
```
As [**stated here**](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**.
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**.
### [IAM user groups](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 utente 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 utente** in modo che tutti gli **utenti** nel gruppo utente **ricevano le autorizzazioni della politica**. Non puoi **identificare un gruppo utente** 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.
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 utente:
Ecco alcune caratteristiche importanti dei gruppi di utenti:
- Un **gruppo** utente può **contenere molti utenti**, e un **utente** può **appartenere a più gruppi**.
- **I gruppi utente non possono essere annidati**; possono contenere solo utenti, non altri gruppi utente.
- Non esiste **un gruppo utente predefinito che include automaticamente tutti gli utenti nell'account AWS**. Se desideri avere un gruppo utente 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 le quote di AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
- 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 [quote IAM e AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
### [IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
### [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 autorizzazione 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 autorizzazioni diverse 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 autorizzazione 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 autorizzazioni diverse 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 autorizzazione**, che non può essere vuota, che definisce **cosa può accedere**.
#### AWS Security Token Service (STS)
#### Servizio di Token di Sicurezza AWS (STS)
AWS Security Token Service (STS) è un servizio web che facilita l'**emissione di credenziali temporanee e con privilegi limitati**. È specificamente progettato per:
Il Servizio di Token di Sicurezza AWS (STS) è un servizio web che facilita l'**emissione di credenziali temporanee e con privilegi limitati**. È specificamente progettato per:
### [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>
### [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.
### Policies
### Politiche
#### Policy Permissions
#### Permessi delle Politiche
Vengono utilizzate per assegnare autorizzazioni. Ci sono 2 tipi:
Vengono utilizzati per assegnare autorizzazioni. Ci sono 2 tipi:
- Politiche gestite da AWS (preconfigurate da AWS)
- Politiche gestite dal cliente: configurate da te. Puoi creare politiche basate su politiche gestite da AWS (modificando una di esse e creando la tua), utilizzando il generatore di politiche (una vista GUI che ti aiuta a concedere e negare autorizzazioni) o scrivendo la tua.
- Politiche gestite dai clienti: configurate da te. Puoi creare politiche basate su politiche gestite da AWS (modificando una di esse e creando la tua), utilizzando il generatore di politiche (una vista GUI che ti aiuta a concedere e negare autorizzazioni) o scrivendo la tua.
Per **default l'accesso** è **negato**, l'accesso sarà concesso se è stato specificato un ruolo esplicito.\
Se **esiste un singolo "Deny", sovrascriverà il "Allow"**, tranne per le richieste che utilizzano le credenziali di sicurezza root dell'account AWS (che sono consentite per impostazione predefinita).
@@ -192,33 +192,33 @@ Se **esiste un singolo "Deny", sovrascriverà il "Allow"**, tranne per le richie
]
}
```
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).
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).
#### Inline Policies
#### Politiche Inline
Questo tipo di policies è **assegnato direttamente** a un utente, gruppo o ruolo. Quindi, non appaiono nell'elenco delle Policies poiché nessun altro può usarle.\
Le inline policies sono utili se si desidera **mantenere una relazione rigorosa uno a uno tra una policy e l'identità** a cui è applicata. Ad esempio, si vuole essere certi che i permessi in una policy non siano assegnati inavvertitamente a un'identità diversa da quella per cui sono destinati. Quando si utilizza un'inline policy, i permessi nella policy non possono essere attaccati inavvertitamente all'identità sbagliata. Inoltre, quando si utilizza la AWS Management Console per eliminare quell'identità, le policies incorporate nell'identità vengono eliminate anch'esse. Questo perché fanno parte dell'entità principale.
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 involontariamente a un'identità diversa da quella per cui sono destinati. Quando si utilizza una politica inline, i permessi nella politica non possono essere attaccati involontariamente 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.
#### Resource Bucket Policies
#### Politiche dei Bucket di Risorse
Queste sono **policies** che possono essere definite in **resources**. **Non tutte le risorse di AWS le supportano**.
Queste sono **politiche** che possono essere definite in **risorse**. **Non tutte le risorse di AWS le supportano**.
Se un principale non ha un diniego esplicito su di esse, e una policy di risorsa concede loro accesso, allora sono autorizzati.
Se un principale non ha un diniego esplicito su di esse, e una politica di risorsa concede loro accesso, allora sono autorizzati.
### IAM Boundaries
### Limiti IAM
Le IAM boundaries possono essere utilizzate 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 **diversa policy**, 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.
Una boundary è semplicemente una policy allegata a un utente che **indica il livello massimo di permessi che l'utente o ruolo può avere**. Quindi, **anche se l'utente ha accesso da Administrator**, se la boundary indica che può solo leggere i bucket S·, quello è il massimo che può fare.
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.
**Questo**, **SCPs** e **seguire il principio del minimo privilegio** sono i modi per controllare che gli utenti non abbiano più permessi di quelli di cui hanno bisogno.
**Questo**, **SCP** e **seguire il principio del minimo privilegio** sono i modi per controllare che gli utenti non abbiano più permessi di quelli di cui hanno bisogno.
### Session Policies
### Politiche di Sessione
Una session policy è una **policy impostata quando un ruolo viene assunto** in qualche modo. Questo sarà come un **IAM boundary per quella sessione**: Questo significa che la session policy non concede permessi ma **li restringe a quelli indicati nella policy** (essendo i permessi massimi quelli che il ruolo ha).
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 admin sta per assumere un ruolo molto privilegiato, potrebbe restringere il permesso solo a quelli indicati nella session policy nel caso in cui la sessione venga compromessa.
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
aws sts assume-role \
--role-arn <value> \
@@ -226,18 +226,18 @@ aws sts assume-role \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]
```
Nota che per impostazione predefinita **AWS potrebbe aggiungere politiche di sessione alle sessioni** che verranno generate a causa di motivi terzi. Ad esempio, in [ruoli assunti da cognito non autenticati](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) per impostazione predefinita (utilizzando l'autenticazione avanzata), AWS genererà **credenziali di sessione con una politica di sessione** che limita i servizi a cui la sessione può accedere [**alla seguente lista**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
Nota che per impostazione predefinita **AWS potrebbe aggiungere politiche di sessione alle sessioni** che verranno generate per motivi terzi. Ad esempio, in [ruoli assunti da cognito non autenticati](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) per impostazione predefinita (utilizzando l'autenticazione avanzata), AWS genererà **credenziali di sessione con una politica di sessione** che limita i servizi a cui la sessione può accedere [**alla seguente lista**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
Pertanto, se a un certo punto ti trovi di fronte all'errore "... perché nessuna politica di sessione consente il ...", e il ruolo ha accesso per eseguire l'azione, è perché **c'è una politica di sessione che lo impedisce**.
### Federazione dell'Identità
La federazione dell'identità **consente agli utenti di fornitori 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 fornitore 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.
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 **Fornitore di Identità IAM (SAML o OAuth)** che **fiducia** nella **altra piattaforma**. Poi, almeno un **ruolo IAM è assegnato (fiducioso) al Fornitore di Identità**. Se un utente della piattaforma fidata accede ad AWS, accederà come il ruolo menzionato.
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.
Tuttavia, di solito vorrai dare un **ruolo diverso a seconda del gruppo dell'utente** nella piattaforma di terze parti. Quindi, diversi **ruoli IAM possono fidarsi** del Fornitore di Identità di terze parti e la piattaforma di terze parti sarà quella che consentirà agli utenti di assumere un ruolo o l'altro.
Tuttavia, di solito vorrai dare un **ruolo diverso a seconda del gruppo dell'utente** nella piattaforma di terze parti. Quindi, diversi **ruoli IAM possono fidarsi** del Provider di Identità di terze parti e la piattaforma di terze parti sarà quella che consentirà agli utenti di assumere un ruolo o l'altro.
<figure><img src="../../../images/image (247).png" alt=""><figcaption></figcaption></figure>
@@ -251,13 +251,13 @@ Per accedere agli utenti, ci sono 3 fonti di identità che possono essere utiliz
- Directory del Centro Identità: Utenti AWS regolari
- Active Directory: Supporta diversi connettori
- Fornitore di Identità Esterno: Tutti gli utenti e i gruppi provengono da un Fornitore di Identità esterno (IdP)
- Provider di Identità Esterno: Tutti gli utenti e i gruppi provengono da un Provider di Identità esterno (IdP)
<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 **qualsiasi degli account** dell'organizzazione.
Per dare accesso a un utente/gruppo del Centro Identità a un account, verrà creato un **Fornitore di Identità SAML che fida il Centro Identità**, e verrà creato un **ruolo che fida il Fornitore 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 verrà creato un **ruolo che fida il Provider di Identità con le politiche indicate** nell'account di destinazione.
#### AwsSSOInlinePolicy
@@ -277,7 +277,7 @@ Non supportato:
- Relazioni di Fiducia
- Centro Amministrativo AD
- Supporto completo per PS API
- Cestino AD
- Cestino di Riciclo AD
- Account di Servizio Gestiti da Gruppo
- Estensioni di Schema
- Nessun accesso diretto a OS o Istanza
@@ -297,19 +297,19 @@ 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:
| ABIA | [Token portatore del servizio AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
| ABIA | [Token bearer del servizio AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
| ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ACCA | Credenziale specifica del contesto |
| AGPA | Gruppo utente |
| AIDA | Utente IAM |
| AIPA | Profilo istanza Amazon EC2 |
| AIPA | Profilo di 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 chiave di accesso temporanea (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) utilizza questo prefisso, ma è unico 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
@@ -328,7 +328,7 @@ 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:
```

View File

@@ -10,7 +10,7 @@ Per informazioni su SAML, controlla:
https://book.hacktricks.xyz/pentesting-web/saml-attacks
{{#endref}}
Per configurare una **Federazione di Identità tramite SAML**, è sufficiente fornire un **nome** e il **metadata XML** contenente tutta la configurazione SAML (**endpoint**, **certificato** con chiave pubblica)
Per configurare una **Federazione di Identità tramite SAML**, è sufficiente fornire un **nome** e il **metadata XML** contenente tutta la configurazione SAML (**endpoints**, **certificato** con chiave pubblica)
## OIDC - Abuso di Github Actions
@@ -18,9 +18,9 @@ Per aggiungere un'azione github come fornitore di identità:
1. Per _Tipo di fornitore_, seleziona **OpenID Connect**.
2. Per _URL del fornitore_, inserisci `https://token.actions.githubusercontent.com`
3. Clicca su _Ottieni impronta digitale_ per ottenere l'impronta digitale del fornitore
4. Per _Pubblico_, inserisci `sts.amazonaws.com`
5. Crea un **nuovo ruolo** con le **permissive** di cui l'azione github ha bisogno e una **politica di fiducia** che fidi del fornitore come:
3. Clicca su _Ottieni thumbprint_ per ottenere il thumbprint del fornitore
4. Per _Audience_, inserisci `sts.amazonaws.com`
5. Crea un **nuovo ruolo** con le **permissive** necessarie all'azione github e una **politica di fiducia** che fidi del fornitore come:
- ```json
{
"Version": "2012-10-17",
@@ -44,7 +44,7 @@ Per aggiungere un'azione github come fornitore di identità:
]
}
```
6. Nota nella politica precedente come solo un **branch** del **repository** di un'**organizzazione** è stato autorizzato con un **trigger** specifico.
6. Nota nella politica precedente come solo un **branch** di un **repository** di un'**organizzazione** è stato autorizzato con un **trigger** specifico.
7. L'**ARN** del **ruolo** che l'azione github potrà **impersonare** sarà il "segreto" che l'azione github deve conoscere, quindi **conservalo** all'interno di un **segreto** in un **ambiente**.
8. Infine, utilizza un'azione github per configurare le credenziali AWS da utilizzare nel workflow:
```yaml
@@ -78,7 +78,7 @@ role-session-name: OIDCSession
- run: aws sts get-caller-identity
shell: bash
```
## OIDC - EKS Abuse
## OIDC - Abuso di EKS
```bash
# Crate an EKS cluster (~10min)
eksctl create cluster --name demo --fargate