Tijd om je API te verbergen
De behoefte aan robuuste API-beveiliging groeit snel als reactie op de toenemende afhankelijkheid van organisaties van API’s voor hun digitale activiteiten.
Aangezien 70% van de respondenten van een rapport verwacht in 2023 meer API’s te gebruiken dan vorig jaar, vormt dit een grotere uitdaging voor API-beveiliging, die momenteel slechts ongeveer 4% uitmaakt van de testinspanningen bij organisaties. Het 4e jaarlijkse State of the APIs-rapport verzamelde inzichten van meer dan 850 wereldwijde ontwikkelaars, ingenieurs en leiders uit de hele technologiegemeenschap in meer dan 100 landen, waaronder de VS, het VK, Duitsland en India.
Het toegenomen API-gebruik is vooral prominent aanwezig in de telecommunicatie, dat naar verwachting zal stijgen tot 72%, vergeleken met 59% vorig jaar. Daarna volgen kleinere, maar nog steeds aanzienlijke stijgingen op het gebied van technologie en professionele dienstverlening.
Mark O’Neill, VP-analist en hoofd onderzoek voor software-engineering bij Gartner, voorspelde in 2021 correct dat API-inbreuken tegen dit jaar de belangrijkste bedreigingsvector voor webapplicaties zouden zijn. “Een deel van de reden daarvoor is dat bij mobiele en web-apps, samen met elk ander type moderne applicatie die je gebruikt, het allemaal om het gebruik van API’s gaat”, aldus O’Neill.
Onderzoek van Gartner heeft geschat dat tegen 2025 minder dan de helft van de enterprise-API’s zal worden beheerd, aangezien de explosieve groei van API’s de mogelijkheden van API-beheertools overtreft en “beveiligingscontroles oude paradigma’s proberen toe te passen op nieuwe problemen.” Dit enorme aantal API’s dat rond de organisatie zweeft, wordt volgens O’Neill verder gecompliceerd doordat meerdere teams API’s bouwen en beheren terwijl ze verschillende cloudplatforms en -frameworks gebruiken.
“Als je verschillende platforms hebt waarop je teams API’s bouwen en implementeren, is er geen plek om de gateway te plaatsen, wat een probleem is voor traditionele API-beheeroplossingen”, aldus O’Neill. Om dit brede API-landschap te beveiligen, hebben veel bedrijven meerdere gateways opgezet, wat betekent dat er nu meer gateways voor API’s zijn, maar het creëerde een nieuw probleem om te leren hoe al deze gateways samen te beheren.
“Veel klanten hebben ons gevraagd om een gefedereerde oplossing die over verschillende API-gateways zou werken en teams in staat zou stellen een enkel beeld van hun API-verkeer te hebben en één enkel controlevlak voor beheer en beveiliging te hebben, maar op dit moment is dat een hiaat op de markt,’ zei O’Neill. Met één enkele gefedereerde oplossing kunnen gebruikers authenticatie- en autorisatieschema’s opzetten voor verschillende API’s, zodat alleen de juiste gebruikers toegang hebben tot de juiste bronnen. Het stelt beheerders ook in staat om snelheidsbeperkingen en andere beveiligingsmaatregelen in te stellen, zoals IP white/blacklisting, ter bescherming tegen kwaadaardige aanvallen.
Met een dergelijke oplossing zouden teams ook inzicht krijgen in de prestaties en het gebruik van API’s, waardoor teams potentiële beveiligingsproblemen snel kunnen identificeren en aanpakken.
Het andere probleem met API’s voor API-beheeroplossingen is dat er veel verschillende soorten API’s in gebruik zijn. De API-warboel bestaat vaak uit REST, Webhooks, Websockets, SOAP, GraphQL, Kafka, AsyncAPI’s, gRPC’s, zo niet meer.
“Als je kijkt naar een typische organisatie die API-beheer heeft geïmplementeerd, denken ze misschien dat al hun API’s op één platform worden beheerd”, zei O’Neill. “Maar meestal zijn er veel andere API’s die ze hebben die deel uitmaken van webapplicaties, deel uitmaken van mobiele apps, en die worden niet beheerd, ze zijn effectief onder de radar voor die organisatie. En dit zijn degenen die geschonden worden.”
De API’s om op te letten zijn vooral GraphQL’s, aldus O’Neill. Gebruikers kunnen zeer brede en diepe query’s op gegevens uitvoeren, wat ook hun nadeel kan zijn, omdat het moeilijk is om de juiste regels voor toegangscontrole in te stellen. Door de complexiteit van de query kan het moeilijk zijn om te voorspellen welke gegevens toegankelijk zullen zijn.
Bovendien kan het gebruik van variabelen in query’s het moeilijk maken om te voorkomen dat kwaadwillende gebruikers de API misbruiken. GraphQL API’s zijn vaak stateless, wat betekent dat beveiligingsteams ervoor moeten zorgen dat alle verzoeken correct worden geverifieerd en geautoriseerd. Dit soort API’s zijn ook nieuw, dus veel organisaties zijn de vaardigheden van hun beveiligingsteams aan het opbouwen rond GraphQL en grafische API’s in het algemeen.
Een andere uitdaging is om na te gaan waar al je API’s vandaan komen.
Terwijl interne API’s nog steeds de meest voorkomende API-type-ontwikkelaars waren voor hun organisatie, meldden meer ontwikkelaars in 2022 dat ze aan partnergerichte of externe API’s werkten dan het jaar ervoor. Daarnaast gebruiken de SaaS-applicaties die ontwikkelaars gebruiken ook vaak hun eigen set API’s.
Volgens het State of the API-rapport van 2022 groeide het percentage ontwikkelaars dat aangaf te werken aan partnergerichte en externe API’s in 2022 met bijna 5% ten opzichte van 2021. Deze verandering was zelfs nog dramatischer met partnergerichte API’s in sectoren zoals technologie, die met bijna 10% groeiden.
Een hotspot van beveiligingsproblemen zit meestal rond de API’s die toegang tot gegevens vereisen: klantgegevens, voorkeuren en allerlei soorten accountinformatie. Problemen omringen ook API’s die een functie uitvoeren om iets te doen, omdat daarvoor vaak een transactie nodig is, dus betalingsinformatie kan gevaar lopen, zei O’Neill.
“Een daarvan is het hele gebied van klantenkaarten waar je punten krijgt voor het doen van aankopen, reizen, enzovoort. Daarbij zijn veel API’s betrokken. Zo heb je een API om op te zoeken hoeveel punten een bepaalde persoon heeft of je hebt een API om de punten uit te geven. We hebben beveiligingsinbreuken gezien waarbij aanvallers mensen konden vinden die veel punten hadden verzameld en die vervolgens uitgeven,’ zei O’Neill. “Vaak is de persoon zich er niet van bewust, omdat ze zich er simpelweg niet van bewust waren dat ze al deze punten in de eerste plaats opliepen, en dan weten ze niet wanneer ze worden uitgegeven.”
De eerste stap om API-beveiliging te waarborgen, is om alle API’s in de organisatie te catalogiseren en te inventariseren. Bedrijven kijken vaak alleen naar hun bestaande API-gateway om te zien welke API’s daar zijn geregistreerd, maar zelfs meerdere gateways geven niet het volledige beeld, legt O’Neill uit.
“De manier waarop we mensen adviseren om dit te doen, is om te zien van welke API’s uw bedrijf afhankelijk is”, aldus O’Neill. “Dat kunnen dus natuurlijk je eigen API’s zijn, maar ze kunnen ook belangrijk zijn voor API’s die je ook van derden afneemt. Het wordt een probleem als die API’s te maken krijgen met een beveiligingslek, als ze niet beschikbaar zijn of als ze gewoon veranderen en ingrijpende wijzigingen aanbrengen. API-ontdekking is dus een moeilijk probleem, omdat je op meerdere plaatsen naar de API’s moet zoeken.
Eén benadering is om de interne productmanagers, die vervolgens met technische leiders praten, te vragen welke API’s de teams aan het bouwen zijn.
Er zijn ook enkele oplossingen op de markt waarmee gebruikers toepassingsfirewalls in de infrastructuur op CDN-niveau kunnen aanboren om naar het verkeer te kijken en te zien welke API-aanroepen er plaatsvinden. “Die aanpak kan in veel opzichten te laat zijn, omdat de API’s die je ontdekt al in productie zijn. Maar toch, het is beter dan ze helemaal niet te ontdekken,’ zei O’Neill.
Door samen te werken met API’s kunnen organisaties als geheel veiliger worden. Een voorbeeld hiervan deed zich voor in het Open Banking Initiative dat in Europa begon, maar sindsdien in populariteit is verspreid naar Noord-Amerika. Het Open Banking Initiative begon in januari 2016, toen de Competition and Markets Authority (CMA) in het VK een richtlijn uitvaardigde waarin de negen grootste banken van het land werden opgedragen hun klantgegevens open te stellen voor externe providers.
Sindsdien is het waardevol geworden omdat het financiële instellingen in staat heeft gesteld Open API’s te creëren die externe organisaties en hun externe ontwikkelaars kunnen gebruiken, aldus MuleSoft in een blogpost.
In plaats van de API’s open te stellen voor aanvallen, maakte het initiatief een veilige vorm van gegevensuitwisseling mogelijk die de samenwerking met externe organisaties versnelt en de risico’s verkleint die samenhangen met screen scraping, een techniek die door programma’s wordt gebruikt om gegevens te extraheren uit de voor mensen leesbare output van een computer applicatie. Schermschrapen is onveilig omdat het vereist dat klanten inloggegevens van externe aggregators verstrekken en het ook bij elke “schraap” aanzienlijk verkeer naar servers duwt.
Open Banking-initiatieven bieden financiële instellingen de mogelijkheid om via API’s veilig samen te werken met externe ontwikkelaars. In tegenstelling tot screen scraping is deze veilige gegevensuitwisseling API-enabled en worden servers niet overbelast.
Cyberaanvallen en datalekken stoppen niet met een economische vertraging. Bij het prioriteren van beveiligingsinvesteringen moeten beveiligingsleiders blijven investeren in beveiligingscontroles en -oplossingen die de klantgerichte en inkomstengenererende workloads van de organisatie beschermen, evenals alle infrastructuur die cruciaal is voor gezondheid en veiligheid voor die organisaties in sectoren zoals nutsbedrijven, energie, en transport, volgens Forrester in zijn Planning Guide 2023: Security & Risk.
“API-first is de de facto moderne ontwikkelingsbenadering, en API’s helpen organisaties nieuwe bedrijfsmodellen en methoden voor betrokkenheid bij klanten en partners te creëren. Beveiligingsinbreuken als gevolg van onbeschermde API’s en API-eindpunten komen echter veel voor en geen enkel type tool lost API-beveiliging volledig op”, stelt de gids. API-beheertools pakken authenticatie- en autorisatieproblemen aan, terwijl API-specifieke beveiligingstools worden gebruikt voor scannen en ontdekken. Bovendien breiden sommige beveiligingstools zich verder uit om runtime-beveiligingen en microgateways te bieden ter bescherming tegen API-aanvallen. Traditionele beveiligingstools zoals WAF’s en botbeheeroplossingen worden ook uitgebreid om deze aanvallen te dekken, aldus het rapport.
Gartner’s O’Neill zei dat hij ziet dat grote leveranciers stappen voorwaarts zetten in het bieden van krachtige API-bescherming en dat ze ook enkele van de kleinere gespecialiseerde leveranciers overnemen die zijn meegekomen voor API-bescherming. Volgens het 2022 State of APIs-rapport zei 69% van de ontwikkelaars dat ze verwachten API’s meer te gaan gebruiken in 2023, terwijl 25% zei ongeveer hetzelfde te verwachten. Slechts ongeveer 6% geeft aan minder te verwachten of het niet te weten.
