Системы защиты данных: критерии выбора без ошибок

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

Сначала классификация: что именно защищаем

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

Данные бывают в трех состояниях:

1. At rest — лежат в базе, файловом хранилище, объектном бакете, архиве, бэкапе, на диске ноутбука.

2. In transit — передаются между сервисами, филиалами, пользователями, API, облаками.

3. In use — обрабатываются приложением, пользователем, аналитической системой, LLM-сервисом, BI-контуром.

Под каждое состояние нужен свой контроль. Шифрование диска закрывает at rest, но не контролирует выгрузку CSV из CRM. TLS защищает канал, но не запрещает отправку файла не тому адресату. DLP видит часть пользовательских операций, но не заменяет IAM и резервное копирование.

Классификация по типу защиты выглядит так:

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

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

Шифрование: AES-256 не равно безопасность

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

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

Критичные вопросы:

• Где хранятся ключи. Встроенное хранилище продукта, внешний KMS, HSM, облачный KMS. Чем ближе ключи к данным и администраторам приложения, тем выше риск.
• Кто имеет доступ к ключам. Один глобальный администратор — плохая модель. Нужны разделение ролей, журналирование операций, ограничение привилегий.
• Есть ли ротация. Ключи должны меняться по политике и после инцидента. Без ротации компрометация живет годами.
• Как работает удаление ключа. Для некоторых сценариев crypto-shredding быстрее и надежнее физического удаления больших массивов.
• Что происходит с резервными копиями. Бэкапы тоже должны быть зашифрованы. Отдельным ключом или отдельным контуром, а не тем же доступом, что продуктив.

Шифрование in transit — отдельный слой. TLS для внешних и внутренних соединений уже не предмет дискуссии. Но в корпоративных сетях до сих пор встречается логика «внутри периметра можно без шифрования». В 2026 году это слабая архитектура. Внутренний сегмент не является доверенной зоной по умолчанию. После компрометации одной рабочей станции злоумышленник живет именно во внутренней сети.

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

Доступ: пароль уже не контроль

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

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

Минимальный набор для корпоративного контура:

1. MFA для всех пользователей с доступом к чувствительным данным. Не только для администраторов. Бухгалтерия, HR, продажи, поддержка — типовые цели.

2. Фишинг-устойчивая MFA для критичных ролей. Аппаратные ключи или механизмы, устойчивые к перехвату одноразовых кодов, лучше SMS и push без контекста.

3. PAM для привилегированных учетных записей. Админ-доступ должен выдаваться на время, с записью сессий и журналами команд.

4. Запрет общих учеток. «admin», «support», «operator» без персональной привязки убивают расследование.

5. Условный доступ. Риск-сигналы: устройство, география, поведение, сеть, время, аномалии входа.

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

Здесь часто возникает конфликт с бизнесом: MFA «мешает», PAM «замедляет», условный доступ «ломает командировки». Это решается проектированием, а не отключением контроля. Исключения должны жить по сроку, с владельцем и логом. Бессрочное исключение — будущий инцидент.

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

Резервное копирование: 3-2-1 как нижняя планка

Правило 3-2-1: три копии данных, два разных носителя, одна копия вне основной площадки. Это старая спецификация здравого смысла. Она пережила ленточные библиотеки, виртуализацию, облака и ransomware.

Но правило часто имитируют. Делают снапшоты в том же облачном аккаунте. Хранят бэкап в той же сети. Дают backup-серверу доменную учетку с широкими правами. Шифровальщик проходит по инфраструктуре и шифрует не только продуктив, но и резервные копии. Формально бэкап был. Практически — нет.

Нормальный контур резервного копирования для защиты данных должен включать:

• Изоляцию учетных записей. Доступ к бэкапам не должен зависеть от тех же учетных данных, что продуктивная среда.
• Неизменяемость копий. Immutable storage или аналогичный механизм снижает риск удаления и шифрования бэкапов.
• Шифрование резервных копий. Особенно для off-site и облачных хранилищ.
• Тест восстановления. Бэкап без регулярного restore-теста — гипотеза.
• RPO и RTO по системам. Для CRM, ERP, файлового архива и аналитического хранилища допустимы разные окна потери и восстановления.
• Отдельный сценарий для ransomware. Восстановление должно учитывать зараженные образы, компрометированные учетные записи и необходимость чистой среды.

Сравнение подходов:

Резервное копирование не заменяет DLP, EDR или MFA. Оно закрывает другой класс ущерба: потерю доступности и целостности. Для бизнеса это часто важнее самой утечки. Утекшие данные нельзя «откатить», но зашифрованную базу можно восстановить, если архитектура не сэкономила на изоляции.

Бэкап существует только после успешного восстановления. До этого это файл с обещанием.

Регуляторика: GDPR, 152-ФЗ и доказуемость процесса

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

GDPR действует с 2018 года и требует уведомления надзорного органа об утечке персональных данных в течение 72 часов после обнаружения. Это жесткий срок. Его невозможно выполнить, если организация не знает:

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

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

С технической стороны регуляторика означает несколько требований к системе:

1. Инвентаризация данных. Нельзя защищать неизвестные таблицы, дампы, экспортированные отчеты и теневые копии в личных папках.

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

3. Журналирование доступа. Не только вход в систему, но и чтение, экспорт, массовые операции, изменение прав.

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

5. Процедура уведомления. Юристы, ИБ, ИТ, PR и владельцы бизнес-систем должны понимать порядок действий до инцидента.

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

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

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

Масштабируемость: защита должна расти быстрее хаоса

Корпоративная инфраструктура редко остается статичной. Добавляются SaaS, облачные проекты, подрядчики, API, мобильные устройства, data lake, BI, ИИ-инструменты. Система защиты данных, построенная только вокруг локальной сети и файлового сервера, быстро слепнет.

Критерии выбора СЗИ надо привязывать к масштабу:

Отдельный блок — защита данных в ИИ-сценариях. Бизнес уже загружает документы в LLM-сервисы, строит RAG, подключает корпоративные базы к ассистентам. Здесь классические DLP-политики часто не видят контекст. Файл не отправлен по почте, но его фрагменты попали в промпт. Или ассистент получил доступ к папке шире, чем должен пользователь.

Для таких сценариев нужны:

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

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

Как выбрать систему защиты данных без самообмана

Практичный порядок выбора выглядит так.

1. Составить карту данных. Системы, базы, файловые хранилища, SaaS, бэкапы, выгрузки, интеграции. Без карты данных выбор будет гаданием.

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

3. Построить модель угроз. Фишинг, компрометация учеток, инсайдер, ransomware, ошибка администратора, уязвимость нулевого дня, утечка через подрядчика.

4. Проверить текущие контроли. MFA, права, шифрование, бэкапы, логи, DLP, EDR, процессы увольнения и доступа подрядчиков.

5. Найти разрывы. Не «какого продукта нет», а какой риск не закрыт. Например: нет immutable-бэкапов, нет PAM, нет аудита массового экспорта.

6. Сформировать требования к системе. Интеграции, API, экспорт логов, поддержка SSO, KMS, масштаб, SLA, модель лицензирования, локализация данных.

7. Провести пилот на реальных данных. Не на демо-стенде вендора. Нужны ваши роли, ваши SaaS, ваши типовые нарушения, ваши логи.

8. Оценить эксплуатацию. Кто будет разбирать алерты, менять политики, ревизовать доступы, тестировать восстановление, вести инциденты.

9. Закрепить процесс документами. Политики доступа, классификация данных, регламент реагирования, порядок уведомлений, схема резервного копирования.

10. Повторять оценку после изменений. Новый SaaS, M&A, переход в облако, внедрение ИИ, смена подрядчика — повод пересчитать риски.

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

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

Финальная позиция: покупать надо не продукт, а управляемый риск

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

Минимальная планка для бизнеса в 2026 году выглядит жестко:

• AES-256 или эквивалентный промышленный уровень шифрования для данных at rest;
• защищенная передача данных и отказ от доверия к внутренней сети по умолчанию;
• MFA для всех критичных учетных записей и фишинг-устойчивые методы для администраторов;
• PAM для привилегированного доступа;
• резервное копирование по модели 3-2-1 с изоляцией и тестами восстановления;
• immutable-копии там, где риск ransomware значим;
• журналирование доступа к данным, экспорта и изменения прав;
• понятный процесс реагирования на инциденты, включая 72-часовой регуляторный таймер для GDPR-сценариев;
• контроль SaaS, подрядчиков и ИИ-интеграций;
• регулярная ревизия прав и удаление неиспользуемых доступов.

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