Éléments à prendre en compte sur la gestion des identités et des accès pour l’accélérateur de zone d’atterrissage Services d’intégration Azure

Cet article s’appuie sur l’aide fournie dans l’article relatif aux zones d’atterrissage Azure intitulé Zone de conception des zones d’atterrissage Azure pour la gestion des identités et des accès. Les conseils fournis dans l’article suivant vous aideront à identifier les considérations et recommandations relatives à la conception concernant la gestion des identités et des accès spécifiques au déploiement des Services d’intégration Azure. Si les Services d’intégration Azure sont déployés pour prendre en charge les plateformes stratégiques, votre conception doit également inclure l’aide sur les zones de conception des zones d’atterrissage Azure.

Présentation de la gestion des identités et des accès (IAM)

Pour les besoins de cet article, la gestion des identités et des accès (IAM) fait référence aux options d’authentification et d’autorisation disponibles pour le déploiement ou la maintenance des ressources dans Azure. En pratique, cela implique d’identifier les identités autorisées à créer, mettre à jour, supprimer et gérer des ressources via le Portail Azure ou via l’API Resource Manager.

IAM est un élément à prendre en compte distinct de la sécurité des points de terminaison, qui définit les identités autorisées à appeler vos services et à y accéder. La sécurité des points de terminaison est abordée dans l’article Sécurité distinct de cette série. Cela dit, les deux zones de conception se chevauchent parfois : pour certains services dans Azure, l’accès au point de terminaison est configuré via les contrôles RBAC servant déjà à gérer l’accès aux ressources.

Remarques relatives à la conception

• Déterminez les limites d’administration des ressources Azure pour les ressources que vous déployez, en tenant compte de la séparation des tâches et de l’efficacité des opérations.

• Passez en revue les activités d’administration et de gestion Azure que vous exigez de vos équipes. Tenez compte des ressources de Services d’intégration Azure que vous allez déployer et de la façon dont vous allez les utiliser. Déterminez la meilleure distribution possible des responsabilités au sein de votre organisation.

Recommandations de conception

• Utiliser des identités managées pour les ressources de service d'intégration : veuillez consulter l’article Sécurité de cette série si vous souhaitez en savoir plus sur cette recommandation.

• Utilisez Microsoft Entra ID pour l’authentification auprès des ressources des services d’intégration.

• Tenez compte du niveau d’accès requis par les rôles au sein de votre organisation, puis appliquez le principe du moindre privilège par rôle. Ces rôles peuvent inclure des propriétaires de plateforme, des propriétaires de charge de travail, des ingénieurs DevOps et des administrateurs système, par exemple.

• En utilisant le principe du moindre privilège, réfléchissez aux rôles dont vous aurez besoin pour gérer et gérer vos applications de Services d’intégration Azure. Questions à poser à ce sujet :

  • Qui aura besoin d’afficher les fichiers journaux depuis des sources comme Application Insights, Log Analytics et les comptes de stockage ?

  • Quelqu’un a-t-il besoin d’afficher des données de requête d’origine (y compris des données sensibles) ?

  • D’où les données de requête d’origine peuvent-elles être consultées (par exemple, uniquement depuis votre réseau d’entreprise) ?

  • Qui peut afficher l’historique des exécutions d’un workflow ?

  • Qui peut soumettre de nouveau une exécution ayant échoué ?

  • Qui a besoin d’accéder aux clés d’abonnement Gestion des API ?

  • Qui peut afficher le contenu d’une rubrique ou d’un abonnement Service Bus, ou voir les métriques de file d’attente/rubrique ?

  • Qui doit pouvoir administrer Key Vault ?

  • Qui doit pouvoir ajouter, modifier ou supprimer des clés, des secrets et des certificats dans Key Vault ?

  • Qui doit pouvoir afficher, puis lire des clés, des secrets ou des certificats dans Key Vault ?

  • Les rôles et groupes Microsoft Entra intégrés existants couvriront-ils les besoins que vous avez identifiés ?

• Créez des rôles personnalisés pour limiter l’accès ou pour fournir plus de granularité sur les autorisations lorsque les rôles intégrés ne verrouillent pas suffisamment l’accès. Par exemple, l’accès à l’URL de rappel d’une application logique nécessite une autorisation unique, mais il n’existe aucun rôle intégré pour ce type d’accès autre que « Contributeur » ou « Propriétaire », qui sont trop larges.

• Nous vous recommandons d’utiliser Azure Policy pour restreindre l’accès à certaines ressources ou pour appliquer la conformité à la stratégie d’entreprise. Par exemple, vous pouvez créer une stratégie qui autorise uniquement le déploiement d’API Gestion des API qui utilisent des protocoles chiffrés.

• Passez en revue les activités courantes impliquées dans l’administration et la gestion des Services d’intégration sur Azure, puis attribuez les autorisations RBAC de manière appropriée. Si vous souhaitez en savoir plus sur les autorisations disponibles, veuillez consulter la rubriques Opérations du fournisseur de ressources.

Voici quelques exemples d’activités courantes d’administration Azure :

Étape suivante

Vérifiez les zones de conception critiques pour achever les considérations et recommandations relatives à votre architecture.

Contenu recommandé

• Guide de référence sur les opérations de gestion des identités et des accès Microsoft Entra

• Zone de conception de la gestion des identités et des accès Azure

• Identité et accès Azure pour les zones d’atterrissage

• Sécuriser l’accès et les données dans Azure Logic Apps

• Créer des rôles personnalisés dans Azure

• Vue d’ensemble d’Azure Policy

• Tutoriel : générer des stratégies pour appliquer la conformité