Transition d’un environnement Azure existant vers l’architecture de référence de la zone d’atterrissage Azure

De nombreuses organisations ont une empreinte Azure existante, un ou plusieurs abonnements et potentiellement une structure de groupe d’administration existante. Selon leurs besoins et scénarios métier, ils peuvent avoir des ressources Azure déployées, telles que la passerelle VPN Azure ou Azure ExpressRoute pour la connectivité hybride.

Cet article fournit des recommandations pour aider votre organisation à parcourir les modifications en fonction de votre environnement Azure existant qui passe à l’architecture de référence de la zone d’atterrissage Azure. Cet article décrit également les considérations relatives au déplacement de ressources dans Azure, par exemple le déplacement d’un abonnement d’un groupe d’administration existant vers un autre groupe d’administration. Tenez compte de ces recommandations pour vous aider à évaluer et à planifier la transition de votre environnement Azure existant.

Déplacer des ressources dans Azure

Vous pouvez déplacer certaines ressources dans Azure après la création. Il existe différentes approches qui sont soumises aux permissions de contrôle d'accès basées sur les rôles (RBAC) d'un utilisateur à travers différents niveaux d'étendue. Le tableau suivant décrit les ressources que vous pouvez déplacer, à quelle étendue, ainsi que les avantages et inconvénients associés à chaque ressource.

Pour déterminer la stratégie de déplacement que vous devez utiliser, tenez compte des exemples suivants.

Déplacer des abonnements

En règle générale, vous déplacez des abonnements pour les organiser en groupes d’administration ou pour transférer des abonnements vers un nouveau locataire Microsoft Entra ID. Le déplacement d’un abonnement vers un nouveau locataire consiste principalement à transférer la propriété de facturation. Pour plus d’informations sur le déplacement d’abonnements entre des groupes d’administration dans le même locataire, consultez Déplacement de groupes d’administration et d’abonnements.

Configuration requise pour Azure RBAC

Pour évaluer un abonnement avant un déplacement, il est important que l’utilisateur dispose du RBAC Azure approprié. L’utilisateur peut être propriétaire de l’abonnement (attribution de rôle directe) et disposer d’une autorisation d’écriture sur le groupe d’administration cible. Les rôles intégrés permettant l’autorisation d’écriture sur le groupe de gestion cible sont le rôle propriétaire, le rôle contributeur et le rôle contributeur du groupe de gestion.

Si l’utilisateur dispose d’une autorisation de rôle de propriétaire héritée sur l’abonnement à partir d’un groupe d’administration existant, vous pouvez uniquement déplacer l’abonnement vers le groupe d’administration dans lequel l’utilisateur reçoit le rôle de propriétaire.

Policies

Les abonnements existants peuvent être soumis à des stratégies Azure affectées directement ou affectées au groupe d’administration où ils se trouvent actuellement. Il est important d’évaluer les stratégies actuelles et les stratégies qui peuvent exister dans le nouveau groupe d’administration ou la hiérarchie des groupes d’administration.

Vous pouvez utiliser Azure Resource Graph pour effectuer un inventaire des ressources existantes et comparer leur configuration aux stratégies qui existent à la destination.

Après avoir déplacé des abonnements vers un groupe d’administration avec le RBAC Azure existant et les stratégies en place, tenez compte des facteurs suivants :

• Pour tout RBAC Azure hérité vers les abonnements déplacés, les jetons utilisateur dans le cache de groupe d’administration peuvent prendre jusqu’à 30 minutes pour s’actualiser. Pour accélérer ce processus, vous pouvez actualiser le jeton en vous déconnectant puis en vous reconnectant, ou demander un nouveau jeton.

• Une stratégie dans laquelle l’étendue d’affectation inclut les abonnements déplacés effectue un audit uniquement sur les ressources existantes. Une ressource existante dans l'abonnement qui est soumise à un :

  • DeployIfNotExists l’effet de la politique apparaît comme non conforme et n’est pas corrigé automatiquement. Un utilisateur doit effectuer manuellement la correction.

  • Deny l’effet de la politique est signalé comme non conforme et n’est pas rejeté. Un utilisateur doit atténuer manuellement ce résultat selon les besoins.

  • Append et Modify l’effet de stratégie apparaît comme non conforme et nécessite qu’un utilisateur atténue.

  • Audit et AuditIfNotExist l’effet de stratégie apparaît comme non conforme et nécessite qu’un utilisateur atténue.

• Toutes les nouvelles écritures dans les ressources de l’abonnement déplacé sont soumises aux stratégies affectées en temps réel, comme normale.

Déplacer des ressources

En règle générale, vous déplacez des ressources lorsque vous souhaitez consolider des ressources dans le même groupe de ressources s’ils partagent le même cycle de vie. Ou si vous souhaitez déplacer des ressources vers un autre abonnement en raison des exigences en matière de coût, de propriété ou de RBAC Azure.

Lorsque vous déplacez des ressources, le groupe de ressources source et le groupe de ressources cible sont verrouillés pendant l’opération de déplacement. Vous ne pouvez pas ajouter, mettre à jour ou supprimer des ressources dans les groupes de ressources. Une opération de déplacement de ressources ne modifie pas l’emplacement des ressources.

Pour plus d’informations sur la façon de déplacer des ressources entre des groupes de ressources et des abonnements dans le même locataire, consultez Déplacer des ressources vers un nouveau groupe de ressources ou un nouvel abonnement.

Avant de déplacer des ressources

Avant une opération de déplacement, vous devez vérifier que les ressources sont prises en charge et évaluer leurs exigences et leurs dépendances. Par exemple, lorsque vous déplacez un réseau virtuel appairé, vous devez d'abord désactiver l'appairage du réseau virtuel, puis le réactiver une fois que l'opération de déplacement est terminée. Planifiez à l’avance la dépendance de désactivation et de réactivation afin de comprendre l’effet sur les charges de travail existantes susceptibles d’être connectées à vos réseaux virtuels.

Après avoir déplacé des ressources

Lorsque vous déplacez les ressources dans un nouveau groupe de ressources dans le même abonnement, le RBAC Azure et les stratégies hérités du groupe d’administration ou de l’abonnement s’appliquent toujours. Cela s’applique également si vous passez à un groupe de ressources dans un nouvel abonnement où l’abonnement peut être soumis à d’autres attributions de RBAC et de stratégie Azure. Vous devez valider la conformité des ressources et les contrôles d’accès.

Scénarios

Les scénarios suivants décrivent comment migrer et transformer un environnement existant vers l’architecture de référence de la zone d’accueil Azure.

• Scénarios d’alignement

  • Transition d’un abonnement unique sans groupes d’administration vers l’architecture de référence de la zone d’atterrissage Azure
  • Transition des groupes d’administration vers l’architecture de référence de la zone d’atterrissage Azure
  • Transition d’une organisation régionale vers l’architecture de référence de la zone d’atterrissage Azure

• Approches d’alignement

  • Transition d’un environnement en dupliquant un groupe d’administration de zone d’atterrissage (recommandé)