Identità, risorsa e boundary

Uso di AWS Security per sviluppatori

Rahul Singh

Technical Product Manager

Quale policy comanda?

La modifica che non cambia nulla

Capitolo uno: deny esplicito o nessun allow
Qui: una terza causa

Una richiesta incontra tre controlli di policy impilati, con un punto interrogativo dove andrebbe la decisione.

Quale policy comanda?

Fino a tre livelli

Policy di identità sul chiamante
Policy di risorsa sulla risorsa
Boundary sopra, solo sottrae

Nel tuo account, basta che una consenta

Negata da qualsiasi livello che incontra

Una richiesta scorre dall'alto verso il basso attraverso tre controlli in ordine: una policy di identità, una policy di risorsa e un permissions boundary, prima di arrivare a un risultato consentito.

Due posti in cui può vivere una policy

Policy basata sull'identità

Allegata al chiamante
Cosa può fare quell'identità
Un badge che indossi

Un ruolo in alto ha una policy basata sull'identità, con spazio sotto per il lato risorsa della stessa richiesta.

Due posti in cui può vivere una policy

Policy basata sull'identità

Allegata al chiamante
Cosa può fare quell'identità
Un badge che indossi

Policy basata sulla risorsa

Allegata alla risorsa
Chi può toccarla
Necessaria per chiamanti cross-account

Un ruolo in alto ha una policy basata sull'identità mentre un bucket S3 sotto ha una policy basata sulla risorsa, e una richiesta scende tra i due.

Gestita per te o da te

Due tipi di policy basate sull'identità

Gestite da AWS: di proprietà di AWS
Gestite dal cliente: di tua proprietà

Due schede a confronto: una policy gestita da AWS, di proprietà di AWS e ampia di default, e una policy gestita dal cliente, di tua proprietà e mirata al task.

Gestita per te o da te

Due tipi di policy basate sull'identità

Gestite da AWS: di proprietà di AWS
Gestite dal cliente: di tua proprietà

Comodità o precisione

Gestite da AWS: muoversi veloci
Gestite dal cliente: minimo privilegio

Due schede a confronto: una policy gestita da AWS, di proprietà di AWS e ampia di default, e una policy gestita dal cliente, di tua proprietà e mirata al task.

Un boundary limita ciò che concede una policy

Perché un account ne applica una

Gli sviluppatori creano ruoli, nessuno fa escalation

Permissions boundary

Un tetto a ciò che una policy concede
Efficaci: consentite da entrambe

Tre permessi concessi da una policy di identità passano in un permissions boundary che consente solo azioni S3, dove il permesso iam:CreateUser viene bloccato e gli altri due continuano nei permessi effettivi sotto.

Un boundary limita ciò che concede una policy

Perché un account ne applica una

Gli sviluppatori creano ruoli, nessuno fa escalation

Permissions boundary

Un tetto a ciò che una policy concede
Efficaci: consentite da entrambe

Perché iam:CreateUser non ha fatto nulla

Solo sottrae, non concede mai

Un boundary limita ciò che concede una policy

Perché un account ne applica una

Gli sviluppatori creano ruoli, nessuno fa escalation

Permissions boundary

Un tetto a ciò che una policy concede
Efficaci: consentite da entrambe

Perché iam:CreateUser non ha fatto nulla

Solo sottrae, non concede mai

Session policy: una sessione AssumeRole

Una condizione restringe l'allow

Chiave di condizione

Restringe un allow al contesto della richiesta
aws:SourceIp: la rete di origine

Un allow per leggere un oggetto S3 passa attraverso una fascia di condizioni con una chiave di rete di origine e una chiave di tag del chiamante, poi si divide in un percorso consentito dove il contesto corrisponde e uno negato dove non corrisponde.

Una condizione restringe l'allow

Chiave di condizione

Restringe un allow al contesto della richiesta
aws:SourceIp: la rete di origine
aws:PrincipalTag: un tag sul chiamante

ABAC: attribute-based access control

Una policy, molti principal

Una tabella, un tenant alla volta

Una tabella condivisa

DynamoDB, una partition key per tenant
Da sola non isola

Un chiamante del tenant A passa attraverso una condizione di chiavi iniziali in una tabella DynamoDB condivisa, dove le righe del tenant A vengono restituite e quelle dei tenant B e C vengono bloccate.

Una tabella, un tenant alla volta

"Condition": {
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["${aws:PrincipalTag/tenant}"]
  }
}

Una tabella condivisa

DynamoDB, una partition key per tenant
Da sola non isola

Una condizione la restringe

ForAllValues: ogni chiave fornita deve corrispondere

Una tabella, un tenant alla volta

"Action": ["dynamodb:Query", "dynamodb:GetItem", "dynamodb:Scan"],
"Condition": {
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["${aws:PrincipalTag/tenant}"]
  }
}

Una tabella condivisa

DynamoDB, una partition key per tenant
Da sola non isola

Una condizione la restringe

ForAllValues: ogni chiave fornita deve corrispondere

Il vuoto che resta: non tutte le richieste indicano una partition

dynamodb:Scan non ne fornisce, quindi nulla può fallire

Esercitiamoci!

Uso di AWS Security per sviluppatori