Всем привет! Сегодня хочу затронуть «стыдную» тему – то, о чем ни вендоры, ни интеграторы, ни даже сами заказчики на уровне менеджмента обычно не говорят.
Привилегированные пользователи ненавидят PAM.
Предлагаю разобраться, почему это так, и что тут можно улучшить.
Отвечая на вопрос, сформулированный в названии статьи, я бы выделил три основные проблемы, возникающие при использовании PAM:
– Отрицательное влияние PAM на UX;
– Восприятие PAM как инструмента слежки;
– Проблемы с надежностью.
Давайте разберем каждую из них подробнее.
Влияние на UX
Я давно обратил внимание: знакомясь с новой для себя PAM-системой, опытный, матерый, администратор, почти всегда задает вопросы, нацеленные на то, чтобы оценить удобство пользователей. Все потому, что PAM-системы сильно влияют на UX. Вот несколько ярких примеров того, как это иногда бывает:
– Необходимость для работы с защищаемыми ресурсами применять на АРМ какие-то агенты/клиенты от вендора PAM (либо вовсе – безальтернативное использование браузера в качестве административного клиента);
– Не поддерживаются, либо требуют от пользователя дополнительных телодвижений часть обычных для администратора операций, таких как передача файлов, работа с буфером обмена, sudo и т.п. (в наиболее одиозных ситуациях – буфер обмена работает только в одном направлении из-за того, что сессия транслируется как поток графики);
– «Лишние» и лишние шаги при доступе к ресурсу. Иногда пользователей может в принципе раздражать необходимость зайти в ЛК или предъявлять второй фактор – все-таки тут больше действий, чем при простом подключении, скажем, по SSH или RDP. Но бывает и так, что у вендора не пробрасываются «креды» и состояние аутентификации: зашел пользователь в личный кабинет, предъявил «креды», выбрал ресурс для доступа – и на каком-нибудь шлюзе/прокси/jump ему опять надо предъявлять те же «креды». В числе моих «любимых» – накладываемая на пользователя обязанность указать причину, по какой нужен доступ. Как правило, в реальной практике туда пишут нечто вроде: «Работа». Как эта информация используется потом – остается только гадать;
– Из-за плохой масштабируемости либо незрелости PAM возникают проблемы с производительностью: лаги, фризы, непредсказуемо «рвутся» сессии.
В результате у пользователя возникает ощущение, что он борется с PAM-системой, «выбивая» у нее право сделать свою работу. С другой стороны, абсолютно бесплатной (с точки зрения удобства работы пользователей) ИБ не бывает. Поэтому некоторые вещи, из тех, что я указал выше, «не лечатся» без серьезных компромиссов с совестью ИБ либо «не лечатся» вовсе. Разумным разменом мне представляется:
– Поддержка стандартных клиентов для взаимодействия с защищаемыми системами (для основных протоколов – без промежуточных терминальных серверов);
– SSO, в т. ч. в условиях применения многофакторной аутентификации;
– Развитые возможности по масштабированию системы (куда без этого!);
– Наличие в Личном кабинете привилегированного пользователя возможности организовать удобное рабочее пространство: избранное, последние подключения и др.;
– Конечно, отсутствие навязываемых пользователю лишних, искусственных шагов при установке привилегированных сессий.
Хорошим тоном, по моему мнению, будет наличие на шлюзах/прокси пользовательских интерфейсов с селекторами ресурсов для подключения и возможностью здесь же, при необходимости, пройти аутентификацию – свойство системы, позволяющее «админам» подолгу не заглядывать в Личный кабинет PAM.
PAM как инструмент слежки
Второй по распространенности причиной негатива в сторону PAM является укоренившееся мнение пользователей о том, что системы этого класса применяют для слежки за ними. Есть ли у пользователей объективные предпосылки так думать? У нас «стыдная» сегодня тема, помните? Никакой слежки (обычно) нет, но предпосылки для тревоги есть! Современная PAM-система обязательно записывает тем или иным способом действия пользователей, многие вендоры применяют разнообразные средства автоматического контроля действий пользователей (вплоть до AI, как например, в Avanpost SmartPAM:)), продвинутые решения еще и оснащены различными аналитическими инструментами для работы с записями. Объективная, основанная на возможностях PAM, обеспокоенность пользователей зачастую усугубляется безаппеляционным подходом ко внедрению и закрытостью информации о характере ее применения.
Конечно, упомянутый арсенал «шпионских» средств создают и развертывают для контроля, а не ради слежки (для которой есть специализированные классы ПО).
Однако компромисса между беспокойством пользователей и задачами ИБ, достижимого сугубо техническими средствами, я в данном случае не вижу. В моем понимании, противоречие тут скорее психологическое. Поэтому обозначу организационные решения, способные купировать остроту проблемы:
– Допуск к записям и аналитике сессий ограниченного круга лиц, исключительно из числа ответственных за ИБ;
– Открытость информации о применении PAM, о сохранении записей сессий, о регламенте доступа к ним;
– Плавное с точки зрения пользователей внедрение PAM, предусматривающее «просветительскую работу» , нацеленную на разъяснение принципов работы системы и ее назначения;
– Информирование пользователей об инцидентах, предотвращенных с помощью PAM.
На последней мере остановлюсь подробнее. Нередко выносить сор из избы – последнее, что хотят делать службы ИБ в отношении инцидентов. Вспомним, однако, что пользователи PAM – привилегированные. Т. е., в их непосредственной зоне интересов находится обеспечение бесперебойной работы ИТ-систем. Следовательно, если они будут видеть, что PAM помогает достигать эту цель, то и отношение к нему можно ожидать более толерантное.
О надежности PAM
В обсуждениях вопрос о надежности PAM часто сводят к наличию либо отсутствию кластера. Это представляется опасным упрощением.
Представим ситуацию: упала Active Directory. Очевидно, ее надо импортозамещать чинить. Коллектив администраторов пытается подключиться к контроллеру домена через PAM, но… не может там аутентифицироваться, потому что аккаунты PAM доменные, а домен сломан по условию задачи.
Что нужно, чтобы успешно справиться с такой ситуацией? Процедуры и механизмы «Break glass» – как в самом продукте, так и на уровне его развертывания и эксплуатации. Я бы отметил следующее:
– Встроенные (внутренние) учетные записи привилегированных пользователей – это сработает на 100% в нашем примере, а еще даст возможность оперативно организовать работу специалистов из внешних организаций, привлекаемых к устранению аварий, развивающихся по более прозаическим сценариям;
– Выдача привилегированного доступа на время – чтобы дать «аварийной партии» выполнить свою работу без изменения основных политик доступа;
– Возможность откатиться к старой версии хранимых в PAM секретов от привилегированных УЗ (на случай восстановления аварийного сервиса из бэкапа).
– При внедрении опасно выбирать конфигурации, которые исключают привилегированный доступ в обход PAM за счет модернизации сетевой инфраструктуры (вместо передачи владения секретами от пользователей к PAM). С другой стороны, вендор должен предоставлять возможность быстро и гарантировано «вытащить» из аварийной системы секреты.
«Break glass» не должна быть теоретической, «бумажной» процедурой: служба технической поддержки должна иметь доступ к инструментам восстановления работоспособности системы и к механизмам «Break glass», а также владеть соответствующим инструментарием.
Рассмотрим обратную ситуацию: инфраструктура работает прекрасно, вышел из строя сам PAM. В этом случае привилегированные пользователи не могут делать свою обычную работу. Казалось бы, ответом вот на эту ситуацию как раз и является кластер. Однако:
– У разных вендоров существенно отличаются топологии и возможности кластера (например, не все компоненты могут иметь режим Active-Active, могут существовать неудобные/непригодные для ряда инфраструктур ограничения на количество узлов определенного типа);
– Важно не только один раз развернуть и проверить кластер, но и организовать периодические проверки его работоспособности;
– Отнюдь не всякий фатальный отказ компенсируется механизмами кластера. Имеют место отказы вида «Сервис перезагружается по кругу», «Загрузка CPU 100% и не падает» и т.п. Поэтому PAM (как и всякий критичный сервис) должен быть поставлен на мониторинг и резервное копирование. Важно, считаю, чтобы это были общекорпоративные сервисы (система должна быть с ними совместима на 100%). «Местные» решения в экстренной ситуации могут подвести, например, из-за отсутствия на месте нужного специалиста или неадекватным ситуации показателям RPO либо RTO.
Закончу сегодняшнюю «стыдную» тему особо «стыдным» организационным аспектом, о котором говорят только шепотом. Дело в том, что PAM, как правило, находится во владении и в зоне ответственности службы ИБ. А пользуются им, преимущественно, представители ИТ. Если одни с другими дружат плохо – даже качественная, зрелая, правильно внедренная PAM-система может стать линией разлома.
Что же с этим делать?
Организовать совместное управление PAM-системой со стороны ИБ и ИТ.
Внедрение PAM неизбежно затрагивает рабочие процессы администраторов: меняется способ подключения, появляются дополнительные проверки, иногда ломаются привычные сценарии работы. Если эти изменения навязываются исключительно со стороны ИБ, система почти неизбежно начинает восприниматься как препятствие.
Поэтому договариваться необходимо. В современных условиях контроль привилегированного доступа - это must-have, а успешно его реализовать без применения систем класса PAM очень сложно.
Значит, единственный реалистичный путь – строить такие решения совместно: когда безопасность получает необходимый уровень контроля, а администраторы – инструменты, с которыми они могут и готовы нормально работать.
