Database-credentials veilig delen tussen development en support

Database-credentials zijn een van de gevoeligste typen inloggegevens in een technische organisatie. Ze geven directe toegang tot ruwe data — inclusief persoonsgegevens, transactiegeschiedenissen en bedrijfskritieke informatie. Toch worden ze in de praktijk opvallend nonchalant gedeeld: via Slack, e-mail of zelfs meegestuurd in een pull request.

Waarom database-credentials extra risico vormen

Een database-credential is gevaarlijker dan een applicatiewachtwoord om een aantal redenen:

• Directe datatoegang: Wie de database-credentials heeft, omzeilt applicatielogica, permissies en audit logs volledig.
• Brede scope: Een root- of admin-credential geeft schrijftoegang tot alles. Zelfs een read-only credential legt alle data bloot.
• Langere levensduur: Database-credentials worden minder vaak geroteerd dan applicatiewachtwoorden. Een lek kan lang onopgemerkt blijven.
• Veelgebruikt in scripts: Credentials die in scripts of .env-bestanden staan worden gemakkelijk per ongeluk meegecommit of gemaild.

De meest voorkomende risicosituaties

Development naar staging naar productie: Developers werken soms met productiecredentials om een bug te reproduceren. Dat is begrijpelijk maar gevaarlijk — zeker als die credentials daarna in een chatbericht blijven staan.

Support krijgt tijdelijke toegang: Een supportmedewerker heeft eenmalig toegang nodig om een klantprobleem te onderzoeken. De credential wordt per e-mail gestuurd en nooit ingetrokken.

Onboarding van nieuwe developers: Een nieuwe teamlid krijgt bij de start een set credentials toegestuurd via het eerste het beste kanaal dat beschikbaar is.

Externe partijen: Een extern auditeur of consultant krijgt tijdelijke leestoegang. De toegang wordt niet beperkt in tijd, de credentials worden niet geroteerd na het project.

Hoe het beter kan

Gebruik separate accounts per persoon

De gouden standaard is dat niemand directe database-credentials deelt. Iedereen heeft een eigen account met minimale benodigde rechten. Toegang wordt per persoon beheerd en ingetrokken bij vertrek of projecteinde.

Dat is de ideale situatie. In de praktijk zijn er altijd momenten waarop tijdelijke overdracht noodzakelijk is. Voor die gevallen geldt:

Gebruik een beveiligd kanaal voor tijdelijke overdracht

Wanneer u toch database-credentials moet delen, gebruik dan PassTransfer of een vergelijkbare tool. De credential wordt versleuteld aangemaakt, eenmalig opvraagbaar gemaakt en automatisch verwijderd na gebruik. De ontvanger krijgt een link, haalt de informatie op, en daarna bestaat de link niet meer.

Combineer dit met:

• Een korte vervaldatum: Stel in dat de link na 4 of 8 uur vervalt. Als de ontvanger hem niet heeft gebruikt, is er niets gecompromitteerd.
• Documentatie: Leg intern vast dat credentials zijn gedeeld, met wie en voor welk doel. Dat is relevant voor audits en incident response.
• Rotatie na gebruik: Zodra het doel is bereikt, wijzig het wachtwoord. Als de credentials voor een tijdelijk doel zijn gedeeld, mogen ze daarna niet meer werken.

Geen productiecredentials voor reproductie

Als een developer een productieprobleem wil reproduceren, gebruik dan geanonimiseerde of gesynthetiseerde data in een testomgeving. Productiecredentials zouden nooit op een ontwikkelaarslaptop of in een lokale omgeving terecht moeten komen.

Gebruik secrets management voor geautomatiseerde processen

Voor CI/CD-pipelines en geautomatiseerde scripts: gebruik een secrets manager (HashiCorp Vault, AWS Secrets Manager, of een vergelijkbare oplossing). Harde credentials in .env-bestanden of scripts zijn een recept voor een lek.

Praktisch advies

Maak een inventarisatie van wie nu toegang heeft tot uw database-omgevingen en via welke weg die toegang is verleend. U zult waarschijnlijk ontdekken dat er credentials in chatgeschiedenissen staan die allang geroteerd hadden moeten zijn. Stel een procedure in voor tijdelijke toegangsverlening via PassTransfer, documenteer het gebruik, en maak rotatie na gebruik de standaard. Dat verkleint uw aanvalsoppervlak zonder uw team te remmen in hun werk.