Partager via


Migrer d’Azure Sphere (hérité) vers Azure Sphere (intégré)

Le 27 septembre 2027, Azure Sphere met hors service ses interfaces de service héritées, l’API Azure Sphere (héritée) (également appelée PAPI) et l’interface CLI Azure Sphere (également appelée azsphere). Tous les utilisateurs Azure Sphere (hérités) doivent migrer vers Azure Sphere (intégré) avant cette date. Azure Sphere (intégré) est natif de la plateforme Azure et fournit un remplacement semblable à celui de l’interface Azure Sphere (héritée). Azure Sphere (intégré) offre également des améliorations significatives de la sécurité (intégration RBAC Azure), de la facilité d’utilisation (intégration du portail Azure) et de l’observabilité/alerte (intégration d’Azure Monitor). Pour plus d’informations, voir ce blog.

Cet article est conçu pour aider les administrateurs et les équipes d’ingénierie Azure Sphere à comprendre et planifier la migration. Nous avons conçu le processus de migration pour vous permettre de gérer vos appareils Azure Sphere dans Azure Sphere (intégré) et Azure Sphere (hérité) en fonction des besoins tout au long du projet de migration. En outre, vos scripts, automatisation et interfaces hérités peuvent fonctionner sans interruption pendant que votre équipe d’ingénierie génère et teste des versions mises à jour basées sur Azure Sphere (intégré).

Diagramme montrant le flux de travail de migration de haut niveau

Le processus de migration peut être divisé en domaines de travail suivants :

  • Intégration du locataire hérité dans un catalogue Azure Sphere dans Portail Azure
  • Migration de flux de travail utilisateur interactifs
  • Migration de processus et d’interfaces automatisés

Intégration de votre locataire Azure Sphere (hérité) à un catalogue Azure Sphere

Cette première étape du processus de migration doit être effectuée avant que tout autre travail puisse commencer. La fonctionnalité Intégrer dans Portail Azure prépare votre locataire Azure Sphere (hérité) à gérer dans l’environnement Azure où il devient un catalogue Azure Sphere. Le locataire et ses ressources restent identiques à l’exception que vous pouvez désormais accéder et gérer via les interfaces utilisateur d’Azure, notamment les Portail Azure, l’extension Azure Sphere pour Azure CLI et Azure Sphere pour PowerShell.

Diagramme montrant l’écran Intégration d’Azure Sphere

Le processus d’intégration effectue deux étapes :

  1. Il affecte un ID de ressource Azure à chaque ressource du locataire, ce qui permet à la ressource d’être gérée par Azure Resource Manager.
  2. Il mappe les rôles d’accès utilisateur de locataire hérités aux rôles d’accès utilisateur gérés par le contrôle d’accès en fonction des rôles Azure (RBAC). Lorsque les mappages de rôles d’accès suggérés sont affichés pendant le processus d’intégration, vous pouvez les accepter, les modifier ou les rejeter. Une fois l’étape d’intégration terminée, vous pouvez modifier l’accès utilisateur à tout moment.

En règle générale, l’étape d’intégration ne prend que quelques minutes, et une fois l’accès terminé, tout utilisateur qui a été accordé pendant l’intégration peut immédiatement commencer à gérer le nouveau catalogue Azure Sphere dans l’une des interfaces utilisateur d’Azure. Aucun flux de travail existant n’est bloqué par le processus d’intégration, et nous vous recommandons de le faire bientôt afin de commencer à explorer les nouvelles interfaces et avantages Azure Sphere (intégré). Une fois l’opération terminée, vous pouvez commencer le reste de votre travail de migration.

Migration de flux de travail utilisateur interactifs

Les flux de travail interactifs sont ceux où un individu utilise l’interface CLI « azsphere » (ou utilise un script qui utilise à son tour l’interface CLI « azsphere ») pour effectuer une tâche. Ces flux de travail interactifs peuvent se produire dans le cadre de la fabrication (par exemple, la revendication de nouveaux appareils dans votre locataire), les opérations (par exemple, la gestion des certificats liés à votre locataire) ou les cas d’usage des développeurs (par exemple, la configuration d’un appareil développeur pour ne pas recevoir de mises à jour à l’air excessive).

Lors de la planification de la migration de vos flux de travail, vous devez envisager d’entraîner les utilisateurs, de mettre à jour la documentation interne et, dans les cas où des scripts sont utilisés de manière interactive, en mettant à jour ces scripts. Vous pouvez également envisager de tirer parti de deux améliorations clés dans Azure Sphere (intégré) : l’interface simplifiée d’Azure Sphere dans Portail Azure et la gestion robuste de l’accès utilisateur d’Azure dans le contrôle d’accès en fonction du rôle (RBAC) Azure.

Il est important de déterminer si un flux de travail utilisateur particulier est mieux accompli dans une interface web plutôt qu’une interface CLI. Azure Sphere (intégré) vous permet de gérer le catalogue dans le portail Azure et, pour de nombreux flux de travail d’utilisateurs interactifs, le portail offre une expérience utilisateur plus riche et plus simple. Par exemple, dans Portail Azure vous pouvez charger et déployer simultanément des images en une seule étape, comme indiqué ci-dessous.

Diagramme montrant l’écran Ajouter des images Azure Sphere

Ensuite, réfléchissez à la façon dont vous pouvez restreindre l’accès utilisateur plus efficacement. Azure Sphere (intégré) prend en charge le contrôle d’accès en fonction du rôle Azure (RBAC) qui permet un accès utilisateur beaucoup plus robuste et affiné qu’Azure Sphere (hérité).

Diagramme montrant l’écran de configuration RBAC Azure

Il s’agit d’un modèle d’autorisations minimales conçu pour accorder à un utilisateur individuel l’accès uniquement à ces ressources requises pour son travail, ainsi que l’autorisation d’effectuer uniquement les actions de l’utilisateur nécessaires pour son travail. Par exemple, dans un catalogue Azure Sphere, vous pouvez autoriser un utilisateur à afficher le groupe d’appareils de production et à créer de nouveaux déploiements dans ce groupe d’appareils, mais en particulier les empêcher de déplacer des appareils vers et hors du groupe d’appareils, ou d’afficher d’autres groupes d’appareils dans le catalogue.

Si vous n’avez pas déjà utilisé Azure RBAC, nous vous recommandons d’en savoir plus sur les concepts RBAC Azure de base tels que l’étendue et la hiérarchie des ressources, car ils sont essentiels pour comprendre les impacts de l’application d’une autorisation de rôle RBAC spécifique à un catalogue plutôt qu’à la ressource enfant d’un catalogue comme un groupe d’appareils.

Pour vous aider, nous avons fourni un exemple de configuration RBAC pour plusieurs utilisateurs professionnels qui illustrent certaines bonnes pratiques pour RBAC pour Azure Sphere. L’exemple met en évidence les autorisations adaptées aux besoins courants des utilisateurs professionnels, notamment les ingénieurs logiciels produisant des applications pour les appareils Azure Sphere, les techniciens OT gérant les flottes d’appareils Azure Sphere de production et les fabricants qui créent des appareils Azure Sphere.

Suppression de l’accès utilisateur au locataire Azure Sphere (hérité)

Une fois qu’un flux de travail est migré et que vos utilisateurs utilisent Azure Sphere (intégré) à temps plein, nous vous recommandons vivement de supprimer les autorisations de chaque utilisateur du locataire hérité pour éliminer l’accès involontaire. Dans le cas contraire, un utilisateur peut contourner les contrôles d’accès affinés que vous avez configurés dans Azure RBAC en continuant à utiliser Legacy. La suppression de l’accès utilisateur hérité vous aidera également à vous assurer que ces utilisateurs peuvent effectuer correctement toutes leurs tâches requises dans Azure Sphere (intégré) et ne seront pas affectés par la mise hors service héritée.

Les utilisateurs travaillant sur la conversion ou le test de processus automatisés peuvent avoir besoin de conserver leurs privilèges d’accès de locataire hérités pendant une période plus longue.

Migration de processus et d’interfaces automatisés

En plus de migrer des flux de travail interactifs, si votre organisation a créé des processus automatisés qui utilisent des scripts Azure Sphere (hérités) ou des interfaces utilisateur basées sur l’API Azure Sphere (héritée), vous devez les retravailler pour utiliser Azure Sphere (intégré). Pour faciliter le processus de migration, vous pouvez développer et tester activement l’automatisation mise à jour pendant que votre automatisation héritée de production s’exécute sans interruption. Les soins sont nécessaires lors du test des commandes qui ne peuvent pas être inversées, telles que la revendication d’un appareil dans un catalogue où vous ne souhaitez pas qu’il réside à long terme.

Pour chaque interface que vous générez sur l’API Azure Sphere (intégrée), vous devez créer un jeton d’accès Microsoft Entra qui permettra à l’interface d’accéder au point de terminaison de l’API. Pour plus d’informations sur les jetons d’accès et l’appel des API REST Azure, reportez-vous à la documentation de référence de l’API REST Azure.

Après avoir déployé les processus et interfaces automatisés mis à jour en production, vous devez supprimer l’accès Azure Sphere (hérité) pour les principaux de service utilisés pour authentifier votre ancienne automatisation et interfaces héritées. La suppression de l’accès à tous les principaux de service garantit que tous vos processus automatisés sont entièrement migrés et ne seront pas affectés par la mise hors service héritée.

Arrêt de l’accès restant au locataire hérité

La dernière étape du processus de migration consiste à supprimer tout accès Azure Sphere restant (hérité). Aujourd’hui, les locataires Azure Sphere (hérités) nécessitent au moins un compte d’administrateur hérité actif, même si le locataire a été intégré à Portail Azure. Nous travaillons sur une fonctionnalité qui vous permettra de supprimer ce dernier compte d’administrateur de locataire hérité, mais il n’est pas disponible pour l’instant. Lors de la publication de cette fonctionnalité, nous annoncerons sa disponibilité sur Azure Update.

Tirer parti des fonctionnalités disponibles dans Azure Sphere (intégré)

Bien qu’il n’soit pas nécessaire d’utiliser Azure Sphere (intégré), nous vous recommandons vivement d’explorer et de tirer parti des autres services Azure puissants disponibles pour Azure Sphere.

L’un des plus puissants est Azure Monitor. Azure Monitor offre une variété de fonctionnalités de surveillance de flotte, telles que la collecte de métriques de performances et de données de diagnostic, et l’interrogation d’événements dans les journaux d’activité des appareils Azure Sphere et du service de sécurité Azure Sphere.

Diagramme montrant l’écran Azure Monitor

À l’aide des données Azure Monitor, vous pouvez mettre en corrélation l’intégrité de la flotte d’appareils avec les événements qui se produisent sur le service de sécurité Azure Sphere, comme la publication d’une nouvelle mise à jour d’application. Vous pouvez également configurer des alertes sur les événements critiques, tels que l’expiration à venir de votre certificat de locataire Azure Sphere. Pour plus d’informations, consultez Surveillance de la flotte Azure Sphere et de l’intégrité des appareils.

Prise en main et recherche d’aide

Il est facile de commencer simplement en intégrant votre azure Sphere (hérité) dans un catalogue Azure Sphere (intégré) et en commençant à explorer l’utilisation d’Azure Sphere dans Azure CLI ou le portail Azure. Azure Sphere (hérité) est entièrement pris en charge jusqu’à la date de mise hors service du 27 septembre 2027. Toutes les activités de migration doivent être effectuées à cette date. Si vous avez des questions sur la migration ou avez besoin d’assistance technique, vous pouvez trouver des réponses d’experts de la communauté sur microsoft Q&A, ou vous pouvez contacter AZSPPGSUP@microsoft.com.