Accéder aux partages de fichiers Azure à l’aide de Microsoft Entra ID avec Azure Files OAuth sur REST

  • Article

Azure Files OAuth sur REST permet aux utilisateurs et aux applications d’accéder en lecture et en écriture aux partages de fichiers Azure au niveau de l’administrateur via le protocole d’authentification OAuth, à l’aide de Microsoft Entra ID pour l’accès basé sur l’API REST. Les utilisateurs, les groupes, les services internes tels que le Portail Azure, et les services et applications tiers utilisant des interfaces REST peuvent désormais utiliser l’authentification et l’autorisation OAuth avec un compte Microsoft Entra pour accéder aux données dans des partages de fichiers Azure. Les cmdlets PowerShell et les commandes Azure CLI qui appellent des API REST peuvent également utiliser OAuth pour accéder aux partages de fichiers Azure.

Important

Vous devez appeler l’API REST à l’aide d’un en-tête explicite pour indiquer votre intention d’utiliser le privilège supplémentaire. Cela est également vrai pour l’accès à Azure PowerShell et Azure CLI.

Limites

Azure Files OAuth sur REST prend uniquement en charge les API de données FileREST qui prennent en charge les opérations sur les fichiers et les répertoires. OAuth n’est pas pris en charge sur les API du plan de données FilesREST qui gèrent les ressources FileService et FileShare. Ces API de gestion sont appelées à l’aide de la clé de compte de stockage ou du jeton SAS et sont exposées via le plan de données pour des raisons héritées. Nous vous recommandons d’utiliser les API du plan de contrôle (le fournisseur de ressources de stockage, Microsoft.Storage) qui prennent en charge OAuth pour toutes les activités de gestion liées aux ressources FileService et FileShare.

L’autorisation d’opérations de données de fichier avec Microsoft Entra ID est prise en charge uniquement pour les versions 2022-11-02 et ultérieures de l’API REST. Consultez Contrôle de version pour le Stockage Azure.

Cas d'usages du client

L’authentification et l’autorisation OAuth avec Azure Files sur l’interface API REST peuvent bénéficier aux clients dans les scénarios suivants.

Développement d’applications et intégration de services

L’authentification et l’autorisation OAuth permettent aux développeurs de créer des applications qui accèdent aux API REST du Stockage Azure à l’aide d’identités d’utilisateur ou d’application à partir de Microsoft Entra ID.

Les clients et partenaires peuvent également permettre aux services propres et tiers de configurer l’accès nécessaire de manière sécurisée et transparente à un compte de stockage client.

Les outils DevOps tels que le Portail Azure, PowerShell et la CLI, AzCopy et l’Explorateur Stockage peuvent gérer les données à l’aide de l’identité de l’utilisateur, ce qui élimine la nécessité de gérer ou de distribuer des clés d’accès de stockage.

Identités managées

Les clients disposant d’applications et d’identités managées qui ont besoin d’accéder aux données de partage de fichiers à des fins de sauvegarde, de restauration ou d’audit peuvent bénéficier de l’authentification et de l’autorisation OAuth. L’application d’autorisations au niveau du fichier et du répertoire pour chaque identité ajoute de la complexité et peut ne pas être compatible avec certaines charges de travail. Par exemple, les clients peuvent souhaiter autoriser l’accès d’un service de solution de sauvegarde aux partages de fichiers Azure avec un accès en lecture seule à tous les fichiers, sans égard aux autorisations spécifiques aux fichiers.

Remplacement de clé de compte de stockage

Microsoft Entra ID offre plus de sécurité et une plus grande facilité d’utilisation que l’accès aux clés partagé. Vous pouvez remplacer l’accès à la clé de compte de stockage par l’authentification et l’autorisation OAuth pour accéder aux partages de fichiers Azure avec des privilèges de lecture/écriture. Cette approche offre également un meilleur audit et un meilleur suivi de l’accès d’un utilisateur spécifique.

Accès privilégié et autorisations d’accès pour les opérations de données

Pour utiliser la fonctionnalité Azure Files OAuth sur REST, des autorisations supplémentaires doivent être incluses dans le rôle RBAC attribué à l’utilisateur, au groupe ou au principal du service. Deux nouvelles actions de données sont introduites dans le cadre de cette fonctionnalité :

Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action

Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action

Les utilisateurs, groupes ou principaux de service qui appellent l’API REST avec OAuth doivent avoir l’action readFileBackupSemantics ou writeFileBackupSemantics attribuée au rôle qui autorise l’accès aux données. Il s’agit d’une exigence pour utiliser cette fonctionnalité. Pour plus d’informations sur les autorisations nécessaires pour appeler des opérations propres au service Fichier, consultez Autorisations pour appeler des opérations de données.

Cette fonctionnalité fournit deux nouveaux rôles intégrés qui incluent ces nouvelles actions.

Rôle Actions de données
Lecteur privilégié des données du fichier de stockage Microsoft.Storage/storageAccounts/fileServices/fileShares/files/read
Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action
Contributeur privilégié des données du fichier de stockage Microsoft.Storage/storageAccounts/fileServices/fileShares/files/read
Microsoft.Storage/storageAccounts/fileServices/fileShares/files/write
Microsoft.Storage/storageAccounts/fileServices/fileShares/files/delete
Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action
Microsoft.Storage/storageAccounts/fileServices/fileshares/files/modifypermissions/action

Ces nouveaux rôles sont similaires aux rôles intégrés existants Lecteur de partage SMB des données du fichier de stockage et Contributeur avec privilèges élevés de partage SMB des données du fichier de stockage, mais il existe quelques différences :

  • Les nouveaux rôles contiennent les actions de données supplémentaires requises pour l’accès OAuth.

  • Lorsque l’utilisateur, le groupe ou le principal de service auquel sont attribués les rôles Lecteur privilégié des données du fichier de stockage ou Contributeur privilégié des données du fichier de stockage appelle l’API de données FilesREST à l’aide d’OAuth, l’utilisateur, le groupe ou le principal de service aura :

    • Lecteur privilégié des données du fichier de stockage : Accès en lecture complet sur toutes les données des partages pour tous les comptes de stockage configurés, quelles que soient les autorisations NTFS définies au niveau du fichier/répertoire.
    • Contributeur privilégié des données du fichier de stockage : Accès en lecture, écriture, modification et suppression des ACL complet sur toutes les données des partages pour tous les comptes de stockage configurés, quelles que soient les autorisations NTFS définies au niveau du fichier/répertoire.

  • Avec ces autorisations et rôles spéciaux, le système contourne toutes les autorisations au niveau du fichier/répertoire et autorise l’accès aux données de partage de fichiers.

Avec les nouveaux rôles et actions de données, cette fonctionnalité fournit des privilèges à l’échelle du compte de stockage qui remplacent toutes les autorisations sur les fichiers et dossiers sous tous les partages de fichiers dans le compte de stockage. Toutefois, les nouveaux rôles contiennent uniquement des autorisations d’accès aux services de données. Elles n’incluent aucune autorisation d’accès aux services de gestion de partage de fichiers (actions sur les partages de fichiers). Pour utiliser cette fonctionnalité, vérifiez que vous disposez des autorisations pour accéder :

  • au compte de stockage
  • aux services de gestion de partage de fichiers
  • aux services de données (les données dans le partage de fichiers)

Il existe de nombreux rôles intégrés qui fournissent l’accès aux services de gestion. Vous pouvez aussi créer des rôles personnalisésavec les autorisations adéquates. Pour en savoir plus sur le contrôle d’accès en fonction du rôle, consultez Azure RBAC. Pour plus d’informations sur la définition des rôles intégrés, consultez Comprendre les définitions de rôles.

Important

Tous les cas d’usage génériques définis pour le chemin d’accès Microsoft.Storage/storageAccounts/fileServices/* ou l’étendue supérieure héritent automatiquement de l’accès et des autorisations supplémentaires accordés avec cette nouvelle action de données. Pour empêcher l’accès involontaire ou trop privilégié à Azure Files, nous avons implémenté des vérifications supplémentaires qui obligent les utilisateurs et les applications à indiquer explicitement leur intention d’utiliser le privilège supplémentaire. En outre, nous recommandons vivement aux clients de passer en revue leurs attributions de rôles RBAC d’utilisateur et de remplacer toute utilisation générique par des autorisations explicites pour garantir une gestion appropriée de l’accès aux données.

Autoriser l’accès aux données de fichier dans le code de l’application

La bibliothèque de client Azure Identity simplifie le processus d’obtention d’un jeton d’accès OAuth 2.0 pour l’autorisation avec Microsoft Entra ID via le Kit de développement logiciel (SDK) Azure. Les versions les plus récentes des bibliothèques de client Stockage Azure pour .NET, Java, Python, JavaScript et Go s’intègrent aux bibliothèques Azure Identity pour chacun de ces langages afin de fournir un moyen simple et sécurisé d’acquérir un jeton d’accès pour l’autorisation des demandes du service de fichier Azure.

L’un des avantages de la bibliothèque de client Azure Identity est qu’elle vous permet d’utiliser le même code pour acquérir le jeton d’accès, que votre application soit exécutée dans l’environnement de développement ou dans Azure. La bibliothèque de client Azure Identity renvoie un jeton d’accès pour un principal de sécurité. Lorsque votre code s’exécute dans Azure, le principal de sécurité peut être une identité managée pour les ressources Azure, un principal de service, un utilisateur ou un groupe. Dans l’environnement de développement, la bibliothèque de client fournit un jeton d’accès pour un utilisateur ou un principal de service à des fins de test.

Le jeton d’accès renvoyé par la bibliothèque de client Azure Identity est encapsulé dans les informations d’identification d’un jeton. Vous pouvez ensuite utiliser les informations d’identification du jeton pour obtenir un objet client de service à utiliser lors de l’exécution d’opérations autorisées sur le service Azure Files.

Voici un exemple de code :

using Azure.Core;
using Azure.Identity;
using Azure.Storage.Files.Shares;
using Azure.Storage.Files.Shares.Models;

namespace FilesOAuthSample
{
    internal class Program
    {
        static async Task Main(string[] args)
        {
            string tenantId = "";
            string appId = "";
            string appSecret = "";
            string aadEndpoint = "";
            string accountUri = "";
            string connectionString = "";
            string shareName = "test-share";
            string directoryName = "testDirectory";
            string fileName = "testFile"; 

            ShareClient sharedKeyShareClient = new ShareClient(connectionString, shareName); 
            await sharedKeyShareClient.CreateIfNotExistsAsync(); 

            TokenCredential tokenCredential = new ClientSecretCredential(
                tenantId,
                appId,
                appSecret,
                new TokenCredentialOptions()
                {
                    AuthorityHost = new Uri(aadEndpoint)
                });

            ShareClientOptions clientOptions = new ShareClientOptions(ShareClientOptions.ServiceVersion.V2023_05_03);

            // Set Allow Trailing Dot and Source Allow Trailing Dot.
            clientOptions.AllowTrailingDot = true;
            clientOptions.AllowSourceTrailingDot = true;

            // x-ms-file-intent=backup will automatically be applied to all APIs
            // where it is required in derived clients.

            clientOptions.ShareTokenIntent = ShareTokenIntent.Backup;
            ShareServiceClient shareServiceClient = new ShareServiceClient(
                new Uri(accountUri),
                tokenCredential,
                clientOptions);

            ShareClient shareClient = shareServiceClient.GetShareClient(shareName);
            ShareDirectoryClient directoryClient = shareClient.GetDirectoryClient(directoryName);
            await directoryClient.CreateAsync();

            ShareFileClient fileClient = directoryClient.GetFileClient(fileName);
            await fileClient.CreateAsync(maxSize: 1024);
            await fileClient.GetPropertiesAsync();
            await sharedKeyShareClient.DeleteIfExistsAsync();
        }
    }
}

Autoriser l’accès à l’aide de l’API de plan de données FileREST

Vous pouvez également autoriser l’accès aux données de fichier à l’aide du Portail Azure ou d’Azure PowerShell.

Le Portail Azure peut utiliser soit votre compte Microsoft Entra, soit les clés d’accès au compte de stockage pour accéder aux données de fichier dans un compte de stockage Azure. Le schéma d’autorisation utilisé par le portail Azure dépend des rôles Azure qui vous sont attribués.

Quand vous tentez d’accéder aux données de fichier, le Portail Azure commence par vérifier si un rôle Azure avec Microsoft.Storage/storageAccounts/listkeys/action vous a été attribué. Si vous êtes doté d’un rôle avec cette action, le Portail Azure utilise la clé de compte pour l’accès aux données de fichier via l’autorisation de clé partagée. Si un rôle avec cette action ne vous a pas été attribué, le Portail Azure tente d’accéder aux données à l’aide de votre compte Microsoft Entra.

Pour accéder aux données de fichier à partir du Portail Azure à l’aide de votre compte Microsoft Entra, vous devez disposer d’autorisations pour accéder aux données de fichier, ainsi que pour parcourir les ressources de compte de stockage dans le Portail Azure. Les rôles intégrés fournis par Azure octroient l’accès aux ressources de fichier, mais n’accordent pas d’autorisations pour les ressources de compte de stockage. C’est la raison pour laquelle l’accès au portail requiert également l’attribution d’un rôle Azure Resource Manager (ARM), tel que le rôle Lecteur, étendu au niveau du compte de stockage ou à un niveau supérieur. Le rôle Lecteur octroie les autorisations les plus restreintes, mais l’utilisation d’un rôle ARM accordant l’accès aux ressources de gestion de compte de stockage est aussi acceptable.

Le Portail Azure indique le schéma d’autorisation en cours d’utilisation lorsque vous accédez à un conteneur. Pour plus d’informations sur l’accès aux données dans le portail, consultez Choisir comment autoriser l’accès à des données de fichier dans le Portail Azure.

Voir aussi