API-sleutels en wachtwoorden zijn nodig om applicaties met andere systemen te verbinden, maar de plek waar ze worden opgeslagen bepaalt mede hoeveel risico een lek oplevert. Je leest hoe je geheimen scheidt van applicatiecode, omgevingen veilig inricht en opslag, toegang, logging en rotatie op elkaar afstemt.
Waar API-sleutels thuishoren in ontwikkel-, test- en productieomgevingen
Een API-sleutel hoort niet bij de applicatiecode, maar bij de omgeving waarin de applicatie draait. De code beschrijft welke configuratie nodig is; de omgeving levert de concrete waarde. Zo kan dezelfde applicatie in ontwikkeling, test en productie met verschillende accounts en toegangsrechten werken. Een sleutel voor een testdienst hoort dus niet in de configuratie van productie, en een productiesleutel hoort niet op een laptop van een ontwikkelaar.
Behandel wachtwoorden, tokens, private sleutels en databasecredentials op dezelfde manier. Het zijn geheimen zodra bezit ervan toegang geeft tot gegevens of functionaliteit. Leg per geheim vast welk systeem het gebruikt, welke rechten het heeft en wie het mag beheren. Dat maakt zichtbaar wanneer een sleutel te breed is, niet meer nodig is of op meerdere plaatsen wordt hergebruikt. Gebruik waar mogelijk afzonderlijke credentials per applicatie en per omgeving; een incident in test hoeft dan niet automatisch productie te raken.
De opslagkeuze hangt af van de uitvoeromgeving. Lokale ontwikkeling kan bijvoorbeeld een bestand gebruiken dat buiten versiebeheer blijft, terwijl productie geheimen uit een centrale secret store ophaalt. De belangrijkste ontwerpregel blijft gelijk: applicatiecode en geheimen hebben gescheiden levenscycli. Een wijziging in de code mag niet vereisen dat een sleutel in Git wordt aangepast, en een sleutelrotatie mag niet afhangen van een handmatige codewijziging.
Omgevingsvariabelen voor geheimen: praktisch, maar niet risicoloos
Omgevingsvariabelen zijn een veelgebruikte manier om configuratie aan een proces mee te geven. De applicatie leest bijvoorbeeld bij het starten een databasewachtwoord uit de omgeving, zonder dat dit in het bronbestand staat. Dat werkt met uiteenlopende programmeertalen en hostingplatforms en maakt het eenvoudig om dezelfde build naar verschillende omgevingen te brengen. De container of runtime krijgt per omgeving andere waarden aangeleverd.
Een omgevingsvariabele is echter geen versleutelde kluis. De waarde kan zichtbaar zijn voor processen met voldoende rechten, in diagnostische uitvoer terechtkomen of worden opgenomen in dumps en beheerinterfaces. Ook kan een platform variabelen tonen aan iedereen die configuratierechten heeft. Beperk daarom wie deploymentinstellingen mag bekijken, geef processen alleen de variabelen die ze nodig hebben en vermijd het printen van de volledige procesomgeving bij fouten. Controleer ook of monitoring- en crashrapportagetools omgevingswaarden verzamelen.
Variabelen zijn geschikt voor relatief eenvoudige deployments, mits de distributie en toegangsrechten goed zijn ingericht. Voor grotere systemen kunnen ze dienen als doorgeefmechanisme vanuit een secret manager, in plaats van als handmatig beheerde opslag. Let op het onderscheid tussen een waarde die tijdens het starten wordt ingelezen en een waarde die gedurende de hele proceslevensduur beschikbaar blijft. Als een geheim roteert, moet de applicatie soms opnieuw worden gestart of opnieuw verbinding maken voordat de nieuwe waarde actief is.
Secret stores gebruiken voor centrale opslag en toegangscontrole
Een secret store bewaart geheimen buiten de applicatie en beheert wie ze mag lezen of wijzigen. Dat kan een cloudvoorziening zijn, een beheerde vault of een dienst in de eigen infrastructuur. Applicaties halen de benodigde waarde op tijdens deployment of bij het starten. Een centrale voorziening kan toegangsbeleid, versleuteling, auditregistratie en versiebeheer op één plek organiseren, in plaats van losse wachtwoorden te verspreiden over CI-configuraties en serverinstellingen.
De integratie bepaalt mede het beveiligingsniveau. Laat een applicatie zich bij voorkeur identificeren met een rol of workload identity die door het platform wordt uitgegeven. Daarmee hoeft er geen permanent geheim in de applicatie te staan om een ander geheim op te halen. Beperk vervolgens de rol tot specifieke secretnamen en acties. Een service die alleen een leescredential nodig heeft, hoort geen rechten te krijgen om geheimen te wijzigen of andere applicatiesleutels op te vragen.
Een secret store introduceert ook afhankelijkheden. Een applicatie kan bij een storing of netwerkprobleem mogelijk niet starten wanneer ze op dat moment een geheim moet ophalen. Cachegedrag kan de beschikbaarheid verbeteren, maar maakt wijzigingen minder direct actief en vraagt om een bewuste vervaltijd. Maak daarnaast duidelijk wie de store beheert, hoe toegang wordt ingetrokken en welke gebeurtenissen worden gelogd. Centrale opslag vermindert verspreiding, maar voorkomt geen misbruik door een gecompromitteerde applicatie met geldige leesrechten.
Lokale ontwikkeling en testomgevingen zonder productiesleutels
Lokale ontwikkeling vraagt vaak om toegang tot externe diensten, maar dat betekent niet dat ontwikkelaars productiesleutels nodig hebben. Gebruik waar mogelijk mocks, lokale diensten of credentials voor een afgeschermde sandbox. Wanneer een echte API nodig is, maak dan een individuele sleutel met beperkte rechten en gegevens die geen productieschade veroorzaken. Individuele toegang maakt intrekken en onderzoeken eenvoudiger dan een gedeelde sleutel die in een teamchat of wiki circuleert.
Voor lokale configuratie zijn genegeerde bestanden, zoals een lokaal environment-bestand, vaak praktisch. Zet een voorbeeldbestand in de repository met uitsluitend namen en uitleg van vereiste variabelen; zet er nooit werkelijke waarden in. Controleer dat het echte bestand door .gitignore wordt uitgesloten en dat ontwikkeltools het niet automatisch uploaden. Een uitsluiting voorkomt alleen toekomstige commits: als een geheim eerder is vastgelegd, blijft het in de Git-geschiedenis staan totdat die geschiedenis afzonderlijk wordt opgeschoond.
Testomgevingen verdienen dezelfde scheiding. Een testdatabase met echte persoonsgegevens of een sleutel die productiegegevens kan wijzigen, maakt een fout in test potentieel een productie-incident. Gebruik aparte accounts, datasets en sleutels, en beperk netwerktoegang waar dat past. Automatische tests kunnen geheimen uit CI-variabelen ontvangen, maar laat ze niet terugschrijven naar testresultaten of foutmeldingen. Controleer ook snapshots en artefacten: daarin kunnen configuratiebestanden of logs zitten die langer worden bewaard dan de testomgeving zelf.
Toegang tot productiegeheimen beperken tot wat een proces nodig heeft
Een productiegeheim moet alleen beschikbaar zijn aan de applicatie of taak die het nodig heeft. Een algemene sleutel die door meerdere services wordt gedeeld, vergroot de impact van een compromittering en maakt het lastig te bepalen welke component verantwoordelijk is voor gebruik. Maak daarom waar mogelijk aparte credentials per service, met rechten die aansluiten op één functie. Een sleutel die alleen gegevens mag lezen, hoort geen beheeracties te kunnen uitvoeren.
Beperk ook menselijke toegang. Ontwikkelaars hoeven niet standaard de geheime waarde zelf te kunnen zien om een deployment te beheren. Scheid rechten voor codewijzigingen, secretbeheer en productie-uitrol, en registreer wie toegang verleent of intrekt. Voor incidentele toegang kan een tijdelijk proces met goedkeuring en auditregistratie passender zijn dan een blijvend gedeeld account. Vermijd het versturen van geheimen via chat, e-mail of tickets; die systemen hebben vaak een andere bewaartermijn en een bredere groep lezers dan de applicatieomgeving.
Controleer periodiek welke accounts en services nog bestaan en welke geheimen zij kunnen lezen. Oude deploymentrollen blijven anders ongemerkt toegang houden nadat een project of medewerker is veranderd. Let bij containers en serverless functies eveneens op scope: als alle containers op een host dezelfde omgevingsvariabelen of bestandsrechten delen, is de scheiding minder sterk dan de architectuur suggereert. Toegangsbeheer werkt alleen wanneer identiteit, rechten, netwerkpaden en feitelijke runtimeconfiguratie met elkaar overeenkomen.
Geheimen uit logs, foutmeldingen en monitoring houden
Een geheim kan correct uit de repository zijn gehouden en toch in een logbestand belanden. Denk aan een HTTP-client die bij een fout de volledige requestheaders registreert, een applicatie die configuratie toont bij het opstarten of een exception die een database-URL met wachtwoord bevat. Ook tokens in queryparameters zijn kwetsbaar: proxylogs, analytics en browsergeschiedenis kunnen de volledige URL opslaan. Controleer daarom niet alleen applicatielogs, maar ook reverse proxies, CI-uitvoer, traces en foutmonitoring.
Log gerichte gebeurtenissen in plaats van volledige request- of configuratieobjecten. Registreer bijvoorbeeld welke integratie faalde, welke statuscode werd ontvangen en een correlatie-ID, maar niet de Authorization-header of volledige payload. Maskering kan een extra vangnet zijn, maar is geen vervanging voor zorgvuldig ontworpen logging: nieuwe velden, afwijkende formaten of gecodeerde waarden kunnen de filter omzeilen. Stel logniveaus en retentie af op de omgeving en beperk wie ruwe logs kan doorzoeken.
Als een geheim toch in logs terechtkomt, behandel dat als blootstelling. Het verwijderen van één logregel neemt kopieën in exports, back-ups en externe monitoring niet vanzelf weg. Bepaal welke systemen de waarde hebben ontvangen, beperk verdere toegang en roteer de betreffende sleutel wanneer de situatie daarom vraagt. Voeg detectie toe op bekende patronen, maar vermijd dat detectieregels zelf geheimen in meldingen opnemen. Een alert met de volledige gelekte waarde kan het incident naar nog meer systemen verspreiden.
API-sleutels en wachtwoorden uit versiebeheer houden
Geheimen horen niet in broncode, configuratiebestanden of documentatie die in versiebeheer staat. Een private repository is geen veilige opslagplaats: toegang kan later worden uitgebreid, repositories kunnen worden gespiegeld en commits blijven doorgaans in de geschiedenis staan. Ook een sleutel die kort na een commit is verwijderd, kan nog terug te vinden zijn in eerdere commits, pull requests, forks of lokale clones. Verwijderen uit de nieuwste versie is dus niet hetzelfde als intrekken.
Gebruik placeholders in configuratievoorbeelden en beschrijf apart hoe ontwikkelaars hun lokale waarden aanleveren. Automatiseer detectie met secret scanning in repositories en CI, zodat verdachte patronen vroeg worden gemeld. Zulke scanners missen soms willekeurige tokens of aangepaste formaten en kunnen ook onschuldige voorbeelden markeren. Behandel de scanner daarom als aanvullende controle naast code review, toegangsbeheer en veilige configuratie. Zorg dat meldingen niet de volledige gevonden waarde tonen aan een brede groep ontvangers.
Wanneer een credential in Git is gepubliceerd, moet eerst worden vastgesteld of die nog geldig is en welke rechten eraan verbonden zijn. Trek de sleutel in of roteer hem; alleen de Git-geschiedenis herschrijven maakt een actieve sleutel niet ongeldig. Geschiedenis opschonen kan wel nodig zijn om verdere verspreiding te beperken, maar clones en caches vragen afzonderlijke aandacht. Maak het proces voor geheimenbeheer onderdeel van repositoryrichtlijnen, met duidelijke regels voor voorbeeldbestanden, CI-instellingen en het melden van een onbedoelde commit.
Geheimen roteren zonder onverwachte uitval
Rotatie betekent een bestaande sleutel vervangen en controleren dat alle gebruikers de nieuwe waarde kunnen gebruiken. Het is geen losse administratieve handeling: applicaties, geplande taken, workers en deploymentpijplijnen kunnen verschillende kopieën van hetzelfde geheim gebruiken. Breng die afhankelijkheden in kaart voordat een credential wordt gewijzigd. Anders kan een toepassing na rotatie blijven werken terwijl een minder zichtbare batchtaak bij de volgende uitvoering faalt.
Waar de externe dienst het ondersteunt, kan een overgang met twee geldige sleutels risico beperken. Plaats de nieuwe waarde, laat de applicatie die gebruiken en trek daarna de oude in. Dit vraagt om een gecontroleerde volgorde en een manier om vast te stellen welke sleutel daadwerkelijk wordt gebruikt. Bij diensten die slechts één sleutel tegelijk toestaan, kan rotatie een korte herconfiguratie of herstart vereisen. Houd rekening met connection pools en langlopende processen die een credential bij het starten inlezen.
De frequentie van rotatie hangt af van het type geheim, de rechten, het gebruik en eventuele beleidsregels. Regelmatige rotatie is nuttig, maar een geautomatiseerd proces dat onvolledige distributie veroorzaakt kan beschikbaarheidsproblemen opleveren. Automatiseer daarom waar mogelijk zowel het aanmaken als het bijwerken van gebruikers, en controleer na afloop foutpercentages en authenticatiefouten. Trek oude sleutels aantoonbaar in en verwijder achtergebleven kopieën uit configuraties en documentatie. Houd rotatie bovendien uitvoerbaar als reactie op een incident, niet alleen als periodieke taak.
Veelgestelde vragen
Kan ik een API-sleutel veilig in JavaScript of een mobiele app opslaan?
Nee, een geheime API-sleutel is niet veilig te bewaren in code die naar een browser of mobiele gebruiker wordt verspreid. Gebruikers kunnen de code en netwerkverzoeken inspecteren en de sleutel daaruit halen, ook als de app is gecompileerd of de waarde is gemaskeerd. Laat de app daarom via een eigen backend communiceren; die backend kan de geheime sleutel buiten het bereik van gebruikers bewaren en verzoeken controleren.
- Gebruik voor publieke client-apps alleen sleutels die door de API-aanbieder expliciet als openbaar bedoeld zijn.
- Beperk zulke sleutels waar mogelijk tot specifieke API’s, domeinen of applicaties.
- Gebruik gebruikersauthenticatie en serverzijdige controles om misbruik te beperken.
Hoe voorkom ik dat API-sleutels in een Docker-image terechtkomen?
Geef geheimen niet mee als Dockerfile-instructie of als buildargument, maar lever ze pas tijdens runtime aan de applicatie. Waarden die tijdens een build in een image-laag zijn opgeslagen, kunnen soms ook na het verwijderen ervan uit een latere laag worden teruggevonden. Gebruik voor buildstappen die tijdelijk toegang tot een geheim nodig hebben een secret-mountfunctie van je buildtool, en neem het geheim niet op in gekopieerde configuratiebestanden.
- Controleer image-lagen en buildlogs met een scanner voordat je images publiceert.
- Beperk wie images kan downloaden en gebruik alleen images uit vertrouwde pipelines.
- Als een sleutel in een image is beland, trek die dan in of roteer hem; een nieuwe image alleen maakt de oude sleutel niet ongeldig.
Hoe beheer ik secrets in Kubernetes?
Beheer Kubernetes-secrets met beperkte RBAC-rechten, versleuteling van gegevens in etcd en zo klein mogelijke toegangsscope voor pods. De standaard Kubernetes Secret-objecten coderen waarden in base64, maar dat is op zichzelf geen versleuteling. Controleer daarom of versleuteling at rest voor je cluster is ingeschakeld en wie secrets via de Kubernetes API kan uitlezen.
- Geef een serviceaccount alleen toegang tot de secrets die de betreffende workload nodig heeft.
- Vermijd brede rechten zoals het uitlezen van alle secrets in een namespace.
- Overweeg een externe secret manager en een gecontroleerde synchronisatie als je geheimen centraal beheert.
- Controleer na een wijziging hoe en wanneer pods de nieuwe waarde daadwerkelijk inladen.
Hoe voorkom ik dat CI/CD-pipelines API-sleutels lekken bij pull requests?
Stel CI/CD zo in dat niet-vertrouwde pull requests geen toegang krijgen tot productiegeheimen. Een pipeline die code van een externe bijdrage uitvoert, kan die code ook gebruiken om beschikbare variabelen of bestanden naar buiten te sturen. Vertrouw daarom niet alleen op het verbergen van waarden in de uitvoer: dat voorkomt niet dat een kwaadaardige stap ze gebruikt.
- Voer tests voor forks uit zonder productiecredentials.
- Gebruik aparte, beperkt bevoegde credentials voor testpipelines.
- Laat deployments naar productie alleen starten vanuit beschermde branches of na goedkeuring.
- Gebruik waar mogelijk kortdurende identiteiten in plaats van langdurige tokens.
Hoe vaak moet ik een API-sleutel roteren?
Er is geen vaste rotatiefrequentie die voor elke API-sleutel geschikt is; bepaal die op basis van de impact van misbruik, de geldigheidsduur en de mogelijkheden van de API-aanbieder. Trek een sleutel direct in of roteer hem bij een vermoeden van blootstelling, ongeautoriseerd gebruik of een wijziging in wie toegang nodig heeft. Een kortere geldigheidsduur kan de periode van mogelijk misbruik beperken, maar vraagt om betrouwbare automatisering.
- Leg per sleutel vast wie verantwoordelijk is en wanneer de geldigheid opnieuw wordt beoordeeld.
- Geef sleutels met brede rechten extra aandacht en maak ze waar mogelijk beperkter.
- Test het rotatieproces vooraf, zodat duidelijk is welke applicaties en taken van de sleutel afhankelijk zijn.
- Gebruik signalen van de API-aanbieder, zoals gebruikslogs, om ongebruikte sleutels op te sporen.
