Tredjepartscertifikatrisiko sidder i et ubehageligt hul. Det er jeres problem når noget bryder, men det er ikke jeres certifikat — I har ingen kontrol over det, ingen direkte mulighed for at forny det og typisk ingen synlighed i hvornår det udløber inden jeres integration holder op med at virke.
De fleste certifikathåndteringsprocesser fokuserer udelukkende på certifikater organisationen kontrollerer. Det er rationelt — dem er dem I faktisk kan forny. Men det efterlader et signifikant blindt felt: de operationelle afhængigheder af leverandørcertifikater du ikke kan kontrollere men absolut har brug for at fungere.
Hvordan leverandørcertifikatfejl forårsager jeres hændelser
Fejlstien er ligetil. Jeres applikation laver API-kald til et leverandørendepunkt. Leverandørens TLS-certifikat udløber. Jeres HTTP-klient modtager en certifikatfejl. Afhængigt af hvordan jeres applikation håndterer TLS-fejl:
- Hvis TLS-fejl behandles som hårde fejl (korrekt adfærd), holder jeres integration op med at virke øjeblikkeligt. Forespørgsler fejler, fejl propagerer og jeres tjeneste degraderer eller holder op med at fungere afhængigt af hvor kritisk leverandøren er.
- Hvis TLS-fejl undertrykkes eller ignoreres (forkert men ikke ualmindeligt), kan jeres applikation fortsætte med at operere men med ukrypterede eller uvaliderede forbindelser — en sikkerhedsfejl der måske ikke er umiddelbart synlig.
Hændelsen er jeres at håndtere. Jeres brugere ser fejl. Jeres operationsteam undersøger. De identificerer til sidst at grundårsagen er et tredjepartscertifikatudløb. Og derefter kontakter de leverandøren, som måske eller måske ikke reagerer hurtigt.
Løsningen afhænger fuldstændigt af hvor hurtigt leverandøren fornyer sit certifikat. I kan ikke forny det for dem. Alt I kan gøre er at vente — og styre servicedegraderingen i mellemtiden.
Kategorier af leverandørcertifikateksponering
Kritiske stiafhængigheder. Betalingsgateways, identitetsudbydere, kerne-API'er som jeres primære funktionalitet afhænger af. Et udløbet certifikat her er en P1-hændelse øjeblikkeligt. Blast-radius matcher jeres mest kritiske brugervendte funktionalitet.
Ikke-kritiske men kundesynlige afhængigheder. Tredjeparts analytics, indlejrede indholdsudbydere, valgfri funktions-API'er. Et udløbet certifikat forårsager degraderet funktionalitet eller manglende funktioner — mærkbar men ikke et komplet nedbrud.
Baggrundsbehandlingsafhængigheder. Datafeeds, notifikationstjenester, synkroniserings-API'er. Et udløbet certifikat kan forårsage stille fejl — data holder op med at synkronisere, notifikationer holder op med at sende — der ikke er umiddelbart synlige men akkumulerer over tid.
Interne leverandørafhængigheder. Tjenester leveret af andre teams inden for den samme organisation — interne API'er, delte tjenester, microservices drevet af partnerteams. Disse har ofte de samme karakteristika som eksterne leverandørafhængigheder men med mere mulighed for intern eskalering.
Hvorfor risikoen vokser
Integrationsdensitet vokser. Moderne applikationer integrerer med flere tredjepartstjenester end nogensinde. Hver integration er en potentiel certifikatafhængighed. Jo flere integrationer, jo mere eksponering.
47-dages certifikatlevetider øger fornyelsesfrekvensen. Efterhånden som certifikatlevetider forkortes, accelereres fornyelseskadencen for alle certifikater — inklusiv dine leverandørers. Flere fornyelser betyder flere muligheder for fornyelsesfejl. En leverandør der med succes styrede årlige fornyelser manuelt kan kæmpe med at forny otte gange om året.
Leverandørs certifikathåndteringsmodenhed varierer enormt. Store, modne teknologivirksomheder har typisk automatiseret certifikathåndtering og oplever sjældent udløbsproblemer. Mindre leverandører, niche-leverandører og virksomheder der primært ikke opererer i softwareindustrien kan have dårlige certifikathåndteringspraksisser — og fejlmoden er den samme uanset.
Hvad I kan gøre ved det
I kan ikke forny en leverandørs certifikat for dem. Men der er mere I kan gøre end ingenting:
Overvåg leverandørcertifikater og advar på forhånd. I kan overvåge certifikatsundheden for ethvert endepunkt I forbinder til, hvad enten I ejer det eller ej. Hvis jeres betalingsgateways certifikat udløber om 14 dage og jeres leverandør ikke har fornyet det, vil I vide det på forhånd — og give jer tid til at kontakte dem inden fejlen, ikke efter.
Inkluder certifikatovervågning i leverandørvurdering. Når I evaluerer nye leverandører eller fornyer kontrakter, spørg om deres certifikathåndteringspraksisser. Har de automatiseret fornyelse? Hvad er deres proces? Dette er et rimeligt teknisk due diligence-spørgsmål, særlig for kritiske afhængigheder.
Inkluder certifikatkrav i SLA'er. For kritiske leverandørafhængigheder, overvej at inkludere certifikathåndteringskrav i serviceniveauaftalen — gyldige certifikater, minimumledtid til fornyelse, notifikationskrav. Dette giver jer et kontraktuelt grundlag for at forvente forhåndsadvarsel om certifikatproblemer.
Byg graceful degradation til kritiske integrationer. For integrationer hvor certifikatfejl ville forårsage en P1-hændelse, design integrationen til at degradere gracefully — kø transaktioner frem for at fejle, give en manuel fallbackvej eller cache den sidst kendte gode tilstand.
Hav en leverandøreskaleringsreference klar. Når en leverandørs certifikat udløber, kører uret. At have en direkte teknisk eskaleringsreference — ikke kun en supportsagkø — kan komprimere svartiden markant. For kritiske afhængigheder bør denne kontakt etableres inden en hændelse opstår.
Sådan sporer I leverandørcertifikater med CertControl
CertControl kan overvåge ethvert offentligt tilgængeligt endepunkt, uanset om du ejer certifikatet. At tilføje et leverandør-API-endepunkt til den overvågede certifikatliste giver jer den samme udløbssporing og advarsling for det endepunkt som I har for jeres egne certifikater.
Det betyder at I kan vide at en kritisk leverandørs certifikat udløber om 30 dage — i tide til at kontakte dem, åbne en supportsag eller eskalere til jeres account manager — frem for at finde ud af det når jeres integration bryder kl. 02:00 en søndag.
For leverandørrelationer dækket af NIS2 forsyningskæde-krav eller ISO 27001 leverandørsikkerhedskontroller giver overvågningsdataene revisionsbevis for at leverandørcertifikatsundhed aktivt spores som del af jeres tredjepartsrisikostyringsprogram.