Återkalla och rotera exponerade hemligheter

När en autentiseringsuppgift har bekräftats läckt är snabbhet viktig – men även ordningsföljden. Om ni inaktiverar en nyckel abrupt kan produktionen sluta fungera om ni inte först förstår vad som är beroende av den.

Målet är att stänga ute angriparen samtidigt som legitima arbetslaster fortsätter att fungera, helst i en enda övad sekvens.

Det första steget vid en läckt access key är att inaktivera den, inte att radera den. Om ni omedelbart ställer in nyckelns status på Inactive slutar den att fungera.

Genom att behålla den (inaktiv) tills vidare finns den kvar för forensisk korrelation i CloudTrail. Radera den först när utredningen är klar.

För legitima användningsområden innebär rotation att utfärda en ny access key, uppdatera varje plats där den gamla används och därefter inaktivera den komprometterade nyckeln.

Den ordningen förhindrar avbrott: den nya autentiseringsuppgiften är aktiv innan den gamla stängs av. Kontrollera alltid först att applikationen fungerar med den nya nyckeln.

Att inaktivera en långlivad nyckel avslutar inte tillfälliga autentiseringsuppgifter som den redan kan ha utfärdat. För roller använder ni IAM-funktionen revoke sessions, som kopplar en nekandepolicy baserad på en tidpunkt för när token utfärdades.

Det ogiltigförklarar alla aktiva sessioner som är äldre än den tidpunkten och stänger dörren för autentiseringsuppgifter som redan finns i angriparens händer.

Ta reda på var hemligheten finns innan ni roterar den. CloudTrail visar vilka tjänster och IP-adresser som använde nyckeln.

En hemlighet som hårdkodats på många platser visar exakt varför hårdkodning är farligt. Genom att kartlägga alla användare säkerställer ni att rotationen inte lämnar ett bortglömt system trasigt eller en kopia av hemligheten fortfarande aktiv.

AWS Secrets Manager lagrar hemligheter som databaslösenord och API-nycklar och kan rotera dem automatiskt enligt ett schema med hjälp av en Lambda-funktion.

Automatisk rotation innebär att en läckt hemlighet bara kan användas under en kort tid och att applikationer hämtar det aktuella värdet vid körning i stället för att lagra en gammal, hårdkodad kopia.

En läckt autentiseringsuppgift låser ofta upp andra. Om en angripare använde en nyckel för att läsa en databas kan även databaslösenorden vara komprometterade.

Rotera även efterföljande hemligheter. Tänk igenom hela kedjan: varje hemlighet som angriparen kan ha kommit åt måste betraktas som exponerad och ersättas.

Om AWS upptäcker en exponering kan tjänsten koppla AWSCompromisedKeyQuarantineV2 till användaren, vilket nekar högriskåtgärder samtidigt som ni fortfarande kan utreda.

Koppla inte bara bort den och gå vidare. Se den som en signal om att ni fortfarande måste slutföra den faktiska åtgärden – inaktivering, rotation och granskning.

Rotation stoppar framtida missbruk men återställer inte tidigare skador. Använd CloudTrail för att lista varje åtgärd som den komprometterade autentiseringsuppgiften utförde.

Återställ skadliga ändringar: radera otillåtna IAM-användare, ta bort bakdörrsnycklar och avveckla resurser som angriparen skapade. Inneslutning och sanering är separata, nödvändiga steg.

Minska framtida risk efter återställningen. Ersätt långlivade nycklar med tillfälliga rollbaserade autentiseringsuppgifter, aktivera automatisk rotation av hemligheter och lägg till sökning efter hemligheter i er CI/CD-pipeline.

Den starkaste lösningen är arkitektonisk: om det inte finns någon statisk hemlighet att läcka finns det inget för angriparen att hitta.

Åtgärden är inte klar förrän den har dokumenterats. Dokumentera vilka autentiseringsuppgifter som roterades, vad angriparen gjorde och vad som återställdes.

Informera de intressenter som anges i er körhandbok och följ era skyldigheter att anmäla incidenter om reglerade uppgifter exponerades. En tydlig dokumentation gör incidenten till en lärdom och uppfyller senare revisioner.

För att åtgärda en läckt autentiseringsuppgift ska du deaktivera åtkomstnyckeln (och bevara den för forensisk analys), rotera till en ny nyckel utan driftstopp och återkalla aktiva rollsessioner för att göra redan utfärdade tillfälliga autentiseringsuppgifter obrukbara. Kartlägg först alla användare, rotera de underliggande hemligheter som angriparen kan ha nått och återställ skadliga ändringar från CloudTrail. Använd Secrets Manager för automatisk rotation och övergå till rollbaserade tillfälliga autentiseringsuppgifter för att förhindra att detta händer igen.