Private in de Azure public Cloud

Zodra we een solution zonder er al teveel over na te denken deployen in de public cloud, dan hebben we veelal maar 1 layer-of-defence, namelijk authenticatie/autorisatie. Dit zal veelal middels username/password, single sign-on, access-keys of andere geheimen gaan.

Kijk even naar onderstaand diagram. We nemen 3 compute diensten (Kubernetes, Virtual Machine en App Service), en 3 storage diensten (Container registry, Storage Account en SQL Database). Er zijn ook andere variaties mogelijk, maar in dit geval staan alleen Kubernetes en de Virtual Machine in een VNet (Virtual Network). Alle andere diensten hebben een public IP adres en geen integratie met het VNet.

Dit is een feestje voor die hacker uit Rusland, die alle kans heeft om te penetreren op diensten met een public IP adres.

KENMERKEND:

• Infrastructure as a Service (IaaS) diensten (zoals Kubernetes en Virtual Machine) hebben standaard al VNet integratie.
• Platform as a Service (PaaS) diensten (zoals Container registry, Storage Account, SQL Database en App Service) hebben out-of-the-box geen VNet integratie.
• Azure diensten hebben geen toegang tot on-premise data-sources.

Je kunt de nieuwe Docker app lokaal runnen met ‘docker run –rm <imageid>’, waarbij je het imageid uit de Docker build output krijgt. Dit zorgt ervoor dat de Docker container lokaal geladen wordt en de default app in die container gestart wordt. In de Dockerfile zie je bij ‘entrypoint’ dat de nieuwe app automatisch gestart wordt.

Een makkelijke manier om een tweede layer-of-defence toe te voegen is het toepassen van IP white-listing. Alle PaaS (en SaaS) diensten hebben deze mogelijkheid. Met IP white-listing geef je op welke IP adressen toegestaan zijn (denk aan het kantoor, thuis-werkers en Azure diensten).

Deze methode is een veelgebruikte manier. Er is makkelijk mee te starten, en in korte tijd kun je veel bereiken.

Dit maakt het die hacker uit Rusland al een stuk moeilijker, maar niet onmogelijk.

Echter, deze oplossing heeft een paar nadelen:

• IP adressen willen wel eens wijzigen, vooral voor thuis-werkers.
• Verschillende PaaS diensten hebben alleen de IP adressen (zonder naam) in de firewall staan. Zonder administratie is niet te achterhalen welk IP adres voor wie bedoeld was. Dus blijven ze er waarschijnlijk onnodig lang in staan.
• Soms dien je IP adressen van Azure diensten toe te voegen (zie Download Azure IP Ranges and Service Tags), die erg ruim zijn. Tevens kunnen hackers ook Azure diensten afnemen die in dezelfde IP-range komen, en dus door jouw tweede layer-of-defence kunnen penetreren.

Ik zal er ook niet te diep op ingaan aangezien er genoeg over te vinden is. Laten we maar eens gaan kijken of er een Rich man’s solution is…

Voor een solide tweede layer-of-defence gaan we volledig gebruik maken van network-isolation in een VNet. Dit zorgt er voor dat we een vergelijkbaar netwerk opzetten als bedrijven on-premise hebben.

In Azure zou het er als volgt uit kunnen zien:

KENMERKEND:

• Voor IaaS diensten (zoals Kubernetes en Virtual Machine) zal er niets veranderen. Deze worden zoals we al hebben gezien altijd gedeployed in een VNet.
• Voor vele PaaS diensten wordt de firewall dicht gezet, en creëren we een Private Endpoint in het VNet. Meer details volgen hieronder.
• Voor App Service (PaaS) wordt een App Service Environment aangemaakt in het VNet, waardoor de App Service volledig in het VNet gedeployed wordt, en niet vanaf publiekelijk internet bereikbaar is. Ook voor deze volgen meer details hieronder.
• Middels een Express Route creëren we een permanente netwerkverbinding tussen kantoor (on-premise) en het VNet in Azure. Dit is een tweerichtingsverbinding. Wellicht is een Express Route aan de prijzige kant, dan kan het ook met een site-to-site VPN.

Middels deze aanpassingen is er een extra layers-of-defence toegevoegd.

Die hacker uit Rusland maakt geen schijn van kans. Het fort is op slot! Hij zal zijn pijlen wel op iemand anders gaan richten.

Ik heb al kort laten zien dat er gebruik wordt gemaakt van Private Endpoints en App Service Environment. Hier wordt het echter complex: vrijwel iedere PaaS (en SaaS) dienst heeft zijn eigen manier voor network-isolation. Deze brengen extra kosten met zich mee voor de Azure resources, maar ook extra complexiteit dat zich zal vertalen naar hogere ontwikkelkosten. Vandaar dat dit de Rich man’s solution is.

Hieronder volgen de meest voorkomende PaaS diensten, met hun bijbehorende oplossing voor network-isolation…

PRIVATE ENDPOINTS, VOOR STORAGE DIENSTEN

Is van toepassing op:

• Storage Account
• SQL Database (Server)
• Cosmos DB
• MySQL
• PostgreSQL
• Container Registry
• Key Vault
• En nog vele anderen, zie de documentatie

Met een Private Endpoint creëer je een netwerk-interface met een private IP adres in het VNet. Deze netwerk-interface wordt verbonden met de storage dienst. Tevens wordt een DNS record aangemaakt met exact dezelfde naam/URL als je storage connection-string, maar dan verwijst deze naar het private IP-adres i.p.v. het public IP adres. Op de storage dienst wordt de firewall (van het public IP) dichtgezet.

 

Dit geheel zorgt ervoor dat je zonder de applicatie aan te passen, met exact dezelfde connection-string, toch verbinden met de storage dienst.

Kosten: € 9 /maand, bovenop de storage dienst

Private Endpoints zijn de opvolger van Service Endpoints. De Service Endpoints zijn nog altijd beschikbaar en zelfs makkelijker in gebruik, maar ook beperkter in mogelijkheden.

Documentatie:

• Azure Private Endpoint | Microsoft Docs
• Use private endpoints – Azure Storage | Microsoft Docs

APP SERVICE ENVIRONMENT (ASE), VOOR APP SERVICES EN FUNCTIONS

De App Service Environment is een omgeving waarbinnen meerdere App Service Plans (web-servers) gedeployed kunnen worden, met daarop weer de App Services (web-sites). Het grote verschil is dat nu de App Services alleen toegankelijk zijn vanuit het VNet, en toegang hebben tot on-premise data-sources.

 

Als je normaal gewend bent dat een App Service Plan een SKU van Free, Basic of Standard heeft, dan heeft die op de App Service Environment een SKU van Isolated (I1, I2, I3).Kosten: € +/- 950 /maand per App Service Environment v2, bovenop de I1, I2, I3 App Service Plan kosten.

Een groot nadeel van de huidige ASE (v2) is dat deze vaste (stamp) kosten heeft van ongeveer € 950 /maand, en daar komen de kosten voor de App Service Plans (bijvoorbeeld voor I1 is dat € 184 /maand) nog bovenop. Maar er is hoop, want er is een nieuwe preview versie van de ASE die kosteloos is. Zie App Service Environment v3 (en Isolated v2 Plan). Je betaalt dan niet de vaste stamp kosten van € 950 /maand, maar alleen de App Service Plans (I1v2, I2v2, I3v2), al is de goedkoopste variant I1v2 al € 350 /maand.

Documentatie:

• Azure App Service Environment | Microsoft Docs
• Azure App Service Environment v3 (preview) | Microsoft Docs

Het kan ook anders.

Mocht je denken dat App Services ook zonder App Service Environment gekoppeld kunnen worden aan een VNet, dan klopt dat. Echter dien je dan 2 concepten te gebruiken:

• Toegang vanaf VNet tot app-service: Private Endpoint (vereist Premium App Service Plan)
• Toegang vanaf app-service tot VNet: VNet integration

Documentatie:

• Integrate app with Azure Virtual Network – Azure App Service | Microsoft Docs

ON-PREMISE DATA GATEWAY, VOOR POWER BI, POWER APPS EN LOGIC APPS

Bij het gebruik van Power BI (rapportage tooling), Power Apps (no-code/low-code application platform) en Logic Apps (no-code/low-code workflows) is het redelijk voordehand liggend dat deze ook bij on-premise data-sources moeten kunnen, of op een secure manier bij Azure data-sources.

Om network-isolation te bereiken met Power BI, Power Apps en Logic Apps dien je de Data Gateway software te installeren op een Virtual Machine (Windows). Dit zou in Azure kunnen, maar ook on-premise.

 

Kosten: Alleen de kosten van de VM

Documentatie:

• On-premises data gateways documentation | Microsoft Docs

INTEGRATED SERVICE ENVIRONMENT (ISE), VOOR LOGIC APPS

Bij de vorige oplossing ‘Data Gateway’ voor een Logic App, draait de compute nog altijd op een public-internet node. Om er voor te zorgen dat niet alleen de data-access, maar ook de compute afgeschermd is, kun je gebruik maken van een Integrated Service Environment (ISE).

 

De ISE is vergelijkbaar met de ASE, maar dan specifiek voor Logic Apps. Er worden diverse compute en storage resources gedeployed die beheerd worden door Microsoft.

Kosten:

• Developer: € +/- 750 /maand
• Premium: € +/- 6.600 /maand

Documentatie:

• Connect to Azure virtual networks with an ISE – Azure Logic Apps | Microsoft Docs

HYBRID RUNBOOK WORKER, VOOR AUTOMATION ACCOUNTS (RUNBOOKS)

Automation Accounts worden gebruikt voor proces-automatisering, configuratie management, update management en PowerShell desired state configuration (DSC).

Om network-isolation te bereiken met een Automation Account, dien je de Hybrid Runbook Worker software te installeren op een Virtual Machine (Windows of Linux). Dit zou op Azure kunnen, maar ook on-premise.

Kosten: Alleen de kosten van de VM

Documentatie:

• Azure Automation Hybrid Runbook Worker overview | Microsoft Docs

INTEGRATION RUNTIME (IR), VOOR AZURE DATA FACTORY (ADF)

Azure Data Factory is een ETL (Extract, Transform, Load) tool om data te kopiëren en transformeren. Voor de oude rotten onder ons: dit is de opvolger van SSIS (SQL Server Integration Services). Ook bij deze dienst is het erg voordehand liggend dat hij toegang moet hebben tot on-premise data-sources en/of network-isolation.

Om network-isolation te bereiken met Azure Data Factory, kun je uit 2 opties kiezen: A en B

A. SELF-HOSTED INTEGRATION RUNTIME

De Self-hosted integration runtime is wederom een software pakket dat geïnstalleerd dient te worden op een Virtual Machine (Windows). Dit zou in Azure kunnen, maar ook on-premise.

Kosten: De kosten van de VM + gebruik van ADF

Beperking:

• Kan alleen data kopiëren (data-copy), niet transformeren (data-flow)!

Documentatie:

• Self-hosted Integration runtime – Azure Data Factory | Microsoft Docs

B. MANAGED VIRTUAL NETWORK

Het is ook mogelijk om de (standaard) Azure hosted Integration Runtime te gebruiken, maar dan met een Managed Virtual Network. In dit geval wordt er speciaal voor de dor jou aangemaakte IR een VNet aangemaakt, echter heb je zelf geen toegang tot dit network. Je kunt vervolgens wel Private Endpoints aanmaken richting Azure storage diensten, en op die manier network-isolation creëren.

Kosten: +/- 2x zoveel als de reguliere Azure Integration Runtime.

Beperking:

• Kan wel bij Azure storage diensten komen, maar niet bij on-premise data-sources.

Documentatie:

• Managed virtual network & managed private endpoints – Azure Data Factory | Microsoft Docs

SAFEGUARD

Met behulp van network-isolation is het mogelijk om een solution volledig af te schermen van public internet. Echter als er minder secuur wordt omgegaan, kan het zomaar gebeuren dat een firewall wordt opengezet of een VM voorzien wordt van een public IP adres.

Als je de moeite neemt om een solution secure te maken, kijk dan ook naar safegaurds om de solution secure te houden. Dit zou kunnen met Azure policy, die ervoor zorgt draagt dat het bijvoorbeeld niet mogelijk is om een VM te deployen met een public IP, en dat een storage account altijd de firewall aan heeft staan.

Je dient zelf te zorgen voor meerdere layers-of-defence in de public cloud. De eerste zal authenticatie en autorisatie zijn. De tweede zal op netwerk niveau zijn. Dit kan (als Poor man’s solution) met IP white-listing, of (als Rich man’s solution) met network-isolation a.k.a. Private in de public cloud.

Afhankelijk van de Azure dienst, is de oplossing voor network-isolation erg verschillend. Hieronder een korte opsomm

 

Bij een geavanceerde network-isolation solution, dien je safeguards te hebben tegen misconfiguratie. Dat kan met Azure Policies.

De gebruikte Russische hacker is een metafoor voor een kwaadwillende aardbewoner, en kan van iedere andere nationaliteit zijn.