В проектах импортозамещения обычно много говорят о выборе самого каталога: какие функции он поддерживает, насколько хорошо работает с Linux и Windows, как переносить пользователей и группы. При этом вопрос, где этот каталог будет «жить» после миграции, часто остается за скобками. На мой взгляд, это архитектурная ошибка, поскольку размещение службы каталогов напрямую влияет на доступность инфраструктуры, модель администрирования, требования к резервированию и информационной безопасности. Это становится заметно в крупных организациях, где каталог перестает быть просто серверным приложением и становится одним из базовых элементов ИТ-ландшафта.
Поэтому при проектировании миграции я бы рекомендовала рассматривать вопрос размещения каталога одновременно с выбором целевой платформы. В этой статье разберу, что меняется при размещении службы каталогов on-premise и в облаке, какие компромиссы возникают у каждого подхода и почему универсального ответа здесь нет.
Раньше вопрос о том, где физически размещать корпоративный каталог, для большинства российских организаций возникал гораздо реже. Microsoft Active Directory традиционно разворачивалась в собственной инфраструктуре, чаще всего на физических или виртуальных серверах организации, и такой подход долгое время оставался стандартным сценарием. Сегодня, когда российские компании переходят на отечественные службы каталогов, этот выбор приходится делать осознанно. Облачные провайдеры активно продвигают свои платформы, вендоры отечественных каталогов публикуют облачные образы своих решений, а ИТ-директора оказываются между давлением регуляторов, ограниченными бюджетами и необходимостью не уронить инфраструктуру в процессе трансформации.
Разберем, что на самом деле стоит за каждым из вариантов.
Что такое служба каталогов и почему ее место размещения так важно?
Служба каталогов — это верифицирующий узел всей корпоративной инфраструктуры. Через нее проходят аутентификация по протоколу Kerberos, управление групповыми политиками, разграничение прав доступа к файловым серверам и сервисам, управление рабочими станциями.
Фактически каталог является точкой, от работоспособности которой зависит функционирование всего остального. Поэтому вопрос о том, где он размещен — на серверах в собственном машинном зале, в арендованном ЦОД или в публичном облаке — становится вопросом архитектурного решения с прямыми последствиями для безопасности, управляемости и соответствия требованиям регуляторов.
On-premise и контроль ценой ресурсов
Размещение службы каталогов на собственной инфраструктуре — исторически доминирующая модель в корпоративном сегменте. И на то есть веские основания.
Основание 1: Полный контроль над данными и инфраструктурой
Контроллеры домена* находятся в периметре организации. Служба информационной безопасности видит весь трафик, управляет доступом и может в любой момент провести аудит. Для организаций, работающих с персональными данными по 152-ФЗ, или субъектов критической информационной инфраструктуры (КИИ) по 187-ФЗ, это требование регулятора или внутренней политики безопасности.
С 1 марта 2026 года в силу вступили обновленные требования 187-ФЗ и Приказ ФСТЭК №117 — требования к аттестации информационных систем и ЦОД заметно ужесточились. Для значимых объектов КИИ первой категории это фактически означает, что размещение в публичном облаке требует отдельного обоснования и выполнения строгого перечня условий, включая физическое нахождение данных на территории РФ и разграничение ответственности с провайдером в договоре.
Основание 2: Предсказуемость производительности
Домен не является монолитной системой, а представляет собой распределенную среду, где несколько контроллеров домена реплицируют изменения между собой, и любое масштабное обновление (к примеру, изменение членства в группах для тысяч пользователей) порождает поток репликаций на все контроллеры одновременно.
В собственной инфраструктуре администратор управляет этой нагрузкой напрямую. В облаке появляется дополнительная переменная — качество и стабильность сетевого канала между площадками.
Обратная сторона on-premise очевидна:
капитальные затраты (CAPEX) на оборудование;
обслуживание;
обеспечение отказоустойчивости через резервные контроллеры домена;
организация физической защиты серверных помещений.
Вывод: относительно реальных потребностей для небольших организаций это может быть непропорционально дорого.
Облако для службы каталогов, или Гибкость, но с оговорками
Облачное размещение службы каталогов в российском контексте — сравнительно молодая практика, которая, тем не менее, набирает обороты. В феврале 2025 года «Группа Астра» перевела в облако службу каталогов ALD Pro, опубликовав готовые образы на маркетплейсе для быстрой инсталляции контроллеров домена и всех подсистем продукта в облачной инфраструктуре. Это позволяет развернуть полноценную доменную среду в несколько кликов, без закупки оборудования и долгого конфигурирования.
Модель OPEX
Модель OPEX** вместо CAPEX привлекательна для организаций, которые не хотят или не могут инвестировать в собственное железо. Облачный провайдер берет на себя физическую инфраструктуру, резервирование питания, охлаждение и базовую отказоустойчивость. Масштабирование — вопрос нескольких часов, а не недель закупки и монтажа оборудования.
Специфические риски облачного размещения
Однако у облачного размещения каталога есть специфические риски, которые в случае с другими сервисами менее критичны:
Каталог — это инфраструктурный сервис, от доступности которого зависит возможность сотрудников войти в систему, получить доступ к файлам и запустить рабочие приложения. Деградация сетевого канала между корпоративной сетью и облачным контроллером домена в часы пиковой нагрузки становится потенциальной невозможностью аутентификации для части пользователей (для которых визуально все предстает в виде медленной загрузки сайты).
Гибридная схема как компромисс
Архитекторы, работающие с облачным размещением каталога, как правило, рекомендуют гибридную схему: как минимум один контроллер домена остается локально на площадке организации и обслуживает аутентификацию в штатном режиме, а облачные контроллеры либо выступают резервными, либо обслуживают удаленные офисы и филиалы.
А что говорит закон?
Для значительной части российских организаций выбор места размещения каталога — это и техническое, и юридическое решение. Регулятор не запрещает использование публичных облачных платформ для объектов КИИ, однако при этом провайдер должен соответствовать нормативным требованиям, данные должны физически находиться на территории РФ, а ответственность должна быть разграничена в договоре.
Для организаций, не относящихся к КИИ, но работающих с персональными данными, ситуация несколько проще: 152-ФЗ позволяет оператору персональных данных доверить их обработку третьему лицу (облачному провайдеру) на основании поручения на обработку, которое оформляется в составе договорной документации. Главное требование — данные должны обрабатываться и храниться на территории РФ.
На практике это означает, что публичное облако иностранного провайдера для размещения корпоративного каталога российской организации фактически исключено. Выбор остается между собственной инфраструктурой, российскими облачными провайдерами с соответствующими сертификациями и аттестованными ЦОД.
Что выбирают на практике?
Универсального ответа нет, и это не уклонение от вопроса. Реальный выбор определяется несколькими факторами одновременно:
Организации с развитой собственной инфраструктурой, зрелой ИБ-службой и статусом субъекта КИИ, как правило, остаются на on-premise — просто потому что контроль над каталогом для них важнее операционной экономии. Государственные структуры и крупные промышленные предприятия в большинстве своем движутся именно по этому пути.
Средний бизнес и компании с распределенными офисами все активнее смотрят на гибридные схемы: локальный контроллер домена для основной площадки плюс облачные узлы для филиалов. Это снижает капитальные затраты, не жертвуя доступностью в критичном контуре.
Малые организации и те, кто только начинает проект импортозамещения и хочет быстро развернуть пилотную среду, используют облачные образы отечественных каталогов как стартовую точку с последующим переносом на собственные мощности по мере готовности инфраструктуры.
Отдельный вопрос, который возникает вне зависимости от выбранной модели размещения, — это сам процесс переноса данных из Microsoft AD в целевой каталог.
Независимо от того, разворачивается ли новая среда на собственных серверах или в облаке, миграция учетных записей, групп, прав доступа и паролей требует отдельного инструментария. Встроенные средства отечественных каталогов закрывают базовые сценарии, однако в инфраструктурах с тысячами объектов и сложной иерархией прав ручной перенос или самописные скрипты быстро становятся неуправляемыми. Специализированные инструменты решают эту задачу: автоматизируют перенос и обеспечивают синхронизацию между двумя каталогами на всем протяжении переходного периода, независимо от того, где физически размещена целевая среда.
Вывод
Вопрос о выборе облака или on-premise применительно к службе каталогов не имеет правильного ответа вне контекста конкретной организации, но точно требует осознанного решения с учетом регуляторных ограничений, архитектуры инфраструктуры, требований к доступности и реального бюджета.
Каталог — слишком фундаментальный компонент, чтобы принимать это решение по умолчанию или под влиянием маркетинга провайдера.
Терминология:
* DC (domain controllers) — физические или виртуальные серверы, на которых работает каталог;
**OPEX (Operating Expenditures) — текущие операционные расходы компании, необходимые для поддержания ее деятельности