DLP или контроль доступа к данным: почему это разные уровни защиты

Одна утечка начинается в двух разных местах

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

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

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

Поэтому вопрос «что выбрать — DLP или контроль доступа» поставлен слишком широко. Полезнее спросить: на каком шаге возникает риск, какое решение должна принять защита и какое доказательство останется после события.

DLP отвечает за передачу, доступ — за раскрытие

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

Управление доступом принимает другое решение: может ли конкретный субъект получить объект или выполнить операцию в текущем контексте. Это не только вход по паролю. В приказе ФСТЭК России № 21 отдельно перечислены управление учётными записями, методы и правила разграничения, разделение ролей и назначение минимально необходимых прав. На практике объектом контроля может быть система, запись, документ, поле или действие: чтение, изменение, экспорт.

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

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

Статья 19 Федерального закона № 152-ФЗ также не сводит защиту к покупке одного класса решений. Оператор определяет угрозы, устанавливает правила доступа, регистрирует действия и применяет совокупность правовых, организационных и технических мер. Наличие DLP или отдельного защитного слоя само по себе не подтверждает выполнение всех требований.

Карта угроз: где нужен каждый уровень

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

Карта показывает две типичные слепые зоны. Первая — DLP хорошо видит попытку передачи, но данные уже были избыточно раскрыты внутри системы. Вторая — права настроены корректно, но разрешённо полученный набор уходит по каналу, для которого нет политики или наблюдения.

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

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

Работу удобнее начинать не с перечня продуктов, а с одной чувствительной сущности и её пути.

1. Классифицируйте объект и операции. Опишите, какие поля чувствительны, кому нужны маска или полное значение, кто может менять запись и выгружать набор.
2. Ограничьте выдачу в точке раскрытия. Роль — только начало. Учитывайте цель операции, подразделение, время, устройство, объём и необходимость дополнительного подтверждения.
3. Проверьте дальнейшее движение. Перечислите почту, веб, мессенджеры, печать, буфер обмена, съёмные носители и интеграции. Для каждого канала зафиксируйте, что реально видит действующая DLP и где начинается неконтролируемая зона.
4. Свяжите события. Событие раскрытия внутри системы и последующая попытка передачи должны сопоставляться по субъекту, времени и сценарию без записи самих персональных данных в журнал.
5. Назначьте владельца остаточного риска. Если фотографирование экрана, общий сервисный аккаунт или неохваченный канал остаются возможными, это должно быть явным решением с компенсирующей мерой, а не сюрпризом расследования.

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

Если слепая зона находится именно в моменте раскрытия полей внутри разрешённой системы, может потребоваться дополнительный внутренний слой. DataSafe закрывает чувствительные значения по роли и сценарию, журналирует обращения без хранения самих персональных данных и передаёт сигналы в действующий контур ИБ. Это не замена DLP, IAM, SIEM или организационным мерам, а способ закрыть конкретную точку выдачи данных.

Проверка текущей защиты за один проход

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

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

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

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

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

Тест понедельником

На ближайшем рабочем совещании выберите одну карточку или документ и ответьте на четыре вопроса:

1. Кто может увидеть полное чувствительное значение, а кто — только маску?
2. Кто может выгрузить его и по каким каналам передать дальше?
3. В какой точке система примет решение «разрешить» или «остановить» для каждого действия?
4. Можно ли по журналам связать раскрытие, выгрузку и передачу, не сохраняя сами чувствительные данные?

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

Важное уведомление

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