Безопасность в российском облаке: модель разделения ответственности между провайдером и компанией

Облака в России — это новая рабочая реальность. Туда переносят критичные сервисы, персональные данные, системы аутентификации. По итогам 2025 года объём российского рынка облачных сервисов, по оценке ООО «АЦ ИКС», составил 416,5 млрд руб. Это на 32,8% больше, чем в 2024. По многим оценкам, этот рост продолжится дальше, и к 2030 объём рынка составит 1,2 трлн руб. И тут возникает вопрос, который мы регулярно обсуждаем с коллегами: кто отвечает за безопасность, если что-то пойдёт не так? Провайдер, который даёт инфраструктуру, или мы, компания, которая размещает в облаке свои системы?

Ответы на эти и другие вопросы в материале Валерия Аблекова, технического директора компании МУЛЬТИФАКТОР, который рассказал, как на самом деле устроено разделение ответственности в российском облаке, какие документы это регулируют и что стоит проверить до того, как вы подпишете договор.

Базовое разделение ответственности

В идеальном мире всё просто. Облачный провайдер (ЦОД) отвечает за «железо»: здания, электричество, охлаждение, физическую охрану, сеть до уровня гипервизора. Заказчик (компания) отвечает за всё, что работает поверх: операционки, приложения, данные, управление доступом, политики безопасности. В реальности граница часто размывается. Провайдеры по умолчанию стремятся снять с себя максимум ответственности. Заказчики не всегда понимают, что требования регуляторов остаются на них, даже если данные физически лежат в стороннем дата-центре.

Решение одно — детальное соглашение о разделении ответственности. В нём должно быть прописано, кто за что отвечает в каждом блоке: доступность, защита данных, соответствие требованиям регуляторов, реагирование на инциденты. Без такого документа вы рискуете оказаться в ситуации, когда все говорят: «Это не мы», а проблему приходится решать вам.

Зона доступности: SLA, реальные потери и конфликт интересов

Один из самых болезненных вопросов: кто отвечает, когда облако «падает». Несколько часов недоступности могут стоить заказчику миллионов: простой бизнес-процессов, недополученная выручка, удар по репутации. В договоре с ЦОД обычно есть SLA — соглашение об уровне доступности. Но компенсации за нарушение SLA часто выглядят как капля в море на фоне реальных потерь. Провайдер предлагает скидку на десятки тысяч рублей, а ваш простой стоит десятки миллионов.

Я вижу два пути решения. Первый — выбрать провайдера с архитектурой высокой доступности: несколько независимых дата-центров, построенная схема высокой доступности Active-Active, с автоматическим переключением трафика при отказе одной из площадок. Второй — обсудить с провайдером расширенную ответственность за недоступность, но это почти всегда увеличивает стоимость услуг. Тут каждый решает сам, исходя из своего бюджета и аппетита к риску.

До подписания договора я рекомендую задать провайдеру шесть вопросов:

1. Сколько у вас независимых дата-центров и в каких они городах?
2. Как организована схема резервирования?
3. Что происходит при отказе одной площадки?
4. Какое среднее время восстановления (RTO)?
5. Прописана ли в договоре компенсация за нарушение SLA и в каком размере?
6. Как организована информационная безопасность?

Если ответов на эти вопросы нет — это повод задуматься.

Персональные данные: ответственность остаётся у заказчика

С персональными данными правило одно и то же, как ни крути: оператором остаётся ваша компания-заказчик, даже если данные лежат в облаке у провайдера. Поэтому все требования 152-ФЗ и приказа ФСТЭК № 21 от 13.02.2013 — на вас. Вы отвечаете за безопасность персональных данных, включая технические и организационные меры. Провайдер со своей стороны должен дать инфраструктуру, которая этим требованиям соответствует, и подписать с вами соглашение о разграничении ответственности.

Как это выглядит в жизни? Цепочка такая: регулятор → вы (заказчик и оператор ПДн) → облачный провайдер → его субподрядчики (ЦОДы). Если, где-то в этой цепочке что-то идёт не так, в итоге всё равно спрашивают с оператора персональных данных, то есть с вас.

Поэтому перед выбором провайдера нужно проверить хотя бы пять пунктов:

1. Есть ли у провайдера Политика по обработке персональных данных?
2. Соответствует ли инфраструктура требованиям ФСТЭК (Приказ № 21 от 13.02.2013)?
3. Есть ли у провайдера аттестованные облачные сегменты для работы с персональными данными?
4. Готов ли провайдер предоставить выписку из договора между провайдером и ЦОД (хотя бы в части мер безопасности)?
5. Внесён ли провайдер в реестр операторов персональных данных Роскомнадзора?

Отсутствие этих документов или неготовность их предоставить — красный флаг. Лучше потратить время на проверку сейчас, чем потом объясняться с регулятором.

PCI DSS: как стандарт помогает разделить ответственность

Если вы работаете с платёжными данными, модель разделения ответственности уже придумана за вас — она прописана в стандарте PCI DSS. Там прямо сказано: что делает провайдер, а что заказчик.

Заказчик отвечает за защиту сред и данных всех сторон, которых он обслуживает, включая данные держателей карт. Проще говоря, на нём вся «внутренняя кухня» безопасности: как настроены брандмауэры и маршрутизаторы, кто и как имеет доступ к среде с данными карт, чтобы конфигурации не «разъезжались» и были актуальны, чтобы была DMZ, чтобы заводские пароли и настройки были изменены, чтобы ключи шифрования хранились и управлялись правильно, чтобы антивирусы стояли и обновлялись, уязвимости вовремя находились и закрывались, изменения контролировались, доступ к ресурсам был ограничен, а учётные записи и аутентификация — под контролем.

Физическая безопасность: ответственность пополам

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

А вот всё, что работает поверх инфраструктуры уже зона ответственности заказчика. Действия, совершённые под вашей учётной записью, тоже ваши. Эта модель полезна не только для платёжных данных. Она показывает общий принцип: провайдер отвечает за инфраструктуру, заказчик — за то, что на этой инфраструктуре работает.

Как это у нас

В качестве примера реализованной модели разделения ответственности можно привести облачную инфраструктуру MULTIFACTOR. Сегодня облачная версия обслуживает более 1 000 000 пользователей. Каждый рабочий день система обрабатывает сотни тысяч операций аутентификации. Для обеспечения высокой доступности промышленная инфраструктура спроектирована как распределённая система.

Первый уровень отказоустойчивости — несколько независимых дата-центров. Архитектура построена в трёх ЦОДах, объединённых выделенными каналами Direct Connect и собственными волоконно-оптическими линиями связи. Площадки работают по схеме Active-Active: каждый дата-центр постоянно принимает пользовательские запросы. Если одна площадка становится недоступной, трафик идёт на другую. Третья площадка включается, если недоступен весь основной кластер. Такая схема позволяет поддерживать доступность сервиса на уровне 99,99%, а среднее время ответа не превышает 30 мс.

Второй уровень — разделение сервисов. В инфраструктуре используется более 100 виртуальных серверов и 600 подов. Каждый компонент платформы выполняет собственную функцию: вычислительные кластеры Kubernetes, базы данных, системы хранения резервных копий, журналирование, мониторинг. Такое разделение позволяет масштабировать подсистемы независимо и уменьшает влияние отдельных отказов.

Третий уровень — отказоустойчивая база данных. Основная MongoDB развёрнута минимум на трёх виртуальных машинах в каждом дата-центре. Репликация организована по схеме ReplicaSet. Для защиты от DDoS-атак используется NGENIX, который также играет роль балансировщика запросов между тремя дата-центрами.

В июле 2026 года облачная часть MULTIFACTOR получила аттестат соответствия требованиям ФСТЭК России для класса защищённости К1 и уровня защищённости персональных данных УЗ1. Это означает, что облачная модель получила подтверждение соответствия государственным требованиям, и выбор между облачным и локальным развёртыванием определяется не вопросами доверия к облаку, а особенностями проекта и нормативными ограничениями.

Искусственный интеллект: проблемы будущего, которые уже здесь

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

С одной стороны, ИИ помогает обнаружить аномалии, спрогнозировать инциденты, автоматизировать рутинные задачи. С другой возникает вопрос: куда уходят данные, которые вы отправляете в облачную ИИ-модель? Если в процессе обработки персональные или чувствительные данные попадают в другую компанию (например, провайдеру ИИ-сервиса), кто несёт ответственность? Облачный провайдер эту ответственность на себя не возьмёт. Заказчик скажет: «Я отправил данные вам, а вы их куда-то дели». А на самом деле это сделала ИИ-модель. В результате оператор персональных данных остаётся один на один с регулятором.

Но этот вопрос не только про ответственность, про неё обычно думают в первую очередь. А что делать с результатом? Деньги на ИИ-сервис потрачены, а результата нет или он не соответствует вашим представлениям о прекрасном. Как вернуть средства? Как доказать, что они были потрачены целевым образом? Если ИИ-модель выдала некорректный прогноз или не решила задачу, провайдер может ответить: «Модель работала в рамках заявленных параметров, результат зависит от ваших данных». А вы уже заплатили и ничего не получили.

Рекомендация простая: не сливать в публичные ИИ-сервисы персональные данные, коммерческую тайну и любую чувствительную информацию. Если ИИ необходим — использовать изолированные решения, развёрнутые в собственном контуре или в аттестованном облаке, где вы контролируете потоки данных. И заранее прописывать в договоре не только вопросы ответственности за данные, но и критерии результата: что считается выполненной задачей, как измеряется эффективность, какие есть механизмы возврата средств или перерасчёта. Не стоит забывать и про чистоту данных и корректность обучения ИИ-модели.

Вместо вывода

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

• Есть ли соглашение о разделении ответственности?
• Соответствует ли инфраструктура требованиям 152-ФЗ и приказа ФСТЭК № 21 от 13.02.2013?
• Внесён ли провайдер в реестр операторов персональных данных Роскомнадзора?
• Есть ли аттестованные облачные сегменты (если работаете с гостайной или персональными данными)?
• Прописан ли в договоре SLA и предусмотрена ли компенсация за его нарушение?
• Сколько независимых дата-центров используется?
• Как организовано резервирование и переключение при отказе площадки?
• Готов ли провайдер предоставить информацию о мерах безопасности (хотя бы основные моменты)?
• Есть ли у провайдера сертификаты (ФСТЭК, PCI DSS, ISO 27001)?
• Назначен ли у вас внутренний ответственный за взаимодействие с провайдером?

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

Используемые термины

Гипервизор — это специальная программа или слой кода, который делит один физический компьютер на много независимых виртуальных машин.

SLA (Service Level Agreement) — это соглашение об уровне сервиса.

Active-Active (активно-активный) — это схема работы компьютерной системы, где два или более серверов (узлов) работают одновременно.

RTO (Recovery Time Objective или «целевое время восстановления») — это максимальное время, в течение которого ИТ-система, сервис или сайт могут оставаться недоступными после аварии или сбоя, пока их снова не включат.

PCI DSS (Payment Card Industry Data Security Standard) — это международный стандарт безопасности данных.

DMZ (Demilitarized Zone — демилитаризованная зона, ДМЗ) — сегмент сети, содержащий общедоступные сервисы и отделяющий их от частных.

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

Kubernetes (или K8s) — это бесплатная программа с открытым кодом для автоматического управления множеством контейнеров с приложениями на разных серверах.

MongoDB — это популярная NoSQL система управления базами данных (СУБД).

ReplicaSet (репликасет) в Kubernetes — это специальный объект-контроллер, который следит за тем, чтобы в кластере всегда работало строго заданное число одинаковых копий подов (Pod).

DDoS-атака (Distributed Denial of Service) — это кибератака на сайт, сервер или сеть с целью вывести их из строя.

NGENIX — это быстрый веб-сервер с открытым исходным кодом.

Класс защищённости К1 — высший класс безопасности, присваиваемый государственным информационным системам (ГИС).

Уровень защищённости персональных данных УЗ1 — это максимальный уровень защищённости информационных систем персональных данных (ИСПДн) в соответствии с Постановлением Правительства РФ № 1119.

ISO 27001 — это главный мировой стандарт информационной безопасности.