Ik zie veel kwetsbare API’s voorbij komen die niet veilig zijn. Hoe kan het dat API’s kwetsbaar zijn? Waarom wordt er niet serieus om gegaan met security? Laat mij je voorstellen aan mijn oom, die niet serieus om ging met security.
Ready? let’s GO.
We gaan starten met een burcht. Iedereen weet waarschijnlijk wat een burcht is. Maar wat heeft een burcht te maken met een API? Eventjes geduld want daar kom je snel achter. Laat ik al wel het doel van mijn blog met je delen: blijf je API’s versterken en voorzien zijn van één of meerdere security maatregelen.
Mijn oom en zijn kwetsbare nederzetting (API)
Zoals beloofd het verhaal over mijn oom die in de middeleeuwen leefde. Hij was een boer en op zijn kleine boerderij verbouwde hij graan. Hij werkte keihard, had zijn hart op de juiste plek maar was te goed van vertrouwen in de mens. Vaak was zijn oogst goed en mensen kwamen graag met hem in contact om goederen te ruilen.
Na een aantal jaar had mijn oom een kleine nederzetting opgebouwd met mensen die hij blind kon vertrouwen. Door met elkaar goederen te ruilen was de nederzetting welvarend en de populatie groeide. Samen met mijn tante en mijn twee nichtjes was het leven prima.
Helaas was hij te goed van vertrouwen. Hij had weinig geld en geen oog voor security. Zijn nederzetting was kwetsbaar zonder dat hij het door had. Hij nam dus geen moeite om zijn nederzetting te beveiligen. Er waren geen muren, uitkijktorens, ophaalbruggen of entree poorten.
Na een periode van twee jaar zag mijn oom steeds vaker mensen in de luwte, kijkend naar zijn nederzetting en zij verdwenen weer in de bossen. Dat was het moment dat plunderaars een aanval voorbereidden. Op een zekere dag viel de nacht en kwamen de plunderaars in actie! Met een hoop kabaal, paarden en wapens werd zijn nederzetting geplunderd en ging zijn boerderij in vlammen op.
Wat nu? Gelukkig werd het leven van mijn oom, mijn tante en mijn nichtjes gespaard maar hij moest opnieuw beginnen om te overleven… Mijn leermoment? Wees niet afhankelijk van de genade van hackers.
Let nu goed op!Het is belangrijk om het verschil duidelijk te maken tussen de plunderaars van toen en de hackers van nu…
Met een beetje gezond verstand kon mijn oom de aanval van de plunderaars aan zien komen. Dan was de ravage niet zo groot geweest; ze lieten uiteindelijk een duidelijk spoor van vernieling achter.
De hackers van nu? Die zie je niet aankomen en laten zo min mogelijk een spoor van vernieling achter. Sterker nog… Het kan dagen, maanden of zelfs jaren duren voordat je er achter bent dat er een aanval heeft plaats gevonden.
Hoe verhoudt een API zich tot de boerderij van mijn oom
De boerderij produceerde voedsel [POST], leverde voedsel aan de populatie [GET] en verwijderde voedsel als het bedorven was [DELETE]. De boerderij kon geen gebruik maken van een burcht dus was het wachten op problemen. Het voedsel werd geplunderd of vergiftigd (corrupted data) [PUT] met onherstelbare schade als eindresultaat.
De boerderij ging failliet.
Het is tijd voor een burcht
Hoeveel (nieuwe) API’s stel jij beschikbaar aan de open wijde wereld (internet)? Hoeveel security maatregelen pas je toe op het gebruik? In veel gevallen laat de beveiliging te wensen over door te weinig resources, kennis en/of geld. Ik schrik voortdurend van de grote hoeveelheid API’s die slecht beschermt zijn zoals de boerderij van mijn oom. Laat me je inspireren door het gebruik van een API Gateway (burcht) in dit gedeelte van mijn blog post.
Een burcht is een API gateway voor al je nieuwe en bestaande API’s. In mijn geval neem ik je mee in de wereld van Microsoft: Azure API Management (APIM). Ik wil je kennis laten maken met de mogelijkheden. Na het lezen van mijn blog post heb je inspiratie voor het beveiligen van je API’s. Denk aan hoge muren, sterke poorten, uitkijktorens met boogschutters en ophaalbruggen. Deze blog post beperkt zich nu tot een basis toegangspoort en de mogelijkheden tot het bouwen van hoge muren door middel van policy’s.
Hierbij ook nog het antwoord van Wikipedia maar dat slaat natuurlijk nergens op…
Laat (nieuwe) je boerderijen direct gebruik maken de security features van een burcht
Lieve mensen, ga alstublieft gebruik maken van een API gateway zoals een APIM oplossing. Voor ontwikkelaars is het een fantastische uitkomst want we hoeven ons geen zorgen te maken over het leveren van een API inclusief één of meerdere security maatregelen.
Mijn beste CISO collega, je kan je beleid afdwingen vanaf één centrale plek. Eén plek waar al je API’s aan moeten en kunnen voldoen.
En jullie van de operatie? Er zijn veel monitoring features om je burcht real-time te bewaken.
De vele belangrijke features van APIM
Om even in de beeldspraak van mijn oom te blijven, laten we kort een tweetal features bespreken die hij goed had kunnen gebruiken: een basis toegangspoort en de hoge muren met potentie.
Disclaimer: op een later moment zal ik hier zeker dieper op in gaan door nieuwe blogs te maken. Het gaat nu om de inspiratie.
De basis toegangspoort van de burcht
Standaard worden voor alle API’s binnen APIM beveiligd met een subscription key. Deze subscription key heb je nodig om een API te consumeren. De subscription key krijg je pas tot je beschikking als je geabonneerd bent op het product waar de API onderdeel van is. Uiteraard zit er een approval workflow achter zodat je niet eenvoudig in bezit kan komen van de subscription key.
Het is een sleutel die past in het sleutelgat van de toegangspoort waarmee je enkel toegang krijgt tot API’s binnen je geabonneerde boerderij. Je eerste security maatregel heb je hierbij toegepast.
LET OP: zie mijn blog over de risico’s van de “master key”. Eenmaal de master key in handen en je hebt toegang tot alle boerderijen binnen je burcht.
Maak gebruik van geavanceerde muren
Een API call heeft twee belangrijke kenmerken: het onvangen van een request en het beantwoorden van de request in de vorm van een response. Door gebruik te maken van APIM policy’s heb je controle over het accepteren (of juist niet) van een request en de inhoud van de response. Deze controle is belangrijk! Je wilt mogelijk een aantal voorwaarden definiëren voordat een request geaccepteerd wordt en je wilt niet te veel informatie blootstellen in je response.
Een APIM policy heeft een viertal momenten waar controle op uitgeoefend kan worden tijdens het verloop van een API call (levenscyclus):
- Inbound;
- Backend;
- Outbound;
- Error.
Hieronder de XML code snippet vanuit de de documentatie van Microsoft over het toepassen van de controle.
<policies>
<inbound>
<!-- statements to be applied to the request go here -->
</inbound>
<backend>
<!-- statements to be applied before the request is forwarded to
the backend service go here -->
</backend>
<outbound>
<!-- statements to be applied to the response go here -->
</outbound>
<on-error>
<!-- statements to be applied if there is an error condition go here -->
</on-error>
</policies>Eigenlijk is het heel simpel: maak meer gebruik van de policy’s,. Zorg ervoor dat je ze goed en op het juiste moment toepast. Je zult zien dat de muren van je burcht sterker worden. Voordat je het weet staat er een peloton van boogschutters op je muur om je API’s te beschermen!
Zo klaar is Kees, einde blog? Ja voor nu wel… Ik vind een blog van 1000 woorden voor jou als lezer meer dan genoeg. Ik krijg nog wel veel vragen over het juist toepassen van de policy’s. Wat is het laag hangend fruit? Met welke policy’s kan je het beste beginnen? Wanneer pas je de juiste maatregel (policy) toe? Dat ga ik nog zeker met je delen in toekomstige blog artikelen. Je kan mij ook altijd een berichtje sturen.
Het advies aan mijn favoriete oom
Beste oom uit de middeleeuwen, je kan hard werken en biedt hulp aan anderen maar je bent naïef gebleken. Je trotse nederzetting is aangevallen doordat je kwetsbaar was. Ik weet zeker dat je de volgende keer security serieus neemt en dat je er alles aan zult doen om je nederzetting te beschermen! Mijn advies, ga gebruik maken van een API Gateway zoals APIM en houdt alle kwaadwillenden buiten de deur.
One Comment