Импортозамещение без революций: как поэтапно построить российский контур управления доступом
В 2025 году число кибератак на российские компании выросло на 42% — примерно 22 тысячи инцидентов. Почти половина из них привела к сбоям в ИТ-системах. Цифры сами по себе ничего не доказывают, но они хорошо объясняют, почему импортозамещение управления доступом перестало быть отложенной задачей и стало частью операционной устойчивости бизнеса.
Для органов власти и компаний с госучастием Указ Президента РФ № 166 ограничивает использование иностранного ПО на принадлежащих им значимых объектах КИИ. Субъектам КИИ Указ № 250 запрещает использовать средства защиты информации из недружественных государств. Применимость этих требований зависит от статуса организации, типа объекта, категории значимости и переходных положений.
Меня зовут Дмитрий Макаров, я руководитель продукта MULTIDIRECTORY в компании МУЛЬТИФАКТОР. Вместе с Александрой Гончаровой, менеджером продукта СКДПУ НТ в «АйТи Бастион», мы решили поделиться опытом перевода управления доступом на отечественные решения без остановки бизнеса. На встречах с заказчиками команды чаще всего обсуждают штатные сценарии: какие группы защищать, куда подключать MFA и как не усложнить жизнь пользователям. А вопрос «что делать, если сам контур доступа недоступен» нередко всплывает позже — иногда уже после первого серьёзного сбоя. С импортозамещением нужно двигаться осторожнее — сначала понять, от чего что зависит, затем проверить новую архитектуру на пилоте и только потом переносить продуктив.
Почему переход сложнее замены
Служба каталогов связана с множеством компонентов инфраструктуры. Через неё могут работать аутентификация, групповые политики, VPN, почта, файловые ресурсы, 1С и внутренние приложения. Если заменить каталог, не проверив эти зависимости, проблемы возникнут не только у администраторов. Пользователи могут потерять доступ к приложениям, а некоторые сервисы — перестать проходить аутентификацию.
До миграции стоит выяснить, какие приложения используют LDAP или Kerberos, где настроены доверительные отношения, какие группы определяют доступ к файлам и как управляются рабочие станции. Результатом должна стать карта зависимостей, по которой можно определить порядок переноса. Одни системы удастся переключить сравнительно быстро, другие придётся на время оставить в прежнем контуре.
С PAM ситуация похожая, но есть дополнительная сложность: за годы эксплуатации в системе накапливаются настройки, о назначении которых уже не всегда помнят. Это сведения о серверах и пользователях, сервисные пароли, API-ключи, ролевые матрицы и коннекторы. Часть записей может относиться к давно выведенным из эксплуатации системам или сотрудникам, которые больше не работают в организации.
Особенно внимательно нужно проверить сервисные учётные записи: root, локальных администраторов, технические аккаунты приложений и интеграций. Нередко одним аккаунтом пользуются несколько команд, а пароль хранится в общей таблице или локальном менеджере. При переносе важно не просто скопировать эти сведения в новую систему, а выяснить, кто отвечает за каждую учётную запись, какие приложения от неё зависят и где действительно необходимы прежние привилегии.
Есть и архитектурные различия между PAM-платформами. Например, некоторые зарубежные решения используют агентов на целевых хостах. СКДПУ НТ компании «АйТи Бастион» работает по другой схеме — через безагентский сетевой шлюз-бастион. Это влияет на организацию подключений, поэтому переноса настроек недостаточно. Нужно проверить сетевую доступность целевых систем, маршрутизацию, используемые протоколы и порядок управления сессиями. Отдельно стоит решить, как поступить с архивами сессий. Записи нужны не только для контроля действий администраторов. При расследовании инцидента они помогают восстановить последовательность событий, а иногда позволяют подтвердить, что инженер действовал в соответствии с регламентом.
Миграция — это повод пересмотреть привилегии. Действительно ли каждому администратору нужен прежний набор прав? Какие сервисные аккаунты можно вывести из эксплуатации? Где общий пароль стоит заменить индивидуальным доступом с контролируемой выдачей секрета?
При этом PAM редко меняют отдельно от остальной инфраструктуры. Организация может одновременно переходить на отечественные операционные системы, СУБД, гипервизоры и службы каталогов. В таких условиях новая система управления доступом должна работать не только в конечной архитектуре, но и в переходный период, когда часть ресурсов ещё использует Windows и Active Directory, а новые Linux-системы уже подключаются к отечественному каталогу.
Три уровня управления доступом
Контур привилегированного доступа складывается из нескольких функций. Служба каталогов хранит сведения о пользователях и группах. MFA добавляет проверку личности. PAM контролирует доступ к ресурсам и действия в привилегированных сессиях.
В качестве примера рассмотрим связку решений, совместимость которых подтверждена испытаниями: MULTIDIRECTORY выполняет роль службы каталогов, MULTIFACTOR — многофакторной аутентификации, СКДПУ НТ — управления привилегированным доступом. Такой контур можно собирать и из других совместимых решений: важнее не конкретные названия, а разделение функций каталога, проверки личности и контроля привилегированных сессий.
MULTIDIRECTORY может работать параллельно с Microsoft Active Directory. Поддержка доверительных отношений типа «Лес» позволяет не отключать действующий домен, а переносить отдельные группы пользователей и сервисы по мере готовности. Например, Linux-серверы и новые сервисы подключаются к MULTIDIRECTORY, а часть Windows-рабочих станций и зависимых приложений продолжает работать с Active Directory. Такой сценарий снижает риски: новый каталог постепенно становится единым источником учётных данных для новых систем, а действующий домен продолжает обслуживать существующие процессы. По мере переноса сервисов в MULTIDIRECTORY можно переводить группы, права доступа и политики паролей, не разрывая работу пользователей. Каталог также поддерживает LDAP-аутентификацию и может использоваться для Linux-серверов, VPN-шлюзов, файловых ресурсов, СУБД, систем мониторинга и внутренних приложений.
При интеграции пользователь проходит аутентификацию в СКДПУ НТ под персональной доменной учётной записью. Отдельную учётную запись в PAM для каждого сотрудника заводить не нужно — можно легко интегрировать доменные УЗ в политику доступа. Дальше MULTIFACTOR проверяет второй фактор, а СКДПУ НТ сопоставляет пользователя с его правами и создаёт контролируемую сессию. Важно различать учётную запись человека и привилегированную учётную запись на целевом сервере. Администратор входит в шлюз под своим именем, а к серверу подключается, например, от имени root или локального администратора. PAM может подставить целевой пароль, не раскрывая его пользователю, и при настроенном сценарии автоматически ротировать. Это особенно полезно там, где один пароль раньше знали несколько инженеров: на сетевых устройствах, серверах баз данных или сервисных узлах. Ресурс продолжает работать, но общий секрет перестаёт быть общим знанием. Права инженера можно связать с группой в каталоге, а при блокировке его учётной записи — прекратить доступ через PAM. Правда, только если интеграция и правила авторизации настроены корректно.
Как спланировать переход
Сначала — инвентаризация. Соберите сведения о ресурсах, подключённых к действующей PAM-платформе: серверах, сетевых устройствах, базах данных и технологических системах. Зафиксируйте используемые протоколы и коннекторы, роли пользователей, привилегированные учётные записи и зависимости между системами.
Не забудьте про журналы и архивы сессий. Нужно понимать, где они хранятся, как долго сохраняются, какие системы получают события аудита, и кто отвечает за доступ к архивам. Отдельно опишите аварийный доступ: какие реквизиты используются, где они находятся и кто имеет право их получить. Включите в инвентаризацию и подключения в обход PAM: прямые SSH- и RDP-соединения, VPN-доступ, консоли гипервизоров, временные учётные записи подрядчиков. Выясните, как сотрудники передают друг другу пароли. Каждый такой канал нужно либо перевести под контроль PAM, либо явно оформить как обоснованное исключение. Если после миграции часть администраторов продолжит подключаться к серверам напрямую, новый PAM-контур не обеспечит полного контроля, даже если все основные настройки будут выполнены правильно.
Затем — пилот на ограниченном наборе ресурсов. Не стоит начинать с самых критичных систем. Выберите несколько ресурсов, на которых можно проверить новую схему без риска для основных бизнес-процессов. На этом этапе нужно убедиться, что работают сетевые маршруты, правила межсетевых экранов и целевые подключения по используемым протоколам — SSH, RDP, VNC, Telnet или Raw TCP. Перечень зависит от реальной инфраструктуры и возможностей выбранной PAM-платформы.
Пилот лучше проводить с участием разных категорий пользователей: Linux-администраторов, сетевых инженеров и, если это предусмотрено рабочими процессами, внешнего подрядчика. Так можно проверить не только подключение к ресурсам, но и ограничения доступа, обработку отказов и работу привычных инструментов. Отдельный сегмент тестовых Linux-серверов или новый сервис можно подключить к MULTIDIRECTORY, не меняя основной домен. Это позволит проверить LDAP-интеграцию, сопоставление групп, политики паролей и сценарии входа. Если обнаружатся проблемы, их можно устранить до переноса продуктивных систем.
Настройте роли и MFA. После проверки базовых подключений сопоставьте группы каталога с правилами доступа PAM. Убедитесь, что администраторы входят под персональными учётными записями и получают только те привилегии, которые предусмотрены их ролями. Затем проверьте сценарии входа: подтверждение через пуш-уведомление, OTP-коды и другие используемые способы аутентификации. Политики MFA не обязательно должны быть одинаковыми для всех. Например, для внешнего подрядчика можно потребовать дополнительное подтверждение при каждом входе, а для внутреннего инженера — применять усиленную проверку при обращении к наиболее чувствительным системам. Конкретные правила стоит выбирать с учётом рисков и требований организации.
Переводите ресурсы поэтапно. После пилота переходите к следующей группе систем. Обычно разумно начать с тестовых и вспомогательных ресурсов, затем подключить среды разработки и тестирования, после них — отдельные сегменты продуктивной инфраструктуры. Критичные системы лучше переводить тогда, когда команда уже проверила основные сценарии и отработала процедуру возврата к прежней схеме.
Перед каждой волной определите, по каким признакам можно считать перенос завершённым. Достаточно ли прав у нужных пользователей? Работают ли все используемые протоколы? Записываются ли сессии и поступают ли события в SIEM? Проверен ли аварийный доступ? Понятно ли, кто принимает решение об откате и выполняет его? Удобно фиксировать результаты в коротком чек-листе по каждой группе ресурсов. Это помогает не потерять отдельные системы при масштабировании проекта и видеть, какие проверки уже пройдены, а какие ещё предстоят.
Не отключайте старую систему раньше времени. Перед выводом прежней PAM-платформы проверьте, что архивы видеозаписей и сессионных журналов сохранены и доступны в течение необходимого срока. Их нельзя считать ненужными только потому, что новая система уже работает. Также проверьте аварийный доступ — Break-Glass. Недостаточно описать его в регламенте: нужно убедиться, что ответственные сотрудники действительно могут воспользоваться этим сценарием. Например, можно раз в квартал моделировать недоступность PAM-шлюза или доменного контроллера, проверять получение аварийных реквизитов и фиксировать все действия, выполненные в обход штатного контура. После такой проверки важно вернуть систему в обычный режим и убедиться, что аварийные полномочия снова ограничены.
Контроль без лишних барьеров
Даже правильно настроенная система может вызвать проблемы, если привычные рабочие сценарии внезапно перестанут работать. Поэтому на пилоте стоит проверить, какими SSH- и RDP-клиентами пользуются администраторы, нужен ли им буфер обмена, требуется ли передача файлов и какие действия должны блокироваться политиками. Изменения лучше объяснить заранее. Администратор должен понимать, как теперь подключаться к серверу, что произойдёт при попытке выполнить запрещённую команду и куда обращаться, если доступ не работает. Если порядок действий непонятен, люди начинают искать обходные пути, например, пытаться использовать старые прямые подключения, которые не попадают под аудит.
Для службы ИБ PAM обеспечивает контроль привилегированных сессий в пределах настроенных возможностей: может записывать действия, вести видеозапись, ограничивать буфер обмена, блокировать определённые команды и передавать события в SIEM. Набор доступных функций зависит от продукта, протокола подключения и конфигурации. Поэтому на этапе пилота нужно проверять не только наличие нужной настройки в интерфейсе, но и то, как она работает на конкретных целевых системах. Для подрядчиков можно организовать временный доступ с ограничениями по ресурсам и сроку действия. После завершения работ права следует отзывать, а если продукт поддерживает соответствующий сценарий — автоматизировать этот процесс.
Полезно ограничить прямой доступ к административным портам сетевыми правилами, разрешив подключения только с PAM-шлюзов и других согласованных узлов управления. Иначе администратор сможет обойти контроль PAM, подключившись к ресурсу напрямую. Передача событий в SIEM или SOC помогает сопоставлять действия в привилегированных сессиях с другими событиями безопасности, но только при условии, что необходимые журналы действительно поступают и корректно обрабатываются. При этом PAM не заменяет операционные системы, СУБД, межсетевые экраны и средства криптографической защиты. Наличие такой платформы само по себе также не означает, что вся информационная система соответствует требованиям регуляторов. Это определяется архитектурой, настройками, документацией и результатами оценки конкретного контура.
Как измерить результат
До начала пилота зафиксируйте исходное состояние. Сколько привилегированных учётных записей используется? Какие из них актуальны? Сколько времени занимает выдача и отзыв доступа? Какая доля ресурсов доступна через PAM, а к каким можно подключиться напрямую? Все ли необходимые сессии записываются и доходят ли события аудита до SIEM? При необходимости можно добавить другие показатели: количество общих паролей, время согласования доступа, число запросов в поддержку, инциденты с участием подрядчиков и долю сессий с полным аудитом. Главное — выбрать показатели, которые действительно связаны с задачами проекта, и измерять их одинаковым способом до и после миграции.
После каждой волны сравнивайте результаты с исходными значениями. Если прямых подключений стало меньше, а доля привилегированных сессий с полным аудитом выросла, это уже измеримый результат. А вот снижение затрат или количества инцидентов нельзя обещать заранее: на них влияют и другие изменения в инфраструктуре, процессы эксплуатации и общая ситуация с угрозами. Экономику проекта тоже нужно считать с учётом реальной конфигурации. В расчёт входят лицензии PAM, службы каталогов и операционных систем, требования к серверам и базам данных, стоимость внедрения, сопровождения и обучения. Сравнивать только цены лицензий недостаточно: полезнее оценивать совокупную стоимость владения.
При этом масштаб проекта определяется не одним числом серверов или пользователей. Для одной организации важнее запись и контроль привилегированных сессий, для другой — отказоустойчивость, интеграция с каталогом или автоматическая ротация секретов. Поэтому состав решения лучше выбирать после инвентаризации и проверки сценариев, а не только по перечню функций в презентации.
Для регулируемых контуров нужно отдельно проверить разрешительные документы на выбранные продукты: наличие в реестре отечественного ПО, сертификаты ФСТЭК или ФСБ, если они требуются для конкретного сценария. Важно смотреть не только на название продукта, но и на версию, область действия сертификата и условия применения. Сертификат конкретного решения не подтверждает автоматически соответствие всей информационной системы требованиям для защиты значимого объекта КИИ или АСУ ТП.
Постепенно — не значит медленно
Поэтапная миграция требует предварительной работы: нужно описать зависимости, подготовить пилот, проверить интеграции и определить условия отката. Зато команда получает возможность обнаруживать проблемы на ограниченном наборе систем, а не после того, как изменения затронули всю организацию. Результат зависит не столько от самого факта установки отечественных продуктов, сколько от того, как они встроены в инфраструктуру. Каталог определяет учётные записи и группы, MFA добавляет проверку личности, PAM управляет привилегированным доступом и фиксирует действия в сессиях. Если эти механизмы согласованы между собой, переход можно проводить последовательно, сохраняя работающие процессы и проверяя каждое следующее изменение.
Перед завершением проекта стоит убедиться, что привилегированный доступ действительно проходит через предусмотренный контур, события аудита поступают в SIEM, аварийный вход проверен, а оставшиеся прямые подключения учтены и обоснованы. Только после этого можно говорить не просто о замене продукта, а о перестроенном управлении доступом, которое работает в реальной инфраструктуре.
Используемые термины: MFA (Multi-Factor Authentication) — многофакторная аутентификация. Способ входа, при котором помимо пароля требуется дополнительное подтверждение личности. Продуктив — производственная среда: рабочие ИТ-системы и данные, от которых зависит деятельность организации. VPN (Virtual Private Network) — виртуальная частная сеть. Технология защищённого подключения к корпоративной сети через интернет. LDAP (Lightweight Directory Access Protocol) — облегчённый протокол доступа к каталогам. Протокол, по которому приложения получают сведения о пользователях и группах из службы каталогов и выполняют аутентификацию. Kerberos — протокол сетевой аутентификации. Позволяет пользователю или сервису подтвердить личность без передачи пароля по сети. PAM (Privileged Access Management) — управление привилегированным доступом. Решение или процесс для контроля доступа администраторов и сервисных учётных записей к критичным системам, включая выдачу паролей, запись сессий и аудит действий. API-ключи (Secret keys for Application Programming Interface) — секретные ключи интерфейса программирования приложений. Коды доступа, с помощью которых одна программа обращается к другой. Root — суперпользователь в Unix-подобных системах, в том числе Linux. Обладает максимальными правами в системе, поэтому доступ к root требует особого контроля. Безагентский — работающий без установки специальной программы (агента) на защищаемый сервер или устройство. СУБД (система управления базами данных) — программное обеспечение для создания, хранения, изменения и защиты данных. Гипервизор — программная платформа для создания и управления виртуальными машинами. Windows — операционная система корпорации Microsoft для персональных компьютеров и серверов. Active Directory — служба каталогов Microsoft. Linux-системы — операционные системы на основе ядра Linux. SSH (Secure Shell) — защищённая оболочка. Протокол безопасного удалённого управления серверами и сетевыми устройствами, преимущественно в Linux-средах. RDP-соединения (Remote Desktop Protocol) — протокол удалённого рабочего стола. VNC (Virtual Network Computing) — виртуальные сетевые вычисления. Протокол удалённого доступа к графическому рабочему столу. Telnet — устаревший протокол удалённого управления устройствами. Передаёт данные, включая пароли, без шифрования, поэтому в защищённых контурах его применение ограничивают. Raw TCP — необработанный TCP, прямое сетевое соединение по протоколу TCP. Пуш-уведомление (push notification) — сообщение, которое приложение отправляет. OTP-коды (One-Time Password) — одноразовые пароли. Коды с ограниченным сроком действия, которые пользователь вводит как второй фактор при входе. SIEM (Security Information and Event Management) — управление информацией и событиями безопасности. Платформа, которая собирает журналы из разных систем, сопоставляет события и помогает выявлять инциденты. Break-Glass — аварийный доступ. Заранее подготовленный и контролируемый способ входа в систему, когда штатные механизмы аутентификации или управления доступом недоступны. ИБ — информационная безопасность. SOC (Security Operations Center) — центр операций безопасности. Команда и инфраструктура, которые непрерывно отслеживают события безопасности, расследуют и устраняют инциденты. ФСТЭК — Федеральная служба по техническому и экспортному контролю. ФСБ — Федеральная служба безопасности Российской Федерации. АСУ ТП — автоматизированная система управления технологическим процессом.
