Tilbagekaldelse og rotation af eksponerede hemmeligheder

Når det er bekræftet, at en legitimationsoplysning er lækket, er hastighed vigtig — men rækkefølgen er det også. Hvis du deaktiverer en nøgle brat, kan du ødelægge produktionen, hvis du ikke først forstår, hvad der afhænger af den.

Målet er at afskære angriberen og samtidig holde legitime arbejdsbelastninger kørende, helst i én indøvet rækkefølge.

Det første skridt ved en lækket adgangsnøgle er at deaktivere den, ikke at slette den. Hvis du sætter nøglens status til Inactive, holder den straks op med at virke.

Ved at beholde den (inaktiv) indtil videre bevarer du den til retsmedicinsk sammenkædning i CloudTrail. Du sletter den først, når undersøgelsen er afsluttet.

For legitime anvendelser betyder udskiftning, at du udsteder en ny adgangsnøgle, opdaterer alle steder, der brugte den gamle, og derefter deaktiverer den kompromitterede nøgle.

Hvis du gør det i den rækkefølge, undgår du driftsstop: Den nye legitimationsoplysning er aktiv, før den gamle slås fra. Kontrollér altid først, at applikationen fungerer med den nye nøgle.

Deaktivering af en langsigtet nøgle afslutter ikke de midlertidige legitimationsoplysninger, som den allerede kan have udstedt. For roller skal du bruge IAM-funktionen revoke sessions, som tilknytter en afvisningspolitik baseret på et tidspunkt, der afgrænser udstedelsen af tokens.

Det ugyldiggør alle aktive sessioner, der er ældre end dette tidspunkt, og lukker dermed døren for legitimationsoplysninger, der allerede er havnet i hænderne på angriberen.

Før du udskifter nøglen, skal du finde ud af, hvor hemmeligheden findes. CloudTrail viser, hvilke tjenester og IP'er der brugte nøglen.

En hemmelighed, der er hardkodet mange steder, er netop grunden til, at hardkodning er farligt. Hvis du kortlægger alle forbrugere, sikrer du, at udskiftningen ikke efterlader et glemt system ødelagt eller en kopi af hemmeligheden stadig aktiv.

AWS Secrets Manager gemmer hemmeligheder som databaseadgangskoder og API-nøgler og kan automatisk udskifte dem efter en tidsplan ved hjælp af en Lambda-funktion.

Automatisk udskiftning betyder, at en lækket hemmelighed kun kan bruges i kort tid, og at applikationer henter den aktuelle værdi under kørsel i stedet for at opbevare en forældet, hardkodet kopi.

Én lækket legitimationsoplysning låser ofte op for andre. Hvis en angriber brugte en nøgle til at læse en database, kan databaseadgangskoderne også være kompromitteret.

Udskift også efterfølgende hemmeligheder. Tænk kæden igennem: Alle hemmeligheder, som angriberen kan have haft adgang til, skal betragtes som eksponerede og udskiftes.

Hvis AWS opdager en eksponering, kan tjenesten tilknytte AWSCompromisedKeyQuarantineV2 til brugeren. Det nægter adgang til risikofyldte handlinger, samtidig med at du stadig kan undersøge hændelsen.

Du må ikke bare fjerne den og gå videre. Betragt den som et tegn på, at du stadig skal gennemføre den egentlige afhjælpning — deaktivering, udskiftning og gennemgang.

Udskiftning stopper fremtidigt misbrug, men ophæver ikke tidligere skade. Brug CloudTrail til at opregne alle handlinger, som den kompromitterede legitimationsoplysning udførte.

Rul skadelige ændringer tilbage: Slet uautoriserede IAM-brugere, fjern bagdørsnøgler, og fjern ressourcer, som angriberen oprettede. Inddæmning og oprydning er separate, nødvendige skridt.

Reducer den fremtidige risiko efter genoprettelsen. Erstat langsigtede nøgler med midlertidige, rollebaserede legitimationsoplysninger, aktivér automatisk udskiftning af hemmeligheder, og tilføj scanning efter hemmeligheder i din CI/CD-pipeline.

Den stærkeste løsning er arkitektonisk: Hvis der ikke findes en statisk hemmelighed, der kan lækkes, er der intet for en angriber at finde.

Afhjælpningen er ikke afsluttet, før den er dokumenteret. Dokumentér, hvilke legitimationsoplysninger der blev udskiftet, hvad angriberen gjorde, og hvad der blev rullet tilbage.

Underret de interessenter, der står i din beredskabsvejledning, og følg dine forpligtelser til at underrette om brud, hvis regulerede data blev eksponeret. En tydelig dokumentation gør hændelsen til en læring og opfylder senere revisioner.

For at afhjælpe en lækket legitimationsoplysning skal du deaktivere adgangsnøglen (men bevare den til forensisk analyse), rotere til en ny nøgle uden driftsafbrydelse og tilbagekalde aktive rollesessioner for at ugyldiggøre midlertidige legitimationsoplysninger, der allerede er udstedt. Kortlæg først alle forbrugere, roter efterfølgende hemmeligheder, som angriberen kan have fået adgang til, og rul ondsindede ændringer tilbage fra CloudTrail. Brug Secrets Manager til automatisk rotation, og gå over til midlertidige legitimationsoplysninger baseret på roller for at forhindre gentagelser.