Освободить ЦОД от ответственности за утечки? Всё сложнее, чем кажется

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

Это важная оговорка.

Существование проекта сомнений практически не вызывает. Еще в июне «Ведомости» сообщали, что Аналитический центр подготовил проект дорожной карты «Гильотина 2.0» по направлению «Центр обработки данных», предусматривающий изменения более 15 нормативных актов. При этом источники издания отдельно предупреждали, что документ может изменяться в ходе обсуждения, а Минцифры тогда говорило, что формирование подходов продолжается и обсуждать детали преждевременно.

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

Но на официальной странице документов проекта «Регуляторная гильотина» опубликованной дорожной карты по направлению «Центр обработки данных» сейчас нет: поиск по словам «ЦОД» и «Центр обработки данных» результата не дает.

Следовательно, мы пока обсуждаем не опубликованный нормативный текст, а его изложение средствами массовой информации.

А это существенно.

Формулировки:

«освободить ЦОД от ответственности за утечки»,

«исключить ответственность ЦОД, если он не осуществляет обработку ПДн»

и

«разграничить ответственность оператора ПДн и инфраструктурного провайдера»

юридически означают совершенно разные вещи.

Сам по себе ЦОД действительно не обязательно является оператором ПДн

В этом с Минцифры сложно спорить.

Статья 3 Федерального закона № 152-ФЗ определяет оператора как лицо, которое организует или осуществляет обработку персональных данных и определяет цели обработки, состав данных и совершаемые с ними операции.

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

Поэтому классическая ситуация вполне возможна.

Компания привезла собственный сервер, установила его в стойку коммерческого ЦОД, самостоятельно развернула ОС, базу данных, средства защиты и приложения. ЦОД предоставляет только:

• помещение;
• электропитание;
• охлаждение;
• пожаротушение;
• физическую охрану;
• стойко-место;
• подключение к каналам связи.

Сотрудники ЦОД не знают, какие именно данные находятся на сервере, не имеют учетных записей в системе и не определяют цели обработки.

Признавать такой ЦОД самостоятельным оператором персональных данных клиента действительно было бы странно.

Но из этого совершенно не следует, что он вообще не влияет на безопасность этих данных.

«Не имеем доступа к базе» не означает «не можем стать причиной утечки»

Рассмотрим простой пример.

Клиент разместил собственный сервер в ЦОД. Доступ к операционной системе есть только у клиента.

Но сетевой путь выглядит примерно так:

сервер клиента — коммутационное оборудование — кроссировка — кабельная инфраструктура — оператор связи.

Предположим, сотрудник ЦОД получает физический доступ к участку кабельной трассы и организует перехват трафика.

Формально пароль от базы данных ему действительно неизвестен.

Но означает ли это, что ЦОД никак не связан с произошедшим инцидентом?

Очевидно, нет.

Более того, новое регулирование самих дата-центров прямо признает существование такой зоны ответственности.

С 1 марта 2026 года действует постановление Правительства РФ № 1932 о реестре российских ЦОД. Для включения в реестр оператор ЦОД декларирует, среди прочего:

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

То есть действующее регулирование буквально признает: у владельца ЦОД есть собственная эксплуатационная область ответственности, включающая физическую безопасность и кабельную инфраструктуру.

И это плохо сочетается с максимально широкой трактовкой «ЦОД только предоставляет помещение и потому к утечке отношения иметь не может».

А если утечки вообще не было, но данные уничтожены?

Есть еще более наглядный сценарий.

Из-за ошибки обслуживающего персонала ЦОД происходит сбой электроснабжения. Резервирование не срабатывает. Оборудование клиента аварийно выключается, повреждается СХД, часть персональных данных восстановить невозможно.

152-ФЗ рассматривает безопасность ПДн значительно шире одной конфиденциальности.

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

А постановление № 1932 требует от ЦОД обеспечения отказоустойчивости инженерных систем, возможности обслуживания без прекращения предоставления услуг и резервирования компонентов. В самом реестре даже фиксируется категория электроснабжения ЦОД.

Теперь возникает вопрос: кто виноват?

Ответ зависит от обстоятельств.

Если заказчик приобрел две независимые линии электропитания, а сотрудники ЦОД своим ошибочным действием одновременно отключили обе, одна ситуация.

Если заказчик выбрал дешевую конфигурацию без резервирования и держал единственную копию критичной базы на одном сервере — другая.

Если резервное копирование входило в договор с тем же провайдером, но оказалось неработоспособным — третья.

Поэтому реальный анализ ответственности начинается не с вывески «ЦОД», а с архитектуры и договора.

Потому что «услуги ЦОД» бывают очень разными

Когда в новостях пишут просто «коммерческий дата-центр», возникает ложное впечатление, что речь всегда идет об одном и том же.

На практике различия огромны.

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

При Dedicated Server / Bare Metal сервер уже принадлежит провайдеру.

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

При PaaS часть ОС, СУБД, middleware и runtime также переходит под управление поставщика.

При SaaS клиент вообще получает готовое приложение, а практически весь технический стек находится у поставщика.

Отдельно существуют Managed Hosting, Backup-as-a-Service, Disaster-Recovery-as-a-Service, Managed Firewall, DDoS Protection, SOC-as-a-Service и множество промежуточных вариантов.

Даже официальные методические материалы различают colocation как размещение принадлежащего организации сервера в дата-центре провайдера и другие варианты размещения инфраструктуры.

Поэтому универсальная формула «ЦОД не имеет доступа к данным» просто не описывает весь рынок.

А кто тогда устанавливает средства защиты?

Еще один вопрос, который почти отсутствует в обсуждении новости.

Предположим, сервер действительно принадлежит клиенту.

Кто предоставляет:

• межсетевой экран;
• VPN;
• защиту от DDoS;
• сетевую сегментацию;
• маршрутизацию;
• IDS/IPS;
• управление гипервизором;
• систему хранения;
• резервное копирование;
• средства мониторинга;
• физический контроль доступа?

Ответ: зависит от услуги.

В классическом colocation практически весь собственный защитный контур клиент действительно может построить самостоятельно.

Но в IaaS клиент физически не может управлять гипервизором провайдера, его коммутаторами или внутренней сетью хранения.

А при Managed Firewall уже сам провайдер может администрировать правила межсетевого экранирования.

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

Физическая защита тоже является частью защиты ПДн

Постановление Правительства № 1119 устанавливает требования к защите ПДн в информационных системах.

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

Если сервер стоит в собственной серверной организации — понятно, кто отвечает за двери, СКУД и режим помещения.

Если он находится в коммерческом ЦОД — значительная часть этих мер фактически обеспечивается сторонней организацией.

При использовании СКЗИ связь между физической инфраструктурой и защитой еще очевиднее. Приказ ФСБ России № 378 требует обеспечивать режим помещений с СКЗИ и ключевой информацией, устанавливать правила доступа и перечни лиц, имеющих право доступа.

Поэтому физическую инфраструктуру нельзя просто вынести за скобки информационной безопасности.

Но все это всё равно не делает каждый ЦОД оператором ПДн

Здесь важно не уйти в другую крайность.

Если электрик по ошибке отключил питание сервера с персональными данными, он от этого не становится оператором ПДн.

Если сотрудник ЦОД получил несанкционированный доступ к кабельной трассе, это тоже не означает автоматически, что организация изначально являлась оператором ПДн клиента.

Нужно разделять два вопроса:

Какова роль организации в обработке персональных данных?

и

За какой участок инфраструктуры, действия и обязательства она отвечает?

Это не одно и то же.

И именно поэтому правильным направлением мне кажется не «дать ЦОД иммунитет», а четко разграничить зоны ответственности.

Есть еще «лицо, осуществляющее обработку по поручению оператора»

152-ФЗ предусматривает отдельную конструкцию.

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

Для чистого colocation эта конструкция может вообще не возникать.

Но если поставщик:

• администрирует систему;
• создает резервные копии;
• обслуживает СУБД;
• управляет виртуальной инфраструктурой;
• выполняет операции с данными;

вопрос становится значительно сложнее.

Правовой статус должен определяться не названием услуги и не словом «ЦОД» на сайте компании, а фактически выполняемыми операциями.

«ЦОД соответствует УЗ-1» — тоже требует осторожности в формулировках

На рынке можно встретить предложения инфраструктуры «для УЗ-1», «для УЗ-2» и т. п.

Но юридически уровень защищенности устанавливается не абстрактному зданию дата-центра, а персональным данным при их обработке в конкретной информационной системе в соответствии с постановлением № 1119.

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

Но это не означает автоматического соответствия всей ИСПДн заказчика.

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

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

И договор здесь иногда важнее красивого сертификата на сайте

Перед размещением ИСПДн в стороннем ЦОД необходимо читать не только рекламную страницу поставщика, но и договор, техническое приложение и SLA.

В них критично определить хотя бы:

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

Одного слова «ЦОД» для распределения рисков совершенно недостаточно.

А что с той самой «правоприменительной практикой»?

Вот здесь новость вызывает у меня еще больше вопросов.

Публикации утверждают, что действующая практика позволяет привлекать владельцев ЦОД к ответственности за клиентские утечки.

Но конкретных судебных дел при этом не приводится.

Я попробовал посмотреть открытую судебную практику.

Например, дело № А53-30936/2023 действительно касается коммерческой услуги виртуального ЦОД «Ростелекома». Но спор там вообще не о персональных данных — «Ростелеком» взыскивал задолженность с Ростовского медицинского информационно-аналитического центра. Зато из дела видно другое: услуги ЦОД могут представлять собой единую комплексную услугу без разделения отдельных составляющих.

Дело № 2-2734/2020 относится к монтажу системы кондиционирования в помещении ЦОД и к персональным данным отношения практически не имеет.

Еще одно найденное решение, где встречается аббревиатура «ЦОД», оказалось уголовным делом о неправомерном обороте средств платежей, а упоминание относится к Межрегиональной инспекции ФНС России по централизованной обработке данных.

Есть судебные дела, где ЦОД действительно обрабатывает персональные данные, но это собственный технологический комплекс самого оператора. Например, в деле № А60-40568/2018 суд описывал ЦОД организации как единый инженерный комплекс, предназначенный в том числе для сбора, хранения, систематизации и обработки ПДн потребителей коммунальных услуг. Но это опять совершенно другая конструкция: организация сама владела ЦОД и сама обрабатывала данные.

Публичного показательного кейса, где независимого pure-colocation-провайдера, не имеющего доступа к клиентской ИСПДн, привлекли именно за утечку клиентских ПДн по ст. 13.11 КоАП, мне обнаружить пока не удалось.

Это не означает, что такой практики не существует вообще.

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

Кстати, со штрафами в новости тоже есть проблема

В ряде перепечаток утверждается, что за первую утечку ЦОД якобы может получить штраф до 500 млн рублей, а за повторную — до 3% выручки.

Это некорректное описание действующей статьи 13.11 КоАП.

Для первичной массовой утечки установлены фиксированные диапазоны.

Например:

• 1 000-10 000 субъектов — для юрлица 3-5 млн рублей;
• 10 000-100 000 субъектов — 5-10 млн;
• более 100 000 субъектов — 10-15 млн;
• специальные категории ПДн — 10-15 млн;
• биометрические ПДн — 15-20 млн.

А вот при повторной утечке применяется оборотный штраф 1-3% годовой выручки, не менее 20 млн и не более 500 млн рублей.

То есть журналистские пересказы здесь, похоже, поменяли местами условия применения санкций.

Тогда что действительно стоило бы изменить?

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

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

Это полезно закрепить.

Но одновременно должно быть прямо понятно, что такая норма:

не освобождает ЦОД от ответственности за собственную область эксплуатации.

Если причиной инцидента стали:

• нарушение физического доступа;
• действия сотрудника ЦОД;
• вмешательство в кабельную инфраструктуру;
• неправильная работа инженерных систем;
• нарушение условий SLA;
• неправомерное администрирование;
• невыполнение принятых обязательств по резервированию или защите;

сам факт отсутствия у организации статуса оператора ПДн не должен превращаться в универсальный иммунитет.

И тем более правило не должно одинаково распространяться на colocation, IaaS, PaaS, managed hosting и SaaS.

Вместо «кто виноват?» лучше задавать шесть вопросов

При расследовании инцидента в стороннем ЦОД я бы начинал не с названия организации, а с другого:

1. Кто является оператором персональных данных?
2. Есть ли обработка ПДн по поручению оператора?
3. Какие операции фактически выполняет поставщик?
4. Где проходит техническая граница ответственности?
5. Что предусмотрено договором и SLA?
6. Какая конкретно причина привела к компрометации — прикладная система клиента, действия администратора, гипервизор, СХД, сеть, физический доступ, питание или другой компонент?

После этого ответственность становится значительно понятнее.