AWS access key og secret key: sådan opretter, bruger, roterer og deler du dem sikkert

En AWS-adgangsnøgle består af to strenge, som tilsammen lader et program handle som en IAM-bruger: access key ID, som identificerer nøglen, og secret access key, som beviser, at man har den. Folk søger efter dem under tre navne, ”access key and secret key”, ”secret access key” og bare ”AWS secret key”, men det er det samme par. Parret dukker op i CLI-konfigurationer, i CI-pipelines og alt for ofte i en Slack-besked.

Denne guide gennemgår, hvad de to halvdele er, hvordan du opretter og konfigurerer dem, hvordan du roterer dem uden nedetid, og hvad du gør, når en nøgle lækker. Til sidst kommer spørgsmålet, der dukker op, hver gang en udvikler starter, eller en ekstern konsulent begynder: hvordan giver man en secret key til en person uden at lægge den i en e-mail?

Access key ID og secret access key

Langtidsnøgler starter med AKIA. Midlertidige loginoplysninger fra STS, som også følger med et sessionstoken, starter med ASIA og udløber af sig selv. Ser du en ASIA-nøgle i en konfigurationsfil, holder den op med at virke inden for få timer, og sådan er det tænkt.

Ingen af de to halvdele giver tilladelser. Nøglen logger ind som en IAM-bruger, og de politikker, der er knyttet til brugeren, bestemmer, hvad den identitet må. En lækket nøgle på en bruger med kun læseadgang er et problem. En lækket nøgle på en administrator er en sikkerhedshændelse.

Hvornår har du overhovedet brug for en langtidsnøgle?

Det ærlige svar er: sjældnere, end folk tror.

• Arbejdsbelastninger på AWS (EC2, Lambda, ECS, EKS) bør bruge IAM-roller. SDK'et henter automatisk kortlivede loginoplysninger, og der er intet at rotere eller lække.
• Personer bør logge ind via IAM Identity Center eller fødereret SSO og få midlertidige loginoplysninger fra aws sso login.
• CI-systemer som GitHub Actions kan påtage sig en rolle via OIDC uden en gemt nøgle.
• Langtidsnøgler er tilbage til de tilfælde, der ikke kan bruge nogen af ovenstående: et værktøj på en bærbar computer uden understøttelse af SSO, en tredjepartstjeneste, der kun accepterer statiske nøgler, eller et ældre job, du ikke har flyttet endnu.

Har du brug for en, så opret den på en dedikeret IAM-bruger med den snævreste politik, der kan klare opgaven, og aldrig på en persons administratorkonto.

Opret og konfigurer en nøgle

Åbn brugeren i IAM-konsollen, vælg ”Security credentials” og derefter ”Create access key”. Vælg det anvendelsesområde, AWS spørger om, læs det alternativ, AWS foreslår, og fortsæt. Den hemmelige del vises præcis én gang. Gem den direkte i dit system til hemmeligheder eller din adgangskodeadministrator, eller download CSV-filen, og slet den efter importen. Hver IAM-bruger kan højst have to nøgler ad gangen, og det er det, der gør rotation mulig.

På en maskine bør du konfigurere en navngivet profil frem for standardprofilen:

aws configure --profile deploy-tool
# AWS Access Key ID [None]: AKIA...
# AWS Secret Access Key [None]: ...
# Default region name [None]: eu-west-1

Kommandoen skriver til ~/.aws/credentials og ~/.aws/config. Begræns adgangen til filen til din egen bruger med chmod 600. I containere og CI skal du indsætte AWS_ACCESS_KEY_ID og AWS_SECRET_ACCESS_KEY som hemmeligheder fra platformens eget lager, ikke som almindelige variabler i en YAML-fil. Giv dem aldrig med på en kommandolinje, hvor de ender i shell-historikken.

Roter uden at ødelægge noget

Rotation sker i fire trin, og grænsen på to nøgler er det, der gør det muligt.

1. Opret den anden nøgle på den samme bruger.
2. Opdater alt, der bruger nøglen, til den nye: konfigurationer, hemmeligheder i CI og posten i dit system til hemmeligheder. IAM-konsollen viser, hvornår hver nøgle sidst blev brugt, så du kan se, om du har overset noget.
3. Deaktiver den gamle nøgle. Vent en dag eller en udrulningscyklus. Hvis noget går i stykker, så genaktiver den, ret det, der brugte den, og prøv igen.
4. Slet den gamle nøgle, når intet længere har brugt den.

Gør det efter en fast plan for de nøgler, der ikke kan undværes, og ved bestemte hændelser for dem alle: en medarbejder stopper, en leverandør bliver skiftet ud, en bærbar computer bliver væk, eller der er mistanke om et læk. AWS Config og IAM Access Analyzer kan markere nøgler, der er ældre, end jeres politik tillader.

Når en nøgle er blevet eksponeret

Betragt en nøgle, der har været synlig i et repository, en log, en sag eller en chat, som kompromitteret, også selv om den blev slettet et minut senere. Scannere finder hemmeligheder, der er blevet pushet, på få sekunder.

1. Deaktiver nøglen i IAM med det samme. Vent ikke med det, til du har oprettet en ny nøgle, medmindre nedetiden ville være værre end eksponeringen.
2. Opret en ny nøgle, og opdater alt, der brugte den gamle.
3. Læs CloudTrail for hver handling, der er udført med det access key ID siden eksponeringen. Se efter nye IAM-brugere eller nøgler, nye instanser, ændrede bucket-politikker og ukendte regioner.
4. Tjek regningen og Cost Explorer for stigninger, der ligner kryptomining.
5. Fjern hemmeligheden fra kode, logfiler og git-historikken. AWS kan selv knytte politikken AWSCompromisedKeyQuarantine til brugeren, når den opdager et offentligt læk. Lad den blive, indtil oprydningen er færdig.
6. Slet den gamle nøgle, find derefter ud af, hvordan den endte der, og luk den vej.

Sådan deler du en AWS secret key med en person

Nogle gange skal nøglen ud til et menneske: en konsulent, der skal bruge den til et udrulningsværktøj, en udvikler, der starter på et projekt, før SSO er sat op, eller en integration hos en leverandør, der vil have den indsat i sit dashboard. E-mail, Slack og supportsager gemmer alle kopier, og en hemmelighed på 40 tegn kan læses i årevis i hvilken som helst af dem.

Den sikre fremgangsmåde tager et minut:

1. Opret en nøgle til den person på en dedikeret IAM-bruger med præcis den politik, opgaven kræver, og intet andet. Del ikke en nøgle, som noget andet bruger.
2. Indsæt kun secret access key i et hemmeligt engangslink. Den krypteres i din browser, før den gemmes, den gemte kopi destrueres, første gang linket åbnes, og linket udløber efter en time, en dag eller en uge, hvis ingen åbner det.
3. Send linket med en kort forklaring på én linje. Send access key ID, regionen og profilnavnet i en separat besked. Ingen af dem er hemmelige hver for sig.
4. Tilføj en adgangssætning med en Pro-konto til alt, der giver mere end læseadgang, og giv den videre via sms eller i et opkald.
5. Bekræft, at modtageren har åbnet det. Hvis linket viser, at indholdet allerede er set, og modtageren ikke har åbnet det, så deaktiver nøglen, og start forfra.
6. Deaktiver nøglen, når samarbejdet slutter, og slet den bagefter.

Guiden til API-nøgler bruger den samme fremgangsmåde for andre udbydere, og sikker deling af links for udviklere viser, hvordan du automatiserer overdragelsen ved onboarding med et script.

Læs også

• Sådan deler du API-nøgler sikkert
• Cloud secret manager: hvad det er, og hvordan du vælger en
• Sådan sender du et midlertidigt databaselogin sikkert til en konsulent
• Sådan virker hemmelige engangslinks