Partager via

Gestion des identités et des accès pour SQL Managed Instance avec Azure Arc

  • Article

Cet article décrit l’architecture de gestion des identités et des accès SQL Managed Instance avec Azure Arc et les considérations relatives à la conception, et il fournit des recommandations pour différents scénarios.

SQL Managed Instance avec Arc s’appuie sur l’extension de services de données avec Azure Arc s’exécutant sur un cluster Kubernetes avec Azure Arc. Voici les différents composants des services de données avec Azure Arc qui sont importants pour la gestion des identités et des accès dans le cadre de cette zone de conception critique.

  • Contrôleur de données Azure Arc
  • Connecteur Active Directory Azure Arc
  • SQL Managed Instance avec Azure Arc

Architecture

Authentification SQL

L’authentification SQL est prise en charge pour SQL Managed Instance avec Arc à l’aide d’identités SQL locales. La méthode d’authentification SQL est utilisée lors de la première connexion afin de créer des informations d’identification de connexion à partir de Windows pour les administrateurs, et afin d’accorder des autorisations à la base de données pour accéder à SQL Managed Instance avec Arc à l’aide de l’authentification Active Directory. À l’heure actuelle, les tableaux de bord Grafana et Kibana prennent uniquement en charge l’authentification de base.

Authentification Active Directory

Pour de nombreuses organisations, l’authentification Active Directory (AD) est la norme pour appliquer le contrôle d’accès en fonction du rôle (RBAC) avec des serveurs SQL s’exécutant localement et dans des environnements cloud. SQL Managed Instance avec Azure Arc prend en charge l’authentification AD pour migrer de manière fluide les bases de données SQL Server existantes vers SQL Managed Instance avec Arc et rester à jour avec la dernière version de SQL Server et les derniers correctifs de sécurité.

SQL Managed Instance avec Arc utilise un fichier keytab Kerberos pour prendre en charge l’authentification AD lors de l’exécution sur des clusters Kubernetes avec Arc. Le connecteur Active Directory est un composant clé dans les services de données avec Arc pour prendre en charge l’authentification AD.

Vous trouverez ci-dessous deux façons de générer et de gérer le fichier keytab Kerberos et de l’utiliser dans SQL Managed Instance avec Arc. Les sections suivantes expliquent les scénarios et quand utiliser le mode keytab approprié.

Keytab géré par le système

Le connecteur Active Directory en mode keytab géré par le système simplifie la génération de comptes AD et la gestion de keytab pour SQL Managed Instance avec Arc. Le connecteur AD est responsable de la création des comptes de service, de l’attribution de principaux de service et de la génération de fichier keytab pour prendre en charge l’authentification AD. Cette méthode est recommandée pour les clients qui préfèrent simplifier les opérations plutôt que bénéficier d’un contrôle précis pour gérer automatiquement le fichier keytab pour l’authentification AD.

Diagram that shows Active Directory authentication using system-managed keytab mode.

Figure 1 : Diagramme d’architecture du connecteur AD en mode keytab géré par le système.

Keytab géré par le client

Le connecteur Active Directory en mode keytab géré par le client assure un contrôle total de la gestion des comptes de service, des principaux de service et de la génération de fichier keytab pour les clients qui suivent strictement le processus ITIL (Information Technology Infrastructure Library) et la séparation des tâches pour déléguer les activités à différentes équipes.

Diagram that shows Active Directory authentication using customer-managed keytab mode.

Figure 2 : Diagramme d’architecture du connecteur AD en mode keytab géré par le client.

Contrôleur de données Azure Arc

Lorsque l’extension des services de données avec Arc est installée en mode Connecté directement, une identité managée est créée pour que les services de données avec Arc interagissent avec le plan de contrôle et le plan de données des API ARM (Azure Resource Manager). Le contrôleur de données Azure Arc utilise cette identité managée pour effectuer ces actions lors de la gestion de SQL Managed Instance avec Arc.

En mode Connectivité indirecte, le contrôleur de données Azure Arc a besoin d’un principal de service disposant d’autorisations requises pour exporter régulièrement des informations d’utilisation telles que l’inventaire et l’utilisation des ressources vers Azure.

Azure RBAC sur les services de données avec Azure Arc

Voici les autorisations RBAC requises pour publier des métriques de monitoring dans Azure Monitor.

Role Description
Publication des métriques de surveillance Permet de publier les métriques relatives aux ressources Azure.

Sécuriser l’accès à SQL Managed Instance avec Azure Arc

Le diagramme d’architecture suivant illustre l’accès sécurisé à l’aide de l’authentification AD.

Diagram that shows secure access to Arc-enabled SQL Managed Instance using AD authentication.

Le diagramme d’architecture suivant illustre l’accès sécurisé à l’aide de l’authentification SQL.

Diagram that shows secure access to Arc-enabled SQL Managed Instance using SQL authentication.

Remarques relatives à la conception

Examinez la zone de conception critique de gestion des identités et des accès des zones d’atterrissage Azure afin d’évaluer l’effet des services de connées avec Azure Arc sur votre modèle d’identité et d’accès global.

Déploiement des services de données avec Arc

  • Réfléchissez à l’identité utilisée pour déployer des services de données avec Azure Arc en fonction du type de déploiement (par exemple manuel ou automatisé), pour le déploiement des services de données avec Arc. Cette identité peut être un compte Microsoft Entra ou un compte LDAP (Lightweight Directory Access Protocol) d’Active Directory Domain Services (AD DS) ou d’un fournisseur LDAP tiers, en fonction de la façon dont les contrôles d’accès Kubernetes avec Azure Arc sous-jacents sont gérés dans des environnements locaux ou d’autres environnements cloud.

  • Déterminez si le contrôle d’accès basé sur le groupe ou des contrôles d’accès individuels basés sur les identités sont plus appropriés pour votre organisation informatique, afin de gérer les services de données avec Arc en fonction de la surcharge des opérations créée par les deux options.

  • Déterminez s’il est préférable de recourir à des administrateurs Kubernetes avec Azure Arc, à un groupe d’administration de base de données (DMG) ou à un groupe d’administration d’application pour déployer et gérer les services de données avec Azure Arc, en fonction des exigences de votre organisation en matière de gouvernance de sécurité et de séparation des tâches.

  • Prenez en considération les différences entre un modèle d’utilisation avec keytab géré par le système et avec keytab géré par le client pour déployer le connecteur AD Azure Arc, en vue de la prise en charge de l’authentification Azure AD dans SQL Managed Instance avec Arc. Ces deux méthodes se caractérisent par des opérations simplifiées, par rapport au contrôle total par le client de la gestion des comptes de service et du keytab en vue de la prise en charge de l’authentification AD.

Accès aux services de données avec Arc

Les contrôles d’accès SQL Managed Instance avec Arc sont totalement indépendants des contrôles d’accès Kubernetes avec Azure Arc sous-jacents. Il est important de prendre quelques décisions de conception pour administrer SQL Managed Instance avec Arc et fournir l’accès aux applications consommateur et aux utilisateurs finaux.

  • Choisissez entre l’authentification AD et SQL en fonction des applications ou des fonctionnalités de service de votre organisation. Comme toutes les applications ne prennent pas en charge l’authentification AD, passez en revue les stratégies de sécurité de votre organisation afin de connaître les types d’authentification autorisés, et appliquez des contrôles de sécurité supplémentaires nécessaires lors de l’utilisation de l’authentification SQL.

  • Lorsque des services natifs cloud doivent s’authentifier et se connecter à des bases de données SQL Managed Instance avec Arc pour extraire et ingérer des données dans des services d’analytique données, vous pouvez utiliser des machines virtuelles ou physiques locales à runtime auto-hébergé jointes à AD sur SQL pour l’authentification et la connexion à SQL Managed Instance avec Arc.

Recommandations de conception

Outre les recommandations de conception suivantes, passez en revue les recommandations pour la conception de la gestion des identités et des accès pour Kubernetes avec Azure Arc, car SQL Managed Instance avec Arc est déployé sur le cluster Kubernetes avec Arc.

Déploiement des services de données avec Arc

  • Pour les organisations d’entreprise qui suivent des processus ITIL stricts, isolez les équipes responsables de la gestion des services de données avec Arc de Kubernetes avec Arc en créant différents groupes de sécurité, puis attribuez des autorisations pour gérer les services de données avec Arc.

  • Utilisez le mode keytab géré par le système pour la prise en charge de l’authentification AD afin de décharger le compte de domaine et la surcharge de gestion keytab et simplifier les opérations.

  • Utilisez le mode keytab géré par le client pour l’authentification AD afin de bénéficier d’un contrôle total sur la création des comptes de service et la génération des fichiers keytab.

  • Créez une unité d’organisation AD dédiée pour déléguer le contrôle d’accès et simplifier les opérations pour tous les comptes SQL Managed Instance avec Arc.

  • Utilisez le chiffrement AES256 pour les fichiers keytab Kerberos, et évitez l’utilisation des chiffrements RC4.

Accès aux services de données avec Arc

  • Si nécessaire, utilisez l’authentification AD avec SQL Managed Instance pour décharger la gestion du cycle de vie des utilisateurs vers les services d’annuaire et utilisez des groupes de sécurité dans AD pour gérer les autorisations des utilisateurs.

  • Utilisez l’authentification SQL avec SQL Managed Instance avec Arc comme type d’authentification le moins préféré et quand il n’est pas possible d’utiliser l’authentification AD.

  • Une fois l’authentification AD rendue possible pour vos besoins organisationnels, évitez d’utiliser l’authentification SQL pour les opérations quotidiennes. Utilisez l’authentification SQL uniquement pour l’accès d’urgence au serveur de base de données pour l’administration de la base de données.

  • Dans les scénarios de déploiement qui ne prennent pas en charge l’authentification AD, utilisez l’authentification SQL prise en charge dans SQL Managed Instance avec Arc. Veillez à appliquer des stratégies à mots de passe forts, et à activer l’audit afin de superviser les identités utilisateur SQL et les autorisations accordées pour accéder aux bases de données et aux serveurs de base de données.

Contrôles d’accès en fonction du rôle (RBAC)

En mode keytab géré par le système, des autorisations explicites au compte de service de domaine (DSA) sont requises au niveau de l’unité d’organisation Active Directory pour SQL Managed Instance avec Arc.

Vous trouverez ci-dessous les autorisations RBAC requises. Pour le mode keytab géré par le client, aucune autorisation explicite n’est requise pour le compte de service de domaine au niveau de l’unité d’organisation Active Directory.

Autorisations du connecteur AD Azure Arc

Autorisation Description
Lire toutes les propriétés Autoriser la lecture de toutes les propriétés d’un objet d’annuaire.
Écrire toutes les propriétés Autoriser les mises à jour de toutes les propriétés de l’objet d’annuaire.
Créer des objets utilisateur Autoriser la création d’objets d’annuaire dans l’unité d’organisation.
Supprimer des objets utilisateur Autoriser la suppression d’objets d’annuaire dans l’unité d’organisation.
Réinitialiser le mot de passe Autoriser la réinitialisation de mot de passe des objets utilisateur dans l’unité d’organisation.

Rôles SQL Server

Étapes suivantes

Pour plus d’informations sur la gestion des identités et des accès dans SQL Managed Instance avec Azure Arc, consultez les articles suivants :