Trust No-One Architecture For Services And Data

© Cloud Mechanix 2020 www.cloudmechanix.com
Trust No-One Architecture For
Services And Data
Aidan Finn, MVP
Cloud Mechanix & Innofactor Norway

• 13 year MVP – currently Microsoft Azure (3)
• Previously Hyper-V and SCCM
• Owner of Cloud Mechanix
• Custom-written Azure training
• Principal Consultant for Innofactor Norway
• Azure infrastructure – networking & security
• Working as consultant/sys admin since 1996
• Windows Server, Hyper-V, System Center, desktop managment, and Azure
• http://aidanfinn.com
• http://innofactor.com
• http://www.cloudmechanix.com
• @joe_elway
Aidan Finn
Introduction

Infrastructure and Platforms

• It’s the cloud
• Networks:
• Connection to/from Internet
• Between components of your service
• Not limited to virtual machines!
There Is Always A Network
Even with PaaS

• Control:
• Inbound flows
• Flows between components of your service
• Data access
• Outbound flows
• Log & report:
• Flows
• Classification of threats
• Alert
• Security threat
Network Security
Governance, compliance, and security

• Usual data center approach:
• “Open up everything inside the network”
• It’s easy for admins … and malware and attackers
• Micro-Segmentation
• Breaking up a network into smaller secure zones
• Right down to the workload
• A “trust no one” concept
Essential Concept – Micro-Segmentation
Nothing new – but rarely used

• Public IP Addresses
• Multi-directional:
• North-south
• East-west
• Layer-4 (transport)
• Layer-7 (application)
• Services:
• Into a service
• Between services
• Maybe even between tiers of a service
Micro-Segmentation
Protection

• Limit public IP addresses
• Eliminate Poor “default” virtual machine deployments
• Better platform resource deployment
• Network architecture
• Control the edge
• Routing
• Firewalls
• Implement security at depth
• NSGs
• Resource-based firewalls
• Log and monitor
• Logging & auditing
• Azure Security Center & Azure Sentinel
Micro-Segmentation
Architecture

Limit Public IP Addresses

• The default experience in the Azure Portal
• Click > Click > Click > “magic VM on the Internet”
• Every VM:
• Has a Public IP Address (PIP)
• Has a Network Security Group (NSG) of its own
• Use Azure Policy:
• Prevent PIP association with virtual machine NICs
• Allow exceptions for virtual appliances
• Route inbound traffic using other means:
• RDP/SSH: Azure Bastion, RDGW, Guacamole, etc
• Application traffic: VPN, ExpressRoute, SD-WAN, Firewall NAT, Web Application
Firewall
Default Virtual Machine Deployment
Azure Portal focuses on getting you working, not secure

• Every platform resource is network connected
• Has 1+ public IP addresses
• “Naked” on the Internet
• Some expensive SKUs for full VNet integration:
• SQL Managed Instance, App Service Environment, and more
• Service Endpoints
• Route from virtual network to resource over private Azure backbone
• Private Link + Private Endpoint
• Resource/service gets a private IP address on subnet of your choice
• Routable from VNet and via site-to-site networking
Platform
The virtual network is always there

Network Architecture
Abstract of what we want to achieve
Public IP
Addresses
Resources Resources Resources

Hub & Spoke (VNet Peering)
Enterprise abstract of what we want to achieve
Hub VNet
Spoke
VNet
Spoke
VNet
Spoke
VNet

Hub & Spoke
Using a VNet-based hub (legacy)
RouteTable
VirtualSubnet
VirtualNetwork
Firewall
VirtualNetwork Gateway
RouteTable
VirtualSubnet
RouteTable
VirtualSubnet
VirtualNetwork
RouteTable
VirtualSubnet
VirtualMachineScale Set VirtualMachineWindows
RouteTable
VirtualSubnet
VirtualNetwork
RouteTable
VirtualSubnet
SQL Database
Application Service

Hub & Spoke (Virtual WAN)
Using a Azure WAN hub
VirtualSubnet
VirtualNetwork
VirtualSubnet
VirtualMachineScale Set VirtualMachineWindows
VirtualSubnet
VirtualNetwork
VirtualSubnet
SQL Database
Application Service
VirtualWAN
Gateway
VirtualWAN
Firewall

Control The Edge

• In a physical network, you control flows using network cables
• In the cloud:
• There are no cables
• Packets go directly from source to destination (SDN)
• Routing is the most important part of secure network architecture
• “It’s always routing, and then it’s DNS”
• How you force flows:
• In through a firewall
• Out through a firewall
• Through a firewall to get to another service
• Bypass a firewall for platform control plane
Routing
A firewall in Azure always requires understanding of Azure routing

• Mandatory learning:
• There is always a per-subnet “route table”
• Longest Path First (LPF)
• The most accurate route is always chosen
• Priority – when there are clashing routes:
1. User-defined route
2. BGP
3. Default (“system”) routes
• Routes must exist both ways (client > service, service > client)
• Example: spoke subnet propagates to on-premises
• There is literally hours of learning in this essential topic!
Subnet Routing
This topic is a session all of its own!

• “Softly launched” feature (Sept 2020)
• Used in Azure Virtual WAN
• Central “one time” configuration
• Route tables configured in the regional hub
• Propagated out to connections (branches and spokes)
• Adds support for 3rd party firewall hosted in a spoke
Custom Routing
Routes centrally propagated from Azure WAN Hub

• Azure Firewall
• Platform
• Optional ARM configuration (DevSecOps)
• Optional component of Azure Virtual WAN Hub
• Third-Party firewall
• Familiar
• Already trusted
• Added cost of IaaS maintenance
• Layer-4 protection
• At the edge (North-South)
• In the hub (East-West)
Network Firewall
Network isolation for north-south & east-west traffic

• Layer-7 protection for inbound HTTP/S traffic
• Network:
• Azure Application Gateway w/ Web Application Firewall (OWASP)
• Third-party appliance
• Typically outside of the network firewall flow
• Edge data centers:
• Azure Front Door w/ Web Application Firewall (OWASP)
• Third-party cloud services, e.g. Cloud Flare, Imperva, etc
Web Application Firewall
Often in addition to a network firewall

• Every VNet has DDoS Basic
• You pay (a lot) for Standard
• Enabled on edge VNets with public IP
addresses
• WAF/firewall VNets
• It takes 2 weeks for the machine learning
to “learn” your network
• Don’t wait until you are attacked!
• But it’s really pricey
Distributed Denial of Service (DDoS) Protection
https://docs.microsoft.com/en-us/azure/virtual-network/ddos-protection-overview

Implement Security At Depth

• The “hard egg shell” approach is proven to fail:
• UK NHS, Norway NorskHydro, etc
• Defence must exist everywhere
• Do not trust on-premises
• Do not trust other services
• Do not trust other tiers in a service
• Limit all traffic to absolute minimum needed:
• Source
• Destination
• Protocol/port
• Direction
The Proven Need
We need to learn from past mistakes

• Layer-4 security at the subnet
• Control:
• Ingress
• Egress (I do this centrally at in the hub firewall)
• Implement on a per-subnet basis (best practice according to Azure Networking
product group)
• Not per-NIC
• Scalability and support for platform services
• Recommended:
• Enable NSG Flow Logging/Traffic Analytics
Network Security Groups
Free resource provides a foundation of network security

• Virtual machines:
• Guest OS Firewall
• Platform resources:
• Storage Account
• Azure SQL
• Azure Key Vault
• And many more
• Note, some resource types add identity based protections
• Azure Key Vault access policies
Resource-Based Firewalls
Additional protection at the resource (the last hurdle)

• Virtual Machines
• NIC with private IP address
• Platform resources
• Private Link/Private Endpoint
• Resource gets a private IP
• Expanding rapidly to (planned) every resource type
• Many interesting architectural options (on-prem, SaaS, IP overlap)
• VNet Integration
• Limited resource types
• Typically very expensive SKUs
• App Service Environment, SQL Managed Instance, etc
• Service Endpoints
• Limited resource types, no private IPs
Connect The Resources
VNet/Subnet connection for governance/compliance/security

Log And Monitor

• Send logging & auditing data to Log Analytics
• Azure Firewall, WAF, NSG, VM logs, etc
• Benefits:
• Solution classification (NSG Traffic Analytics)
• Troubleshooting (routing and firewall rules)
• Investigation
• Seamless integration into Azure Sentinel (SIEM)
• Reporting with Azure Workbooks & Power BI
• Using Splunk etc?
• Keep data in Log Analytics for 30 days
• Use Log Analytics to power the Azure toolset
• Keep sending data to Splunk, etc
Logging
Implement this on day 0

• Basic Tier:
• Recommendations (use as a suggestion, not as a rule)
• Data collection from VM guest OS (Azure Sentinel!)
• Standard Tier:
• Machine Learning monitoring
• Adaptive Application Controls
• Adaptive Network Hardening
• Threat Intelligence
• File Integrity Monitoring
• Just-In-Time VM Access
Azure Security Center
Recommendations, compliance, and some operations tools

• Data collection
• Existing logging data from Azure
• Additional data from Azure, other on-premises, and other MSFT & competing
clouds/SaaS
• Machine-learning based threat protection
• Threat hunting
• Notebooks
• Workbooks
• Playbooks
Azure Sentinel (SIEM)
Security Information & Event Management as-a-service

Wrap Up

• http://aidanfinn.com
• http://www.cloudmechanix.com
• http://www.innofactor.com
• @joe_elway
Thank You!
Aidan Finn, Cloud Mechanix

Trust No-One Architecture For Services And Data

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Trust No-One Architecture For Services And Data

Semelhante a Trust No-One Architecture For Services And Data (20)

Mais de Aidan Finn

Mais de Aidan Finn (20)

Último

Último (20)

Trust No-One Architecture For Services And Data

Notas do Editor