Identiteit, resource en grens

AWS-beveiliging gebruiken voor developers

Rahul Singh

Technical Product Manager

Welk beleid is de baas?

De wijziging die niets verandert

Hoofdstuk één: expliciet weigeren, of geen toestaan
Hier: een derde oorzaak

Een verzoek dat drie beleidscontroles doorloopt, met een vraagteken bij de beslissing.

Welk beleid is de baas?

Maximaal drie lagen

Identity-beleid op de aanroeper
Resource-beleid op de resource
Grens erboven, trekt alleen af

In je eigen account is één toestaan genoeg

Geweigerd door elke laag die het tegenkomt

Een verzoek stroomt van boven naar beneden door drie checks op volgorde: een identity-beleid, een resource-beleid en een permissions boundary, en eindigt met toegestaan.

Twee plekken waar beleid kan staan

Identity-based policy

Vastgemaakt aan de aanroeper
Wat die identiteit mag doen
Een pas die je draagt

Een rol bovenaan heeft een identity-beleid, met ruimte eronder voor de resource-kant van hetzelfde verzoek.

Twee plekken waar beleid kan staan

Identity-based policy

Vastgemaakt aan de aanroeper
Wat die identiteit mag doen
Een pas die je draagt

Resource-based policy

Vastgemaakt aan de resource
Wie erbij mag
Nodig voor cross-account aanroepers

Een rol bovenaan heeft een identity-beleid, terwijl een S3-bucket onderaan een resource-beleid heeft; een verzoek reist ertussen.

Voor jou beheerd, of door jou

Twee soorten identity-beleid

AWS managed: eigendom van AWS
Customer managed: eigendom van jou

Twee gestapelde kaarten vergelijken een AWS managed policy (eigendom van AWS, standaard breed) met een customer managed policy (eigendom van jou, afgestemd op de taak).

Voor jou beheerd, of door jou

Twee soorten identity-beleid

AWS managed: eigendom van AWS
Customer managed: eigendom van jou

Gemak of precisie

AWS managed: snel aan de slag
Customer managed: least privilege

Twee gestapelde kaarten vergelijken een AWS managed policy (eigendom van AWS, standaard breed) met een customer managed policy (eigendom van jou, afgestemd op de taak).

Een grens begrenst wat een beleid verleent

Waarom een account er één koppelt

Developers maken rollen, niemand eskaleert

Permissions boundary

Een plafond op wat een beleid verleent
Effectief: toegestaan door beide

Drie rechten verleend door een identity-beleid gaan door naar een permissions boundary die alleen S3-acties toestaat; de permissie iam:CreateUser stopt, de andere twee gaan door naar de effectieve rechten eronder.

Een grens begrenst wat een beleid verleent

Waarom een account er één koppelt

Developers maken rollen, niemand eskaleert

Permissions boundary

Een plafond op wat een beleid verleent
Effectief: toegestaan door beide

Waarom iam:CreateUser niets deed

Trekt alleen af, verleent nooit

Een grens begrenst wat een beleid verleent

Waarom een account er één koppelt

Developers maken rollen, niemand eskaleert

Permissions boundary

Een plafond op wat een beleid verleent
Effectief: toegestaan door beide

Waarom iam:CreateUser niets deed

Trekt alleen af, verleent nooit

Session policy: één AssumeRole-sessie

Een conditie vernauwt het toestaan

Condition key

Vernauwt een allow tot de context van het verzoek
aws:SourceIp: het netwerk van herkomst

Eén allow om een S3-object te lezen gaat door een voorwaardeband met een bronnetwerksleutel en een aanroeper-tag, en splitst daarna in toegestaan (context matcht) en geweigerd (matcht niet).

Een conditie vernauwt het toestaan

Condition key

Vernauwt een allow tot de context van het verzoek
aws:SourceIp: het netwerk van herkomst
aws:PrincipalTag: een tag op de aanroeper

ABAC: attribute-based access control

Eén beleid, veel principals

Eén allow om een S3-object te lezen gaat door een voorwaardeband met een bronnetwerksleutel en een aanroeper-tag, en splitst daarna in toegestaan (context matcht) en geweigerd (matcht niet).

Eén tabel, één tenant tegelijk

Eén gedeelde tabel

DynamoDB, één partition key per tenant
Niet op zichzelf isolerend

Een tenant A-aanroeper gaat door een leading keys-conditie naar een gedeelde DynamoDB-tabel, waar de rijen van tenant A terugkomen en die van tenant B en C worden geblokkeerd.

Eén tabel, één tenant tegelijk

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

Eén gedeelde tabel

DynamoDB, één partition key per tenant
Niet op zichzelf isolerend

Eén conditie vernauwt het

ForAllValues: elke opgegeven key moet matchen

Eén tabel, één tenant tegelijk

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

Eén gedeelde tabel

DynamoDB, één partition key per tenant
Niet op zichzelf isolerend

Eén conditie vernauwt het

ForAllValues: elke opgegeven key moet matchen

Het gat dat overblijft: niet elk verzoek noemt een partitie

dynamodb:Scan levert er geen, dus kan niets falen

Laten we oefenen!

AWS-beveiliging gebruiken voor developers