Veilig werken met microservices – mits u deze maatregelen neemt

Owen Garrett van NGINX bespreekt in dit artikel micro­ser­vices en de mogelijke security-risico’s waarmee rekening mee moet worden gehouden. Vervol­gens geeft hij moge­lijk­heden om de risico’s te minimaliseren.

Micro­ser­vices kunnen van appli­ca­tion devel­op­ment en delivery een snel proces maken. Dat is onder andere mogelijk doordat door micro­ser­vices een groot, mono­li­tisch systeem ontkop­pelen in diverse groepen. De micro­ser­vices-archi­tec­tuur past goed bij agile ontwik­ke­lings­stra­te­gieën. Daarnaast sluiten micro­ser­vices goed aan bij API-gedreven situaties. IT-afde­lingen die gebruik maken van DevOps kunnen er goed mee uit de voeten. Bedrijven als Netflix, Uber en Lyft hebben de overstap naar micro­ser­vices al gemaakt. Soms door gefaseerd over te stappen naar het werken met micro­ser­vices. Andere bedrijven hebben ineens meerdere micro­ser­vices voor nieuwe appli­ca­ties omarmd.

Groter risico

Bij micro­ser­vices zien we andere aandachts­punten met betrek­king tot bevei­li­ging dan bij mono­li­ti­sche systemen. Het is belang­rijk te weten waar je op moet letten, voordat je met micro­ser­vices aan de slag gaat.

Micro­ser­vices hebben een groter risico op aanvallen dan mono­li­ti­sche systemen 

Op micro­ser­vices geba­seerde appli­ca­ties zijn heel anders dan appli­ca­ties die in één enkel groot mono­li­tisch systeem zijn gebouwd. Kort na het opdelen van een appli­catie in indi­vi­duele diensten, reali­seren orga­ni­sa­ties zich vaak dat dit mogelijk riskante neven­ef­fecten 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 poten­tiële aanvallen. En moet dus goed beveiligd zijn.

Lastiger dan ‘gewoon’ webverkeer

Het bevei­ligen van API’s is echter lastiger dan het bevei­ligen van normaal webver­keer. Micro­ser­vices-appli­ca­ties maken zeer veel gebruik van API’s voor interne commu­ni­catie. 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 bevei­ligen van API’s lastiger dan het bevei­ligen van normaal webverkeer.

Het bevei­ligen van API’s is in veel opzichten makke­lijker dan het bevei­ligen van complexe HTML-trans­ac­ties die via HTTP-verkeer worden over­ge­bracht. API’s zijn meer gestruc­tu­reerd, zijn voorzien van goed gede­fi­ni­eerde authen­ti­catie- en auto­ri­sa­tie­maat­re­gelen, en hebben goed gede­fi­ni­eerde en gemak­ke­lijk te begrijpen request en respons formats. API’s kunnen echter een veel bredere func­ti­o­na­li­teit bieden en gevoelige interne infor­matie openbaar maken. Het is daarom van essen­tieel belang alle extern toegan­ke­lijke API’s zorg­vuldig te contro­leren en vast te stellen welke infor­matie ze openbaar kunnen maken en op welke interne systemen ze invloed hebben.

API gateways

In plaats van te proberen een interne API te bevei­ligen, is het in veel gevallen makke­lijker voor orga­ni­sa­ties om speciaal opge­schoonde API’s voor extern verbruik te constru­eren die voorzien zijn van bevei­li­gings­maat­re­gelen, zoals rate-limiting, gede­tail­leerde logging en circuit-breaker patronen.  

Wie een of meer API’s voor externe toegang beschik­baar 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 micro­ser­vice, maakt een bepaalde vorm van een API gateway één toegangs­punt in het systeem mogelijk. Dit hoeft overigens niet een gespe­ci­a­li­seerd apparaat te zijn. Voor veel use cases kan bijvoor­beeld ook een intel­li­gente omge­keerde proxy worden gebruikt die een orga­ni­satie in staat stelt API-verzoeken te inspec­teren, te veri­fi­ëren en te ‘rate-limiten’. Hierbij treden ze als gate­keeper op. Ze staan alleen verzoeken toe die aan de juiste criteria voldoen. Alle trans­ac­ties worden bovendien gelogd.

Orga­ni­sa­ties moeten ervoor zorgen dat alle API-verkeer is gecodeerd met behulp van TLS (Transport Layer Security) en dat elke API-client wordt geve­ri­fi­eerd met zowel een appli­catie-iden­ti­fi­catie (een API-sleutel of een ander geheime gedeelde sleutel) als een gebrui­ker­si­den­ti­fi­catie (een SSL-certi­fi­caat of een OAuth-token). Ook voor anonieme API-requests moet gelden dat ze een unieke gebrui­ker­si­den­ti­fi­catie gebruiken, rate limits toepassen en verkeer loggen.  

Interne security en microservices

Vergeet de interne security van micro­ser­vices appli­ca­ties niet. Het is daarnaast ook belang­rijk andere compo­nenten van de appli­catie 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 appli­catie op termijn zal toenemen. Daarom is het beter dat orga­ni­sa­ties voor de geza­men­lijke interne commu­ni­catie TLS (Transport Layer Security) als standaard nemen. Daarnaast is het verstandig om vanaf de start certi­fi­cate vali­da­tion in de archi­tec­tuur op te nemen van zowel clients en servers. De impact die dit heeft op de perfor­mance kan door proxy-encryp­ties gemi­ni­ma­li­seerd worden.

Goed voorbereiden

Om het interne data­ver­keer te bevei­ligen kunnen orga­ni­sa­ties verder gebruik maken van SSL-encryptie voor al het data­ver­keer. Dat kan bijvoor­beeld met behulp van een PKI (Public Key Infrastructure).

Het is heel belang­rijk dat orga­ni­sa­ties, voordat ze met micro­ser­vices aan de slag gaan, zich voor­be­reiden op aanpas­singen qua IT-bevei­li­ging in zo’n nieuwe archi­tec­tuur. Als je dit van tevoren goed inregelt kun je je voordeel doen van de flexi­bi­li­teit en schaal­baar­heid van microservices.

Owen Garrett is Head of Products bij NGINX