Google Workspace как вариант обеспечения непрерывности бизнеса при сбоях в работе Microsoft 365

Когда происходит сбой в работе Microsoft 365, первым вопросом, который возникает у всех, становится: как вернуть сотрудников к работе. Это практическая проблема обеспечения непрерывности бизнеса, и Google Workspace может стать практическим решением.

Для большинства компаний Microsoft 365 — это инфраструктура, обеспечивающая коммуникацию, координацию и функционирование самого бизнеса. В случае сбоя в работе Microsoft 365 сразу же начинают поступать вопросы:

Можно ли отправлять и получать электронную почту?

Они могут посмотреть свои календари?

Имеет ли руководство по-прежнему доступ к электронной почте и календарю для организации мер по ликвидации последствий кризиса?

Могут ли подразделения, работающие с клиентами, по-прежнему поддерживать внешнюю коммуникацию?

Могут ли члены команды получить доступ к файлам? Или им нужно сначала дождаться восстановления данных из резервной копии?

Эти вопросы сейчас важны как никогда, поскольку нормативные требования предъявляют все более высокие требования к операционной устойчивости и обеспечению непрерывности деятельности.

Независимо от того, стремитесь ли вы к SOC 2 управление доступностью, навигация NIS2 требования к операционной устойчивости или приведение в соответствие с такими концептуальными моделями, как NIST CSF 2.0 и ISO 22301, необходимо тщательно проанализировать степень зависимости от Microsoft 365. Полагаться исключительно на гарантии бесперебойной работы Microsoft в качестве стратегии обеспечения непрерывности бизнеса становится всё менее оправданным.

Это побудило технические команды все чаще обращаться к вариантам «горячего резервирования», в частности к решению Google Workspace. Не в качестве замены Microsoft 365 и не в качестве традиционного инструмента резервного копирования, а в качестве второй, независимой облачной среды, способной обеспечить доступ к электронной почте, календарям, файлам и важным средствам связи в случае сбоев в работе Microsoft 365.

Это совершенно иной подход к организации платформы резервного копирования Microsoft 365, такой как Veeam, Druva или другое решение для восстановления данных, которое позволяет восстанавливать почтовые ящики, файлы и другие данные после инцидента. Какими бы хорошими ни были эти платформы, если тысячам пользователей в течение следующих двух часов потребуется доступ к рабочему почтовому ящику и календарю, одной только резервной копии для этого будет недостаточно.

Google Workspace can indeed support business continuity during a Microsoft 365 outage, especially for email, calendar, appointments, and crisis communication. Microsoft 365 remains the primary platform, while Google Workspace provides an independent continuity environment. But this kind of cross-cloud business continuity model requires the right architecture and planning: identity, mail routing, synchronization, security, user access, and failback all need to be designed and tested before the outage happens, not during it.

Такие нормативные акты и рамочные документы, как NIS2, DORA и Рамочная концепция кибербезопасности NIST, повышают требования к предотвращению сбоев в работе жизненно важных услуг и критически важных или важных функций, а также к управлению такими сбоями, хотя их сфера применения, терминология и юридическая сила различаются.

ДОРА определяет “критическую или важную функцию” исходя из существенного воздействия, которое её сбой может оказать на финансовые показатели, непрерывность предоставления услуг или выполнение нормативных обязательств, при этом NIS2 требует внедрения мер по обеспечению непрерывности бизнеса и кризисному управлению в рамках управления рисками кибербезопасности. Кроме того, такие рамки, как NIST CSF решать связанные с этим задачи с помощью функций «Управление», «Реагирование» и «Восстановление», включая реагирование на инциденты, восстановление работоспособности и информирование.

Даже если используемые термины не являются единообразными, практический вопрос остаётся:

Какие сервисы и зависимости являются критически важными в вашей организации?

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

Если этот облачный сервис будет недоступен в течение X часов, превысим ли мы установленные по закону, операционные, связанные с обслуживанием клиентов, безопасностью или финансовые пороговые значения?

В случае Microsoft 365 такая оценка должна включать:

• RTO и RPO: how quickly services need to resume, and how much data loss is acceptable
• Радиус взрыва: какие функции, подразделения, клиенты или процессы затронуты
• Риск концентрации: в какой степени это зависит от конкретного провайдера, арендатора, региона или уровня идентификации
• Взаимозависимости: аутентификация, управление ключами, доступ к сети, интеграции и каналы внешней связи

Если посмотреть на Microsoft 365 через эту призму, картина редко выглядит обнадеживающей. Электронная почта, идентификация пользователей, календари и доступ к файлам зачастую оказываются операционными зависимостями, требующими тщательного планирования обеспечения непрерывности работы, а не просто резервного копирования и восстановления.

Нормативные акты и стандарты не предписывают использование какой-либо конкретной архитектуры обеспечения непрерывности работы или услуг определенных поставщиков. Тем не менее, их требования могут напрямую влиять на её проектирование:

• ISO 22301 требует установления четких целей по восстановлению, документированных процедур обеспечения непрерывности работы и проведения регулярных тестов. В тех случаях, когда это оправдано с точки зрения потенциального воздействия на бизнес, целесообразно использовать режим «горячего резервирования» для Microsoft 365.
• Если ваша организация является финансовой организацией, ДОРА requires you to assess information and communication technology (ICT) concentration risk and provider substitutability. It also requires documented exit strategies for ICT services that support critical or important functions. Depending on the risk assessment, this may support an alternative-provider or multi-vendor design, but DORA does not mandate one specific architecture.
• NIS2 распространяет эту же логику на более широкий круг ключевых и важных объектов и явно включает обеспечение непрерывности бизнеса, восстановление после аварий, управление кризисными ситуациями и безопасность цепочки поставок в свои меры по управлению рисками кибербезопасности. Благодаря этому зависимость от крупных облачных сервисов и поставщиков услуг становится одним из важных факторов при оценке рисков организации.
• В США функции «Управление», «Реагирование» и «Восстановление» NIST CSF 2.0 требуют разработки проверенных планов восстановления и управления рисками в цепочке поставок, что вызывает тот же вопрос: смогут ли критически важные функции продолжать работу в случае выхода из строя ключевого поставщика?

Архитектурный вопрос заключается в том, как обеспечить непрерывность работы критически важных функций в случае недоступности основного поставщика. Если сбой в работе Microsoft 365 может привести к прерыванию этих функций, организации может потребоваться альтернативная среда, которая уже подготовлена, доступна и протестирована. Этот риск зачастую оказывается более значительным, чем кажется на первый взгляд, поскольку Microsoft 365 представляет собой не одну, а несколько взаимосвязанных точек зависимости.

Microsoft 365 объединяет четыре компонента, каждый из которых в отдельности уже сам по себе является основанием для разработки плана обеспечения непрерывности деятельности:

• Общение (Exchange / Teams). Сбой в маршрутизации почты или отключение чата на практике приводит к остановке работы компании, даже если с технической точки зрения все файлы находятся в безопасности.
• Календарь (Exchange / Teams). Проблемы с планированием и доступом к встречам возникают точно так же, как и с электронной почтой, что приводит к отсутствию внутренней координации и пропуску внешних встреч, даже если с технической точки зрения ничего не "потеряно"."
• Документы (SharePoint / OneDrive). Файлы должны оставаться доступными, а не просто поддаваться восстановлению.
• Идентичность (Entra ID / Azure AD). Если уровень аутентификации выходит из строя, не имеет значения, что ещё работает: никто не сможет войти никуда, в том числе в сторонние приложения, которые используют того же поставщика идентификации.

На данном этапе обычно выявляется неприятный факт: стандартное программное обеспечение для резервного копирования защищает только третий пункт, причем только после завершения процесса восстановления, который может занять 24–48 часов. А пока у пользователей нет альтернативного места, где они могли бы реально работать.

Первым решением, которое приходит на ум, может быть создание дополнительного арендатора Microsoft. К сожалению, при более тщательном рассмотрении этот вариант не выдерживает критики, поскольку сбой может привести к одновременному отключению обоих арендаторов, даже если они развернуты в разных регионах Microsoft 365 или Azure. Региональный хостинг не означает наличия независимых доменов отказов, поскольку Entra ID и основные службы Microsoft 365 по-прежнему используют одну и ту же глобальную инфраструктуру.

Наличие второго арендатора формально соответствует требованию "у нас есть запасной арендатор", но не обеспечивает достаточной независимости.

Именно это побуждает к поиску отдельного гипермасштабируемого провайдера. Не потому, что Google Workspace по своей сути более надежен, а потому, что он предоставляет операционно обособленную инфраструктуру и стек идентификации. Такое разделение может помочь решить проблемы, связанные с риском концентрации ИКТ и обеспечением непрерывности бизнеса, которые отражены в директивах DORA и NIS2.