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

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

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

Главная ошибка при создании ИСПДн — подменить управление рисками покупкой набора средств защиты.

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

1. Определение уровня защищенности: методология классификации данных

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

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

Какие данные попадают в контур

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

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

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

Почему «класс защищенности ИСПДн» часто вводит в заблуждение

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

В нормативном контуре обычно анализируются:

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

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

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

Как выглядит практическая классификация

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

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

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

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

2. Технические требования к защите персональных данных в контуре компании

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

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

Доступ: от учетной записи к конкретному действию

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

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

Здесь полезно разделять четыре уровня:

1. Идентификация — система понимает, под какой учетной записью действует пользователь.

2. Аутентификация — система убеждается, что пользователь действительно владеет этой учетной записью.

3. Авторизация — система определяет, какие действия ему разрешены.

4. Аудит — система фиксирует, что именно произошло и кто выполнил операцию.

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

Журналы событий и наблюдаемость

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

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

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

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

Сегментация и резервирование

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

Сегментация разделяет контур на зоны с разными правилами взаимодействия. Сервер базы персональных данных не должен принимать произвольные подключения от каждого рабочего места. Административный интерфейс открывают только из выделенной зоны управления. Тестовая среда отделяется от промышленной. Гостевой Wi-Fi не получает маршрут к корпоративным ресурсам.

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

Резервная копия — это часть ИСПДн, а не внешний к ней объект. На нее распространяется тот же разговор о доступе, журналировании и защите каналов.

3. Проектирование системы защиты персональных данных: от модели угроз до внедрения

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

Что должна объяснять модель угроз

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

Отдельно анализируют каналы, по которым данные покидают контролируемый контур:

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

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

Внедрение без разрыва между проектом и эксплуатацией

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

Рабочая последовательность обычно выглядит так:

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

2. Описание потоков. Фиксируется движение информации между системами и внешними участниками.

3. Определение границ ИСПДн. Отдельно отмечаются промышленная, тестовая, резервная и административная среды.

4. Формирование модели угроз. Для каждой зоны описываются источники угроз, уязвимые точки и возможные последствия.

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

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

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

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

Подрядчики и цепочка обработки

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

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

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

4. Роль средств криптографической защиты в обеспечении соответствия регуляторам

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

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

Где криптография действительно закрывает риск

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

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

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

Когда требуется сертифицированное решение

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

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

На практике при проектировании проверяют:

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

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

Организационные меры, без которых техническая система остается незавершенной

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

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

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

Полезно заранее разделить регламенты на несколько уровней:

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

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

Как оценить зрелость проектирования

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

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

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

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

Вывод

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

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

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