Partager via

Créer une SAP de service pour un conteneur ou un objet blob avec .NET

  • Article

Une signature d’accès partagé (SAP) vous permet d’accorder un accès limité aux conteneurs et aux objets blob de votre compte de stockage. Lorsque vous créez une SAP, vous spécifiez ses contraintes, notamment les ressources de Stockage Azure auxquelles un client est autorisé à accéder, les autorisations dont ils disposent sur ces ressources et la durée de validité de la SAP.

Chaque SAP est signée avec une clé. Vous pouvez signer une SAP grâce à l’une des deux méthodes suivantes :

  • Avec une clé créée en utilisant les informations d’identification Microsoft Entra. Une SAS signée avec des informations d’identification Microsoft Entra est une SAS de délégation d’utilisateur. Un client qui crée une signature d’accès partagé de délégation d’utilisateur doit avoir un rôle RBAC Azure qui inclut l’action Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey. Pour en savoir plus, consultez Créer une SAS de délégation d'utilisateur.
  • Avec la clé du compte de stockage. Une SAP de service et une SAP de compte sont signées avec la clé du compte de stockage. Le client qui crée une signature d’accès partagé de service doit avoir un accès direct à la clé de compte ou une autorisation Microsoft.Storage/storageAccounts/listkeys/action. Pour plus d’informations, consultez Créer une SAS de service ou Créer une SAS de compte.

Notes

Une SAP de délégation d’utilisateur offre une meilleure sécurité à une SAP signée avec la clé de compte de stockage. Microsoft recommande d’utiliser une SAP de délégation d’utilisateur dans la mesure du possible. Pour plus d’informations, consultez Accorder un accès limité aux données avec des signatures d’accès partagé (SAP).

Cet article explique comment utiliser la clé de compte de stockage pour créer une SAP de service pour un conteneur ou un objet blob avec la bibliothèque cliente Stockage Blob Azure pour .NET.

À propos de la SAS de service

Une SAP de service est signée avec la clé d’accès au compte. Vous pouvez utiliser la classe StorageSharedKeyCredential afin de créer les informations d’identification utilisées pour signer le jeton SAS de service.

Vous pouvez également utiliser une stratégie d’accès stockée pour définir les autorisations et la durée de la signature d’accès partagé. Si le nom d’une stratégie d’accès stockée existante est fourni, cette stratégie est associée à la SAP. Pour plus d’informations sur les stratégies d’accès stockées, consultez Définir une stratégie d’accès stockée. Si aucune stratégie d’accès stockée n’est fournie, les exemples de code de cet article montrent comment définir des autorisations et une durée pour la SAS.

Créer une SAP de service

Vous pouvez créer une SAP de service pour un conteneur ou un blob, en fonction des besoins de votre application.

L’exemple de code suivant montre comment créer une SAS de service pour une ressource de conteneur. Tout d’abord, le code vérifie que l’objet BlobContainerClient est autorisé avec des informations d’identification de clé partagée en vérifiant la propriété CanGenerateSasUri. Ensuite, il génère la SAS de service via la classe BlobSasBuilder et appelle GenerateSasUri pour créer un URI SAS de service basé sur les objets client et générateur.

public static async Task<Uri> CreateServiceSASContainer(
    BlobContainerClient containerClient,
    string storedPolicyName = null)
{
    // Check if BlobContainerClient object has been authorized with Shared Key
    if (containerClient.CanGenerateSasUri)
    {
        // Create a SAS token that's valid for one day
        BlobSasBuilder sasBuilder = new BlobSasBuilder()
        {
            BlobContainerName = containerClient.Name,
            Resource = "c"
        };

        if (storedPolicyName == null)
        {
            sasBuilder.ExpiresOn = DateTimeOffset.UtcNow.AddDays(1);
            sasBuilder.SetPermissions(BlobContainerSasPermissions.Read);
        }
        else
        {
            sasBuilder.Identifier = storedPolicyName;
        }

        Uri sasURI = containerClient.GenerateSasUri(sasBuilder);

        return sasURI;
    }
    else
    {
        // Client object is not authorized via Shared Key
        return null;
    }
}

Utiliser une SAS de service pour autoriser un objet client

Vous pouvez utiliser une SAP de service pour autoriser un objet client à effectuer des opérations sur un conteneur ou un blob en fonction des autorisations octroyées par la SAP.

L’exemple de code suivant montre comment utiliser la SAS de service pour autoriser un objet BlobContainerClient. Cet objet client peut être utilisé pour effectuer des opérations sur la ressource d’objet conteneur en fonction des autorisations accordées par la signature d’accès partagé.

Tout d’abord, créez un objet BlobServiceClient signé avec la clé d’accès au compte :

string accountName = "<storage-account-name>";
string accountKey = "<storage-account-key";
StorageSharedKeyCredential storageSharedKeyCredential =
    new(accountName, accountKey);
BlobServiceClient blobServiceClient = new BlobServiceClient(
    new Uri($"https://{accountName}.blob.core.windows.net"),
    storageSharedKeyCredential);

Ensuite, générez le SAS de service comme indiqué dans l'exemple précédent et utilisez le SAS pour autoriser un objet BlobContainerClient :

// Create a Uri object with a service SAS appended
BlobContainerClient containerClient = blobServiceClient
    .GetBlobContainerClient("sample-container");
Uri containerSASURI = await CreateServiceSASContainer(containerClient);

// Create a container client object representing 'sample-container' with SAS authorization
BlobContainerClient containerClientSAS = new BlobContainerClient(containerSASURI);

Définir une stratégie d’accès stockée

Une stratégie d’accès stockée fournit un niveau de contrôle supplémentaire sur une signature d’accès partagé (SAP) au niveau du service du côté du serveur. L'établissement d'une stratégie d'accès stockée sert à regrouper des signatures d'accès partagé et à fournir des restrictions supplémentaires pour les signatures liées par la stratégie.

Utilisez une stratégie d'accès stockée pour modifier l'heure de début, l'heure d'expiration ou les autorisations d'une signature. Vous pouvez également utiliser une stratégie d'accès stocké pour révoquer une signature après sa délivrance. Cette section se concentre sur les conteneurs d’objets blob, mais les stratégies d’accès stockées sont également prises en charge pour les partages de fichiers, les files d’attente et les tables.

Pour gérer les stratégies d’accès stockées sur une ressource conteneur, appelez l’une des méthodes suivantes à partir d’un objet BlobContainerClient :

Créer ou modifier une stratégie d’accès stockée

Vous pouvez définir un maximum de cinq stratégies d’accès sur une ressource à la fois. Chaque champ SignedIdentifier, avec son champ Id unique, correspond à une seule stratégie d'accès. Si vous essayez de définir plus de cinq stratégies d’accès à la fois, le service retourne le code de statut 400 (Bad Request).

L’exemple de code suivant montre comment créer deux stratégies d’accès stockées sur une ressource de conteneur :

public static async Task CreateStoredAccessPolicyAsync(BlobContainerClient containerClient)
{
    // Create a stored access policy with read and write permissions, valid for one day
    List<BlobSignedIdentifier> signedIdentifiers = new List<BlobSignedIdentifier>
    {
        new BlobSignedIdentifier
        {
            Id = "sample-read-write-policy",
            AccessPolicy = new BlobAccessPolicy
            {
                StartsOn = DateTimeOffset.UtcNow,
                ExpiresOn = DateTimeOffset.UtcNow.AddDays(1),
                Permissions = "rw"
            }
        },
        new BlobSignedIdentifier
        {
            Id = "sample-read-policy",
            AccessPolicy = new BlobAccessPolicy
            {
                StartsOn = DateTimeOffset.UtcNow,
                ExpiresOn = DateTimeOffset.UtcNow.AddDays(1),
                Permissions = "r"
            }
        }
    };

    // Set the container's access policy
    await containerClient.SetAccessPolicyAsync(permissions: signedIdentifiers);
}

Vous pouvez également modifier une stratégie existante. L’exemple de code suivant montre comment modifier une stratégie d’accès stockée unique pour mettre à jour la date d’expiration de la stratégie :

public static async Task ModifyStoredAccessPolicyAsync(BlobContainerClient containerClient)
{
    BlobContainerAccessPolicy accessPolicy = await containerClient.GetAccessPolicyAsync();
    List<BlobSignedIdentifier> signedIdentifiers = accessPolicy.SignedIdentifiers.ToList();

    // Modify the expiration date a single policy
    var samplePolicy = signedIdentifiers.FirstOrDefault(item => item.Id == "sample-read-policy");
    samplePolicy.AccessPolicy.PolicyExpiresOn = DateTimeOffset.UtcNow.AddDays(7);

    // Update the container's access policy
    await containerClient.SetAccessPolicyAsync(permissions: signedIdentifiers);
}

Révoquer ou supprimer une stratégie d’accès stockée

Pour révoquer une stratégie d’accès stockée, Microsoft recommande de supprimer l’identificateur signé et d’en créer un nouveau. La modification de l'identificateur signé désactive les associations entre les signatures existantes et la stratégie d'accès stockée. La suppression ou la modification de la stratégie d'accès stockée affecte immédiatement toutes les signatures d'accès partagé qui lui sont associées.

L’exemple de code suivant montre comment révoquer une stratégie en modifiant la propriété Id de l’identificateur signé. Cette approche supprime efficacement l’identificateur signé et en crée un nouveau :

public static async Task RevokeStoredAccessPolicyAsync(BlobContainerClient containerClient)
{
    BlobContainerAccessPolicy accessPolicy = await containerClient.GetAccessPolicyAsync();
    List<BlobSignedIdentifier> signedIdentifiers = accessPolicy.SignedIdentifiers.ToList();

    // Revoke a single policy by changing its name
    var samplePolicy = signedIdentifiers.FirstOrDefault(item => item.Id == "sample-read-policy");
    samplePolicy.Id = "sample-read-policy-revoke";

    // Update the container's access policy
    await containerClient.SetAccessPolicyAsync(permissions: signedIdentifiers);
}

Vous pouvez également supprimer toutes les stratégies d’accès d’une ressource conteneur en appelant SetAccessPolicyAsync avec un paramètre vide permissions. L'exemple suivant montre comment supprimer toutes les politiques d'accès stockées dans un conteneur donné :

public static async Task DeleteStoredAccessPolicyAsync(BlobContainerClient containerClient)
{
    // Remove all stored access policies for the container resource
    await containerClient.SetAccessPolicyAsync();
}

Ressources

Pour en savoir plus sur la création d’une SAS de service à l’aide de la bibliothèque cliente Stockage Blob Azure pour .NET, consultez les ressources suivantes.

Exemples de code

Ressources de bibliothèque cliente

Voir aussi