Network security oplossingen in multicloud

Naarmate organisaties steeds meer internetgerichte webapplicaties in de publieke cloud gebruiken, wordt het waarborgen van de beveiliging van gevoelige financiële en persoonlijke gegevens cruciaal. Naast basisbeveiligingsmaatregelen zijn Intrusion Detection and Prevention Systems (IDPS) op netwerkniveau essentieel. Na samen te hebben gewerkt met zowel AWS als Azure om deze oplossingen voor verschillende klanten te implementeren, heb ik aanzienlijke verschillen tussen de twee waargenomen. Deze blog biedt inzichten en richtlijnen om je te helpen deze verschillen te doorgronden en te werken aan een meer uniforme aanpak van netwerkbeveiliging in een multicloud-omgeving.

Begin met native oplossingen

Wanneer je nieuwe functionaliteiten implementeert, is het logisch om eerst de native services van je cloudprovider te verkennen. Deze services beheren onder andere schaalbaarheid, software-updates, beschikbaarheid en het bijwerken van signatures. Azure en AWS, de toonaangevende publieke cloudplatforms, bieden hun eigen IDPS-oplossingen: Azure Firewall Premium en AWS Network Firewall met Managed Rules. Hoewel beide robuuste IDPS-opties bieden, verschillen hun architecturen aanzienlijk.

• Azure Firewall Premium: Meestal implementeer je een enkele firewall-instantie in een Hub Virtual Network (VNet) of Vwan Hub, ken je een privé-IP-adres toe en gebruik je routeringstabellen om het verkeer te sturen.
• AWS Network Firewall: Bij AWS werk je met meerdere firewall-endpoints, wat veel meer flexibiliteit biedt. Hoewel deze flexibiliteit een sterk punt is, maakt het ook de kostenraming complexer, waardoor AWS-oplossingen minder voorspelbaar zijn in vergelijking met de meer transparante prijzen van Azure.

Meer complexe verschillen

Bij een recent project hebben we een multicloud-landingzone geïmplementeerd met IDPS ingeschakeld op zowel AWS als Azure. Op Azure is het inschakelen van IDPS in Azure Firewall Premium zo simpel als een schakelaar omzetten in het portaal of een enkele regel Terraform-code toevoegen. Je kunt kiezen tussen Alert-modus of Deny-modus, waarbij de firewall netwerkverkeer vergelijkt met een steeds groeiende database van meer dan 70.000 treat signatures. Aanpassingen, zoals het configureren van uitzonderingen voor false positives of het toevoegen van TLS-inspectie, kunnen later worden uitgevoerd, maar de kerninstallatie is snel en eenvoudig.

Klik op de afbeelding om deze te vergroten

AWS biedt meerdere netwerkbeveiligingsarchitecturen. Voor deze klant kozen we voor de gecentraliseerde ingress/egress-implementatie, wat redelijk eenvoudig is. AWS native IDPS wordt geïmplementeerd door zogenaamde 'managed firewall rules' toe te voegen naast je eigen bron-bestemming-protocol-poortregels. Deze beheerde regels zijn gebaseerd op het open-source IDPS-project Suricata en worden actief onderhouden. Na het toevoegen van een regel aan je firewallbeleid moet je kiezen of het elke treffer moet waarschuwen (Alert) of blokkeren (Block). Maar het wordt al snel complexer.

IDPS-regels zijn er in twee hoofdtypen:

• Domain and IP Rule Groups: Gericht op domeinen en IP-adressen die geassocieerd worden met botnets, malware of verdachte activiteiten.
• Threat Signature Rule Groups: Analyseren netwerkverkeerpatronen op bekende bedreigingen.

Er zijn vier domein- en IP-regelgroepen en zestien Threat Signature-regelgroepen. Om te beginnen moet je de locatie en volgorde van verwerking van deze beheerde regels actief configureren. Dit gebeurt door de juiste prioriteit aan regelgroepen toe te wijzen, afhankelijk van het verkeer dat je wilt beschermen (bijv. noord-zuid of oost-west verkeer).

Keuzes maken

Maar we zijn er nog niet, elke Firewall Policy heeft een maximale capaciteitslimiet van 30.000 eenheden voor zowel stateless als stateful regels. Elke stateful regel telt voor één capaciteitseenheid, maar je moet voldoende capaciteitseenheden reserveren (en dus al verbruiken) voor elke aangepaste regelgroep die je hebt aangemaakt. Voor stateless regels wordt de capaciteit berekend op basis van het aantal match-criteria dat je definieert, waardoor er meer rekenwerk nodig is. Geen match-criteria (Any of All) hebben een complexiteit van 1. Als je wel match-criteria hebt, bijvoorbeeld twee bron-CIDR-reeksen, één bestemmings-CIDR-reeks, één protocol (bijvoorbeeld TCP of UDP) en één poortnummer, dan telt dat op tot 2*1*1*1=2. Zoals je kunt zien, kan het verbruik van capaciteit snel toenemen zodra je meer match-criteria toevoegt. Daarnaast verbruikt elke Managed Rule Group die je voor IDPS-functionaliteit wilt toevoegen ook een vast aantal capaciteitseenheden, en deze kunnen ook snel oplopen. Ik heb deze capaciteitseenheden nergens gedocumenteerd gevonden, behalve in de AWS Console, dus ik zal ze hier ter referentie opnemen:

Zoals je kunt zien is het totaal al ver boven de 30K, dus het is onmogelijk om ze allemaal in één firewall policy op te nemen, wat betekent dat je keuzes moet maken. Dit houdt in dat je heel goed op de hoogte moet zijn van de soorten workloads die je draait en de bedreigingen die hen waarschijnlijk het meest zullen beïnvloeden, wat gespecialiseerde beveiligingskennis vereist. Een teller in de AWS Console houdt het verbruik van de capaciteit van je policy bij:

Een mogelijke manier om deze capaciteitslimiet te omzeilen is door alle beheerde rule groups als Stateful rule groups te definiëren en alleen Stateless capaciteit te gebruiken voor al je aangepaste regels. Echter, stateless regels zijn veel minder gebruiksvriendelijk, omdat ze alleen verkeer in één richting toestaan en niet automatisch retourverkeer toestaan, zoals stateful regels dat doen. Daarom is dit geen geweldige oplossing. Aangezien je slechts één Firewall Policy kunt koppelen aan een Network Firewall-instantie, is er geen manier om de eenheidslimiet te verhogen.

Ten slotte is dit niet de enige beperking. Elke Firewall Policy heeft een harde limiet van 20 stateless en 20 stateful rule groups. Dus zelfs als de capaciteitslimiet er niet was, zou het toevoegen van alle beheerde regels aan je policy geen ruimte overlaten voor aangepaste stateful rule groups. Naast de beheerde regels van AWS heb je ook de optie om regels toe te voegen die worden beheerd door enkele bekende beveiligingsproviders, wat de hele capaciteitsberekening en schatting nog complexer maakt. Als je, net als ik, TerraForm gebruikt om meer dan 20 rule groups toe te voegen, krijg je de volgende foutmelding:

Overstappen op Multicloud

Voor ondernemingen die in een multicloud-omgeving opereren, neemt de complexiteit aanzienlijk toe. Elke cloudprovider's IDPS vereist verschillende kennis en expertise, wat resulteert in uiteenlopende netwerkbeveiligingsimplementaties. Een webapp die bijvoorbeeld in Azure is geïmplementeerd, heeft mogelijk niet hetzelfde beschermingsniveau in AWS door capaciteits- of regelprioriteitsproblemen.

Zou het niet ideaal zijn om een uniforme oplossing te hebben voor alle clouds?

Een universele oplossing: Aviatrix Distributed Cloud Firewall

Maak kennis met Aviatrix, een platform dat is gebouwd voor multicloud-omgevingen. Aviatrix integreert naadloos met alle native cloudservices en biedt een Distributed Cloud Firewall die centrale zichtbaarheid en beheer mogelijk maakt, ongeacht of je workloads zich in AWS, Azure of een andere cloudprovider bevinden.

Met behulp van Aviatrix Gateways kun je eenvoudig IDPS-functies activeren. Aviatrix introduceert ook SmartGroups, waarmee je soortgelijke workloads in verschillende clouds logisch kunt groeperen voor micro-segmentatie. Met Aviatrix worden alle netwerkbeveiligingsfuncties beheerd via de CoPilot-console, die fungeert als een centraal dashboard voor je volledige multicloud-omgeving.

In tegenstelling tot gecentraliseerde architecturen in Azure en AWS, waar al het verkeer via een centrale firewall wordt geleid, verdeelt Aviatrix de verkeersinspectie over meerdere VNet- of VPC-gateways. Deze gedistribueerde aanpak detecteert bedreigingen eerder en vermindert de kans op knelpunten, wat de prestaties en veerkracht verbetert.

Enterprise-grade functies

Aviatrix is ontworpen voor gebruik op enterprise-niveau en ondersteunt:

• Tot 500 SmartGroups
• 3.000 CIDR’s per SmartGroup
• 2.000 regels per policy
• Overlappende IP-reeksen

Deze mogelijkheden zorgen ervoor dat Aviatrix de schaalbaarheid en flexibiliteit biedt die nodig zijn voor grote, complexe omgevingen.

Klik op de afbeelding om deze te vergroten

Conclusie

Als je binnen een enkele cloud werkt, kan het inschakelen van IDPS eenvoudig zijn - hoewel AWS meer inspanning vereist in vergelijking met Azure. Echter, zodra je overstapt naar een multicloud-opzet, kunnen verschillen in architectuur, beperkingen en aanpassingsmogelijkheden het beheer van netwerkbeveiliging aanzienlijk complexer maken.

Aviatrix biedt een overtuigende oplossing voor multicloud-omgevingen en combineert het beste van zowel AWS als Azure: de eenvoud van Azure en de gedistribueerde architectuur van AWS. Met lagere kosten, gecentraliseerd beheer en krachtige aanpassingsmogelijkheden zoals SmartGroups, is Aviatrix een uitstekende optie voor organisaties die hun netwerkbeveiliging over verschillende clouds willen versterken.