PAM 
Можно сократить поверхность атаки на облачную инфраструктуру, проверяя каждое постоянное разрешение на облачных платформах и платформах управления идентификацией, удаляя ненужные права доступа и заменяя постоянно активны...
опубликованный , дата публикации: 01 сентября, 2026
Одна из наиболее уязвимых составляющих современной поверхности атаки — постоянные привилегии: права доступа, которые продолжают действовать для учетных записей даже после того, как необходимость в них исчезла. При наличии постоянных привилегий статические учетные данные легче похитить, а учетные записи с избыточными правами дают злоумышленникам значительно больше возможностей для перемещения по системе и доступа к ресурсам. Принцип отсутствия постоянных привилегий (ZSP) решает эти проблемы за счет предоставления доступа только тогда, когда он действительно нужен, и его отзыва сразу после завершения задачи, чтобы лишние права не сохранялись. Однако внедрение ZSP не так просто, как может показаться: переход от постоянного доступа к модели, в которой доступ предоставляется только по необходимости, затрагивает практически все системы, механизмы идентификации и рабочие процессы в организации. К распространенным проблемам при внедрении модели отсутствия постоянных привилегий относятся устаревшие системы, не поддерживающие временный доступ, защита машинных идентичностей, сопротивление внутри организации и необходимость подтверждать соответствие требованиям в ходе аудита.
Продолжайте читать, чтобы узнать о самых распространенных проблемах при переходе к отсутствию постоянных привилегий, подходах к их решению и о том, как может помочь Keeper®.
6 самых распространенных проблем при переходе к отсутствию постоянных привилегий
Хотя отсутствие постоянных привилегий — желаемая модель для любой организации, перейти к ней бывает непросто. Ниже рассмотрены самые распространенные сложности при внедрении ZSP и способы их преодоления.
1. Устаревшие системы
Устаревшие инфраструктурные решения и приложения часто рассчитаны на использование постоянных учетных данных для входа, которые всегда остаются доступными. Это прямо противоречит требованиям ZSP, поэтому такие системы нередко не позволяют выдавать доступ по требованию и автоматически отзывать его вскоре после этого. Именно поэтому внедрить ZSP в них особенно сложно. Оптимальный подход — переходить поэтапно, а не пытаться сделать все сразу: сначала охватить системы с наибольшим уровнем риска и установить перед устаревшей системой прокси-сервер управления привилегированным доступом (PAM). Поскольку прокси-сервер выступает в роли контролирующего шлюза, устаревшая система продолжает работать привычным для нее способом, а PAM-инструмент предоставляет временный доступ и регистрирует все действия.
2. Нечеловеческие идентичности (NHI)
Постоянные привилегии — проблема не только пользователей: они также характерны для нечеловеческих идентичностей (NHI). Служебные учетные записи и автоматизированные процессы часто используют долговременные учетные данные, которые однажды настроили и затем забыли, поскольку ими напрямую не пользуется человек. В результате такие данные никто не меняет и не отзывает. Поскольку эти идентичности часто обладают привилегированным доступом, а в облачно-нативных средах превышают количество пользователей-людей примерно в соотношении 144:1, они становятся все более заметной и часто упускаемой из виду частью поверхности атаки. К NHI следует применять такой же строгий контроль, как и к пользователям: долговременные учетные данные нужно заменять краткосрочными, которые создаются во время выполнения и автоматически истекают, чтобы постоянный доступ не сохранялся.
3. Агентский ИИ
Помимо нечеловеческих идентичностей, еще одной сложностью при внедрении модели отсутствия постоянных привилегий становятся ИИ-агенты. Они создаются на ограниченное время, выполняют конкретную задачу и во время работы получают доступ только к тем ресурсам, которые им необходимы. Если организация заранее предоставляет им права доступа, это приводит к избыточным разрешениям «на всякий случай», а со временем такой доступ накапливается и выходит из-под контроля. Поэтому ИИ-агентам необходимо предоставлять доступ только на время выполнения задачи, строго ограничивать область действия каждого токена конкретной задачей или инструментом, который использует агент, и автоматически отзывать доступ сразу после завершения задачи.
4. Сложность RBAC
Управление доступом на основе ролей (RBAC) — естественная основа для модели отсутствия постоянных привилегий, однако точно определять роли на уровне отдельных задач и поддерживать их в большом масштабе сложно. Роли меняются по мере того, как сотрудники берут на себя новые обязанности, разрешения со временем накапливаются, и в итоге даже тщательно продуманные роли перестают соответствовать объему привилегированного доступа, который действительно необходим организации. Решение заключается в том, чтобы регулярно пересматривать права доступа и использовать автоматическое выявление назначенных разрешений, чтобы находить неиспользуемый доступ и постепенно переходить к управлению доступом на основе атрибутов (ABAC).
5. Сопротивление изменениям и снижение продуктивности
Люди склонны воспринимать постоянный доступ как нечто, что принадлежит им, поэтому необходимость отказаться от него вызывает сопротивление и опасения, что процессы запроса и одобрения доступа будут замедлять работу команд, привыкших действовать быстро. Если оставить эти опасения без внимания, сопротивление может затормозить внедрение еще до того, как новый подход начнет приносить пользу. Решение заключается в грамотной коммуникации: важно объяснить, зачем нужны изменения, и на реальных примерах инцидентов, связанных с постоянным доступом, показать, к каким рискам он приводит.
6. Недостаточная прозрачность для аудита
Очень сложно доказать, что модель ZSP действительно работает, если нет возможности в режиме реального времени видеть, кто получил доступ, когда, к каким ресурсам и по какой причине. Если организация не может подтвердить, что доступ предоставляется и отзывается надлежащим образом, ей будет трудно убедить в эффективности этой модели аудиторов — да и собственных специалистов. Чтобы этого избежать, необходимы централизованное ведение журналов, мониторинг и запись сеансов, а также регулярный пересмотр прав доступа. Все это позволяет формировать подтверждающие данные, которые можно напрямую предоставить аудиторам. Проверяемая прозрачность превращает ZSP из формальной политики в механизм, эффективность которого можно реально подтвердить.
Как подходить к решению проблем при переходе к отсутствию постоянных привилегий
Хотя многие сложности, связанные с ZSP, вполне реальны, их можно решить при правильном подходе. Ниже приведены шаги, которые помогут внедрить модель отсутствия постоянных привилегий в организации:
- Выявите и инвентаризируйте постоянные привилегии и NHI: начните с перечня всех учетных записей с постоянным доступом — не только пользователей, но и машинных идентичностей, таких как служебные учетные записи и ИИ-агенты.
- Расставьте приоритеты по уровню риска: оцените потенциальный ущерб в случае компрометации и начните с объектов с наибольшим риском — например, привилегированных учетных записей администраторов, ИИ-агентов и всего, что связано с критически важными системами.
- Проведите пилотное внедрение в ограниченном, но важном сценарии: сначала протестируйте модель в одной значимой, но управляемой области, а уже затем распространяйте ее на всю организацию. Это позволит убедиться, что подход работает, и устранить проблемы в контролируемой среде, чтобы ранняя ошибка не затронула всю организацию.
- Автоматизируйте запрос, одобрение и отзыв доступа: убедившись, что модель работает, откажитесь от ручных процессов и автоматизируйте их, чтобы ZSP можно было эффективно применять в масштабе всей организации и забытый отзыв доступа не приводил к повторному накоплению постоянных привилегий.
- Постоянно проводите аудит и подтверждайте соблюдение требований: проверяйте, что доступ предоставляется и отзывается так, как предусмотрено, и сохраняйте записи, подтверждающие, что этот процесс стабильно работает с течением времени и может быть продемонстрирован аудиторам.
Как преодолеть сложности при переходе к отсутствию постоянных привилегий с Keeper
Правильная последовательность действий и автоматизация процессов управления доступом делают переход к модели отсутствия постоянных привилегий гораздо более управляемым. Keeper Privileged Cloud обеспечивает ZSP, предоставляя повышенные права доступа только тогда, когда они запрошены, одобрены и действительно необходимы, а затем автоматически отзывает их по завершении утвержденного периода доступа. Keeper работает с уже используемыми в организации поставщиками удостоверений, включая AWS, Microsoft Entra ID, Google Cloud, Okta и Active Directory. Кроме того, система сохраняет полный журнал аудита: кто запросил доступ, кто его одобрил и когда срок доступа истёк. Сочетание автоматического повышения привилегий и полной прозрачности помогает решить некоторые из самых сложных задач, связанных с ZSP, без необходимости внедрять еще одну отдельную систему, которую пришлось бы поддерживать.
Запросите демонстрацию KeeperPAM, чтобы отказаться от постоянных привилегий во всей организации.
Вопросы и ответы
Почему отсутствие постоянных привилегий так сложно внедрить?
Внедрение модели отсутствия постоянных привилегий сложно, поскольку она затрагивает почти все системы, идентичности и рабочие процессы в организации. Устаревшие системы по умолчанию используют постоянные учётные данные, нечеловеческие идентичности и ИИ-агенты легко упустить из виду, роли со временем меняются, а команды часто сопротивляются отказу от постоянного доступа. При последовательном применении в масштабах всей организации эта модель становится сложной, поэтому поэтапное внедрение с автоматизацией обычно эффективнее, чем попытка изменить все сразу.
Можно ли применять отсутствие постоянных привилегий к устаревшим системам?
Да, модель отсутствия постоянных привилегий можно применять и к устаревшим системам, хотя они не всегда способны поддерживать ее самостоятельно. Устаревшие приложения рассчитаны на постоянные учетные данные, поэтому обычно не могут предоставлять доступ по требованию и сразу отзывать его после завершения работы. Обходной вариант — установить перед системой PAM-прокси, который будет выступать в роли контролирующего шлюза: предоставлять временный доступ, определять, кто может войти, и регистрировать каждый сеанс. Это позволяет реализовать контроль ZSP вокруг системы, которая сама по себе такую модель не поддерживает.
Что происходит с аварийным доступом после отказа от постоянных привилегий?
Отказ от постоянных привилегий не устраняет необходимость в аварийном доступе — меняется только способ его организации. Вместо нескольких постоянно активных учетных записей администраторов, распределенных по разным системам, организации сосредотачивают аварийный доступ в одной специальной административной учетной записи, которая не зависит от обычных механизмов доступа. Благодаря этому уполномоченные администраторы по-прежнему могут войти в систему в случае сбоя или неправильной конфигурации. Аварийная учетная запись — это не способ обойти ZSP, а специально предусмотренное и строго контролируемое исключение. Она хранится в защищенном хранилище, защищена MFA и надежным паролем, ее использование сопровождается оповещением и полностью регистрируется. Это позволяет сохранить возможность аварийного доступа, ограничив постоянные привилегии одной тщательно контролируемой учетной записью.
