Planning Network Security For Your Mission-Critical Workloads With Virtual Networks

Speakers: Anitha Adusumilli and Mario Lopez

Networking ensure that data remains in your private space in the cloud. So it’s not just a VM thing.

Understanding Cloud Challenges

• Dynamic, scalable workloads – no fixed network perimeter
• Attack vectors based on application access patterns
• Risk of data exposure to exploits, with a mix of IaaS, PaaS, and SaaS services

Cloud network security is evolving as the apps change!

Planning Network Security in Azure

• Similar controls as on-premises.
• Pick your network security offerings
• Layer and scale
• More flexible than on-premises – faster to deploy/tear down
• Azure offers managed services

You can build a vNet and add subnets as security boundaries. You can add peered vNets locally and in other regions.  And you might have external connections via VPN/ExpressRoute.

There are a mixture of Azure-native and third-party security offerings.

Application access Patterns

Use these to decide what network security solution to pick. Probably will be a mixture of the below.

• Service endpoints
• NSGs
• ASGs
• User-defined routes
• DDoS Protection
• WAF
• Azure Firewall
• NVAs

Security with Azure Services

VMs don’t need public IPs. However, when you use Azure services, they have public IPs, e.g. Azure SQL. This might require you to allow outbound connections that you might not have done before. Anyone with rights for default deployments can access from anywhere. But if you add services to the VNet, via service endpoints, and apply services firewalls, e.g. Azure SQL, then you can restrict access to these platform services.

Two patterns:

• Add services to a VNet where the VNet is all that can access the service
• Add services to a VNet to allow private access, but public access is also possible.

Pattern 1: Deploy services into VNet

Example, App Services Environment (ASE) is deployed into a subnet.

Security:

• NSGs
• NVAs
• User-defined routing can control direction of traffic, e.g.a private deployment can only route via a gateway (forced tunnelling)
• Services in Azure might require outbound access from your VNet. Use Service Tags to limit outbound traffic to local service.

New service tags:

Azure Webapps will be getting preview support soon – an alternative to P2S VPN.

Pattern 2: Service Endpoints

• Extend VNet identity to the service
• Secure your critical Azure resources to only your VNet
• Traffic remains on the Microsoft backbone

How to Secure Your Resources Using Service Endpoints

Normal flow in new setup:

1. Set endpoint on your endpoint
2. Lock your service resource to your subnet

One-Time Migration:

1. Step 1: Add VNet rule without endpoint
2. Set endpoint on subnet
3. Remove the public IP setting

All scenarios: Remove “Allow All Azure Services” or “Allow All” settings.

Service Endpoint: Scaling Security

• Resource locked to a VNet: No access to other VNets or Internet or on-premises.
• Permit more VNets: Turn on service endpoints on VNets and add under “virtual Networks” on resource
• Permit on-premises: Add the on-prem NAT IPs under “firewall” on resource.

Careful – locking network access down can prevent Azure services, such as backup. There are docs for these workarounds – ask Anitha Adusumilli.

Stitching Services Together

• Secure Azure resources to managed service subnets with endpoints
• More

Securing VNet traffic: Services Tags in NSGs

• Restrict network access to just the azure services your use.
• Maintenance of IP addresses for each tag provided by Azure (Service Tags)
• Support for global and regional tags (varies by service)

Service endpoints: Data-Exfiltration Risk

• NSG service tags not enough to prevent data exfiltration from VNet
• Access to unauthorized accounts possible

Option 1: filtering with Azure Firewall or NVAs

• Service endpoints bypass NVAs for service traffic, if set on originating subnet
• Optionally, continue using NVAs for auditing/filtering service traffic
• More

Service Endpoint Policies

• Prevent unauthorized access to storage accounts
• Restrict vnet access to specific azure storage accounts
• Granular access control over service endpoints
• West Central US and West US2 today

Demo: Service Endpoint Policies

She has a VNet with a subnet. Service endpoints is turned on for Storage (all) in the subnet. She only wants to allow access to a single storage account. Adds that storage account to the subnet’s service endpoint. Logs into VM in the subnet and runs Storage Explorer. Can access files in the configured storage account. Another storage account can also be accessed. Goes to Service Endpoint Policies – a top level resource like NSGs. Adds a new policy, adds it to resource group and names it. Sets a scope – all storage accounts, all accounts in resource group, or specific storage account – picks the allowed storage account. Associates the policy with the subnet – like NSG. Now in the VM, only the authorized storage account can be accessed in Storage Explorer.

Switch to Mario for part 2.

Securing Access From Internet

• DDoS attacks
• Web Application Vulnerabilities

New in DDoS Standard

• Attack analysis
• Rapid Response – Specialized rapid response team support during active attacks (via support ticket). Custom mitigation policy configuration.
• Azure Security Center Integration – intelligent DDoS protection virtual network recommendation

New in WAF

They’re flattening the number of subnets using ASGs – tiers of app in one subnet but rules based on on ASGs instead of subnets. Subnets then deployed for Edge/DMZ and app. Using ASGs for micro-segmentation.

Putting it All Together