Защита персональных данных при использовании SaaS: ответственность и технические меры

• SaaS меняет модель контроля
• Кто отвечает за обработку ПДн?
• Локализация данных
• Оценка поставщика
• Технические меры защиты
• Организационные процедуры
• Требования к уровню защищенности
• Инциденты безопасности
• Удаление и возврат данных
• Модель постоянного контроля

SaaS сервисы позволяют использовать корпоративные приложения без самостоятельного развертывания серверов, обновления программного обеспечения и администрирования всей инфраструктуры. Компания подключает готовую платформу и получает доступ к ней через веб интерфейс или API. Такой подход сокращает сроки запуска ИТ решений, но одновременно переносит часть рисков за пределы корпоративной сети.

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

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

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

SaaS меняет модель контроля

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

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



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

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

Кто отвечает за обработку ПДн?

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

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



Статья 6 Федерального закона № 152 ФЗ допускает передачу обработки другому лицу на основании договора или иного документа. В поручении необходимо определить перечень персональных данных, операции с ними, цели обработки, требования к конфиденциальности и меры безопасности.

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

В договоре или отдельном поручении следует закрепить:

- цели и правовые основания обработки;

- категории субъектов и состав персональных данных;

- допустимые операции;

- территорию обработки;

- перечень субподрядчиков;

- требования к аутентификации и журналированию;

- порядок резервного копирования;

- сроки уведомления об инцидентах;

- правила возврата и удаления данных;

- право заказчика проводить проверки.

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

Локализация данных

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

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

До подключения сервиса необходимо запросить у поставщика:

- адреса и страны размещения дата центров;

- местоположение резервных площадок;

- маршруты передачи данных;

- перечень внешних подрядчиков;

- порядок доступа сотрудников поддержки;

- используемые инструменты мониторинга;

- правила хранения резервных копий;

- механизм удаления данных после завершения договора.

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

Оценка поставщика

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

Проверка включает четыре основных направления:

Правовая модель

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

Инфраструктура

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

Контроль доступа

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

Инциденты

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

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

Технические меры защиты

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

Управление идентификацией

Для корпоративных SaaS сервисов предпочтительна федерация идентификации через SAML 2.0 или OpenID Connect. Пользователь проходит аутентификацию в корпоративном провайдере идентификации, а сервис получает подтверждение личности и набора атрибутов.

Автоматическое управление жизненным циклом учетных записей целесообразно реализовать через SCIM 2.0. При увольнении сотрудника или изменении его должности система может автоматически отозвать доступ или изменить роль.

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

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

Разграничение доступа

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

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

Критичные действия следует защищать дополнительными условиями:

- повторной аутентификацией;

- согласованием операции;

- ограничением по IP адресу или VPN;

- запретом массового экспорта;

- временным повышением привилегий;

- обязательным журналированием.

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

Защита API

Интеграции через API необходимо рассматривать как отдельные точки доступа к персональным данным. Для них следует использовать OAuth 2.0 с короткоживущими access token, ограниченными scopes и контролируемым сроком действия.

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

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

API шлюз должен обеспечивать:

- проверку токенов;

- ограничение частоты запросов;

- контроль размера выгрузок;

- фильтрацию опасных параметров;

- регистрацию вызовов;

- блокирование подозрительной активности.

Шифрование

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

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

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

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

Журналирование

Сервис должен фиксировать:

- успешные и неуспешные входы;

- изменения ролей и политик;

- создание и удаление учетных записей;

- просмотр и изменение персональных данных;

- массовые выгрузки;

- действия администраторов;

- обращения к API;

- изменения настроек интеграций.

Журналы следует передавать в централизованную систему мониторинга, например SIEM. Для защиты от подмены применяются разграничение прав, контроль целостности, отдельное хранилище и ограничение доступа администраторов приложения.

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

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

Резервное копирование

Резервные копии должны быть защищены теми же или более строгими мерами, что и продуктивные данные. Необходимо определить:

- периодичность копирования;

- сроки хранения;

- место размещения;

- схему шифрования;

- порядок контроля целостности;

- перечень ответственных;

- процедуру восстановления.

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

Сегментация

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

Доступ администраторов к панели управления следует ограничивать через выделенный сегмент, VPN или защищенный шлюз. Прямой доступ из открытого интернета увеличивает площадь атаки.

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

Организационные процедуры

Технические средства не заменяют внутренние документы. Статья 18.1 Федерального закона № 152 ФЗ предусматривает принятие необходимых и достаточных мер, включая назначение ответственного, разработку политики и локальных актов, а также применение организационных и технических мер.



До подключения SaaS сервиса рекомендуется актуализировать следующие нормативные документы в компании:

- политику обработки персональных данных;

- перечень целей и категорий обработки;

- модель угроз или документ оценки рисков;

- правила предоставления доступа;

- порядок реагирования на инциденты;

- регламент взаимодействия с провайдером;

- процедуру удаления данных;

- порядок внутреннего контроля.

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

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

Требования к уровню защищенности

Для информационных систем персональных данных пунктом 8 Требований к защите персональных данных при их обработке в информационных системах персональных данных, утвержденных постановлением Правительства РФ от 1 ноября 2012 года № 1119, установлены четыре уровня защищенности: первый, второй, третий и четвертый. Необходимый уровень определяется с учетом категории обрабатываемых персональных данных, типа актуальных угроз, особенностей информационной системы и количества субъектов персональных данных, а состав соответствующих организационных и технических мер устанавливается приказом ФСТЭК России от 18 февраля 2013 года № 21.

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

Перед определением требований необходимо установить:

- состав данных;

- категории субъектов;

- количество субъектов;

- выполняемые операции;

- актуальные угрозы;

- используемые компоненты;

- зоны ответственности провайдера;

- компенсирующие меры заказчика.

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

Инциденты безопасности

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

Провайдер должен сообщать:

- время обнаружения;

- затронутые системы;

- категории возможных данных;

- предполагаемый способ атаки;

- принятые меры;

- рекомендации заказчику;

- контакт ответственного специалиста.

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

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

Удаление и возврат данных

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

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

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

Модель постоянного контроля

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

Работу с SaaS сервисом следует организовать в несколько последовательных этапов:

1. определить цели, категории данных и основания обработки;

2. классифицировать сервис и оценить угрозы;

3. проверить инфраструктуру и договорные условия;

4. настроить идентификацию, доступ и журналирование;

5. провести приемочное тестирование;

6. регулярно пересматривать права пользователей;

7. контролировать изменения и инциденты;

8. ежегодно обновлять оценку рисков;

9. проверять резервное восстановление;

10. поддерживать процедуру возврата и уничтожения данных.

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