Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
На уровне контейнера можно задать политику неизменяемости типа WORM (запись один раз, чтение много раз). Дополнительные сведения о неизменяемом хранилище для хранилища BLOB-объектов Azure см. в разделе "Хранение критически важных для бизнеса больших двоичных объектов" с использованием неизменяемого хранилища в режиме WORM (Write Once, Read Many)
Доступность
Политики WORM на уровне контейнера (CLW) доступны для всех новых и существующих контейнеров. Эти политики поддерживаются для учетных записей общего назначения версии 2, блочных BLOB-объектов класса Premium, общего назначения версии 1 (устаревшая версия) и для хранения BLOB-объектов (устаревшая версия).
Совет
Корпорация Майкрософт рекомендует обновить учетные записи общего назначения версии 1 до версии 2 общего назначения, чтобы воспользоваться дополнительными функциями. Сведения об обновлении существующей учетной записи хранения общего назначения версии 1 см. в статье Обновление учетной записи хранения.
Эта функция поддерживается для учетных записей иерархического пространства имен. Если включено иерархическое пространство имен, невозможно переименовать или переместить блоб, когда он находится в неизменяемом состоянии. Имя BLOB и структура каталогов предоставляют важные контейнерные данные, которые нельзя изменить после применения политики неизменности.
Для этой функции нет процесса включения; он автоматически доступен для всех контейнеров. Дополнительные сведения о настройке политики в новом или существующем контейнере см. в разделе "Настройка политик неизменяемости WORM на уровне контейнера".
Удаление
Контейнер с набором политик WORM уровня контейнера должен быть пустым перед удалением контейнера. Если в контейнере есть набор политик с включенным иерархическим пространством имен, каталог должен быть пуст, прежде чем его можно будет удалить.
Контейнер с политикой WORM, применённой на уровне контейнера, можно удалить только с помощью операций на уровне контрольной плоскости. Все такие запросы отправляются по URL-адресу Azure Resource Manager. Например, команда PowerShell Remove-AzRmStorageContainer использует операцию плоскости управления для удаления контейнера. В отличие от этого, команда Remove-AzStorageContainer пытается использовать операцию с плоскостью данных, которая не увенчается успехом. Аналогичным образом команда Azure CLI az storage container-rm delete использует операцию плоскости управления, в то время как az storage container delete зависит от операции плоскости данных. Контейнер можно также удалить на портале Azure, так как он выполняет задачу с помощью операции плоскости управления.
Сценарии
| Сценарий | Запрещенные операции | Защита BLOB-объектов | Защита контейнеров | Защита учетных записей |
|---|---|---|---|---|
| Контейнер защищен активной политикой хранения на основе времени, применяемой ко всему контейнеру, и/или временной блокировкой по юридическим причинам. | Удаление BLOB-объекта, вставка BLOB-объекта1, задание метаданных BLOB-объекта, вставка страницы, задание свойств BLOB-объекта, создание моментального снимка BLOB-объекта, инкрементное копирование BLOB-объекта, добавление блока2 | Все блобы в контейнере неизменяемы по содержимому и пользовательским метаданным. | Удаление контейнера не удается, если политика WORM на уровне контейнера действует. | Удаление учетной записи хранения не удаётся, если в контейнере есть хотя бы один объект BLOB. |
| Контейнер находится под защитой временной политики хранения, срок которой истёк и действуют только на контейнеры; юридическое удержание не применяется. | Вставка BLOB-объекта1, задание метаданных BLOB-объекта, вставка страницы, задание свойств BLOB-объекта, создание моментального снимка BLOB-объекта, инкрементное копирование BLOB-объекта, добавление блока2 | Операции удаления разрешены. Операции перезаписи не допускаются. | Удаление контейнера не удается, если в контейнере существует хотя бы один BLOB, независимо от того, заблокирована или разблокирована политика. | Удаление учетной записи службы хранилища завершается сбоем, если существует по крайней мере один контейнер с заблокированной политикой хранения на основе времени. Разблокированные политики не обеспечивают защиту от удаления. |
Замечание
Разблокированные политики не обеспечивают защиту от удаления.
Это относится к обоим:
- Контейнеры, защищенные активной, разблокированной политикой хранения на основе времени и/или юридическим удержанием (сценарий 1).
1 Служба хранилища Azure допускает использование операции Put Blob для создания нового объекта BLOB. Последующие операции перезаписи существующего пути блоба в неизменяемом контейнере не допускаются.
2 Операция добавления блока разрешена только для политик с включенным свойством allowProtectedAppendWrites или allowProtectedAppendWritesAll.
Разрешить запись в защищённые добавочные BLOB-объекты
Добавляемые BLOB-объекты состоят из блоков данных и оптимизированы для операций добавления данных, необходимых для сценариев аудита и ведения журналов. По замыслу, BLOB-объекты с добавлением позволяют только добавлять новые блоки в конец объекта. Независимо от незыблемости, изменение или удаление существующих блоков в добавляемом двоичном объекте категорически запрещается. Дополнительные сведения о добавочных BLOB-объектах см. в разделе О добавочных BLOB-объектах.
Параметр allowProtectedAppendWrites позволяет писать новые блоки в блоб добавления, обеспечивая защиту от изменений и соблюдение соответствия требованиям. Если это значение включено, вы можете создать добавочный BLOB-объект непосредственно в защищенном политикой контейнере и продолжить добавлять новые блоки данных в конец добавочного BLOB-объекта с помощью операции Append Block. Можно добавлять только новые блоки; существующие блоки изменять или удалять нельзя. Включение этого параметра не влияет на поведение блочных или страничных BLOB-объектов.
Параметр свойства AllowProtectedAppendWritesAll предоставляет те же разрешения, что и свойство allowProtectedAppendWrites, и добавляет возможность записи новых блоков в блоб с блочным хранением. API Хранилища объектов Blob не предоставляет приложениям возможность осуществлять это напрямую. Однако приложения могут выполнить это с помощью методов добавления и очистки, доступных в API Data Lake Storage. Кроме того, это свойство позволяет приложениям Майкрософт, таким как Фабрика данных Azure, добавлять блоки данных с помощью внутренних API. Если рабочие нагрузки зависят от любого из этих средств, используйте это свойство, чтобы избежать ошибок, которые могут появляться при попытке добавить данные в BLOB-объекты.
Append blobs остаются в неизменяемом состоянии в течение эффективного периода хранения. Поскольку могут быть добавлены новые данные, помимо первоначального создания большого двоичного объекта, существует небольшая разница в способе определения срока хранения. Эффективный срок хранения — это разница между временем последнего изменения добавочного BLOB-объекта и заданным пользователем периодом хранения. Аналогично, когда интервал хранения продлевается, при вычислении действующего периода хранения неизменяемое хранилище использует самое последнее значение указываемого пользователем интервала хранения.
Например, предположим, что пользователь создает политику хранения на основе времени с включенным свойством AllowProtectedAppendWrites и интервалом хранения 90 дней. Сегодня в контейнере создается добавочный BLOB-объект logblob1, и новые журналы будут добавляться в этот добавочный BLOB-объект в течение следующих 10 дней. Таким образом, действующий период хранения в случае logblob1 составит 100 дней начиная с сегодняшнего дня (время последнего добавления + 90 дней).
Политики хранения, основанные на разблокированном времени, позволяют включать и выключать параметры свойств allowProtectedAppendWrites и AllowProtectedAppendWritesAll в любое время. После блокировки политики хранения на основе времени невозможно изменить параметры свойств allowProtectedAppendWrites и AllowProtectedAppendWritesAll .
Ограничения
Для учетной записи хранения данных максимальное количество контейнеров с неизменяемой политикой (временем хранения или юридическим удержанием) составляет 10 000.
Для контейнера максимальное число тегов юридического удержания в любое время равно 10.
Минимальная длина тега юридического удержания составляет 3 буквенно-цифровых символа. Максимальная длина составляет 23 буквенно-цифровых символа.
Для контейнера на протяжении действия политики сохраняются не более 10 журналов аудита политики юридического удержания.
Рекурсивные удаления для каталогов блокируются при наличии политики неизменяемости контейнера. Чтобы удалить каталог, убедитесь, что сначала он пуст, а затем удаляется без рекурсивного флага.