Créer une SAP de service pour un blob avec .NET
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é du compte de stockage pour créer une SAP de service, pour 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 SAP.
Créer une SAP de service pour un objet blob
L’exemple de code suivant montre comment créer une SAP de service pour une ressource blob. Tout d’abord, le code vérifie que l’objet BlobClient est autorisé avec des informations d’identification de clé partagée en vérifiant la propriété CanGenerateSasUri. Ensuite, il génère la SAP de service via la classe BlobSasBuilder et appelle GenerateSasUri pour créer un URI SAP de service basé sur les objets client et générateur.
public static async Task<Uri> CreateServiceSASBlob(
BlobClient blobClient,
string storedPolicyName = null)
{
// Check if BlobContainerClient object has been authorized with Shared Key
if (blobClient.CanGenerateSasUri)
{
// Create a SAS token that's valid for one day
BlobSasBuilder sasBuilder = new BlobSasBuilder()
{
BlobContainerName = blobClient.GetParentBlobContainerClient().Name,
BlobName = blobClient.Name,
Resource = "b"
};
if (storedPolicyName == null)
{
sasBuilder.ExpiresOn = DateTimeOffset.UtcNow.AddDays(1);
sasBuilder.SetPermissions(BlobContainerSasPermissions.Read);
}
else
{
sasBuilder.Identifier = storedPolicyName;
}
Uri sasURI = blobClient.GenerateSasUri(sasBuilder);
return sasURI;
}
else
{
// Client object is not authorized via Shared Key
return null;
}
}
Utiliser une SAP de service pour autoriser un objet client
L’exemple de code suivant montre comment utiliser la SAP de service pour autoriser un objet BlobClient. Cet objet client peut être utilisé pour effectuer des opérations sur la ressource d’objet blob 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);
Générez ensuite la SAP de service, comme indiqué dans l’exemple précédent, et utilisez la SAP pour autoriser un objet BlobClient :
// Create a Uri object with a service SAS appended
BlobClient blobClient = blobServiceClient
.GetBlobContainerClient("sample-container")
.GetBlobClient("sample-blob.txt");
Uri blobSASURI = await CreateServiceSASBlob(blobClient);
// Create a blob client object representing 'sample-blob.txt' with SAS authorization
BlobClient blobClientSAS = new BlobClient(blobSASURI);
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.
Ressources de bibliothèque cliente
- Documentation de référence sur la bibliothèque cliente
- Code source de la bibliothèque de client
- Package (NuGet)
Voir aussi
- Accorder un accès limité aux ressources du Stockage Azure à l’aide des signatures d’accès partagé (SAP)
- Créer une SAP de service
- Pour obtenir des exemples de code associés utilisant des Kits de développement logiciel (SDK) .NET version 11.x dépréciés, consultez l’article Exemples de code utilisant .NET version 11.x.
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : pendant toute l’année 2024, nous allons éliminer progressivement Problèmes GitHub comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, voir :Soumettre et afficher des commentaires pour