Contrôle des accès et des identités
Dans cette unité, vous apprenez comment authentifier les utilisateurs et fournir l’accès aux partages de fichiers Azure. Azure Files prend en charge l’authentification basée sur l’identité pour les clients accédant aux partages de fichiers via SMB. En outre, les utilisateurs SMB peuvent également s’authentifier à l’aide d’une clé de compte de stockage. Les partages de fichiers NFS s’appuient sur l’authentification au niveau du réseau et sont dès lors uniquement accessibles via des réseaux restreints. L’utilisation d’un partage de fichiers NFS nécessite systématiquement un certain niveau de configuration réseau. L’accès au partage de fichiers sur les API REST utilise des signatures d’accès partagé et des clés de compte de stockage pour des opérations de gestion des données spécifiques.
Authentification basée sur l’identité : Les clients peuvent utiliser l’accès basé sur l’identité par le protocole d’authentification Kerberos. Les services Active Directory stockent les informations de compte d’utilisateur telles que les noms d’utilisateur, les mots de passe, les informations de contact, et ainsi de suite. Azure Files s’intègre aux services d’annuaire communs pour vérifier les détails du compte d’utilisateur et procéder à l’authentification. Pour SMB, l’authentification basée sur l’identité est l’option la plus sécurisée et recommandée.
Clé de compte de stockage : un utilisateur disposant de la clé de compte de stockage peut accéder aux partages de fichiers Azure avec des autorisations de superutilisateur sur SMB et REST. Dans l’idéal, seuls les administrateurs super-utilisateurs doivent utiliser des clés de compte de stockage, car elles contournent toutes les restrictions d’accès. Pour les partages de fichiers utilisés par les clients d’entreprise, les clés de compte de stockage ne constituent pas des mécanismes scalables ou sécurisés pour l’accès à l’échelle de l’organisation, et ne sont donc pas recommandées. La bonne pratique en matière de sécurité consiste à éviter de partager les clés de compte de stockage et à utiliser l’authentification basée sur l’identité.
Signature d’accès partagé : les clients accédant par le biais de REST peuvent utiliser une signature d’accès partagé (SAS) pour s’authentifier auprès d’Azure Files. Les signatures d’accès partagé sont utilisées dans des scénarios spécifiques où des éditeurs de logiciels indépendants développent des applications API REST et utilisent Azure Files comme solution de stockage. Elles sont également utilisées lorsque des partenaires internes ont besoin d’accéder à REST pour les opérations de gestion des données. Une signature d’accès partagé est un URI qui octroie des droits d’accès restreints à des ressources Stockage Azure. Vous pouvez utiliser une signature d’accès partagé pour permettre aux clients d’accéder à certaines ressources de compte de stockage sans avoir à leur accorder l’accès à votre clé de compte de stockage.
Authentification basée sur l’identité
Azure Files prend en charge l’authentification basée sur l’identité pour les partages de fichiers SMB à l’aide du protocole Kerberos. Quand une identité associée à un utilisateur ou à une application s’exécutant sur un client tente d’accéder à des données se trouvant dans des partages de fichiers Azure, la requête est envoyée au service de domaine afin d’authentifier l’identité. Si l’authentification réussit, un jeton Kerberos est renvoyé. L’application envoie une requête incluant le jeton Kerberos, que les partages de fichiers Azure utilisent pour autoriser la requête. Les partages de fichiers Azure ne reçoivent que le jeton Kerberos, et non les informations d’identification d’accès.
Azure Files prend en charge les méthodes d’authentification suivantes pour les partages de fichiers SMB :
Active Directory Domain Services (AD DS) en local : L’activation de l’authentification AD DS pour un partage de fichiers Azure permet aux utilisateurs de s’authentifier à l’aide de leurs informations d’identification AD DS locales. Les services AD DS locaux doivent être synchronisés avec l’ID Microsoft Entra à l’aide de la synchronisation Microsoft Entra Connect. Seuls les utilisateurs hybrides, qui existent à la fois dans AD DS local et Microsoft Entra ID, peuvent être authentifiés et autorisés à accéder aux partages de fichiers Azure. Le client doit configurer ses contrôleurs de domaine et joindre ses ordinateurs ou machines virtuelles au domaine. Les contrôleurs de domaine peuvent être hébergés localement ou sur des machines virtuelles, mais les clients doivent avoir une ligne de vue sur les contrôleurs de domaine, soit sur un réseau local, soit sur le même réseau virtuel.
Microsoft Entra Domain Services : Pour l’authentification Microsoft Entra Domain Services, les clients doivent activer Domain Services et joindre au domaine les machines virtuelles à partir desquelles ils souhaitent accéder aux données des fichiers. Les machines virtuelles jointes au domaine doivent résider dans le même réseau virtuel que les services de domaine. Toutefois, les clients n’ont pas besoin de créer l’identité dans les services de domaine pour représenter le compte de stockage. Le processus d’activation crée l’identité en arrière-plan. Par ailleurs, tous les utilisateurs présents dans Microsoft Entra ID peuvent être authentifiés et autorisés. L’utilisateur peut être de type cloud uniquement ou hybride. La plateforme gère la synchronisation depuis Microsoft Entra ID vers Domain Services sans nécessiter de configuration utilisateur.
Microsoft Entra Kerberos pour les identités utilisateur hybrides : Azure Files supporte l’authentification Microsoft Entra Kerberos (anciennement Azure AD Kerberos) pour les identités d’utilisateurs hybrides, qui sont des identités AD sur site qui sont synchronisés au cloud. Cette configuration utilise Microsoft Entra ID pour émettre des tickets Kerberos afin d’accéder au partage de fichiers par le biais de SMB. Cela signifie que les utilisateurs finaux peuvent accéder à des partages de fichiers Azure via Internet sans avoir besoin d’une ligne de vue sur les contrôleurs de domaine de machines virtuelles jointes Microsoft Entra et hybrides. En outre, avec cette fonctionnalité, les clients Azure Virtual Desktop peuvent créer un partage de fichiers Azure pour stocker des conteneurs de profils auxquels les utilisateurs hybrides peuvent accéder.
Authentification AD pour les clients Linux : L’authentification pour les clients Linux est prise en charge via AD DS ou Microsoft Entra Domain Services.
Cas d’usage courants pour l’authentification basée sur l’identité
Voici quelques scénarios courants d’utilisation de l’authentification basée sur l’identité :
Migration de serveurs de fichiers locaux vers Azure Files : Le remplacement de serveurs de fichiers locaux est un cas d’usage de transformation informatique courant pour de nombreux clients aujourd’hui. L’utilisation d’AD DS local pour permettre une migration transparente vers Azure Files offre non seulement une bonne expérience utilisateur, mais permet également aux utilisateurs d’accéder au partage de fichiers et aux données à l’aide de leurs informations d’identification actuelles en joignant leurs machines à un domaine.
Déplacement d’applications d’entreprise vers le cloud : lorsque les clients déplacent leurs applications natives locales vers le cloud, l’authentification basée sur l’identité avec Azure Files élimine la nécessité de modifier les mécanismes d’authentification pour prendre en charge les applications cloud.
Sauvegarde et reprise d’activité après sinistre : Azure Files peut agir comme système de stockage de sauvegarde pour les serveurs de fichiers locaux. La configuration de l’authentification appropriée permet d’appliquer des contrôles d’accès pendant les scénarios de reprise d’activité.