Section 5 – Implement platform protection – Implement advanced network security – Hybrid and virtual networks

In this part we will be discover the following:

• Secure the connectivity of hybrid networks
• Secure the connectivity of virtual networks

Best practices for securing Your networks:

There is a lot more than these but these are a good way to start securing Your networks.

Build a Hub-spoke network topology

A hub-spoke network topology is a way to isolate workloads while sharing services such as identity and security. The hub is a virtual network (VNet) in Azure that acts as a central point of connectivity to your on-premises network. The spokes are VNets that peer with the hub. Shared services are deployed in the hub, while individual workloads are deployed as spokes.

Routing all on-premises user requests through Azure Firewall

The user-defined route in the gateway subnet blocks all user requests other than those received from on-premises. The route passes allowed requests to the firewall, and these requests are passed on to the application if they are allowed by the firewall rules. You can add other routes, but make sure they don’t inadvertently bypass the firewall or block administrative traffic intended for the management subnet.

Using NSGs to block/pass traffic between application tiers

Traffic between tiers is restricted by using NSGs. The business tier blocks all traffic that doesn’t originate in the web tier, and the data tier blocks all traffic that doesn’t originate in the business tier. If you have a requirement to expand the NSG rules to allow broader access to these tiers, weigh these requirements against the security risks. Each new inbound pathway represents an opportunity for accidental or purposeful data leakage or application damage.

Using ASG

Application security groups enable you to configure network security as a natural extension of an application’s structure, allowing you to group virtual machines and define network security policies based on those groups. You can reuse your security policy at scale without manual maintenance of explicit IP addresses. The platform handles the complexity of explicit IP addresses and multiple rule sets, allowing you to focus on your business logic.

Peering Your virtual networks

Virtual network peering is a non-transitive relationship between two virtual networks. If you require spokes to connect to each other, consider adding a separate peering connection between those spokes.

Suppose you have several spokes that need to connect with each other. In that case, you’ll run out of possible peering connections quickly, because the number of virtual network peerings per virtual network is limited. (For more information, see Networking limits. In this scenario, consider using user-defined routes (UDRs) to force traffic destined to a spoke to be sent to Azure Firewall or a network virtual appliance acting as a router at the hub. This change will allow the spokes to connect to each other.

You can also configure spokes to use the hub gateway to communicate with remote networks. To allow gateway traffic to flow from spoke to hub and connect to remote networks, you must:

• Configure the peering connection in the hub to allow gateway transit.
• Configure the peering connection in each spoke to use remote gateways.
• Configure all peering connections to allow forwarded traffic.

For more information, see Create VNet peerings.

Spoke connectivity

You can also use a VPN gateway to route traffic between spokes, although this choice will impact latency and throughput. See Configure VPN gateway transit for virtual network peering for configuration details.

Consider what services are shared in the hub to ensure the hub scales for a larger number of spokes. For instance, if your hub provides firewall services, consider your firewall solution’s bandwidth limits when adding multiple spokes. You might want to move some of these shared services to a second level of hubs.

Block creation of Private Endpoint and Links to other tenants.

data-management-zone/params.policyDefinition.Deny-PrivateEndpoint-PrivateLinkServiceConnections.json at main · Azure/data-management-zone · GitHub

How to:

Create Azure Private DNS Zones

The Domain Name System, or DNS, is responsible for translating (or resolving) a service name to an IP address. Azure DNS is a hosting service for domains and provides naming resolution using the Microsoft Azure infrastructure. Azure DNS not only supports internet-facing DNS domains, but it also supports private DNS zones.

Azure Private DNS provides the following benefits:

• Removes the need for custom DNS solutions. Previously, many customers created custom DNS solutions to manage DNS zones in their virtual network. You can now manage DNS zones using the native Azure infrastructure, which removes the burden of creating and managing custom DNS solutions.
• Use all common DNS records types. Azure DNS supports A, AAAA, CNAME, MX, PTR, SOA, SRV, and TXT records.
• Automatic hostname record management. Along with hosting your custom DNS records, Azure automatically maintains hostname records for the VMs in the specified virtual networks. In this scenario, you can optimize the domain names you use without needing to create custom DNS solutions or modify applications.
• Hostname resolution between virtual networks. Unlike Azure-provided host names, private DNS zones can be shared between virtual networks. This capability simplifies cross-network and service-discovery scenarios, such as virtual network peering.
• Familiar tools and user experience. To reduce the learning curve, this service uses well-established Azure DNS tools (Azure portal, Azure PowerShell, Azure CLI, Azure Resource Manager templates, and the REST API).
• Split-horizon DNS support. With Azure DNS, you can create zones with the same name that resolve to different answers from within a virtual network and from the public internet. A typical scenario for split-horizon DNS is to provide a dedicated version of a service for use inside your virtual network.
• Available in all Azure regions. The Azure DNS private zones feature is available in all Azure regions in the Azure public cloud.

Use Private Endpoints

To deploy a private endpoint a user must have assigned a built-in role such as:

• Owner
• Contributor
• Network contributor

When You enable Private Endpoints:

• When you enable Private Endpoints, you disable all public access.
• You can enable multiple Private Endpoints in others VNets and Subnets, including VNets in other regions.
• The IP address of the Private Endpoint NIC must be dynamic, but will remain the same until you delete the Private Endpoint.
• The NIC of the Private Endpoint cannot have an NSG associated.
• The Subnet that hosts the Private Endpoint can have an NSG associated, but you must disable the network policies enforcement for the Private Endpoint: see Disable network policies for private endpoints. As a result, you cannot filter by any NSG the access to your Private Endpoint.
• You can eliminate the data exfiltration risk from the VNet by removing all NSG rules where destination is tag Internet or Azure services

Use Private Links

To deploy a private link service a user must have assigned a built-in role such as:

• Owner
• Contributor
• Network contributor

Azure Private Link enables you to access Azure PaaS Services (for example, Azure Storage and SQL Database) and Azure hosted customer-owned/partner services over a private endpoint in your virtual network.

Traffic between your virtual network and the service travels the Microsoft backbone network. Exposing your service to the public internet is no longer necessary. You can create your own private link service in your virtual network and deliver it to your customers. Setup and consumption using Azure Private Link is consistent across Azure PaaS, customer-owned, and shared partner services.

Private Links DNS options:

• Azure VNET without custom DNS Servers (without Active Directory)
• On-premises and/or cloud workloads with own DNS servers and multiple internet routes
• On-premises and/or cloud workloads with own DNS servers and internet gateway forced in on-premises

Workflow

Things to remember

Tips on things to remember for the exam.

Firewall

Make Your firewall know all the traffic by routing the traffic always thru the firewall.

Hub-spoke

A hub-spoke network topology is a way to isolate workloads while sharing services such as identity and security.

Peering

Virtual network peering is a non-transitive relationship between two virtual networks. If you require spokes to connect to each other, consider adding a separate peering connection between those spokes.

NSG (Network Security Group)

Traffic between tiers is restricted by using NSGs.

ASG (Application Security Group)

With ASG You can in example define the servers having the same resources and open an port to allow traffic to this group. Then you add servers to this group and don’t have to define the IP-addresses of these servers.

Private DNS Zones

• Automatic registration of virtual machines from a virtual network that’s linked to a private zone with autoregistration enabled.
• Forward DNS resolution is supported across virtual networks that are linked to the private zone.
• Reverse DNS lookup is supported within the virtual-network scope.

Private Endpoints

• When you enable Private Endpoints, you disable all public access.

Private Links

• Privately access services on the Azure platform.
• On-premises and peered networks
• Protection against data leakage
• Connect privately to services running in other regions. The consumer’s virtual network could be in region A and it can connect to services behind Private Link in region B.
• Extend to your own services: Enable the same experience and functionality to render your service privately to consumers in Azure. By placing your service behind a standard Azure Load Balancer, you can enable it for Private Link.

Link to main post