Хранение персональных данных в облачной инфраструктуре давно превратилось из инновационной модели в типовое технологическое решение. Бизнес идёт в облако ради эластичности и экономии, а нормативное регулирование при этом продолжает усложняться. На стыке этих двух тенденций возникает реальная задача: построить такую конфигурацию облачного сервиса, которая обеспечивает соблюдение российских правил о персональных данных, защищает интересы оператора и пользователей и при этом сохраняет преимущества облачной модели — масштабируемость, отказоустойчивость, скорость развёртывания.
Настоящая статья даёт системный обзор правового режима хранения персональных данных в облаке: участники, основания обработки, требования к мерам защиты, локализация и трансграничная передача, ответственность за нарушения, рекомендации по построению облачной архитектуры и стандартные ошибки. Завершают материал ответы на наиболее частые вопросы. Тематический фокус — российское регулирование персональных данных применительно к облачным услугам в моделях IaaS, PaaS и SaaS.
Правовое регулирование
Базовый правовой акт — Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных» (далее — Закон № 152-ФЗ). Он устанавливает понятийный аппарат, перечень оснований обработки, обязанности оператора, требования к защите и санкции. Закон гарантирует особый статус оператора и обработчика и устанавливает ответственность оператора перед субъектом за все действия обработчика.
Ключевые требования к мерам защиты подробно раскрыты в Постановление Правительства РФ от 01.11.2012 № 1119 и в подзаконных актах регуляторов. Технические меры защиты в части использования сертифицированных средств защиты информации формализованы приказ ФСТЭК России от 18.02.2013 № 21, а вопросы криптографической защиты персональных данных, в том числе при хранении и передаче, — приказ ФСБ России от 10.07.2014 № 378.
Существенное значение для информационных систем имеет Федеральный закон от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации» и связанные с ним приказы Минцифры России. Системно к облачной модели применяются и нормы части первой Гражданского кодекса Российской Федерации о договоре возмездного оказания услуг, об ответственности за нарушение обязательств, а также положения главы 38 ГК РФ при квалификации технологических разработок и заказных модификаций.
Ключевые понятия и квалификация
Облачные модели — IaaS, PaaS и SaaS — отличаются распределением ответственности между провайдером и заказчиком. В терминологии Закона № 152-ФЗ заказчик облачных услуг, как правило, является оператором: он определяет цели и средства обработки, формирует политики и обеспечивает законные основания обработки персональных данных. Провайдер становится обработчиком, если оператор поручает ему обработку персональных данных по ст. 6 Закона № 152-ФЗ; такое поручение оформляется отдельным договором или приложением к нему.
Поручение обработки персональных данных имеет несколько обязательных элементов: согласие оператора, перечень обрабатываемых персональных данных и операций, цели обработки, обязанности обработчика по обеспечению безопасности и конфиденциальности, оценка соответствия требованиям к защите. Без надлежаще оформленного поручения отношения между оператором и провайдером могут быть квалифицированы как непрозрачные, что повышает риски претензий со стороны Роскомнадзора и субъектов персональных данных.
Облачное хранение не отменяет обязанности оператора по обеспечению уровня защищённости информационных систем персональных данных, установленных Постановление Правительства РФ от 01.11.2012 № 1119. В зависимости от категории субъектов, типа персональных данных, актуальных угроз и числа субъектов оператор определяет один из четырёх уровней защищённости — от первого (наивысшего) до четвёртого. Уровень защищённости определяет набор обязательных мер: организационные политики, средства защиты информации, журналирование, контроль доступа, физическая безопасность объектов, в которых размещена инфраструктура.
Применительно к облачному хранению особое значение имеет принцип «общей ответственности»: некоторые меры защиты (физическая безопасность дата-центров, базовая защита от инфраструктурных угроз) обеспечиваются провайдером, тогда как иные меры (политики доступа, классификация данных, инструменты шифрования прикладного уровня) лежат на операторе. В правильной модели эти зоны прямо описаны в договорной документации и в технических регламентах, что облегчает и эксплуатацию, и общение с регулятором.
Локализация и трансграничная передача
Обязанность по локализации обработки персональных данных российских граждан закреплена в ч. 5 ст. 18 Закона № 152-ФЗ: запись, систематизация, накопление, хранение, уточнение и извлечение должны выполняться с использованием баз данных, расположенных на территории Российской Федерации. В облачной модели это означает, что провайдер должен предоставлять оператору ресурсы, размещённые в российских центрах обработки данных, и что архитектура должна исключать первичную запись или существенное обновление данных российских граждан в иностранных регионах облака.
Закон допускает использование иностранной инфраструктуры для операций, не относящихся к шести «локализуемым»: например, аналитика на де-идентифицированных выборках, машинное обучение, тестирование. При проектировании потоков данных оператор должен явно отделить «первичные» базы от вспомогательных и убедиться, что любые передачи данных за рубеж имеют правовое основание (включая адекватность защиты, согласие субъекта, договорные гарантии и иные основания, предусмотренные Законом № 152-ФЗ).
С 1 марта 2023 года Закон № 152-ФЗ устанавливает специальный режим трансграничной передачи: оператор обязан подать в Роскомнадзор уведомление о намерении осуществлять трансграничную передачу персональных данных и при необходимости ожидать решения регулятора. Это требование значительно повлияло на архитектуры мультиоблачных решений: для глобальных компаний задача состоит не только в технической локализации, но и в правильной маршрутизации потоков на этапах, когда данные покидают территорию России.
Меры защиты при хранении в облаке
Меры защиты должны обеспечивать конфиденциальность, целостность и доступность персональных данных. В состав обязательных мер для облачного хранения, как правило, входят сертифицированные средства защиты информации, реализующие требования приказ ФСТЭК России от 18.02.2013 № 21, и криптографические средства, соответствующие приказ ФСБ России от 10.07.2014 № 378. Конкретный состав определяется уровнем защищённости информационной системы персональных данных и моделью угроз.
Шифрование данных при хранении — стандартная и в большинстве случаев обязательная мера. В облачных сервисах применяются механизмы шифрования на уровне диска (Server-Side Encryption), на уровне сервиса хранения, на уровне базы данных и на прикладном уровне (Client-Side Encryption). Для российской регуляторики важна не только сама криптография, но и тип использованных алгоритмов: при защите персональных данных в требуемых случаях должны применяться сертифицированные ФСБ России криптосредства, реализующие отечественные алгоритмы (ГОСТ Р 34.10, ГОСТ Р 34.12 и др.). Управление ключами шифрования — отдельный, нетривиальный домен: оператор обязан исключить ситуации, когда провайдер фактически получает неограниченный доступ к открытому тексту персональных данных в случаях, для которых это не предусмотрено поручением.
Журналирование и контроль доступа должны охватывать все ключевые операции: создание учётных записей, изменение прав, доступ к персональным данным, перенос данных между сервисами, операции резервного копирования и восстановления. Журналы должны храниться достаточно длительный срок (обычно не менее трёх лет, а для финансовых организаций — дольше) и быть защищены от несанкционированного изменения. Особое значение имеет реагирование на инциденты: оператор должен иметь регламент уведомлений (внутренних и внешних — в адрес Роскомнадзора и при необходимости субъектов персональных данных), а провайдер — обеспечивать своевременную передачу технических сведений об инциденте.
Типовые ситуации и риски
Первая типовая ситуация — использование российского провайдера для всей цепочки обработки. В такой конструкции наибольшее внимание уделяется правильному оформлению поручения, согласованию мер защиты, аудиту провайдера и формализации процедур взаимодействия по инцидентам. Технологические риски сосредоточены вокруг управления ключами шифрования, ограничения доступа подрядчиков провайдера, мониторинга прав привилегированных пользователей.
Вторая типовая ситуация — использование иностранного провайдера для отдельных функций. Здесь критичны два момента: соответствие требованиям локализации (первичные записи и хранение российских граждан — на российской инфраструктуре) и надлежащее оформление трансграничной передачи. Несоблюдение приводит к административной ответственности и потенциальной блокировке ресурсов оператора. Для глобальных компаний рабочей моделью становится «двойной слой»: российская часть — на российских мощностях; глобальная аналитическая часть — за рубежом, при условии корректной де-идентификации и оформления передачи.
Третья типовая ситуация — гибридная архитектура с собственной инфраструктурой и облачными сервисами. Такая модель удобна для крупных операторов, но требует тщательной классификации систем по уровням защищённости, согласованной модели угроз и формального описания границ ответственности. На практике именно здесь чаще всего возникают «слепые зоны»: данные, перемещаемые между внутренними и облачными системами, оказываются вне периметра защиты или регулируются неполно.
Особый риск представляют резервные копии. Восстановление из резервных копий, размещённых в облаке, способно вернуть «локализованные» персональные данные в иностранную инфраструктуру, если не предусмотрены отдельные регламенты. Аналогичный риск возникает при использовании облачных систем мониторинга, аналитики и логирования, которые могут собирать персональные данные из приложений и передавать их в иностранную зону.
Судебная практика и позиции Верховного Суда РФ
Применительно к хранению персональных данных в облаке судебная практика концентрируется на двух блоках споров. Первый — обжалование актов Роскомнадзора, в том числе предписаний, штрафов и решений об ограничении доступа. Второй — гражданские дела между субъектами персональных данных и операторами, а также между операторами и провайдерами облачных сервисов.
Верховный Суд РФ системно подчёркивает необходимость защиты прав субъектов и применения принципа разумности при оценке мер, принимаемых операторами. В частности, суды строго оценивают доказательственную базу оператора: при отсутствии задокументированной модели угроз, моделей нарушителя, журналов и доказательств реализации мер защиты позиция оператора оказывается слабой даже при формально корректной договорной структуре.
В корпоративных спорах между операторами и провайдерами наиболее болезненный вопрос — пределы ответственности провайдера. Распространены ограничения ответственности, существенно сужающие размер возмещения; их применимость анализируется судами с учётом существа договорных обязательств и наличия признаков злоупотребления (умысла, грубой неосторожности). Поэтому при заключении договоров с провайдером операторам важно балансировать коммерческие условия с уровнем фактических рисков обработки персональных данных.
Практические рекомендации
Базовый набор практических действий укладывается в несколько последовательных шагов. Сначала проводится инвентаризация обработки персональных данных, формируется реестр информационных систем и идентифицируются те из них, которые планируется размещать в облаке. Затем определяется применимый уровень защищённости по Постановление Правительства РФ от 01.11.2012 № 1119, разрабатывается модель угроз, формируется перечень мер защиты, выбирается провайдер, проводится его аудит на соответствие требованиям регуляторов. Параллельно готовится комплект внутренних документов: политика обработки персональных данных, регламент работы с инцидентами, инструкции для пользователей, регламент управления доступом, регламент управления ключами шифрования.
Договорный пакет с провайдером должен включать: соглашение о поручении обработки персональных данных (с обязательным составом, указанным в ст. 6 Закона № 152-ФЗ), описание мер защиты, гарантии локализации, регламенты уведомлений об инцидентах, права аудита и проверки соответствия, ответственность сторон, условия по подрядчикам провайдера и иные положения. Если провайдер привлекает субподрядчиков (включая в составе глобальных групп), отдельным условием регулируются их статус, права и обязанности.
Регулярные аудиты и тесты — необходимый элемент. Рекомендуется проводить внутренние оценки соответствия не реже одного раза в год, а при существенных изменениях архитектуры — внеплановые проверки. Параллельно следует тестировать сценарии инцидентов и восстановления, отдельно проверяя факты возврата данных в требуемые юрисдикции после восстановления из резервных копий. Программа обучения для сотрудников оператора и обработчика — отдельный обязательный модуль; без неё реализованные технические меры не превращаются в устойчивую практику.
Типичные ошибки
Среди наиболее частых ошибок — отсутствие надлежащего поручения обработки персональных данных провайдеру, использование шаблонных типовых форм без учёта специфики, перекладывание всех мер защиты на провайдера без описания обязательств оператора, отсутствие управления ключами шифрования, недостаточная классификация информационных систем по уровню защищённости. Самостоятельная категория — недостоверные политики обработки, обещающие меры, которые фактически не реализованы; такие документы повышают, а не снижают риски привлечения к ответственности.
Часто встречается также игнорирование требований к журналированию и хранению журналов, что усложняет расследование инцидентов и общение с регулятором. Административные санкции по ст. 13.11 КоАП РФ за совокупность нарушений могут существенно превышать те, что применяются к отдельным правонарушениям, поэтому экономия на превентивных мерах является ложной.
Заключение
Хранение персональных данных в облаке — это не столько технологический выбор, сколько комплексный правовой и операционный проект. Эффективная модель строится на корректной квалификации участников (оператор и обработчик), формализованном поручении обработки персональных данных, реалистичной модели угроз и сбалансированной системе мер защиты, выверенной локализации и юридически безупречной трансграничной передаче. При системном подходе облачная инфраструктура становится конкурентным преимуществом, а не источником регуляторных рисков.
Вопросы и ответы
1. Можно ли хранить персональные данные в иностранном облаке?
Прямого запрета на использование иностранных облачных сервисов нет, но локализация обработки персональных данных российских граждан обязательна. Это означает, что первичные базы данных должны быть расположены в России, а иностранная инфраструктура может использоваться для операций, не относящихся к «локализуемым», и при условии корректной трансграничной передачи.
2. Что обязательно отразить в договоре с провайдером?
Минимальный перечень условий:
— перечень операций по обработке, поручаемых провайдеру;
— цели и категории персональных данных;
— меры защиты с указанием стандартов и регламентов;
— территория размещения инфраструктуры и подтверждение локализации;
— регламенты уведомления об инцидентах;
— права аудита и доступа к доказательственной базе;
— ответственность сторон, включая ответственность за действия субподрядчиков провайдера.
3. Кто отвечает за инцидент в облаке?
Перед субъектом персональных данных и регулятором отвечает оператор. Между оператором и провайдером ответственность распределяется по договору и общим нормам гражданского права; неполная или неотчётливая регламентация ответственности повышает риск ответственности оператора по умолчанию.
4. Какие меры защиты обязательны при хранении в облаке?
Минимум определяется уровнем защищённости по Постановление Правительства РФ от 01.11.2012 № 1119 и соответствующими требованиями ФСТЭК России и ФСБ России. В типовом случае это организационные политики, контроль доступа и журналирование, антивирусная защита, шифрование при хранении и передаче (включая криптосредства по ГОСТ при необходимости), резервное копирование и план восстановления.
5. Что делать при инциденте?
Действовать по заранее подготовленному регламенту: оперативно фиксировать факты, локализовать угрозу, уведомить Роскомнадзор и при необходимости субъектов персональных данных в установленные сроки, привлечь провайдера к расследованию, сохранить доказательства. После инцидента — провести разбор и обновить процедуры. Чёткая документированная реакция снижает риски претензий и репутационных потерь.
6. Нужна ли согласие на хранение в облаке?
Согласие требуется на обработку персональных данных, в том числе при их хранении, если такая обработка не подпадает под иные основания, перечисленные в Законе № 152-ФЗ (например, исполнение договора, выполнение возложенных функций оператора, законные интересы). Хранение в облаке не создаёт самостоятельного основания, требующего отдельного согласия; согласие, если оно получено для обработки в целом, охватывает и облачную инфраструктуру при условии корректного информирования субъектов.
7. Можно ли использовать иностранные алгоритмы шифрования?
Иностранные алгоритмы шифрования допустимы для общей защиты информации, однако в случаях, когда применяются обязательные меры с использованием криптосредств по приказ ФСБ России от 10.07.2014 № 378, применяются сертифицированные ФСБ России средства, реализующие отечественные алгоритмы. В коммерческой практике распространены гибридные схемы: иностранные алгоритмы для общей защиты, отечественные — там, где это требуется регуляторикой.
8. Как проверить локализацию у провайдера?
Локализация подтверждается комплексом источников: документами провайдера о размещении инфраструктуры (сертификаты, паспорта ЦОД), договором с указанием территории размещения, технологическими протоколами и тестами, а также подтверждениями маршрутизации сетевого трафика. При аудитах целесообразно запросить у провайдера развёрнутую техническую схему и подтверждающие документы по операциям сохранения и резервирования.
9. Какие сроки уведомления Роскомнадзора при инциденте?
Сроки и порядок уведомления определяются ст. 19 Закона № 152-ФЗ и подзаконными актами. На практике стандарт — оперативно после установления факта инцидента, в течение нескольких часов (для существенных инцидентов) и не позднее установленного срока для дополнительных сведений. Точные значения регулярно обновляются, поэтому соответствие должно проверяться по актуальной редакции.
10. Можно ли хранить персональные данные в SaaS-сервисах для совместной работы?
Можно — при соблюдении общих требований. Для SaaS-инструментов важно: наличие договорной модели поручения обработки персональных данных, обеспечение мер защиты, контроль трансграничной передачи и локализации, аудит провайдера. SaaS-инструменты с общедоступным размещением данных без должной защиты для обработки персональных данных, особенно специальных категорий, не подходят.
Характеристики
| Право | Россия |
|---|---|
| Отрасль права | Цифровое |
| Юридическая практика | Технологии, медиа, телеком |
| Изложение | Полное |
| Актуальность | Актуально сейчас |