В прошлом году злоумышленники зашли в 84% организаций, просто используя украденные учётные данные. Не через дыры в коде и не через уязвимости в железе — просто взяли действующий пароль и вошли, как обычный сотрудник. IBM подсчитал: средняя цена одного такого инцидента — $4,44 млн (Cost of a Data Breach 2025). В половине случаев история одна и та же: кто-то получил доступ, выполнил задачу и ушёл, а доступ за ним не закрыли. Учётная запись продолжала существовать — с теми же правами, без владельца, без контроля. Вот через неё и вошли.
Именно эту структурную проблему решает концепция Zero Standing Privileges — ZSP. Только не путайте её с очередным обновлением PAM или маркетинговой надстройкой над существующими инструментами. ZSP — это отказ от базового допущения, на котором строится вся классическая безопасность доступа: что привилегии должны существовать заранее, до того как они понадобятся.
Сразу скажу: ZSP не убирает риски взлома сессий ваших пользователей полностью. Временные токены и сессии тоже атакуются — session hijacking никуда не делся. Но окно атаки сжимается радикально. В классической модели учётная запись с правами живёт 24 часа в сутки, 365 дней в году — пока её кто-нибудь не удалит или не взломает. В модели ZSP злоумышленнику доступен только узкий промежуток активной сессии: 10–30 минут. Это принципиально другая математика угрозы.
Хорошая аналогия — отель. Вам выдали ключ-карту. Вы ожидали что он только от вашего номера. Но по факту и от вашего номера, и от служебных коридоров, и от технических помещений и серверной, потому что карту никто под конкретного гостя не настраивал. Сдать её на ресепшн при выезде? Кто-то сдал, кто-то унёс с собой, кто-то потерял ещё в первый день. Настройки защиты после выезда никто не менял — слишком дорого и хлопотно. Читаете это и думаете: «у нас примерно так»? Правильно думаете. ZSP — это когда ключ-карта физически перестаёт существовать в момент выезда. Не «попросим вернуть» — исчезает сама.
Откуда взялась идея
В сентябре 2019 года аналитики Gartner — Феликс Гетгенс, Майкл Келли и Абхьюдай Дата — опубликовали исследование «Remove Standing Privileges Through a Just-in-Time PAM Approach». Центральный аргумент был таким: пока учётная запись с широкими правами существует постоянно, она постоянно уязвима — независимо от того, насколько хорошо защищён сам пароль. Хранилище паролей защищает секрет, но не убирает учётную запись с всеми ее правами из системы. Мишень остаётся на месте — просто немного защищённее.
Gartner назвал ZSP целевым состоянием, к которому должны стремиться все организации. Forrester поддержал: это новый обязательный стандарт, а не опциональная улучшенка. С тех пор тема не утихает, потому что количество взломов через привилегированные учётные записи не снижается — растёт.
По сути ZSP достраивает два давно известных принципа — наименьших привилегий и Zero Trust. Принцип наименьших привилегий говорит: давай только то, что нужно для задачи. Zero Trust добавляет: не доверяй никому, постоянно всегда проверяй. ZSP добавляет третье измерение — временнóе: никаких прав, которые существуют дольше, чем нужна конкретная задача.
Это не изобретение с нуля: AWS поддерживает временные учётные данные через STS с 2011 года, Microsoft добавил временное членство в группах AD с 2015-го. Gartner в 2019 году не придумал технологию — он дал имя концепции и поднял её до уровня стратегического требования.
Почему классический PAM не справляется
PAM-системы появились давно, и логика у них была разумная: пароли от привилегированных учётных записей лежат в защищённом хранилище, пользователь берёт нужный пароль, делает работу, возвращает пароль обратно. Сразу оговорюсь: современные PAM-решения — CyberArk, BeyondTrust, Delinea — это не инструменты прошлого века. Они уже много лет пишут сессии, ограничивают конкретные команды и умеют выдавать JIT-доступ с удалением из групп по таймеру. Проблема не в том, что PAM плохой. Проблема в том, что даже хорошо настроенный PAM упирается в структурные ограничения, которые настройками не убрать — нужна другая архитектура.
Доступ — это всё или ничего. Классический PAM открывает доступ к сервису целиком, но не контролирует, что пользователь делает внутри. Получил доступ к серверу — делай с ним что хочешь: читай, пиши, удаляй, копируй. Взломали один аккаунт — под угрозой весь сервис, а не одна операция.
Согласование — это театр безопасности. Заявки на доступ одобряются вручную, права формально пересматриваются раз в квартал. В реальности никто не разбирается, зачем конкретному человеку конкретный доступ прямо сейчас — ставят подпись, потому что так принято. В итоге в любой крупной организации тихо живёт зоопарк: учётки «на всякий случай», admin-роли трёхлетней давности без единого пересмотра, shared-аккаунты без конкретного владельца, сервисные записи подрядчиков, которых уволили год назад. Все они имеют доступ и ждут. По данным Idira Identity Security Landscape 2026, у 96% пользователей прав больше, чем нужно для их реальной работы. Не у части — у подавляющего большинства.
Права отозвали — сессия продолжается. Вот где классический PAM ломается особенно неприятно. Традиционные PAM-решения не интегрированы напрямую с корпоративными SSO-системами и облачными IAM. Как только система выдала SAML- или OAuth-токен — она передаёт управление сессией целевому приложению. Администратора уволили, права в Active Directory закрыли, запись в PAM деактивировали — но его активное облачное подключение продолжает работать, пока токен не истечёт сам по расписанию. Это не баг конкретного вендора — это архитектурное ограничение всей модели с долгоживущими сессиями.
Пять тысяч открытых дверей. Крупные облачные провайдеры предлагают свыше 5000 типов полномочий — на каждый ресурс, каждое действие, каждый сценарий. Большинство из них сотрудники не используют никогда. Но все они назначены — потому что проще дать с запасом, чем разбираться, что именно нужно. И через любое из этих неиспользуемых полномочий можно войти.
PAM, JIT и ZSP — это не конкуренты, это этапы одного пути
Здесь часто путаются, поэтому скажу прямо: ZSP не заменяет PAM и не отменяет JIT. Без нормально настроенного PAM и механизмов JIT концепция ZSP вообще не заработает — нечем будет управлять временными учётными записями и некому их создавать.
PAM — это инфраструктура: хранилища, политики, аудит, управление жизненным циклом учётных записей. JIT (Just-In-Time) — это механизм: права выдаются ровно в тот момент, когда они нужны, а не хранятся постоянно. ZSP — это целевое состояние поверх них: постоянных привилегированных записей нет вообще, они создаются динамически под задачу и уничтожаются после.
Компания не выбирает между тремя колонками в таблице. Она проходит их последовательно: сначала наводит порядок в PAM — убирает зоопарк учёток, настраивает политики. Потом переходит на JIT — права выдаются по запросу, а не хранятся постоянно. Потом убирает постоянные учётные записи полностью — это и есть ZSP. Перепрыгнуть этапы не получится.
| Критерий | Классический PAM | Just-In-Time (JIT) | Zero Standing Privileges |
|---|---|---|---|
| Что есть в системе по умолчанию | Постоянные учётные записи с широкими правами | Учётные записи есть, права урезаны до минимума | Привилегированных записей не существует вообще |
| Как получить доступ | Взять пароль из хранилища | Временно войти в нужную группу | Система создаёт одноразового пользователя прямо сейчас |
| Сколько живут права | Постоянно — пока кто-нибудь не удалит | Часы или дни — по таймеру | Ровно столько, сколько длится задача |
| Что происходит после работы | Пароль возвращается в хранилище, запись активна | Пользователя исключили из группы, сама запись осталась | Временная запись полностью удалена |
| Остаточный риск | Высокий: статические пароли можно перехватить в любой момент | Средний: запись уязвима вне рабочих окон | Минимальный: атаковать нечего — записи не существует |
Как это реально работает в продуктах
Одноразовые пользователи в Active Directory. Инженер через Palo Alto Networks Idira запрашивает RDP-доступ к Windows-серверу. Система не извлекает пароль из хранилища для существующей учётки — она создаёт нового пользователя прямо в этот момент, добавляет его в нужные группы безопасности и строит сессию, не пуская инженера напрямую во внутреннюю сеть. Инженер закончил работу — пользователь удалён полностью. Не заморожен, не деактивирован — удалён. Здесь есть реальная техническая сложность: AD не предназначена для массового создания и удаления пользователей в реальном времени, репликация между контроллерами домена может занимать минуты, а удалённые объекты оставляют SID в журналах и ACL. Именно поэтому лучшие реализации ZSP для Windows, как у Teleport, вообще не трогают AD — работают через собственный прокси с сертификатами поверх неё.
Без хранилища паролей вообще. Teleport пошёл дальше и убрал хранилище как концепцию. Вместо статических паролей и SSH-ключей система выдаёт короткоживущие X.509-сертификаты, криптографически привязанные к конкретному человеку. Сессия закрылась — сертификат автоматически уничтожен. Некому случайно скопировать ключ в Telegram, некому забыть его сменить после увольнения коллеги.
Доступ отзывается в реальном времени, не по расписанию. Нормальные современные решения не просто выдают токен и ждут, пока он истечёт сам. Они непрерывно следят за контекстом: уволили сотрудника в HR-системе, устройство повело себя подозрительно, EDR зафиксировал аномалию — доступ отрубается мгновенно, не дожидаясь планового истечения токена.
ИИ-агенты — это новые сервисные учётки, только опаснее
Сервисные учётные записи всегда были головной болью безопасников: их создавали при запуске системы, давали широкий постоянный доступ к базам и API — и забывали про них на годы. Никто не пересматривал права, никто не проверял, кто ими пользуется. Типичный пример накопленного технического долга безопасности.
С ИИ-агентами та же история повторяется — но масштаб угрозы другой. Агент, который сверяет платежи раз в месяц, не должен круглосуточно иметь доступ к финансовой базе данных. Это очевидно. Но без ZSP именно так и происходит: аккаунт создали при развёртывании агента и не трогают до списания всей системы. Фактически это суперпользователь, который никогда не уходит домой и никогда не берёт отпуск.
И вот тут разница с человеком принципиальная. Человек сделал что-то не то — остановился, заметил, исправил. Агент выполняет тысячи операций в минуту без пауз. Ошибка или намеренная инъекция промптов — когда злоумышленник подбрасывает агенту вредоносные инструкции через данные, которые тот обрабатывает — масштабируется мгновенно и без человеческого контроля.
ZSP переводит агентов на ту же схему, что и людей: запросил временный токен, выполнил задачу, потерял доступ. Плюс жёсткое ограничение набора действий — не на уровне инструкции агенту, а на уровне авторизации в системе. Агент настроен читать логи — попытка записать код или изменить конфигурацию будет отклонена на уровне прав, а не зависеть от того, правильно ли сработала инструкция.
IBM Cost of a Data Breach 2025 подтверждает это цифрой: 97% утечек, связанных с ИИ, произошли в средах, где не было контроля доступа и формализованных политик. Не в половине случаев — в девяноста семи процентах.
Где ZSP уже работает
Промышленность и SCADA. Внешний подрядчик приходит обслуживать оборудование на электростанции. В старой схеме он получает пароль от системы управления — и этот пароль потом живёт в его записной книжке, в телефоне, иногда на стикере на мониторе ещё лет пять после завершения контракта. В ZSP-схеме система сама подставляет учётные данные в сессию на время работ — подрядчик пароля не видит вообще, он просто работает. Контракт закончился — доступ исчез автоматически. По оценкам аналитиков, такой подход снижает вероятность успешной атаки на критическую инфраструктуру больше чем на 50%.
Здравоохранение. Врач видит карту пациента только во время своей смены и только в рамках запланированного приёма. Попытка получить доступ к базе в нерабочее время или к карте пациента, который к нему не записан — технически невозможна, это не вопрос политики, а вопрос архитектуры доступа. Это одновременно выполнение требований HIPAA и реальная защита от инсайдерских утечек, когда сотрудник сливает данные намеренно.
DevOps. Постоянные ключи к Kubernetes и облачным ресурсам исчезают из сборочных конвейеров — туда, где их чаще всего и крадут через утечки из репозиториев. Деплой проходит через временную роль, которая создаётся перед сборкой и уничтожается сразу после. Доступ привязан к конкретному тикету в Jira или ServiceNow: нет открытого тикета — система просто не выдаст роль.
Почему компании внедряют это медленно
ZSP звучит разумно, цифры убедительные — но внедряют медленно. Причины?
Первая — администраторы воспринимают это как личное недоверие. Человек десять лет работает с постоянным root-доступом — и вдруг его просят каждый раз запрашивать права заново. С его точки зрения это выглядит как: «вам теперь не доверяют». Технически вопрос решается за неделю, организационно — может затянуться на месяцы.
Вторая — разработчики говорят, что это тормозит деливери. Они привыкли, что доступ к среде есть всегда, и любое ожидание — это потеря темпа. На практике это решается автоматизацией: запрос доступа через Slack занимает 30 секунд. Но кто-то должен эту автоматизацию настроить, и кто-то должен выделить на это время.
Третья — легаси-системы просто не поддерживают временные учётные записи технически. Промышленные контроллеры, ERP-системы девяностых, старые базы данных — они рассчитаны на статические учётки и ничего другого не понимают. Там ZSP реализуется частично через прокси-слой или не реализуется вообще. Полного покрытия в таких средах не будет.
Четвёртое — и об этом говорят реже всего. ZSP сокращает окно атаки, но не закрывает его полностью. Перехватил злоумышленник сессию в момент её работы — у него те же 10–30 минут с теми же правами. За это время можно сделать дамп базы или запустить вредоносный скрипт — и временность сессии не поможет. Поэтому ZSP без мониторинга действий внутри сессии — это половина защиты. Ещё одна реальная проблема — долгие операции: миграция данных на 2 часа, ночной бэкап, длинный ETL-процесс. Для них нужны отдельные политики с увеличенным окном сессии — и это место, где архитектура ZSP требует честного компромисса.
Как это выглядит на практике
Лучше всего разница видна на конкретном сценарии. Инженер получил задачу — обновить конфигурацию на продакшн-сервере.
Старая схема: он открывает записную книжку или корпоративный менеджер паролей, берёт пароль от shared-аккаунта типа «svc_admin», подключается. Этот аккаунт существует вне зависимости от того, работает инженер прямо сейчас или нет — ночью, в выходные, через год после его увольнения. Кто ещё знает этот пароль — неизвестно.
ZSP-схема: инженер открывает Slack и нажимает кнопку запроса доступа. Система проверяет, что в трекере существует открытый тикет на эту задачу. Создаёт одноразового пользователя с правами ровно на нужную операцию. Инженер подключается, делает изменение, закрывает соединение. Пользователя уже нет. Следующий запрос создаст другого — с новым именем, новым токеном, новой записью в журнале аудита.
С чего начать
Переход к ZSP — это не замена существующей PAM-системы, а её развитие. Инфраструктура остаётся, меняется логика работы: вместо постоянных учётных записей с хранимыми паролями — временные, которые PAM создаёт по запросу и уничтожает автоматически после завершения сессии.
Шаг 1. Аудит того, что есть. Инвентаризация всех учётных записей с привилегированным доступом: кто создал, кому выдан, когда последний раз использовался. Запись без понятного владельца или без реальной бизнес-задачи отключается немедленно. Это неприятный разговор, но он необходим — именно эти «ничейные» учётки чаще всего становятся точкой входа.
Шаг 2. Политики под задачи, а не роли на вырост. Уходим от фиксированных широких ролей. Для каждого сценария — шаблон: сколько длится сессия, при каком условии доступ выдаётся вообще (только если в трекере открыт инцидент определённого типа, только с проверенного корпоративного устройства), какую многофакторную проверку проходит пользователь перед подключением.
Шаг 3. Автоматизация, иначе это не взлетит. Если получение временного доступа занимает больше двух минут — люди найдут обходной путь. Запросы через Slack или Teams, автоматическое создание записи в Active Directory или облаке, уведомление руководителя в случае нестандартного запроса. Один клик — и через несколько секунд человек работает.
Шаг 4. Мониторинг и автоматический отзыв. Время сессии вышло или система обнаружила аномалию — доступ закрывается автоматически, без ожидания, пока кто-то вручную нажмёт кнопку. Каждое действие пишется в журнал: аудиторы получают полную картину того, кто, когда и что делал.
И сразу отвечу на вопрос, который неизменно возникает: а что, совсем никаких постоянных прав не остаётся? Остаётся одна «аварийная» учётная запись — физически запечатана, хранится отдельно от основной инфраструктуры, используется только в случае полного отказа систем управления доступом. Её применение автоматически запускает расследование. Это не дыра в архитектуре — это огнетушитель за стеклом.
Рынок уже проголосовал
ZSP всё чаще становится обязательным условием для получения киберстраховки. Страховщики при расчёте рисков смотрят на архитектуру управления доступом — и компании без контроля привилегий либо получают отказ, либо платят принципиально другую, значительно более высокую премию.
Цена промедления измеряется конкретно. По данным Idira Identity Security Landscape 2026: в прошлом году у 87 компаний из ста злоумышленники как минимум дважды успешно входили в системы через чужие учётные данные. Когда это происходило, команды безопасности в среднем теряли 12 часов только на то, чтобы выяснить — где именно произошёл взлом и через какую учётную запись. Потому что инструменты управления идентификацией были разрозненными и не давали единой картины.
В феврале 2026 года Palo Alto Networks закрыла сделку по покупке CyberArk и выпустила объединённую платформу Idira — PAM, IAM и управление агентскими идентичностями в одном месте. Это не случайное корпоративное решение: крупнейший вендор в области сетевой безопасности поставил управление идентификацией в центр своей стратегии, потому что именно здесь сейчас проходит основная линия атаки.
Постоянные права доступа — это не устаревшая техническая деталь, которую можно исправить в следующем квартале. Это фундаментальное архитектурное решение: доступ существует заранее, потому что так удобнее. ZSP отвергает этот компромисс. Старая модель защищает доступ — ставит замки, ротирует пароли, логирует подключения. Новая убирает сам объект атаки: привилегированной записи нет, красть нечего. Злоумышленники не взламывают — они входят. ZSP закрывает дверь, которой больше нет.