Hændelsesresumé
Dato: Tirsdag, [Dato]
Varighed: 4 timer 17 minutter (03:14 – 07:31)
Påvirkning: Autentifikationstjeneste utilgængelig. Alle brugere ude af stand til at logge ind. Cirka 2.400 mislykkede loginforsøg under nedbruddsvinduet. Tre enterprise-kunder kontaktede support inden intern detektion.
Grundårsag: TLS-certifikat på autentifikations-API-endepunktet udløb kl. 03:14. Certifikatet var ikke i den overvågede inventar. Fornyelsesadvarsel blev sendt til en distributionsliste der var deaktiveret seks måneder tidligere under en teamomstrukturering.
Alvorlighed: P1
Tidslinje
18 måneder tidligere: Autentifikationstjeneste migreret fra monolit til separat microservice. Nyt underdomæne oprettet (auth-api.ditdomæne.dk). Certifikat skaffet manuelt via CA-portalen. Tilføjet til et overvågningsregneark vedligeholdt af ingeniøren der ledede migrationen.
12 måneder tidligere: Ingeniøren der ledede migrationen skifter til et andet team. Regnearket overdrages ikke. Certifikatovervågningsansvar er effektivt uassigneret.
45 dage tidligere: CA sender fornyelsespåmindelse til den e-mailadresse der blev angivet ved certifikatudstedelse — en teamdistributionsliste der blev udfaset under en reorganisering. E-mailen bouncer. Ingen modtager den.
14 dage tidligere: CA sender anden påmindelse. Samme resultat.
03:14: Certifikat udløber. Autentifikationstjeneste begynder at returnere TLS-fejl til alle klienter.
03:14 – 05:40: Ingen interne advarsler affyres. Syntetisk overvågning dækker hovedwebsitet og tre primære API-endepunkter. Auth-api-underdomænet er ikke i den syntetiske overvågningskonfiguration.
05:40: Første supportsag oprettet af en enterprise-kunde der rapporterer "login virker ikke." Sag tildelt supportkø med standardprioritet.
05:58: Anden enterprise-kunde mailer sin account manager direkte. Account manager eskalerer internt.
06:03: On-call ingeniør paged. Begynder undersøgelse.
06:11: Grundårsag identificeret — TLS-certifikatudløb bekræftet ved brug af openssl s_client. Certifikat viser not-after tidsstempel i fortiden.
06:11 – 07:20: Nødfornyelsesproces for certifikat. CA-portallogin-legitimationsoplysninger ikke i password manager — gemt lokalt på laptopen til ingeniøren der oprindeligt opsatte tjenesten. Nødkontakt for at hente legitimationsoplysninger. Manuel domænevalidering. Certifikatudstedelse. Certifikatinstallation og tjenesterestart.
07:31: Autentifikationstjeneste bekræftet operationel. Alt-klart kommunikeret til berørte kunder.
Total varighed: 4 timer 17 minutter.
Bidragende faktorer
1. Certifikat ikke i managed inventar. Auth-api-certifikatet var i et personligt regneark, ikke teamets certifikathåndteringssystem. Da den ansvarlige ingeniør skiftede teams, blev certifikatet effektivt usporet.
2. Fornyelsesadvarsler routet til en forældet e-mailadresse. Certifikatet blev udstedt med en team-e-mailadresse der blev udfaset under en reorganisering. CA-fornyelsespåmindelser havde ingen steder at gå.
3. Overvågningsgab på det berørte underdomæne. Den syntetiske overvågningskonfiguration blev oprettet inden autentifikationsmicroservice'en blev splittet ud. Det nye underdomæne blev aldrig tilføjet til overvågningsomfanget.
4. Legitimationsoplysningsstyringsfejl. CA-portalens legitimationsoplysninger var gemt lokalt frem for i det delte legitimationsoplysningslager. Dette forlængede hændelsen med over en time mens legitimationsoplysninger blev hentet.
5. Ingen certifikatinventarejerskabsproces. Der var ingen proces der krævede at certifikatejerskab overdrages når ingeniører skifter teams eller forlader organisationen. Ejerskab blev implicit og derefter fraværende.
Hvad der ikke var en bidragende faktor
Det er værd at bemærke hvad der ikke forårsagede denne hændelse:
- Certifikatet selv var gyldigt og korrekt konfigureret da det først blev udstedt.
- Fornyelsesprocessen, når den erst var igangsat, virkede korrekt.
- Teamets reaktion når hændelsen var detekteret var kompetent og rimeligt hurtig.
Fejlen lå fuldstændigt i processerne omkring certifikatlivscyklusstyring — ikke i certifikatteknologien selv. Dette er mønsteret i næsten alle certifikatudløbshændelser: certifikatet gør hvad det skal, og fejlen er i de menneskelige og procesmæssige systemer der er ment til at styre det.
Handlingspunkter
Øjeblikkelig (inden for 48 timer):
- Auditér alle certifikater på tværs af alle underdomæner ved brug af CT-log-enumeration. Producér en komplet liste over hvert certifikat knyttet til organisationens domæner.
- Tilføj alle opdagede certifikater til det centrale certifikathåndteringssystem med tildelte ejere.
- Tilføj auth-api og alle andre manglende underdomæner til den syntetiske overvågningskonfiguration.
- Flyt CA-portallegitimationsoplysninger til det delte legitimationsoplysningslager.
Kortfristet (inden for 2 uger):
- Implementer certifikatovervågning med advarsler ved 90, 60, 30 og 14 dage inden udløb. Rout advarsler til funktionelle teamadresser, ikke individuelle eller midlertidige distributionslister.
- Definer og dokumenter processen for certifikatejerskabsoverdragelse når ingeniører skifter teams.
- Gennemgå alle certifikater for fornyelsespåmindelseskontaktadresser. Opdater dem der peger på individuelle adresser eller forældte distributionslister.
Mellemfristet (inden for 6 uger):
- Evaluer ACME-automatisering for alle certifikater hvor det er teknisk muligt. Mål: eliminer manuel fornyelse for alle produktionscertifikater.
- Implementer kontinuerlig CT-overvågning så nye certifikater udstedt til organisationens domæner detekteres automatisk og tilføjes til den managed inventar.
- Kør en tabletop-øvelse der simulerer certifikatudløb på en anden kritisk tjeneste for at validere at responsprocessen virker inden den er nødvendig i en reel hændelse.
Brug af denne skabelon til dine egne hændelser
En god postmortem er skyldfri — den fokuserer på systemiske fejl, ikke individuelle fejltagelser. Ingeniøren der ikke overdrog regnearket fulgte ingen bestemt proces, fordi ingen proces eksisterede. Svaret er ikke at bebrejde individet men at bygge den proces der gør individets afgang irrelevant for certifikatkontinuitet.
Spørgsmålene der er værd at stille i enhver certifikatudløbspostmortem:
- Hvordan endte dette certifikat uden for den managed inventar?
- Hvem var ansvarlig for at overvåge dette certifikat — og vidste de det?
- Hvilke advarsler var konfigureret? Hvortil gik de? Modtog nogen dem?
- Hvem lang tid gik der mellem udløb og detektion? Hvorfor var detektion ikke hurtigere?
- Hvad forlængede løsningstiden? Var legitimationsoplysninger, adgang eller procedurer utilgængelige?
- Hvilken procesændring gør denne specifikke fejlvej umulig i fremtiden?
CertControl adresserer de systemiske huller der gør certifikatudløbshændelser tilbagevendende frem for engangsforekomster: kontinuerlig inventar fra CT-logs, overvågning med funktionel advarselsrouting, ACME-automatisering hvor muligt og rapportering der gør certifikatlandskabet synligt for de ansvarlige.