Veilig omgaan met credentials in supporttickets
Het stille probleem in je ticketsysteem
Supporttickets zijn gebouwd voor communicatie, niet voor het bewaren van geheimen. Toch bevatten de ticketsystemen van veel organisaties — Zendesk, Freshdesk, Jira Service Management, OTRS — wachtwoorden, API-sleutels en inloggegevens die ooit in een reactie zijn geplakt en daar sindsdien onaangeroerd staan.
Dit is wat beveiligingsonderzoekers een "schaduwdatabank" noemen: een opslagplaats van gevoelige data die niet bedoeld is als dataopslagplaats, niet beveiligd is als zodanig, en waarvan de meeste organisaties zich nauwelijks bewust zijn. Bij een audit of een datalek is het altijd een onaangename verrassing.
Hoe credentials in tickets belanden
Het begint onschuldig. Een klant heeft een probleem met zijn inloggegevens. Een supportmedewerker vraagt om toegang om het probleem te reproduceren. De klant typt het wachtwoord in het ticket. De medewerker lost het probleem op en sluit het ticket.
Maar het wachtwoord staat er nog. In de ticketgeschiedenis. Zichtbaar voor elke toekomstige medewerker die het ticket opent. Geïndexeerd in de zoekfunctie. Opgeslagen in database-back-ups. En als het ticket ooit wordt geëxporteerd of gearchiveerd, gaat het wachtwoord mee.
Varianten van dit patroon zijn legio:
- Credentials die worden aangemaakt voor een klant en via het ticket worden meegedeeld
- Tijdelijke wachtwoorden die worden gereset en via ticket worden verstuurd
- API-sleutels die worden doorgegeven bij het instellen van een integratie
Waarom dit een groter probleem is dan het lijkt
Toegangsrechten zijn niet op maat: iedereen met toegang tot het ticketsysteem kan historische tickets doorzoeken. Dat zijn niet alleen huidige medewerkers, maar ook tijdelijke krachten, stagiairs en leveranciers van de tickettool zelf.
Tickets worden zelden opgeschoond: de retentieperiode van ticketsystemen is typisch jaren. Een wachtwoord dat vijf jaar geleden in een ticket is geplakt, staat er waarschijnlijk nog steeds.
Zoekmachines van de tool indexeren alles: als je zoekt op een klantnaam, verschijnt het wachtwoord in de zoekresultaten.
Bij een breach gaat alles mee: als het ticketsysteem wordt gecompromitteerd, ligt niet alleen de communicatiegeschiedenis maar ook een verzameling credentials bloot.
De oplossing: credentials buiten het ticket houden
De regel is simpel: geen credential gaat ooit in een supportticket. Dat geldt voor wachtwoorden, API-sleutels, tokens, pincodes en alles wat als geheim bedoeld is.
Hoe dan wel?
-
Gebruik een eenmalige transferlink voor elke credential die je naar een klant stuurt. Stuur de link via het ticket, maar niet de credential zelf. Na het openen is de link verbruikt en bestaat de credential alleen nog bij de klant.
-
Vraag klanten nooit om hun wachtwoord. Als je toegang nodig hebt om een probleem te reproduceren, laat de klant een tijdelijk wachtwoord aanmaken of een impersonation-sessie starten. Nooit het echte wachtwoord.
-
Schoon bestaande tickets op. Doe een gerichte zoekactie in je ticketsysteem op patronen die op credentials lijken (lange willekeurige strings, "wachtwoord:", "password:", etc.) en verwijder of redigeer die gegevens.
-
Train je supportteam actief. Niet als eenmalige sessie, maar als onderdeel van onboarding en periodieke refreshers. De reflex om een wachtwoord in een ticket te typen, moet worden vervangen door de reflex om een transferlink te sturen.
PassTransfer is direct inzetbaar in dit proces: een supportmedewerker maakt in enkele seconden een eenmalige link aan, kopieert die in het ticket en de klant opent hem. Het wachtwoord verlaat nooit het ticketsysteem.
Conclusie
Je ticketsysteem is waarschijnlijk een schaduwdatabank vol credentials. De eerste stap is dat toegeven, de tweede is een protocol invoeren dat voorkomt dat er nieuwe credentials worden toegevoegd. Behandel elk ticket als een publiek document en zorg dat credentials daar nooit in thuishoren.
