Een API-sleutel per ongeluk in een screenshot

Begin met een korte inventarisatie voordat je iets wijzigt. Noteer, zonder de sleutel zelf over te typen:

1. Welke sleutel: de naam of het label in je beheeromgeving, niet de waarde.
2. Waar het screenshot staat: ticket, chat, document, presentatie, publiek kanaal of intern.
3. Wie toegang heeft of had tot die plek, en sinds wanneer.
4. Wat de sleutel mag: alleen lezen of ook schrijven, welke diensten, welke gegevens.
5. Welke systemen hem gebruiken: websites, apps, automatiseringen, plug-ins, partners.

De conclusie is bijna altijd dezelfde: zie de sleutel als gelekt zodra hij buiten het geheime kanaal is geweest, ook als je het bericht snel verwijderde. Een screenshot kan gekopieerd, gecachet of doorgestuurd zijn. Het verwijderen van het bericht is nuttig, maar het vervangt het intrekken van de sleutel niet.

Maak de ernst niet groter of kleiner dan nodig. Een sleutel met alleen leesrechten op een testomgeving vraagt een andere reactie dan een sleutel met schrijfrechten op klantgegevens. Dat verschil bepaalt de snelheid van je reactie, niet de vraag óf je intrekt.

Trek alleen de gelekte sleutel in, niet alle sleutels van de dienst. Een algemene reset kan kritieke koppelingen onnodig breken. De volgorde die het minste schade geeft:

1. Maak eerst een nieuwe sleutel aan bij dezelfde dienst, met dezelfde of liefst minimale rechten.
2. Zet de nieuwe sleutel bij de systemen die de oude gebruiken (zie volgende sectie).
3. Trek daarna de oude sleutel in, of schakel hem uit als de dienst dat toelaat.

Weet je dat de sleutel buiten het geheime kanaal is geweest, wacht dan niet tot alle consumers zijn omgezet of de inventaris volledig is. Zit het lek in een publiek of breed zichtbaar kanaal, of zijn de rechten ruim, dan trek je de oude sleutel meteen in en herstel je daarna de consumers, ook als dat korte onderbreking geeft. Ook bij een intern ticket weeg je dit af, want je weet niet wie het screenshot heeft gekopieerd. Leg die keuze en je motivatie vast.

Waar je dit in je omgeving doet, verschilt per dienst, en schermnamen en rechten kunnen wijzigen. Controleer dat daarom in de documentatie of het beheerpaneel van je eigen leverancier. Heb je zelf geen beheerrechten, dan escaleer je naar de persoon of leverancier die ze wel heeft, zonder de sleutelwaarde in het bericht te zetten. Beschrijf alleen het label en de plek van het lek.

Met 'consumer' bedoelen we elk systeem dat de sleutel gebruikt: je website, een app, een koppeling, een script, een externe partner. Maak eerst een lijst van alle consumers, want een sleutel die ergens vergeten blijft, laat na het intrekken stilletjes iets uitvallen.

Gebruik als werkvolgorde:

1. Zoek per consumer waar de sleutel is opgeslagen, bijvoorbeeld in omgevingsvariabelen, een geheimenbeheer, een instellingenscherm of een configuratiebestand.
2. Vervang de waarde door de nieuwe sleutel, rechtstreeks in dat beheerde opslagpunt.
3. Test per consumer één representatieve actie die de sleutel echt gebruikt, en noteer: gelukt of mislukt, met tijdstip.
4. Controleer de logboeken of foutmeldingen van de dienst op afgewezen verzoeken met de oude sleutel. Dat laat zien welke consumer je nog hebt gemist.

De beveiligingsrichtlijnen van MDN noemen goede operationele praktijken: toegang tot broncode beheren, geheimen veilig behandelen en afhankelijkheden controleren (MDN Web Security). Pas dat hier toe: plaats de sleutel nooit in broncode die je deelt. Als eigen redactioneel advies, dat niet uit de MDN-bron komt: gebruik per omgeving een eigen sleutel, zodat een lek in testen niet meteen productie raakt, en controleer of je minimale rechten kunt instellen bij de nieuwe sleutel.

De meest voorkomende tweede fout is het opnieuw plakken van het geheim tijdens het oplossen: de nieuwe sleutel in een chat, de oude sleutel in het incidentticket, of een screenshot van de nieuwe instelling. Houd deze regels aan:

• Zet nooit een sleutelwaarde in een ticket, chat of e-mail, ook niet de oude, ingetrokken sleutel. Noem alleen het label, de datum en het systeem.
• Overleg over de nieuwe sleutel uitsluitend via het kanaal dat je organisatie voor geheimen gebruikt, of laat de beheerder hem rechtstreeks in de instelling invoeren.
• Maak bij het documenteren van de stappen screenshots van schermen zonder zichtbare waarden, en controleer elk screenshot vóór het delen.
• Verwijder of vervang het originele screenshot waar mogelijk, en vraag ontvangers het lokaal te verwijderen. Beschouw dit als hygiëne, niet als vervanging van het intrekken.

Een extra voorzorg die je team zelf kan invoeren: een vaste regel om vóór het delen van een screenshot altijd de zichtbare velden na te lopen, en gevoelige waarden af te dekken met een effen vlak. Gebruik geen lichte vervaging of lage-contrastmarkering, want die is soms terug te halen.

Beveilig ook de accounts die toegang hebben tot sleutelbeheer. Volgens de help van Google verhoogt tweestapsverificatie de beveiliging van een account als een wachtwoord wordt gestolen, en passkeys zijn een beveiligd alternatief voor wachtwoorden (Google Account Help: tweestapsverificatie). Dit geldt voor Google-accounts en is geen uitleg over API-sleutelbeheer; controleer bij je eigen dienst welke gelijkwaardige opties beschikbaar zijn.

Gebruik onderstaande checklist als vaste volgorde, en vul hem in per incident.

Fictief voorbeeld, alleen invoer en verwachte controles. Een medewerker plaatst in een intern ticket een screenshot van een instellingenpagina waarop een sleutel met label 'webshop-koppeling' leesbaar is. Je noteert: label, ticketplek, intern kanaal, wie het ticket kan zien. Je maakt een nieuwe sleutel met label 'webshop-koppeling-2' met dezelfde rechten, of minder. De consumers zijn de webshop en een voorraadscript. Je laat de beheerder de nieuwe waarde rechtstreeks in beide instellingen zetten.

Verwachte controle: een testbestelling of testaanroep per consumer slaagt met de nieuwe sleutel. Trek de oude sleutel daarna zo snel mogelijk in en controleer dat de dienst een testaanroep met de oude sleutel nu weigert. Is er al onzekerheid over toegang door anderen, trek hem dan eerst in. Je documenteert in het ticket alleen labels en tijdstippen, nooit waarden, en je vervangt het originele screenshot door een versie zonder zichtbare sleutel.

Wil je ook weten welke publieke signalen je website uitzendt? Bekijk ze via Marketing Scan. Dat is een blik op zichtbare signalen; het intrekken van sleutels, het controleren van consumers en het nakijken van logboeken blijft werk in je eigen systemen.