AWS Permission Boundaries for Dummies

I permission boundary di AWS sono complicati. So che sono complicati perché hanno confuso anche me, e mi ci sono voluti un paio d'anni per capirli. So che sono complicati anche perché lo ha detto Corey Quinn, chiedendo a qualcuno di renderli meno complicati.

Probabilmente fallirò, ma ci provo.

In sintesi: le normali policy IAM consentono di fare determinate cose, ma possono anche impedire di farle. I permission boundary si limitano a impedire di fare determinate cose. Vengono utilizzati soprattutto per consentire a qualcuno di amministrare alcuni aspetti di IAM, ma non al punto da poter effettuare un'escalation di privilegi (per sé o per altri). Sono una misura di salvaguardia. Se consente a qualcuno di gestire IAM in un account e non vuole che possa effettuare un'escalation di privilegi, nella quasi totalità dei casi le serve un permission boundary!

La documentazione ufficiale di AWS è molto dettagliata, ma resta comunque poco chiara. Questo articolo intende aiutarla a comprendere i concetti e le ragioni per cui esistono, non a padroneggiare ogni dettaglio della loro scrittura (con un'unica eccezione).

Faccia finta che sia un ragazzino, non uno sprovveduto, e me li rispieghi

Bene, se insiste.

Prima dei IAM Permission Boundaries era DAVVERO DIFFICILE consentire a qualcuno di gestire i permessi IAM sulle proprie risorse senza creare un problema di sicurezza assegnando troppi permessi a qualcosa come un'istanza EC2 o… a se stesso. Il problema si poneva soprattutto quando si voleva permettere di scrivere policy IAM e poi assegnarle. È il problema dell'amministrazione delegata. “Consentire a qualcuno di amministrare alcune cose relative a IAM, ma non quelle”.

È uno scenario molto comune. Gli sviluppatori creano spesso un ruolo per un'istanza, una funzione lambda o un container task nel proprio stack applicativo e poi assegnano dei permessi a quel ruolo. Può trattarsi di qualcosa di semplice come consentire a un'istanza di leggere dati da un bucket S3. In realtà, dal punto di vista della sicurezza questo è difficile da gestire:

• Se consente allo sviluppatore di scrivere le proprie policy, potrebbe aggiungere privilegi eccessivi… come *.*.
• Se consente allo sviluppatore di assegnare policy, potrebbe collegarne una esistente con troppi permessi.
• Se consente allo sviluppatore di creare un nuovo ruolo E di assegnare una policy… i problemi sono gli stessi.

Certo, potrebbe far gestire tutto questo al team di sicurezza o a un amministratore di alto livello, ma è inefficiente. I permission boundary consentono di avere due livelli di amministratori IAM: quelli di alto livello con la responsabilità complessiva della sicurezza e quelli di livello inferiore che si occupano delle attività quotidiane.

Un permission boundary è semplicemente una policy IAM che elenca i privilegi massimi che una persona o una risorsa può avere. Collega quella policy e gli sviluppatori che gestiscono la risorsa non potranno mai assegnarle più permessi di quelli previsti dal boundary. Può quindi anche consentire allo sviluppatore di creare nuovi ruoli e utenti e di assegnare loro permessi, imponendo però che tutto ciò che crea abbia quel permission boundary. In questo modo non potrà mai creare o modificare nulla assegnandogli più permessi di quanti lei intenda concedere.

Non sono certo che fosse una spiegazione per ragazzini, ma può farmi un esempio

Alice è la super-amministratrice di un'organizzazione AWS. Deve supervisionare centinaia di account, e ogni account ha i propri amministratori locali e sviluppatori che si occupano concretamente di costruire le applicazioni.

Bob è uno di questi sviluppatori locali. Bob sta realizzando una nuova applicazione ed è più efficiente che sia lui a creare i propri ruoli e le proprie policy, dato che conosce le esigenze della sua app.

Alice decide di lasciare che Bob gestisca IAM per alcune parti della sua applicazione. Nello specifico:

• Bob può scrivere e assegnare nuove policy IAM con i permessi di cui hanno bisogno le sue istanze e le sue funzioni lambda.
• Sono in uso altri servizi AWS che quei componenti non devono mai toccare. Non è quindi possibile disattivarli semplicemente con una Service Control Policy: ciò renderebbe quei servizi inutilizzabili per i componenti autorizzati a usarli.
• Bob non è autorizzato ad assegnare una nuova policy a se stesso.

È un classico caso di amministrazione delegata: Bob è autorizzato ad amministrare solo una parte di IAM. È qui che si utilizza un permission boundary:

• Alice crea un permission boundary “A” che consente i permessi per i servizi AWS con cui le istanze e le funzioni lambda di Bob possono comunicare (ad esempio S3, SNS, SQS).
• Alice crea un permission boundary “B” che consente a Bob di creare ruoli e policy IAM (e di assegnarli), ma NON di assegnarli a se stesso.
• Alice concede a Bob i permessi IAM per creare e assegnare nuovi ruoli e policy, ma ogni nuovo ruolo deve avere il permission boundary “A”. Ciò significa che quelle istanze e funzioni lambda non avranno MAI più permessi di quelli previsti dal boundary, ma potranno averne di meno.
• Alice assegna il permission boundary “B” a Bob per impedirgli di assegnare permessi a se stesso. Ora non può più rimuovere l'obbligo di distribuire le risorse con “A” applicato.

Sì, esistono diversi modi di affrontare questo problema… ma in breve ogni volta che vuole consentire a qualcuno di amministrare una parte di IAM in un account, probabilmente le serve un permission boundary se non vuole che faccia troppo.

Mi ripeta perché qui una Service Control Policy non funziona

A volte una SCP può funzionare, ma può usarla solo se si trova in un'Organization, mentre un permission boundary funziona in qualsiasi account. Inoltre, le SCP sono davvero efficaci per cose come limitare le chiamate API che si possono effettuare (e quindi quali servizi AWS si possono usare), ma non sono realmente pensate per questo livello di granularità e per queste condizioni.

Pensi all'esempio precedente: Alice potrebbe dover conoscere gli identificatori delle risorse per consentire l'accesso ai servizi nell'account, ma non dalle risorse create da Bob. Esistono modi per gestire eventualmente questa situazione (ad esempio i resource path), ma non sono più semplici del nostro esempio con il permission boundary e non sempre funzionano, a seconda delle condition key supportate.

Nel mio Incident Response Training Range uso una SCP per impedire agli utenti amministratori (gli studenti) negli account di compromettere il mio accesso a livello di Organizations e alcune altre cose. Ma funziona solo perché concedo loro IAM completo e perché sono già dei super-amministratori. Se volessi limitare la loro capacità di creare risorse con permessi eccessivi, mi servirebbe un permission boundary o una SCP per vincolarli ad assegnare solo determinate policy predefinite.

Non posso semplicemente usare policy di tipo Deny

Non proprio. Ci abbiamo provato prima che esistessero i permission boundary e, oltre alla complessità, c'erano semplicemente troppe scappatoie.

Può farmi un altro esempio semplice

Certamente! Eccone uno che usiamo noi stessi.

Alcuni utenti ci consentono di apportare modifiche IAM nei loro account. A questo scopo utilizziamo ruoli cross-account. Quando gli utenti distribuiscono il ruolo, applicano un permission boundary che non ci consente mai di modificare i permessi su noi stessi. Questo previene l'escalation di privilegi.

Credo di aver capito, ma come interagiscono tutte queste policy IAM

Consulti la documentazione AWS sulla logica di valutazione delle policy, ma ecco i miei appunti essenziali:

• Le Service Control Policy limitano ciò che chiunque può fare in un account (ad esempio possono attivare e disattivare servizi).
• Le policy di permesso IAM consentono a utenti e ruoli di fare determinate cose in un account.
• Le policy di risorsa IAM consentono a utenti e ruoli di interagire con la risorsa a cui la policy è collegata.
• I permission boundary definiscono i privilegi massimi che un utente o un ruolo può avere. Non consentono di fare le cose, ma possono impedire di farle.

Le policy funzionano tutte insieme. Per poter fare qualcosa, occorre avere un permesso da qualche parte nello stack che lo consenta e non deve esserci alcuna policy di deny che lo impedisca. Un solo Deny prevale su qualsiasi Allow, ovunque si trovi.

Mi ricordi quando usare i permission boundary

Quando vuole consentire a qualcuno di amministrare una parte di IAM in un account, limitandone però la portata, dovrebbe pensare a un permission boundary.

Anche quando utilizza strumenti IAM avanzati come il nostro nuovo FireMon Authorization Control, potrebbe comunque volere alcuni permission boundary, soprattutto negli account altamente sensibili.

Qual è l'unico esempio che aveva detto di voler includere?

Sebbene i permission boundary servano a impedire determinate azioni, richiedono comunque di specificare tutte le autorizzazioni allow. In altre parole, se scrive un permission boundary con un'istruzione DENY per bloccare l'unica cosa che non vuole far eseguire a quell'utente/ruolo, le servirà comunque un'istruzione ALLOW * altrimenti non potranno fare nulla.

Questa è la parte che all'inizio mi ha confuso, poiché avevo letto male la descrizione di Amazon e pensavo che si potesse usare un permission boundary semplicemente per bloccare le azioni. È possibile, ma a eccezione di un caso d'uso relativo alle resource policy che oggi non intendo affrontare, il permission boundary deve includere anche tutto ciò che si vuole consentire. Non si può semplicemente inserire un DENY per una cosa nel permission boundary e degli ALLOW per altre cose nella normale policy di autorizzazione IAM e aspettarsi che funzioni. Anche il permission boundary deve contenere le istruzioni ALLOW (e sì, a volte imbroglio e qui uso ALLOW *).

Ho ancora dei dubbi

Mi scriva un'email. Sul serio, queste cose sono davvero confuse.