Et muligt hverdagsscenarie: en formular vises stadig, men den efterfølgende grænseflade modtager ikke længere forespørgsler. Eller en natlig import standser, fordi login ikke længere er gyldigt. Sådanne afhængigheder opdages ofte først, når forretningsprocessen udebliver.
En API-adgang kræver derfor mere end sikker opbevaring. Ansvar, gyldighed, udskiftningsprocedure og kontrol af den faktiske funktion hører sammen. Det gælder API-nøgler, OAuth-klientoplysninger, tjenestekonti og certifikater, hver med forskellige regler.
Udløb, rotation og tilbagekaldelse er forskellige hændelser
En fast udløbsdato kan teknisk afslutte videre brug. En rotationsregel fastlægger derimod, hvornår en adgang skal udskiftes. Den kan være pålagt af udbyderen eller aftalt i driften. Tilbagekaldelse afslutter en rettighed af en konkret grund og kan også ramme et endnu gyldigt legitimationsmiddel.
Ikke alle nøgler har automatisk samme levetid. Google dokumenterer eksempelvis som standard intet udløb for brugeroprettede tjenestekontonøgler; organisationspolitikker kan ændre dette. Microsoft Entra-klienthemmeligheder har derimod en defineret gyldighed. Registrer den faktiske udsteders regel frem for ét interval for alle tjenester.
I OAuth er adgangstoken, eventuelt opdateringstoken og applikationens loginoplysninger forskellige legitimationsmidler. Deres livscyklusser må ikke samles til én »API-nøgle« i inventaret. En tjenestekontos identitet er heller ikke det samme som en enkelt tilhørende nøgle.
Et inventar kræver ansvar, uden hemmeligheder i klartekst
Registrer mindst tjeneste, projekt, berørt proces, udsteder og type for hver vigtig integrationsadgang. Tilføj ansvarlig person eller rolle, stedfortræder og en tilgængelig eskaleringsvej. Modtageren af en advarsel skal kende den afhængige forretningsproces.
- Regel: Udstedelsesdato, faktisk udløb eller udtrykkeligt intet udløb, planlagt rotation og mulige udbyderændringer.
- Afhængigheder: Applikationer, job, installationer og adskilte miljøer, som bruger adgangen.
- Opbevaring: Henvisning til godkendt hemmelighedslager og administration; ingen rå værdier i inventaret.
- Udskiftning: Testprocedure, varsel, godkendelse, tilbagevej og dato for seneste vellykkede test.
En dato i hemmelighedslageret og den teknisk håndhævede gyldighed hos udstederen kontrolleres hver for sig. Vedligeholdte metadata fornyer ikke automatisk adgangen hos udbyderen.
Advar tidligt og kontroller den faktiske funktion
En udløbsadvarsel skal give tid til godkendelse, klargøring og test. Varslet afhænger af udbyder, risiko og organisering. En modtager uden stedfortræder eller advarsel via den berørte integration skaber en unødvendig afhængighed.
Overvåg også den forventede proces: ankommer forespørgslerne? Kører importen? Kan den planlagte modelforespørgsel behandles? Fejlrater, manglende kørsler og reproducerbare test viser afvigelser, også uden nært udløb. Kontrollen bør skabe så få ekstra data og omkostninger som muligt.
Et fejlet kald betyder ikke automatisk en udløbet nøgle. Rettigheder, kvoter, fakturering eller betaling, udbyderændringer og teknisk tilgængelighed undersøges separat. Den konkrete fejl og virkningen afgør næste handling.
| Hændelse | Betydning | Passende forberedelse |
|---|---|---|
| Teknisk udløb | Et legitimationsmiddel ophører efter udstederens regel. | Kontroller dato, udskift i tide og test funktionen. |
| Planlagt rotation | Eksisterende adgang udskiftes som planlagt. | Kend alle forbrugere, test overgang og tilbagevej. |
| Tilbagekaldelse eller inddragelse | En rettighed afsluttes målrettet. | Medtag grund, berørte adgange og igangværende processer. |
| Anden integrationsfejl | Eksempelvis rettigheder, kvote, betaling eller tilgængelighed. | Undersøg konkret årsag og forretningsproces hver for sig. |
Planlæg udskiftningen som et samlet forløb
Understøtter udbyderen flere samtidigt gyldige loginoplysninger, kan et nyt middel forberedes, mens det gamle virker. Microsoft beskriver eksempelvis princippet for ressourcer med to nøgler. Det er en udbyderspecifik mulighed, ikke et generelt løfte for alle API’er.
- Forbered: Kontroller rettigheder og alle forbrugere, klargør den nye adgang i det tiltænkte sikre lager.
- Test: Kontroller faktisk nødvendige handlinger med det nye middel i et egnet testmiljø eller kontrolleret omfang.
- Skift: Opdater berørte applikationer og job ordnet; medtag indlæsningsadfærd og eventuelle cacher.
- Observer: Kontroller funktion og fejludvikling. Se efter en overset forbruger, som stadig kræver gammel adgang.
- Afslut: Tilbagekald det gamle middel efter bekræftet skift, og opdater inventar og driftsdokumentation.
Med kun én gyldig adgang ad gangen kræves tættere koordinering. Et aftalt vedligeholdelsesvindue kan være nyttigt. Tilbagevejen fastlægges først; kompromitteret eller tilbagekaldt gammel adgang aktiveres ikke blot igen.
Reducer behovet for permanente nøgler, hvor muligt
Egnede platforme tilbyder administrerede identiteter eller fødereret login til applikationer. Det kan mindske håndtering af selvdistribuerede langlivede hemmeligheder. Egnethed, målrettigheder, levetid og gendannelse kontrolleres stadig. Også et certifikat kræver en livscyklus.
En hemmelighedsscanner supplerer beskyttelsen ved at opdage potentielt offentliggjorte legitimationsoplysninger. Den vedligeholder ikke driftsinventaret over afhængigheder og udskifter ikke adgangen hos alle forbrugere. Lækagesøgning og levetidsstyring har forskellige opgaver.
Begynd med forretningskritiske forbindelser
DAXS registrerer vigtige grænseflader og ansvar, kontrollerer advarselsveje og udvikler et gentageligt skift. En pilot kan starte med formularafsendelse, dataimport eller modelforbindelse. Det er mulige test, ikke påståede kundehændelser.
Vores ydelser til udvikling og integration og fagsiden om MCP og grænseflader forklarer integrationen. Vores artikel om projektspecifikke MCP-rettigheder supplerer kontrolleret adgang. Du kan anmode om en kortlægning af dine integrationsadgange.
Ofte stillede spørgsmål
Skal alle API-nøgler oprettes på ny regelmæssigt?
Der findes ingen fælles regel for alle udbydere. Gyldighed, udstederregler, risiko og driftsproces vurderes konkret. En nøgle uden fast udløbsdato kræver stadig ordnet administration.
Er en e-mail kort før udløb nok?
En advarsel hjælper kun med ansvar, stedfortræder og et testet forløb. Det bør også være synligt, om den afhængige funktion faktisk virker.
Kan rotation altid ske uden afbrydelse?
Det afhænger af udbyder, parallelt anvendelige legitimationsmidler og applikationers indlæsning. Hvor overlappende skift er umuligt, planlægges et aftalt forløb med passende vedligeholdelsesvindue.
Kilder: Google Cloud: tjenestekontonøgler og udløb (eksternt link) · Microsoft: applikationsadgang og rotation (eksternt link) · Microsoft: skift med to loginoplysninger (eksternt link) · Microsoft: rotation med én loginoplysning (eksternt link) · IETF: OAuth-tokens og applikationslogin (eksternt link) · OWASP: hemmeligheders livscyklus (eksternt link) · GitHub: omfang af hemmelighedsscanning (eksternt link)
Mulige scenarier og forenklede forløb; konkrete regler og skiftemuligheder afhænger af udbyder og applikation. Diagram og illustrationsfoto viser ikke en kundekonfiguration.
