Создание SAS для службы для контейнера или большого двоичного объекта с помощью .NET
Подписанный URL-адрес (SAS) позволяет предоставить ограниченный разрешениями доступ к контейнерам и BLOB-объектам в вашей учетной записи хранения. При создании SAS необходимо указать его ограничения, включая ресурсы службы хранилища Azure, к которым разрешен доступ клиенту, разрешения, предоставленные для доступа к этим ресурсам, а также срок действия SAS.
Каждый SAS подписывается ключом. Подписать SAS можно одним из двух способов:
- С помощью ключа, созданного с помощью учетных данных Microsoft Entra. SAS, подписанный учетными данными Microsoft Entra, — это SAS делегирования пользователей. Клиенту, создающему SAS делегирования пользователей, должна быть назначена роль Azure RBAC, которая включает действие Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey. Дополнительные сведения см. в статье "Создание SAS делегирования пользователей".
- Ключом учетной записи хранения. Как SAS службы, так и SAS учетной записи подписываются ключом учетной записи хранения. Клиент, создающий SAS службы, должен иметь прямой доступ к ключу учетной записи или ему должно быть назначено разрешение Microsoft.Storage/storageAccounts/listkeys/action. Дополнительные сведения см. в статье "Создание SAS службы" или "Создание SAS учетной записи".
Примечание.
SAS делегирования пользователя обеспечивает более высокую безопасность по сравнению с SAS, подписанным ключом учетной записи хранения. Корпорация Майкрософт рекомендует по возможности использовать SAS делегирования пользователя. Дополнительные сведения см. в статье Предоставление ограниченного доступа к данным с помощью подписанных URL-адресов (SAS).
В этой статье показано, как использовать ключ учетной записи хранения для создания SAS службы для контейнера или большого двоичного объекта с клиентской библиотекой Хранилище BLOB-объектов Azure для .NET.
Сведения о SAS службы
SAS службы подписан ключом доступа к учетной записи. Класс StorageSharedKeyCredential можно использовать для создания учетных данных, используемых для подписи SAS службы.
Вы также можете использовать хранимую политику доступа для определения разрешений и длительности SAS. Если указано имя существующей хранимой политики доступа, то эта политика будет связана с SAS. Дополнительные сведения о хранимых политиках доступа см. в статье "Определение хранимой политики доступа". Если хранимая политика доступа не указана, в примерах кода в этой статье показано, как определить разрешения и длительность SAS.
Create a service SAS (Создание SAS на уровне службы)
Вы можете создать SAS службы для контейнера или большого двоичного объекта в зависимости от потребностей приложения.
В следующем примере кода показано, как создать SAS службы для ресурса контейнера. Во-первых, код проверяет, разрешен ли объект BlobContainerClient с учетными данными общего ключа, проверяя свойство CanGenerateSasUri . Затем он создает SAS службы через класс BlobSasBuilder и вызывает GenerateSasUri для создания URI SAS службы на основе объектов клиента и построителя.
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;
}
}
Использование SAS службы для авторизации клиентского объекта
С помощью SAS службы можно авторизовать клиентский объект для выполнения операций с контейнером или BLOB-объектом на основе разрешений, предоставленных SAS.
В следующих примерах кода показано, как использовать SAS службы для авторизации объекта BlobContainerClient . Этот клиентский объект можно использовать для выполнения операций с ресурсом контейнера на основе разрешений, предоставленных SAS.
Сначала создайте объект BlobServiceClient, подписанный ключом доступа к учетной записи:
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);
Затем создайте SAS службы, как показано в предыдущем примере, и используйте SAS для авторизации объекта 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);
Определение хранимой политики доступа
Хранимая политика доступа обеспечивает дополнительный уровень управления подписанным URL-адресом уровня обслуживания (SAS) на стороне сервера. Установка хранимой политики доступа служит для группирования подписанных URL-адресов и предоставления дополнительных ограничений для подписей, связанных с политикой.
Для изменения времени начала, истечения срока действия или разрешений для подписи можно использовать хранимую политику доступа. Вы также можете использовать хранимую политику доступа для отзыва подписи после ее выдачи. В этом разделе рассматриваются контейнеры БОЛЬШИХ двоичных объектов, но хранимые политики доступа также поддерживаются для общих папок, очередей и таблиц.
Чтобы управлять хранимыми политиками доступа в ресурсе контейнера, вызовите один из следующих методов из объекта BlobContainerClient :
Создание или изменение хранимой политики доступа
За раз можно задать не более пяти политик доступа к ресурсу. Каждое SignedIdentifier поле с уникальным Id полем соответствует одной политике доступа. Попытка установить более пяти политик доступа одновременно приводит к тому, что служба возвращает код 400 (Bad Request)состояния.
В следующем примере кода показано, как создать две хранимые политики доступа в ресурсе контейнера:
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);
}
Вы также можете изменить существующую политику. В следующем примере кода показано, как изменить одну хранимую политику доступа для обновления даты окончания срока действия политики:
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);
}
Отмена или удаление хранимой политики доступа
Чтобы отменить хранимую политику доступа, корпорация Майкрософт рекомендует удалить подписанный идентификатор и создать новую. Изменение подписанного идентификатора нарушает связи между существующими подписями и хранимой политикой доступа. Удаление или изменение хранимой политики доступа немедленно влияет на все подписанные url-адреса, связанные с ним.
В следующем примере кода показано, как отменить политику, изменив Id свойство для подписанного идентификатора. Этот подход эффективно удаляет подписанный идентификатор и делает новый:
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);
}
Вы также можете удалить все политики доступа из ресурса контейнера, вызвав SetAccessPolicyAsync с пустым permissions параметром. В следующем примере показано, как удалить все хранимые политики доступа из указанного контейнера:
public static async Task DeleteStoredAccessPolicyAsync(BlobContainerClient containerClient)
{
// Remove all stored access policies for the container resource
await containerClient.SetAccessPolicyAsync();
}
Ресурсы
Дополнительные сведения о создании SAS службы с помощью клиентской библиотеки Хранилище BLOB-объектов Azure для .NET см. в следующих ресурсах.