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

Резервное копирование облачных и локальных нагрузок в облако

  • Статья

Служба Azure Backup обеспечивает комплексную защиту ресурсов данных в Azure с помощью простого, безопасного и экономичного решения, для которого не нужна инфраструктура. Это встроенное решение Azure для защиты данных, рассчитанное на широкий спектр рабочих нагрузок. Azure Backup помогает защитить ваши критически важные облачные рабочие нагрузки, а также обеспечивает постоянную доступность резервных копий и управление всей системой резервного копирования.

Целевая аудитория

Основная целевая аудитория этой статьи — ИТ-администраторы, администраторы приложений и специалисты по внедрению в крупных и средних организациях, желающие ознакомиться с возможностями встроенной в Azure технологии защиты данных (Azure Backup) и способами эффективной реализации решений для более надежной защиты развернутых систем. Предполагается знакомство читателя с основными технологиями Azure и понятиями из области защиты данных, а также наличие у него опыта работы с тем или иным решением для резервного копирования. Материал этой статьи облегчит вам разработку решения для резервного копирования в Azure по установленным шаблонам и поможет избежать типичных ошибок.

Структура статьи

Приступить к защите инфраструктуры и приложений в Azure легко, но если вы позаботитесь о правильной настройке и оптимальном использовании базовых ресурсов Azure, то сможете скорее получить отдачу от своих усилий. Статья содержит краткий обзор рекомендаций по проектированию и оптимальной настройке развернутой службы Azure Backup. В ней рассматриваются основные компоненты (например, хранилище Служб восстановления, Политика резервного копирования) и понятия (например, система управления), а также их роль, место и возможности со ссылками на подробную документацию по продукту.

Начало работы

Стратегия проектирования подписок

Помимо составления четкого плана развертывания облачных служб, необходимо спланировать разработку подписки и структуру учетной записи облачного развертывания в соответствии с возможностями владения, выставления счетов и управления вашей организации. Так как хранилище является областью действия подписки, дизайн вашей подписки будет сильно влиять на дизайн вашего хранилища. Дополнительные сведения о разных стратегиях проектирования подписок и рекомендации по их использованию.

Документирование требований к резервному копированию

Для начала работы с Azure Backup определите свои потребности в резервном копировании. Ниже приведены некоторые вопросы, которые вам следует себе задать при составлении идеальной стратегии резервного копирования.

Какой тип рабочей нагрузки вы хотите защитить?

Для проектирования хранилищ выберите централизованный или децентрализованный режим работы.

Какая нужна степень детализации резервного копирования?

Определите, должно ли оно быть согласованным с приложениями, согласованным со сбоями или резервным копированием журналов.

Имеются ли требования к соответствию?

Убедитесь, что вам нужно применять стандарты безопасности и отдельные границы доступа.

Какие требуются показатели RPO и RTO?

Определите частоту резервного копирования и скорость восстановления.

Есть ли какие-либо ограничения в отношении места расположения данных?

Определите избыточность хранилища для требуемой надежности данных.

Как долго нужно хранить данных резервных копий?

Определите длительность хранения резервных копий в хранилище.

Архитектура

Схема, демонстрирующая архитектуру Azure Backup.

Рабочие нагрузки

Azure Backup обеспечивает защиту данных, относящихся к локальным и облачным рабочим нагрузкам. Это безопасный и надежный защитный механизм, встроенный в Azure. Он позволяет с легкостью масштабировать защиту на множество рабочих нагрузок, не требуя от вас дополнительных усилий по управлению. Для этих целей существует также несколько каналов автоматизации (PowerShell, интерфейс командной строки, шаблоны Azure Resource Manager и REST API).

  • Масштабируемое, надежное и безопасное хранилище. В Azure Backup используется надежное хранилище BLOB-объектов со встроенными функциями обеспечения безопасности и высокого уровня доступности. Для резервных копий данных можно выбрать хранилище LRS, GRS или RA-GRS.

  • Собственная интеграция с рабочими нагрузками. Azure Backup обеспечивает собственную интеграцию с рабочими нагрузками Azure (виртуальными машинами, SAP HANA, SQL в виртуальных машинах Azure и даже службой Файлы Azure) без необходимости управлять автоматизацией или инфраструктурой для развертывания агентов, писать новые сценарии или подготавливать хранилище.

Дополнительные сведения о поддерживаемых рабочих нагрузках.

Плоскость данных

  • Автоматизированное управление хранилищем. В Azure Backup автоматизированы процессы подготовки учетных записей хранения для резервных копий данных и управления ими, чтобы обеспечить масштабирование с ростом объемов данных резервных копий.

  • Защита от вредоносного удаления. Функция обратимого удаления предохраняет от случайного и вредоносного удаления резервных копий. Удаленные данные резервных копий хранятся бесплатно в течение 14 дней и могут быть восстановлены из этого состояния.

  • Защищенные зашифрованные резервные копии. В Azure Backup организовано безопасное хранение данных резервных копий с использованием встроенных в платформу Azure функций безопасности, таких как управление доступом на основе ролей (RBAC) и шифрование.

  • Управление жизненным циклом данных резервных копий. В Azure Backup старые данные резервных копий автоматически очищаются в соответствии с политиками хранения. Вы также можете переводить данные из оперативного использования в хранилище.

  • Защита критически важных операций. Авторизация нескольких пользователей (MUA) для Azure Backup обеспечивает дополнительный уровень защиты критических операций в хранилищах Служб восстановления.

Плоскость управления

  • Управление доступом. Хранилищами (Служб восстановления и Azure Backup) можно управлять через портал Azure, Центр резервного копирования, панели мониторинга хранилищ, пакет SDK, интерфейс командной строки и даже REST API. Это также граница управления доступом на основе ролей Azure (Azure RBAC), предоставляющая вам возможность ограничить доступ к резервным копиям только авторизованным администраторам резервного копирования.

  • Управление политиками. Политики резервного копирования Azure Backup, устанавливаемые для каждого хранилища, определяют, когда следует выполнять резервное копирование и длительность хранения резервных копий. Этими политиками можно управлять, а также применять их ко множеству элементов.

  • Мониторинг и создание отчетов. Azure Backup интегрируется с Log Analytics и позволяет просматривать отчеты, используя Книги.

  • Управление моментальными снимками. Azure Backup создает моментальные снимки для некоторых собственных рабочих нагрузок Azure (виртуальных машин и Файлов Azure), управляет этими моментальными снимками и обеспечивает быстрое восстановление из них. Эта функция радикально сокращает время восстановления данных в исходном хранилище.

Рекомендации по созданию хранилищ

В службе Azure Backup для оркестрации резервных копий, управления ими и хранения данных резервных копий используются хранилища (Служб восстановления и Azure Backup). Эффективная структура хранилища помогает организациям упорядочивать резервные копии и управлять ими в Azure согласно своим бизнес-приоритетам. При создании хранилища примите во внимание приведенные ниже рекомендации.

Одно или несколько хранилищ

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

  • Защита ресурсов в разных регионах глобально. Если ваша организация развернута в Северной Америке, Европе и Азии, а ваши ресурсы развернуты в восточной части США, западной части Соединенного Королевства и Азиатско-Тихоокеанском регионе. Одно из требований Azure Backup — хранилища должны находиться в том же регионе, что и ресурс, для которого создается резервная копия. Поэтому для защиты ресурсов необходимо создать по три отдельных хранилища в каждом регионе.

  • Защита ресурсов в различных подразделениях и отделах. Учитывайте, что бизнес-операции разделены на три отдельных бизнес-подразделения (BU), и каждый бизнес-подразделение имеет свой собственный набор отделов (пять отделов — финансы, продажи, отделы кадров, R ИД и маркетинг). В соответствии с бизнес-потребностями может понадобиться, чтобы каждый отдел мог управлять своими резервными копиями и восстановлениями и получать к ним доступ; кроме того, может понадобится возможность отслеживать использование и затраты отдельных отделов. В таких случаях мы рекомендуем создать по хранилищу для каждого отдела в подразделении. Таким образом, в организации будет 15 хранилищ.

  • Защита разных рабочие нагрузки. Если вы планируете защищать различные типы рабочих нагрузок (например, 150 виртуальных машин, 40 баз данных SQL и 70 баз данных PostgreSQL), рекомендуем создавать отдельные хранилища для каждого типа рабочей нагрузки (в данном примере необходимо создать по три хранилища для каждой рабочей нагрузки: ВМ, базы данных SQL и базы данных PostgreSQL). Это позволяет разделить границы доступа для пользователей, чтобы вы могли предоставлять доступ соответствующим заинтересованным лицам (с помощью управления доступом на основе ролей Azure RBAC).

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

  • Защита большого количества (более 1000) виртуальных машин Azure. Предположим, что вам нужно организовать резервное копирование 1500 виртуальных машин. Azure Backup позволяет выполнить резервное копирование только 1000 виртуальных машин Azure в одном хранилище. В этом случае можно создать два разных хранилища и распределить 1000 и 500 виртуальных машин между ними или использовать любое сочетание с учетом верхнего предела.

  • Защита большого количества (более 2000) разных рабочих нагрузок. При управлении резервными копиями в большом масштабе вы защищаете виртуальные машины Azure, а также другие рабочие нагрузки, такие как базы данных SQL и SAP HANA, работающие на этих виртуальных машинах Azure. Например, вам нужно защитить 1300 виртуальных машин Azure и 2500 баз данных SQL. Ограничения хранилища позволяют сделать в каждом хранилище резервные копии до 2000 рабочих нагрузок (с ограничением в 1000 виртуальных машин). Поэтому математическим образом можно сделать резервные копии 2000 рабочих нагрузок в одном хранилище (1000 виртуальных машин + 1000 баз данных SQL), а резервные копии остальных 1800 рабочих нагрузок — в другом хранилище (300 виртуальных машин + 1500 баз данных SQL).

    Но этот тип разделения не рекомендуется, так как вы не сможете определить границы доступа и рабочие нагрузки не будут изолированы друг от друга. Чтобы правильно распределить рабочие нагрузки, создайте четыре хранилища: два хранилища для виртуальных машин (1000 ВМ + 300 ВМ) и два других хранилища для баз данных SQL (2000 баз данных + 500 баз данных).

  • Управлять ими можно с помощью следующих средств:

    • Центр резервного копирования позволяет использовать одну область для управления всеми задачами резервного копирования. Дополнительные сведения см. здесь.
    • Если требуется согласованная политика в отношении нескольких хранилищ, можно распространить политику резервного копирования на все эти хранилища, воспользовавшись для этого политикой Azure. Чтобы распространить политику резервного копирования на несколько хранилищ, можно создать пользовательское определение политики Azure с эффектом "deployifnotexists". Это определение политики Azure можно также назначить конкретной области (подписке или группе ресурсов), чтобы развернуть ресурс "политика резервного копирования" во всех хранилищах Служб восстановления, относящихся к этой области. Параметры политики резервного копирования (например, периодичность резервного копирования, срок хранения и т. д.) должны быть указаны пользователем в качестве параметров назначения политики Azure.
  • По мере разрастания организации вам может понадобиться переместить рабочие нагрузки между подписками, чтобы сгруппировать их по политике резервного копирования, консолидировать хранилища или снизить затраты ценой меньшей избыточности (перейдя с GRS на LRS). Azure Backup поддерживает перемещение хранилища Служб восстановления между подписками Azure или в другую группу ресурсов в рамках той же подписки. Дополнительные сведения см. здесь.

Проверить настройки по умолчанию

Прежде чем настраивать резервное копирование в хранилище, проверьте заданные по умолчанию тип репликации хранилища и параметры безопасности.

  • По умолчанию для параметра Тип репликации хранилища установлено значение "Геоизбыточное (GRS)". После настройки резервного копирования изменить этот параметр будет невозможно. Чтобы проверить и изменить параметры, выполните указанные здесь действия.

    • Некритичным рабочим нагрузкам, например непроизводственным и для разработки, подходит репликация локально избыточного хранилища (LRS).

    • Хранилище, избыточное между зонами (ZRS) — это хороший способ хранения данных с высокой надежностью и указанием места расположения данных.

    • Геоизбыточное хранилище (GRS) рекомендуется использовать для критически важных рабочих нагрузок, например в рабочей среде, для предотвращения необратимой потери данных и их защиты в случае сбоя всего региона или аварии, после которой нельзя восстановить основной регион.

  • Обратимое удаление по умолчанию включено во вновь создаваемых хранилищах, чтобы защитить данные резервного копирования от случайного или вредоносного удаления. Чтобы проверить и изменить параметры, выполните указанные здесь действия.

  • Восстановление между регионами можно использовать для восстановления виртуальных машин Azure в дополнительном регионе, который является парным регионом Azure. Эта функция позволяет проводить учения согласно требованиям аудита или соответствия, а также восстанавливать виртуальную машину или ее диск при аварии в основном регионе. Восстановление между регионами по умолчанию выключено и может быть включено для любого хранилища GRS. Дополнительные сведения см. здесь.

  • Прежде чем окончательно определяться с выбором структуры хранилища, сверьтесь с матрицей поддержки хранилищ, в которой указаны факторы, способные повлиять на ваш выбор или ограничить его.

Рекомендации в отношении политики резервного копирования

Политика резервного копирования Azure имеет два компонента: Расписание (время создания резервной копии) и Период хранения (срок хранения резервной копии). Политику можно задавать исходя из типа данных, для которых выполняется резервное копирование, требований RTO/RPO, эксплуатационных или нормативных требований соответствия и типа рабочей нагрузки (например, виртуальных машин, базы данных, файлов). Подробнее

При создании политики резервного копирования примите во внимание следующие рекомендации.

Расписание

При планировании политики резервного копирования учитывайте следующие аспекты:

  • Для критически важных ресурсов попробуйте запланировать автоматическое резервное копирование с наибольшей доступной частотой в день, чтобы уменьшить значение целевой точку восстановления. Подробнее

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

  • Ресурсы, для которых требуется одинаковое время начала, частота и параметры хранения, необходимо сгруппировать в одной политике резервного копирования.

  • Рекомендуем обеспечить, чтобы запланированное время начала резервного копирования не приходилось на часы пик работы приложений. Например, лучше запланировать ежедневное автоматическое резервное копирование с 2 до 3 часов ночи, а не в дневное время, когда нагрузка на ресурсы высока.

  • Для распределения трафика резервного копирования рекомендуем выполнять резервное копирование разных ВМ в разное время суток. Например, чтобы создать 500 ВМ с одинаковыми настройками хранения, мы рекомендуем создать 5 разных политик, каждая из которых связана со 100 ВМ, и запланировать их с интервалом в несколько часов.

Период хранения

  • Краткосрочное хранение может быть "ежедневно". Хранение резервных копий, создаваемых с периодичностью "еженедельно", "ежемесячно" или "ежегодно", называется долгосрочным.

  • Виды долгосрочного хранения:

    • Плановое (исходя из требований соответствия). Если заранее известно, что данные потребуются через годы, выберите долгосрочное хранение. Azure Backup поддерживает резервное копирование точек долгосрочного хранения на архивном уровне, в дополнение к моментальным снимкам и стандартному уровню. Узнайте больше о поддерживаемых рабочих нагрузках для архивного уровня и конфигурации хранения.
    • Внеплановое (по запросу). Если заранее неизвестно, когда потребуются данные, выберите вариант "по запросу", задав конкретные параметры хранения (на них при этом не будут влиять параметры политики).

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

Оптимизация политики резервного копирования

  • По мере изменения бизнес-требований у вас может возникнуть потребность продлить или сократить период хранения. При этом можно ожидать следующего:

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

  • Azure Backup обеспечивает гибкость для остановки защиты резервных копий и управления ими:

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

    • Остановка защиты и удаление данных резервного копирования. Этот вариант предусматривает остановку защиты виртуальной машины путем отмены всех будущих заданий резервного копирования и удаление всех точек восстановления. После этого вы не сможете восстановить виртуальную машину или воспользоваться параметром Возобновить резервное копирование.

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

  • Прежде чем окончательно определяться с выбором политики, важно учесть следующие факторы, которые могут повлиять на ваш выбор.

    • Политика резервного копирования задается для конкретного хранилища.
    • Число элементов в одной политике ограничено (например, не более 100 виртуальных машин). Для масштабирования можно создавать дубликаты политик с такими же или другими расписаниями.
    • Вы не можете выборочно удалять конкретные точки восстановления.
    • Вы не можете полностью отключить резервное копирование по расписанию и удерживать источник данных в защищенном состоянии. Наименьшая периодичность резервного копирования по расписанию, которую можно установить с помощью политики — одно еженедельное резервное копирование. Как вариант, можно снять защиту с сохранением данных резервной копии, а затем каждый раз, когда необходимо будет создать резервную копию, включать защиту, выполнять резервное копирование по запросу и снова снимать защиту с сохранением данных. Дополнительные сведения см. здесь.

Вопросы безопасности

Чтобы помочь вам защитить данные резервных копий и обеспечить безопасность в соответствии с требованиями вашего бизнеса, Azure Backup предоставляет гарантии конфиденциальности, целостности и доступности в случае преднамеренных атак и злоупотребления вашими ценных данными и системами. Примите во внимание следующие рекомендации по обеспечению безопасности решения на базе Azure Backup.

Проверка подлинности и авторизация с помощью управления доступом на основе ролей Azure (Azure RBAC)

  • Управление доступом на основе ролей Azure (Azure RBAC) позволяет управлять доступом с высокой степенью детализации, разделять обязанности внутри команды и предоставлять пользователям доступ только в таком объеме, который им необходим для выполнения своей работы. Дополнительные сведения см. здесь.

  • Если вам нужно сделать резервные копии нескольких рабочих нагрузок (например, виртуальные машины Azure, базы данных SQL и базы данных PostgreSQL) и у вас есть несколько заинтересованных лиц, которые будут управлять этими резервными копиями, важно разделить их обязанности, чтобы у пользователей был доступ только к тем ресурсам, за которые они отвечают. Управление доступом на основе ролей Azure (Azure RBAC) позволяет управлять доступом с высокой степенью детализации, разделять обязанности внутри команды и предоставлять пользователям только те типы доступа, которые им необходимы для выполнения своей работы. Подробнее

  • Вы также можете разделить обязанности, предоставив минимальный необходимый доступ для выполнения конкретной задачи. Например, у человека, ответственного за отслеживание рабочих нагрузок, не должно быть доступа к изменению политики резервного копирования или удалению элементов резервной копии. Azure Backup предусматривает три встроенные роли для управления резервным копированием: участники, операторы и читатели резервного копирования. Подробнее см. здесь. Сведения о минимальной роли Azure, требуемой для каждой операции резервного копирования для виртуальных машин Azure, баз данных SQL/SAP HANA и общей папки Azure, см. в этом руководстве.

  • Управление доступом на основе ролей Azure (Azure RBAC) также позволяет создавать настраиваемые роли на основе ваших индивидуальных требований. Если вы не уверены в типах ролей, рекомендуемых для конкретной операции, вы можете использовать встроенные роли, предоставляемые службой управления доступом на основе ролей Azure (RBAC Azure), и начать работу.

    На следующей схеме по объясняется, как работают разные встроенные роли Azure:

    Схема, объясняющая, как работают разные встроенные роли Azure.

    • На приведенной выше схеме User2 и User3 являются читателями резервного копирования. Таким образом, они могут только отслеживать резервные копии и просматривать службы резервного копирования.

    • С точки зрения области доступа,

      • User2 может получить доступ только к ресурсам Subcription1, а User3 может получить доступ только к ресурсам Subcription2.
      • User4 является оператором резервного копирования. Он имеет разрешение на включение резервного копирования, активацию резервного копирования по запросу, активацию восстановления вместе с возможностями средства чтения резервных копий. Однако в этом сценарии область действия ограничена только Subscription2.
      • User1 — это участник резервного копирования. У него есть разрешение на создание хранилищ, создание, изменение и удаление политик резервного копирования и остановку резервного копирования, а также возможности оператора резервного копирования. Однако в этом сценарии область действия ограничена только Subscription1.

  • Учетные записи хранения, которые используются хранилищами Служб восстановления, изолированы и недоступны для пользователей-злоумышленников. Доступ разрешается только через операции управления Azure Backup, такие как восстановление.

Шифрование передаваемых и хранимых данных

Шифрование защищает данные и помогает соблюсти корпоративные требования к обеспечению безопасности и соответствия.

  • В пределах Azure данные, передаваемые между службой хранилища Azure и хранилищем, защищены протоколом HTTPS. Эти данные остаются в сети Azure.

  • Резервные копии автоматически шифруются с использованием ключей, управляемых корпорацией Майкрософт. Кроме того, можно использовать собственные ключи — так называемые ключи, управляемые клиентом. Кроме того, использование шифрования CMK для резервного копирования не влечет за собой никаких дополнительных затрат. Однако использование Azure Key Vault, в котором хранится ключ, приводит к расходам, которые являются разумной платой за повышение безопасности данных.

  • Azure Backup поддерживает резервное копирование и восстановление виртуальных машин Azure, диски которых зашифрованы с помощью шифрования дисков Azure. Подробнее

Защита данных резервных копий от непреднамеренного удаления с помощью обратимого удаления

Вы можете столкнуться с ситуациями, в которых вы поместили критически важные данные резервной копии в хранилище, а они были удалены случайно или по ошибке. Кроме того, злоумышленник может удалить элементы резервной копии. Воссоздание этих ресурсов часто является затратным по времени и ресурсам процессом и даже может привести к потере критически важных данных. Azure Backup обеспечивает защиту от случайного и злонамеренного удаления с помощью функции Обратимое удаление, чтобы эти ресурсы можно было восстановить после их удаления.

При использовании обратимого удаления, если пользователь удалит резервную копию (виртуальной машины, базы данных SQL Server, общей папки Azure, базы данных SAP HANA), данные резервной копии хранятся еще 14 дней, что позволяет восстановить этот элемент без потери данных. Дополнительные 14 дней хранения данных резервной копии в режиме обратимого удаления предоставляются бесплатно. Подробнее

Авторизация нескольких пользователей (MUA)

Как защитить данные, если администратор окажется злоумышленником и скомпрометирует систему?

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

Azure Backup предоставляет функцию многопользовательской авторизации (MUA) для защиты от таких атак администратора-изгоев. Авторизация нескольких пользователей помогает защититься от администратора-злоумышленника, который выполняет вредоносные операции (например, отключая обратимое удаление), благодаря тому, что все привилегированные/вредоносные операции выполняются только после получения одобрения администратора безопасности.

Защита от программ-шантажистов

  • Прямой доступ к данным Azure Backup злоумышленником с целью шифрования исключен, так как все операции с данными резервных копий можно выполнять только помощью хранилища служб восстановления или хранилища резервных копий, которые можно защитить с помощью управления доступом на основе ролей Azure (RBAC Azure) и MUA.

  • Включение обратимого удаления при резервном копировании данных (которое включено по умолчанию) позволяет удерживать удаленные данные в течение 14 дней (без затрат). Отключение обратимого удаления можно защитить с помощью MUA.

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

Мониторинг подозрительных действий и создание оповещений о них

В некоторых случаях злоумышленник может попытается взломать систему и отключить механизмы безопасности, например обратимое удаление, или попытается выполнить опасные операции, например удалить ресурсов резервного копирования.

Azure Backup обеспечивает защиту от таких инцидентов путем отправки критических оповещений по предпочтительному каналу уведомлений (электронная почта, ITSM, веб-перехватчик, runbook и другие), создав правило действия поверх оповещения. Подробнее

Средства безопасности для защиты гибридных резервных копий

Azure Backup использует агент Служб восстановления Microsoft Azure (MARS) для резервного копирования и восстановления файлов, папок, томов или состояний системы с локального компьютера в Azure. Теперь MARS предоставляет функции обеспечения безопасности: предусмотрена парольная фраза для шифрования данных перед отправкой и их расшифровки после скачивания из Azure Backup, удаленные данные резервных копий хранятся еще 14 дней после их удаления, а критически важные операции (например, изменение парольной фразы) могут выполнять только пользователи, у которых есть действительные учетные данные Azure. Дополнительные сведения см. здесь.

Рекомендации по сети

Azure Backup требует перемещения данных рабочей нагрузки в хранилище Служб восстановления. В Azure Backup предусмотрен ряд возможностей для защиты от непреднамеренного предоставления открытого доступа к данным резервных копий (например, в результате атаки "злоумышленник в середине", направленной на сеть). Ознакомьтесь со следующими рекомендациями:

Подключение к Интернету

  • Резервная копия виртуальной машины Azure. Все необходимое взаимодействие и передача данных между хранилищем и службой Azure Backup происходит в сети Azure, без необходимости в доступе к вашей виртуальной сети. Поэтому для резервного копирования виртуальных машин Azure, размещенных в защищенных сетях, не требуется предоставлять доступ к каким-либо IP-адресам или FQDN.

  • Базы данных SAP HANA на виртуальной машине Azure, базы данных SQL Server на виртуальной машине Azure: требуется подключение к службе архивации Azure, служба хранилища Azure и идентификатору Microsoft Entra. Для этого можно использовать частные конечные точки или разрешить доступ к необходимым общедоступным IP-адресам или полным доменным именам. Неправильное подключение к необходимым службам Azure может привести к сбою в таких операциях, как обнаружение базы данных, настройка резервного копирования, выполнение резервного копирования и восстановление данных. Полное руководство по настройке сетевых подключений при использовании тегов NSG, брандмауэра Azure и прокси-сервера HTTP см. в этих статьях, посвященных SQL и SAP HANA.

  • Гибридная среда. Агенту MARS (Служб восстановления Microsoft Azure) требуется доступ к сети для выполнения всех критически важных операций: установки, настройки, резервного копирования и восстановления. Агент MARS может подключаться к службе Azure Backup через Azure ExpressRoute, используя общедоступный пиринг (доступный для старых каналов) и пиринг Майкрософт посредством частных конечных точек или через прокси-сервер либо брандмауэр с соответствующими элементами управления доступом.

Частные конечные точки для безопасного доступа

При защите критически важных данных с помощью Azure Backup нежелательно, чтобы ваши ресурсы были общедоступны через Интернет. Если ваша компания — банк или финансовое учреждение, для защиты данных с высокой степенью влияния на бизнес (HBI) особенно актуально соблюдать строгие требования к обеспечению соответствия и безопасности. Даже в области здравоохранения существуют строгие правила соответствия.

Для удовлетворения всех этих потребностей используйте Частную конечную точку Azure — это сетевой интерфейс, который защищенно и безопасно подключается к службе через Приватный канал Azure. Рекомендуем использовать частные конечные точки для обеспечения резервного копирования и восстановления без добавления в список разрешений всех IP-адресов и полных доменных имен для Azure Backup или службы хранилища Azure из виртуальных сетей.

Узнайте больше о том, как создавать и использовать частные конечные точки для Azure Backup в виртуальных сетях.

  • При включении частных конечных точек для хранилища они используются только для резервного копирования и восстановления рабочих нагрузок SQL и SAP HANA в виртуальной машине Azure, агенте MARS, резервном копировании DPM/MABS. Кроме того, хранилище можно использовать для резервного копирования других рабочих нагрузок (но для них не требуются частные конечные точки). Помимо резервного копирования рабочих нагрузок SQL и SAP HANA, резервное копирование с помощью агента MARS и сервера DPM/MABS, частные конечные точки также используются для восстановления файлов в случае резервного копирования виртуальных машин Azure. Дополнительные сведения см. здесь.

  • Идентификатор Microsoft Entra в настоящее время не поддерживает частные конечные точки. Таким образом, ip-адреса и полные доменные имена, необходимые для идентификатора Microsoft Entra ID, должны быть разрешены исходящий доступ из защищенной сети при резервном копировании баз данных на виртуальных машинах Azure и резервном копировании с помощью агента MARS. Вы также можете использовать теги NSG и теги Брандмауэр Azure для предоставления доступа к идентификатору Microsoft Entra, как применимо. Подробнее о предварительных требованиях см. здесь.

Рекомендации по системе управления

Система управления в Azure реализуется главным образом с помощью Политики Azure и Управления затратами Azure. Политика Azure позволяет создавать, назначать и администрировать определения политик для применения правил для ресурсов. Эта функция поддерживает соответствие этих ресурсов корпоративным стандартам. Служба Управление затратами Azure позволяет отслеживать использование облака и затраты для ресурсов Azure и других поставщиков облачных услуг. Кроме того, важную роль в управлении затратами играют такие средства, как Калькулятор цен Azure и Помощник по Azure.

Автоматическая настройка новой инфраструктуры резервного копирования с помощью Политики Azure в большом масштабе

  • Когда подготавливается к работе новая инфраструктура и создаются новые виртуальные машины, резервный администратор должен обеспечить их защиту. Вы можете легко настроить резервные копии для одной или двух виртуальных машин. Однако этот процесс становится сложным, если вам нужно настроить сотни или даже тысячи виртуальных машин. Чтобы упростить процесс настройки резервных копий, Azure Backup предоставляет набор встроенных политик Azure для управления хранилищем резервных копий.

  • Автоматическое включение резервного копирования на виртуальных машинах с помощью политики (модель группы централизованного резервного копирования): если у вашей организации есть центральная группа резервного копирования, которая управляет резервными копиями в группах приложений, эту политику можно использовать для настройки резервного копирования в существующем хранилище центральных служб восстановления в той же подписке и расположении, что и виртуальные машины. Вы можете включить или исключить виртуальные машины, содержащие определенный тег, из области действия этой политики. Подробнее.

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

  • Политика мониторинга. Чтобы создать для ресурсов Отчеты о резервном копировании, включите параметры диагностики при создании нового хранилища. Добавлять параметр диагностики вручную для каждого хранилища — задача зачастую трудоемкая. Таким образом, вы можете использовать встроенную политику Azure, которая настраивает параметры диагностики в большом масштабе для всех хранилищ в каждой подписке или группе ресурсов, где в качестве назначения используется Log Analytics.

  • Политика только для аудита: Azure Backup также предоставляет политику только для аудита, которая определяет виртуальные машины без конфигурации резервного копирования.

Затраты на Azure Backup

Служба Azure Backup обеспечивает гибкое, эффективное управление затратами без ущерба бизнес-требованиям BCDR (непрерывности бизнес-процессов и аварийного восстановления). Ознакомьтесь со следующими рекомендациями:

  • Используйте калькулятор цен для оценки и оптимизации своих затрат. Настраивать параметры на калькуляторе можно с помощью ползунков. Подробнее

  • Оптимизируйте политику резервного копирования.

    • Оптимизируйте расписание и параметры исходя из архетипов рабочей нагрузки (например, критически важная, некритичная).
    • Оптимизируйте параметры хранения для мгновенного восстановления.
    • Выберите подходящий для себя тип резервного копирования с учетом того, какие его типы (полное, добавочное, резервное копирование журналов, разностное) поддерживаются в Azure Backup для тех или иных рабочих нагрузок.

  • Уменьшите затраты на хранилище резервных копий с помощью дисков выборочного резервного копирования: функция исключения диска обеспечивает эффективный и экономичный выбор выборочно резервного копирования критически важных данных. Например, если вы не хотите создавать резервные копии всех дисков, подключенных к виртуальной машине, создайте резервную копию только одного диска. Это может также пригодиться при наличии нескольких решений для резервного копирования — Например, чтобы создать резервные копии баз данных или данных с помощью решения для резервного копирования рабочей нагрузки (база данных SQL Server в резервной копии виртуальной машины Azure), используйте резервное копирование на уровне виртуальной машины Azure для избранных дисков.

  • Ускорьте восстановление и уменьшите RTO с помощью функции мгновенного восстановления. Azure Backup создает моментальные снимки виртуальных машин Azure и сохраняет их вместе с дисками, чтобы повысить эффективность создания точек восстановления и ускорить восстановление. Это называется мгновенным восстановлением. Эта функция позволяет производить восстановление из таких моментальных снимков, сокращая временны́е затраты на восстановление. Благодаря этому обратное преобразование и копирование данных из хранилища занимает меньше времени. Таким образом, это повлечет затраты на хранение моментальных снимков, сделанных в течение этого периода. Подробнее о функции мгновенного восстановления Azure Backup.

  • Выберите подходящий тип репликации. По умолчанию для параметра "Тип репликации хранилища" Azure Backup установлено значение "Геоизбыточное (GRS)". После включения защиты данных этот параметр изменить нельзя. Геоизбыточное хранилище (GRS) обеспечивает большую устойчивость данных, чем локально избыточное хранилище (LRS), и позволяет по выбору использовать восстановление между регионами, но стоимость его выше. Решите, что нужнее в вашем сценарии — снизить затраты или повысить устойчивость данных. Подробнее

  • Используйте архивный уровень для долгосрочного хранения (LTR) и экономии средств. Рассмотрите сценарий, в котором старые резервные копии редко используются, но хранятся долго (например, 99 лет) из соображений соответствия требованиям. Хранение такого большого объема данных на уровне "Стандартный" является затратным и нерациональным с экономической точки зрения. Чтобы вы могли оптимизировать затраты на хранилище, Azure Backup предоставляет архивный уровень — уровень доступа, предназначенный для долгосрочного хранения (LTR) данных резервных копий.

  • Если вы защищаете как рабочую нагрузку, выполняющуюся в виртуальной машине, так и саму виртуальную машину, то убедитесь, что такая двойная защита необходима.

Рекомендации по мониторингу и рассылке уведомлений

Как пользователь или администратор резервного копирования, вы должны быть в состоянии вести мониторинг всех решений для резервного копирования и получать уведомления о важных событиях. В этом разделе описаны возможности мониторинга и уведомления, предоставляемые службой Azure Backup.

Azure Monitor

  • В Azure Backup предусмотрен встроенный мониторинг заданий для таких операций, как настройка резервного копирования, резервное копирование, восстановление, удаления резервных копий и так далее. Он ограничивается конкретным хранилищем и идеально подходит для случая, когда хранилище всего одно. Дополнительные сведения см. здесь.

  • Если необходим мониторинг операций в большом масштабе, вам поможет Обозреватель резервного копирования, в котором отображается сводное представление всей системы резервного копирования, что позволяет проводить детальный анализ и устранять неполадки. Обозреватель резервного копирования — это встроенная книга Azure Monitor, обеспечивающая централизованный мониторинг операций во всей системе резервного копирования в среде Azure, включая клиенты, расположения, подписки, группы ресурсов и хранилища. Дополнительные сведения см. здесь.

    • Используйте его, чтобы выявлять ресурсы, для которых не настроено резервное копирование, и не оставить случайно без защиты важные данные в вашем растущем информационном хозяйстве.
    • На панели мониторинга отображаются операции за последние семь дней (максимум). Если необходимо сохранить эти данные, можно экспортировать их в виде файла Excel и оставить на хранение.
    • Если вы пользуетесь Azure Lighthouse, то можете просматривать сведения по нескольким клиентам и, таким образом, вести мониторинг без границ.

  • Если необходимо хранить и просматривать операции за долгосрочный период, используйте Отчеты. Чаще всего администраторам резервного копирования требуется получать аналитические сведения о резервных копиях по данным за длительный период времени. Ниже перечислены различные сценарии использования такого решения.

    • Выделение и прогнозирование потребления ресурсов облачного хранилища.
    • Аудит операций резервного копирования и восстановления.
    • Определение ключевых тенденций при различных уровнях детализации.

  • Кроме того, примите во внимание следующее:

    • Вы можете организовать передачу данных (заданий, политик и т. д.) в рабочую область Log Analytics. Тогда с помощью функциональности журналов Azure Monitor можно будет сопоставлять их с другими данными мониторинга, собранными Azure Monitor, консолидировать записи журналов из нескольких подписок Azure и клиентов в едином месте для анализа, а также выполнять сложный анализ и получать подробные аналитические сведения о записях журналов, используя запросы к журналам. Дополнительные сведения см. здесь.
    • Вы можете организовать передачу данных в концентратор событий Azure для отправки записей за пределы Azure — например, в сторонние системы управления информационной безопасностью и событиями безопасности (SIEM) или в другое решение для анализа журналов. Дополнительные сведения см. здесь.
    • Вы можете отправлять данные в учетную запись служба хранилища Azure, если вы хотите сохранить данные журнала дольше 90 дней для аудита, статического анализа или резервного копирования. Если же вам достаточно хранить события в течение 90 дней или более короткого срока, настраивать архивацию в учетную запись хранения нет необходимости, так как события в журнале действий хранятся на платформе Azure 90 дней. Подробнее.

видны узлы

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

Такие критические оповещения можно настроить и перенаправить на любой предпочитаемый канал уведомлений (электронную почту, ITSM, веб-перехватчик, runbook и т. д.). Azure Backup интегрируется с различными службами Azure в зависимости от требований к оповещениям и уведомлениям.

  • Журналы Azure Monitor (Log Analytics). Вы можете настроить хранилища для отправки данных в рабочую область Log Analytics, написания пользовательских запросов в рабочей области и настройки оповещений на основе результатов запроса. Результаты запроса можно просмотреть в таблицах и диаграммах, а также экспортировать в Power BI или Grafana. (Log Analytics также является ключевым компонентом функции отчетности и аудита, описанной в последующих разделах.)

  • Оповещения Azure Monitor. В некоторых стандартных сценариях, например в случае сбоя резервного копирования, сбоя восстановления, удаления данных резервных копий и подобных ситуациях, Azure Backup по умолчанию отправляет оповещения, полученные с помощью Azure Monitor, без необходимости настройки рабочей области Log Analytics.

  • В Azure Backup имеется встроенный механизм оповещений по электронной почте о сбоях, предупреждениях и критических операциях. Для оповещений можно указывать отдельные адреса электронной почты или списки рассылки. Можно также выбрать способ получения оповещений — по отдельности или сгруппированными в виде почасового дайджеста.

    • Эти оповещения определяются службой и поддерживают ограниченный круг сценариев: сбои резервного копирования и восстановления, снятие защиты с сохранением или удалением данных и так далее. Дополнительные сведения см. здесь.
    • При выполнении разрушительной операции, такой как снятие защиты с удалением данных, создается оповещение и отправляется сообщение электронной почты владельцам подписки, администраторам и соадминистраторам, даже если уведомления для хранилища Служб восстановления не настроены.
    • Определенные рабочие нагрузки могут выдавать оповещения о сбоях с высокой частотой (например, SQL Server — каждые 15 минут). Чтобы избежать когнитивной перегрузки от оповещений по каждому случаю сбоя, оповещения консолидируются. Дополнительные сведения см. здесь.
    • Встроенные оповещения не предусматривают настройки и могут доставляться только в виде сообщений электронной почты, определенных на портале Azure.

  • Если вам требуются настраиваемые оповещения (например, об успешном выполнении заданий), используйте Log Analytics. В Azure Monitor можно создавать собственные оповещения в рабочей области Log Analytics. Гибридные рабочие нагрузки (DPM/MABS) могут также передавать данные в LA и с помощью LA вырабатывать общие оповещения для различных рабочих нагрузок, поддерживаемых Azure Backup.

  • Кроме того, вы можете получать уведомления через встроенные журналы действий хранилища Служб восстановления. Однако они поддерживают ограниченный круг сценариев и не подходят для таких операций, как резервное копирование по расписанию, для которых органичнее использовать журналы ресурсов. Подробнее об этих ограничениях и о том, как использовать рабочую область Log Analytics для мониторинга и оповещений в большом масштабе по всем рабочим нагрузкам, защищенным Azure Backup, см. в этой статье.

Автоматическая попытка повторного выполнения заданий резервного копирования, завершившихся сбоем

Многие ошибки сбоя или сценарии сбоя являются временными, и вы можете устранить, настроив правильные разрешения на управление доступом на основе ролей Azure (Azure RBAC) или повторно активировать задание резервного копирования и восстановления. Так как решение таких сбоев является простым, что вам не нужно инвестировать время, ожидая, чтобы инженер вручную активировал задание или назначить соответствующее разрешение. Таким образом, более рациональный способ обработки этого сценария — автоматизировать попытки повторного выполнения заданий, завершившихся сбоем. Это позволит значительно уменьшить время, необходимое для восстановления после сбоев. Для этого необходимо получить соответствующие данные резервной копии с помощью службы Azure Resource Graph (ARG) и объединить их с помощью корректной процедуры PowerShell/CLI.

Посмотрите видео, чтобы узнать, как повторно запускать резервное копирование для всех заданий, завершившихся сбоем (в хранилищах, подписках, арендаторах) с помощью ARG и PowerShell.

Направляйте оповещения в предпочитаемый канал уведомлений

Хотя временные ошибки можно исправить, для устранения некоторых постоянных ошибок может понадобиться глубокий анализ, и повторный запуск заданий может оказаться неподходящим решением. Вы можете настроить собственные механизмы мониторинга и отправки запросов, обеспечивающие правильное отслеживание и исправление таких сбоев. Для обработки таких сценариев вы можете направить оповещения в предпочитаемый канал уведомлений (электронную почту, ITSM, веб-перехватчик, runbook и другие), создав правило действия для оповещения.

Посмотрите видео, чтобы узнать, как использовать Azure Monitor для настройки различных механизмов уведомлений для критических оповещений.

Следующие шаги

В качестве введения в работу с Azure Backup ознакомьтесь со следующими статьями: