Networking

This document aims to provide required information to understand the networking services provided by TDF to your Azure Hardened environments. Required vocabulary is available in the Glossary.

---

Introduction

Every C3 Azure Hardened subscription provided by the TDF is configured with some networking services ready to use. This include:

• A dedicated Virtual Network already configured for DNS resolution
• A dedicated address space you can organize as you wish
• A set of dedicated subnets provisioned for some services
• A preconfigured Azure Peering that allow you to reach core TDF resources such as Software Factory
• A set of preconfigured network rules to restrict public exposition of resources on Internet

All these capabilities are provided by default to your subscription.

In C2 Azure Hardened subscriptions, TDF BL consumers are responsible to configure their Virtual Network as they need. TDF will be providing:

• Non-Overlapping address space to be used to create Virtual Network
• Peering capability for your virtual networks with TDF Azure Virtual WAN architecture
• Some C2 TDF Core services

---

My Virtual Network

C3 Dedicated Virtual Network

C3 Azure Hardened subscriptions are provisioned with an Azure Virtual Network Named tdp-he-vnet located in the tdf.he-vnet-rg resource group. This resource is automatically provisioned and configured for you. When requesting your subscription, you were requested to select a virtual Network T-Shirt size. Based on the size you selected, a non-overlapping address space was configured to your Virtual Network. This virtual Network is configured with a set of options:

• Address space size
• Some preexisting subnets
• Peering with core networks
• Internet exposition rules
• Network Security Groups
• DNS

C2 Virtual Network

In C2 Azure Hardened subscriptions, TDF BL consumers are responsible to provision their Virtual Network. Theses Virtual Networks can be peered to the TDF Azure Virtual WAN architecture if comply with the following conditions:

• Virtual Network Address space must have been provided by the TDF (Overlapping address space prevent the peering operation)
• No Virtual Network Gateway provisioned on the Virtual Network (P2S & S2S scenarios)

In C2 Azure Hardened subscriptions, TDF BL consumers are responsible to configure their DNS infrastructure. They can rely on the TDF DNS infrastructure by requesting a peering of their virtual network.

Address space size

When requesting a Landing zone using, you selected a T-Shirt size for your virtual network using the following table. By default, the default address space size is L.

Size name	IP	CIDR Style
S	64	/26
M	128	/25
L	256	/24
XL	512	/23

TDF deliver two types of address spaces :

• THALES : Thales address space can only be used on C3 Azure Hardened Subscriptions
• TDF : TDF address space (172.16.0.0/12) can only be used on C2 Azure Hardened Subscriptions

Notes:

• Address space extension will be offered as a service later on C2 Azure Hardened subscriptions.
• On C2 Azure Hardened subscriptions, TDF BL consumer can bring their own Address space to configure their virtual network. These Virtual network will not be considered as eligible for peering with TDF Azure Virtual WAN architecture
• Azure reserve some IP address for management purposes. By default, each subnet will be using the first IP address of the subnet for gateway purpose and will use two IP address for network related services.

You must consider multiple aspects when selecting your Address space size:

• Some Azure services will require a dedicated subnet for their dedicated usage (Azure Bastion, Azure Application Gateway for examples)
• Some network security features cannot be enabled on the same subnet (Private endpoint and Service Endpoints cannot be enabled on the same Subnet)
• Some subnets are already provisioned by default
• Subnet size cannot be changed unless all linked resources are deprovisioned (or relocated to a different subnet)

Subnet organization (C3 only)

In your C3 Azure Hardened Subscription, your tdp-he-vnet virtual Network will be provisioned with the following pre-existing subnets:

• AzureBastionSubnet
• Private-bastion

The “AzureBastionSubnet” subnet is dedicated to the public bastion service and required for the Azure Bastion service. No virtual machine or other network related resource can be connected to it. Strong Network Security Groups rules are enforced to restrict both inbound and outbound network flow on this subnet. The “Private-Bastion” subnet is dedicated to the Private Bastion service. By default, Bastion related virtual machines will be automatically connected to this subnet. Private Bastion relies on Azure DevTest Labs. Strong Network Security group rules are enforced to avoid direct public exposition for administration protocols such as RDP/SSH.

Before you can deploy your workload on your Azure Subscription, you must organize your virtual network into multiple subnets. You may consider the following subnets:

• A dedicated subnet for Application Gateway to expose your workload. Application Gateway infrastructure configuration. Based on Microsoft documentation you will require at least a /27 dedicated subnet.
• A dedicated subnet for your back end services configured for Private Endpoint. Microsoft recommendation is to isolate theses resources on a dedicated subnet. List of Azure services supporting Private endpoint is available here: Private link resource
• A dedicated subnet for each tier of your workload. If you want to enforce network isolation rules between the front and the back part of your workload, you should consider creating two separated subnets.

Notes:

• Private Bastion service will be removed from C3 Azure Hardened subscriptions in a near future. The Azure DevTest Labs service is not compatible with some C3 service hardening performed. Service will be replaced by a solution that TDF BL consumer will be able to deploy themselves.

Subnet organization (C2 only)

In your C2 Azure Subscription, TDF BL consumers are free to organize their subnet as they need. Before you can deploy your workload on your Azure Subscription, you must organize your virtual network into multiple subnets. You may consider the following subnets:

• A dedicated subnet for Application Gateway to expose your workload. Application Gateway infrastructure configuration. Based on Microsoft documentation you will require at least a /27 dedicated subnet.
• A dedicated subnet for your back end services configured for Private Endpoint. Microsoft recommendation is to isolate theses resources on a dedicated subnet. List of Azure services supporting Private endpoint is available here: Private link resource
• A dedicated subnet for each tier of your workload. If you want to enforce network isolation rules between the front and the back part of your workload, you should consider creating two separated subnets.

Peering (C3 only)

Your tdp-he-vnet virtual Network will be provisioned with the required Azure peering and routing rules information to access Core services provided by the TDF. This peering service is provided as part of the Azure Virtual WAN architecture provided by the TDF. This peering is only possible because the address space used for your Virtual Network is unique and not not overlapping with another one.

TDF BL consumers cannot manage Peering configuration of the tdp-he-vnet Virtual Network. So, you cannot establish a Peering with another virtual network. Providing peering service between Azure Hardened subscriptions is being evaluated.

Peering (C2 only)

Inside a C2 Azure Hardened Subscription TDF BL consumer are able to establish and manage peering with their virtual network. TDF BL consumer can request to have their Virtual Network to be peered with the Azure Virtual WAN TDF architecture to have access to TDF core services. Peering operation will be performed by the TDF Network team if virtual network comply with the following criteria:

• Non-Overlapping address space provided by the TDF to be used to create Virtual Network
• Peering capability for your virtual networks with TDF Azure Virtual WAN architecture

Virtual Network configured by Address space not provided by the TDF will not be eligible for peering with Azure Virtual WAN. Consequence, access to TDF core services will rely on Public internet access only. Services such as TDF central DNS infrastructure will not be available.

Peering monitoring

TDF BL consumers may require to have peering monitoring. If you need to be alerted about the ExpressRoute and Hub status, you need to open a Postit ticket asking to be subscribed to the C3_Net_Subscribers alert group. You can ask to subscribe several email addresses at once.

Here is a template for the Postit ticket:

Hello,
I would like to be subscribed to the C3_Net_Subscribers azure action group for the following mail addresses:
[list of addresses]]

This request is directed to the it-network team.
Thanks.

Internet exposition (C3 only)

According to C3 security compliance level, inbound communication must be blocked by default. For this reason, Internet exposition is limited on C3 Azure Hardened subscription for C3 hardened services. Because only Azure Standard Public IP SKU are allowed on C3 Azure Hardened Subscriptions, no Internet traffic can reach a virtual machine if no NSG rule explicitly allow it.

Internet exposition (C2 only)

By design C2 Azure Hardened environment does not block inbound communications by default. TDF BL consumers are responsible to secure their workloads according to their security criteria.

Network Security Groups (To be updated C2/C3)

TDF BL consumers are free to configure their own set of network rules on their networks using Network Security Groups. TDF BL consumers just have to create the NSG resource and link it to the selected subnet / network interface. Azure Hardened subscription include a set of Azure policies that deny incoming rules using public IPs. Trying to create an incoming rule with public source will be disallowed by policy as illustrated bellow:

There is no restriction on outbound traffic applicable at the Network Security group level.

DNS (To be updated C2/C3)

TDF provide a central DNS infrastructure service that deliver the following services:

• Public DNS name resolution
• Azure public resources managed by the TDF
• Azure Private DNS name resolution
• Azure private resources managed by the TDF
• Thales resources located On-Premises

Access to this service require virtual network to be configured to use this DNS infrastructure and having the virtual network peered with TDF Azure Virtual WAN architecture. Table provide detailed service availability for each Azure Hardened Subscription delivered by the TDF.

Service	C3	C2
Public DNS name resolution	Yes	Yes for peered virtual networks
Azure public resources managed by the TDF	Yes	Yes for peered virtual networks
Azure Private DNS name resolution	Yes	No
Thales resources located On-Premises	Yes	No

On C3 Azure Hardened Subscription, a single Virtual network named tdp-he-vnet and already configured for DNS resolution. On C2 Azure Hardened subscriptions, TDF BL consumer are responsible to setup this configuration by :

• Request Virtual Network peering to the TDF Azure Virtual WAN
• Configuring the IP for DNS on the Virtual Network

Table bellow document Private IP used by TDF DNS infrastructure:

Service	Private IP
Infoblox1	10.201.248.68
Infoblox2	10.201.248.69
SRE DNS infrastructure	10.202.31.28

Public DNS name resolution

DNS infrastructure provided by TDF provides all Internet DNS name resolution. Access to Internet resources rely on the routing information provided by the peering configured on your Virtual Network.

Azure public resources managed by the TDF (C3 only)

DNS infrastructure provided by the TDF provide access to TDF related DNS zones such as thalesdigital.io domain. This domain is managed by TDF. This domain contains a child-domain named ahe (standing for Azure Hardened Environment). ahe.thalesdigital.io domain is managed by TDF.

Every C3 Azure Hardened subscription have a public DNS zone created as child domain of the thalesdigital.io. This public DNS zone is created in the C3 Azure Hardened Subscription provided to the TDF BL consumer and managed by him. In illustration bellow, we have the public DNS zone related to an Azure Hardened subscription. This Azure resource is located in the tdp-he-dns-rg resource group. TDF BL consumers can manage DNS records in this DNS zone.

DNS zone thalesdigital.io public, same for all child-zones. Every DNS record created in your Azure public DNS zone is visible on Internet within a minute as we can see in this illustration from dnschecher.org

Azure public resources managed by the TDF (C2 only)

C2 Azure Hardened subscriptions are not automatically configured with a dedicated Azure public DNS zone. TDF BL consumers can request the TDF to have a subdomain of thalesdigital.io.

Azure Private DNS name resolution (C3 only)

DNS infrastructure provided by the TDF SRE team provide Azure private DNS name resolution. Thales services delegated the tdp.infra.thales private DNS zone to the TDF. Every C3 Azure Hardened Subscription have it's own dedicated private DNS zone named uniquename.ahe.tdp.infra.thales. This Azure resource is in the tdp-he-dns-rg resource group your C3 Azure Hardened subscription. TDF BL consumers can manage DNS records in this private DNS zone as illustrated bellow.

By default your Private DNS zone is using the following format: <subscriptionid>.01.ahe.tdp.infra.thales. You can request a more friendly name, as described here: Get a friendly Private DNS Zone.

Azure Private DNS name resolution (C2 only)

C2 Azure Hardened subscription are not automatically configured with a dedicated Azure private DNS zone. TDF BL consumers can configure the Private DNS zones as they need.

Azure private resources managed by the TDF (C3 only)

Configuring Azure resources to support Azure Private Endpoint require Azure Private DNS zones. DNS infrastructure provided by the SRE team is managing all theses DNS zone for the TDF BL consumer. Because DNS infrastructure is already configured there is no need to create the Azure Private DNS zone as proposed in the Azure portal. In illustration below, we create an Azure SQL database resource configured for Private Endpoint with "Integrate with private DNS zone" option configured to "no". This Azure private DNS zone already exists and is managed by the central DNS infrastructure.

This feature is only available on C3 Azure Hardened Subscriptions. Due to strict network isolation between Azure Azur Hardened subscriptions, Azure resources configured with Private endpoint are not reachable outside the Virtual Network provided with the Azure subscription.

Azure private resources managed by the customer (C2 only)

On C2 Azure Hardened Subscription, TDF BL consumer can configure their Azure resources with Private endpoint but will be responsible to setup their own Azure DNS zones. TDF Central DNS infrastructure cannot manage theses DNS zone on behalf on the consumer.

Thales resources located On-Premises (C3 only)

DNS infrastructure managed by TDF will be providing DNS resolution for Thales resources located On-Premises such as the infra.thales internal domain. This feature is only available on C3 Azure Hardened Subscription, not on C2 Azure Hardened Subscriptions.

---

How to

How to open flows from RIE to my Landing Zone

In order to enable flows from your app in your landing zone to RIE users, you need to follow severals steps :

Use case : my app is accessible from port 443

• Configure the DNS
• Open port 443 on your LZ
• Ask to open flows between Hub Firewall and you LZ

Use case : my app is accessible from another port

• Configure the DNS
• Open port XXX on your LZ
• Ask to open flows between Hub Firewall and you LZ
• Ask to open flows in the Express Route with Process FLORE

How to create new subnets

TDF BL consumers are responsible to create and manage their address space by organizing it into one or more subnets.

1. Locate the tdp-he-vnet virtual network resource located in the tdp-he-vnet-rg resource group
2. Click on "Subnets"
3. Click on +Subnet to add a new subnet
4. Configure a unique subnet name with a subnet address range
5. Click on the Save button

How to disable policies for Private Endpoint

By default, every subnet created in a Virtual Network is configured with the PrivateEndpointNetworkPolicies attribute configured to enabled. Microsoft documentation Disable network policies for private endpoints provide guidance how to reconfigure this attribute for a selected subnet in your Virtual Network.

How to list which ports are open on my landing zone

Search network security groups into Azure portal search bar

![List all NSG](../img/list-nsg-01.png)

Here are all the network security group you created manually or managed by Azure when you create ressource (virtual machine for exemple). A Network security group regroup multiple security groups. To know which port are open on which subnet you just need to open a NSG to see the details

![Get details about your open ports](../img/list-nsg-02.png)

In this screenshot you can see that we have 3 inbound security group and 3 outbound. These rules are apply on the tdp-he-bastion-rg ressources.

• AllowVNetInBound, AllowAzureLoadBalancerInBound and DenyAllInbound are the default Inbound Azure security group
• AllowVnetOutBound, AllowInternetOutBound and DenyAllOutBound are the default Outbound Azure security group

1. All trafic are allowed from this ressource to interne (AllowInternetOutBound)
2. The communication between VNet are allowed in both Inbound and Outbound.
3. Others are deny by default

How to create new network security group and allow, deny ports

TDF BL consumers are responsible to create and manage their network security group into subnet to open, close ports connection to their app into a subnet. Please find here the documentation about network security group policy.

1. Search network security groups into Azure portal search bar
2. Click on "+Create" too add a new network security groups
   1. Subscriptions : your actuel subscriptions
   2. Resource group : the resource group into which one you created your app.
   3. Name: the name of the network security groups
   4. Region : West-Europe
3. Click on review+create
4. Once the resource's deployment is finished, click on go to resource

To allow RIE to access on an app into your subscription expose on port 2345 for example

1. On the right bar, select Inbound security rules to allow to your subnet. (./img/nsg-02.png)
   1. To add a new rule, click on "+Add"
      1. Source : "Ip Adresses"
      2. Source IP addresses/CIDR ranges : 10.59.0.0/16 (Cidr RIE FR)
      3. Source port : "*" or a specified port from source
      4. Destination : Any or an application security group if your app have one
      5. Service: Custom
      6. Destination port ranges : 2345
      7. Protocol : select the right protocol. (currently TCP)
      8. Action : Allow
      9. Priority : 100 (select a right priority, top prio is 0. You can not give the same priority for each rules, we recommand you to gape each rules priority by 100 : 100,200,300, ...)
      10. Name: the name of the rules : allow-port-<source_port> (example : allow-port-2345)
      11. Description : describe the rule

Deleting an access to your LZ

1. On the right bar, Inbound security rules to view all access rules to your subnet. (./img/nsg-02.png)
2. Select the rule you want to delete, example select the rule that allow access with the port 2345 named "allow-port-2345"
3. Click on "Delete"
4. Click on "Yes"

---

FAQ

Can I configure my own address space?

On C3 Azure Hardened Subscriptions, you cannot change address space configured on the tdp-he-vnet Virtual Network, but you can create your own Virtual Network using your own address space. However, your own virtual network will have the following limitations:

• Not possible to peer it with the tdp-he-vnet Virtual Network
• Not possible to access Core services provide by the TDF (GitLabs, ...)
• Not possible to access ExpressRoute circuit provided by the TDF

On C2 Azure Hardened Subscription, TDF BL consumers can:

• Request a non-overlapping address space to the TDF
• Bring their own address space

TDF BL consumers using their own address space for their virtual network won't be able to request peering with the TDF Azure Virtual WAN architecture.

Can I extend the address space of my Virtual Network?

No, this address space is centrally managed at the TDF using an IPAM solution (IP Address Management). Later, TDF will offer Address space extension as a service.

Can I provision a Virtual Network Gateway ?

Provisioning a Virtual Network gateway is not possible on an C3 Azure Hardened Subscription for security considerations. On a C2 Azure Hardened Subscription, deployment can be performed by the TDF BL consumer but peering the virtual network with the TDF Azure Virtual architecture will be rejected.