Partager via

Préparer votre zone d’atterrissage pour la migration

  • Article

Cet article explique comment préparer votre zone d’atterrissage Azure pour une migration. Il répertorie également les principales tâches que vous devez effectuer pour vous assurer que les configurations sont en place pour votre projet de migration.

Quelle que soit l’implémentation de référence de la zone d’atterrissage Azure que vous avez utilisée, vous devez effectuer certaines tâches pour préparer votre zone d’atterrissage en vue d’un projet de migration réussi.

Si vous n’avez pas utilisé d’implémentation de référence de zone d’atterrissage Azure, vous devez toujours effectuer les étapes décrites dans cet article. Toutefois, il se peut que vous deviez d’abord effectuer des tâches préalables ou adapter des recommandations spécifiques à votre conception.

Cet article décrit les tâches que vous devez effectuer pour votre zone d’atterrissage Azure existante après son déploiement. Certaines tâches se concentrent sur les déploiements automatisés. Il est noté si une tâche n’est pas pertinente pour les environnements déployés et gérés manuellement.

Établir la connectivité hybride

Lors d’un déploiement d’une zone d’atterrissage Azure, vous pouvez déployer un abonnement Connecter avec un réseau virtuel hub et des passerelles réseau, telles que des passerelles VPN Azure, des passerelles Azure ExpressRoute, ou les deux. Après le déploiement de votre zone d’atterrissage Azure, vous devez toujours configurer la connectivité hybride à partir de ces passerelles, pour vous connecter à vos appliances de centre de données existantes ou à votre circuit ExpressRoute.

Dans la phase de préparation, vous avez planifié votre connectivité à Azure. Utilisez ce plan pour déterminer les connexions que vous devez incorporer. Par exemple, si vous utilisez ExpressRoute, vous devez travailler avec votre fournisseur pour établir votre circuit ExpressRoute.

Pour obtenir des conseils techniques pour des scénarios spécifiques, consultez :

Remarque

Pour obtenir des conseils supplémentaires, reportez-vous également à la documentation spécifique de votre fournisseur.

Si vous établissez votre connectivité hybride à Azure par le biais d’appliances virtuelles réseau (NVA) tierces déployées dans votre réseau virtuel, passez en revue leurs conseils spécifiques et nos conseils généraux sur les NVA hautement disponibles.

Préparer l’identité

Pendant le déploiement de votre zone d’atterrissage Azure, vous devez également déployer une architecture de prise en charge pour votre plateforme d’identité. Vous pouvez avoir un abonnement d’identité dédié ou des groupes de ressources et un réseau virtuel ou des sous-réseaux pour les ordinateurs virtuels que vous utilisez pour l’identité. Toutefois, vous devez déployer les ressources d’identité après le déploiement de la zone d’atterrissage Azure.

Les sections suivantes fournissent des conseils relatifs à Active Directory. Si vous utilisez un autre fournisseur d’identité pour l’authentification et les autorisations, vous devez suivre ses instructions sur l’extension de votre identité à Azure.

Avant d’implémenter ce conseil, examinez les décisions relatives à Active Directory et aux identités hybrides que vous avez prises lorsque vous avez planifié votre zone d’atterrissage.

Vous devez également passer en revue votre base de référence d’identité de la phase de gouvernance pour déterminer si vous devez faire des changements dans Microsoft Entra ID.

Étendre les contrôleurs de domaine Active Directory

Dans la plupart des scénarios de migration, les charges de travail que vous migrez vers Azure sont déjà jointes à un domaine Active Directory existant. Microsoft Entra ID offre des solutions pour moderniser la gestion des identités, même pour les charges de travail d’ordinateur virtuel, mais cela peut perturber la migration. La réarchitecture de l’utilisation des identités pour les charges de travail est souvent effectuée lors d’initiatives de modernisation ou d’innovation.

Par conséquent, vous devez déployer des contrôleurs de domaine sur Azure à l’intérieur de la zone réseau d’identité que vous avez déployée. Après avoir déployé les ordinateurs virtuels, vous devez suivre votre processus de promotion du contrôleur de domaine normal pour les ajouter au domaine. Ce processus peut inclure la création de sites supplémentaires pour prendre en charge votre topologie de réplication.

Pour un modèle d’architecture commun permettant de déployer ces ressources, consultez Déployer Active Directory Domain Services (AD DS) dans un réseau virtuel Azure.

Si vous implémentez l’architecture à l’échelle de l’entreprise pour les petites entreprises, les serveurs AD DS se trouvent souvent dans un sous-réseau du hub. Si vous implémentez l’architecture réseau en étoile à l’échelle de l’entreprise ou l’architecture Virtual WAN à l’échelle de l’entreprise, les serveurs se trouvent souvent dans leur réseau virtuel dédié.

Microsoft Entra Connect

De nombreuses organisations disposent déjà de Microsoft Entra Connect pour remplir les services Microsoft 365 comme Exchange Online. Si votre organisation ne dispose pas de Microsoft Entra Connecter, vous devrez peut-être l’installer et le déployer après le déploiement de votre zone d’atterrissage afin de pouvoir répliquer les identités.

Activer le DNS hybride

La plupart des organisations doivent être en mesure de résoudre les requêtes DNS (Domain Name System) pour les espaces de noms qui font partie des environnements existants. Ces espaces de noms nécessitent souvent une intégration avec des serveurs Active Directory. En outre, les ressources de l’environnement existant doivent être en mesure de résoudre les ressources dans Azure.

Pour activer ces fonctions, vous devez configurer les services DNS pour prendre en charge les flux courants. Vous pouvez utiliser des zones d’atterrissage Azure pour déployer un grand nombre des ressources dont vous avez besoin. Pour obtenir des tâches supplémentaires à examiner et à préparer, consultez Résolution DNS dans Azure.

Résolution de DNS personnalisée

Si vous utilisez Active Directory pour votre programme de résolution DNS ou si vous déployez une solution tierce, vous devez déployer des ordinateurs virtuels. Vous pouvez utiliser ces ordinateurs virtuels en tant que serveurs DNS si vos contrôleurs de domaine sont déjà déployés sur votre abonnement d’identité et votre spoke de réseau. Sinon, vous devez déployer et configurer les ordinateurs virtuels pour héberger ces services.

Après avoir déployé les ordinateurs virtuels, vous devez les intégrer à votre plateforme DNS existante afin qu’ils puissent effectuer des recherches sur vos espaces de noms existants. Pour les serveurs DNS Active Directory, cette intégration est automatique.

Vous pouvez également utiliser Azure DNS Private Resolver, mais ce service n’est pas déployé dans le cadre de votre déploiement de zone d’atterrissage Azure.

Si votre conception utilise des zones DNS privées, planifiez en conséquence. Par exemple, si vous utilisez des zones DNS privées avec des points de terminaison privés, consultez Spécifier des serveurs DNS. Les zones DNS privées sont déployées dans le cadre de votre zone d’atterrissage. Si vous utilisez également des points de terminaison privés pour effectuer des efforts de modernisation, vous devez disposer d’une configuration supplémentaire pour ceux-ci.

Proxy DNS du Pare-feu Azure

Vous pouvez configurer le Pare-feu Azure en tant que proxy DNS. Le pare-feu Azure peut recevoir du trafic et le transmettre à un programme de résolution Azure ou à vos serveurs DNS. Cette configuration permet d’effectuer des recherches depuis des sites vers Azure, mais elles ne peuvent pas être renvoyées de manière conditionnelle vers des serveurs DNS locaux.

Si vous avez besoin d’une résolution DNS, vous pouvez configurer le proxy DNS du pare-feu Azure pour qu’il transfère le trafic à vos serveurs DNS personnalisés (tels que vos contrôleurs de domaine).

Cette étape est facultative, mais elle présente plusieurs avantages. Cela réduit les modifications de configuration ultérieures si vous modifiez les services DNS et active les règles de nom de domaine complet (FQDN) dans le Pare-feu Azure.

Configurer les serveurs DNS du réseau virtuel personnalisés

Après avoir effectué les activités précédentes, vous pouvez configurer les serveurs DNS de vos réseaux virtuels Azure sur les serveurs personnalisés que vous utilisez.

Pour plus d’informations, consultez Paramètres DNS du Pare-feu Azure.

Configurer le pare-feu du hub

Si vous avez déployé un pare-feu dans votre réseau hub, vous devez prendre en compte quelques considérations pour être prêt à migrer des charges de travail. Si vous ne tenez pas compte de ces considérations au début de votre déploiement, vous risquez de rencontrer des problèmes de routage et d’accès réseau.

Dans le cadre de ces activités, passez en revue la zone de conception réseau, en particulier les conseils sur la sécurité réseau.

Si vous déployez une appliance virtuelle réseau (NVA) tierce en tant que pare-feu, examinez les conseils du fournisseur et nos conseils généraux sur les NVA hautement disponibles.

Déployer des ensembles de règles standard

Si vous utilisez un Pare-feu Azure, tout le trafic de pare-feu est bloqué jusqu’à ce que vous ajoutiez des règles d’autorisation explicites. De nombreux autres pare-feu NVA fonctionnent de la même façon. Le trafic est refusé jusqu’à ce que vous définissiez des règles qui spécifient le trafic autorisé.

Vous devez ajouter des règles individuelles et des regroupements de règles en fonction des besoins de charge de travail. Mais vous devez également prévoir des règles standard, telles que l’accès à Active Directory ou à d’autres solutions de gestion et d’identité, qui s’appliquent à toutes les charges de travail activées.

Routage

Azure fournit le routage pour les scénarios suivants sans configuration supplémentaire :

  • Routage entre les ressources du même réseau virtuel
  • Routage entre les ressources de réseaux virtuels appairés
  • Routage entre des ressources et une passerelle de réseau virtuel, soit dans son propre réseau virtuel, soit dans un réseau virtuel appairé configuré pour utiliser la passerelle.

Deux scénarios de routage courants nécessitent une configuration supplémentaire. Dans les deux cas, des tables de routage sont attribuées aux sous-réseaux pour structurer le routage. Pour plus d’informations sur le routage Azure et sur les routes personnalisées, consultez Routage du trafic de réseau virtuel.

Routage inter-spokes

Pour la zone de conception de réseau, de nombreuses organisations utilisent une topologie réseau hub-and-spoke.

Vous avez besoin d’itinéraires qui transfèrent le trafic d’un spoke à un autre. Pour plus d’efficacité et de simplicité, utilisez l’itinéraire par défaut (0.0.0.0/0) vers votre pare-feu. Une fois cet itinéraire en place, le trafic vers un emplacement inconnu se dirige vers le pare-feu, qui l’inspecte et applique vos règles de pare-feu.

Si vous souhaitez autoriser la sortie d’Internet, vous pouvez également affecter un autre itinéraire pour votre espace IP privé au pare-feu, par exemple 10.0.0.0/8. Cette configuration ne remplace pas les itinéraires plus spécifiques. Mais vous pouvez l’utiliser comme un itinéraire simple afin que le trafic entre spokes puisse correctement acheminer.

Pour plus d’informations sur la mise en réseau spoke-to-spoke, consultez Modèles et topologies pour la communication inter-spokes.

Routage à partir du sous-réseau de passerelle

Si vous utilisez des réseaux virtuels pour votre hub, vous devez prévoir comment gérer l’inspection du trafic provenant de vos passerelles.

Si vous envisagez d’inspecter le trafic, vous avez besoin de deux configurations :

  • Dans votre abonnement de connectivité, vous devez créer une table de routage et la lier au sous-réseau de passerelle. Le sous-réseau de passerelle a besoin d’un itinéraire pour chaque réseau spoke que vous envisagez d’attacher, avec un tronçon suivant de l’adresse IP de votre pare-feu.

  • Dans chacun de vos abonnements de zone d’atterrissage, vous devez créer une table de routage et la lier à chaque sous-réseau. Désactiver la propagation de BGP (Border Gateway Protocol) sur les tables de routage.

Pour plus d’informations sur les itinéraires personnalisés et définis par Azure, consultez Routage du trafic de réseau virtuel Azure

Si vous envisagez d’inspecter le trafic vers des points de terminaison privés, activez la stratégie réseau de routage appropriée sur le sous-réseau où les points de terminaison privés sont hébergés. Pour en savoir plus, consultez Gestion des stratégies réseau pour les points de terminaison privés.

Si vous n’avez pas l’intention d’inspecter le trafic, aucune modification n’est nécessaire. Toutefois, si vous ajoutez des tables de routage à vos sous-réseaux de réseau spoke, activez la propagation BGP afin que le trafic puisse effectuer le routage vers votre passerelle.

Configurer la surveillance et la gestion

Dans le cadre du déploiement de votre zone d’atterrissage, vous aurez provisionné des stratégies qui inscrivent vos ressources dans Journaux Azure Monitor. Toutefois, vous devez également créer des alertes pour vos ressources de zone d’atterrissage.

Pour implémenter des alertes, vous pouvez déployer la base de référence Azure Monitor pour les zones d’atterrissage. Utilisez ce déploiement pour obtenir des alertes basées sur des scénarios courants de gestion des zones d’atterrissage, tels que les ressources de connectivité et l’intégrité du service.

Vous pouvez également déployer votre propre alerte personnalisée pour les ressources si vos besoins diffèrent de ce qui se trouve dans la base de référence.

Préparez votre zone d’atterrissage pour les migrations de charges de travail souveraines

Si vous devez répondre aux exigences de souveraineté, vous pouvez évaluer si Microsoft Cloud for Sovereignty répond à vos besoins. Microsoft Cloud for Sovereignty fournit une couche supplémentaire de capacités de stratégie et d’audit qui répondent aux besoins individuels du secteur public et des gouvernements.

Vous pouvez activer ces fonctionnalités en déployant la zone d’atterrissage souveraine. L’architecture de la zone d’atterrissage souveraine s’aligne sur les conceptions recommandées pour les zones d’atterrissage Azure.

Portefeuille de la stratégie Microsoft Cloud for Sovereignty

L’utilisation de la stratégie Azure permet de centraliser le contrôle des ressources Azure afin de mettre en œuvre des configurations spécifiques. Vous pouvez attribuer les initiatives de stratégie Microsoft Cloud for Sovereignty à vos zones d’atterrissage pour vous assurer que vous respectez les stratégies locales et les exigences réglementaires dans votre pays/région.

Si ces initiatives de stratégie ne sont pas encore attribuées à votre déploiement de zone d’atterrissage souveraine, envisagez d’attribuer les initiatives correspondant à vos exigences réglementaires.

Activer le distributeur d’abonnements

Cette section s’applique aux organisations qui souhaitent automatiser leur processus d’approvisionnement d’abonnement. Si vous gérez manuellement votre zone d’atterrissage et la création de votre abonnement, vous devez établir votre propre processus de création d’abonnements.

Lorsque vous commencez la migration, vous devez créer des abonnements pour vos charges de travail. Activez le distributeur d’abonnements pour automatiser et accélérer ce processus. Lorsque le distributeur d’abonnements est établi, vous devez être en mesure de créer des abonnements rapidement.

Se préparer à Microsoft Defender pour le cloud

Lorsque vous déployez votre zone d’atterrissage, vous définissez également des stratégies pour activer Defender pour le cloud pour vos abonnements Azure. Defender pour le cloud fournit des recommandations sur l’état de la sécurité via son niveau de sécurité, qui évalue les ressources déployées par rapport à la base de référence de sécurité de Microsoft.

Vous n’avez pas besoin d’implémenter des configurations techniques supplémentaires, vous devez passer en revue les recommandations et concevoir un plan pour améliorer état de la sécurité à mesure que vous migrez des ressources. Lorsque vous avez commencé la migration des ressources vers Azure, vous devez être prêt à implémenter des améliorations de la sécurité dans le cadre de l’optimisation de votre migration.

Tenez compte de ces ressources supplémentaires à préparer pour la migration :

Étapes suivantes

Préparer des outils et un backlog de migration initial