Проверка личности становится слабым местом Zero Trust еще до первого логина: компания должна решить, кому выдать учетку, MFA и доступ, когда надежных факторов у нового сотрудника еще нет. Для русскоязычных IT-команд с удаленным наймом это не теория, а вполне практичный риск: ошиблись на входе — дальше инфраструктура сама аккуратно оформит злоумышленнику пропуск.
На эту дыру в архитектуре Zero Trust указывает Specops Software в материале, о котором сообщает BleepingComputer. Логика простая и неприятная: Zero Trust хорошо проверяет уже существующего пользователя, но плохо отвечает на вопрос, как безопасно создать этого пользователя с нуля. Service desk, HR и IT-администраторы в этот момент работают с минимумом контекста, зато принимают решения с максимальной ценой ошибки.
Классический сценарий атаки выглядит так: злоумышленник крадет пароль, обходит или ломает MFA, затем входит в корпоративную среду. В случае онбординга все выглядит чище. Атакующий проходит найм или убеждает службу поддержки, после чего компания сама создает ему учетную запись, помогает включить MFA, зарегистрировать passkey или security key, выдать корпоративное устройство и доступ к приложениям. Снаружи это уже не похоже на взлом. Это похоже на нормальный рабочий процесс, только с неправильным человеком в центре.
Specops отдельно связывает проблему с кампаниями северокорейских IT-работников, о которых ранее предупреждало ФБР. По данным ведомства, такие кандидаты использовали поддельные или украденные документы, прокси-инфраструктуру и посредников в США, чтобы устроиться на удаленную работу и получить доступ к корпоративным сетям. ФБР рекомендовало проверять личность не только при найме, но и в течение всей работы удаленных сотрудников. Для компаний, которые нанимают разработчиков, DevOps-инженеров или саппорт по всему миру, это бьет прямо в больное место: резюме, видеозвонок и уверенный голос в трубке больше не выглядят достаточной процедурой доверия.
Самый уязвимый отрезок — первичная настройка доступа. Новый сотрудник еще не имеет корпоративного устройства, зарегистрированного аутентификатора, проверенного токена или истории нормальных входов. Но именно в этот момент ему выдают пароль, подключают MFA, добавляют в группы, открывают VPN, SaaS и внутренние системы. Если в процедуре нет отдельного слоя проверки, сильная аутентификация закрепляет ошибку, а не исправляет ее. Получается почти комичная ситуация: организация строит крепкую дверь, а потом сама вручает ключ человеку, которого толком не проверила.
Разница между аутентификацией и identity proofing здесь критична. Аутентификация отвечает на вопрос: контролирует ли пользователь привязанный к аккаунту фактор. Проверка личности отвечает на другой вопрос: тот ли это человек, которому компания вообще собиралась выдать аккаунт. Для действующего сотрудника могут хватить зарегистрированного устройства или уже настроенного аутентификатора. Для новичка таких опор еще нет, поэтому Specops предлагает выносить проверку личности в обязательный этап онбординга: сканирование и валидация государственного документа плюс биометрическая проверка живого человека перед камерой.
В материале также приводится цифра из отчета Verizon Data Breach Investigations Report: украденные учетные данные фигурируют в 44,7% инцидентов. Эта статистика обычно используется как аргумент в пользу MFA, парольных политик и защиты Active Directory. Но в контексте онбординга она подсвечивает другой слой проблемы: если учетная запись создана на мошенника, пароль уже не украден — он легально выдан. И это куда хуже для расследования, потому что логи, тикеты и записи service desk будут выглядеть почти скучно.
Для разработчиков и IT-директоров вывод довольно приземленный. Процесс выдачи первого доступа должен быть спроектирован так же внимательно, как SSO, PAM или сегментация сети. Нужны четкие правила: кто подтверждает личность, какие документы или факторы принимаются, какие действия запрещены до завершения проверки, как обрабатываются исключения, что логируется и кто может переопределить решение. Особенно это важно для ролей с доступом к репозиториям, CI/CD, облачным консолям, финансовым системам и персональным данным.
Specops продвигает на этом фоне Secure Onboarding — решение, которое встраивает проверку личности в процессы онбординга и обращений в service desk. Рекламную часть стоит читать с обычной поправкой на вендора, но сама проблема от этого не исчезает. Следующий этап зрелости Zero Trust, похоже, будет не в еще одной галочке MFA, а в более скучном и важном вопросе: кто именно получает право стать доверенным пользователем в первый день.