Управление привилегированным доступом

Привилегированный доступ остаётся одной из самых болезненных точек российской ИБ. Через привилегированную учётную запись подрядчика заходит шифровальщик, через сервисную учётку с давно не менявшимся паролем уходят данные, через сохранённый доступ уволенного администратора в инфраструктуру возвращается тот, кто в ней уже не работает. PAM (Privileged Access Management — управление привилегированным доступом) обещает закрыть эту зону, но на практике у одних компаний он становится единственным путём к критичным системам, а у других превращается в дорогую формальность, которую обходят сами администраторы.

Редакция CISOCLUB обсудила с 18 экспертами из 16 российских компаний 7 вопросов о том, в каких ситуациях компании приходят к PAM осознанно и в каких реактивно, какие ошибки внедрения превращают PAM в формальность, что отличает работающий проект от пилота, как меняется работа администраторов и подрядчиков, в каких случаях PAM окупается быстро и почему иногда не оправдывается, насколько российские решения готовы заменить CyberArk и при каких условиях отдельный PAM может раствориться в IdM (Identity Management — управление идентификацией), SIEM и endpoint-решениях. Своими наблюдениями и рекомендациями поделились:

• Алексей Кузнецов, директор по работе с партнерами Axiom JDK.
• Андрей Вонгай, ведущий пресейл-инженер Cloud Networks.
• Никита Блинов, ведущий пресейл-инженер Cloud Networks.
• Любовь Смирнова, менеджер сервиса PAM от Контур.Эгиды.
• Султан Салпагаров, архитектор по информационной безопасности, технологическая компания Getmobit.
• Кирилл Левкин, проджект-менеджер MD Audit (SL Soft FabricaONE.AI, акционер ГК Softline).
• Денис Фокин, руководитель отдела технического консалтинга и инженерной поддержки направления ИБ компании Axoft.
• Андрей Лаптев, директор по продуктовому развитию Индид.
• Владимир Арышев, эксперт по комплексным проектам информационной безопасности STEP LOGIC.
• Алексей Ширикалов, руководитель отдела развития продуктов компании «АйТи Бастион».
• Дмитрий Симак, менеджер по продукту, NGR Softlab.
• Игорь Еньков, владелец продукта Innostage PAM Управление привилегированным доступом.
• Илья Куриленко, заместитель генерального директора по развитию компании «Анлим».
• Леонид Ломакин, руководитель отдела разработки систем информационной безопасности iTPROTECT.
• Эльвира Хайретдинова, эксперт УЦСБ.
• Андрей Каганский, начальник отдела управления учетными данными и доступом, УЦСБ.
• Артём Назаретян, руководитель BI.ZONE PAM.
• Антон Залесский, бизнес-архитектор группы развития продукта Solar SafeInspect ГК «Солар».

Большинство экспертов называет инцидент типичным триггером реактивного внедрения, один говорит, что инцидент как раз редко становится триггером именно для PAM. Несколько экспертов связывают плохую окупаемость с малой инфраструктурой, один утверждает прямо обратное. Большинство уверено, что российские PAM закрывают сценарии CyberArk, и только спорят о деталях разрыва. И только один из 14 ответивших на последний вопрос вместо встраивания PAM в более широкие платформы и экосистемы видит его сборку из IdM, EDR, SIEM и DLP «как из кубиков».

Когда к PAM приходят сами, а когда после инцидента

Эксперты CISOCLUB описывают вход в PAM как двойной. С одной стороны это осознанный заход зрелых компаний, у которых уже работают SIEM и IdM, банков и финтеха под аудитом регуляторов, организаций после пентеста или аудита. С другой это реактивный сценарий после конкретного инцидента — чаще всего шифровальщика с RDP-доступом подрядчика, утечки через сервисную учётную запись или ухода администратора с сохранёнными правами. Один из спикеров приводит количественную характеристику: около 75% проектов стартуют именно после инцидента или успешного пентеста, и парадокс в том, что реактивный сценарий проще согласовать, бюджет размораживается быстрее, чем в осознанном проекте. Третья группа сценариев лежит в стороне от классической ИБ-боли: конфликты с контрагентами и между подразделениями, дисциплинарные расследования, реорганизация ИТ, появление нового отдела ИБ и «паранойя» руководителя на фоне аномалий и подозрений в саботаже. И один из наших собеседников считает, что инцидент как раз редко становится триггером именно для PAM, и драйвером называет сложившуюся культуру удалённой работы.

Зрелость, регуляторы и аудит как осознанный путь

Развёрнутый вариант осознанного подхода представил Алексей Ширикалов, руководитель отдела развития продуктов компании «АйТи Бастион». По его наблюдениям, в проактивном сценарии PAM появляется не на пустом месте, а как следующий шаг после уже внедрённых базовых средств: SIEM, IAM, аудит. Подрядчики при этом начинают рассматриваться как отдельный изолируемый риск, а у компаний, движущихся к zero trust, контроль привилегированного доступа становится базовой практикой.

«В проактивном сценарии — это этап, когда базовые меры уже внедрены: есть SIEM, IAM, ведется аудит. В какой-то момент становится понятно, что этого недостаточно, и возникает потребность в более глубоком контроле привилегированных доступов. В компаниях, движущихся к zero trust, это становится базовой практикой».

Финальный аргумент Алексей Ширикалов сводит к одной строчке: «Ключевое различие — в отношении к риску: либо его считают заранее, либо уже после потерь, и нередко именно бизнес становится драйвером изменений».

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

«Когда важные ИТ-системы администрируют как внутренние, так и внешние специалисты. При этом инфраструктура имеет распределенный характер, число привилегированных доступов растет, а ручной контроль перестает обеспечивать необходимый уровень управляемости. В таком случае PAM рассматривается как превентивный инструмент для разграничения обычных и привилегированных учетных записей, централизации предоставления доступа и обеспечения полного отслеживания действий».

Свою экономическую формулу осознанного захода вводит Артём Назаретян, руководитель BI.ZONE PAM. У него осознанный заход — это момент, когда руководство уже посчитало риски и видит экономику внедрения.

«В ряде случаев такие решения внедряются проактивно, когда у руководства уже сформировано понимание экономики риска: дешевле внедрить PAM, чем платить за простой, штрафы и репутационные потери».

Андрей Каганский, начальник отдела управления учетными данными и доступом, УЦСБ, отмечает, что драйвером часто становится не превентивная стратегия, а аттестация или внешний аудит на соответствие требованиям регуляторов: «В роли драйвера внедрения PAM может выступать аттестация или аудит на соответствие требованиям регуляторов, в ходе которых устанавливаются факты бесконтрольного использования привилегированных учетных записей».

Кирилл Левкин, проджект-менеджер MD Audit (SL Soft FabricaONE.AI, акционер ГК Softline), перечисляет конкретные отрасли и единственный в материалах наших собеседников внешний показатель. Осознанно к PAM приходят крупные банки, промышленность и энергетика, у которых уже внедрены IdM и SIEM. А цифру в качестве дополнительного аргумента он берёт из IBM Security: «По данным IBM Security до 20% инцидентов связаны с инсайдерскими угрозами, что часто становится триггером для внедрения PAM».

Уникальный среди наших экспертов инструмент осознанного захода описывает Дмитрий Симак, менеджер по продукту, NGR Softlab. В его опыте зрелые заказчики начинают не с выбора продукта, а с инвентаризации привилегированных учётных записей и реестра критичных систем, и лишь после этого выходят на запрос предложений у вендоров через формат RFI (Request for Information — запрос информации).

«Еще до старта проекта проводят инвентаризацию всех привилегированных учетных записей, составляют реестр критичных систем и выстраивают SLA по доступу. заказчики запускают RFI (Request for Information) с конкретными вопросами по сценариям работы с учетками, правами, ротацией паролей и интеграцией с другими системами».

Сходную мысль про корпоративные дорожные карты ИБ выражает Леонид Ломакин, руководитель отдела разработки систем информационной безопасности iTPROTECT: «РАМ-система — одно из основных решений на зрелых корпоративных дорожных картах ИБ. Когда компания понимает, что ей не удается на достаточном уровне контролировать ИТ-подрядчиков и внутренних ИТ-специалистов и администраторов, гранулярно выдавать им доступы, а также следить за безопасностью паролей, встает вопрос внедрения РАМ».

У Антона Залесского, бизнес-архитектора группы развития продукта Solar SafeInspect ГК «Солар», регуляторная карта расписана подробнее, чем у других. Он единственный среди собеседников называет 187-ФЗ и стандарты Банка России как отдельные драйверы и добавляет два сценария, не связанных с инцидентом: «Осознанный подход к внедрению PAM чаще всего встречается в трех случаях: при масштабной реорганизации ИТ-инфраструктуры, при появлении отдела ИБ, а также для соответствия регуляторным требованиям (например, для соответствия стандартам ЦБ, 187-ФЗ или при прохождении аудита)».

После инцидента и парадокс реактивного сценария

Полнее всех картину реактивного захода рисует Любовь Смирнова (Контур.Эгида). В её формулировке у PAM есть четыре типичных триггера, и они перечисляются в одном предложении почти без воды: «Шифровальщик зашел через RDP с привилегированной учеткой подрядчика, уволенный администратор сохранил доступ, утечка произошла через сервисную учетную запись с давно не менявшимся паролем, аудит выявил десятки забытых привилегированных учеток».

Самое неожиданное наблюдение Любови Смирновой — про парадокс согласования. Реактивный сценарий, по её опыту, проходит внутри компании быстрее осознанного, потому что бюджет и сроки уже не нужно отстаивать, боль уже понятна: «Парадокс в том, что реактивный сценарий проще с точки зрения согласования: боль уже понятна, бюджет размораживается быстрее, сроки становятся жесткими. В осознанных проектах PAM приходится конкурировать внутри ИБ-бюджета с другими, более срочными задачами».

Самую конкретную цифру по реактивному сценарию даёт Владимир Арышев, эксперт по комплексным проектам информационной безопасности STEP LOGIC. По его наблюдениям, после серьёзного инцидента PAM обычно внедряют в режиме «срочно вчера», и доля таких проектов в его практике значительно выше осознанных. Среди конкретных примеров инцидента, после которого приходят к PAM, он называет в том числе атаки шифровальщиков (ransomware, программа-вымогатель) на корпоративную инфраструктуру.

«Реактивный сценарий внедрения РАМ возникает после серьезного инцидента, например, компрометации домена, утечки корпоративных данных через подрядчика или ransomware. После этого PAM внедряют в режиме «срочно вчера». На практике примерно 75% проектов стартуют именно после инцидента или успешного пентеста, когда заказчик внезапно обнаруживает «дыру» в системе защиты».

Свой сценарий предлагает Султан Салпагаров, архитектор по информационной безопасности технологической компании Getmobit. Он называет причину «золотыми ключами» в руках администраторов и подчёркивает, что только после реальной утечки у бизнеса появляются метрики для разговора об инвестициях в защиту: «Осознанный выбор PAM чаще всего связан с большим количеством системных администраторов, в чьих руках концентрируется доступ к критической части чувствительной информации. Когда само существование бизнеса попадает в зависимость от работников с «золотыми ключами». Вынужденный выбор PAM — это уже случившаяся утечка, когда у бизнеса появляются реальные метрики для оценки затрат на защиту в сравнении с ценой утечки».

В одно предложение ту же логику умещает Игорь Еньков (Innostage PAM Управление привилегированным доступом): «Реактивный сценарий проще: уже произошел инцидент, и компания понимает, что нормальный контроль привилегированного доступа мог бы этот инцидент предотвратить или хотя бы заметно сократить последствия. Реальные инциденты быстро показывают, что человек остается одной из самых больших проблем в ИБ, особенно если у него высокий уровень привилегий».

Нестандартные драйверы и контр-голос

Необычные сценарии входа в PAM приводит Илья Куриленко, заместитель генерального директора по развитию компании «Анлим». Кроме классического комплаенса с прямой ссылкой на приказ ФСТЭК России № 117, у него в списке есть два сценария: использование PAM как доказательной базы в дисциплинарных и судебных разбирательствах, а также «паранойя» руководителя на фоне аномалий и слабой коммуникации с инженерным составом.

«Здесь выделю основные сценарии, когда внедряется PAM в инфраструктуру: конфликтные ситуации с контрагентами и (или) между собственными сотрудниками/подразделениями. Гипотетически, после инцидента в организации провели расследование и установили виновного в возникновении причин происшествия. Однако на него указывают лишь косвенные улики, а сам обвиняемый отрицает свою причастность. В итоге все доходит до дисциплинарных комиссий или судебных тяжб, в которых без прямых доказательств защитить интересы у работодателя ничтожны. Улики же можно получить в ходе записей действий администратора».

Третий нестандартный мотив Илья Куриленко формулирует прямо: «Паранойя. На фоне аномалий в работе систем у руководителя появляются подозрения в саботаже его работы и команды, но нет возможности обосновать эти предположения и подстраховаться. Либо же вновь устроившийся руководитель не может выработать коммуникацию с инженерным составом, поэтому вынужден опираться только на 1-2 человек».

Андрей Вонгай, ведущий пресейл-инженер Cloud Networks, смотрит на «осознанный заход» совсем под другим углом. Он отдельно выделяет SMB-сегмент, где PAM появляется не от зрелости ИБ, а под давлением оборотных штрафов и риска приостановки деятельности. Такой проект формально «осознанный», по факту чисто реактивный по отношению к регулятору: «Часто для компаний SMB-сектора, приоритетом становится закрытие комплаенс-рисков под давлением оборотных штрафов и угрозы запрета осуществления основного вида деятельности, и в итоге бизнес «уворачивается» от санкций регулятора: средство ИБ воспринимается не как инструмент контроля, а как вынужденная мера, и как правило технически сопровождается не качественно, так как формально комплаенс-риск закрыт и мера выполнила свою функцию — PAM-направление не исключение».

Денис Фокин, руководителя отдела технического консалтинга и инженерной поддержки направления ИБ компании Axoft, в отличие от большинства экспертов, он считает, что инцидент сравнительно редко становится поводом купить именно PAM. Куда важнее в его опыте сложившаяся культура удалённой работы и общая зрелость процессов ИБ: «Чаще к осознанному PAM приходят компании-заказчики, в которых сформировалась культура удаленной работы, но при этом организация должна быть достаточно зрелая с точки зрения процессов информационной безопасности. В то же время, если говорить о практике, то она показывает, что какой-либо инцидент реже становится триггером для приобретения именно PAM-систем».

Почему пользователи обходят PAM

На вопрос об ошибках внедрения, которые превращают PAM в формальность, большинство экспертов CISOCLUB крутится вокруг одного тезиса, расходясь в нюансах. Тезис: PAM работает только тогда, когда становится единственным технически возможным путём к привилегированному доступу. Нюансы у каждого свои — от прямой блокировки сети и отключения VPN до борьбы с резервными «забытыми» учётками, файлами с паролями, реверс-прокси самих администраторов и внешним syslog-сервером для защиты логов от искажения. Трое спикеров отдельной ошибкой называют отсутствие автоматической ротации паролей привилегированных учётных записей, а неудобство работы и UX-задержки как самостоятельный драйвер обхода поднимают пятеро: Любовь Смирнова, Кирилл Левкин, Артём Назаретян, Андрей Вонгай и Султан Салпагаров. Организационный блок звучит у двух спикеров: у одного, что главная ошибка не техническая, а политическая, попытка ИБ контролировать ИТ через голову, у другого — что без согласованности между службами, без управления изменениями и без обучения сотрудников технически идеальный PAM всё равно будет обходиться.

Без технического принуждения PAM не работает

Тезис, объединяющий большинство ответов, чётче всех формулирует Любовь Смирнова (Контур.Эгида). По её опыту, главная ошибка — оставить пользователю физическую возможность зайти в обход PAM, и тогда никакие регламенты не помогут.

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

Отдельный механизм деградации Любовь Смирнова описывает через накопление исключений, которое снимает внутреннюю мотивацию следовать правилам: «Накапливаются исключения: сначала обход разрешают на время аварии, потом еще раз, и постепенно это становится нормой. По сути, PAM работает только тогда, когда становится единственным технически возможным путем к привилегированному доступу».

Практический список альтернативных входов перечисляет Алексей Ширикалов (АйТи Бастион). По его наблюдениям, любой одиночный незакрытый канал превращает PAM в формальность. «Остаются альтернативные входы — прямой доступ по RDP или SSH, локальные администраторы, сохраненные пароли, сервисные аккаунты. Пока существует хотя бы один такой путь, PAM не становится точкой контроля».

Этот же тезис в инженерной формулировке повторяет Владимир Арышев, эксперт по комплексным проектам информационной безопасности STEP LOGIC. Он перечисляет конкретные технические шаги, без которых внедрение остаётся декорацией: «РАМ действительно будет обеспечивать контроль, если другие варианты доступа к целевым системам технически невозможны: сетевые соединения заблокированы межсетевым экраном, «старый» VPN отключен, локальный доступ заблокирован».

В технических деталях Леонид Ломакин (iTPROTECT) доводит мысль до конкретного класса средств. По его опыту, прямой доступ к серверам надо закрывать не на регламентном, а на сетевом уровне через NGFW (Next Generation Firewall — межсетевой экран нового поколения), а пароли целевых систем дополнительно сменить: «Если не закрыть доступ в обход PAM (закрыв прямой доступ к серверам на уровне NGFW и/или изменив пароли от целевых систем), пользователи продолжат работать привычным образом, так как это быстрее и удобнее».

Тот же тезис сужает до конкретики бизнес-процессов Андрей Вонгай (Cloud Networks). По его наблюдениям, если архитектура внедрения не учитывает реальные сценарии, пользователи быстро находят обход: «Система требует многошаговых согласований, PAM не поддерживает привычные инструменты или требует постоянного ввода паролей там, где раньше быстро работали токены, пользователи начинают искать обходные пути чаще. Они оставляют «запасные» учетные записи вне PAM или просто работают через альтернативные теневые хосты. без блокировки прямых каналов доступа и строгой настройки сетевых политик, которые делают PAM единственной точкой входа, пользователи всегда выберут более короткий и привычный путь».

Похожую логику в своих формулировках разделяет Артём Назаретян (BI.ZONE PAM): «В первую очередь речь идет о сохранении прямого сетевого доступа к целевым системам в обход PAM, а также о ситуациях, когда у пользователя остается знание секрета привилегированной учетной записи и при этом не используется регулярная ротация». На практике, по его словам, к этому добавляется неполное покрытие систем PAM и исключения для отдельных сотрудников, причиной которых обычно становится неудобство пользовательского опыта.

О том же, но в один абзац, говорит Андрей Лаптев (Индид): «Применение PAM может не дать ожидаемого эффекта, если сохраняется возможность прямого доступа к защищаемым ресурсам в обход системы или если привилегированные пользователи продолжают использовать для доступа к этим ресурсам свои обычные учетные записи».

Самый «хакерский» взгляд на эту тему выдаёт Илья Куриленко («Анлим»). По его опыту, главная ошибка руководителя — надеяться, что у инфраструктуры просто нет обходных каналов, потому что администраторы в случае надобности построят их сами: «Самая большая ошибка для руководителя — это уповать на отсутствие физических/логических каналов связи, огибая PAM-серверов. Самим же администраторам не составит труда совершить обход интерактивно или при помощи организации реверс-прокси в инфраструктуре».

Этот же сценарий Илья Куриленко разворачивает в сторону сетевых инженеров и ротации паролей: «Если в инфраструктуре нет ротации паролей для всех учетных записей с административными правами, а также агентов для контроля интерактивных сессий, то стоит надеяться лишь на осознанность сетевых инженеров. Что они не станут причастны к инцидентам за счёт проброса обходных маршрутов».

В двух пунктах укладывает эту же группу ошибок Антон Залесский (Solar SafeInspect, ГК «Солар»): «Во-первых, это ошибки, связанные с конфигурацией PAM в сети и неверно выданными доступами. Во-вторых, пренебрежение ротацией паролей привилегированных пользователей позволяет обойти систему пользователям».

Неполное покрытие, общие учётки и забытые секреты

Если первая группа ошибок связана с инфраструктурными «дырами», то вторая — с самим объёмом охвата. Дмитрий Симак (NGR Softlab) называет именно неполное покрытие главной причиной обходов и предлагает в качестве лекарства функцию Discovery (автоматическое обнаружение устройств и учётных записей в инфраструктуре): «Админы и подрядчики продолжают использовать старые аккаунты, файлы с паролями и прямые или альтернативные каналы подключения к целевым устройствам, потому что по какой-то причине PAM не охватил все системы, а только часть «видимых» серверов и учеток. Ключевой момент — правильное использование функционала Discovery на ранних этапах».

Шире на ту же зону смотрит Эльвира Хайретдинова, эксперт УЦСБ. В её картине обход возникает там, где недостаточно проработаны организационные и инфраструктурные ограничения: подключения в обход PAM не запрещены на сетевом уровне, сервисные учётные записи не контролируются, локальные администраторы созданы там, где не нужны, пароль привилегированной учётки не скрыт от самого сотрудника, а события безопасности можно подделать на месте.

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

В качестве отдельной защиты Эльвира Хайретдинова приводит требование к скрытию пароля и внешнему хранению логов: «При такой схеме пароль от привилегированной учетной записи должен оставаться в секрете от сотрудника с целью предотвращения подключения напрямую. Все события безопасности при этом должны отправляться на внешний syslog-сервер для исключения возможности корректировки логов привилегированным пользователем».

На массовый каталог тех же ошибок указывает Кирилл Левкин (MD Audit / SL Soft FabricaONE.AI / ГК Softline). Он отдельно выделяет неполное покрытие, отсутствие мониторинга и одну особенно тонкую ошибку — избыточные права «на всякий случай», после которых сам PAM становится формальностью.

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

К этой группе примыкает наблюдение Султана Салпагарова (Getmobit), о котором редко говорят вслух: «забытые» доступы остаются вне PAM не только по халатности, но и как сознательный резерв на случай отказа самой PAM-системы.

«Технический персонал высоко ценит время. И если PAM усложняет и замедляет работу, то чаще всего при внедрении останутся «забытые» доступы в обход PAM-систем. Это происходит в том числе и по причине резервирования на случай сбоев самого PAM».

Организационные ошибки, обучение и политика

Третья группа ошибок лежит вне инфраструктуры. Игорь Еньков (Innostage PAM Управление привилегированным доступом) называет главной причиной обходов отсутствие согласованности и управления изменениями внутри самого заказчика: «Главная ошибка в том, что нет согласованности действий внутри заказчика и отсутствие процессов управления изменениями. Критически важно грамотно спланировать обучение сотрудников и донесение информации до всех зачем нужен РАМ, т.к. внедрение РАМ меняет устоявшиеся процессы получения доступа. В итоге PAM формально есть, но привилегированные пользователи продолжают работать в обход».

Острый тезис на эту тему выдвигает Денис Фокин (Axoft). Для него главная ошибка вообще не техническая, а заключается в попытке отдела ИБ контролировать ИТ-службу через голову. По его опыту, такая постановка задачи практически всегда обречена.

«Если отдел информационной безопасности хочет явно или неявно контролировать специалистов ИТ, почти всегда это обречено на провал, так как ИТ-службы как администраторы систем найдут способ получить нужный уровень доступа непосредственно к решениям. Развитие информационной безопасности всегда должно идти в связке с ИТ».

Что отличает работающий PAM от пилота, который никуда не пошёл

До промышленной эксплуатации доходят проекты, в которых ещё на старте появляется бизнес-владелец с реальными полномочиями, пилот разворачивается на реальной инфраструктуре и сценариях заказчика, а с пользователями работают так же тщательно, как с архитектурой. Эксперты CISOCLUB сходятся в том, что чаще всего пилот ломается не на интеграциях, а на людях, отсутствии цели, попытке прогнать функциональную демонстрацию вместо реальной трансформации модели управления доступом, отсутствии поэтапной дорожной карты и предпроектного обследования. Один из спикеров формулирует жёсткий критерий: пока остаётся возможность работать в обход PAM, считать его внедрённым нельзя.

Бизнес-владелец и согласие на всех уровнях

Андрей Вонгай, ведущий пресейл-инженер Cloud Networks, описывает успешные проекты как такие, где архитектура строится в порядке «от политики к внедрению», а не наоборот. У такого проекта с самого начала есть человек, который отвечает за PAM перед бизнесом и имеет право принимать решения.

«В успешных проектах с самого начала определен бизнес-владелец, который наделен полномочиями утверждать политики, разрешать межведомственные конфликты, и самое главное — добиваться интеграции системы во все ключевые бизнес-процессы с участием привилегированных пользователей. Тогда техническая часть строится по принципу «от политики к архитектуре и далее к внедрению»: формализуются правила управления привилегированными учетными записями, утверждается матрица ответственности, и под них разворачивается инструмент».

Зеркальную картину Андрей Вонгай описывает для застрявших проектов. Инструмент развёрнут, тестовые узлы подключены, но политики никто не утвердил, кому и при каких условиях выдавать доступ, неясно, а руководство так и не сформулировало бизнес-ценность системы. Итог жёсткий: «Проект существует как технологическая инициатива без административного и организационного обеспечения».

Любовь Смирнова, менеджер сервиса PAM от Контур.Эгиды, добавляет к этому уровень спонсорства. По её наблюдениям, технические сложности промышленной среды (сотни систем, несколько доменов AD, нестандартные протоколы, legacy-инфраструктура) чаще удаётся преодолеть, чем внутреннюю политику.

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

Без верхнего уровня поддержки, по словам Любови Смирновой, проекты застревают предсказуемо: «Если у проекта нет спонсора на уровне C-level, он часто застревает именно здесь».

На том же фокусе настаивает Андрей Каганский, начальник отдела управления учетными данными и доступом, УЦСБ. Он различает два сценария по тому, кто и почему инициировал внедрение. Если решение принято осознанно и на всех уровнях, пилот плавно перетекает в пуско-наладку и эксплуатацию. Если же PAM пришёл сверху по требованию регулятора, заинтересованности нет: «Работники ИТ-подразделений, которые в конечном итоге будут являться основными пользователями системы, могут проявлять несогласие и даже саботировать внедрение, так как их рабочий процесс усложнится и усилится контроль за их действиями. При достижении консенсуса ввод системы в эксплуатацию становится лишь делом техники».

Реальная инфраструктура против синтетики

Если организационная зрелость задаёт траекторию проекта, то выбор «полигона» для пилота определяет, что заказчик в принципе увидит. Дмитрий Симак, менеджер по продукту, NGR Softlab, приводит конкретные ориентиры объёма и метрики, по которым можно судить о реальном результате, а не о красиво пройденной демонстрации.

«Успешные проекты обычно начинаются с ограниченного, но живого пилота в 50–100 серверов, 2–3 критичных системы и реальные администраторы, которые работают в проде. В таких кейсах мы вместе с заказчиком фиксируем необходимые критерии успешности пилота, например доля охваченных систем, количество сессий в день, время доступа, количество срабатываний политик и т.п. Это помогает не просто показать функционал PAM-системы, а оценить ее реальное влияние на операционную работу».

Зеркально Дмитрий Симак описывает и обратный сценарий. Если пилот не привязан к реальным процессам, PAM так и остаётся отдельным экспериментом для ИБ или внутреннего аудита: «PAM существует как отдельный эксперимент для ИБ или аудита, без интеграции с инфраструктурой, менеджментом, SLA подрядчиков или внутренней системой управления доступом».

Эту же границу через противопоставление формулирует Алексей Ширикалов, руководитель отдела развития продуктов компании «АйТи Бастион»: для него ключевое отличие лежит в самом подходе к пилоту, когда заказчик понимает, что покупает изменение модели управления доступом, а не «внедрение инструмента».

«Разница почти всегда в подходе: пилот как демонстрация или пилот как начало реальной трансформации. Сам пилот при этом строится на реальной инфраструктуре и сценариях заказчика, а не как формальная демонстрация».

Самую жёсткую формулировку даёт Илья Куриленко, заместитель генерального директора по развитию компании «Анлим». Он прямо называет один из двух типичных сценариев застревания: «На пилоте обычно застревают два типа PAM-проектов. Во-первых, с исключительно синтетической средой, которая создана для проверки функциональных возможностей продукта. Во-вторых, проекты с не до конца реализованным комплексным подходом».

Где пилот ломается на людях

Игорь Еньков, владелец продукта Innostage PAM Управление привилегированным доступом, переводит разговор от технологий и инфраструктуры к самой неожиданной для вендора причине. По его опыту, пилоты с чистым техническим прохождением всё равно срываются, если в команде заказчика нет согласия. И наоборот, проект, в котором удалось договориться на всех уровнях, доходит до эксплуатации даже там, где интеграция шла тяжело.

«До продуктивной эксплуатации доходят не те PAM-проекты, где пилот технически прошёл без замечаний, а те, где удалось решить внутренние конфликты и доказать практическую ценность решения для всех заинтересованных лиц начиная от рядовых сотрудников и заканчивая руководителями ИТ и ИБ».

Главную мысль Игорь Еньков сводит к одной формуле: «Во многих внедрениях пилот ломается не об интеграции, а об отношение людей к изменениям». Поэтому успешный проект для него — это не только рабочие коннекторы и сессии, но и «согласованный порядок эксплуатации, с которым готовы жить все участники процесса».

Близкая мысль есть у Артёма Назаретяна, руководителя BI.ZONE PAM: в его трёхуровневой модели проекта работа с пользователями стоит отдельным уровнем наряду с целями и процессом, и пропуск этого уровня превращает PAM в препятствие. «Если этот этап упускается, PAM начинает восприниматься как барьер», предупреждает он. К самой модели мы вернёмся ниже.

Поэтапность, цели и предпроектное обследование

Структурированный взгляд на процесс предлагает Артём Назаретян (BI.ZONE PAM). Он делит работу на старте на три уровня и предупреждает, что без них пилот превращается в «пилот ради пилота».

«Чтобы PAM дошел до промышленной эксплуатации, важно с самого начала выстроить основу проекта на трех уровнях: целях, процессе и работе с пользователями».

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

На приоритизации и ограничении охвата настаивает и Кирилл Левкин, проджект-менеджер MD Audit (SL Soft FabricaONE.AI, акционер ГК Softline). Он формулирует это короче и одновременно объясняет типичную ошибку «давайте охватим всё сразу»: «Успешные проекты начинаются с приоритизации: сначала закрываются критичные системы. Важна поддержка бизнеса и ИТ, а не только ИБ».

Уровнем раньше, ещё до пилота, расположен этап, который выделяет Леонид Ломакин, руководитель отдела разработки систем информационной безопасности iTPROTECT. Прежде чем разворачивать стенд, он рекомендует провести содержательное обследование с теми, кто будет работать в системе: «Четко поставленные цели и границы работ. Важно перед стартом работ по внедрению провести качественное обследование, в том числе, пообщаться с будущими пользователями системы».

Свой тезис на ту же тему предлагает Антон Залесский, бизнес-архитектор группы развития продукта Solar SafeInspect ГК «Солар». По его мнению, разница между работающим и застрявшим проектом упирается в компетенции на стороне заказчика, конкретно в группе ИБ: «Ключевое отличие — в глубине понимания ИБ-специалистами принципов работы PAM, её функционала и нюансов настройки».

Замыкает тему Султан Салпагаров, архитектор по информационной безопасности технологической компании Getmobit. Его критерий «внедрён или нет» предельно простой и одновременно жёсткий: PAM считается работающим только тогда, когда он полностью замещает прямой доступ и встроен в бизнес-процессы. В противном случае всё остальное — пилот. «Возможность работать в обход PAM — это самый главный, если не единственный, признак того, что PAM не внедрен».

Как PAM меняет работу администраторов и подрядчиков

PAM меняет работу администраторов сразу в нескольких плоскостях. На уровне технологии это переход от постоянных учётных записей к доступу по запросу через единый шлюз, а у одного из спикеров ещё и с автоматической ротацией паролей после каждой сессии. На уровне дисциплины и аудита – это прозрачность действий и встречная защита самого администратора при разборе инцидента. На уровне инженерной практики – это автоматизация рутинных операций и встраивание PAM в процессы DevOps. При этом один из экспертов CISOCLUB предупреждает, что реагирование в моменте на практике отключается из-за ложных срабатываний, а ещё двое прямо говорят, что для конечного пользователя суть работы остаётся прежней, меняется только механика доступа.

Доступ по запросу вместо постоянных учётных записей

Никита Блинов, ведущий пресейл-инженер Cloud Networks, описывает основной сдвиг как переход от владения постоянными привилегированными учётками к получению доступа по запросу на ограниченное время. Администраторы и подрядчики больше не знают и не хранят пароли от критичных систем, а каждое подключение идёт через проксирующий компонент.

«Учетные данные ротируются автоматически после каждой сессии, а подключение осуществляется через проксирующий компонент PAM без прямого доступа к целевому ресурсу. Все действия в сессии, например, записываются на видео, а при попытке выполнения запрещенных операций сессия может быть прервана в реальном времени».

Особо Никита Блинов выделяет ситуацию ухода подрядчика. Если до PAM это означало ручную смену паролей на десятках серверов, то теперь действует централизованная блокировка по единой идентификации. «При завершении сотрудничества доступ блокируется централизованно без необходимости вручную менять пароли на десятках серверов».

Дмитрий Симак, менеджер по продукту, NGR Softlab, добавляет к этому единственную среди собеседников количественную метрику. По его данным, после настройки доступа Just-in-Time (JIT, доступ по запросу на ограниченное время) среднее время получения прав на критичную систему сокращается в два раза.

«После настройки JIT (Just-In-Time) доступа и процессов согласования среднее время получения доступа к критичной системе сократилось в 2 раза. Администратор получил доступ за 10 минут вместо часа-полтора ручного согласования. При этом все сессии проходили через единый шлюз, а сервисные учетки были централизованно закрыты».

Алексей Ширикалов, руководитель отдела развития продуктов компании «АйТи Бастион», описывает тот же сдвиг в более общих терминах. PAM убирает постоянные привилегированные учётки, делает доступ временным, а действия фиксируемыми, при этом пароли больше не передаются и не хранятся в открытом виде. Сопротивление при таком переходе появляется именно у внутренних ИТ-специалистов: «Основная зона сопротивления при внедрении РАМ — внутренние ИТ-специалисты: контроль редко воспринимается с энтузиазмом, тогда как подрядчики обычно адаптируются быстрее».

Эту картину одним абзацем замыкает Леонид Ломакин, руководитель отдела разработки систем информационной безопасности iTPROTECT: «У привилегированных пользователей появляется единая точка входа, через которую осуществляется вся работа с важными активами. Также у них исчезают лишние доступы — остаются лишь те, которые нужны для текущей работы».

Прозрачность действий и защита самого администратора

Если для технологии главный итог – это исчезновение постоянных прав, то для людей главный итог другой. Любовь Смирнова, менеджер сервиса PAM от Контур.Эгиды, формулирует то, о чём другие говорят между строк: запись сессий это не только контроль, но и защита самого администратора, если потом начнётся разбор инцидента.

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

Похожий, но более жёсткий аспект подмечает Илья Куриленко, заместитель генерального директора по развитию компании «Анлим». С одной стороны, фактор внешнего контроля заставляет администраторов работать тщательнее. С другой, он же предупреждает о побочном эффекте, о котором другие эксперты не вспомнили: вместе с дисциплиной растёт и риск саботажа со стороны самих сотрудников. Зато для подрядчиков картина становится прозрачной до уровня действий внутри сессии: «С помощью PAM можно узнать, если сотрудники сторонней организации выходят в интернет с мощностей серверов ».

Похожую логику переводит в плоскость отчётности перед заказчиком Андрей Лаптев, директор по продуктовому развитию Индид. Видеозапись сессии, по его словам, превращается в прямой инструмент проверки реально выполненной работы: «Заказчик в любой момент может посмотреть видеозапись сессии и убедиться в фактически выполненном объеме работ».

На дисциплину как побочный, но осязаемый эффект указывает и Кирилл Левкин, проджект-менеджер MD Audit (SL Soft FabricaONE.AI, акционер ГК Softline). По его наблюдениям, регламентированный доступ снижает риск злоупотреблений, но одновременно требует более высокой собранности от самих администраторов: «В итоге снижается риск злоупотреблений, но возрастает требование к дисциплине».

Автоматизация повторяющихся операций и DevOps

Артём Назаретян, руководитель BI.ZONE PAM, переводит разговор от ограничений к ускорению. По его наблюдениям, при грамотной схеме PAM не тормозит работу, а у команд с развитой инженерной практикой даёт целый набор механик, которые без PAM обычно вынесены наружу.

«В командах с развитой инженерной практикой, например у DevOps-специалистов: появляется возможность контроля второй рукой, многопоточные сессии, проброс сертификатов, запуск Ansible-скриптов через PAM».

На редкое совмещение удобства и контроля указывает Денис Фокин, руководитель отдела технического консалтинга и инженерной поддержки направления ИБ компании Axoft: «PAM-системы сочетают в себе и удобство, и безопасность, что зачастую довольно редкое явление. Грамотно настроенная PAM-система позволяет значительно автоматизировать предоставления нужных привилегий, при этом сохраняя контроль над действиями пользователей».

Игорь Еньков, владелец продукта Innostage PAM Управление привилегированным доступом, напоминает, что PAM не меняет состав задач администратора, а только унифицирует их выполнение и убирает рутину со скрытием паролей и реквизитов: «Сам набор задач у администратора от появления PAM не меняется. Меняется способ работы с критичными системами. Он становится более унифицированным независимо от того, о какой информационной системе идет речь. За счет этого становится меньше рутины в части получения доступов. Уходит головная боль, связанная с хранением и поиском нужных учетных записей, ресурсов, паролей, ключей, адресов и другой информации, необходимой для работы».

Контр-голоса и оговорки

На этом фоне три голоса звучат отдельно. Самый резкий принадлежит Султану Салпагарову, архитектору по информационной безопасности технологической компании Getmobit. Он соглашается с дисциплинирующей ролью PAM, но снимает с системы один из часто рекламируемых пунктов, а именно реакцию на запрещённые действия в реальном времени. По его наблюдениям, такая реакция в практической эксплуатации обычно отключается: «Реагирование на опасные действия «в моменте» не являются достаточно эффективной функциональностью PAM и после нескольких ложных срабатываний обычно отключается».

Двое других смещают фокус ещё дальше и фактически говорят, что для конечного пользователя ничего радикально не меняется. Эльвира Хайретдинова, эксперт УЦСБ, формулирует это так: «Суть работы упомянутых групп пользователей остается неизменной, меняется только механика организации доступа». Замедление от дополнительных шагов через PAM-портал у неё компенсируется психологическим эффектом: «Администратор, который знает, что каждое его действие контролируется, по статистике действует более предусмотрительно, совершает меньше ошибок и не склонен к злоупотреблениям».

На той же стороне стоит Антон Залесский, бизнес-архитектор группы развития продукта Solar SafeInspect ГК «Солар». В его картине PAM при грамотной настройке вообще остаётся почти невидимым для конечного пользователя: «В большинстве случаев изменения касаются только безопасности удаленного доступа и не влияют на сам рабочий процесс».

Когда PAM окупается, а когда становится дорогой формальностью

На вопрос об окупаемости эксперты CISOCLUB не дают единой формулы. Андрей Вонгай, Алексей Ширикалов, Андрей Каганский и Леонид Ломакин прямо уводят разговор от классического ROI к логике предотвращённого ущерба и считают PAM ближе к страховке, чем к инвестиции с прямой возвратностью. Артём Назаретян, напротив, предлагает считать окупаемость через ROI и ROSI. Дальше начинаются расхождения. Любовь Смирнова, Кирилл Левкин и Алексей Ширикалов сходятся на том, что PAM быстрее окупается у крупных компаний с десятками подрядчиков и измеримой стоимостью риска и хуже окупается в небольшой инфраструктуре. Один из спикеров с этим не согласен и утверждает, что небольшая компания с умеренными затратами как раз и получает быструю окупаемость. Полевой кейс с подрядчиком, которого наняли для работ с 1C-сервером, и экспертная цифра срока окупаемости (12-14 месяцев) дополняют картину.

PAM как страховка, классический ROI неприменим

Самую лаконичную формулу даёт Андрей Вонгай (Cloud Networks). Он предлагает вообще отказаться от термина «окупаемость» и говорить об экономической обоснованности через количественную оценку рисков: «В ИБ классическая «окупаемость» неприменима — инвестиции в ИБ не генерируют прибыль, они предотвращают потери от рисков. Корректно оперировать понятием экономической обоснованностью. Главный критерий — размер предотвращаемого ущерба».

В похожем ключе рассуждает Алексей Ширикалов (АйТи Бастион), который прямо сравнивает PAM со страховкой и предлагает раскладывать расчёт на две части — оценку рисков и операционную экономию.

«Окупаемость PAM нельзя считать как у обычного ИТ-продукта: он работает с рисками, а значит часть эффекта гипотетическая. Корректнее рассматривать его в качестве страховки — инвестицию в снижение вероятности дорогого инцидента. При этом оценить потенциальный ущерб и влияние на него вполне возможно. Расчет складывается из двух частей: оценка рисков (вероятность и стоимость последствий) и прямая операционная экономия — снижение ручного труда, ускорение доступа, упрощение аудита и реагирования».

Самую необычную позицию занимает Андрей Каганский (УЦСБ). Он утверждает, что говорить об окупаемости PAM через оптимизацию процессов вообще некорректно, потому что PAM — не средство автоматизации, а средство защиты, и единственный честный критерий тут — это качество внедрения.

«PAM-системы не являются средствами автоматизации в привычном смысле, поэтому говорить об окупаемости за счет оптимизации процессов и снижения операционных расходов будет не совсем корректно. В первую очередь, PAM — это средство защиты. Крайне важно, чтобы внедрение было выполнено опытными и компетентными специалистами, которые учтут все необходимые организационные, технические и методологические меры. В этом случае средства будут потрачены на реальную защиту, а не на её имитацию».

Самый лаконичный аргумент в этой группе у Леонида Ломакина (iTPROTECT): «Быстрее всего PAM «окупится», если предотвратит инцидент, ведь финансовые и репутационные потери могут стоить сильно больше лицензий на PAM».

Сценарии быстрой окупаемости

Чёткий список условий быстрой окупаемости приводит Любовь Смирнова (Контур.Эгида). По её опыту, PAM быстро окупается там, где совпадают сразу несколько факторов риска и где ущерб уже измерим в деньгах: «Быстрее всего PAM окупается там, где у компании много внешних подрядчиков с доступом к критичным системам, где уже был инцидент и ущерб можно посчитать в деньгах, где есть жесткие требования регулятора или где аудит выявил очевидные проблемы вроде неотозванных учеток уволенных сотрудников. В таких случаях решение закрывает конкретный и уже признанный риск».

Конкретный размер компании, у которой PAM окупается быстрее всего, обозначает Кирилл Левкин (MD Audit / SL Soft / ГК Softline). В его опыте это промышленность с большим штатом, и порядок цифр он указывает прямо: «Быстрее всего РАМ окупается в компаниях с большим числом администраторов и подрядчиков (например, промышленность 5-10 тыс. сотрудников). Там высок риск и стоимость инцидента».

Единицу срока окупаемости приводит Дмитрий Симак (NGR Softlab). По его данным из конкретного проекта, расчётный возврат инвестиций укладывается в 12-14 месяцев, и складывается он не из «магии PAM», а из снижения времени ручных проверок и числа повторных инцидентов: «Например, в одном проекте мы увидели, что затраты на PAM окупились за 12-14 месяцев за счет сокращения времени на ручные проверки и уменьшения числа повторных инцидентов».

Алексей Ширикалов (АйТи Бастион) отмечает, что критичны не отдельные параметры, а их одновременное наличие: «Быстрее всего PAM окупается там, где совпадают несколько факторов: высокая концентрация привилегий и критичных систем, активная работа с подрядчиками и удаленным доступом, а также значительные операционные издержки на управление доступами. В таких условиях даже один инцидент может перекрыть стоимость проекта».

Султан Салпагаров (Getmobit) сообщает, что PAM лучше всего окупается там, где автоматизирует уже сложившуюся ручную работу администраторов и ИБ: «PAM эффективно окупается и внедряется в зрелых компаниях с IdM и документооборотом, где работу PAM уже выполняют администраторы домена, сетевые инженеры и информационная безопасность. PAM просто автоматизирует эту работу, внедряясь в уже существующие процессы».

Самый необычный кейс рассказывает Илья Куриленко («Анлим»). Он предупреждает, что чётких метрик окупаемости PAM не существует, но даёт конкретный пример пользы из практики: контроль реально выполненной работы подрядчиков.

«В случае PAM сложно найти четкие метрики для подсчета окупаемости. Скорее в случае работы с администраторами и подрядчиками у тебя появляются дополнительные доводы, чтобы при инциденте сделать свои обвинения менее голословными. Организация наняла подрядчика для модернизации 1C-сервера. По документам заявляется, что работы будут проходить на протяжении 6 дней в неделю командой из пяти человек. А на деле они заходили на сервера один раз в неделю на полчаса. И все это видно через PAM. То есть задекларированный объем работ, который будет переложен в стоимость для заказчика, не соответствует действительности».

Когда PAM не окупается, и почему один эксперт против общего тренда

Любовь Смирнова (Контур.Эгида) формулирует обратный сценарий жёстко. Кроме малой инфраструктуры и формального внедрения, она называет один сюжет, которого нет ни у кого: тяжёлое enterprise-решение, купленное под простую задачу.

«Медленная окупаемость или ее отсутствие обычно связаны с другой картиной. Например, когда инфраструктура относительно небольшая и стоимость владения PAM выше реального масштаба рисков. Или когда решение внедряют формально: часть систем остается вне покрытия, обходные пути сохраняются, а реального контроля не появляется. Плохо окупаются и случаи, когда под простую задачу покупают тяжелое enterprise-решение с избыточной функциональностью».

Тот же риск ресурса на сопровождение подсвечивает Андрей Вонгай (Cloud Networks): «На практике компании часто не готовят ресурсы для полноценной эксплуатации: система внедряется, но не поддерживается, политики не пересматриваются, инциденты не анализируются, и в таких случаях PAM перестаёт эффективно перекрывать риски, внедрение становится экономически нецелесообразным».

Похожую картину описывает Дмитрий Симак (NGR Softlab): «PAM редко оправдывает затраты, если фактический охват мал, администраторы и подрядчики работают в обход системы, а политики доступа строятся базовые, не основываясь на реальных процессах в компании».

Свой жёсткий критерий «всё или ничего» вводит Антон Залесский (Solar SafeInspect, ГК «Солар»). В его картине PAM окупается только при одновременном выполнении трёх условий, и стоит хотя бы одному отвалиться, как затраты становятся неоправданными.

«PAM окупается в том случае, когда у организации и её ИБ-специалистов появляется возможность прозрачно контролировать подключения к ресурсам и полноценно расследовать любые инциденты с достаточной детализацией на основе записанного протокола и без нарушения бизнес-процессов. Если хотя бы одно из этих условий не выполняется или выполняется частично, затраты на внедрение и сопровождение могут оказаться неоправданными».

Против общего тренда прямо высказывается Артём Назаретян (BI.ZONE PAM). Если Смирнова, Левкин и Ширикалов помещают малую инфраструктуру в категорию «не окупается», то Артём Назаретян говорит ровно обратное: при ограниченной инфраструктуре и небольшом числе пользователей затраты на внедрение остаются умеренными, а значит, формальный порог окупаемости проходится. Кроме того, он единственный среди наших собеседников использует термин ROSI (Return on Security Investment — возврат инвестиций в безопасность): «Быстрее всего PAM окупается в ситуациях, где либо относительно невысокий порог входа, либо высока потенциальная цена инцидента. В первом случае речь идет о компаниях с ограниченной инфраструктурой и небольшим числом пользователей, где затраты на внедрение и сопровождение остаются умеренными. Корректная оценка обычно требует более формального подхода — через модели ROI или ROSI, чтобы сравнивать вложения в PAM с финансовым эффектом от снижения рисков и потерь. В целом утверждать, что PAM «не окупается», без подобных расчетов довольно сложно».

Готовы ли российские PAM закрыть сценарии CyberArk

На этот вопрос эксперты CISOCLUB отвечают по-разному, но без алармизма. Большинство сходятся на том, что в типовых on-prem сценариях российские PAM закрывают всё то же, что раньше закрывал CyberArk: ротация паролей, изоляция и запись сессий по RDP и SSH, интеграция с AD. Один из спикеров идёт дальше и говорит, что отечественные продукты в ряде функций уже превзошли западные, особенно в адаптации к российским ОС и службам каталогов. Один из спикеров делает акцент не на функциональности (она у многих сравнима с CyberArk), а на бесшовности перехода, SLA, производительности и поддержке нативных сценариев подключений. Меньшая, но содержательная группа фиксирует разрыв в сложных кейсах: функциональности (хранилище секретов) с автоматической ротацией, управлении привилегиями на конечных точках, нестандартных протоколах, глубоких интеграциях с SIEM и SOAR, поддержке моделей Zero Standing Privileges. Отдельный нефункциональный аргумент добавляет один из спикеров: ключевое преимущество российских PAM сегодня не в функционале, а в сертификате соответствия требованиям ФСТЭК России, без которого аттестация невозможна. Ещё один ракурс добавляет вендор Java-платформы: готовность класса PAM, по его мнению, складывается не только из функций самого продукта, но и из доверенности всей среды исполнения.

Полностью готовы и в чём-то превзошли

Самую жёсткую позицию занимает Андрей Лаптев (Индид). Для него ответ короткий и категоричный, а в качестве аргумента он называет специфические режимы, которых у западных продуктов попросту нет, и приводит конкретную цифру про новых игроков рынка.

«Готовы на 100%. Более того, в ряде аспектов отечественные решения уже превзошли западные аналоги. появились специфические режимы функционирования различных систем, например как, контроль привилегированного доступа в отечественных Linux-системах, режим замкнутой программной среды (ЗПС) в Astra Linux, а также поддержка интеграции с российскими службами каталогов».

К этому Андрей Лаптев добавляет редкий рыночный факт: «За последние несколько лет на рынке появилось 3 новых отечественных разработчика в этой нише».

В том же ключе высказывается Игорь Еньков (Innostage PAM Управление привилегированным доступом). По его наблюдениям, переход заказчиков на отечественные ОС сделал западные PAM-продукты ограниченно применимыми в реальном российском ландшафте: «Российские PAM-решения полностью готовы закрывать такие сценарии. Всё больше заказчиков переходят на отечественные операционные системы и другие инфраструктурные решения. У такой среды есть свои особенности, и западные PAM-продукты с ней либо не работают вообще, либо работают ограниченно, потому что это для них не целевой ландшафт».

Более точечный список преимуществ перечисляет Леонид Ломакин (iTPROTECT). Он соглашается, что базовый функционал есть у всех, но отдельно выделяет четыре направления, по которым отечественные продукты заметно ушли вперёд: «Базовый функционал у всех отечественных PAM-систем уже есть: все они умеют подключаться к корпоративным ресурсам для контроля доступа, записывать видео и текст сессии, регистрировать события, менять пароли. Некоторые вендоры превзошли своих предшественников в таких вещах, как возможность интеграции с различными СЗИ «из коробки», встроенная 2FA с использованием разных факторов, удобный мастер установки, облегченная архитектура».

Антон Залесский (Solar SafeInspect, ГК «Солар») называет российский рынок зрелым, а ключевое преимущество видит в адаптации к местной регуляторике и скорости реакции на новые требования заказчиков: «Российские PAM-решения сегодня — это зрелый рынок. Они изначально ориентированы на отечественные стандарты безопасности и экосистему импортозамещения. отечественные вендоры лучше приспособлены к нашей регуляторике и технологическому ландшафту и готовы оперативно реагировать на новые требования заказчиков».

Не уступают по функциональности, но критичен бесшовный переход

Чуть более осторожную позицию занимает Артём Назаретян (BI.ZONE PAM). Функционально, по его словам, отечественные PAM уже не уступают западным, но настоящая проверка такого тезиса лежит в качестве самого перехода. Производительность, нативные сценарии подключений, SLA по доступности — всё это должно сохраниться на уровне «как раньше», иначе пользователи не примут замещение.

«С точки зрения функциональности российские PAM-решения уже не уступают зарубежным. Однако важно, чтобы переход был бесшовным для пользователей PAM. Это значит, что производительность не должна снижаться, а система должна поддерживать нативные сценарии подключений. Также важно, чтобы SLA по доступности и надежности были аналогичны работе без PAM».

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

В близкой по смыслу позиции стоит Дмитрий Симак (NGR Softlab). По его наблюдениям, ряд российских продуктов уже близок к западным по основным функциям, и перечень функций он даёт прямо: «По функциональности ряд российских PAM-решений уже близок к западным продуктам. JIT-доступ, контроль сервисных учеток, ротация, сессионный мониторинг, интеграция с российскими СЗИ, поддержка Zero-Trust-подходов».

Алексей Ширикалов (АйТи Бастион) не оспаривает зрелость отечественных продуктов, но честно отмечает, что конкурировать по масштабу внедрений с глобальными игроками готовы не все, а развитие сейчас идёт уже не в догонку базовому функционалу, а в сторону комплексного подхода и поведенческой аналитики: «Лидеры российского рынка PAM — зрелые решения, которые закрывают базовые функции: контроль привилегированных доступов, запись сессий, управление учетками. При этом важно сохранять реализм: конкурировать с глобальными игроками по масштабу внедрений готовы не все. Российские вендоры делают ставку на комплексный подход — развивают интеграции, автоматизацию, упрощают работу администраторов и снижают трудозатраты. Отдельно развивается поведенческая аналитика и выявление аномалий».

Где разрыв с CyberArk ещё ощутим

Детальный список пробелов даёт Любовь Смирнова (Контур.Эгида). По её опыту, российские PAM уже хорошо закрывают типовые сценарии on-prem (SSH, RDP, HTTPS, изоляция и проксирование, временный доступ для подрядчиков, базовая интеграция с AD, аудит), но до уровня зрелости западных лидеров не дотягивают сразу по четырём направлениям: «Если сравнивать с тем уровнем зрелости, который давали CyberArk и другие крупные западные игроки, разрыв все еще сохраняется. В первую очередь это касается функциональности с автоматической ротацией паролей, сценариев управления привилегиями на конечных точках, поддержки нестандартных протоколов и глубоких интеграций с SIEM и SOAR».

В похожем ключе высказывается Никита Блинов, ведущий пресейл-инженер Cloud Networks. В традиционной on-prem-инфраструктуре с Windows Server, Linux и Active Directory российские PAM, по его данным, в полной мере покрывают сценарии CyberArk, и это подтверждают практика на объектах ОПК и КИИ. Но как только разговор уходит в Zero Standing Privileges (модель «нулевых постоянных привилегий») и Just-in-Time доступ через API-интеграции, западные продукты ушли вперёд: «В сегменте традиционной on-premise инфраструктуры с преобладанием Windows Server, Linux, Active Directory российские PAM-продукты в полной мере покрывают ключевые сценарии, ранее реализуемые CyberArk. Но при выходе за пределы классических сценариев возникают ограничения. С другой стороны, западные решения, такие как CyberArk, BeyondTrust, сегодня эволюционировали в сторону моделей Zero Standing Privileges и Just-in-Time доступа, где акцент смещен с хранения постоянных учетных записей на динамическую выдачу короткоживущих прав через API-интеграции».

Кирилл Левкин (MD Audit / SL Soft / ГК Softline) соглашается, что в базовых сценариях разрыва уже нет, но фиксирует три зоны, где он сохраняется и постепенно сокращается: «В базовых сценариях они вполне готовы: управление доступом, запись сессий, контроль привилегий закрываются. Сложности остаются в масштабировании, UX и глубокой интеграции с разнородной инфраструктурой. Однако разрыв постепенно сокращается за счет доработок и проектов внедрения».

Султан Салпагаров (Getmobit) отмечает, что для него вся разница сводится к одному критерию — числу поддерживаемых систем и коннекторов: «Эффективность PAM это прежде всего количество поддерживаемых систем, коннекторы. Я не знаю решений, перекрывающих западные решения именно по этому признаку. Всё остальное плюс-минус одинаково».

Илья Куриленко («Анлим») напоминает, что фундаментально западные и отечественные PAM устроены одинаково, а вся разница лежит в глубине автоматизации. И эта разница критична только для крупных предприятий, тогда как для SMB её попросту нет: «Фундаментально принцип работы у западных и отечественных PAM-решений одинаковый, идентичные требования к внедрению и результату. Разница только в глубине аналитики и автоматизации принятия решений. подобный функционал важен для enterprise-предприятий, которые в силу масштаба без автоматизации не в состоянии оперативно реагировать на инциденты. А на базовом уровне, то есть для малого и среднего бизнеса, разницы между западными и отечественными решениями нет никакой».

Сертификат ФСТЭК России и готовность всего стека

Отдельный, не функциональный, а сертификационный аргумент вносит Эльвира Хайретдинова, эксперт УЦСБ. По её опыту, ключевое преимущество отечественных PAM лежит не в самих функциях, а в сертификате соответствия требованиям ФСТЭК России, без которого аттестация по требованиям безопасности информации просто невозможна. Кроме того, она единственная отмечает, что российский рынок неоднороден и сравнивать «отечественный PAM» как монолит с CyberArk некорректно: «Современные отечественные PAM-системы способны эффективно удовлетворять большинство требований бизнеса, касающихся контроля привилегированных категорий пользователей и защиты удаленного доступа. При необходимости прямого сравнения с зарубежными аналогами важно корректно определить критерии, поскольку даже в рамках российского рынка продукты имеют значительные функциональные различия. Ключевым преимуществом большинства отечественных решений является сертификат соответствия требованиям ФСТЭК России, который необходим для аттестации предприятий и является гарантом безопасности».

Алексей Кузнецов, директор по работе с партнерами Axiom JDK смотрит на тему не с позиции PAM-вендора, а с позиции поставщика российской Java-платформы и серверов приложений. Готовность класса PAM в его картине складывается не только из функций самого продукта, а из доверенности всего технологического стека, в котором PAM работает: «Заказчикам нужны не просто функциональные продукты, а доверенные и совместимые компоненты, которые можно использовать в защищённых контурах как полноценную альтернативу Open Source-компонентов без поддержки и зарубежному техстеку. рынок движется от простой замены отдельных зарубежных продуктов к формированию полноценной доверенной и защищенной экосистемы, где безопасность обеспечивается на всех уровнях, начиная со среды исполнения и серверов приложений и заканчивается бизнес-логикой».

Может ли отдельный PAM раствориться в IdM, SIEM и endpoint-решениях

Исчезновение PAM как отдельного класса не пугает экспертов CISOCLUB, но и сценарий замещения они описывают по-разному. Часть наших собеседников считает, что замещение функциями IdM, SIEM и endpoint теоретически возможно при совпадении нескольких жёстких условий, на практике пока не складывающихся, причём один из спикеров отдельно оговаривает, что в большинстве российских enterprise-компаний с унаследованной инфраструктурой отдельный PAM ещё долго будет востребован. Один эксперт отвечает категоричным «никогда», ещё несколько мягче настаивают, что задача защиты привилегированного доступа не покрывается ни одним из смежных классов. Третья группа уверена, что PAM не исчезнет, а растворится в более широких платформах вроде Identity Security или гипотетического «PAM 2.0», и напоминает про покупку CyberArk одной из IdM-компаний. И только один из 14 ответивших смотрит с обратной стороны: PAM, как функцию можно собрать из других классов СЗИ, как из «кубиков».

Условия теоретического замещения

Список таких условий приводит Любовь Смирнова, менеджер сервиса PAM от Контур.Эгиды. По её формулировке, сценарий замещения возможен только при совпадении сразу трёх жёстких предпосылок, и в большинстве российских компаний с унаследованной инфраструктурой все три не выполняются. UEBA в третьем условии — это User and Entity Behavior Analytics, поведенческий анализ пользователей и инфраструктуры. «Во-первых, система управления идентификацией должна уметь работать с жизненным циклом привилегированных учетных записей так же хорошо, как с обычными, включая сервисные и технические аккаунты. Во-вторых, инфраструктура должна быть почти полностью покрыта endpoint-агентами, без большого числа legacy-систем, сетевого оборудования и промышленных сегментов. В-третьих, SIEM или UEBA должны быть достаточно зрелыми, чтобы выявлять аномалии в привилегированных действиях без отдельной изоляции сессий».

Свой вывод Любовь Смирнова дополняет ремаркой про вектор движения рынка. Сценария исчезновения PAM она не видит, рынок идёт не по этому пути: «Скорее рынок пойдет не по пути исчезновения PAM, а по пути его встраивания в более широкие платформы».

На том же фокусе настаивает Андрей Вонгай, ведущий пресейл-инженер Cloud Networks. В его картине отдельный PAM перестаёт быть нужен тогда, когда привилегированный доступ перестаёт существовать как самостоятельный функциональный блок и становится частью более широких систем.

«Отдельная PAM-система перестает быть необходимой, когда управление привилегированным доступом перестает существовать как изолированный функциональный блок и становится встроенной, неотъемлемой частью более широких систем управления сущностями/пользователями, мониторинга безопасности и защиты конечных точек».

Ту же мысль излагает Кирилл Левкин, проджект-менеджер MD Audit (SL Soft FabricaONE.AI, акционер ГК Softline): «Это возможно, если IdM, SIEM и endpoint-решения обеспечат полноценный контроль сессий, управление доступом и аудит в одном контуре. Но на практике такие функции пока фрагментированы. Отдельный PAM остается востребованным там, где критична глубина контроля и соответствие требованиям ИБ».

Антон Залесский, бизнес-архитектор группы развития продукта Solar SafeInspect ГК «Солар» включает в перечень не только функции, но и нагрузочные требования к замещающему продукту: «Это возможно лишь в том случае, если сторонний продукт (IdM, SIEM или endpoint-решение) полностью закроет все ключевые функции PAM: запись сессий с достаточной детализацией, контроль действий привилегированных пользователей, возможность реагировать на инциденты прямо внутри сессии, а также обеспечит нужную производительность в сложных сетевых условиях».

PAM как класс задачи, который нечем заменить

Самую категоричную позицию занимает Андрей Лаптев, директор по продуктовому развитию Индид. Для него ситуация, при которой отдельный PAM станет не нужен, не наступит никогда, а сама постановка вопроса основана на смешении классов задач: «На мой взгляд, такая ситуация не наступит никогда. Контроль привилегий сфокусирован на пользовательских учетных записях и не решает задачу защиты привилегированного доступа».

Если Андрей Лаптев опирается на разницу классов, то Дмитрий Симак (NGR Softlab) отталкивается от конкретного списка сценариев, которые не сможет закрыть никакой IdM или endpoint. Сервисные учётные записи, тысячи SSH-ключей, токены доступа, A2A-пароли, СУБД, большие команды подрядчиков. Каждый из этих случаев в его опыте остаётся за PAM.

«PAM останутся востребованным там, где есть сложные сценарии привилегированного доступа — сервисные учетные записи, управление тысячами SSH-ключей, токенов доступа, паролей приложений A2A (Application-to-Application), поддержка доступа к СУБД, работа большого числа подрядчиков и т.п. В этих случаях IdM и endpoint-решения ничем не смогут помочь».

Близко по смыслу высказывается Артём Назаретян (BI.ZONE PAM). Он не отрицает, что функции PAM можно распределить между другими продуктами, но указывает, что у такого решения есть цена: «Средства защиты дополняют друг друга, но не заменяют. Отказ от PAM в зрелой инфраструктуре почти невозможен. Его функции можно распределить между другими продуктами, но это приведет к потере целостного контроля, росту операционных рисков и увеличению затрат на сопровождение».

Денис Фокин (Axoft) соглашается, что мониторинг подключений можно выстроить через SIEM или EDR, но эти инструменты не закрывают саму задачу предоставления доступа: «Это решения разного класса. Объективно можно реализовать контроль подключений с помощью и SIEM, и EDR. Но это будет не так гибко, эффективно и удобно, чем через PAM. И точно эти продукты не решают вопрос непосредственно предоставления доступа, а дают лишь ограниченный, в сравнении с PAM, мониторинг».

Алексей Ширикалов (АйТи Бастион) предлагает иной критерий избыточности PAM. Для него PAM становится избыточным не тогда, когда отдельные функции появляются в других продуктах, а когда вся система ИБ в целом обеспечивает сопоставимый уровень контроля действий привилегированных пользователей.

«PAM решает конкретную задачу — контроль действий привилегированных пользователей, и работает в связке с другими элементами ИБ. PAM становится избыточным не тогда, когда аналогичные функции реализуются в других продуктах, а когда вся система безопасности способна обеспечить сопоставимый уровень контроля без него».

Замыкает группу Леонид Ломакин (iTPROTECT) с напоминанием, что PAM это не набор отдельных функций, а единый контур работы с привилегированными учётными записями: «Это решение, которое объединяет в единый контур управление функциями доступа и выстраивает полный процесс работы с привилегированными учетными записями: от их обнаружения в инфраструктуре до своевременной выдачи и отзыва доступа, от детального мониторинга видеозаписей и текстового лога сессий до приведения парольной политики в соответствии с требованиями ИБ».

Identity Security и гипотетический PAM 2.0

Третья группа экспертов смотрит на ту же картину иначе. PAM не исчезнет и не сохранится в нынешнем виде, а станет модулем более широкой платформы. Самую яркую гипотезу здесь предлагает Игорь Еньков (Innostage PAM Управление привилегированным доступом). Он напоминает, что отдельные вендоры уже идут по этому пути, и приводит конкретный пример: «При текущей архитектуре IdM, SIEM и endpoint-решений практически нереально, что РАМ как отдельный класс перестанет существовать. Каждый из этих классов решает свою основную задачу (управление идентичностями, корреляция событий, защита конечных точек/контроль пользователей), и добавление полнофункционального PAM — это, по сути, создание отдельного продукта внутри их платформы. Некоторые идут по этому пути (например, CyberArk купили IdM-компанию и сделали отдельный модуль). Пока ни один вендор не смог органично объединить всё без потери качества».

Гипотетическое условие исчезновения отдельного PAM Игорь Еньков описывает как появление платформы следующего поколения, которая объединит IdM, SIEM, EDR и PAM в едином агенте: «Но это будет уже не IdM, не SIEM и не EDR — это будет новый класс систем, и вполне вероятно, что его назовут «PAM 2.0».

Похожий тренд, но без термина «PAM 2.0», описывает Андрей Каганский (УЦСБ). Он называет единую экосистему «Identity Security» и формулирует, что переход функций PAM в смежные классы для него не событие исчезновения, а эволюция: «Наблюдается тренд на объединение решений, направленных на управление доступом и защиту учетных данных, в единую экосистему Identity Security. И если в будущем функции записи сессий, контроля JIT-доступа, перехвата и блокировки команд, ротации паролей сервисных учетных записей перетекут в решения другого класса, то это будет лишь свидетельствовать об эволюции PAM из отдельного решения в модуль более широкой платформы, что никак не отразится на востребованности и актуальности функционала».

Историческую перспективу к этому добавляет Илья Куриленко (Анлим). Он напоминает, что то же самое уже происходило с другими классами СЗИ.

«Например, в SIEM добавляется функционал SOAR, IRP, UEBA; в антивирусы — персональные МЭ и СОВ, средство контроля носителей, шифрования дисков и патч менеджмента. Границы между классами СрЗИ постоянно размываются. И PAM не является исключением».

Контр-голос: PAM можно собрать из других систем

Другого мнения придерживается Султана Салпагарова (Getmobit). Он не пугает рынок исчезновением PAM и не защищает класс от смежных решений. Его тезис прямой: PAM как функцию уже сейчас можно собрать из IdM, EDR, SIEM и DLP. Цена решения тоже обозначена честно: «Можно собрать такой PAM из других систем безопасности и это сделает отдельную систему ненужной. «PAM на IdM», «PAM на EDR», «PAM на SIEM» или «PAM на DLP» — в зависимости от того, какие инструменты у вас внедрены, какие «смежные» функции в них реализованы и насколько эффективна их оркестрация. Так или иначе, все это путь компромиссов и избыточности».

Заключение

На вопросе о причинах внедрения PAM эксперты CISOCLUB сходятся в двойной формуле «зрелость или инцидент». В первую группу укладываются ответы Андрея Вонгая (Cloud Networks), Любови Смирновой (Контур.Эгида), Кирилла Левкина (MD Audit), Андрея Лаптева (Индид), Владимира Арышева (STEP LOGIC), Алексея Ширикалова (АйТи Бастион), Дмитрия Симака (NGR Softlab), Игоря Енькова (Innostage PAM), Леонида Ломакина (iTPROTECT), Андрея Каганского (УЦСБ), Артёма Назаретяна (BI.ZONE PAM) и Антона Залесского (Solar SafeInspect, ГК «Солар»). Реактивный сценарий с шифровальщиком, утечкой через сервисную учётку или уволенным администратором ярче других описывает Любовь Смирнова, конкретную долю «75% проектов после инцидента или пентеста» приводит Владимир Арышев. Свою точку зрения высказывает Султан Салпагаров (Getmobit): осознанный заход начинается там, где у большого числа администраторов в руках концентрируются «золотые ключи», а вынужденный — после первой реальной утечки, когда у бизнеса появляются метрики стоимости защиты против цены инцидента. Илья Куриленко (Анлим) добавляет три нестандартных драйвера: точечную ссылку на приказ ФСТЭК России № 117 (комплаенс как драйвер встречается и у других, но конкретного приказа нет ни у кого), использование PAM как доказательной базы в дисциплинарных и судебных разбирательствах и «паранойя» руководителя на фоне аномалий. Контр-аргумент приводит Денис Фокин (Axoft), который считает, что инцидент сравнительно редко становится триггером именно для PAM, и драйвером называет сложившуюся культуру удалённой работы.

На вопросе об ошибках внедрения 15 ответивших разошлись на несколько групп. Девять экспертов сходятся в том, что PAM работает только тогда, когда становится единственным технически возможным путём к привилегированному доступу. Любовь Смирнова отмечает инженерный список альтернативных входов (RDP, SSH, локальные администраторы, сохранённые пароли, сервисные аккаунты), Леонид Ломакин называет NGFW и смену паролей целевых систем, Эльвира Хайретдинова (УЦСБ) добавляет внешний syslog-сервер и требование скрывать пароль от самого сотрудника. Илья Куриленко предупреждает, что администраторы при желании построят реверс-прокси сами. Отдельный технический мотив обхода — отсутствие автоматической ротации паролей привилегированных учёток называют Артём Назаретян, Антон Залесский и Илья Куриленко. Неудобство и UX-задержки как драйвер обхода отмечают Любовь Смирнова, Кирилл Левкин, Артём Назаретян, Андрей Вонгай и Султан Салпагаров (Getmobit), причём именно Султан Салпагаров отдельно называет редкий мотив обхода: «забытые» учётные записи остаются как сознательный резерв на случай отказа самой PAM. Организационный блок звучит у двух спикеров. Денис Фокин утверждает, что главная ошибка не техническая, а политическая, попытка ИБ контролировать ИТ через голову. Игорь Еньков главной ошибкой называет отсутствие согласованности внутри заказчика, отсутствие управления изменениями и отсутствие обучения сотрудников.

На вопросе о переходе пилота в продуктивную эксплуатацию из 13 ответивших содержательно к теме обращаются 12, ответ Алексея Кузнецова (Axiom JDK) касается доверенности технологического стека и логичнее ложится в дискуссию о готовности рынка. Условие «бизнес-владелец с реальными полномочиями» называют Андрей Вонгай и Любовь Смирнова, а формулу «от политики к архитектуре и далее к внедрению» в чистом виде даёт только Андрей Вонгай. Также Смирнова отдельно указывает на необходимость спонсора на C-level, без которого проект застревает. Реальную инфраструктуру вместо синтетического стенда требуют Дмитрий Симак с конкретным ориентиром «50–100 серверов и 2–3 критичных системы», Алексей Ширикалов с оппозицией «пилот как демонстрация против пилота как трансформации» и Илья Куриленко с прямым диагнозом «синтетическая среда». Самую строгую формулу приводит Игорь Еньков: «Во многих внедрениях пилот ломается не об интеграции, а об отношение людей к изменениям». К той же теме людей и согласования примыкают Андрей Каганский с необходимостью консенсуса с ИТ-подразделениями, Артём Назаретян с трёхуровневой моделью «цели — процесс — пользователи», Кирилл Левкин с тезисом про приоритизацию критичных систем, Леонид Ломакин с акцентом на предпроектное обследование и Антон Залесский с упором на компетенции ИБ-специалистов на стороне заказчика. Короткую формулу «PAM считается работающим, только когда полностью замещает прямой доступ» приводит Султан Салпагаров.

На вопросе о том, как PAM меняет работу администраторов и подрядчиков, 14 экспертов выстраиваются в несколько групп. Об исчезновении постоянных привилегий и переходе к доступу по запросу через единый шлюз говорят Никита Блинов (Cloud Networks), Дмитрий Симак, Алексей Ширикалов и Леонид Ломакин. Автоматическую ротацию паролей после каждой сессии как отдельный механизм называет в этой группе только Никита Блинов. Единственную среди собеседников количественную метрику приводит Дмитрий Симак: «Администратор получил доступ за 10 минут вместо часа-полтора ручного согласования». Тему прозрачности и защиты самого администратора при разборе инцидента уникально формулирует Любовь Смирнова, к ней с разных сторон примыкают Илья Куриленко с побочным наблюдением о росте саботажа внутреннего персонала, Андрей Лаптев с возможностью проверки фактического объёма работ подрядчика по видеозаписи и Кирилл Левкин с тезисом про возросшее требование к дисциплине. DevOps-специфику с контролем «второй рукой», многопоточными сессиями, пробросом сертификатов и запуском Ansible-скриптов через PAM описывает только Артём Назаретян, а Денис Фокин и Игорь Еньков добавляют тему упрощения работы и снятия рутины в хранении учётных данных. Отдельно выделяются три эксперта. Султан Салпагаров говорит, что реакция «в моменте» на запрещённые действия в практической эксплуатации обычно отключается из-за ложных срабатываний. Эльвира Хайретдинова и Антон Залесский утверждают, что для конечного пользователя суть работы остаётся прежней, меняется только механика доступа.

Из 11 ответов о вопросах окупаемости первый общий тезис, что классический ROI к PAM неприменим, а его корректнее считать страховкой от дорогого инцидента, поддерживают Андрей Вонгай, Алексей Ширикалов, Андрей Каганский и Леонид Ломакин. Сценарии быстрой окупаемости с большим числом подрядчиков, концентрацией привилегий и конкретной отраслью «промышленность 5-10 тысяч сотрудников» отмечают Любовь Смирнова, Кирилл Левкин и Алексей Ширикалов. Единственную цифру срока окупаемости «12-14 месяцев» в одном из реальных проектов приводит Дмитрий Симак. Илья Куриленко рассказывает уникальный полевой кейс с подрядчиком 1С-сервера, у которого реальный объём работы оказался в десятки раз меньше задекларированного, и видит в этом отдельный сценарий пользы PAM. Андрей Каганский предлагает не считать PAM средством автоматизации и оценивать его не через окупаемость, а через качество внедрения, «реальную защиту, а не её имитацию». Жёсткое условие «всё или ничего» (прозрачный контроль, полноценное расследование, без нарушения бизнес-процессов) формулирует Антон Залесский. Прямое возражение этой группе даёт Артём Назаретян: он единственный среди наших собеседников использует термин ROSI и утверждает, что небольшая инфраструктура с умеренными затратами как раз попадает в сценарий быстрой окупаемости, тогда как Смирнова, Левкин и Ширикалов относят малый размер к признакам «не окупается». Тонкий нюанс «тяжёлое enterprise-решение под простую задачу» как отдельную причину провала добавляет Любовь Смирнова. Отдельный сценарий окупаемости отмечает Султан Салпагаров: PAM окупается там, где автоматизирует уже сложившуюся ручную работу администраторов, сетевых инженеров и службы ИБ в зрелых компаниях с IdM и документооборотом, а в незрелой среде эти процессы приходится сначала строить.

На сравнении с CyberArk из 14 ответивших позицию «полностью готовы или превзошли» занимают Андрей Лаптев с категоричной формулировкой «100%, в ряде аспектов превзошли западные» и Игорь Еньков с тезисом «российские PAM полностью готовы закрывать такие сценарии». Не уступают по функциональности с оговоркой про бесшовный переход, SLA, производительность и нативные сценарии подключений говорит Артём Назаретян. О близости российских PAM к западным по основным функциям (JIT, контроль сервисных учёток, ротация, сессионный мониторинг, поддержка Zero Trust) сообщает Дмитрий Симак. Алексей Ширикалов уравновешивает оптимизм оговоркой, что конкурировать по масштабу внедрений с глобальными игроками готовы пока не все российские вендоры. Базовый функционал у всех уже есть и отдельные вендоры превзошли своих предшественников по интеграциям из коробки и удобству установки, фиксирует Леонид Ломакин, добавляя, что российским PAM проще работать в отечественной инфраструктуре. Похожий ракурс «зрелый рынок, изначально ориентированный на отечественные стандарты, лучше приспособлен к регуляторике и технологическому ландшафту» приводит Антон Залесский. Практический кейс замещения иностранного решения отечественным приводит Артём Назаретян, ссылаясь на проект у одного из крупнейших российских заказчиков. Группа «закрывают базовые сценарии, но есть пробелы» включает Никиту Блинова, Любовь Смирнову и Кирилла Левкина. Самый детальный список из четырёх групп пробелов, функциональность с автоматической ротацией, управление привилегиями на конечных точках, нестандартные протоколы и глубокие интеграции с SIEM и SOAR, отчечает Любовь Смирнова. Неожиданную позицию «вся разница в количестве коннекторов» вводит Султан Салпагаров. Илья Куриленко сегментирует ответ по размеру бизнеса, фундаментально различий нет, а в глубине автоматизации они критичны для крупных предприятий и не критичны для SMB. Эльвира Хайретдинова добавляет нефункциональный аргумент про сертификат соответствия требованиям ФСТЭК России, без которого аттестация невозможна, и оговаривает, что российский рынок неоднороден. Другую позицию занимает Алексей Кузнецов, он считает, что готовность класса PAM складывается не только из функций самого продукта, а из доверенности всего технологического стека.

На вопросе о растворении PAM в IdM, SIEM и endpoint из 14 ответивших образуются три большие группы и один контр-голос. Сценарий «возможно при совокупности жёстких условий, но в реальности нескоро» формулируют Андрей Вонгай, Любовь Смирнова с тремя условиями, Кирилл Левкин и Антон Залесский со своим списком требований к замещающему продукту. Категоричное «такая ситуация не наступит никогда» формулирует только Андрей Лаптев. Рядом с ним стоит группа из пяти спикеров с условной незамещаемостью PAM, без слова «никогда», но с неустранимыми сценариями. Дмитрий Симак приводит перечень случаев, в которых PAM остаётся востребованным (сервисные учётные записи, тысячи SSH-ключей, A2A, СУБД, подрядчики), и говорит, что PAM может начать терять смысл только если смежные системы возьмут на себя весь этот спектр. Артём Назаретян формулирует это как «отказ от PAM в зрелой инфраструктуре почти невозможен». Денис Фокин разделяет классы решений и считает, что SIEM и EDR не так гибки и не решают задачу выдачи доступа. Алексей Ширикалов сдвигает критерий: PAM становится избыточным только тогда, когда вся система ИБ в целом обеспечивает сопоставимый уровень контроля. Леонид Ломакин описывает PAM как «единый контур» жизненного цикла привилегированных учётных записей, без которого функции расползаются. Третья группа уверена, что PAM не исчезнет, а растворится в более широких платформах вроде Identity Security или гипотетического PAM 2.0, и в неё входят Игорь Еньков с термином «PAM 2.0» и единственным среди собеседников фактом про покупку CyberArk одной из IdM-компаний, Андрей Каганский с термином Identity Security и Илья Куриленко с историческими параллелями размывания классов СЗИ. Контр-аргумент принадлежит Султану Салпагарову: он единственный считает, что PAM как функцию уже сейчас можно собрать из IdM, EDR, SIEM и DLP «как из кубиков», хотя и признаёт это «путём компромиссов и избыточности».

PAM работает не сам по себе, а как часть решения, в котором закрыты все альтернативные пути доступа, выстроены процессы и согласована позиция администраторов. Достаточно одного незакрытого канала, одной общей сервисной учётки без ротации, одного непрояснённого бизнес-владельца или одного ИТ-подразделения, негласно сопротивляющегося внедрению, и любая современная PAM-система превращается в дорогую формальность.

Российский PAM в 2026 году уже закрывает большинство on-prem сценариев, хотя пробелы по функциональности, управлению привилегиями на конечных точках, нестандартным протоколам и глубоким интеграциям с SIEM и SOAR никуда не делись. Не менее важным становится другой вопрос: готова ли организация на стороне заказчика убрать обходные пути, договориться внутри ИТ и ИБ и пропустить доступ к критичным системам через один шлюз. Где это сделано, у PAM есть шанс окупиться. Где не сделано, ни одна архитектура сама по себе не справится.