Owen Garrett van NGINX bespreekt in dit artikel microservices en de mogelijke security-risico’s waarmee rekening mee moet worden gehouden. Vervolgens geeft hij mogelijkheden om de risico’s te minimaliseren.
Microservices kunnen van application development en delivery een snel proces maken. Dat is onder andere mogelijk doordat door microservices een groot, monolitisch systeem ontkoppelen in diverse groepen. De microservices-architectuur past goed bij agile ontwikkelingsstrategieën. Daarnaast sluiten microservices goed aan bij API-gedreven situaties. IT-afdelingen die gebruik maken van DevOps kunnen er goed mee uit de voeten. Bedrijven als Netflix, Uber en Lyft hebben de overstap naar microservices al gemaakt. Soms door gefaseerd over te stappen naar het werken met microservices. Andere bedrijven hebben ineens meerdere microservices voor nieuwe applicaties omarmd.
Groter risico
Bij microservices zien we andere aandachtspunten met betrekking tot beveiliging dan bij monolitische systemen. Het is belangrijk te weten waar je op moet letten, voordat je met microservices aan de slag gaat.
Microservices hebben een groter risico op aanvallen dan monolitische systemen
Op microservices gebaseerde applicaties zijn heel anders dan applicaties die in één enkel groot monolitisch systeem zijn gebouwd. Kort na het opdelen van een applicatie in individuele diensten, realiseren organisaties zich vaak dat dit mogelijk riskante neveneffecten kan hebben. Zij kunnen hun trusted clients met behulp van de API’s en Web Endpoints directe toegang tot interne gegevens en diensten geven. Maar deze toegang creëert ook een grotere kans op potentiële aanvallen. En moet dus goed beveiligd zijn.
Lastiger dan ‘gewoon’ webverkeer
Het beveiligen van API’s is echter lastiger dan het beveiligen van normaal webverkeer. Microservices-applicaties maken zeer veel gebruik van API’s voor interne communicatie. Hierdoor is het zinvol sommige van deze API’s extern vrij te geven en te vertrouwen op Rich Javascript-clients om webpagina’s en weergaven op het apparaat van de client te genereren. Als gevolg hiervan is het beveiligen van API’s lastiger dan het beveiligen van normaal webverkeer.
Het beveiligen van API’s is in veel opzichten makkelijker dan het beveiligen van complexe HTML-transacties die via HTTP-verkeer worden overgebracht. API’s zijn meer gestructureerd, zijn voorzien van goed gedefinieerde authenticatie- en autorisatiemaatregelen, en hebben goed gedefinieerde en gemakkelijk te begrijpen request en respons formats. API’s kunnen echter een veel bredere functionaliteit bieden en gevoelige interne informatie openbaar maken. Het is daarom van essentieel belang alle extern toegankelijke API’s zorgvuldig te controleren en vast te stellen welke informatie ze openbaar kunnen maken en op welke interne systemen ze invloed hebben.
API gateways
In plaats van te proberen een interne API te beveiligen, is het in veel gevallen makkelijker voor organisaties om speciaal opgeschoonde API’s voor extern verbruik te construeren die voorzien zijn van beveiligingsmaatregelen, zoals rate-limiting, gedetailleerde logging en circuit-breaker patronen.
Wie een of meer API’s voor externe toegang beschikbaar maakt, doet er goed aan API gateways te overwegen. In plaats van een client die direct via het publieke eindpunt een request indient bij elke microservice, maakt een bepaalde vorm van een API gateway één toegangspunt in het systeem mogelijk. Dit hoeft overigens niet een gespecialiseerd apparaat te zijn. Voor veel use cases kan bijvoorbeeld ook een intelligente omgekeerde proxy worden gebruikt die een organisatie in staat stelt API-verzoeken te inspecteren, te verifiëren en te ‘rate-limiten’. Hierbij treden ze als gatekeeper op. Ze staan alleen verzoeken toe die aan de juiste criteria voldoen. Alle transacties worden bovendien gelogd.
Organisaties moeten ervoor zorgen dat alle API-verkeer is gecodeerd met behulp van TLS (Transport Layer Security) en dat elke API-client wordt geverifieerd met zowel een applicatie-identificatie (een API-sleutel of een ander geheime gedeelde sleutel) als een gebruikersidentificatie (een SSL-certificaat of een OAuth-token). Ook voor anonieme API-requests moet gelden dat ze een unieke gebruikersidentificatie gebruiken, rate limits toepassen en verkeer loggen.
Interne security en microservices
Vergeet de interne security van microservices applicaties niet. Het is daarnaast ook belangrijk andere componenten van de applicatie kritisch te bekijken. Ook al zijn ze vandaag compleet te vertrouwen, dan geeft dat nog geen garanties voor de toekomst. Je weet nu immers niet hoe sterk het aantal clients van je applicatie op termijn zal toenemen. Daarom is het beter dat organisaties voor de gezamenlijke interne communicatie TLS (Transport Layer Security) als standaard nemen. Daarnaast is het verstandig om vanaf de start certificate validation in de architectuur op te nemen van zowel clients en servers. De impact die dit heeft op de performance kan door proxy-encrypties geminimaliseerd worden.
Goed voorbereiden
Om het interne dataverkeer te beveiligen kunnen organisaties verder gebruik maken van SSL-encryptie voor al het dataverkeer. Dat kan bijvoorbeeld met behulp van een PKI (Public Key Infrastructure).
Het is heel belangrijk dat organisaties, voordat ze met microservices aan de slag gaan, zich voorbereiden op aanpassingen qua IT-beveiliging in zo’n nieuwe architectuur. Als je dit van tevoren goed inregelt kun je je voordeel doen van de flexibiliteit en schaalbaarheid van microservices.
Owen Garrett is Head of Products bij NGINX
