Границы ИСПДн: как определить состав системы и ничего не забыть

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

Что закон называет ИСПДн

По статье 3 Закона №152-ФЗ информационная система персональных данных — совокупность ПДнПерсональные данные — Любая информация, относящаяся к прямо или косвенно определённому физическому лицу (субъекту ПДн). в базах данных, информационных технологий и технических средств, обеспечивающих их обработку. Поэтому ИСПДнИнформационная система персональных данных — Совокупность персональных данных в базах данных и обеспечивающих их обработку информационных технологий и технических средств. нельзя автоматически отождествлять с одной программой, сервером или файлом. CRM может быть центральным приложением, но в состав контура также входят компоненты, через которые данные вводятся, передаются, хранятся, копируются, администрируются или восстанавливаются.

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

С чего начать: не с перечня программ, а с потоков данных

1. Перечислите цели обработки и категории субъектов: работники, кандидаты, клиенты, представители контрагентов, посетители сайта и другие.
2. Для каждой цели проследите путь данных от получения до удаления: источник, ввод, основное хранение, использование, передача, архив, резервирование и уничтожение.
3. Отметьте владельца процесса, пользователей, администраторов и внешних исполнителей.
4. Нанесите на схему приложения, базы, серверы, рабочие места, сети, точки удалённого доступа, интеграции и внешние сервисы.
5. Зафиксируйте доверенные зоны и места, где ответственность переходит к поставщику или иному оператору.

Что обычно забывают включить

• Рабочие места. Браузер, локальный кэш, выгрузки, папка загрузок, временные файлы и буфер обмена могут содержать ПДн даже при полностью облачной CRM.
• Электронную почту и мессенджеры. Заявки, резюме, договоры и выгрузки нередко покидают основную систему через эти каналы.
• Excel и локальные файлы. Это не обязательно самостоятельная ИСПДн, но такие файлы должны быть отнесены к конкретному контуру и защищены.
• Интеграции и API. Веб-формы, телефония, платёжные сервисы, доставка, ЭДО и аналитика получают или передают часть набора данных.
• Журналы и мониторинг. Логи могут содержать ФИО, телефоны, адреса, идентификаторы, IP-адреса и содержимое запросов.
• Резервные копии и архивы. Для них нужны доступ, срок хранения, проверка восстановления и процедура удаления с учётом ротации копий.
• Тестовые и учебные среды. Копирование продуктивной базы в тест без обезличивания создаёт ещё одну точку обработки и часто расширяет круг доступа.
• Удалённый доступ и мобильные устройства. Домашний компьютер, личный телефон и подрядчик с административным доступом меняют модель нарушителя и набор мер.

Одна ИСПДн или несколько

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

Нельзя дробить систему только ради более низкого уровня защищённости, если между частями сохраняются постоянные потоки данных и общее администрирование. Но и объединять всю ИТ-инфраструктуру организации в одну ИСПДн без анализа не всегда полезно: граница должна позволять определить реальные угрозы, ответственность и проверяемые меры. Решение фиксируют и обосновывают.

Как учитывать облако и SaaS

Передача приложения поставщику не передаёт ему статус оператора автоматически и не снимает обязанностей с заказчика. Если поставщик обрабатывает данные по поручению, договор должен соответствовать части 3 статьи 6 Закона №152-ФЗ: определить перечни данных и операций, цели, конфиденциальность, требования статьи 18.1, обязанность принимать меры статьи 19, предоставлять подтверждающие документы, уведомлять об инцидентах и обеспечивать прекращение обработки.

В схеме границ покажите, какие компоненты и меры контролирует оператор, какие — поставщик, а какие требуют совместных действий. Уровень защищённости определяется для ИСПДн в целом; фразы поставщика «ЦОД уровня УЗУровень защищённости персональных данных — Один из четырёх уровней (УЗ-1…УЗ-4) для ИСПДн по постановлению Правительства №1119; определяет состав мер.-3» недостаточно. Нужны проверяемые сведения об архитектуре и мерах, месте размещения баз, субподрядчиках, доступе администраторов, резервировании, выгрузке и уничтожении данных.

Какие документы должны согласоваться между собой

• перечень ИСПДн и технический паспорт каждой системы;
• схема архитектуры, сетевых связей и потоков ПДн;
• перечень компонентов, программ, рабочих мест, пользователей и внешних подключений;
• акт определения уровня защищённости и модель угроз;
• перечень выбранных мер по приказу ФСТЭКФедеральная служба по техническому и экспортному контролю — Регулятор технической защиты информации (ИСПДн, ГИС, КИИ); ведёт реестр сертифицированных СЗИ. от 18.02.2013 №21 и распределение ответственности;
• договоры-поручения с поставщиками и доказательства выполнения ими мер;
• результаты оценки эффективности и документ о вводе системы в эксплуатацию.

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

Когда пересматривать границы

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

Вывод системы из эксплуатации

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

Практический результат

Хорошо определённая граница отвечает на пять вопросов: где находятся ПДн, как они перемещаются, кто имеет доступ, кто выполняет каждую меру и как данные будут удалены. После этого уровень защищённости, модель угроз и приказ №21 становятся не формальным набором документов, а согласованной системой защиты. Связанный обзор всего жизненного цикла — в статье «Обработка ПДн с использованием средств автоматизации».