Безопасность персональных данных в облаке — один из главных источников юридических иллюзий для основателей и руководителей IT-компаний. Перенося базы данных клиентов, CRM или бэкенд SaaS-сервиса на виртуальный сервер стороннего хостинга или в облачную инфраструктуру, бизнес часто довольствуется формальным заверением менеджера: «У нас все надежно, ЦОД уровня Tier III, сертификаты есть».
Однако в российской правоприменительной практике слова и маркетинговые шильдики не имеют юридической силы. Роскомнадзор и ФСТЭК России при проверках или расследовании инцидентов утечки оперируют исключительно документальными доказательствами. Если сервер будет взломан или данные окажутся в открытом доступе, перед законом отвечать будет не хостинг, а ваша компания.
Юридическая ловушка: почему перед законом отвечает бизнес, а не хостинг
В соответствии с частью 3 статьи 6 Федерального закона № 152-ФЗ «О персональных данных», оператор вправе поручить обработку персональных данных другому лицу с согласия субъектов. При этом закон устанавливает жесткую презумпцию: ответственность перед субъектом персональных данных за действия указанного лица несет оператор. Провайдер отвечает только перед оператором в рамках заключенного между ними договора.
Если в инфраструктуре хостинга происходит инцидент, Роскомнадзор привлекает к ответственности компанию-оператора. Ссылка на то, что «виноват дата-центр», не освобождает от оборотных штрафов и блокировок.
| Фактор риска | Нормативная база | Правовые и финансовые последствия |
|---|---|---|
| Передача данных хостингу без юридического поручения | ч. 3 ст. 6 152-ФЗ, ст. 13.11 КоАП РФ | Квалификация как незаконная передача (распространение) третьим лицам; штрафы до 300 000 – 500 000 ₽ |
| Отсутствие подтверждения уровня защищенности (УЗ) | ст. 19 152-ФЗ, Постановление Правительства № 1119 | Предписание ФСТЭК / РКН о несоблюдении организационно-технических мер; приостановление эксплуатации ИСПДн |
| Утечка данных из арендованного контура | КоАП РФ (законопроект об оборотных штрафах) | Штрафы до десятков миллионов рублей либо до 3% совокупной выручки компании |
Золотое трио доказательств: что признают РКН и ФСТЭК
В случае проверки инспекторы не будут читать коммерческие буклеты хостинга. Доказательством реальной защищенности является одновременное совпадение трех обязательных элементов:
1. Аттестат соответствия или Акт оценки эффективности мер защиты
Сертификат надежности дата-центра (Tier II, Tier III) подтверждает бесперебойность питания и кондиционирования серверов, но не имеет отношения к требованиям безопасности информации. Единственным легитимным подтверждением является:
- Аттестат соответствия требованиям безопасности информации по требованиям ФСТЭК России для установленного уровня защищенности (УЗ-1, УЗ-2, УЗ-3 или УЗ-4);
- Либо Акт оценки эффективности принимаемых мер по обеспечению безопасности ПДн (в соответствии с Приказом ФСТЭК России № 21), выданный лицензиатом ФСТЭК.
Этот документ подтверждает, что средства защиты (СЗИ) физически установлены, настроены, протестированы и аттестованы независимой лабораторией.
2. Юридически выверенное Поручение на обработку ПДн (DPA)
Провайдер не может быть просто «поставщиком вычислительных мощностей». Передавая ему данные, вы обязаны заключить соглашение о поручении обработки (в виде отдельного договора или раздела в договоре аренды инфраструктуры). В поручении строго обязательно должны быть прописаны:
- Исчерпывающий перечень действий (операций) с данными;
- Конкретный перечень организационных и технических мер по ст. 19 152-ФЗ;
- Обязанность соблюдать конфиденциальность и локализацию баз данных на территории РФ;
- Обязанность провайдера содействовать при реагировании на инциденты и запросы регулятора.
3. Модель угроз безопасности информации провайдера (МУБИ)
Это ключевой технический документ, о необходимости которого часто не знают даже штатные юристы. Согласно законодательству РФ, каждый оператор обязан разработать собственную Модель угроз безопасности персональных данных для своей информационной системы.
Когда вы размещаете данные в облаке, вы используете модель разделенной ответственности (Shared Responsibility Model): за физический сервер и гипервизор отвечает провайдер, а за гостевую ОС, базу данных и программный код — вы. Вы физически не можете разработать собственную модель угроз без учета модели угроз провайдера. Вам необходима выписка из его модели угроз, описывающая актуальные угрозы на уровне среды виртуализации и каналов связи ЦОД.
Маркеры скрытых рисков: когда нужно насторожиться
Когда сходятся все три пункта (действующий аттестат или акт оценки, официальное поручение и модель угроз), контур правовой безопасности закрыт. Если провайдер сопротивляется хотя бы по одному из пунктов — например, отказывается подписывать поручение или заявляет, что модель угроз — это «внутренняя коммерческая тайна», — это прямой сигнал о том, что у инфраструктуры есть критические уязвимости, за которые провайдер не хочет нести юридическую ответственность.
Для проектов со сложной архитектурой и распределенными базами данных (как в кейсах платформы DBG360 или инвестиционных структур IntInvestCorp) аудит облачного контура проводится до начала развертывания рабочих баз.
Legal Design & Dev-чеклист: как проверить облако перед миграцией
Инструкция для совместной работы технического директора (CTO) и юридического отдела:
- Шаг 1. Запрос лицензий и аттестатов: Запросите у провайдера копию действующего Аттестата соответствия ИСПДн требованиям безопасности информации (или Акт оценки эффективности по Приказу ФСТЭК № 21). Проверьте дату окончания срока действия аттестата.
- Шаг 2. Разграничение зон ответственности (RACI Matrix): Зафиксируйте в SLA, кто отвечает за резервное копирование, сегментацию виртуальных сетей, обновление патчей безопасности гипервизора и управление криптографическими ключами.
- Шаг 3. Интеграция модели угроз: Получите от провайдера выписку из его Модели угроз (описание нейтрализованных угроз на уровне дата-центра) и включите эти параметры в качестве внешних вводных в собственную Модель угроз ИСПДн компании.
- Шаг 4. Включение раздела о поручении обработки: Убедитесь, что договор или оферта провайдера содержит все 5 обязательных пунктов части 3 статьи 6 152-ФЗ. Если провайдер предлагает стандартную оферту без этих пунктов — требуйте подписания индивидуального допсоглашения.
- Шаг 5. Мониторинг интерфейсов и согласий: Убедитесь, что в публичной оферте и политике конфиденциальности вашего сервиса провайдер указан в качестве третьего лица, которому поручена обработка, в рамках комплексного IT-комплаенса 152-ФЗ.
Резюме и экспресс-диагностика
Защита персональных данных в облаке подтверждается не маркетинговыми обещаниями, а тремя строгими документами: аттестатом ФСТЭК, юридическим поручением и моделью угроз. Отсутствие любого из них перекладывает 100% административных и оборотных рисков на вашу компанию.
Проверьте, насколько ваш сайт и формы сбора данных защищены от претензий Роскомнадзора, с помощью нашего бесплатного сканера сайта 152-ФЗ. Для мгновенной экспресс-диагностики рисков запустите специализированного ИИ-ассистента бюро в Telegram: @verislegal_bot. Если вам необходим аудит облачной инфраструктуры или подготовка юридически защищенного поручения обработки данных, свяжитесь с бюро напрямую: @verislegal.
