Хранение критически важных для бизнеса данных BLOB-объектов с неизменяемым хранилищем в однократном режиме записи считывает много (WORM)
Неизменяемое Хранилище BLOB-объектов Azure дает пользователям возможность хранить критически важные для бизнеса данные в состоянии WORM (однократная запись, многократное чтение). В состоянии WORM данные не могут быть изменены или удалены в течение заданного пользователем интервала. Настроив политики неизменяемости для BLOB-объектов, вы можете защитить данные от перезаписи и удаления.
Неизменяемое хранилище BLOB-объектов Azure поддерживает два типа неизменяемых политик:
Политики хранения на основе времени: пользователи могут настраивать политики для хранения данных в течение определенного интервала. Когда установлена политика хранения на основе времени, объекты можно создавать и читать, но нельзя изменять и удалять. По истечении срока хранения объекты могут быть удалены, но не перезаписаны.
Политики удержания по юридическим причинам: удержание позволяет хранить неизменяемые данные до тех пор, пока не будет отменено явным образом. Когда установлено удержание по юридическим причинам, объекты можно создавать и читать, но нельзя изменять и удалять.
Эти политики можно задать одновременно, как и друг друга. Например, пользователь может иметь политику хранения на основе времени и юридическую удержание на одном уровне и одновременно. Чтобы запись была успешно выполнена, необходимо включить управление версиями или не использовать политику хранения на основе времени или удержание на основе времени для данных. Для успешного удаления не должно быть юридической или временной политики хранения данных.
На следующей схеме показано, как политики хранения на основе времени и удержания по юридическим причинам предотвращают операции записи и удаления, когда они действуют.
Существует два компонента в неизменяемом зонтике хранилища: WORM уровня контейнера и WORM уровня версии. WORM уровня контейнера позволяет устанавливать политики только на уровне контейнера, а WORM уровня версии позволяет устанавливать политики на уровне учетной записи, контейнера или версии.
О неизменяемом хранилище BLOB-объектов
Неизменяемое хранилище помогает организациям здравоохранения, финансовым учреждениям и связанным отраслям ( особенно брокер-дилерские организации) безопасно хранить данные. Неизменяемое хранилище можно использовать в любом сценарии для защиты критически важных данных от изменения или удаления.
Распространенные приложения включают следующее.
Соответствие нормативным требованиям: хранение данных в неизменяемом виде в хранилище BLOB-объектов Azure помогает организациям соответствовать SEC 17a-4(f), CFTC 1.31(d), FINRA и другим нормам.
Безопасное хранение документов: неизменяемое хранилище BLOB-объектов гарантирует, что ни один пользователь, даже администратор учетной записи, не сможет изменить или удалить данные.
Удержание по юридическим причинам: неизменяемое хранилище BLOB-объектов позволяет пользователям хранить конфиденциальную информацию, критически важную для судебного процесса или бизнеса, в защищенном от несанкционированного доступа состоянии в течение желаемого периода, пока удержание не будет отменено. Эта функция не ограничивается только юридическими вариантами использования, но также может рассматриваться как удержание на основе событий или блокировка предприятия, где требуется защитить данные на основе триггеров событий или корпоративной политики.
Соблюдение нормативных требований
Корпорация Майкрософт продолжает пользоваться услугами ведущей независимой аудиторской фирмы Cohasset Associates, специализирующейся на управлении записями и информацией, для оценки неизменяемого хранилища BLOB-объектов на предмет его соответствия требованиям безопасности для отрасли финансовых услуг. Компания Cohasset подтвердила, что неизменяемое хранилище, используемое для хранения BLOB-объектов в состоянии WORM, соответствует требованиям к хранению, установленным в правилах CFTC 1.31 (c)-(d), FINRA 4511 и SEC 17A-4. Корпорация Майкрософт ориентируется на этот набор правил, так как они представляют собой наиболее полное нормативное руководство по хранению записей для финансовых учреждений.
Отчет Cohasset доступен в центре управления безопасностью Майкрософт. Центр управления безопасностью Azure содержит подробные сведения о сертификатах соответствия Майкрософт. Чтобы запросить подтверждение аттестации Майкрософт по соответствию требованиям к неизменности WORM, обратитесь в службу поддержки Azure.
Политики хранения на основе времени
Политика хранения на основе времени хранит данные BLOB-объектов в формате WORM для указанного интервала. Если задана политика хранения на основе времени, клиенты могут создавать и считывать большие двоичные объекты, но не могут изменять или удалять их. По истечении срока хранения большие двоичные объекты можно удалить, но нельзя перезаписать.
Область
Политику хранения на основе времени можно настроить в следующих областях:
- Политика 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-объектов в формате "Запись", "Много чтения" (WORM), пока удержание не будет явно удалено. Когда устанавливается удержание по юридическим причинам, большие двоичные объекты можно создавать и читать, но нельзя изменять и удалять. Используйте удержание по юридическим причинам, если данные должны храниться в состоянии WORM.
Область
Удержание по юридическим причинам можно настроить, выбрав любую из следующих областей действия:
Политика WORM уровня версии: юридическое удержание можно настроить на уровне отдельной версии BLOB-объектов для детализированного управления конфиденциальными данными.
Политика WORM уровня контейнера: юридическое удержание, настроенное на уровне контейнера, применяется ко всем blob-объектам в этом контейнере. Настраивать отдельные объекты, указывая для них собственные политики неизменяемости, нельзя.
Теги
Удержание по юридическим причинам на уровне контейнера должно быть связано с одним или несколькими задаваемыми пользователем буквенно-цифровыми тегами, которые служат строками идентификаторов. Например, тег может содержать идентификатор дела или имя события.
Ведение журнала аудита
Каждый контейнер с удержанием по юридическим причинам содержит журнал аудита политики. Журнал содержит идентификатор пользователя, тип команды, отметки времени и теги удержания по юридическим причинам. Журнал аудита сохраняется в течение времени существования политики в соответствии с нормативными правилами SEC 17a-4(f).
Журнал действий Azure представляет собой более полный реестр сведений обо всех действиях службы управления. В журналах ресурсов Azure хранятся сведения об операциях с данными. Пользователь постоянно несет ответственность за хранение этих журналов в соответствии с нормативами или другими требованиями.
Изменения юридических удержаний на уровне версии не проверяются.
Неизменяемые возможности хранилища
В следующей таблице показана разбивка различий между WORM уровня контейнера и WORM уровня версии:
| Категория | WORM уровня контейнера | WORM уровня версии |
|---|---|---|
| Уровень детализации политики | Политики можно настроить только на уровне контейнера. Каждый объект, передаваемый в контейнер, наследует неизменяемый набор политик. | Политики можно настроить на уровне учетной записи, контейнера или большого двоичного объекта. Если политика задана на уровне учетной записи, все большие двоичные объекты, передаваемые в ту учетную запись, наследуют политику. Та же логика следует контейнерам. Если политика задана на нескольких уровнях, порядок приоритета всегда имеет значение BLOB-объект — контейнер —>> учетная запись. |
| Доступные типы политик | На уровне контейнера можно задать два разных типа политик хранения: политики хранения на основе времени и юридические удержания. | На уровне учетной записи и контейнера можно задать только политики хранения на основе времени. На уровне большого двоичного объекта можно задать как политики хранения на основе времени, так и юридические удержания. |
| Зависимости компонентов | Другие функции не являются предварительным условием или требованием для работы этой функции. | Управление версиями является необходимым условием для использования этой функции. |
| Включение существующих учетных записей и контейнеров | Эта функция может быть включена в любое время для существующих контейнеров. | В зависимости от уровня детализации эта функция может не быть включена для всех существующих учетных записей или контейнеров. |
| Удаление учетной записи или контейнера | После блокировки политики хранения на основе времени в контейнере контейнеры могут удаляться только в том случае, если они пусты. | После включения WORM уровня версии на уровне учетной записи или контейнера они могут быть удалены только в том случае, если они пусты. |
| Поддержка Azure Data Lake Storage 2-го поколения (учетные записи хранения с включенным иерархическим пространством имен) | Политики WORM уровня контейнера поддерживаются в учетных записях с иерархическим пространством имен. | Политики WORM уровня версии пока не поддерживаются в учетных записях с иерархическим пространством имен. |
Дополнительные сведения о политиках WORM на уровне контейнера см. в политиках WORM уровня контейнера. Дополнительные сведения о WORM уровня версии см . в политиках WORM уровня версии.
WORM уровня контейнера и WORM уровня версии
В следующей таблице показано, какой тип политики WORM следует использовать.
| Критерии | Использование WORM на уровне контейнера | Использование WORM на уровне версии |
|---|---|---|
| Организация данных | Вы хотите задать политики для определенных наборов данных, которые можно классифицировать по контейнерам. Все данные в этом контейнере должны храниться в состоянии WORM в течение одного и того же времени. | Невозможно группировать объекты по периодам хранения. Все большие двоичные объекты должны храниться с отдельным временем хранения в зависимости от сценариев этого большого двоичного объекта, или пользователь имеет смешанную рабочую нагрузку, чтобы некоторые группы данных могли быть кластеризованы в контейнеры, а другие большие двоичные объекты не могут. Вы также можете задать политики уровня контейнера и политики уровня BLOB-объектов в одной учетной записи. |
| Объем данных, требующих неизменяемой политики | Вам не нужно устанавливать политики на более чем 10 000 контейнеров для каждой учетной записи. | Вы хотите задать политики для всех данных или больших объемов данных, которые можно выделить учетной записью. Вы знаете, что если вы используете WORM уровня контейнера, вам придется превысить ограничение в 10 000 контейнеров. |
| Интерес к включению управления версиями | Вы не хотите работать с включением управления версиями из-за затрат или из-за того, что рабочая нагрузка создаст множество дополнительных версий для работы. | Вы хотите использовать управление версиями или не возражаете против него. Вы знаете, что если они не разрешают управление версиями, вы не можете сохранять изменения или перезаписывать неизменяемые большие двоичные объекты в виде отдельных версий. |
| Расположение хранилища (хранилище BLOB-объектов и Data Lake Storage 2-го поколения) | Рабочая нагрузка полностью ориентирована на Azure Data Lake Storage 2-го поколения. У вас нет немедленного интереса или плана переключиться на использование учетной записи, которая не включает функцию иерархического пространства имен. | Рабочая нагрузка находится в хранилище BLOB-объектов в учетной записи, которая не включает функцию иерархического пространства имен, и теперь может использовать WORM уровня версии, или вы можете ждать, пока управление версиями будет доступно для учетных записей с включенным иерархическим пространством имен (Azure Data Lake Storage 2-го поколения). |
Уровни доступа
Все уровни доступа к BLOB-объектам поддерживают неизменяемое хранилище. Уровень доступа BLOB-объекта можно изменить с помощью операции задания уровня BLOB-объекта. Дополнительные сведения см. в разделе "Уровни доступа" для данных BLOB-объектов.
Конфигурации избыточности
Неизменяемое хранилище поддерживают все конфигурации избыточности. Дополнительные сведения о конфигурациях избыточности см. в разделе Избыточность хранилища Azure.
Рекомендуемые типы BLOB-объектов
Майкрософт рекомендует настраивать политики неизменности в основном для блочных и добавочных BLOB-объектов. Настройка политики неизменяемости для страничного BLOB-объекта, в котором хранится диск VHD для активной виртуальной машины, не рекомендуется, так как запись на диск будет заблокирована или если включена версия, каждая запись сохраняется в качестве новой версии. Майкрософт рекомендует внимательно изучить документацию и протестировать сценарии, прежде чем блокировать любые политики, основанные на времени.
Неизменяемое хранилище с обратимым удалением BLOB-объектов
Если для учетной записи хранения настроено обратимое удаление BLOB-объектов, эта настройка применяется ко всем BLOB-объектам в пределах учетной записи независимо от того, действует ли политика хранения на основе юридических удержаний или времени. Корпорация Майкрософт рекомендует включить обратимое удаление для дополнительной защиты перед применением любых неизменяемых политик.
Если включить обратимое удаление BLOB-объектов, а затем настроить политику неизменяемости, все большие двоичные объекты, которые уже были обратимо удалены, окончательно удаляются после истечения срока действия политики обратимого удаления. Обратимо удаленные большие двоичные объекты можно восстановить в течение периода хранения обратимого удаления. Большой двоичный объект или версия, которая еще не была обратима удалена, защищена политикой неизменяемости и не может быть обратимо удалена до истечения срока действия политики хранения на основе времени или юридического удержания.
Отслеживание политик неизменности с помощью инвентаризации BLOB-объектов
Инвентаризация BLOB-объектов службы хранилища Azure позволяет получить общие сведения о контейнерах в учетных записях хранения, больших двоичных объектах, моментальных снимках и версиях BLOB-объектов в них. Отчет об инвентаризации BLOB-объектов помогает понять свойства BLOB-объектов и контейнеров, в том числе узнать о настроенной для ресурса политике неизменности.
При включении инвентаризации BLOB-объектов служба хранилища Azure ежедневно создает отчет инвентаризации. Отчет содержит общие сведения о данных и требованиях соответствия.
Дополнительные сведения см. в статье об инвентаризации BLOB-объектов службы хранилища Azure.
Примечание.
Политику инвентаризации нельзя настроить в учетной записи, если в этой учетной записи включена поддержка неизменяемости на уровне версии или включена поддержка неизменяемости на уровне версии в целевом контейнере, определенном в политике инвентаризации.
Настройка политик в масштабе
Задачу хранилища можно использовать для настройки политик неизменяемости в масштабе в нескольких учетных записях хранения на основе определенного набора условий. Задача хранения — это ресурс, доступный в служба хранилища Azure Actions; бессерверная платформа, которую можно использовать для выполнения общих операций с данными для миллионов объектов в нескольких учетных записях хранения. Дополнительные сведения см. в статье "Что такое служба хранилища Azure действия?".
Цены
Плата за использование неизменяемого хранилища не взимается. Неизменяемые данные оцениваются так же, как изменяемые. Если вы используете WORM уровня версии, счет может быть выше, так как вы включили управление версиями, и есть затраты, связанные с дополнительными версиями, хранящимися. Дополнительные сведения см. в политике ценообразования на управление версиями. Информацию о ценах на хранилище BLOB-объектов Azure см. на этой странице.
Создание, изменение или удаление политики хранения на основе времени или удержания по юридическим причинам для версии BLOB-объекта оплачивается из расчета за транзакцию записи.
Если вы не платите счет и ваша учетная запись имеет активную политику хранения на основе времени, обычные политики хранения данных применяются, как указано в условиях вашего контракта с корпорацией Майкрософт. Общие сведения см. в разделе Управление данными в корпорации Майкрософт.
Поддерживаемые компоненты
Эта функция несовместима с восстановлением до точки во времени и отслеживанием последнего доступа. Эта функция совместима с управляемой клиентом не плановая отработка отказа однако любые изменения, внесенные в неизменяемую политику после последнего времени синхронизации (например, блокировка политики хранения на основе времени, расширение и т. д.) не будет синхронизирована с дополнительным регионом. После завершения отработки отказа вы можете повторно изменить изменения в дополнительном регионе, чтобы обеспечить актуальность требований к неизменяемости. Политики неизменяемости не поддерживаются в учетных записях с включенным протоколом NFS 3.0 или протоколом SFTP.
Некоторые рабочие нагрузки, такие как резервное копирование SQL на URL-адрес, создают большой двоичный объект, а затем добавляют в него. Если контейнер имеет активную политику хранения на основе времени или юридическое удержание, этот шаблон не будет успешным. Дополнительные сведения см. в статье "Разрешить запись защищенного большого двоичного объекта".
Дополнительные сведения см. в статье о поддержке функций хранилища BLOB-объектов в учетных записях служба хранилища Azure.