Zo beveilig je API's met gevoelige of gereguleerde data

Begin met een dreigingsmodel voor de data, niet voor het framework

Schrijf voordat je tools kiest op wat de API ontsluit en wie hem zou kunnen misbruiken. Voor een bank gaat het om rekening- en transactiegegevens; voor een energie- of nutsbedrijf kan het gaan om meetgegevens, klantcontracten en operationele metingen uit het net.

Een bruikbaar dreigingsmodel is kort. Het noemt de gevoelige data, elke aanroeper die erbij kan, de acties die elke aanroeper mag uitvoeren en wat er gebeurt als een van hen gecompromitteerd raakt. Dat document stuurt vervolgens elke maatregel hieronder, en het vertelt reviewers wat ze moeten testen.

• Welke data persoonlijk, vertrouwelijk of gereguleerd is, en waar die is opgeslagen.
• Elke afnemer van de API: interne services, partners, mobiele apps en beheerders.
• Wat elke afnemer mag lezen, wijzigen of in gang zetten.
• De impact van een gelekt token, een kwaadwillende insider of een gecompromitteerd systeem van een partner.

Authenticeer elke aanroeper en autoriseer daarna elk object

Gebruik een standaardprotocol zoals OAuth 2.0 met OpenID Connect voor gebruikers, en kortlevende tokens of mutual TLS voor aanroepen tussen services. Vermijd langlevende, gedeelde API-sleutels, want niemand kan zien welk systeem ze gebruikte en je kunt ze niet intrekken zonder andere systemen te breken.

Authenticatie bewijst alleen wie er aanroept. Nummer één in de OWASP API Security Top 10 is broken object level authorization: een geldige gebruiker verandert een identifier in het request en leest het record van iemand anders. Controleer op de server voor elk object, elke functie en elk gevoelig veld wie de eigenaar of tenant is, en vertrouw nooit een identifier of rol die door de client wordt meegestuurd.

Geef elke client en service zo min mogelijk rechten

Minimale rechten beperken de schade als er toch iets misgaat. Geef elke afnemer eigen toegangsgegevens, beperk tokens tot specifieke handelingen en zet beheer-endpoints op een apart pad met strengere controles.

Pas dezelfde regel toe onder de API. Het serviceaccount dat meetgegevens leest, hoort ze niet te kunnen verwijderen, en een rapportagejob hoort te verbinden met een databaserol die alleen mag lezen. Loop rechten volgens een vast schema na, want toegang die voor een eenmalige taak is gegeven, blijft meestal voor altijd bestaan.

Verzamel minder, geef minder terug en bewaar het korter

Dataminimalisatie is zowel een beginsel van de AVG als een sterke beveiligingsmaatregel: data die je nooit opslaat, kan niet lekken. Vraag je per veld af of de service het echt nodig heeft, en laat weg of pseudonimiseer wat niet nodig is.

Pas dezelfde discipline toe op responses. Leg expliciete responseschema's vast in plaats van hele databaseobjecten te serialiseren, maskeer identifiers zoals rekeningnummers waar de volledige waarde niet nodig is, en stel bewaartermijnen in zodat oude records worden verwijderd. Documenteer de rechtsgrond voor elk verwerkingsdoel en sluit verwerkersovereenkomsten met elke leverancier die de data verwerkt. Dit is technische praktijk, geen juridisch advies, dus betrek je functionaris gegevensbescherming of je juridisch adviseur bij de juridische beoordeling.

Valideer alle invoer en begrens wat één aanroeper kan verbruiken

Behandel elk request als vijandig tot het is gevalideerd. Dwing per endpoint een schema af, weiger onbekende velden en gebruik geparametriseerde queries, zodat invoer nooit onderdeel wordt van een databasecommando.

Verschillende API-risico's van OWASP komen voort uit ontbrekende limieten, niet uit slechte code. Stel per client een rate limit in, begrens paginagroottes en payloadgroottes, en bescherm gevoelige bedrijfsprocessen zoals betalingen of contractwijzigingen tegen geautomatiseerd misbruik. Haalt de API namens aanroepers externe URL's op, beperk dan de bestemmingen om server-side request forgery te voorkomen.

Houd geheimen buiten code, images en logs

Databasewachtwoorden, ondertekeningssleutels en toegangsgegevens van partners horen in een aparte secrets manager, worden tijdens runtime ingeladen en volgens een vast schema vervangen. Scan repositories en container-images in de buildpipeline op geheimen, en beschouw elk geheim dat in versiebeheer belandt als gecompromitteerd.

Scheid geheimen per omgeving, zodat een gelekt testwachtwoord nooit toegang geeft tot productie. Beperk wie geheimen in productie kan lezen, en log elke toegang ertoe.

Log voor audits en ontwerp voor minder incidenten

Gereguleerde omgevingen moeten achteraf een eenvoudige vraag kunnen beantwoorden: wie heeft welke data ingezien, wanneer en via welke client. Leg dat vast voor elke gevoelige lees- en schrijfactie, bewaar logs op een plek waar beheerders van de applicatie ze niet kunnen wijzigen, en houd persoonsgegevens buiten logberichten.

Combineer logging met alerts op ongebruikelijke patronen, zoals één client die veel meer records leest dan normaal, en met een getest plan voor incidentrespons. Via Sopra Steria bouwden onze engineers beveiligde API's voor gevoelige gegevens van nutsbedrijven onder regelgevende randvoorwaarden, en leidden ze een tool voor operationele supervisie waarbij afgedwongen beveiligingsstandaarden samengingen met minder productie-incidenten. SDK Enterprises past dezelfde werkwijze vandaag toe op projecten voor klanten.

Veelgestelde vragen