Защита персональных данных ФЗ 152: облачные решения против локальных серверов

Защита персональных данных ФЗ-152: облачные решения против локальных серверов

18 ФЗ-152 задаёт место размещения первичной базы, но само по себе не отвечает на вопрос, где именно её безопаснее эксплуатировать: на собственных серверах или в облаке.

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

Локализация: где должны находиться базы

Требования 152-ФЗ к хранению данных часто сводят к географии серверов. Это только один слой соответствия. При сборе персональных данных оператор должен использовать базы, находящиеся на территории РФ, для перечисленных в ч. 5 ст. 18 операций. Следовательно, проверять нужно фактическое размещение баз и маршруты обработки, а не адрес юридического лица провайдера или название региона в панели управления.

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

Локальная инфраструктура даёт оператору больше прямого контроля над физическим размещением. Но контроль не возникает автоматически из факта владения сервером. Если резервирование, администрирование или поддержка вынесены подрядчику, часть обработки уже зависит от внешней стороны. Географию таких компонентов также следует учитывать.

При оценке облачного варианта полезно разделить несколько вопросов:

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

Сбор и обработка персональных данных в SaaS требуют такого же внимания к фактическим потокам. У SaaS-провайдера обычно меньше доступных заказчику настроек, чем в IaaS. Это повышает значение договора, описания компонентов сервиса и сведений о местонахождении данных. Общие обещания о безопасности не заменяют конкретного ответа на вопрос, где и кем обрабатываются данные.

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

Облако и локальные серверы: где проходит граница ответственности

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

В PaaS часть задач по эксплуатации платформы переходит провайдеру. В SaaS заказчик обычно управляет ещё меньшим числом технических компонентов, но сохраняет обязанности оператора персональных данных: он определяет цели и состав обработки, регулирует доступ пользователей и следит за тем, какие сведения передаются сервису. Точная граница зависит от услуги и закреплённых условий.

Облако передаёт провайдеру часть технических функций. Обязанности оператора по обработке персональных данных оно не отменяет.

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

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

Технические меры: требования задают не марку инфраструктуры

Организационные и технические меры защиты персональных данных в информационных системах регулируются Постановлением Правительства РФ № 1119 и Приказом ФСТЭК России № 21. Постановление предусматривает четыре уровня защищённости: УЗ-1, УЗ-2, УЗ-3 и УЗ-4. Выбор уровня связан с характеристиками системы и обрабатываемых данных. По одному лишь факту размещения в облаке или на собственном сервере уровень определить нельзя.

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

Удобно рассматривать контур по слоям:

1. Инфраструктура. Для локальной системы это серверы, сеть и площадка. Для облачной — компоненты услуги, за которые отвечает провайдер, и параметры виртуального контура, доступные заказчику.

2. Операционные системы и приложения. В IaaS конфигурация гостевой ОС и прикладного ПО находится в зоне заказчика. Необновлённая система или приложение с лишними правами создают риск независимо от защищённости дата-центра.

3. Идентификация и доступ. Права пользователей и администраторов должны соответствовать их рабочим задачам. Учётные записи подрядчиков тоже входят в эту модель.

4. Сеть и обмен данными. Следует понимать, какие сервисы взаимодействуют с базой и через какие интерфейсы. Для мобильных приложений это включает серверную часть, API и обработку данных на устройстве.

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

Для мобильного приложения зона анализа не заканчивается смартфоном. Персональные данные могут проходить через клиент, API-шлюз, прикладной сервис, аналитический компонент и базу. Если часть цепочки работает в облаке, нужно сопоставить её с условиями поручения на обработку и принятой моделью разделения ответственности. Отдельного внимания требуют телеметрия и журналы: они могут содержать идентификаторы, сведения об ошибках или другие данные, позволяющие связать события с пользователем.

В облаке стоит отдельно документировать границу между ресурсами провайдера и конфигурацией заказчика. В локальной среде нужна столь же точная фиксация границ между внутренней IT-командой и подрядчиками. Без этого при инциденте трудно установить, на каком уровне возникла ошибка: в инфраструктуре, сетевых правилах, приложении или управлении доступом.

Где возникают сбои соответствия

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

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

Типовые зоны разрыва выглядят так:

• Размытая модель ответственности. Участники проекта не закрепили, кто обновляет ОС, приложения и компоненты защиты. В IaaS это особенно критично: провайдер обслуживает нижний инфраструктурный слой, а гостевая система остаётся в управлении заказчика.
• Неполная карта данных. Основную базу учли, а резервные копии, журналы или сервисные данные оставили за пределами анализа.
• Избыточные полномочия. Администраторский доступ сохраняется у сотрудников и подрядчиков, которым он больше не нужен.
• Смешение функций. Одна и та же учётная запись используется для обычной работы и привилегированных операций. В результате журналы хуже помогают установить, кто и что сделал.
• Несовпадение документов и конфигурации. Внутренние процедуры описывают один порядок обработки, а фактические интеграции и настройки приложения работают по другому.

Это не отдельные «облачные» или «локальные» уязвимости. Такие дефекты встречаются в обеих архитектурах. Разница в том, кто контролирует соответствующий уровень и насколько быстро оператор способен получить достоверные сведения о его состоянии.

Статья 13.11 КоАП РФ и цена нарушения

Нарушения требований к локализации и правил обработки персональных данных могут повлечь административную ответственность по ст. 13.11 КоАП РФ. Конкретный состав нарушения и последствия зависят от обстоятельств. Поэтому нельзя оценивать риск только по наличию договора с облачным провайдером или по тому, что сервер стоит в российском дата-центре.

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

Выбор платформы не позволяет передать ответственность за соблюдение 152-ФЗ подрядчику целиком. Провайдер может отвечать за свой инфраструктурный слой и выполнять порученную обработку, но оператор остаётся стороной, которая организует обработку и должна контролировать её условия. Эта логика одинаково применима к IaaS, PaaS и собственным серверам с внешним администрированием.

Как выбрать архитектуру

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

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

Облачный вариант может быть рациональным, если провайдер подтверждает расположение требуемых компонентов в России, условия поручения оформлены, а заказчик способен администрировать свои системы и виртуальный контур. Для PaaS и SaaS особенно важно заранее установить, какие технические сведения и настройки доступны заказчику. Если сервис не раскрывает нужные параметры, оператору сложнее подтвердить, как именно устроена обработка.

Перед выбором имеет смысл зафиксировать:

• категории персональных данных и операции, выполняемые с ними;
• местонахождение основных баз, резервных копий и компонентов обработки;
• модель ответственности по каждому техническому слою;
• правила управления пользовательскими и административными доступами;
• порядок контроля настроек и действий при изменении сервиса;
• связь между архитектурой системы, требованиями № 1119 и мерами по Приказу ФСТЭК № 21.

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

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