События
Присоединение к вызову ИИ Навыков
8 апр., 15 - 28 мая, 07
Отточите свои навыки ИИ и введите подметки, чтобы выиграть бесплатный экзамен сертификации
Зарегистрируйтесь!Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Неизменяемое хранилище Azure Blob позволяет пользователям хранить критически важные для бизнеса данные в режиме WORM (однократная запись, многократное чтение). В состоянии WORM данные не могут быть изменены или удалены в течение заданного пользователем интервала. Настроив политики неизменяемости для BLOB-объектов, вы можете защитить данные от перезаписи и удаления.
Неизменяемое хранилище Azure Blob поддерживает два типа неизменяемых политик:
Политики хранения на основе времени: пользователи могут настраивать политики для хранения данных в течение определенного интервала. Когда установлена политика хранения на основе времени, объекты можно создавать и читать, но нельзя изменять и удалять. По истечении срока хранения объекты могут быть удалены, но не перезаписаны.
Юридические удержания: юридическое удержание позволяет хранить неизменяемые данные до тех пор, пока оно не будет явно отменено. Когда установлено удержание по юридическим причинам, объекты можно создавать и читать, но нельзя изменять и удалять.
Эти политики можно задавать одновременно. Например, у пользователя могут одновременно быть установлены политика хранения данных, основанная на времени, и юридическое удержание на одном уровне. Чтобы запись была успешно выполнена, необходимо либо включить версирование, либо не использовать юридическое удержание и политику удержания данных на основе времени для данных. Для успешного удаления не должно быть юридической или временной политики хранения данных.
На следующей схеме показано, как политики хранения на основе времени и удержания по юридическим причинам предотвращают операции записи и удаления, когда они действуют.
Существует две особенности в области неизменяемого хранилища: WORM на уровне контейнера и WORM на уровне версии. WORM уровня контейнера позволяет устанавливать политики только на уровне контейнера, а WORM уровня версии позволяет устанавливать политики на уровне учетной записи, контейнера или версии.
Неизменяемое хранилище помогает организациям здравоохранения, финансовым учреждениям и связанным отраслям ( особенно брокер-дилерские организации) безопасно хранить данные. Неизменяемое хранилище можно использовать в любом сценарии для защиты критически важных данных от изменения или удаления.
Распространенные приложения включают следующее.
Соответствие нормативным требованиям: хранение данных в неизменяемом виде в хранилище 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(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-объектов в формате однократной записи, многократного чтения (WORM) до тех пор, пока удержание не будет явно снято. Когда действует юридический запрет на изменение, объекты blob можно создавать и читать, но нельзя изменять или удалять. Используйте удержание по юридическим причинам, если неизвестно, как долго данные должны храниться в состоянии WORM.
Удержание по юридическим причинам можно настроить, выбрав любую из следующих областей действия:
Политика WORM на уровне версии: юридическое удержание можно настроить на уровне отдельной версии BLOB для детализированного управления конфиденциальными данными.
Политика WORM на уровне контейнера: юридическое удержание, настроенное на уровне контейнера, применяется ко всем объектам в этом контейнере. Настраивать отдельные объекты, указывая для них собственные политики неизменяемости, нельзя.
Удержание по юридическим причинам на уровне контейнера должно быть связано с одним или несколькими задаваемыми пользователем буквенно-цифровыми тегами, которые служат строками идентификаторов. Например, тег может содержать идентификатор дела или имя события.
Каждый контейнер с удержанием по юридическим причинам содержит журнал аудита политики. Журнал содержит идентификатор пользователя, тип команды, отметки времени и теги удержания по юридическим причинам. Журнал аудита сохраняется в течение времени существования политики в соответствии с нормативными правилами SEC 17a-4(f).
Журнал действий Azure представляет собой более полный реестр сведений обо всех действиях службы управления. В журналах ресурсов Azure хранятся сведения об операциях с данными. Пользователь постоянно несет ответственность за хранение этих журналов в соответствии с нормативами или другими требованиями.
Изменения юридических удержаний на уровне версии не проверяются.
В следующей таблице показана разбивка различий между WORM уровня контейнера и WORM уровня версии:
| Категория | WORM на уровне контейнера | WORM на уровне версии |
|---|---|---|
| Уровень детализации политики | Политики можно настроить только на уровне контейнера. Каждый объект, передаваемый в контейнер, наследует неизменяемый набор политик. | Политики можно настроить на уровне учетной записи, контейнера или объекта хранения. Если политика задана на уровне учетной записи, все блобы, загружаемые в эту учетную запись, наследуют политику. Та же логика применяется к контейнерам. Если политика задана на нескольких уровнях, порядок приоритета всегда является Blob — контейнер — учетная запись. |
| Доступные типы политик | На уровне контейнера можно задать два разных типа политик хранения: политики хранения на основе времени и юридические удержания. | На уровне учетной записи и контейнера можно задать только политики хранения на основе времени. На уровне объекта BLOB можно задать как политики хранения на основе времени, так и правовые блокировки. |
| Зависимости компонентов | Другие функции не являются предварительным условием или требованием для работы этой функции. | Управление версиями является необходимым условием для использования этой функции. |
| Включение возможностей для существующих учетных записей/контейнеров | Эта функция может быть включена в любое время для существующих контейнеров. | В зависимости от уровня детализации эта функция может не быть включена для всех существующих учетных записей или контейнеров. |
| Удаление учетной записи или контейнера | После блокировки политики хранения на основе времени в контейнере контейнеры могут удаляться только в том случае, если они пусты. | После включения функции WORM на уровне версии для учетной записи или контейнера, они могут быть удалены только в том случае, если учетные записи или контейнеры пусты. |
| Поддержка Azure Data Lake Storage (аккаунты хранения с активированным иерархическим пространством имен) | Политики WORM уровня контейнера поддерживаются в учетных записях с иерархической структурой имен. | Политики WORM уровня версии пока не поддерживаются в учетных записях с иерархическим пространством имен. |
Чтобы узнать больше о WORM на уровне контейнера, см. раздел Политики уровня контейнера для WORM. Чтобы узнать больше о WORM уровня версии, пожалуйста, посетите политики WORM уровня версии.
В следующей таблице показано, какой тип политики WORM следует использовать.
| Критерии | Использование WORM на уровне контейнера | Использование WORM на уровне версии |
|---|---|---|
| Организация данных | Вы хотите задать политики для определенных наборов данных, которые можно классифицировать по контейнерам. Все данные в этом контейнере должны храниться в состоянии WORM в течение одного и того же времени. | Невозможно группировать объекты по периодам хранения. Все блобы должны храниться с индивидуальным временем хранения в зависимости от сценариев каждого блоба, или у пользователя смешанная рабочая нагрузка, так что некоторые группы данных могут быть кластеризованы в контейнеры, а другие блобы не могут. Вы также можете задать политики на уровне контейнера и BLOB-объектов в одной учетной записи. |
| Объем данных, требующих неизменяемой политики | Вам не нужно устанавливать политики на более чем 10 000 контейнеров для каждой учетной записи. | Вы хотите установить политики для всех данных или больших объемов данных, которые можно разграничить по учетной записи. Вы знаете, что при использовании WORM на уровне контейнера вам придется превысить лимит в 10 000 контейнеров. |
| Интерес к включению управления версиями | Вы не хотите иметь дело с включением управления версиями из-за затрат или из-за того, что рабочая нагрузка создаст множество дополнительных версий. | Вы хотите использовать управление версиями или не возражаете против него. Вы знаете, что если они не разрешают управление версиями, вы не можете сохранять изменения или перезаписывать неизменяемые большие двоичные объекты в виде отдельных версий. |
| Расположение хранилища (хранилище BLOB-объектов и Data Lake Storage) | Рабочая нагрузка полностью ориентирована на Azure Data Lake Storage. У вас нет немедленного интереса или плана переключиться на использование учетной записи, которая не включает функцию иерархического пространства имен. | Рабочая нагрузка находится в хранилище Blob в учетной записи, которая не имеет функции иерархического пространства имен, поэтому теперь можно использовать WORM уровня версии. Либо вы готовы подождать, когда управление версиями станет доступно для учетных записей с включенным иерархическим пространством имен (Azure Data Lake Storage). |
Все уровни доступа к BLOB-объектам поддерживают неизменяемое хранилище. Уровень доступа BLOB-объекта можно изменить с помощью операции задания уровня BLOB-объекта. Дополнительные сведения см. в разделе Уровни доступа для данных BLOB.
Все конфигурации избыточности поддерживают неизменяемое хранилище. Дополнительные сведения о конфигурациях избыточности см. в разделе Избыточность хранилища Azure.
Майкрософт рекомендует настраивать политики неизменности в основном для блочных и добавочных BLOB-объектов. Настройка политики неизменяемости для страничного BLOB-объекта, в котором хранится диск VHD для активной виртуальной машины, не рекомендуется, так как запись на диск будет заблокирована, или, если включено версионирование, каждая запись будет сохранена как новая версия. Майкрософт рекомендует внимательно изучить документацию и протестировать сценарии, прежде чем блокировать любые политики, основанные на времени.
Если для учетной записи хранения настроено мягкое удаление BLOB-объектов, эта настройка применяется ко всем BLOB-объектам в учетной записи, независимо от наличия юридических удержаний или временной политики хранения. Корпорация Майкрософт рекомендует включить мягкое удаление для дополнительной защиты перед применением любых политик неизменяемости.
Если включить обратимое удаление BLOB-объектов, а затем настроить политику неизменяемости, все BLOB-объекты, которые уже были подлежат восстановлению, будут окончательно удалены после истечения срока действия политики хранения обратимого удаления. Мягко удаленные BLOB-объекты можно восстановить в течение периода хранения после мягкого удаления. Объект BLOB или версия, которая еще не была мягко удалена, защищена политикой неизменности и не может быть мягко удалена до окончания срока хранения по политике, основанной на времени, или до снятия наложения юридического удержания.
Инвентаризация BLOB в Azure Storage предоставляет обзор контейнеров в учетных записях хранения, объектов BLOB, моментальных снимков и версий этих объектов. Отчет об инвентаризации блоб-объектов помогает понять свойства блоб-объектов и контейнеров, в том числе наличие настроенной для ресурса политики неизменяемости.
При включении инвентаризации BLOB-объектов служба хранилища Azure ежедневно создает отчет инвентаризации. Отчет содержит общие сведения о ваших бизнес-данных и требованиях соответствия.
Дополнительные сведения см. в статье об инвентаризации BLOB-объектов службы хранилища Azure.
Примечание
Политику инвентаризации нельзя настроить в учетной записи, если в этой учетной записи включена поддержка неизменяемости на уровне версии или включена поддержка неизменяемости на уровне версии в целевом контейнере, определенном в политике инвентаризации.
Можно использовать задачу хранилища для настройки политик неизменяемости в масштабе нескольких аккаунтов хранения на основе определенного набора условий. Задача хранения — это ресурс, доступный в Azure Storage Actions; бессерверная платформа, которую можно использовать для выполнения стандартных операций с данными для миллионов объектов в нескольких учетных записях хранилища. Дополнительные сведения см. в статье Что такое Azure Storage Actions?.
Плата за использование неизменяемого хранилища не взимается. Неизменяемые данные оцениваются так же, как изменяемые. Если вы используете WORM на уровне версий, счет может быть выше, так как вы включили версионирование, и есть затраты, связанные с дополнительными версиями. Дополнительные сведения см. в политике ценообразования на управление версиями. Информацию о ценах на хранилище BLOB-объектов Azure см. на этой странице.
Создание, изменение или удаление политики хранения на основе времени или юридического удержания для версии BLOB приводит к списанию платы за транзакцию записи.
Если вы не платите счет и ваша учетная запись имеет активную политику хранения на основе времени, обычные политики хранения данных применяются, как указано в условиях вашего контракта с корпорацией Майкрософт. Общие сведения см. в разделе Управление данными в корпорации Майкрософт.
Важно!
Эта функция несовместима с восстановлением на определенный момент времени и отслеживанием последнего доступа.
Эта функция совместима с управляемой клиентом неплановой отработкой отказа, однако любые изменения, внесенные в неизменяемую политику после последнего времени синхронизации (например, блокировка политики хранения на основе времени, расширение и т. д.), не будут синхронизированы со вторичным регионом. После завершения переключения на резерв вы можете заново внести изменения во вторичном регионе, чтобы обеспечить соответствие требованиям к неизменяемости. Политики неизменяемости не поддерживаются в учетных записях с включенным протоколом NFS 3.0 или протоколом SFTP.
Некоторые рабочие нагрузки, такие как резервное копирование SQL на URL-адрес, создают blob, а затем добавляют в него. Если в контейнере действует активная политика хранения, основанная на времени, или юридическое удержание, то этот паттерн не будет работать. Для получения дополнительной информации, см. Разрешение на запись защищенных добавляемых BLOB-объектов.
Для получения дополнительной информации см. статью о поддержке функций хранилища BLOB-объектов в учетных записях службы хранилища Azure.