Authenticatiemiddelen roteren in PHP-integraties betekent dat een sleutel, token, wachtwoord of certificaat waarmee toegang wordt verkregen tot een externe service, wordt vervangen en het oude middel gecontroleerd wordt ingetrokken. Het is niet simpelweg een waarde in een configuratiebestand wijzigen: de applicatie, de processen die al draaien en de externe aanbieder moeten op elkaar worden afgestemd, zodat de overgang de werkzaamheden niet onderbreekt en het gebruik van een oud authenticatiemiddel niet onnodig lang voortduurt.
Het doel is te verifiëren dat het nieuwe authenticatiemiddel bij alle afnemers werkt voordat het oude wordt ingetrokken, met een beperkte compatibiliteitsperiode en een voorbereide reactie op storingen. De procedure moet aansluiten op de mogelijkheden van de service: sommige aanbieders staan toe dat twee sleutels tegelijk actief zijn; andere vereisen een onmiddellijke vervanging, met minder ruimte om te testen.
Waarom voor het roteren de applicatie en de aanbieder moeten worden afgestemd
Authenticatiemiddelen staan vaak op meerdere plekken tegelijk: in de geheimenmanager, in omgevingsvariabelen, in de configuratie voor de uitrol en in PHP-processen die al zijn gestart. De waarde op de bronlocatie wijzigen, garandeert niet dat elk proces deze opnieuw heeft geladen. Een langdurig actief wachtrijproces kan bijvoorbeeld een oude configuratie in het geheugen behouden, terwijl een webinstantie de nieuwe al gebruikt.
Ook het gedrag van het externe systeem is van belang. Als het de oude en de nieuwe authenticatiemiddelen tegelijkertijd accepteert, kun je het nieuwe middel uitrollen, het gebruik ervan controleren en daarna het oude intrekken. Als het er maar één accepteert, kan de handeling een onderhoudsvenster, een gecoördineerde volgorde of een door de aanbieder aangeboden wijzigingsfunctie vereisen. Ga er niet van uit dat overlap mogelijk is: controleer dit in de documentatie en, indien mogelijk, in een gecontroleerde omgeving.
Het roteren van authenticatiemiddelen verschilt van algemeen configuratiebeheer. Configuratie bepaalt hoe een waarde wordt aangeleverd en gebruikt; bij rotatie worden het geheim en de levenscyclus ervan gewijzigd, inclusief validatie, intrekking en de reactie op blootstelling. Configuratie centraliseren helpt, maar bewijst op zichzelf niet dat het oude authenticatiemiddel niet meer wordt gebruikt.
Afnemers, rechten en afhankelijkheden inventariseren
Breng voordat je een authenticatiemiddel aanmaakt of wijzigt in kaart welke service dit uitgeeft, welke rechten het verleent en welke afnemers ervan gebruikmaken. Neem webapplicaties, geplande opdrachten, achtergrondprocessen, handmatige taken, testomgevingen en operationele hulpmiddelen mee. Controleer ook repositories en CI/CD-configuraties op verouderde verwijzingen, zonder de waarde van het geheim in rapporten of tickets te kopiëren.
- Afnemers: breng repositories, services, processen, verantwoordelijken en uitvoeringsfrequentie in kaart.
- Reikwijdte: documenteer rechten, toegankelijke resources, netwerkbeperkingen en eventuele vervaldatums.
- Aanlevering: controleer via welke manager of welk beveiligd mechanisme elk proces het authenticatiemiddel ophaalt en wanneer het dit opnieuw inleest.
- Afhankelijkheden: ga na of andere systemen of teams afhankelijk zijn van dezelfde sleutel en of de aanbieder meerdere actieve sleutels toestaat.
- Waarneembaarheid: lokaliseer meetgegevens en logboeken met succes- of foutmeldingen waarmee je de wijziging kunt controleren zonder gevoelige waarden te tonen.
Kun je niet vaststellen wie een sleutel gebruikt, trek deze dan niet in alleen omdat het verkeer laag lijkt. Een maandelijks proces of een hersteltaak kan onopgemerkt blijven. Vul de inventaris aan met de gebruikslogboeken die de aanbieder beschikbaar stelt en met de effectieve configuratie van de omgevingen.
De overgang voorbereiden en de overlap beperken
Genereer het nieuwe authenticatiemiddel via het mechanisme van de aanbieder en ken het alleen de benodigde rechten toe. Als de service twee actieve sleutels toestaat, stel dan een overlapperiode met een vastgestelde duur in. Die moet lang genoeg zijn om het nieuwe authenticatiemiddel uit te rollen en de afnemers te testen en te observeren, maar niet langer dan nodig. Leg vast wie de periode beheert en onder welke voorwaarde het oude authenticatiemiddel wordt ingetrokken. Zo voorkom je dat de tijdelijke periode onbepaald wordt.
Lever het geheim aan via het goedgekeurde systeem voor de betreffende omgeving, niet via broncode, berichten, tickets of opdrachtregelargumenten die kunnen worden vastgelegd. Voorkom dat het in debugtraces wordt afgedrukt. Maak in procedures duidelijk onderscheid tussen verwijzingen naar het oude en het nieuwe authenticatiemiddel om fouten te beperken, maar vermeld de waarden ervan niet in operationele documentatie.
Bepaal de volgorde van wijzigingen op basis van de manier waarop de configuratie wordt geladen. Mogelijk moet je het geheim bijwerken, de applicatie uitrollen en achtergrondprocessen of geplande processen herstarten, zodat deze geen waarden meer gebruiken die in het geheugen zijn vastgehouden. Controleer hoe wijzigingen naar elke instantie worden doorgevoerd; een wijziging in de runtimeomgeving werkt bestaande processen niet altijd bij.
Uitrollen en verifiëren zonder geheimen bloot te stellen
Pas de wijziging eerst toe in een representatieve omgeving, als de aanbieder dit toestaat. Rol de wijziging daarna gecoördineerd uit in productie en controleer zowel nieuwe verzoeken als processen die minder vaak worden uitgevoerd. Een eenvoudige connectiviteitstest is nuttig, maar vervangt niet de validatie van de daadwerkelijke bewerkingen die afhankelijk zijn van de integratie.
- Controleer of de applicatie het nieuwe authenticatiemiddel ontvangt en of instanties en achtergrondprocessen hun configuratie opnieuw hebben geladen.
- Controleer reacties van de aanbieder, foutcodes en functionele bewerkingen die relevant zijn voor de bedrijfsvoering.
- Houd succespercentages, authenticatiefouten, nieuwe pogingen en openstaande wachtrijen in de gaten gedurende een periode waarin alle bekende afnemers aan bod komen.
- Gebruik aanvraag- of uitvoerings-ID's om problemen te diagnosticeren; redigeer of sluit headers en bodies uit die geheimen kunnen bevatten.
Logboeken moeten context bieden zonder tokens, wachtwoorden of autorisatieheaders op te slaan. Controleer ook uitzonderingsmeldingen: een bibliotheek of HTTP-client kan gevoelige gegevens in een trace opnemen. Verwerkt de integratie persoonsgegevens of bedrijfsinformatie, pas dan ook de relevante beleidsregels voor toegang, bewaartermijnen en gegevensbescherming toe.
Het oude authenticatiemiddel intrekken en op storingen reageren
Trek de oude sleutel in zodra alle bekende afnemers met de nieuwe werken en de monitoring hun relevante cycli omvat. Bevestig de intrekking bij de aanbieder en houd de daaropvolgende fouten in de gaten. Blijven er pogingen met het oude authenticatiemiddel verschijnen, zoek dan naar vergeten processen, niet bijgewerkte instanties of externe taken voordat je de wijziging als afgerond beschouwt.
Maak bij storingen onderscheid tussen een authenticatieprobleem en een probleem met rechten, connectiviteit of het aanvraagformaat. Als het oude authenticatiemiddel nog actief is en er geen aanwijzingen voor blootstelling zijn, kan het tijdelijk als rollback dienen terwijl de uitrol wordt gecorrigeerd, met autorisatie en een operationeel vastgestelde vervaldatum. Als de rotatie is ingegeven door een vermoeden van compromittering, kan het opnieuw activeren van de oude sleutel het risico opnieuw introduceren: geef prioriteit aan indamming en volg de bijbehorende beveiligingsprocedure.
Leg beslissingen, tijdstippen, verantwoordelijken, resultaten en openstaande acties vast, maar nooit het geheim zelf. Met deze registratie kun je reconstrueren wat er is gewijzigd en het proces helpen herhalen; ze mag geen parallelle inventaris van authenticatiemiddelen worden.
Checklist voor herhaalbare rotatie
- Zijn alle afnemers geïdentificeerd, inclusief langdurig actieve processen en weinig frequente taken?
- Zijn de rechten, vervaldatum en regels van de aanbieder voor gelijktijdige authenticatiemiddelen bekend?
- Wordt het nieuwe authenticatiemiddel via een beveiligd kanaal en met minimale rechten aangeleverd?
- Beschrijft het plan de volgorde van de uitrol, het opnieuw laden van de configuratie, de observatieperiode en de verantwoordelijke?
- Valideren de controles daadwerkelijke bewerkingen en voorkomen ze dat gevoelige waarden worden vastgelegd?
- Is er een afzonderlijke aanpak voor gewone storingen en mogelijke compromittering?
- Wordt het oude authenticatiemiddel ingetrokken en wordt daarna gecontroleerd of er geen achterblijvende afnemers zijn?
Een betrouwbare rotatie is pas afgerond wanneer het nieuwe authenticatiemiddel is gevalideerd, het oude is ingetrokken en er geen processen meer zijn die nog moeten migreren. Kan een van die voorwaarden niet worden gecontroleerd, dan is de wijziging nog niet afgerond en moet deze worden behandeld als een operationele taak met een expliciet aangewezen verantwoordelijke en opvolging.
