Le réseau

Introduction

Le réseau virtuel est dans la grande majorité des cas la première ressource créée sur Azure si l’on exclut le groupe de ressources présenté dans le chapitre Concepts de base. Pour rappel, un groupe de ressources n’est pas à proprement parler une ressource mais plutôt un conteneur de ressources. Il n’est pas possible de créer une ressource sans cet élément.

Le réseau Azure est un terme générique et adresse bien plus qu’un réseau virtuel. Pour ce livre, l’auteur a choisi de parler des composants les plus utilisés, de les présenter en détail et de cibler uniquement ce qui va être utilisé dans le réseau Azure. En voici la liste :

Liaison entre le centre de données local et Azure

Dans une utilisation classique d’un fournisseur de cloud, le centre de données de l’entreprise est relié de manière privée avec son centre de données cloud Azure. On parle d’interconnectivité. Interconnecter son datacenter, ce n’est pas seulement créer une connexion entre son site On-premises et son environnement Azure. On peut aussi interconnecter Azure avec d’autres fournisseurs de cloud comme Google ou AWS si ce sont des fournisseurs de cloud utilisés par l’entreprise. Ce point spécifique de l’interconnexion entre les fournisseurs de cloud n’est pas traité dans le livre.

Tous ces sites peuvent être interconnectés et, pour Azure, cette privatisation de l’accès est possible de plusieurs manières, par trois types de connexion :

Il faut voir ces services comme le lien, le « tuyau » qui unit le réseau du centre de données local au centre de données Azure. Ce service est attaché à des passerelles qui sont un point d’entrée/sortie pour le réseau sur les deux centres de données. C’est en fait un lien sécurisé entre...

VNet

Le VNet (réseau virtuel ou Virtual Network) est l’équivalent du réseau local comme on le retrouve sur un centre de données. Il est complètement isolé du réseau virtuel existant pour les autres clients Azure. Les plages d’adresses IP à utiliser doivent être conformes à la RFC1918 (Requests For Comments), c’est-à-dire les adresses privées suivantes :

Sur ces plages, toutes les adresses ne sont pas disponibles. On retrouve les restrictions classiques pour les adresses 0 (adresse du réseau) et 255 (adresse de diffusion réseau), mais également des restrictions propres à Azure :

Il faut prendre cette contrainte en compte lorsque les VNet sont de très petite taille et ne pas oublier que les premières adresses sont réservées. Ainsi, sur un CIDR en /29, il ne reste que trois IP disponibles.

Les sous-réseaux

Les sous-réseaux ou subnet sont une découpe des réseaux virtuels présentés ci-dessus. Ce sont des espaces dédiés dans la portée du réseau VNet.

Le sous-réseau est obligatoire. Comme présenté dans les exercices à venir, il n’est pas possible de valider la création d’un réseau sans créer un sous-réseau dans ce réseau. Même si un sous-réseau appelé default est créé en /24, si l’administrateur n’effectue pas explicitement l’opération, il est préférable de supprimer ce sous-réseau et de créer ses propres sous-réseaux avec des plages IP adaptées et une bonne convention de nommage.

De même, une ressource Azure qui doit avoir des accès réseau est attachée à un sous-réseau, il n’est pas possible de l’attacher directement au réseau. Le sous-réseau est donc un composant enfant du réseau virtuel. Au-delà de cette obligation, un réseau sans sous-réseau n’a pas de sens.

La découpe offre des possibilités fines et granulaires, par exemple la liaison d’un groupe de sécurité (NSG) à un sous-réseau (voir section suivante). Comme pour les VNet, il est important de prévoir et de documenter...

NSG

Les NSG (Network Security Group ou groupe de sécurité réseau) sont des groupes de règles de filtrage pour les accès au réseau. Ils contrôlent les accès entrants et sortants pour les ressources et ce, même à l’intérieur d’une même VNet puisque, par défaut, et comme déjà expliqué, toutes les ressources d’un même VNet communiquent entre elles. Seuls les NSG peuvent contrôler ce filtrage.

Lorsque l’on contrôle finement les flux à l’aide des NSG, on parle de micro-segmentation des réseaux. Une règle est une combinaison port + protocole + source + destination + sens + action (autoriser/interdire) + priorité. À noter également que des règles par défaut sont attachées au sous-réseau à sa création.

Équilibreur de charge

Le dernier élément réseau présenté dans le chapitre est l’équilibreur de charge ou load balancer. L’équilibreur de charge est une ressource qui va répartir la charge entre plusieurs ressources.

Elle est exposée en externe au travers d’une adresse IP publique ou en interne entre les différentes couches d’une application ; typiquement, entre la partie web d’une application exposée en externe et la partie données de cette même application exposée à la partie web en interne.

Voici ci-dessous un modèle simple d’utilisation qui facilite la compréhension. Ce schéma de base peut être porté et complété d’autres ressources pour devenir plus performant et plus résilient. C’est donc un modèle plus pédagogique que technique. Il représente toute la mécanique de l’équilibreur de charge. Ici, ce sont des machines virtuelles, donc des ressources IaaS. Ce modèle est aussi valable pour des services managés PaaS.

Équilibreur public externe et équilibreur interne

Dans ce schéma de principe, c’est l’équilibreur de charge Azure Équilibrage de charge qui est illustré. La création d’un équilibreur de charge nécessite de nombreux paramètres. C’est un composant très technique qui ne fait pas simplement de la répartition de trafic entre des points de terminaison ; il va beaucoup plus loin.

Il ne faut pas voir l’équilibreur comme un composant autonome mais plutôt comme une partie d’un ensemble de ressources et services qui doivent être assemblés pour fonctionner.

Plus schématiquement :

Exercices

Les exercices suivants reprennent des points théoriques présentés plus haut dans ce chapitre en ajoutant quelques nouvelles notions. Du réseau virtuel aux groupes de sécurité réseau, tous ces exercices sont très liés. Il ne faut pas hésiter à revenir sur les points dédiés dans le chapitre pour bien comprendre ce qui est mis en œuvre ici.

Dans ce premier exercice, un Application Security Group est créé. Avant de préparer des groupes de sécurité réseau, il faut préparer les éléments sur lesquels sont positionnées les règles.

Le groupe de sécurité d’application est créé, il n’est pas utilisable depuis ce menu. C’est un conteneur qui est mis à disposition des ressources réseau et qui s’utilise depuis le menu de ces ressources.

Dans l’exemple suivant, dans le menu Mise en réseau d’une machine virtuelle, puis dans l’onglet Groupe de sécurité d’application, on trouve une option Configurer les groupes de sécurité d’application.

Le menu Mise en réseau d’une...

Filtrage de l’exposition des services PaaS

Par défaut, les services de plateforme Azure (PaaS) sont exposés sur Internet. Ils ont un point de terminaison HTTPS. Voici un exemple avec le compte de stockage qui sera créé dans le chapitre Le stockage : https://stdemoazureexplorer01.file.core.windows.net/

Exposé sur Internet ne veut pas dire (facilement) accessible, mais il s’agit malgré tout d’une exposition publique. C’est-à-dire exposé à d’éventuelles attaques, donc présentant un risque de sécurité. Heureusement, dans leur très grande majorité, les services PaaS (Platform as a Service) peuvent être filtrés au niveau de leur accès réseau, de différentes manières. Le filtrage est un élément fondamental ; c’est un sujet majeur que le lecteur doit complètement maîtriser avant de se lancer sur Azure.

Les différentes méthodes de filtrage sont présentées dans la suite de ce chapitre.

Services DNS Azure

DNS (Domain Name System) est le système qui traduit les noms de domaine en adresses IP. Il est plus simple de retenir une adresse de site web que les adresses IP qui permettent de s’y connecter. Utiliser le DNS sur Azure, c’est le faire pour résoudre des enregistrements internes Azure et des enregistrements Internet pour des environnements Azure uniquement. Si l’entreprise doit résoudre des enregistrements locaux, c’est-à-dire Azure vers le site On-premises et le site On-premises sur Azure, on parle de résolution hybride.

Il y a plusieurs services DNS sur Azure ; ils demandent une bonne compréhension pour faire le bon choix. Ce choix dépendra du mode de résolution attendu, uniquement sur Azure ou hybride, mais aussi de l’intégration de contrôleurs de domaines sur Azure pour étendre le domaine Active Directory dans le cloud. C’est un choix structurant qui va profondément modifier la solution DNS à mettre en place. Avant de parler des différents scénarios, une présentation des trois services utilisés plus un service complémentaire (programmes de résolution privés DNS) qui peut remplacer le déploiement des contrôleurs de domaines sur le cloud.

Exercices

Dans cet exercice, le lecteur va déployer une Zone DNS publique. Il n’est pas possible d’aller au bout de l’exercice, les informations générées par la création du DNS sont à enregistrer chez un registrar. Mais il est important de créer une Zone DNS à blanc pour mieux réaliser au moins une fois cet exercice.

Information pour les serveurs de noms