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

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

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

Разделение ответственности: почему SaaS-провайдер не берёт на себя все риски

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

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

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

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

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

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

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

Правовой ландшафт: от 152-ФЗ до GDPR и уведомлений об утечках

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

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

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

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

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

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

• какие категории персональных данных поступают в SaaS;
• для каких целей их используют и кто определяет эти цели;
• где находятся основные данные и резервные копии;
• какие подрядчики и интеграции получают к ним доступ;
• кто и в какой последовательности реагирует на нарушение;
• какие договорные и организационные меры применяются к каждому участнику.

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

Стандарты доверия: роль SOC 2 и ISO 27001

Отчёты и сертификаты помогают оценить зрелость провайдера, но показывают разные вещи. SOC 2 основан на критериях доверия AICPA. В отчёте Type I оценивается устройство контролей на определённый момент, а Type II рассматривает их работу за период. Условия и охват конкретного отчёта нужно читать отдельно: они могут относиться не ко всем продуктам провайдера и не ко всем его площадкам.

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

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

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

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

Технический контроль: SSPM для мониторинга конфигураций

SSPM, или SaaS Security Posture Management, помогает выявлять небезопасные настройки в корпоративных SaaS-приложениях. Такие инструменты подключаются к сервисам через доступные интерфейсы и проверяют параметры аккаунтов по заданным политикам. В зависимости от продукта они могут обнаруживать открытый внешний доступ к файлам, слабые настройки аутентификации, чрезмерные разрешения интеграций и отключённое журналирование.

Важно заранее уточнить, что именно может читать подключённый SSPM. Доступ через API обычно требует административных разрешений, а значит, сам инструмент становится частью периметра безопасности. Его токены нужно хранить и ротировать, права ограничивать, а действия интеграции включать в мониторинг. Нельзя считать SSPM безопасным только потому, что он предназначен для защиты SaaS.

На практике полезно начать с наиболее значимых настроек:

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

2. Многофакторная аутентификация. Проверяется не только наличие MFA, но и охват привилегированных ролей, аварийных учётных записей и способов восстановления доступа. Если администраторы используют усиленную защиту, а для восстановления аккаунта достаточно слабого канала, защита остаётся неполной.

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

4. OAuth-приложения и токены. Интеграциям следует выдавать только необходимые разрешения. Неиспользуемые подключения и токены нужно отзывать по принятой процедуре, а новые приложения согласовывать с владельцами данных и ИТ-службой.

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

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

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

Уровни защищённости по Постановлению № 1119: классификация угроз

Постановление Правительства РФ № 1119 устанавливает требования к защите персональных данных в информационных системах и связывает набор мер с уровнем защищённости. Классификация учитывает предусмотренные постановлением условия, в том числе тип актуальных угроз, категории и количество субъектов, а также особенности системы. Поэтому её нельзя надёжно свести к правилу вроде «есть интернет, значит такой-то уровень» или назначить по одной характеристике SaaS.

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

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

Уровень защищённости нельзя назначить только по числу пользователей или наличию подключения к интернету. Также неверно автоматически считать, что любая SaaS-система обязана проходить аттестацию по требованиям ФСТЭК. Необходимые меры и процедуры определяются применимыми нормами для конкретного типа системы и организации. Аттестация, оценка соответствия и внутреннее подтверждение выполнения требований не взаимозаменяемы; применимость каждой процедуры нужно устанавливать отдельно.

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

Что остаётся за периметром провайдера

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

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

Внутренние правила обычно охватывают:

• назначение владельца каждому SaaS и порядок согласования новых приложений;
• минимальные права пользователей и отдельный контроль привилегированных ролей;
• MFA, управление аварийными аккаунтами и отзыв доступа при увольнении или смене роли;
• сроки хранения, экспорта и удаления данных;
• проверку OAuth-приложений, токенов и сторонних интеграций;
• журналирование, передачу значимых событий в SIEM и сроки хранения журналов;
• порядок сообщения об инцидентах внутри компании и обмена сведениями с провайдером.

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

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