Der findes ikke ét korrekt interval for alle credentials. Vælg efter levetid, følsomhed, eksponeringsrisiko og leverandørens muligheder. Mistanke om lækage kræver en hændelsesbeslutning frem for at afvente næste kalenderdato.
Begreb
Secret rotation
•
2 min
•
Grundlæggende
Secret rotation er kontrolleret udskiftning af en hemmelig adgangsoplysning, eksempelvis en API-nøgle eller en databaseadgangskode. API betyder Application Programming Interface. Den nye værdi skal både accepteres af tjenesten og anvendes af de klienter, der skal have adgang.
Et secret-lager beskytter opbevaringen, men en ny værdi dér ændrer ikke automatisk adgangsoplysningen hos udstederen. AWS Secrets Manager beskriver netop rotation som opdatering i både lager og den tilknyttede database eller tjeneste.
Hvorfor er begrebet vigtigt?
Langlivede adgangsoplysninger kan overleve medarbejderskift, gamle deployments og utilsigtet kopiering. Rotation begrænser, hvor længe den samme værdi kan give adgang, når den gamle faktisk bliver tilbagekaldt. Den erstatter ikke mindst mulige rettigheder, sikker opbevaring eller undersøgelse af misbrug.
Processen forbinder udsteder, secret-lager og forbrugende applikationer. Cachede værdier, baggrundsprocesser og glemte integrationer kan skabe driftsstop, hvis kun én del bliver opdateret. Rotation bør derfor være en afprøvet livscyklus med en ejer, ikke blot en kalenderpåmindelse.
Typisk misforståelse
En udløbsdato, en ny lagerversion og en tilbagekaldelse er forskellige handlinger. En gammel nøgle kan stadig virke hos udstederen, selv om en nyere værdi er gemt eller den gamle post er slettet fra et lager.
Rotation lover heller ikke automatisk drift uden afbrydelse. Et kontrolleret overlap kan bruges, hvor tjenesten understøtter to samtidige credentials. Med kun én aktiv adgangsoplysning skal klientskift, fejlvej og eventuelt servicevindue planlægges efter den konkrete løsning.
Eksempel
En fiktiv ordreintegration bruger en tjeneste, der understøtter to samtidige API-nøgler. Ved planlagt rotation opretter teamet en ny nøgle hos udstederen og gemmer den i det godkendte secret-lager. Alle kendte klienter skifter til den nye værdi, opdaterer eventuel cache og gennemfører en afgrænset funktionsprøve.
Først derefter tilbagekalder teamet den gamle nøgle og kontrollerer både fortsat funktion og forventet afvisning af den gamle adgang. Hvis en klient endnu bruger den gamle nøgle, er det normale rotationsforløb ikke færdigt. Ved mistanke om kompromittering skal beredskabet i stedet vurdere hurtig tilbagekaldelse og driftskonsekvens; det planlagte overlap er ikke en begrundelse for at bevare angriberens adgang.
Best practice
Kortlæg udsteder, ejer og alle forbrugere; registrér metadata uden at kopiere selve hemmeligheden til arbejdsnoter.
Automatisér en afprøvet proces med mindst mulige rettigheder og tydelige fejlsignaler.
Planlæg klientopdatering, cachefornyelse og tilbagekaldelse efter tjenestens faktiske muligheder.
Kontrollér både ny adgang og ophør af gammel adgang; gem resultat og tidspunkt uden secret-værdier.
Hav en fejl- og hændelsesplan, som undgår at genaktivere kompromitterede adgangsoplysninger.
Frequently asked questions
Nej. Opslaget handler om applikations- og tjenestecredentials. OWASP adskiller dem fra menneskelige brugeres passwords, hvor rutinemæssigt tvunget skift ikke er den generelle anbefaling uden mistanke om kompromittering.
Kun hvis den samlede integration også opdaterer udstederen og sikrer, at forbrugerne anvender den nye værdi. En oprettet lagerversion alene er utilstrækkelig.
Det må ikke antages. Allerede udstedte tokens og etablerede forbindelser kan have deres egen levetid og tilbagekaldelsesmodel. Undersøg den konkrete tjenestes adfærd ved hændelseshåndtering.