Слепая зона IAM. Почему управление паролями остается слабым звеном корпоративной инфраструктуры и как это исправить
Содержание
2. Что закрывают IAM, SSO и PAM в большой компании
3. Теневое ИТ. Как сотрудники обходят политики
4. Каким должен быть корпоративный менеджер паролей
5. Что требует ФСТЭК России от управления паролями
6. Сертификат ФСТЭК России №5063 и переход менеджеров паролей в класс СЗИ
7. Как закрыть слепую зону на практике
8. Что меняется на горизонте 1-2 лет
Парадокс зрелого CISO
Крупные компании вкладывают в информационную безопасность значительные бюджеты, разворачивают SIEM, EDR, NGFW, NDR, DLP, антифрод, PAM и NTA, выстраивают центры мониторинга, заказывают пентесты и закупают сертифицированные средства защиты информации. При этом учётные данные администраторов, общие пароли от инструментов маркетинга, корневые доступы к легаси-сервисам и ключи к интеграциям по-прежнему живут в обычных таблицах, переписках в мессенджерах и заметках на личных устройствах сотрудников.
Миллионы на защиту и root в заметках
Противоречие между планом защиты и тем, что происходит за пределами защищенного периметра, видно любому, кто хоть раз делал инвентаризацию учётных данных в компании. На инфраструктуру и средства защиты у бизнеса уходят серьёзные бюджеты, время команды и внимание руководства, а на пароли остаются только редкие рассылки от службы безопасности с напоминанием не записывать их на стикерах. Корпоративные менеджеры паролей в России долго оставались без сертификата соответствия ФСТЭК России, и работать с ними приходилось без какой-либо опоры на регуляторное подтверждение качества именно для этого класса СЗИ.
Почему вопрос паролей возвращается из года в год
Парольная тема всплывает в новостной ленте всякий раз, когда происходит крупная утечка или выходит свежее отраслевое исследование. В мае 2026 года «Солар» опубликовал материал о том, что каждый второй пользователь рискует своими данными из-за слабого пароля, «Исследование Солара, каждый второй пользователь рискует своими данными из-за слабого пароля». За пару недель до этого в отраслевых СМИ обсуждали, что на чёрном рынке уже лежит около 2,9 миллиарда паролей, готовых к атакам с подстановкой учётных данных, «Хакерам больше не нужно взламывать вас, ваши 2,9 млрд. паролей уже давно лежат на чёрном рынке». А ещё раньше Андрей Пензов в комментарии для CISOCLUB обращал внимание на то, что повторное использование паролей превращает каждую старую утечку в свежий риск, «Эксперт Пензов: повторное использование паролей усиливает эффект старых утечек».
После каждой такой публикации в службе информационной безопасности обычно проходит разбор, по компании рассылается очередное напоминание о парольной гигиене, и на этом тема закрывается до следующего громкого инцидента. К 2026 году напряжение усилилось ещё и с регуляторной стороны, потому что свежий методический документ ФСТЭК России ужесточил требования к парольной политике, подняв минимальную длину пароля до десяти символов, обязав менять его не реже одного раза в 120 дней и вести журнал действий с учётными записями. До 30 апреля 2026 года получалось, что регулятор требовал системного управления паролями, а сертифицированного инструмента, на который можно было бы опереться, в реестре ФСТЭК России в этом классе не было.
За один день эта картина изменилась. Парольная политика перестала быть документом и серией рассылок и превратилась в набор требований к полноценному классу СЗИ, а у CISO появилась обязанность реализовывать эти требования инструментом, прошедшим сертификационные испытания. В архитектуре корпоративной безопасности появился новый блок, которого там раньше попросту не было.
Что закрывают IAM, SSO и PAM в большой компании
За управление доступом в крупной организации, как правило, отвечают три класса систем, у каждого своя зона применимости. На первый взгляд кажется, что вместе они закрывают всю задачу управления доступом. На практике между ними остаются слепые зоны, в которые регулярно проваливаются пароли и сопутствующие учётные данные.
Зона ответственности IAM и SSO
Системы класса IAM строятся вокруг работы с учётной записью человека на всём её жизненном цикле. Когда сотрудник приходит в компанию, в AD/LDAP-каталоге появляется его запись, ему выдаются права на ресурсы, а потом он переходит между отделами, меняет роль и в какой-то момент увольняется. Все эти переходы IAM сопровождает, поддерживая соответствие между ролями в кадровой системе и доступами в ИТ-инфраструктуре.
Рядом с IAM в большинстве зрелых компаний работает SSO, который решает совсем другую задачу. Сотрудник один раз вводит свой пароль в корпоративном каталоге, а дальше входит во все интегрированные приложения уже без повторной аутентификации, потому что приложения доверяют корпоративному провайдеру идентификации и принимают от него токены. Интеграции SAML, OAuth2, OIDC и Kerberos позволяют подключить к этой схеме почтовый клиент, CRM, ITSM, бухгалтерию, портал согласований и сотни других систем, через которые сотрудники работают каждый день.
В рамках таких интеграций задача защиты паролей может быть решена. У сотрудника одна учётная запись и один пароль, который не передаётся в приложения, потому что они видят только токены провайдера. Особенность в том, что этот сценарий покрывает только те приложения, которые могут быть интегрированы, и которые компания смогла подключить.
Зона ответственности PAM
Третий блок относится к доступам администраторов, подрядчиков и других привилегированных пользователей к самой инфраструктуре, то есть к серверам, базам данных, сетевым устройствам, гипервизорам, контроллерам домена и так далее. Системы класса PAM развивались отдельно от IAM, потому что задача у них принципиально иная, не про повседневную работу человека с приложением, а про контроль над тем, кто и когда получает привилегированные права на критичных системах.
Современные PAM-решения выдают администратору временный доступ к нужной сессии, могут целиком записывать её для последующего разбора, при необходимости подменяют пароль учётной записи на время работы и регулярно ротируют пароли по расписанию, а сам пароль администратору при этом не показывается. Подробный разбор класса с типовыми сценариями применения мы делали в материале «Управление привилегированным доступом».
Как и связка IAM с SSO, PAM закрывает конкретный сценарий, в данном случае привилегированную сессию на определённый хост, под определённого администратора, в заданное окно времени. Внутри этого сценария парольный вопрос действительно снимается.
Что остаётся за пределами SSO и PAM
Между этими двумя зонами в крупной организации остаётся пространство, в которое не входят ни SSO, ни PAM, и в которое автоматически проваливается всё, что не подпадает ни под массовый пользовательский сценарий, ни под привилегированную сессию на инфраструктуре. Именно там и живут разделяемые секреты, которыми команды пользуются изо дня в день.
Туда относятся логин и пароль к корпоративному аккаунту в облачном сервисе, который не поддерживает SAML, общие учётные данные к рекламным кабинетам и аналитическим сервисам, доступ к которым нужен сразу нескольким сотрудникам, а также доступы в личные кабинеты хостинга, регистратора домена или регистратора SSL-сертификатов. К той же зоне относятся API-ключи к сторонним сервисам, которыми пользуется бизнес, и технические пароли баз данных, нередко прописанные прямо в конфигурационных файлах приложений, потому что иначе приложение просто не стартует.
Сюда же попадают доступы подрядчиков, которые когда-то выдавали на конкретный проект и забыли отозвать после сдачи работ, доступы к легаси-системам, не поддерживающим SSO в принципе, и сервисные учётные записи, не привязанные к конкретному сотруднику и не попадающие в кадровый цикл IAM. Каждый из этих случаев существует на стыке всех трёх классов, но не закрывается ни одним из них до конца.
| Класс систем | Зона ответственности | Что остаётся за пределами |
| IAM | Жизненный цикл учётной записи сотрудника | Технические и разделяемые секреты, не привязанные к одному сотруднику |
| SSO | Единый вход в приложения по SAML, OIDC, OAuth2, Kerberos и др. | Приложения и сервисы без поддержки этих протоколов |
| PAM | Привилегированные сессии к инфраструктуре, запись, ротация паролей | Учётные данные обычных пользователей и команд, разделяемые секреты |
Теневое ИТ. Как сотрудники обходят политики
В вопросах информационной безопасности любой запрет проигрывает удобству, если не предложить альтернативу. Когда корпоративного инструмента для хранения паролей нет, сотрудники используют свои собственные, и эти варианты редко попадают в поле зрения службы информационной безопасности.
Где компания теряет контроль
Чаще всего сотрудники могут пользоваться личным менеджером паролей (или нативным от операционной системы), причём одним и тем же менеджером сотрудник нередко пользуется и для домашних аккаунтов, и для рабочих. При увольнении такая база, как правило, уходит вместе с сотрудником, у работодателя при этом может не остаться ни прямого доступа к паролям, ни организованной возможности сменить их централизованно.
На следующем уровне находятся заметки и пересылки в мессенджерах, когда пароль попадает в командный чат и одновременно становится доступен всем его участникам, любым ботам с доступом к истории чата и, в худшем варианте, тому, кто получит контроль над взломанным аккаунтом одного из коллег. Чуть выше по типу хранения стоят общие таблицы в облачных сервисах и в Excel с доступом по ссылке, которые со временем расходятся по почтам подрядчиков и теряют контроль над списком получателей. Замыкает эту лестницу зашифрованный файл со слабым мастер-паролем, для вскрытия которого хватает базовых инструментов подбора.
Инциденты, к которым это приводит
Каждая из перечисленных практик регулярно материализуется в конкретные инциденты, о которых СМИ пишут с заметной периодичностью. Это и слив рекламного бюджета через скомпрометированный кабинет, и подмена настроек у регистратора домена с последующим простоем сайта, и публичные утечки API-ключей через коммиты в открытые репозитории кода, после которых ключи приходится экстренно отзывать и выпускать заново.
Отдельный кейс может быть связан с секретами в репозиториях разработки. Когда разработчик случайно коммитит файл с паролем базы данных в публичный или даже приватный репозиторий, секрет уже считается скомпрометированным, потому что удалить его из истории Git задача нетривиальная, и в большинстве компаний просто меняют пароль и идут дальше. С приватными репозиториями ситуация лишь немного спокойнее, потому что доступ к ним есть у всех разработчиков, которые когда-либо клонировали проект, и у бывших сотрудников или подрядчиков, чьи копии репозитория продолжают лежать у них на диске.
Менеджер паролей сам по себе не закрывает все эти риски одним движением, но его отсутствие заметно повышает вероятность того, что компания рано или поздно столкнётся с инцидентом именно через пароли. У крупных организаций частота таких эпизодов выше, и тем заметнее становится зависимость репутации и выручки от того, насколько быстро удаётся пройти по всем сценариям и минимизировать ущерб.
Каким должен быть корпоративный менеджер паролей
При выборе корпоративного менеджера паролей службы ИБ и ИТ смотрят не столько на функциональность по пунктам прайс-листа, сколько на то, как продукт встраивается в уже выстроенную архитектуру защиты информации. Менеджер паролей живёт на стыке корпоративного каталога, центра мониторинга и эксплуатации инфраструктуры, и если этот стык не сошёлся, то никакие красивые галочки в техническом задании работать не будут.
Хранение и шифрование
Базовое требование к продукту состоит в том, чтобы записи в хранилище всегда шифровались на стороне клиента или приложения, не передавались в открытом виде между компонентами и не попадали в открытом виде в журналы. Алгоритм симметричного шифрования в менеджерах паролей обычно выбирают между AES-256 и российским ГОСТ Р 34.12-2015 «Кузнечик», и набор поддерживаемых алгоритмов определяется тем, в каком сегменте применяется продукт. Для российских систем с обработкой персональных данных или информации в государственных информационных системах часто требуется поддержка ГОСТ, и российские продукты (например, Пассворк) поддерживают оба алгоритма.
Поддержка AD/LDAP
Менеджер паролей не должен превращаться в ещё один отдельный каталог учётных записей. В крупной компании уже есть AD/LDAP, HR-система, ITSM, и каждый новый источник учётных данных усложняет администрирование и аудит. Сотрудник входит по своей доменной учётной записи, а группы безопасности из AD/LDAP автоматически проецируются на права в менеджере паролей, при увольнении из каталога учётная запись блокируется и в менеджере без отдельной ручной операции. Без интеграции с корпоративным каталогом внедрение превращается в дублирование, кадровые процессы оказываются разнесены по двум и более системам, и службы ИБ и ИТ на такое могут не согласиться.
MFA
Корпоративный менеджер паролей хранит самые чувствительные данные компании, поэтому вход в сам менеджер защищается дополнительным фактором помимо пароля. Должны поддерживаться TOTP-приложения (Google Authenticator, Яндекс.Ключ и аналоги), отечественные средства MFA и аппаратные ключи. Дополнительный плюс, когда менеджер сам умеет генерировать TOTP-коды для сторонних сервисов, тогда сотруднику не нужно держать ещё одно приложение на телефоне для каждой системы. Требование к многофакторной аутентификации зафиксировано и в мере ИАФ.3 методического документа ФСТЭК России 2026 года.
Ролевая модель доступа
Ролевая модель в корпоративном менеджере паролей должна различать несколько вещей. Доступ к самим записям по конкретным сейфам и папкам. Право управлять этим доступом, выдавать и отзывать его. Системные роли с разной зоной ответственности, обычно это владелец, администратор и аудитор. Дополнительно ограничения на работу с аккаунтом самого пользователя. В реальной компании структура прав редко плоская, и разным командам нужны разные секреты. Маркетингу разделяемые облачные аккаунты, бухгалтерии ключи электронной подписи и сертификаты, ИТ-службе пароли инфраструктуры. Каждая ветка работает обособленно, аудит остаётся сквозным.
Аудит действий и журналирование
Каждое действие в системе должно фиксироваться, чтобы в записях оставались исполнитель, время, IP-адрес и характер операции. События обычно отправляются в центр мониторинга через syslog или интеграцию с системами журналирования операционной системы, попадают в правила корреляции центра мониторинга и становятся объектом наблюдения дежурных аналитиков.
Развёртывание на стороне заказчика
Развёртывание на стороне заказчика, то есть в on-premise режиме, в случае с менеджером паролей становится архитектурным требованием для систем уровня государственных информационных систем, информационных систем персональных данных и значимых объектов критической инфраструктуры. Пароли от внутренней инфраструктуры в таких контурах не должны лежать в облаке у вендора, потому что любая компрометация вендора в такой схеме автоматически превращается в компрометацию заказчика. Облачные менеджеры зарубежного происхождения вроде 1Password, LastPass и Bitwarden (или встроенный инструмент «Пароли» от Apple) дополнительно оказываются юридически непригодными для перечисленных классов систем. Для коммерческого сегмента, не подпадающего под требования к классам защищённости, российские вендоры также предлагают облачные версии на отечественной инфраструктуре, но для критичных контуров корпоративный сценарий строится вокруг установки на собственных серверах с минимальными сетевыми зависимостями от внешних служб.
Чем менеджер паролей отличается от secrets manager и PAM
В обсуждениях с директорами по информационной безопасности нередко смешиваются сразу три класса продуктов, и без чёткого разделения архитектура получается размытой. Менеджер паролей предназначен для хранения паролей пользователей и команд, работающих с приложениями и сервисами. Системы класса secrets manager (управление секретами) отвечают за секреты приложений и автоматизированного инфраструктурного контура, то есть за API-токены, сертификаты и ключи доступа в конвейерах сборки. PAM, в свою очередь, управляет привилегированными сессиями к самой инфраструктуре, и эти три класса не заменяют друг друга, а работают каждый в своей зоне. Сертифицированный по требованиям ФСТЭК России класс, закрывающий именно первую из этих трёх задач, для российского рынка появился только в 2026 году. Рядом с этим триадой существуют также системы класса IGA (управление идентификациями и доступом на уровне процессов), которые задают политики и регламент, но за хранение паролей и привилегированных сессий отвечают именно три перечисленных класса.
В дополнение к функциональному ядру корпоративный менеджер паролей должен поддерживать программный интерфейс, потому что без него часть задач закрыть не получится. Системы сборки, скрипты обслуживания и инструменты автоматизации обращаются за паролями не через интерфейс пользователя, а программно, и API в таком случае оказывается обязательным. Браузерные расширения и десктопные клиенты нужны для повседневной работы пользователей, а мобильные приложения для команды эксплуатации, которая выезжает на инциденты. У отечественного решения (Пассворк) эта линейка клиентов покрыта целиком, есть API с готовым Python-коннектором и CLI для DevOps, десктопные приложения для Windows, macOS и Linux, мобильные клиенты для iOS, Android и RuStore, а также расширения для Chrome, Firefox, Edge и Safari.
Что требует ФСТЭК России от управления паролями
Требования к работе с паролями встречаются в приказах ФСТЭК России о защите информации. Они входят в базовый набор мер защиты, который применяется на любом контуре, обрабатывающем защищаемую информацию.
Меры ИАФ и УПД в приказах ФСТЭК России
В приказах ФСТЭК России №21 от 18.02.2013, №239 от 25.12.2017, №31 от 14.03.2014, №117 от 11.04.2025 базовый набор мер защиты сгруппирован по функциональным группам, среди которых для нашей темы важны две, ИАФ — идентификация и аутентификация, и УПД — управление доступом. Группа ИАФ описывает, как пользователь предъявляет учётные данные, какие требования предъявляются к паролям и какие способы вторичной аутентификации применяются, а группа УПД фиксирует, кто имеет доступ к каким объектам, как распределяются роли и каким образом ведётся учёт учётных записей. Эти меры реализуются вне зависимости от того, есть ли в компании менеджер паролей, но без централизованного инструмента качество их реализации обычно заметно хуже.
Если разложить меры на конкретные подпункты, корпоративный менеджер паролей появляется в архитектуре естественным образом. К нему относятся ИАФ.1 (идентификация и аутентификация работников оператора), ИАФ.5 (защита обратной связи при вводе аутентификационной информации) и ИАФ.6 (идентификация и аутентификация внешних пользователей), УПД.1 (управление учётными записями пользователей), УПД.4 (разделение полномочий пользователей) и УПД.10 (блокирование сеанса доступа после простоя).
Где менеджер паролей становится обязательным
Применимость менеджера паролей зависит от того, в каком контуре работает организация. Приказ ФСТЭК России от 11.04.2025 №117, вступивший в силу 01.03.2026, регулирует государственные информационные системы и заменил собой более ранний приказ ФСТЭК России от 11.02.2013 №17. Приказ ФСТЭК России от 18.02.2013 №21 распространяется на информационные системы персональных данных, приказ ФСТЭК России от 25.12.2017 №239 на значимые объекты критической информационной инфраструктуры, ЗОКИИ — значимый объект КИИ, а приказ ФСТЭК России от 14.03.2014 №31 на автоматизированные системы управления технологическими процессами на критически важных объектах. Если организация попадает хотя бы под один из этих контуров, меры ИАФ и УПД у неё обязательны, а централизованный менеджер паролей как инструмент их реализации становится обоснованным архитектурным решением.
| Приказ ФСТЭК России | Контур применения | Связь с менеджером паролей |
| №117 от 11.04.2025 | Государственные информационные системы | Меры ИАФ и УПД обязательны для всех классов защищённости |
| №21 от 18.02.2013 | Информационные системы персональных данных | Группы мер ИАФ и УПД для всех уровней защищённости |
| №239 от 25.12.2017 | Значимые объекты критической информационной инфраструктуры | Меры ИАФ и УПД для всех категорий значимости |
| №31 от 14.03.2014 | АСУ ТП | Меры ИАФ и УПД для всех классов защищённости |
Парольные требования методического документа ФСТЭК России 2026
В апреле 2026 года ФСТЭК России утвердила методический документ «Мероприятия и меры по защите информации, содержащейся в информационных системах» (информационное сообщение ФСТЭК России от 14.04.2026), который заметно поднял планку по парольной политике. В разделе, посвящённом мере ИАФ.3 «Аутентификация пользователей», для всех уровней сложности зафиксирована минимальная длина пароля от десяти символов и обязательная смена пароля не реже одного раза в 120 дней, а в зависимости от уровня сложности меняются требования к составу пароля. Параллельно усилены требования по защите от подбора, блокированию учётной записи после серии неудачных попыток и обязательному журналированию действий с паролями. Полностью соблюсти эти требования исключительно административными мерами в организации хотя бы из нескольких сотен сотрудников практически невозможно, поэтому появление сертифицированного менеджера паролей перестало быть желательным дополнением и превратилось в обязательный элемент инфраструктуры.
Сертификат ФСТЭК России №5063 и переход менеджеров паролей в класс СЗИ
30 апреля 2026 ФСТЭК России выдала сертификат соответствия №5063 первому продукту класса корпоративных менеджеров паролей.
Что такое 4 уровень доверия
Уровни доверия ввёл приказ ФСТЭК России от 02.06.2020 №76, и всего таких уровней шесть, причём нумерация у них обратная, первый считается высшим, а шестой низшим. Первые три уровня применяются к средствам защиты для систем, обрабатывающих государственную тайну, а с четвёртого по шестой работают коммерческие средства защиты информации. 4 уровень доверия, УД — уровень доверия, при этом остаётся максимально достижимым для коммерческих продуктов, и любое решение, прошедшее сертификацию именно по этому уровню, фактически выходит на потолок применимости в коммерческой сфере.
Сертификат №5063, 30 апреля 2026 года
30 апреля 2026 года сертификат соответствия ФСТЭК России №5603 получил российский менеджер паролей Пассворк, и на момент выхода этой статьи он остаётся единственным продуктом класса менеджеров паролей в соответствующем реестре. До получения сертификата у компании уже были лицензия ФСТЭК России на разработку и производство средств защиты конфиденциальной информации, лицензия ФСТЭК России на техническую защиту конфиденциальной информации, обе с июня 2024 года, лицензия ФСБ России на криптографические технологии и запись в реестре российского ПО Минцифры России под номером 6147.
В каких системах теперь можно применять
4 уровень доверия позволяет применять сертифицированный продукт в системах с наиболее жёсткими требованиями. Сюда относятся государственные информационные системы вплоть до 1 класса защищённости включительно, информационные системы персональных данных до 1 уровня защищённости включительно, значимые объекты критической инфраструктуры до 1 категории включительно и автоматизированные системы управления технологическими процессами до 1 класса защищённости включительно. Если организация работает хотя бы в одном из этих контуров, у неё появилась легитимная возможность развернуть корпоративный менеджер паролей без рисков для прохождения последующей аттестации.
Этот прецедент меняет ситуацию для всего рынка, а не только для одного производителя. Заказчики из госсектора или промышленности впервые получают возможность использовать сертифицированный менеджер паролей, а сам регулятор получает рабочую категорию для дальнейших методических указаний по парольной защите.
| Тип системы | Класс или уровень при 4 УД | НПА |
| Государственная информационная система | до 1 класса защищённости включительно | приказ ФСТЭК России №117 |
| Информационная система персональных данных | до 1 уровня защищённости включительно | приказ ФСТЭК России №21 |
| Значимый объект КИИ | до 1 категории значимости включительно | приказ ФСТЭК России №239 |
| АСУ ТП | до 1 класса защищённости включительно | приказ ФСТЭК России №31 |
Что сертификация 4 УД проверяет на практике
Сертификация по 4 уровню доверия проверяет и готовый продукт, и процессы его разработки. Помимо испытаний самой системы оцениваются процессы безопасной разработки у производителя, работа с уязвимостями и реагирование на них. Отдельным блоком проверяется отсутствие НДВ — недекларированных возможностей, то есть скрытой функциональности, которая теоретически могла бы использоваться для обхода защитных функций. Сертификат в итоге означает, что результат этих проверок зафиксирован независимой испытательной лабораторией, а не остаётся на доверии к маркетинговым материалам производителя.
Чем это меняет ситуацию для CISO
Появление сертифицированного менеджера паролей закрывает для службы информационной безопасности несколько практических задач. Прохождение аттестации по требованиям безопасности информации становится проще, потому что у выбранного решения появляется формальное основание войти в перечень используемых СЗИ. Выход из теневого ИТ облегчается, потому что сотрудникам можно предложить легитимную замену личным менеджерам паролей и заметкам в мессенджерах. А задача импортозамещения в этом сегменте перестаёт упираться в отсутствие сертифицированного СЗИ.
Как закрыть слепую зону на практике
Появление сертифицированного решения само по себе ещё не закрывает проблему, потому что любой инструмент работает только тогда, когда встроен в процессы и политики компании. Без этого он повторит судьбу прежних общих файлов с паролями, только в более красивой обёртке, и службе информационной безопасности придётся последовательно пройти по трём задачам, описать политику, перевести команду со старых теневых инструментов на новый корпоративный и выстроить выбор решения по понятным критериям.
Парольная политика, которая работает
Рабочая парольная политика начинается не с формулировки минимальной длины пароля, а с банальной инвентаризации, на которой выясняется, какие учётные данные у компании вообще есть, кто ими владеет и кто пользуется на постоянной основе. Без такой инвентаризации любая последующая политика остаётся на бумаге, потому что просто непонятно, что именно она регулирует. После того как реестр учётных данных собран, можно формулировать требования по типам, для пользовательских аккаунтов в SSO достаточно стандартной многофакторной аутентификации, для разделяемых корпоративных аккаунтов обязательное хранение в менеджере паролей с раздачей доступа по группам, а для административных и привилегированных учётных записей связка с PAM, регулярная ротация и ограниченный срок жизни. Сама политика спокойно умещается на одну страницу, и к ней дополнительно прилагается отдельный регламент по реакции на компрометацию, описывающий, кто и в какой срок меняет пароль, кого уведомляют и как фиксируется инцидент.
Выход из теневого ИТ без бунта
Выход из теневого ИТ строится на удобной альтернативе, а не на запретах. Если корпоративный инструмент удобен в работе и доступен прямо из браузера в один клик, сотрудники переходят на него сами, без давления со стороны службы информационной безопасности. Если же внедрение пытаются провести админресурсом, в формате «всем под угрозой увольнения за неделю занести пароли в новый менеджер», саботаж практически гарантирован, потому что у сотрудников нет ни мотивации, ни понимания, чем именно новый инструмент лучше старых привычек. Работающая схема обычно выглядит как пилот в одной из команд, сбор обратной связи, постепенное расширение на остальные подразделения и отключение старых каналов хранения паролей только после того, как новый инструмент закрепился в повседневной практике.
На что смотреть при выборе сертифицированного решения
При выборе сертифицированного решения в службе информационной безопасности обычно идут по четырём смысловым блокам. На регуляторном уровне проверяется наличие действующего сертификата ФСТЭК России и сопутствующих лицензий, и сейчас в реестре сертифицированных менеджеров паролей по 4 уровню доверия фигурирует один продукт, Пассворк, функциональность которого мы подробно разбирали в отдельном материале «Пассворк 7, обзор новой версии корпоративного менеджера паролей». На технологическом уровне смотрят на поддержку AD/LDAP, на возможность установки на стороне заказчика, на наличие программного интерфейса и алгоритмов шифрования. На операционном уровне оценивают качество документации на русском языке, доступность технической поддержки в России и опыт внедрений в организациях схожего профиля. Финально сравниваются модель лицензирования, совокупная стоимость владения на горизонте трёх лет и условия технической поддержки.
Что меняется на горизонте 1-2 лет
Менеджер паролей как самостоятельный класс СЗИ
В перспективе одного-двух лет в реестре сертифицированных СЗИ ФСТЭК России может появиться отдельная категория для менеджеров паролей, и вместе с ней сложатся типовые требования и методики оценки соответствия. Это упростит сертификацию для новых вендоров и закупку для службы информационной безопасности, потому что обеим сторонам не придётся каждый раз заново договариваться о том, как именно оценивать продукт.
Что ждать от других вендоров
Логично ожидать, что вслед за Пассворком за сертификацией ФСТЭК России пойдут конкуренты, и кандидаты на это уже видны на рынке. Конкуренция в новом классе нужна и заказчикам, и самому регулятору, потому что монопольное положение единственного сертифицированного решения долго не продержится, и в перспективе это окажется к лучшему для рынка в целом.
От паролей к секретам, токенам и passkey
Параллельно меняется и сама технология пользовательской аутентификации. Помимо паролей и MFA корпоративные SSO постепенно дополняются поддержкой passkey по стандартам WebAuthn и FIDO2, а также биометрии в качестве дополнительного фактора. В долгосрочной перспективе пароль как массовый инструмент пользовательской аутентификации постепенно уступает место этим технологиям, но в других контурах остаётся ещё надолго. Это в первую очередь разделяемые корпоративные секреты, технические пароли баз данных и интеграций, доступы подрядчиков. Менеджер паролей в этой части задач будет нужен и через несколько лет, потому что класс задач, который он закрывает, при переходе на passkey не исчезает.
Заключение
Корпоративная защита информации в крупной компании давно собирается из десятков взаимосвязанных подсистем. SIEM собирает события, EDR и антивирус защищают конечные точки, NGFW и NDR анализируют трафик, DLP пресекает утечки, PAM контролирует привилегированный доступ. Это далеко не полный список, но каждая подсистема закрывает свою зону. Между ними оставался сценарий, на который у бизнеса не хватало ни внимания, ни регуляторного давления, и это работа с корпоративными паролями. Личные менеджеры на флешках, переписки в мессенджерах и таблицы в общих папках стали стандартом по умолчанию, потому что в реестре ФСТЭК России до апреля 2026 года сертифицированных продуктов этого класса не было. Появление сертификата соответствия ФСТЭК России №5063 у Пассворка закрывает этот сценарий уже в реестре. Менеджер паролей становится полноценным классом средств защиты информации с правом применения в коммерческом секторе. У службы информационной безопасности появляется сертифицированный инструмент для управления корпоративными паролями, и от этого изменения выигрывает уже не один производитель.
Реклама. ООО «ПАССВОРК», ИНН: 2901311774, Erid: 2SDnjeiqNq8
