Het belang van API-Security

“API’s zijn enorm aantrekkelijk voor hackers,” zei Paul Fremantle (medeoprichter van WSO2) een paar maanden geleden. En hij heeft gelijk. API’s zijn de deur naar veel producten en diensten van jouw organisatie. Ze zijn van nature open en aantrekkelijk. En dat omdat de gebruikers van jouw API’s meestal niet alleen binnen jouw organisatie zitten, maar steeds vaker ook daarbuiten.

Ik wil het nog sterker uitdrukken:

“Een onbeveiligde API is letterlijk een ‘all-you-can-eat restaurant’ voor hackers.”

Niemand zou met zijn gezond verstand een onbeveiligde API aan de wereld aandien, toch? Dat zou kunnen kloppen. Ik denk dat de meeste mensen zich ervan bewust zijn dat er beveiliging nodig is als je diensten aanbiedt. Het boeit absoluut niet aan wie je ze aanbiedt, binnen de organisatie of naar buiten toe aan derden. Laten we echter niet vergeten dat het definiëren van een API niet gemakkelijk is, de juiste aanpak vinden is een kunstvorm.

Veiligheid heeft veel gezichten

We focussen op veiligheid vanuit een API-perspectief. Er bestaan ook firewalls, virusscanners, malware opsporingsprogramma’s enz. Onze business bij Yenlo draait echter voornamelijk om API’s en vandaar deze invalshoek. Je zou kunnen zeggen dat je zou willen dat jouw API-gebruikers zich registreren en met een token werken. Dat zal de gebruiker autoriseren en kan later ingetrokken worden. Zonder token heb je absoluut geen toegang. De token kan gebruikt worden in samenspel met de gebruikersnaam en wachtwoord door een OAUTH2-type toestemming. Je zult een client-ID en client-secret moeten uitgeven, naast natuurlijk een gebruikersnaam en wachtwoord voor de gebruiker om een token te genereren.

Als je de token binnen een korte tijd laat verlopen, geeft dit je een bepaalde veiligheid. Maar de token op zich is, voor de tijd die het geldig, nog steeds zoiets als een sleutelpas in een hotel. Als je het pasje hebt, kun je de ruimte binnenkomen. Niemand controleert of je daadwerkelijk de rechtmatige bezoeker van die kamer bent. Een token werkt op dezelfde manier.

Toch zijn dat maar eenvoudige dingen, laten we eens kijken naar waar we in eerste plaats veiligheidsmaatregelen voor nodig hebben.

Waar zijn veiligheidsmaatregelen voor nodig?

Er zijn een aantal redenen te noemen:

1. Wet- en regelgeving
2. Public relations
3. Zakenrelaties (bijvoorbeeld: integriteit)
4. Bedrijfscontinuïteit (DDOS, Ransomware)

AVG, CCPA en dergelijke

De eerste categorie bevat het feit dat er wetgeving bestaat over het beheer van gegevens zoals de AVG in Europa die voorschrijft wat je wel en niet zult moeten doen met het oog op de bescherming van gegevens. De Verenigde staten krijgen steeds meer wetgevingen van dezelfde strekking. De California Consumer Privacy Act (CCPA) is daar een voorbeeld van. In Europa betekent dit dat er flinke boetes uitgedeeld kunnen worden als er meerdere overtredingen vastgesteld worden. Dit kan oplopen tot 20 miljoen euro of 4% van de jaaromzet, net welke van de twee hoger is. Meerdere overtredingen houdt in dat je nalatig bent en geen voorzorg genomen hebt door zaken te updaten.

API’s worden ook gebruikt om diensten aan te bieden op het gebied van klantgegevens. De PSD2 richtlijn is een voorbeeld waarbij banken derden toe moeten laten om gegevens in te zien. Maar dat natuurlijk alleen als de daar toestemming heeft gegeven om zijn gegevens te gebruiken. Bijvoorbeeld gegevens die gerelateerd zijn aan zijn bankrekening en transacties.

Publieke schandpaal

Vergeet niet dat er ook veel druk staat op veiligheidsmaatregelen vanuit het perspectief van public relations. Datalekken worden vaak in de media gemeld. Online staan lijsten met datalekken waarbij miljoenen gebruikers van gerenommeerde bedrijven getroffen zijn. (Ik ga geen namen noemen en hier een schandpaal neerzetten, maar je kunt ze op Google terugvinden. Internet vergeet dingen niet gemakkelijk). Is dit allemaal vanwege onbeveiligde API’s? Nee, waarschijnlijk niet. Toch laat het zien dat een datalek of gelekte data via een API nieuws is waar persbureaus maar al te graag over schrijven. Maar zelfs als mensen niet in staat zijn om gegevens van je te stelen, kunnen ze nog steeds je zaken of diensten verstoren of stilleggen.

Integriteit

Stel je een API voor die niet afdoende beveiligd is. Mensen kunnen bijvoorbeeld jouw inventaris manipuleren. Laten we zeggen dat ze de aantallen te verkopen producten flink omlaag zetten. Is er nu al iets gestolen? Nee, je zult er geen kopzorgen over hebben, want wat er in je database staat is de waarheid. Maar als je de waarheid wilt controleren, kan dat een monnikenwerk worden door de hele inventaris in het magazijn na te gaan tellen.

Het zou ook kunnen dat hackers in staat zijn om het aantal stuks op voorraad omhoog zetten. Dat vraagt niet alleen om een hertelling, maar betekent ook dat mensen teleurgesteld moeten worden die spullen gekocht hebben die niet leverbaar waren, omdat het vermelde aantal groter was dan de voorraad.

In beide gevallen is dit niet wat je wil.

Je kunt je veel meer situaties indenken, zoals prijsveranderingen. Of het wijzigen van een afbeelding in iets ongepasts. Dat zou de organisatie wel echt hoofdpijn opleveren. Zoals je ziet, het wijzigen van gegevens is net zo goed een nachtmerrie.

En zelfs het feit dat iemand toegang tot je gegevens heeft die hij niet zou mogen hebben, is een PR-ramp. Neem een database met de lengte van personen, waar mensen ineens elkaars lengte kunnen zien. Zijn dit persoonsgegevens? Ik denk het wel in bepaalde gevallen.

Het lijkt niet zo’n groot probleem, omdat als je naar een persoon kijkt, je ook zo ongeveer zijn lengte kan inschatten. Maar het feit dat mensen geen toegang tot deze database zouden mogen hebben, en dat nu wel hebben, dat is het probleem.

DDOS en ransomware

Genoeg hierover. Laten we het eens hebben over een aantal andere beveiligingscasussen. We zouden kunnen denken aan DDOS (distributed denial of service) waardoor je API’s overspoeld worden met aanvragen en als die niet adequaat behandeld worden (wat een klus op zich is), je hele dienst onbruikbaar gemaakt wordt. Ransomware is een twee keer zo zware aanval en geeft de beveiliging daadwerkelijk hoofdpijn. Je verliest geld, je imago en sommigen verliezen soms zelfs hun baan.

Beveiligen is cruciaal

Nu we begrijpen dat beveiligingsmaatregelen cruciaal zijn stellen we de vraag: wat kun je eraan doen? Het antwoord is relatief eenvoudig. Wat je nodig hebt is een API-managementoplossing in samenspel met een Identity Server die je de mogelijkheid geeft om de identiteit en toegang tot je API’s te managen. Bij voorkeur als een dienst natuurlijk, omdat dit het voordeel heeft dat je het werk aan beveiliging, patches, uptime en monitoring uitbesteedt. Maar hoe zou zo’n platform heten en welke producten zijn daar dan onderdeel van? Nou, dat is het Yenlo’s Connext Platform (beschikbaar als een Platform-as-a-Service-concept) en gebouwd door Yenlo op basis van de prijswinnende open-source WSO2 API Manager, WSO2 Enterprise Integrator en de WSO2 Identity Server waarmee je direct jouw API’s veilig kunt openstellen. Dit wordt nog eens gecombineerd met een volledig geïntegreerde ELK-stack voor monitoring en interactieve weergaves. Het is de ultieme platformoplossing voor jouw API’s en integraties en is inclusief het 42Crunch API onderzoek dat door Yenlo gedaan wordt om te zien of de definities (bijv.: bronnen, context, en http verbs) ook veilig zijn.

Op deze manier hoef je nergens wakker over te liggen wat betreft de veiligheid van je API’s. Voel je vrij contact met ons op te nemen als je meer zou willen weten.

Webinar

Op donderdag 22 oktober 2020 vanaf 9:00 a.m. (PDT) / 6:00 p.m. (CET) / 9:30 p.m. (IST), organiseert Yenlo een webinar over de veiligheidsaspecten waar API’s aan blootgesteld worden, waarom we voor de WSO2 API-Manager kiezen en beiden we een algemeen overzicht van het product en demonstreren we hoe een voorbeeld API gecheckt wordt op veiligheid, ontdekken we de kwetsbaarheden en laten we je zien hoe die te verbeteren.

Registreer je nu om mee te doen aan het webinar.

Gepubliceerd op 22 september 2020