Hvad en permission boundary begrænser

En tilladelsesgrænse er en avanceret IAM-funktion, der fastsætter de maksimale tilladelser, som en bruger eller rolle nogensinde kan have. Den tildeler ikke noget i sig selv, men begrænser, hvad identitetsbaserede politikker reelt kan tillade. Tilladelsesgrænser er et populært emne til eksamen, fordi de muliggør sikker delegering af tilladelsesadministration.

En identitetsbaseret politik tildeler tilladelser, mens en tilladelsesgrænse begrænser dem. De effektive tilladelser er snitpunktet mellem de to: En handling er kun tilladt, hvis både identitetspolitikken og grænsen tillader den. En grænse kan reducere, men aldrig udvide, det som identitetspolitikken tildeler.

Antag, at en brugers identitetspolitik tillader fuld adgang til S3 og EC2, men at brugerens tilladelsesgrænse kun tillader S3. Brugeren kan kun udføre S3-handlinger, fordi grænsen begrænser dem. Fjern grænsen, og EC2-tilladelserne bliver effektive igen. Grænsen håndhæver stille og roligt en øvre grænse.

Denne grænsepolitik tillader kun S3- og CloudWatch-handlinger. Uanset hvad identitetspolitikken siger, kan brugeren aldrig få flere tilladelser end til disse tjenester.

Det vigtigste anvendelsesområde er sikker delegering. Du vil gerne give udviklere mulighed for at oprette deres egne IAM-roller, men frygter, at de vil tildele for mange tilladelser. Ved at kræve, at alle roller, de opretter, har en tilladelsesgrænse, garanterer du, at rollerne aldrig kan overskride grænsen, uanset hvor bred den tilknyttede politik er.

Både grænser og SCP'er begrænser tilladelser, men de adskiller sig i omfang. En tilladelsesgrænse gælder for en enkelt bruger eller rolle og angives i IAM. En SCP gælder for hele konti i en organisation. Eksamen tester, om du vælger det rigtige værktøj: Pr. identitet bruges en grænse, og for hele kontoen bruges en SCP.

I evalueringsforløbet vinder et eksplicit Deny stadig over alt andet, herunder grænser. Ellers fungerer grænsen som et loft: Handlingen kræver en Allow i både identitetspolitikken og grænsen. Ressourcebaserede politikker kan i visse tilfælde give adgang uafhængigt af grænsen, hvilket er en vigtig nuance at huske.

En udbredt misforståelse er, at det at tilføje en handling til en grænse tildeler tilladelsen. Det gør det ikke. Hvis identitetspolitikken mangler tilladelsen, har det ingen effekt, at grænsen tillader den. Identitetspolitikken skal tildele tilladelsen, og grænsen skal også tillade den, før handlingen kan lykkes.

En nuance, som eksamen tester: Tilladelsesgrænser begrænser, hvad en principals identitetsbaserede politikker kan gøre, men de begrænser i visse tilfælde ikke adgang, som en ressourcebaseret politik tildeler denne principal. En grænse, der begrænser en rolle til S3, kan derfor stadig gøre det muligt at tildele rollen SQS-adgang via en køpolitik. Tag højde for dette hul i dit design.

For at håndhæve, at delegerede principals altid tilknytter en grænse, skriver du en tilladelsespolitik med en betingelse, der kræver, at iam:PermissionsBoundary er lig med et bestemt ARN for grænsen på enhver rolle, de opretter. Det forhindrer en udvikler i at oprette roller uden sikkerhedsforanstaltningen og lukker smuthullet i delegeringen.

En tilladelsesgrænse begrænser de maksimale tilladelser for en enkelt bruger eller rolle: Den effektive adgang er snitpunktet mellem grænsen og identitetspolitikken. Den tildeler aldrig tilladelser i sig selv. Dens vigtigste formål er sikker delegering af oprettelse af IAM-roller, håndhævet ved at kræve grænsen via betingelsen iam:PermissionsBoundary.

En tilladelsesgrænse fastsætter de maksimale tilladelser for en enkelt bruger eller rolle; den effektive adgang er snitpunktet mellem grænsen og identitetspolitikken. Den tildeler aldrig tilladelser i sig selv, og et eksplicit deny vinder stadig. Dens primære formål er sikker delegering, håndhævet via betingelsen iam:PermissionsBoundary.