Создание 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 службы подписан ключом доступа к учетной записи. Вы можете использовать класс служба хранилища SharedKeyCredential для создания учетных данных, используемых для подписи SAS службы.

Вы также можете использовать хранимую политику доступа для определения разрешений и длительности SAS. Если указано имя существующей хранимой политики доступа, то эта политика будет связана с SAS. Дополнительные сведения о хранимых политиках доступа см. в статье "Определение хранимой политики доступа". Если хранимая политика доступа не указана, в примерах кода в этой статье показано, как определить разрешения и длительность SAS.

Создание SAS службы для BLOB-объекта

В следующем примере кода показано, как создать SAS службы для ресурса БОЛЬШОго двоичного объекта. Сначала код проверяет, разрешен ли объект BLOBClient с учетными данными общего ключа, проверка свойству CanGenerateSasUri. Затем он создает SAS службы через класс BlobSasBuilder и вызывает GenerateSasUri для создания URI SAS службы на основе объектов клиента и построителя.

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;
    }
}

Использование SAS службы для авторизации клиентского объекта

В следующем примере кода показано, как использовать SAS службы для авторизации объекта BLOBClient . Этот клиентский объект можно использовать для выполнения операций с ресурсом BLOB-объектов на основе разрешений, предоставленных 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 для авторизации объекта 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);

Определение хранимой политики доступа

Хранимая политика доступа обеспечивает дополнительный уровень управления подписанным 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 см. в следующих ресурсах.

Ресурсы клиентской библиотеки

См. также