Een mogelijk dagelijks scenario: een formulier wordt nog getoond, maar de achterliggende interface accepteert geen aanvragen meer. Of een nachtelijke import stopt omdat de aanmelding ongeldig is. Zulke afhankelijkheden worden vaak pas zichtbaar wanneer het bedrijfsproces uitblijft.
API-toegang vraagt daarom meer dan veilige opslag. Verantwoordelijkheid, geldigheid, vervanging en controle van de echte werking horen bij elkaar. Dit geldt voor API-sleutels, OAuth-clientgegevens, serviceaccounts en certificaten, elk met eigen regels.
Verlopen, roteren en intrekken zijn verschillende gebeurtenissen
Een vaste vervaldatum kan verder gebruik technisch beëindigen. Een rotatieregel bepaalt wanneer toegang moet worden vervangen. Die kan door de aanbieder worden afgedwongen of operationeel zijn afgesproken. Intrekking beëindigt een bevoegdheid om een concrete reden en kan ook een nog geldig authenticatiemiddel treffen.
Niet iedere sleutel heeft automatisch dezelfde looptijd. Google documenteert bijvoorbeeld dat zelf aangemaakte serviceaccountsleutels standaard niet verlopen; organisatiebeleid kan dat veranderen. Microsoft Entra-clientgeheimen hebben wel een vastgestelde geldigheid. Leg de regel van de echte uitgever vast in plaats van voor alle diensten hetzelfde interval aan te nemen.
Bij OAuth zijn een toegangstoken, eventueel vernieuwingstoken en de aanmeldgegevens van een applicatie verschillende middelen. Hun levenscycli mogen in de inventaris niet worden samengevoegd tot één ‘API-sleutel’. Ook de identiteit van een serviceaccount is iets anders dan één bijbehorende sleutel.
Een inventaris vraagt eigenaarschap, geen leesbare geheimen
Leg voor iedere belangrijke integratietoegang minimaal dienst, project, betrokken proces, uitgever en soort authenticatiemiddel vast. Voeg een verantwoordelijke persoon of rol, vervanger en bereikbare escalatieroute toe. Wie een waarschuwing ontvangt, moet weten welk bedrijfsproces ervan afhangt.
- Regel: Uitgiftedatum, werkelijk verloop of expliciet geen verloop, geplande rotatie en mogelijke aanbiederswijzigingen.
- Afhankelijkheden: Applicaties, taken, installaties en gescheiden omgevingen die de toegang gebruiken.
- Opslag: Verwijzing naar de goedgekeurde geheimenopslag en het beheer; geen ruwe waarden in de inventaris.
- Wissel: Testprocedure, aanlooptijd, toestemming, terugweg en datum van de laatste geslaagde test.
Een datum in de geheimenopslag en de technisch afgedwongen geldigheid bij de uitgever worden apart gecontroleerd. Bijgewerkte metadata vernieuwen de toegang bij de aanbieder niet vanzelf.
Vroeg waarschuwen en de werking echt controleren
Een verloopwaarschuwing moet genoeg tijd bieden voor toestemming, voorbereiding en testen. De aanlooptijd hangt af van aanbieder, risico en organisatie. Een ontvanger zonder vervanger of een waarschuwing via de getroffen integratie zelf creëert een onnodige afhankelijkheid.
Controleer ook of het verwachte proces werkt: komen aanvragen aan? Loopt de import? Kan de geplande modelaanvraag worden verwerkt? Foutpercentages, ontbrekende uitvoeringen en reproduceerbare tests maken afwijkingen zichtbaar, ook zonder naderende vervaldatum. De controle moet zo min mogelijk extra gegevens en kosten opleveren.
Een mislukte aanroep betekent niet automatisch een verlopen sleutel. Rechten, quota, facturatie of betaalstatus, aanbiederswijzigingen en technische bereikbaarheid worden apart onderzocht. De concrete fout en het effect bepalen de volgende actie.
| Gebeurtenis | Betekenis | Passende voorbereiding |
|---|---|---|
| Technisch verlopen | Een authenticatiemiddel eindigt volgens de uitgeversregel. | Datum controleren, op tijd vervangen en functie testen. |
| Geplande rotatie | Bestaande toegang wordt volgens planning vervangen. | Alle gebruikerssystemen kennen, overgang en terugweg testen. |
| Intrekking of beëindiging | Een bevoegdheid wordt doelbewust beëindigd. | Reden, betrokken toegang en lopende processen meenemen. |
| Andere integratiefout | Bijvoorbeeld rechten, quota, betaalstatus of bereikbaarheid. | Concrete oorzaak en bedrijfsproces afzonderlijk onderzoeken. |
De wissel als samenhangend proces plannen
Ondersteunt de aanbieder meerdere gelijktijdig geldige aanmeldgegevens, dan kan de nieuwe toegang worden voorbereid terwijl de oude nog werkt. Microsoft beschrijft dit bijvoorbeeld voor resources met twee sleutels. Dit is een aanbiederspecifieke mogelijkheid, geen algemene toezegging voor iedere API.
- Voorbereiden: Rechten en alle gebruikerssystemen controleren, nieuwe toegang in de bedoelde veilige opslag plaatsen.
- Testen: De echt benodigde acties met het nieuwe middel in een geschikte testomgeving of gecontroleerde omvang toetsen.
- Omschakelen: Betrokken applicaties en taken ordelijk bijwerken; laadgedrag en mogelijke caches meenemen.
- Observeren: Werking en foutontwikkeling controleren. Nagaan of een vergeten gebruikerssysteem de oude toegang nog nodig heeft.
- Afronden: Na bevestigde wissel het oude middel intrekken en inventaris en beheerdocumentatie bijwerken.
Bij slechts één gelijktijdig geldige toegang vraagt de wissel preciezere afstemming. Een afgesproken onderhoudsvenster kan zinvol zijn. De terugweg wordt vooraf bepaald; gecompromitteerde of ingetrokken oude toegang wordt niet zomaar opnieuw geactiveerd.
Waar mogelijk minder permanente sleutels nodig hebben
Geschikte platforms bieden beheerde identiteiten of federatieve aanmelding voor applicaties. Die kunnen het beheer van zelf verspreide langdurige geheimen verminderen. Geschiktheid, doelrechten, looptijd en herstel worden wel getoetst. Ook een certificaat heeft een levenscyclus nodig.
Een geheimenscanner vult bescherming aan door mogelijk gepubliceerde aanmeldgegevens te detecteren. Hij beheert niet de operationele afhankelijkhedeninventaris en vervangt de toegang niet bij alle gebruikerssystemen. Lekdetectie en looptijdbeheer hebben verschillende doelen.
Beginnen met bedrijfskritieke verbindingen
DAXS inventariseert belangrijke interfaces en verantwoordelijkheden, controleert waarschuwingen en ontwikkelt een herhaalbare wissel. Een proef kan starten met formulierverzending, gegevensimport of modelkoppeling. Dit zijn mogelijke tests, geen beweerde klantstoringen.
De diensten voor ontwikkeling en integratie en de technische pagina over MCP en interfaces verklaren de inpassing. Het artikel over projectgebonden MCP-rechten vult gecontroleerde toegang aan. U kunt een inventarisatie van uw integratietoegang aanvragen.
Veelgestelde vragen
Moet iedere API-sleutel regelmatig opnieuw worden gemaakt?
Er is geen uniforme regel voor alle aanbieders. Geldigheid, uitgeversregels, risico en de operationele wissel worden concreet beoordeeld. Een sleutel zonder vaste vervaldatum vereist nog steeds geregeld beheer.
Volstaat een e-mail vlak voor het verlopen?
Een waarschuwing helpt alleen met eigenaarschap, vervanging en een geteste procedure. Ook moet zichtbaar zijn of de afhankelijke functie werkelijk werkt.
Kan rotatie altijd zonder onderbreking?
Dat hangt af van de aanbieder, parallel bruikbare middelen en het laadgedrag van applicaties. Waar overlappend wisselen niet kan, wordt een afgestemde procedure met passend onderhoudsvenster gepland.
Bronnen: Google Cloud: serviceaccountsleutels en verloop (externe link) · Microsoft: applicatietoegang en rotatie (externe link) · Microsoft: wisselen met twee aanmeldgegevens (externe link) · Microsoft: roteren met één aanmeldgegeven (externe link) · IETF: OAuth-tokens en applicatieaanmelding (externe link) · OWASP: levenscyclus van geheimen (externe link) · GitHub: bereik van geheimenscanning (externe link)
Mogelijke scenario’s en vereenvoudigde processen; concrete regels en wisselmogelijkheden hangen af van aanbieder en applicatie. Schema en illustratief beeld tonen geen klantconfiguratie.
