Tredjepartscertifikatrisiko sidder i et ubehageligt hul. Det er dit problem når noget bryder, men det er ikke dit certifikat — du har ingen kontrol over det, ingen direkte mulighed for at forny det og typisk ingen synlighed i hvornår det udløber inden din integration holder op med at virke.
De fleste certifikathåndteringsprocesser fokuserer udelukkende på certifikater organisationen kontrollerer. Det er rationelt — dem er dem du 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 dine hændelser
Fejlstien er ligetil. Din applikation laver API-kald til et leverandørendepunkt. Leverandørens TLS-certifikat udløber. Din HTTP-klient modtager en certifikatfejl. Afhængigt af hvordan din applikation håndterer TLS-fejl:
- Hvis TLS-fejl behandles som hårde fejl (korrekt adfærd), holder din integration op med at virke øjeblikkeligt. Forespørgsler fejler, fejl propagerer og din 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 din applikation fortsætte med at operere men med ukrypterede eller uvaliderede forbindelser — en sikkerhedsfejl der måske ikke er umiddelbart synlig.
Hændelsen er din at håndtere. Dine brugere ser fejl. Dit 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. Du kan ikke forny det for dem. Alt du kan gøre er at vente — og styre servicedegraderingen i mellemtiden.
Kategorier af leverandørcertifikateksponering
Kritiske stiafhængigheder. Betalingsgateways, identitetsudbydere, kerne-API'er som din primære funktionalitet afhænger af. Et udløbet certifikat her er en P1-hændelse øjeblikkeligt. Blast-radius matcher din 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 dette bliver værre
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 du kan gøre ved det
Du kan ikke forny en leverandørs certifikat for dem. Men der er mere du kan gøre end ingenting:
Overvåg leverandørcertifikater og advar på forhånd. Du kan overvåge certifikatsundheden for ethvert endepunkt du forbinder til, hvad enten du ejer det eller ej. Hvis din betalingsgateways certifikat udløber om 14 dage og din leverandør ikke har fornyet det, vil du vide det på forhånd — og give dig tid til at kontakte dem inden fejlen, ikke efter.
Inkluder certifikatovervågning i leverandørvurdering. Når du evaluerer nye leverandører eller forny 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 dig 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.
Hvordan CertControl overvåger leverandørcertifikater
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 dig den samme udløbssporing og advarsling for det endepunkt som du har for dine egne certifikater.
Det betyder at du 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 din account manager — frem for at finde ud af det når din 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 dit tredjepartsrisikostyringsprogram.