IAM-beleidsevaluatie en expliciete deny

AWS-beveiliging gebruiken voor developers

Rahul Singh

Technical Product Manager

Een policy is een lijst met regels

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "true"
    },
    "IpAddress": {
      "aws:SourceIp": "203.0.113.0/24"
    }
  }
}

Drie velden van één IAM-statement op één lijn gestapeld en genummerd één tot drie: Effect is allow of deny, Action is welke API-call, en Resource is waar het naar wijst, benoemd met een ARN.

Een policy is een lijst met regels

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "true"
    },
    "IpAddress": {
      "aws:SourceIp": "203.0.113.0/24"
    }
  }
}

Vier velden van één IAM-statement op één lijn gestapeld en genummerd één tot vier: Effect is allow of deny, Action is welke API-call, Resource is waar het naar wijst benoemd met een ARN, en Condition is aan welke omstandigheden voldaan moet worden. Een afsluitende regel luidt: vier velden, één regel.

Drie velden vragen, één veld antwoordt

De vraag

Action: is dit de call
Resource: is dit het doel
Condition: kloppen de omstandigheden

Het antwoord

Effect: allow of deny

Vier velden van een IAM-statement verticaal gestapeld: Action, Resource en Condition gegroepeerd door één accolade met label "De vraag", en Effect gegroepeerd door een tweede accolade met label "Het antwoord".

Regels komen uit meer dan één bron

Een beleidsdocument gekoppeld aan een role, met een pijl van de role naar een bucket.

Identity-based

Gekoppeld aan de role
Wat mag deze role doen

Regels komen uit meer dan één bron

Een beleidsdocument gekoppeld aan een role, met een pijl van de role naar een bucket.

Een beleidsdocument gekoppeld aan een resource, met een pijl van de principal naar een bucket.

Identity-based

Gekoppeld aan de role
Wat mag deze role doen

Resource-based

Gekoppeld aan het doelobject
Wie mag deze bucket benaderen

Als regels elkaar tegenspreken

{"Effect": "Allow", "Action": "s3:*", "Resource": "*"}
{"Effect": "Deny",  "Action": "s3:DeleteObject", "Resource": "*"}

Als regels elkaar tegenspreken

{"Effect": "Allow", "Action": "s3:*", "Resource": "*"}
{"Effect": "Deny",  "Action": "s3:DeleteObject", "Resource": "*"}

Request: s3:DeleteObject resulteert in: Denied.

Een expliciete deny wint altijd van elke allow, hoe breed ook

Een allow-statement en een deny-statement die beide in één request uitkomen, met het deny-pad vet getekend en de uitkomst gemarkeerd als denied.

De volgorde van evaluatie, en implicit deny

Stroomschema van IAM-beleidsevaluatie: een API-request checkt eerst op een toepasselijke expliciete deny, dan op een toepasselijke allow, en eindigt bij impliciete deny als geen van beide wordt gevonden.

Explicit deny: iets zei nee
Allow: iets zei ja, en niets zei nee
Implicit deny: niets zei iets

Vier requests, drie uitkomsten

{"Effect": "Allow", "Action": "s3:*",
 "Resource": "*"}

{"Effect": "Deny", "Action": "s3:DeleteObject",
 "Resource": "*"}

s3:GetObject → allow: de brede allow dekt dit
s3:DeleteObject → explicit deny: een statement zegt nee
kms:Decrypt, dynamodb:GetItem → implicit deny: dit beleid noemt die services niet
KMS beheert encryptiesleutels; DynamoDB is een managed key-value database

Waarom permissies toevoegen vaak niet helpt

Dezelfde fout, twee oorzaken

Explicit deny

Nog een allow verandert niets
Vind de deny, beperk of verwijder die

Implicit deny

Eén smalle allow
Op de identity die de call deed

Een AccessDenied-fout die vertakt naar twee oorzaken. Links is een deny gevonden, dus extra allows veranderen niets. Rechts is geen allow gevonden, dus één smalle allow op de aanroepende identity lost het op.

Laten we oefenen!

AWS-beveiliging gebruiken voor developers