Een zero-trust security-strategie voor het microservices-mijnenveld

Sidney Rabsatt is Vice President Product Management NGINX

Websites en apps zijn lichtjaren verwijderd van waar ze ooit begonnen. In het begin waren het relatief kleine websites die werden gehost in één enkel datacenter met één toegangspunt. Inmiddels werken we met rijke en dynamische webapplicaties met duizenden gedistribueerde bewegende onderdelen. Deze nieuwe realiteit zorgt voor zeer reële security-problemen. Als uw bedrijf hier niet klaar voor is, kunnen de microservices die uw website of app laten draaien een mijnenveld worden.

De verschuiving naar een microservices-architectuur biedt websites meer flexibiliteit, waardoor de kosten en complexiteit van het toevoegen van nieuwe functionaliteiten afnemen. Het legt echter ook een breder aanvalsoppervlak bloot aan het steeds verder evoluerende scala aan exploits. Om deze uitdaging aan te gaan, moeten we opnieuw bekijken wat een moderne security-perimeter inhoudt.

In dit artikel leg ik uit wat microservices zijn en welke security-problemen hierbij komen kijken.

Wat zijn microservices?

Microservices zijn een andere manier van softwaredesign op basis van een reeks verwante, maar onafhankelijke componenten die elk een specifieke functie hebben binnen een overkoepelende applicatie. Dit in tegenstelling tot het traditionele idee van een ‘monoliet’ ofwel een applicatie die bestaat uit één codebase.

De user interface van een op microservices gebaseerde app ziet er niet anders uit dan die van monolithische applicaties. Achter de schermen echter splitsen microservices een applicatie op in granulaire services die meestal worden gebouwd door kleine teams, en die elk een specifiek onderdeel van een website verzorgen.

Neem bijvoorbeeld een website zoals Amazon. Elke discrete gebruikersactie – van het bekijken van producten of het invoeren van klantgegevens tot zoeken, winkelwagentjes, betalen en nog veel meer – activeert een groot aantal microservices die op hun beurt zelf actie ondernemen of samenwerken met andere services om uiteindelijk het gewenste resultaat voor de gebruiker te leveren.

Het microservices-mijnenveld

Microservices hebben talloze voordelen, maar ze zorgen ook voor een aantal security-uitdagingen. Naarmate het aantal services, evenals het aantal onafhankelijke teams die betrokken zijn bij de ontwikkeling van deze services, applicatiestacks, compute platforms, datacenters en clouds toeneemt, neemt ook het aanvalsoppervlak en het risico aanzienlijk toe.

Stel je een cloudgebaseerde bank- of financiële applicatie voor. De bank is altijd bezorgd over mogelijke inbreuken en datalekken, en dus is er al sprake van complexiteit als het gaat om de robuuste compliance- en firewallregels die zijn ontworpen om dit te voorkomen. Het gebruik van microservices in deze context zorgt voor genoeg punten waar het fout kan gaan. Hieronder gaan we in op drie van die problemen.

  • De toekomstige applicatie wordt gedistribueerd over meerdere servers en services. Die kunnen dicht bij elkaar staan ​​of zich op totaal verschillende locaties bevinden.
  • Het toepassen van microservices is een proces dat een periode van overlap kent met zowel legacy-technologie als nieuwe code. Tijdens het migratieproces bevindt de organisatie zich in een tussenfase omdat de legacy-app nog steeds in gebruik is, terwijl onderdelen van de app planmatig opgesplitst worden in microservices. Op deze manier wordt niet alleen het aanvalsoppervlak groter, maar IT-teams moeten zich ook bezighouden met de security-problemen van de verouderde app en leren om nieuwe microservices te bouwen vanuit een security mindset. Ook moet consistentie van de protocollen en beveiligingsmechanismen tussen de legacy-app en de nieuwe microservices gegarandeerd worden.
  • Er zijn meerdere teams betrokken bij microservices. Wanneer team A aan één microservice werkt en Team B tegelijkertijd een andere codeert, is het belangrijk dat ze dezelfde best practices gebruiken om consistente, beveiligde code te schrijven in de modulaire architectuur. Hoe meer teams hun eigen services schrijven, en met verschillende programmeertalen of applicatiestacks werken, hoe groter de kans dat er iets fout gaat. De houding ten aanzien van security is zo sterk als de zwakste schakel en met microservices zijn er veel meer schakels.

Aanvalsplan voor zero-trust

Het is eenvoudig om de beveiliging van een app aan de voorkant te regelen, maar dat is niet de grootste verandering met microservices. De uitdaging is dat er achter de schermen meer risico’s zijn, gecombineerd met het feit dat er meerdere teams zijn die invloed hebben op hoe de app zich gedraagt. De oplossing begint met het Zero Trust-model.

Simpel gezegd gaat Zero Trust ervan uit dat niets vertrouwd wordt. Wanneer u ervan uitgaat dat iedereen er op uit is om jouw app aan te vallen, is het de taak van een organisatie om te zorgen voor wederzijdse verificatie, autorisatie, codering en transparantie tussen de microservices die deel uitmaken van een applicatie.

Het dynamische en sterk geautomatiseerde karakter van microservices maakt het noodzakelijk dat apps meer verantwoordelijkheid nemen voor het versterken van hun eigen security-perimeter. Zodra je zero-trust accepteert, kan een plan opgesteld worden om ongeschonden door het mijnenveld te komen. Te beginnen bij de basisregels die bepalen hoe apps en services moeten worden gebouwd. Vervolgens moet bepaald worden hoe ze elkaar identificeren en vertrouwen, hoe ze zich onderling gedragen en wat er gebeurt wanneer er iets misgaat.

Een van de eerste stappen die genomen kan worden, is het toepassen van orchestratie om ervoor te zorgen dat de verificatie sterk is en dat al het verkeer end-to-end versleuteld is. Een manier om dit te bereiken, is via TLS-termination voor front-endroutering en het toevoegen van wederzijdse TLS aan backends met geautomatiseerde verificatie via digitale certificaten. Dit zorgt ervoor dat uw services zo zijn ingesteld dat ze alleen met andere services praten die ze kunnen verifiëren. Stel daarnaast regels in die hen alleen toestemming geeft te werken met services die ze zouden moeten kennen.

Zodra het basisvertrouwen er is, worden besturingselementen nuttig. Bedenk hoeveel een bepaalde service aan moet kunnen op basis van bandbreedte, verbindingen en verzoeken. Wat moet er gebeuren als een service meer wordt gebruikt dan verwacht? Denk aan regels die capaciteit bieden of verplaatsen, aanvragen beter bekijken of de transactiegegevens loggen.

Uiteindelijk is er zichtbaarheid. Maar er kunnen en zullen altijd zaken alsnog fout gaan. Zorg daarom voor volledige inzicht in de applicatie en een uitgebreide audit om te weten te komen wie wat heeft gedaan, wanneer en welk deel van applicatie is getroffen. Als er dan een datalek is, beschikt de organisatie over de gegevens die u nodig heeft om het incident onmiddellijk te traceren.

Niemand wil de persoon zijn die de vraag ‘Wat is er in hemelsnaam misgegaan’ van een VP of C-level moet beantwoorden met: ‘Ik weet het niet’.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Deze website gebruikt Akismet om spam te verminderen. Bekijk hoe je reactie-gegevens worden verwerkt.