Nøglepolitikker, grants og betingelser

At oprette en nøgle er kun halvdelen af opgaven; at styre hvem der må bruge den er den anden halvdel. KMS bruger flere adgangsmekanismer, der lægges oven på hinanden.

Den vigtigste er nøglepolitikken, som er den ressourcebaserede politik, der er knyttet direkte til nøglen.

Alle KMS-nøgler har en nøglepolitik, som er den primære myndighed over adgangen.

• I modsætning til de fleste tjenester skal en KMS-nøgle have en nøglepolitik.
• Hvis nøglepolitikken ikke giver adgang, kan IAM-politikker alene ikke gøre det.

Det gør nøglepolitikken til adgangsvagten.

Adgang til en KMS-nøgle kræver, at nøglepolitikken aktiverer IAM, hvorefter IAM og nøglepolitikken kombineres.

Standardnøglepolitikken indeholder en erklæring, der giver kontoens IAM-principaler adgang underlagt deres IAM-politikker. Uden denne erklæring kan kun principaler, der er nævnt direkte i nøglepolitikken, bruge nøglen.

En tildeling er en fleksibel, midlertidig måde at delegere brugen af en nøgle på.

• Den tillader bestemte handlinger for en principal, ofte programmatisk.
• AWS-tjenester bruger tildelinger til at få adgang til nøgler på dine vegne.

Tildelinger kan afsluttes eller tilbagekaldes, når de ikke længere er nødvendige, hvilket gør dem ideelle til kortvarig delegering.

Vælg ud fra levetid og detaljeringsgrad:

• Brug nøglepolitikken og IAM til langvarig, bred adgang.
• Brug tildelinger til detaljerede, midlertidige tilladelser, som ofte oprettes dynamisk af tjenester eller apps.

Tildelinger betyder, at du ikke behøver redigere nøglepolitikken til kortvarige behov.

KMS understøtter effektive betingelsesnøgler i politikker, såsom kms:ViaService.

ViaService begrænser brugen af nøglen til anmodninger, der kommer gennem en bestemt AWS-tjeneste (f.eks. kun via S3), så en principal kun kan dekryptere, når S3 foretager kaldet, og ikke direkte.

Krypteringskontekst er et sæt nøgle-værdi-par, der sendes med kryptering/dekryptering, og som er kryptografisk bundet til handlingen.

• Den samme kontekst skal angives ved dekryptering.
• Den vises i CloudTrail til revision.

Politikker kan kræve en bestemt kontekst med betingelsen kms:EncryptionContext.

Hvis en anden konto skal kunne bruge en nøgle, skal nøglepolitikken tillade den eksterne konto, og den eksterne principal skal også have IAM-tilladelse.

Det er det samme tosidede mønster som roller på tværs af konti: ressourcepolitikken (her nøglepolitikken) og den kaldende principals IAM-politik skal begge tillade handlingen.

Anvend princippet om mindste privilegium på nøgler:

• Adskil nøgleadministratorer (som administrerer nøglen) fra nøglebrugere (som krypterer/dekrypterer).
• Undgå kms:* for brugere.
• Brug ViaService og krypteringskontekst til at begrænse omfanget.

Det begrænser skadeomfanget, hvis en principal kompromitteres.

En klassisk fejl er at redigere en nøglepolitik og fjerne erklæringen, der aktiverer IAM.

Uden den mister selv kontoens administratorer adgangen, og fordi nøglepolitikken er adgangsvagten, kan du helt låse dig selv ude fra nøglen. Bevar altid en administrativ principal på kontoniveau i nøglepolitikken for at undgå en nøgle, der ikke kan gendannes.

Kombiner CloudTrail (alle KMS-kald med kontekst) og IAM Access Analyzer (nøglepolitikker, der giver ekstern adgang) for at revidere, hvem der kan og faktisk bruger hver nøgle.

Regelmæssig gennemgang opdager for bredt formulerede nøglepolitikker, før de bliver en risiko.

Du lærte, hvordan KMS-adgang kontrolleres.

• Nøglepolitikken er den primære adgangsvagt og skal aktivere IAM, for at den kan bruges.
• Tildelinger giver midlertidig delegering med detaljerede tilladelser.
• Betingelser som ViaService og krypteringskontekst begrænser omfanget.