«Доверие, это не абстракция, а конкретный механизм принятия решений, который в IT-инфраструктуре часто противоречит формальным процедурам. Мы доверяем коллеге, а не системе, потому что система не умеет объяснять, а человек — умеет. Это создаёт слепые зоны в безопасности, которые нельзя устранить только техническими средствами.»
Почему мы обходим систему
Представьте ситуацию: нужно срочно получить доступ к тестовому стенду. Процедура требует создания заявки в Service Desk, согласования с владельцем ресурса и ожидания в течение нескольких часов. Вместо этого вы пишете в мессенджер коллеге, который администрирует этот стенд. Через пять минут доступ открыт. Система контроля доступа осталась в стороне, журналы аудита — пусты, а задача решена.
Это не лень и не саботаж. Это рациональный выбор в условиях, когда формальные системы созданы для идеального мира, а реальность требует скорости и гибкости. Система видит вас как набор атрибутов: логин, группа, роль. Коллега видит вас как личность с репутацией, контекстом задачи и срочностью. Система следует правилам, человек — понимает обстоятельства.
В основе этого лежит фундаментальное различие между формальным доверием, делегированным системе через политики и роли, и неформальным доверием, возникающим между людьми. Первое — бюрократично, медленно, но поддаётся аудиту. Второе — мгновенно, адаптивно, но полностью непрозрачно для контролирующих органов.
Слепые зоны, которые создаёт человеческое доверие
Когда доверие смещается с систем на людей, в инфраструктуре появляются уязвимости, которые не видны сканерам и SIEM.
- Теневые доступы. Права, выданные «на словах» или через личные учётные записи коллег. Они не отражены в CMDB, не имеют срока действия и забываются сразу после решения текущей проблемы.
- Обход журналирования. Критичные действия, такие как изменение конфигурации или остановка службы, выполняются через консоль, к которой у коллеги есть root-доступ. В логах остаётся только факт входа, но не суть операции.
- Эрозия модели «наименьших привилегий». Чтобы не обращаться каждый раз за правами, пользователи получают постоянные избыточные привилегии «на всякий случай». Эта практика легализуется со временем.
Эти зоны — не злой умысел, а побочный продукт рабочего процесса, который система не смогла удовлетворить. Проблема в том, что они становятся точкой входа для инсайдерских угроз или компрометации учётных данных доверенного лица.
Что не так с системами контроля
Требования регуляторов, таких как ФСТЭК или 152-ФЗ, фокусируются на формальных атрибутах: разграничении доступа, обязательном аудите, учёте активов. Эти системы отлично ловят отклонения от прописанных правил, но совершенно слепы к ситуациям, где правила обходятся с молчаливого согласия всех участников.
Основные недостатки формальных систем с точки зрения пользователя:
- Нулевая контекстная осведомлённость. Система не знает, что задача срочная, что это инцидент или что у пользователя уже есть опыт подобных операций. Она видит только запрос, не соответствующий шаблону.
- Неспособность к переговорам. Человек может объяснить, почему ему нужен доступ, привести аргументы, получить одобрение на исключение. Диалог с ticketing-системой сводится к выбору категории из выпадающего списка.
- Задержки, которые делают работу невозможной. Когда срок выполнения задачи измеряется минутами, а согласование — часами, выбор в пользу неформального канала становится неизбежным.
В результате возникает парадокс: чем строже и сложнее система контроля, тем больше параллельных, неучтённых процессов она порождает. Безопасность на бумаге растёт, а реальная — снижается.
Как проектировать системы, которым будут доверять
Задача — не искоренить человеческое взаимодействие, а интегрировать его в контур контроля, сделав легальные процессы достаточно быстрыми и умными, чтобы в них было смысл участвовать.
1. Внедрение Just-In-Time доступа
Вместо статичных привилегий — динамичная выдача прав на короткий срок для конкретной задачи. Современные PAM-решения и системы управления идентификацией позволяют запросить повышенные права через самообслуживание с автоматическим или быстрым одобрением. Ключ — скорость. Если получение временного административного доступа занимает 30 секунд, необходимость просить коллегу «дать под его учёткой» отпадает.
2. Контекстная аутентификация и одобрение
Система должна оценивать не только «кто запрашивает», но и «в какой ситуации». Интеграция с системами мониторинга (например, при запросе доступа к серверу во время инцидента) или календарём (срочная задача в нерабочее время) позволяет автоматически применять упрощённые процедуры одобрения для заранее определённых сценариев.
3. Легализация «быстрых» каналов с аудитом
Создайте официальный, но оперативный канал для срочных запросов. Например, выделенный чат-бот в корпоративном мессенджере, где запрос на доступ логируется, а одобрение от ответственного лица (через реакцию или короткую команду) становится юридически значимым событием. Это превращает неформальное действие в формальное, не теряя скорости.
4. Системы, которые объясняют
Одна из главных причин недоверия — непонятный отказ. Если система не просто отклоняет заявку, а поясняет: «Доступ отклонён, потому что ваша учётная запись не входит в группу ‘Разработчики-Бэкенд’, а запрашиваемый ресурс содержит данные ПДн. Для получения доступа необходимо согласование с отделом безопасности. Вот ссылка на форму запроса», — пользователь с большей вероятностью пойдёт официальным путём. Прозрачность рождает доверие.
Баланс, а не победа
Цель — не заставить людей безоговорочно доверять системе, а создать такую систему, которой имеет смысл доверять. Она должна конкурировать с удобством человеческого взаимодействия по скорости и осмысленности. Когда процедура перестаёт восприниматься как препятствие для работы и становится её эффективной частью, необходимость в обходных манёврах исчезает сама собой.
Доверие к знакомым, это индикатор, а не проблема. Он показывает, где формальные процессы оторвались от реальности. Задача архитектора безопасности — не бороться с этим индикатором, а использовать его данные для проектирования более человекоориентированных и оттого — более безопасных систем.