Информационная защита персональных данных: типичные ошибки настройки

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

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

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

Права администратора как черный ход для утечки

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

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

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

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

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

Для аудита полезно сопоставить несколько источников:

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

Команда вроде Get-LocalGroupMember -Group "Administrators" может помочь собрать первичную выгрузку, но она не заменяет проверку полномочий. На части устройств результат будет зависеть от локальной конфигурации, доменной политики и особенностей операционной системы. Поэтому автоматический сбор нужно дополнять нормализацией данных: одна и та же группа может встречаться на разных машинах, а доменное членство — скрывать фактический уровень доступа.

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

Слепые зоны аудита: СКУД и биометрия

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

СКУД способна хранить ФИО, идентификатор пропуска, фотографию, сведения о подразделении, историю проходов и временные метки. Если используется биометрическая идентификация, система может обрабатывать биометрические персональные данные. Их правовой режим определяется статьей 11 Федерального закона № 152-ФЗ, а не статьей 10, которая регулирует специальные категории персональных данных. При этом сам факт наличия биометрии не означает автоматического присвоения системе конкретного уровня защищенности.

Уровень защищенности ИСПДн устанавливается с учетом условий обработки и требований применимых нормативных актов. На него могут влиять вид угроз, категории субъектов, состав данных, масштабы обработки и другие параметры, которые должны быть отражены в модели угроз и документах оператора. Поэтому фраза «биометрия — значит УЗ-4» заменяет оценку конкретной системы механическим ярлыком и может привести как к завышенным, так и к недостаточным мерам защиты.

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

Аудит СКУД должен отвечать не только на вопрос, есть ли у системы пароль администратора. Нужно установить:

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

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

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

Шаблонный комплаенс: документ есть, защиты нет

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

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

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

Минимальный набор рассогласований, которые стоит искать при внутренней проверке:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Реагирование на инцидент: первые 24 и 72 часа

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

Для инцидентов с персональными данными оператору необходимо учитывать установленные законом сроки уведомления Роскомнадзора. В действующем порядке речь идет об уведомлении о произошедшем инциденте в течение 24 часов с момента его выявления и о результатах внутреннего расследования в течение 72 часов. Эти сроки не означают, что за сутки нужно установить абсолютно все обстоятельства. Но первичное уведомление должно быть подготовлено на основании доступных данных, а уточнения — внесены по мере расследования.

Практическая последовательность может выглядеть так:

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

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

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

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

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

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

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

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

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

Что должно быть связано в одну систему

Защита персональных данных не сводится к покупке нового СЗИ. Рабочая архитектура начинается с инвентаризации и заканчивается регулярным пересмотром, а не подписанием одного документа.

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

1. Инвентаризация систем. В перечень включаются не только CRM и кадровые базы, но и СКУД, архивы документов, видеосистемы, телефония, сервисы рассылок, файловые хранилища и SaaS-платформы, если через них проходят персональные данные.

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

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

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

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

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

7. Тестирование реагирования. Регламент 24/72 часа должен быть не просто приложением к политике. Ответственные лица должны понимать, где взять журналы, кто согласует уведомление и как сохранить доказательства.

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

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

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