Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Неизменяемое хранилище для Хранилище BLOB-объектов Azure позволяет хранить критически важные бизнес-данные в состоянии WORM (однократная запись, многократное чтение). В состоянии WORM данные не могут быть изменены или удалены в течение заданного пользователем интервала. Настроив политики неизменяемости для BLOB-объектов, вы можете защитить данные от перезаписи и удаления.
Неизменяемое хранилище Azure Blob поддерживает два типа неизменяемых политик:
Политики хранения на основе времени: пользователи могут настраивать политики для хранения данных в течение определенного интервала. Когда установлена политика хранения на основе времени, объекты можно создавать и читать, но нельзя изменять и удалять. По истечении срока хранения объекты могут быть удалены, но не перезаписаны.
Юридические удержания: юридическое удержание позволяет хранить неизменяемые данные до тех пор, пока оно не будет явно отменено. Когда установлено удержание по юридическим причинам, объекты можно создавать и читать, но нельзя изменять и удалять.
Вы можете собрать эти полисы вместе. Например, можно одновременно задать на одном и том же уровне как политику хранения на определённый срок, так и юридическое удержание. Чтобы запись была успешной, у вас должно быть либо включено версионирование, либо не должно быть ни юридического удержания, ни политики хранения на основе времени для данных. Для успешного удаления не должно быть юридической политики удержания или времени хранения данных.
Следующая диаграмма показывает, как политики хранения на основе времени и юридические ограничения предотвращают операции записи и удаления во время их действия.
Существует две особенности в области неизменяемого хранилища: WORM на уровне контейнера и WORM на уровне версии. Контейнерный WORM позволяет устанавливать политики только на уровне контейнера, тогда как WORM на уровне версии — на уровне учетной записи, контейнера или версии.
О неизменяемом хранилище BLOB-объектов
Неизменяемое хранение помогает медицинским организациям, финансовым учреждениям и смежным отраслям (особенно брокер-дилерским организациям) безопасно хранить данные. Неизменяемое хранилище можно использовать в любом сценарии для защиты критически важных данных от изменения или удаления.
Распространенные приложения включают следующее.
Соответствие нормативным требованиям: хранение данных в неизменяемом виде в хранилище BLOB-объектов Azure помогает организациям соответствовать SEC 17a-4(f), CFTC 1.31(d), FINRA и другим нормам.
Безопасное хранение документов: неизменяемое хранилище BLOB-объектов гарантирует, что ни один пользователь, даже администратор учетной записи, не сможет изменить или удалить данные.
Юридическое удержание: Неизменяемое хранилище для больших двоичных объектов позволяет хранить конфиденциальную информацию, критически важную для судебных разбирательств или ведения бизнеса, в защищенном от изменений состоянии в течение необходимого периода, пока не будет снято удержание. Эта функция не ограничивается только юридическими вариантами использования, но также может рассматриваться как удержание на основе событий или блокировка предприятия, где требуется защитить данные на основе триггеров событий или корпоративной политики.
Соблюдение нормативных требований
Корпорация Майкрософт наняла ведущую независимую аудиторскую компанию Cohasset Associates, специализирующуюся на управлении записями и информационной политике, для оценки неизменяемого хранилища для BLOB-объектов и его соответствия требованиям, специфическим для индустрии финансовых услуг. Компания Cohasset подтвердила, что неизменяемое хранилище, используемое для хранения BLOB-объектов в состоянии WORM, соответствует требованиям к хранению, установленным в правилах CFTC 1.31(c)-(d), FINRA 4511 и Правиле SEC 17a-4(f). Корпорация Майкрософт ориентируется на этот набор правил, так как они представляют собой наиболее полное нормативное руководство по хранению записей для финансовых учреждений.
Отчет Cohasset доступен в центре управления безопасностью Майкрософт. Центр управления безопасностью Azure содержит подробные сведения о сертификатах соответствия Майкрософт. Чтобы запросить письмо аттестации от Корпорации Майкрософт относительно неизменяемости WORM, обратитесь в службу поддержки Azure.
Политики управления временем хранения
В течение указанного интервала данные блоб-объектов хранятся в формате WORM согласно политике хранения на основе времени. Когда вы устанавливаете политику сохранения по времени, клиенты могут создавать и читать блобы, но не могут их изменять или удалять. После окончания интервала сохранения blob-ы можно удалить, но не перезаписывать.
Область
Вы можете настроить политику удержания на основе времени в следующих областях:
- Политика WORM на уровне версии: Настройте политику хранения с ограничением по времени на уровне учетной записи, контейнера или версии (в учетной записи должно быть включено управление версиями). Если настроить политику на уровне учетной записи или контейнера, все BLOB-объекты в соответствующей учетной записи или контейнере наследуют эту политику. Если для контейнера установлено юридическое удержание, вы не можете создать WORM на уровне версий для этого же контейнера. Это ограничение существует потому, что юридический блок не позволяет генерировать версии.
- Политика WORM на уровне контейнера: политика хранения на основе времени, настроенная на уровне контейнера, применяется ко всем BLOB-объектам в этом контейнере. Нельзя настроить отдельные блоки с их собственными политиками неизменяемости.
Интервал хранения для политики на основе времени
Минимальный интервал хранения для политики хранения на основе времени составляет один день, а максимальный — 146 000 дней (400 лет). При настройке политики хранения на основе времени затронутые объекты остаются в неизменяемом состоянии в течение действующего периода хранения. Эффективный период хранения объекта равен разнице между временем создания объекта и заданным пользователем интервалом хранения. Поскольку интервал хранения в политике продлевается, при вычислении действующего периода хранения неизменяемое хранилище будет использовать самое последнее значение указываемого пользователем интервала хранения.
Пример: пользователь создает политику хранения на основе времени с пятилетним периодом удержания. Существующий BLOB-объект в этом контейнере testblob1 создан год назад. Таким образом, действующий период хранения в случае testblob1 составляет четыре года. Когда в контейнер загружается новый BLOB-объект testblob2, действующий период хранения testblob2 составляет пять лет с момента его создания.
Заблокированные и незаблокированные политики
При первой настройке политики хранения на основе времени политика разблокируется в целях тестирования. После завершения тестирования можно заблокировать политику, чтобы она полностью соответствовала требованиям SEC 17a-4(f) и другим нормативным требованиям.
И заблокированные, и незаблокированные политики защищены от операций удаления и перезаписи. Однако вы можете изменить незаблокированную политику путем сокращения или продления периода хранения. Незаблокированную политику можно также удалить. Заблокированную политику хранения на основе времени удалить не удастся. Вы можете продлить период хранения, но его нельзя сократить. За время существования заблокированной политики, определенной на уровне контейнера, разрешается продлевать действующий период хранения не более пяти раз. В случае политики, настроенной для версии блоба, не существует ограничений на количество продлений периода действия.
Внимание
Политика хранения на основе времени должна быть заблокирована, чтобы blob-объект находился в неизменяемом состоянии (защищенном от изменения и удаления) в соответствии с SEC 17a-4(f) и другими нормативными требованиями. Майкрософт рекомендует блокировать политику в течение приемлемого времени, обычно менее 24 часов. Хотя разблокированное состояние обеспечивает защиту от неизменяемости, мы не рекомендуем использовать его для чего-либо, кроме краткосрочных тестов.
Ведение журнала аудита политики хранения данных
Каждый контейнер с политикой хранения на основе времени включает журнал аудита политики. Журнал аудита содержит до семи команд временного хранения для заблокированных политик хранения на основе времени. Ведение журнала обычно начинается после фиксации политики. В число записей журнала входят записи с ИД пользователя, типом команды, метками времени и интервалом хранения. Журнал аудита сохраняется в течение времени существования политики в соответствии с нормативными правилами SEC 17a-4(f).
Журнал действий Azure представляет собой более полный реестр сведений обо всех действиях службы управления. В журналах ресурсов Azure хранятся сведения об операциях с данными. Вы несёте ответственность за постоянное хранение этих логов, как это может потребоваться для нормативных или иных целей.
Изменения политик хранения на основе времени на уровне версии не подлежат аудиту.
Удержания по юридическим причинам
Удержание по юридическим причинам — это временная политика неизменяемости, которую можно применить для юридических целей или общей защиты. Легальная блокировка хранит данные blob в формате Write Once, Read Many (WORM) до тех пор, пока блокировка не будет явно устранена. Когда действует юридический запрет на изменение, объекты blob можно создавать и читать, но нельзя изменять или удалять. Используйте удержание по юридическим причинам, если неизвестно, как долго данные должны храниться в состоянии WORM.
Область
Удержание по юридическим причинам можно настроить, выбрав любую из следующих областей действия:
Политика WORM на уровне версии: для отдельной версии BLOB-объекта можно настроить юридическое удержание для точного управления конфиденциальными данными (для учетной записи должно быть включено управление версиями).
Политика WORM на уровне контейнера: юридическое удержание, настроенное на уровне контейнера, применяется ко всем объектам в этом контейнере. Настраивать отдельные объекты, указывая для них собственные политики неизменяемости, нельзя.
Теги
Вы должны связать юридическую блокировку на уровне контейнера с одной или несколькими пользовательскими алфавитно-цифровыми тегами, которые служат строками идентификаторов. Например, тег может содержать идентификатор дела или имя события.
Ведение журнала аудита
Каждый контейнер с удержанием по юридическим причинам содержит журнал аудита политики. Журнал содержит идентификатор пользователя, тип команды, отметки времени и теги удержания по юридическим причинам. Журнал аудита сохраняется в течение времени существования политики в соответствии с нормативными правилами SEC 17a-4(f).
Журнал действий Azure представляет собой более полный реестр сведений обо всех действиях службы управления. В журналах ресурсов Azure хранятся сведения об операциях с данными. Вы несёте ответственность за постоянное хранение этих логов, как это может потребоваться для нормативных или иных целей.
Изменения юридических удержаний на уровне версии не проверяются.
Неизменяемые возможности хранилища
В следующей таблице показана разбивка различий между WORM уровня контейнера и WORM уровня версии:
| Категория | WORM на уровне контейнера | WORM на уровне версии |
|---|---|---|
| Уровень детализации политики | Настраивайте политики только на уровне контейнера. Каждый объект, который вы загружаете в контейнер, наследует набор политик неизменяемости. | Настройте политики на уровне учетной записи, контейнера или BLOB-объекта. Если вы установите политику на уровне учетной записи, все блобы, которые вы загружаете в эту учетную запись, унаследуют эту политику. Та же логика применяется к контейнерам. Если вы устанавливаете политику на нескольких уровнях, порядок приоритета всегда будет Blob -> Container -> Account. |
| Доступные типы политик | Установите два разных типа политик на уровне контейнера: политики хранения на основе времени и юридические блокировки. | На уровне аккаунта и контейнера устанавливайте только политику удержания, основанную на времени. На уровне большого двоичного объекта задайте как политики хранения на основе времени, так и юридические удержания. |
| Зависимости компонентов | Другие функции не являются предварительным условием или требованием для работы этой функции. | Управление версиями является необходимым условием для использования этой функции. |
| Активация для существующих аккаунтов и контейнеров | Включите эту функцию в любое время для существующих контейнеров. | В зависимости от уровня детализации эта функция может быть не включена для всех существующих аккаунтов и контейнеров. |
| Удаление учетной записи или контейнера | После того как вы заблокируете временную политику удержания контейнера, вы можете удалить контейнеры только если они пусты. | После включения WORM на уровне версий для учетной записи или контейнера их можно удалить, только если они пусты. |
| Поддержка Azure Data Lake Storage (аккаунты хранения с активированным иерархическим пространством имен) | Поддержка WORM-политик на уровне контейнера в аккаунтах с иерархическим пространством имён. | Политики WORM на уровне версий пока не поддерживаются в аккаунтах с иерархическим пространством имён. |
Чтобы узнать больше о WORM на уровне контейнера, см. политики WORM на уровне контейнера. Чтобы узнать больше о WORM на уровне версии, см. политики WORM на уровне версии.
WORM на уровне контейнера и на уровне версии
В следующей таблице показано, какой тип политики WORM следует использовать.
| Критерии | Использование WORM на уровне контейнера | Использование WORM на уровне версии |
|---|---|---|
| Организация данных | Нужно настроить политики для конкретных наборов данных, которые можно классифицировать по контейнерам. Все данные в этом контейнере должны храниться в состоянии WORM в течение одного и того же времени. | Невозможно группировать объекты по периодам хранения. Все blob-ы должны храниться с индивидуальным временем хранения в зависимости от сценариев этого blob-а, иначе нагрузка смешанная, так что некоторые группы данных можно сгруппировать в контейнеры, а другие — нельзя. Вы также можете задать политики на уровне контейнера и BLOB-объектов в одной учетной записи. |
| Объем данных, требующих неизменяемой политики | Вам не нужно устанавливать политики на более чем 10 000 контейнеров для каждой учетной записи. | Вы хотите установить политики для всех данных или больших объёмов, которые можно разделить по аккаунтам. Вы знаете, что при использовании WORM на уровне контейнера вам придется превысить лимит в 10 000 контейнеров. |
| Интерес к включению управления версиями | Вы не хотите иметь дело с включением управления версиями из-за затрат или из-за того, что рабочая нагрузка создаст множество дополнительных версий. | Вы хотите использовать управление версиями или не возражаете против него. Вы знаете, что если не включить версионирование, нельзя сохранять изменения или перезаписи неизменяемых BLOB-объектов как отдельные версии. |
| Расположение хранилища (хранилище BLOB-объектов и Data Lake Storage) | Рабочая нагрузка полностью ориентирована на Azure Data Lake Storage. У вас нет немедленного интереса или плана переключиться на использование учетной записи, которая не включает функцию иерархического пространства имен. | Рабочая нагрузка находится в хранилище Blob в учетной записи, которая не имеет функции иерархического пространства имен, поэтому теперь можно использовать WORM уровня версии. Либо вы готовы подождать, когда управление версиями станет доступно для учетных записей с включенным иерархическим пространством имен (Azure Data Lake Storage). |
Уровни доступа
Все уровни доступа к BLOB-объектам поддерживают неизменяемое хранилище. Вы можете изменить уровень доступа blob с помощью операции Set Blob Tier . Дополнительные сведения см. в разделе Уровни доступа для данных BLOB.
Конфигурации резервирования
Все конфигурации избыточности поддерживают неизменяемое хранилище. Дополнительные сведения о конфигурациях избыточности см. в разделе Избыточность хранилища Azure.
Рекомендуемые типы BLOB-объектов
Майкрософт рекомендует настраивать политики неизменности в основном для блочных и добавочных BLOB-объектов. Настраивать политику неизменяемости для страничного BLOB-объекта, в котором хранится VHD-диск активной виртуальной машины, не рекомендуется, так как операции записи на диск блокируются, а если включено управление версиями, то каждая запись сохраняется как новая версия. Майкрософт рекомендует внимательно изучить документацию и протестировать сценарии, прежде чем блокировать любые политики, основанные на времени.
Неизменяемое хранилище с функцией мягкого удаления BLOB-объектов
Когда вы настраиваете blob soft delete для аккаунта хранилища, это применяется ко всем blob-ам внутри аккаунта, независимо от того, действует ли юридическая или временная политика удержания. Корпорация Майкрософт рекомендует включить мягкое удаление для дополнительной защиты перед применением любых политик неизменяемости.
Если вы включите мягкое удаление blob, а затем настроите политику неизменяемости, все blobs, которые вы уже удалили, будут навсегда удалены после истечения политики мягкого удаления. Вы можете восстановить мягко удалённые blob-ы в период сохранения мягкого удаления. Блоб или версия, которую вы ещё не удалили, защищены политикой неизменяемости и не могут быть удалены до истечения политики сохранения по времени или после снятия юридической блокировки.
Отслеживание политик неизменности с помощью инвентаризации BLOB-объектов
Инвентаризация BLOB в служба хранилища Azure предоставляет обзор контейнеров в учетных записях хранения, объектов BLOB, моментальных снимков и версий этих объектов. Отчет об инвентаризации блоб-объектов помогает понять свойства блоб-объектов и контейнеров, в том числе наличие настроенной для ресурса политики неизменяемости.
При включении инвентаризации BLOB-объектов служба хранилища Azure ежедневно создает отчет инвентаризации. Отчет содержит общие сведения о ваших бизнес-данных и требованиях соответствия.
Дополнительные сведения см. в статье об инвентаризации BLOB-объектов службы хранилища Azure.
Примечание.
Вы не можете настроить политику инвентаризации в аккаунте, если поддержка неизменности на уровне версии включена на этом аккаунте или если поддержка неизменности на уровне версии включена в контейнере назначения, который вы определили в политике инвентаризации.
Настройка правил в крупном масштабе
Вы можете использовать задачу хранения для настройки политик неизменяемости в масштабе между несколькими аккаунтами хранения на основе определенного вами набора условий. Задача хранения — это ресурс, доступный в служба хранилища Azure Actions; бессерверная платформа, которую можно использовать для выполнения стандартных операций с данными для миллионов объектов в нескольких учетных записях хранилища. Дополнительные сведения см. в статье "Что такое действия службы хранилища Azure"?
Цены
Плата за использование неизменяемого хранилища не взимается. Неизменяемые данные оцениваются так же, как изменяемые. Если вы используете WORM на уровне версии, счет может быть выше, потому что вы включили версионирование, и есть расходы на сохранение дополнительных версий. Дополнительные сведения см. в политике ценообразования на управление версиями. Информацию о ценах на хранилище BLOB-объектов Azure см. на этой странице.
Создание или удаление политики хранения, основанной на времени, или юридического удержания для версии BLOB приводит к списанию платы за транзакцию записи. Изменение политики удержания по времени (либо блокировка, либо продление) приводит к сбору за другие операции. Для получения дополнительной информации о сборах за транзакции см. раздел «Операции и передача данных».
Если вы не платите счет и ваша учетная запись имеет активную политику хранения на основе времени, обычные политики хранения данных применяются, как указано в условиях вашего контракта с корпорацией Майкрософт. Общие сведения см. в разделе Управление данными в корпорации Майкрософт.
Поддержка функций
Внимание
Эта функция несовместима с восстановлением на определенный момент времени и отслеживанием последнего доступа.
Эта функция совместима с незапланированным отказом, управляемым клиентом. Однако любые изменения, которые вы внесёте в политику неизменяемости после последнего времени синхронизации (например, блокировка политики хранения по времени или её продление), не синхронизируются со вторичным регионом. После завершения аварийного переключения вы можете повторно внести изменения во вторичный регион, чтобы убедиться, что он приведён в соответствие с вашими требованиями к неизменяемости. Политики неизменяемости не поддерживаются в учетных записях с включенным протоколом NFS 3.0 или протоколом SFTP.
Некоторые рабочие нагрузки, такие как резервное копирование SQL на URL-адрес, создают blob, а затем добавляют в него. Если для контейнера действует политика хранения на основе времени или установлена блокировка по юридическим причинам, этот шаблон не сработает. Для получения дополнительной информации, см. Разрешение на запись защищенных добавляемых BLOB-объектов.
Для получения дополнительной информации см. статью о поддержке функций хранилища BLOB-объектов в учетных записях службы хранилища Azure.