Rotér AWS-adgangsnøgle uden nedetid

Du kan udskifte en IAM-adgangsnøgle uden planlagt driftsstop ved at oprette en ny nøgle, mens den gamle stadig er aktiv. Flyt alle integrationer, kontrollér den gamle nøgles seneste brug, og deaktivér den før sletning. AWS’ rotationsprocedure beskriver også, hvordan du kan genaktivere den gamle nøgle, hvis en afhængighed er overset.

Overlapningen giver tid til at rulle ændringen ud, men er ikke i sig selv en garanti mod driftsstop. En sjældent kørt opgave kan stadig bruge den gamle nøgle. Afprøv derfor de arbejdsgange, der skal fungere med den nye nøgle, og behold muligheden for at gå tilbage, indtil de relevante kørsler er gennemført.

Afgræns rotationen, før du opretter nøglen

Find IAM-brugeren, den gamle nøgles ID og alle steder, hvor nøgleparret bruges. Gennemgå applikationer, planlagte jobs, integrationsplatforme, lokale CLI-profiler og hemmelighedslagre. Notér, hvem der kan genstarte eller genudrulle hver integration: En opdateret hemmelighed hjælper ikke en proces, som stadig kører med den værdi, den indlæste ved opstart.

Kontrollér også, at IAM-brugeren har plads til en erstatningsnøgle. AWS’ vejledning om adgangsnøgler angiver højst to nøgler pr. bruger og anbefaler CloudTrail til at overvåge nøglebrug. Hvis begge pladser er optaget, må du først fastslå, hvilken nøgle der kan fjernes forsvarligt. Slet ikke en ukendt nøgle alene for at frigøre plads.

Fastlæg et stopkriterium, før udrulningen begynder: Hver kendt integration skal have modtaget det nye nøglepar og gennemført den AWS-handling, den normalt skal kunne udføre. Planlæg desuden observationen, så den omfatter relevante periodiske jobs. Et job, der kun kører ved månedsskifte, kræver en anden kontrol end en tjeneste, der sender anmodninger hele dagen.

Opret den nye nøgle, og rul den ud

I AWS Management Console åbner du IAM, vælger Users og derefter den relevante brugers Security credentials. Under Access keys vælger du Create access key. I den beskrevne konsolprocedure vælger du Other på siden med alternativer, fortsætter med Next og opretter nøglen. Gem både nøgle-ID og den hemmelige adgangsnøgle sikkert med det samme; den hemmelige del kan kun hentes ved oprettelsen. Den nye nøgle er aktiv fra start.

Med AWS CLI er oprettelsen aws iam create-access-key --user-name IAM_USER, hvor IAM_USER erstattes med brugernavnet. Kommandoens svar indeholder den hemmelige nøgle. Lad derfor ikke svaret havne i almindelige logs eller en supportsag; overfør legitimationsoplysningerne til den løsning, integrationen bruger til hemmeligheder.

Udrul nøgleparret til hver forbruger, og sørg for, at processer, som kun læser konfiguration ved opstart, indlæser den nye værdi. Afprøv derefter en relevant AWS-anmodning fra hver integration. En vellykket identitetskontrol viser ikke alene, at den nødvendige læse-, skrive- eller køfunktion virker. Fejler en integration med den nye nøgle, skal du rette dens konfiguration eller tilladelser, mens den gamle nøgle fortsat er aktiv.

Undersøg, om den gamle nøgle stadig bruges

Se feltet Last used for den gamle nøgle under brugerens Security credentials, eller kør aws iam get-access-key-last-used --access-key-id OLD_KEY_ID. Erstat OLD_KEY_ID med den gamle nøgles faktiske ID. Sammenhold den seneste registrerede brug med tidspunktet for udrulningen og din liste over integrationer; kontrol af den nye nøgles brug besvarer ikke spørgsmålet om, hvorvidt den gamle stadig anvendes.

Hvis den gamle nøgle bruges efter udrulningen, er stopkriteriet ikke opfyldt. Find forbrugeren, opdatér den, og kontrollér igen. Manglende registreret brug er heller ikke bevis for, at alle afhængigheder er væk: En opgave, der kun kører periodisk eller ved fejl, har måske endnu ikke forsøgt at bruge nøglen. Brug kørselsplaner, applikationslogs og konkrete funktionstests sammen med oplysningen om seneste brug.

Deaktivér og overvåg med mulighed for rollback

Når alle kendte forbrugere virker med den nye nøgle, vælger du Actions og Deactivate for den gamle nøgle i konsollen. I CLI bruger du aws iam update-access-key --user-name IAM_USER --access-key-id OLD_KEY_ID --status Inactive. Kontrollér nøgle-ID’et før udførelse: Det er den gamle nøgle, der skal skifte status.

Nu skal applikationer og jobs fortsætte med kun den nye nøgle. Overvåg de handlinger, de normalt udfører, og undersøg autentificeringsfejl og afviste AWS-anmodninger. Lad også de periodiske kørsler, som indgår i din observationsperiode, blive gennemført. Fejl efter deaktivering betyder, at oprydningen skal standses, mens du finder den resterende afhængighed.

Hvis en overset integration mister adgang, kan du vælge Activate på den gamle nøgle eller køre aws iam update-access-key --user-name IAM_USER --access-key-id OLD_KEY_ID --status Active. Ret derefter integrationen, afprøv dens normale handling med den nye nøgle, og deaktivér den gamle igen. Er den gamle nøgle mistænkt for at være kompromitteret, bør genaktivering ikke bruges som almindelig driftsgenvej; håndtér eksponeringen som en sikkerhedshændelse.

Slet først, når afhængighederne er afkræftet

Slet den gamle nøgle, når alle kendte integrationer fungerer, de relevante periodiske kørsler er gennemført, og observationen efter deaktivering ikke viser afhængigheder. I konsollen vælger du Delete for den korrekte nøgle og følger bekræftelsen. I CLI er kommandoen aws iam delete-access-key --user-name IAM_USER --access-key-id OLD_KEY_ID. Registrér, hvilken nøgle der blev slettet, og hvilke kontroller der blev gennemført. Efter sletning kan den gamle nøgle ikke bruges til rollback.

Tag samtidig stilling til, om næste rotation overhovedet kræver en langlivet nøgle. AWS’ sikkerhedsvejledning anbefaler IAM-roller med midlertidige legitimationsoplysninger, hvor arbejdsbelastningen understøtter det, og forskellige adgangsnøgler til forskellige applikationer, hvis langlivede nøgler er nødvendige. Separate nøgler gør det lettere at identificere og tilbagekalde én integration, men grænsen på to nøgler pr. IAM-bruger betyder, at en nøgle pr. applikation også kræver en passende opdeling af brugerne.

Læs også: