Italian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - Basic Information

Supporta HackTricks

Gerarchia dell'Organizzazione

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.

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.

Pertanto, ci sono due tipi di account in un'organizzazione (stiamo parlando di account AWS e non di account utente): un singolo account designato come account di gestione e uno o più account membri.

  • L'account di gestione (l'account root) è l'account che utilizzi per creare l'organizzazione. Dall'account di gestione dell'organizzazione, puoi fare quanto segue:

  • Creare account nell'organizzazione

  • Invitare altri account esistenti nell'organizzazione

  • 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/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.

  • 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).

aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com

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. Tieni presente che un'OU può avere altre OU come figli.

# 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)

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 bloccato dal fare qualcosa. Ad esempio, potrebbe essere utilizzato per impedire agli utenti di disabilitare CloudTrail o eliminare i backup. L'unico modo per bypassare questo è compromettere anche l'account master che configura le SCP (l'account master non può essere bloccato).

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.

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

essere disabilitati

  • Negare ai ruoli di sicurezza/riposta agli incidenti di essere eliminati o

modificati.

  • Negare l'eliminazione dei backup.

  • Negare la creazione di utenti IAM e chiavi di accesso

Trova esempi JSON in https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html

ARN

Amazon Resource Name è il nome unico che ogni risorsa all'interno di AWS ha, è composto in questo modo:

arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env

Nota che ci sono 4 partizioni in AWS ma solo 3 modi per chiamarle:

  • AWS Standard: aws

  • AWS China: aws-cn

  • AWS US public Internet (GovCloud): aws-us-gov

  • AWS Secret (US Classified): aws

IAM - Identity and Access Management

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 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.

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.

Utente root dell'account AWS

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.

Utenti IAM

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 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).

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).

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

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.

Le politiche con condizioni MFA possono essere collegate ai seguenti:

  • Un utente o gruppo IAM

  • Una risorsa come un bucket Amazon S3, una coda Amazon SQS o un argomento Amazon SNS

  • La politica di fiducia di un ruolo IAM che può essere assunto da un utente

Se desideri accedere tramite CLI a una risorsa che controlla per MFA, devi chiamare GetSessionToken. Questo ti darà un token con informazioni su MFA. Nota che le credenziali di AssumeRole non contengono queste informazioni.

aws sts get-session-token --serial-number <arn_device> --token-code <code>

As stated here, ci sono molti casi diversi in cui MFA non può essere utilizzato.

IAM user groups

Un gruppo utenti IAM è un modo per allegare politiche a più utenti contemporaneamente, il che può rendere più facile gestire i permessi 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 i permessi 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 ai permessi, non all'autenticazione, e i principal sono entità IAM autenticate.

Ecco alcune caratteristiche importanti dei gruppi 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.

  • 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.

IAM roles

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 che accede utilizzando un provider di identità esterno anziché 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.

AWS Security Token Service (STS)

AWS Security Token Service (STS) è un servizio web che facilita l'emissione di credenziali temporanee e con privilegi limitati. È specificamente progettato per:

Temporary credentials in IAM

Le credenziali temporanee sono utilizzate principalmente con i ruoli IAM, ma ci sono anche altri usi. Puoi richiedere credenziali temporanee che hanno un set di permessi 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

Policy Permissions

Vengono utilizzate per assegnare permessi. Ci sono 2 tipi:

  • Politiche gestite da AWS (preconfigurate da AWS)

  • 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 permessi) 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à l'"Allow", tranne per le richieste che utilizzano le credenziali di sicurezza root dell'account AWS (che sono consentite per default).

{
"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"}
}
}
]
}

I campi globali che possono essere utilizzati per le condizioni in qualsiasi servizio sono documentati qui. I campi specifici che possono essere utilizzati per le condizioni per servizio sono documentati qui.

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. 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.

Politiche dei Bucket di Risorse

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 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 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.

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.

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).

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.

aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--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 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.

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 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.

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.

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.

Centro Identità IAM

AWS IAM Identity Center (successore di AWS Single Sign-On) espande le capacità di AWS Identity and Access Management (IAM) per fornire un luogo centrale che riunisce l'amministrazione degli utenti e il loro accesso agli account AWS e alle applicazioni cloud.

Il dominio di accesso sarà qualcosa come <user_input>.awsapps.com.

Per accedere agli utenti, ci sono 3 fonti di identità che possono essere utilizzate:

  • Directory del Centro Identità: Utenti AWS regolari

  • Active Directory: Supporta diversi connettori

  • Provider di Identità Esterno: Tutti gli utenti e i gruppi provengono da un Provider di Identità esterno (IdP)

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 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 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.

Fiducia e Ruoli tra Account

Un utente (fiducioso) può creare un Ruolo tra Account con alcune politiche e poi, consentire a un altro utente (fidato) di accedere al suo account ma solo avendo l'accesso indicato nelle nuove politiche del ruolo. Per creare questo, basta creare un nuovo Ruolo e selezionare Ruolo tra Account. I ruoli per Accesso tra Account offrono due opzioni. Fornire accesso tra gli account AWS che possiedi e fornire accesso tra un account che possiedi e un account AWS di terze parti. È consigliato specificare l'utente che è fidato e non mettere qualcosa di generico perché altrimenti, altri utenti autenticati come gli utenti federati potranno anche abusare di questa fiducia.

AWS Simple AD

Non supportato:

  • Relazioni di Fiducia

  • Centro Amministrativo AD

  • Supporto completo per PS API

  • Cestino AD

  • Account di Servizio Gestiti da Gruppo

  • Estensioni di Schema

  • Nessun accesso diretto a OS o Istanza

Federazione Web o Autenticazione OpenID

L'app utilizza AssumeRoleWithWebIdentity per creare credenziali temporanee. Tuttavia, questo non concede accesso alla console AWS, solo accesso alle risorse all'interno di AWS.

Altre opzioni IAM

  • Puoi impostare un'impostazione della politica delle password con opzioni come lunghezza minima e requisiti per la password.

  • Puoi scaricare il "Rapporto Credenziali" con informazioni sulle credenziali attuali (come il tempo di creazione dell'utente, se la password è abilitata...). Puoi generare un rapporto credenziali anche ogni quattro ore.

AWS Identity and Access Management (IAM) fornisce controllo degli accessi dettagliato su tutto AWS. Con IAM, puoi specificare chi può accedere a quali servizi e risorse, e sotto quali condizioni. Con le politiche IAM, gestisci i permessi per la tua forza lavoro e i sistemi per garantire permessi minimi.

Prefissi ID IAM

In questa pagina puoi trovare i prefissi ID IAM delle chiavi a seconda della loro natura:

ABIA

Token bearer del servizio AWS STS

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 chiave di accesso temporanea (AWS STS) utilizza questo prefisso, ma è unico solo in combinazione con la chiave di accesso segreta e il token di sessione.

Permessi raccomandati per audit degli account

I seguenti privilegi concedono vari accessi in lettura ai metadati:

  • arn:aws:iam::aws:policy/SecurityAudit

  • arn:aws:iam::aws:policy/job-function/ViewOnlyAccess

  • codebuild:ListProjects

  • config:Describe*

  • cloudformation:ListStacks

  • logs:DescribeMetricFilters

  • directconnect:DescribeConnections

  • dynamodb:ListTables

Varie

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:

[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
aws_secret_access_key = uOcdhof683fbOUGFYEQug8fUGIf68greoihef

[Admin]
aws_access_key_id = AKIA8YDCu7TGTR356SHYT
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
region = eu-west-2

Se hai bisogno di accedere a diversi account AWS e il tuo profilo ha ricevuto accesso per assumere un ruolo all'interno di quegli account, non è necessario chiamare manualmente STS ogni volta (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) e configurare le credenziali.

Puoi utilizzare il file ~/.aws/config per indicare quali ruoli assumere, e poi usare il parametro --profile come al solito (l'assume-role verrà eseguito in modo trasparente per l'utente). Un esempio di file di configurazione:

[profile acc2]
region=eu-west-2
role_arn=arn:aws:iam::<account-id>:role/<role-path>
role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional

Con questo file di configurazione puoi quindi utilizzare aws cli come:

aws --profile acc2 ...

Se stai cercando qualcosa di simile a questo ma per il browser, puoi controllare l'estensione AWS Extend Switch Roles.

Riferimenti

Supporta HackTricks
PreviousAWS PentestingNextAWS - Federation Abuse

Last updated