Hoeveel API-beveiliging heeft uw bedrijf echt nodig?

Een API die klantgegevens, orders of interne processen ontsluit, is geen onzichtbaar technisch detail. Het is een deur naar uw bedrijfskritische systemen, en die deur is dag en nacht bereikbaar. De vraag hoeveel beveiliging daarbij hoort, begint dus niet bij een product of een protocol. Die begint bij een eerlijke inschatting: wat gebeurt er als iemand ongewenst binnenkomt, veel meer gegevens ophaalt dan de bedoeling was, of uw koppeling simpelweg platlegt?

Voor de publieke API van een contentplatform vallen die antwoorden heel anders uit dan voor de koppeling tussen uw webshop, uw voorraadpakket en uw betaalprovider. Toch komen in vrijwel elk project dezelfde beveiligingslagen terug. Het verschil zit in hoe streng u ze inricht, en vooral in hoeveel aandacht ze na de oplevering nog krijgen.

Begin bij uw data en uw risico

Niet elke API verdient hetzelfde slot. Een endpoint dat openbare productcategorieën teruggeeft, brengt weinig risico mee. Een endpoint waarmee iemand facturen downloadt, klantadressen wijzigt of een betaling start, vraagt om aantoonbaar zwaardere controles.

Zet daarom per API op een rij welke gegevens en welke acties erachter zitten. Persoonsgegevens, financiële informatie, bedrijfsgevoelige data, inloggegevens, mutaties in systemen. Kijk in dezelfde beweging naar de gevolgen van uitval. Zet een storing in deze koppeling uw orderverwerking, planning of klantenservice stil? Dan is beschikbaarheid net zo goed een beveiligingsvraag als vertrouwelijkheid.

Die oefening kost een uur of twee en voorkomt twee klassieke fouten. U tuigt geen dure constructie op rond een integratie die dat niet nodig heeft. En u beschermt geen koppeling met grote impact met niet meer dan één vaste API-sleutel die ooit in een configuratiebestand is beland en sindsdien door niemand meer is aangeraakt.

Wie klopt er eigenlijk aan?

Een API moet altijd weten wie of welk systeem een verzoek doet. Zonder die vaststelling kan iedereen die het adres kent gaan proberen wat er lukt.

Voor een eenvoudige server-naar-serverkoppeling is een API-sleutel vaak prima, op drie voorwaarden: de sleutel is uniek per klant of integratie, hij ligt veilig opgeslagen, en u kunt hem per direct intrekken. Eén gedeelde sleutel voor alle koppelingen is een probleem dat wacht op een aanleiding. Lekt die sleutel, dan moet u alles tegelijk vervangen zonder te weten waar het lek zat.

Krijgen gebruikers toegang via een app of webomgeving, dan zijn tijdelijke access tokens meestal de betere route. OAuth 2.0 en OpenID Connect zijn daarvoor de gangbare patronen. Tokens verlopen vanzelf, en toegang kan worden ingetrokken zonder dat u ergens een wachtwoord deelt met een externe partij.

JSON Web Tokens werken prettig, maar vragen om een zorgvuldige inrichting. Controleer bij elk token de handtekening, de uitgever, de doelgroep en de vervaldatum. En geef een token geen levensduur van maanden omdat dat zo lekker weinig gedoe oplevert. Hoe korter een token geldig is, hoe kleiner de schade wanneer iemand hem onderschept.

Bij koppelingen met echt gevoelige systemen, denk aan financiële of zorggerelateerde processen, is wederzijdse TLS-authenticatie het overwegen waard. De client controleert dan niet alleen de server, maar de server controleert ook het certificaat van de client. Dat kost meer beheer. Het maakt zich voordoen als een ander wel een stuk lastiger.

Binnenkomen is iets anders dan iets mogen

Een geldig token zegt dat een partij bekend is. Het zegt niets over wat die partij mag. Precies daar ontstaan veel datalekken: een ingelogde gebruiker past een nummer in de URL aan en kijkt vervolgens naar de gegevens van een andere klant.

Controleer dus bij elk verzoek opnieuw of deze partij dit ook echt mag. Mag deze gebruiker deze order zien? Mag deze medewerker een adres wijzigen? Mag deze partner alleen voorraad lezen, of ook prijzen aanpassen? Die controle hoort aan de serverkant thuis, bij elke actie die ertoe doet. Een knop verbergen in de interface is geen autorisatie.

Ga daarbij uit van zo min mogelijk rechten. Een integratie die alleen zendingen aanmaakt, heeft niets te zoeken in de klantadministratie, de rapportages of het gebruikersbeheer. Beperk rechten per rol, per klant, per organisatie en per functie. Dat maakt een eventueel incident kleiner en het dagelijkse beheer een stuk overzichtelijker.

Controleer wat binnenkomt, beperk wat eruit gaat

API's krijgen data binnen van apps, websites, partners en interne systemen. Vertrouw die invoer nooit blind, ook niet wanneer een verzoek uit uw eigen applicatie lijkt te komen. Controleer datatype, lengte, verplichte velden, toegestane waarden en de samenhang daartussen. Een prijs hoort niet negatief te kunnen zijn, en een gebruiker hoort geen organisatie-ID te kunnen meesturen die niet bij zijn account past.

Werk met vaste schema's voor requests en responses. Daarmee legt u vast wat een endpoint accepteert en houdt u onverwachte velden en rare formaten buiten de deur, voordat ze diep in uw systeem verdwijnen. Dek daarbij de bekende aanvalspatronen af: SQL-injectie, command injection en het manipuleren van objectreferenties.

Even belangrijk, en veel vaker vergeten: stuur alleen terug wat echt nodig is. Een app die een klantnaam en een orderstatus toont, heeft geen interne notities, geen volledig adresbestand en geen technische rechtenstructuur nodig. Hoe minder data er in een response staat, hoe minder er misgaat bij een fout in de app, een gelekt token of een cache die verkeerd is ingesteld.

Versleuteling en limieten houden de deur heel

Al het API-verkeer hoort over HTTPS te lopen. Geen uitzonderingen, ook niet voor die ene interne koppeling waarvan iedereen aanneemt dat hij van buiten toch niet bereikbaar is. TLS versleutelt gegevens onderweg en voorkomt dat tokens, wachtwoorden of persoonsgegevens op een onbeveiligd netwerk zo van de lijn te plukken zijn. Houd protocollen en certificaten actueel en let op testomgevingen, want die blijken verrassend vaak nog via een oude, onbeveiligde route bereikbaar.

Daarnaast heeft een API bescherming nodig tegen overbelasting en misbruik. Rate limiting begrenst het aantal verzoeken per gebruiker, token, IP-adres of klant, en vangt daarmee brute-forcepogingen, doorgeslagen scripts en onverwachte pieken af. Wat een redelijke limiet is, hangt af van uw proces: een betaalendpoint mag strenger staan afgesteld dan een endpoint dat productinformatie uitleest.

Een web application firewall, DDoS-bescherming en netwerkregels voegen daar iets aan toe, zeker bij publieke API's. Beschouw ze wel als de buitenste schil. Ze compenseren geen gebrekkige autorisatie of ontbrekende validatie in de applicatie zelf.

Zonder logging weet u niets

Beveiliging wordt pas bruikbaar op het moment dat u afwijkingen kunt zien en uitzoeken. Log daarom de gebeurtenissen die ertoe doen: mislukte aanmeldingen, geweigerde rechten, opvallend hoge aantallen requests, wijzigingen in toegangsrechten en fouten op kritieke endpoints. Leg vast welk account of welke integratie iets deed, en zorg tegelijk dat tokens, wachtwoorden en gevoelige persoonsgegevens niet onnodig in die logs belanden.

Monitoring moet meer zijn dan een dashboard waar niemand naar kijkt. Stel meldingen in op gedrag dat niet klopt: honderden mislukte logins achter elkaar, een plotselinge piek in dataverkeer, of een integratie die om drie uur 's nachts opeens grote hoeveelheden gegevens ophaalt. Dan kunt u ingrijpen voordat er een incident van wordt.

Beschikbaarheid hoort in diezelfde monitoring thuis. Meet responstijden, foutpercentages en de afhankelijkheid van externe diensten. Een API kan technisch keurig beveiligd zijn en toch een risico vormen, bijvoorbeeld wanneer een trage koppeling uw checkout, planning of klantportaal laat vastlopen.

Na de oplevering begint het pas

Een goed ontworpen API veroudert net zo hard als de rest van uw software, zodra afhankelijkheden, frameworks, sleutels en rechten blijven liggen. Plan periodieke updates, kwetsbaarheidsscans en een herziening van de toegangsrechten. Verwijder accounts van oud-medewerkers, trek ongebruikte sleutels in en roteer geheimen volgens een vast ritme, in plaats van pas na een schrikmoment.

Houd ontwikkeling, test en productie strikt gescheiden. Testdata is niet zomaar een kopie van productiedata, hoe verleidelijk dat ook is. Beperk wie bij beheertools kan en bewaar secrets in een geheimenkluis, niet in broncode, tickets of een spreadsheet die ooit voor de handigheid is aangemaakt.

Voor organisaties zonder groot eigen ontwikkel- of beheerteam is eigenaarschap misschien wel het belangrijkste punt. Wie volgt updates op? Wie ziet een alarm binnenkomen, ook in de vakantieperiode? Wie kan een sleutel intrekken als een leverancier belt over een mogelijk lek? Bij LJPc doen we ontwikkeling en hosting daarom bewust samen, zodat dit soort vragen niet blijft hangen tussen twee partijen die naar elkaar wijzen.

Kies de lagen die bij uw proces passen

De basis voor vrijwel elke zakelijke API is redelijk universeel: HTTPS, betrouwbare authenticatie, autorisatie per actie en per object, validatie van invoer, zuinige responses, rate limiting en bruikbare logging. Gaat het om gevoelige data of om processen die niet stil mogen vallen, dan komen daar kortlevende tokens, strakkere netwerksegmentatie, certificaatauthenticatie en actieve monitoring bij.

De beste keuze is zelden de langste lijst met beveiligingsproducten. Het is een inrichting waarvan u kunt uitleggen waarom hij past bij uw data, uw gebruikers, uw koppelingen en uw continuïteitseisen. Begin bij de processen die niet mogen lekken en niet mogen stilvallen. Daar hoort uw API-beveiliging als eerste op orde te zijn.