Настройка ACL контейнера

Статья
12/15/2024

Операция Set Container ACL задает разрешения для указанного контейнера. Разрешения указывают, доступны ли большие двоичные объекты в контейнере общедоступным образом.

По состоянию на версию 2009-09-19 разрешения контейнера предоставляют следующие параметры управления доступом к контейнерам:

полный открытый доступ на чтение: данные контейнера и больших двоичных объектов можно считывать с помощью анонимного запроса. Клиенты могут перечислять большие двоичные объекты в контейнере с помощью анонимного запроса, но не могут перечислять контейнеры в учетной записи хранения.
общедоступный доступ на чтение только для больших двоичных объектов: данные BLOB-объектов в этом контейнере можно считывать с помощью анонимного запроса, но данные контейнера недоступны. Клиенты не могут перечислять большие двоичные объекты в контейнере с помощью анонимного запроса.
Нет общедоступного доступа на чтение: данные контейнера и больших двоичных объектов можно считывать только владельцем учетной записи.

Set Container ACL также задает хранимую политику доступа для использования с подписанными URL-адресами. Дополнительные сведения см. в статье Определение хранимой политики доступа.

Все общедоступные доступы к контейнеру анонимны, так как доступ осуществляется через подписанный URL-адрес.

Просьба

Запрос Set Container ACL может быть создан следующим образом. Рекомендуется использовать ПРОТОКОЛ HTTPS. Замените myaccount именем учетной записи хранения:

Метод	URI запроса	ВЕРСИЯ HTTP
`PUT`	`https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=acl`	HTTP/1.1

Запрос службы эмулированного хранилища

При выполнении запроса к эмулированной службе хранилища укажите имя узла эмулятора и порт службы BLOB-объектов как 127.0.0.1:10000, а затем имя эмулированной учетной записи хранения:

Метод	URI запроса	ВЕРСИЯ HTTP
`PUT`	`http://127.0.0.1:10000/devstoreaccount1/mycontainer?restype=container&comp=acl`	HTTP/1.1

Дополнительные сведения см. в статье Использование эмулятора Azurite для разработки локальной службы хранилища Azure.

Параметры URI

В URI запроса можно указать следующие дополнительные параметры:

Параметр	Описание
`timeout`	Необязательный. Параметр `timeout` выражается в секундах. Дополнительные сведения см. в разделе Настройка времени ожидания для операций службы BLOB-объектов.

Заголовки запросов

Обязательные и необязательные заголовки запросов описаны в следующей таблице:

Заголовок запроса	Описание
`Authorization`	Обязательно. Указывает схему авторизации, имя учетной записи и подпись. Дополнительные сведения см. в статье Авторизация запросов к службе хранилища Azure.
`Date` или `x-ms-date`	Обязательно. Указывает универсальное время (UTC) для запроса. Дополнительные сведения см. в статье Авторизация запросов к службе хранилища Azure.
`x-ms-version`	Необязательный. Указывает версию операции, используемой для этого запроса. Дополнительные сведения см. в разделе Управление версиями служб хранилища Azure.
`x-ms-blob-public-access`	Необязательный. Указывает, могут ли данные в контейнере получать общедоступный доступ и уровень доступа. Возможные значения: - `container`. Указывает полный общедоступный доступ на чтение для данных контейнера и BLOB-объектов. Клиенты могут перечислять большие двоичные объекты в контейнере с помощью анонимного запроса, но не могут перечислять контейнеры в учетной записи хранения. - `blob:` Указывает общедоступный доступ на чтение для больших двоичных объектов. Данные BLOB-объектов в этом контейнере можно считывать с помощью анонимного запроса, но данные контейнера недоступны. Клиенты не могут перечислять большие двоичные объекты в контейнере с помощью анонимного запроса. Если этот заголовок не включен в запрос, данные контейнера являются частными для владельца учетной записи. Обратите внимание, что установка общедоступного доступа для контейнера в учетной записи хранения Azure Premium не разрешена.
`x-ms-lease-id: <ID>`	Необязательно, версия 2012-02-12 и более поздняя. Если он указан, `Set Container ACL` успешно выполняется только в том случае, если аренда контейнера активна и соответствует этому идентификатору. Если нет активной аренды или идентификатор не соответствует, возвращается значение 412 (сбой предварительных условий).
`x-ms-client-request-id`	Необязательный. Предоставляет созданное клиентом непрозрачное значение с ограничением символов 1-kibibyte (KiB), записанным в журналах при настройке ведения журнала. Настоятельно рекомендуется использовать этот заголовок для сопоставления действий на стороне клиента с запросами, получаемыми сервером. Дополнительные сведения см. в статье Monitorхранилища BLOB-объектов Azure.

Эта операция также поддерживает использование условных заголовков для выполнения операции, только если задано условие. Дополнительные сведения см. в разделе Указание условных заголовков для операций службы BLOB-объектов.

Текст запроса

Чтобы указать хранимую политику доступа, укажите уникальный идентификатор и политику доступа в тексте запроса для операции Set Container ACL.

Элемент SignedIdentifier включает уникальный идентификатор, указанный в элементе Id, и сведения о политике доступа, как указано в элементе AccessPolicy. Максимальная длина уникального идентификатора составляет 64 символа.

Поля Start и Expiry должны быть выражены в формате UTC и должны соответствовать допустимому формату ISO 8061. Поддерживаемые форматы ISO 8061 включают следующие:

YYYY-MM-DD
YYYY-MM-DDThh:mmTZD
YYYY-MM-DDThh:mm:ssTZD
YYYY-MM-DDThh:mm:ss.fffffffTZD

Для части этих форматов YYYY представляет собой четырехзначное представление года, MM является двухзначным представлением месяца, а DD — двухзначное представление дня. Для части времени hh является представлением часа в 24-часовой нотации, mm является двухзначным представлением минуты, ss является двухзначным вторым представлением, и fffffff является семизначным миллисекундным представлением. Конструктор времени T отделяет части строки даты и времени, а конструктор часовых поясов TZD указывает часовой пояс.

<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>unique-64-character-value</Id>  
    <AccessPolicy>  
      <Start>start-time</Start>  
      <Expiry>expiry-time</Expiry>  
      <Permission>abbreviated-permission-list</Permission>  
    </AccessPolicy>  
  </SignedIdentifier>  
</SignedIdentifiers>

Пример запроса

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=acl HTTP/1.1  
  
Request Headers:  
x-ms-version: 2011-08-18  
x-ms-date: Sun, 25 Sep 2011 00:42:49 GMT  
x-ms-blob-public-access: container  
Authorization: SharedKey myaccount:V47F2tYLS29MmHPhiR8FyiCny9zO5De3kVSF0RYQHmo=  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=</Id>  
    <AccessPolicy>  
      <Start>2009-09-28T08:49:37.0000000Z</Start>  
      <Expiry>2009-09-29T08:49:37.0000000Z</Expiry>  
      <Permission>rwd</Permission>  
    </AccessPolicy>  
  </SignedIdentifier>  
</SignedIdentifiers>

Ответ

Ответ включает код состояния HTTP и набор заголовков ответа.

Код состояния

Успешная операция возвращает код состояния 200 (ОК).

Дополнительные сведения о кодах состояния см. в коды состояния и коды ошибок.

Заголовки ответа

Ответ для этой операции содержит следующие заголовки. Ответ также может включать дополнительные стандартные заголовки HTTP. Все стандартные заголовки соответствуют спецификации протокола HTTP/1.1.

Заголовок ответа	Описание
`ETag`	ETag для контейнера. Если версия запроса — 2011-08-18 или более поздняя, значение ETag заключено в кавычки.
`Last-Modified`	Возвращает дату и время последнего изменения контейнера. Формат даты следует RFC 1123. Дополнительные сведения см. в разделе Представление значений даты и времени в заголовках. Любая операция, изменяющая контейнер или его свойства или метаданные, обновляет время последнего изменения, включая настройку разрешений контейнера. Операции с большими двоичными объектами не влияют на время последнего изменения контейнера.
`x-ms-request-id`	Уникально идентифицирует выполненный запрос и может использоваться для устранения неполадок запроса. Дополнительные сведения см. в статье Устранение неполадок с операциями API
`x-ms-version`	Указывает версию службы BLOB-объектов, которая использовалась для выполнения запроса. Этот заголовок возвращается для запросов к версии 2009-09-19 и более поздних версий.
`Date`	Значение даты и времени в формате UTC, созданное службой, указывающее время, когда был инициирован ответ.
`x-ms-client-request-id`	Можно использовать для устранения неполадок запросов и соответствующих ответов. Значение этого заголовка равно значению заголовка `x-ms-client-request-id`, если оно присутствует в запросе, а значение содержит не более 1024 видимых символов ASCII. Если в запросе отсутствует заголовок `x-ms-client-request-id`, он не будет присутствовать в ответе.

Пример ответа

Response Status:  
HTTP/1.1 200 OK  
  
Response Headers:  
Transfer-Encoding: chunked  
Date: Sun, 25 Sep 2011 22:42:55 GMT  
ETag: "0x8CB171613397EAB"  
Last-Modified: Sun, 25 Sep 2011 22:42:55 GMT  
x-ms-version: 2011-08-18  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

Авторизация

Авторизация требуется при вызове любой операции доступа к данным в службе хранилища Azure. Вы можете авторизовать операцию Set Container ACL, как описано ниже.

Важный

Корпорация Майкрософт рекомендует использовать идентификатор Microsoft Entra с управляемыми удостоверениями для авторизации запросов в службу хранилища Azure. Идентификатор Microsoft Entra обеспечивает более высокую безопасность и удобство использования по сравнению с авторизацией общего ключа.

идентификатора Microsoft Entra (рекомендуется)
общий ключ

Служба хранилища Azure поддерживает использование идентификатора Microsoft Entra для авторизации запросов к данным BLOB-объектов. С помощью идентификатора Microsoft Entra можно использовать управление доступом на основе ролей Azure (Azure RBAC) для предоставления разрешений субъекту безопасности. Субъект безопасности может быть пользователем, группой, субъектом-службой приложений или управляемым удостоверением Azure. Субъект безопасности проходит проверку подлинности с помощью идентификатора Microsoft Entra для возврата маркера OAuth 2.0. Затем маркер можно использовать для авторизации запроса к службе BLOB-объектов.

Дополнительные сведения об авторизации с помощью идентификатора Microsoft Entra см. в статье Авторизация доступа к большим двоичным объектам с помощью идентификатора Microsoft Entra ID.

Разрешения

Ниже приведены действия RBAC, необходимые для пользователя Microsoft Entra, группы, управляемого удостоверения или субъекта-службы для вызова операции Set Container ACL и минимально привилегированной встроенной роли Azure RBAC, которая включает в себя следующее:

действие Azure RBAC:Microsoft.Storage/storageAccounts/blobServices/container/setAcl/action
встроенная роль с минимальными привилегиями:владельца данных BLOB-объектов хранилища

Дополнительные сведения о назначении ролей с помощью Azure RBAC см. в статье Назначение роли Azure для доступа к данным BLOB-объектов.

Замечания

При установке разрешений для контейнера заменяются существующие разрешения. Чтобы обновить разрешения контейнера, вызовите получить ACL контейнера, чтобы получить все политики доступа, связанные с контейнером. Измените политику доступа, которую вы хотите изменить, а затем вызовите Set Container ACL с полным набором данных для выполнения обновления.

Включить анонимный общедоступный доступ к данным контейнера

Чтобы включить анонимный общедоступный доступ на чтение данных контейнера, вызовите Set Container ACL с заголовком x-ms-blob-public-access, равным container или blob. Чтобы отключить анонимный доступ, вызовите Set Container ACL без указания заголовка x-ms-blob-public-access.

Если x-ms-blob-public-access задано значение blob, клиенты могут вызывать следующие операции анонимно:

получение большого двоичного объекта
получение свойств BLOB-объектов
получение метаданных BLOB-объектов
получить список блокировок (только для зафиксированного списка блокировок)
получение диапазонов страниц

Если x-ms-blob-public-access задано значение container, клиенты могут вызывать следующие операции анонимно:

Операции доступа к BLOB-объектам, перечисленные в предыдущем разделе.
получение свойств контейнера
получение метаданных контейнера
список больших двоичных объектов

Установка политик доступа на уровне контейнера

Хранимая политика доступа может указать время начала, срок действия и разрешения для подписей общего доступа, с которыми он связан. В зависимости от способа управления доступом к контейнеру или ресурсу BLOB-объектов можно указать все эти параметры в политике сохраненного доступа и опустить их из URL-адреса для подписанного URL-адреса подписанного URL-адреса. Таким образом, вы можете изменить поведение связанной подписи в любое время или отозвать его. Или можно указать один или несколько параметров политики доступа в хранимой политике доступа и другие параметры в URL-адресе. Наконец, можно указать все параметры в URL-адресе. В этом случае можно использовать хранимую политику доступа для отзыва подписи, но не для изменения его поведения. Дополнительные сведения см. в статье Определение хранимой политики доступа.

Вместе подписанный URL-адрес и хранимая политика доступа должны включать все поля, необходимые для авторизации подписи. Если отсутствуют необходимые поля, запрос завершается ошибкой. Аналогичным образом, если поле указано как в URL-адресе подписанного URL-адреса, так и в хранимой политике доступа запрос завершается ошибкой с кодом состояния 400 (недопустимый запрос).

По крайней мере пять отдельных политик доступа можно задать для одного контейнера в любое время. Если в тексте запроса передаются более пяти политик доступа, служба возвращает код состояния 400 (недопустимый запрос).

Подпись общего доступа может быть выдана в контейнере или BLOB-объекте независимо от того, доступны ли данные контейнера для анонимного доступа на чтение. Подписанный URL-адрес обеспечивает большую меру контроля над тем, как, когда и кому предоставляется ресурс.

Заметка

При установке хранимой политики доступа в контейнере политика может занять до 30 секунд. В течение этого интервала, пока политика не станет активной, подписанный URL-адресом, связанный с хранимой политикой доступа, завершается сбоем с кодом состояния 403 (запрещено).

Выставления счетов

Запросы цен могут возникать от клиентов, использующих API хранилища BLOB-объектов, непосредственно через REST API хранилища BLOB-объектов или из клиентской библиотеки службы хранилища Azure. Эти запросы начисляют плату за транзакцию. Тип транзакции влияет на то, как взимается учетная запись. Например, транзакции чтения начисляются в другую категорию выставления счетов, чем операции записи. В следующей таблице показана категория выставления счетов для запросов Set Container ACL на основе типа учетной записи хранения:

Операция	Тип учетной записи хранения	Категория выставления счетов
Настройка ACL контейнера	Большой двоичный объект класса Premium Стандартный общего назначения версии 2	Другие операции
Настройка ACL контейнера	Стандартный общего назначения версии 1	Операции записи

Дополнительные сведения о ценах на указанную категорию выставления счетов см. в цен на хранилище BLOB-объектов Azure.

См. также

Ограничить доступ к контейнерам и большим двоичным объектам
Делегирование доступа с помощью подписанного URL-адреса
Создание и использование подписанного URL-адреса
Определение хранимой политики доступа
получение списка ACL контейнера
Авторизация запросов в службу хранилища Azure
коды состояния и ошибок
коды ошибок службы BLOB-объектов

Поделиться через