Utvärdering av IAM-policyer och explicit nekande

Använda AWS-säkerhet för utvecklare

Rahul Singh

Technical Product Manager

En policy är en lista med regler

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

Tre fält i ett IAM-uttalande staplade på en gemensam linje och numrerade ett till tre: Effect är allow eller deny, Action är vilket API-anrop, och Resource är vad det pekar på, angivet med en ARN.

En policy är en lista med regler

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

Fyra fält i ett IAM-uttalande staplade på en gemensam linje och numrerade ett till fyra: Effect är allow eller deny, Action är vilket API-anrop, Resource är vad det pekar på angivet med en ARN, och Condition är vilka omständigheter som måste gälla. En avslutande rad lyder fyra fält, en regel.

Tre fält frågar, ett fält svarar

Frågan

Action: är detta anropet
Resource: är detta målet
Condition: stämmer omständigheterna

Svaret

Effect: allow eller deny

Ett IAM-uttalandes fyra fält staplade vertikalt: Action, Resource och Condition grupperade med en hakparentes märkt "Frågan", och Effect grupperat med en andra hakparentes märkt "Svaret".

Regler kommer från mer än en plats

Ett policydokument kopplat till en roll, med en pil från rollen till en bucket.

Identitetsbaserad

Kopplad till rollen
Vad får rollen göra

Regler kommer från mer än en plats

Ett policydokument kopplat till en roll, med en pil från rollen till en bucket.

Ett policydokument kopplat till en resurs, med en pil från huvudmannen till en bucket.

Identitetsbaserad

Kopplad till rollen
Vad får rollen göra

Resursbaserad

Kopplad till det som nås
Vem får nå denna bucket

När reglerna är oense

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

När reglerna är oense

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

Begäran: s3:DeleteObject resulterar i: Nekad.

Ett explicit nekande vinner alltid över ett tillåtande, oavsett hur brett

Ett allow-uttalande och ett deny-uttalande som båda påverkar en begäran, där deny-vägen är tydligt markerad och resultatet märkt nekad.

Utvärderingsordningen, och implicit nekande

Flödesschema för IAM-policyutvärdering: en API-begäran kontrolleras först mot ett tillämpligt explicit nekande, sedan mot ett tillämpligt tillåtande, och når implicit nekande om inget av dem hittas.

Explicit nekande: något sa nej
Allow: något sa ja, och inget sa nej
Implicit nekande: inget sa någonting alls

Fyra begäranden, tre utfall

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

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

s3:GetObject → allow: det breda tillåtandet täcker det
s3:DeleteObject → explicit nekande: ett uttalande säger nej
kms:Decrypt, dynamodb:GetItem → implicit nekande: denna policy nämner aldrig dessa tjänster
KMS lagrar krypteringsnycklar; DynamoDB är en hanterad nyckel-värde-databas

Varför det ofta inte hjälper att lägga till behörigheter

Samma fel, två orsaker

Explicit nekande

Ytterligare ett tillåtande ändrar ingenting
Hitta nekandet, begränsa eller ta bort det

Implicit nekande

Ett smalt tillåtande
På identiteten som gjorde anropet

Ett AccessDenied-fel som förgrenar sig i två orsaker. Till vänster hittades ett nekande, så fler tillåtanden ändrar ingenting. Till höger hittades inget tillåtande, så ett smalt tillåtande på den anropande identiteten löser det.

Nu kör vi en övning!

Använda AWS-säkerhet för utvecklare