03 Июня 2024 11:49 | 03 Июн 2024 11:49 | |

Поделиться

Андрей Арефьев, Pragmatic Tools: Импортозамещение завершено тогда, когда последний контроллер Microsoft Active Directory остановлен

«Начинать импортозамещение необходимо с выбора корпоративного каталога»

CNews: Российский рынок сегодня находится в непрерывном процессе импортозамещения тех или иных зарубежных ИТ-продуктов и часто перед компаниями, по понятным причинам, встает вопрос обеспечения непрерывности бизнес-процессов с должным уровнем информационной безопасности. Какую роль играют корпоративные каталоги в ИТ-инфраструктуре с точки зрения эффективного функционирования предприятий и обеспечения информационной безопасности? Стоит ли недооценивать задачу трансформации корпоративного каталога и перехода на отечественные решения в текущих условиях?

Андрей Арефьев: Это важный вопрос, который в ряде случаев опрометчиво оставляется на «потом», и существует мнение, что в первую очередь нужно выбрать отечественную операционную систему, на которую планируется переход, а затем корпоративный каталог. Как правило, определенный корпоративный каталог может управлять только операционной системой того же вендора, и при подходе «от операционной системы» пользователь загоняет себя в угол и получается ситуация «когда хвост вертит собакой». При этом, многочисленные профессиональные дискуссии на тему, когда считать процесс импортозамещения завершенным, единогласно сводится к ответу: когда последний контроллер домена Microsoft Active Directory будет остановлен в компании. Все обоснованно с большой осторожностью и опаской относятся к этому моменту. Потому, что корпоративный каталог является основой информационной безопасности и факты, что через него могут взломать инфраструктуру, совершенно реальные и такие примеры были в российской практике. Когда контроллер домена скомпрометирован, злоумышленники получают доступ ко всей ИТ-инфраструктуре компании, что является чрезвычайно опасной ситуацией. Для нашей действительности — такие риски более, чем возможны, потому что, чем дольше затягивать процесс перехода на поддерживаемые вендором ОС и корпоративный каталог, тем больше вероятность, что потенциальные проблемы в инфраструктуре станут реальными.

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

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

CNews: Какие основные проблемы возникают при миграции данных из Microsoft Active Directory в другие корпоративные каталоги, и почему этот процесс так важен для компаний?

Андрей Арефьев: Одна из основных проблем при миграции на отечественные каталоги заключается в том, что на данный момент функциональность отечественных каталогов на 100% не замещает Microsoft Active Directory. Microsoft в течение 20 лет активно развивала свои технологии, и их достижения трудно даже технологически догнать за короткое время. При этом, даже у Microsoft, с более чем 20-ти летним опытом разработки и эксплуатации, возникают проблемы с репликацией данных между множеством контроллеров домена в реальных инсталляциях. Российские компании опасаются увеличения этих проблем при переходе на отечественные каталоги.

Наиболее часто трудности возникают в управлении рабочими станциями с помощью групповых политик и настройкой ограничений прав делегирования работы с каталогом. Эти аспекты часто недооцениваются отечественными вендорами. Кроме того, существуют риски, связанные с масштабируемостью.

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

CNews: Какие способы миграции данных существуют и используют российские компании сегодня? Насколько они оправданны?

Андрей Арефьев: Способов миграции несколько. Самый очевидный — ручной метод, когда ИТ-специалисты вручную переносят учетные записи. И второй — написание скриптов, по этому пути пошло большое количество интеграторов. Написать скрипты для одноразовой миграции объектов — это не решение проблемы клиента. Подход, использующий скрипты, как правило, не предоставляет контроль над полноценной миграцией — то есть подход «включил и молись». И оба этих способа не учитывают долгосрочного сосуществования корпоративных каталогов и не позволяют мигрировать всю необходимую информацию, например, пароли.

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

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

И не стоит забывать, что для реализации этого подхода используются недокументированные возможности Microsoft, что чревато внезапной поломкой репликации в совершенно непонятном статусе. Что делать в таком случае клиенту совершенно непонятно, нужно начинать все с начала? А если такая поломка сломает и MS AD?

«Если раньше была задача осуществлять разработку под один Microsoft, то теперь это нужно делать под, условно, десятки Линуксов»

CNews: Какие стратегии или лучшие практики вы рекомендуете компаниям, которые планируют начать процесс трансформации своих корпоративных каталогов, основываясь на вашем опыте? Какие вызовы стоят перед российскими разработчиками?

Андрей Арефьев: На мой взгляд, для безболезненной трансформации корпоративного каталога просто необходимо использование специализированных программных продуктов, которые обеспечат необходимые условия для эффективного сосуществования двух корпоративных каталогов (текущего и нового, для непрерывности бизнес-процессов) и их управления в рамках одной организации, должный уровень контроля процесса миграции с регулярной отчетностью, устойчивость к прерыванию процесса трансформации и гарантирует сохранение информационной̆ безопасности ИТ инфраструктуры. Именно таким продуктом является Pragmatic Tools Migrator.

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

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

Поэтому для отечественных разработчиков сделать свое ПО эффективным на различных Linux-платформах, это своего рода вызов. Если раньше была задача осуществлять разработку под один Microsoft, то теперь это нужно делать под, условно, десятки Линуксов, которые совместимы между собой. Это особенно актуально в области информационной безопасности, где интеграция с ядром операционной системы и корпоративным каталогом имеет большое значение. Разработка и адаптация системы безопасности под новую экосистему становится значительной головной болью для вендоров.

«Продуктовые аналоги на российском рынке мне не известны»

CNews: То есть вы разрабатывали решение исходя из потребностей рынка. При этом есть ли аналоги Pragmatic Tools Migrator?

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

Мы понимаем, что степень применимости нашего программного продукта в какой-то степени ограничена. Однако сейчас, в моменте, это решение крайне актуально, и мы видим интерес рынка. И совершенно точно, что оно все равно останется востребованными. Потому, что по разным причинам в компаниях может существовать набор разных корпоративных каталогов — компании сливаются между собой, покупаются другими игроками рынка, может снова меняться ИТ-инфраструктура. Это как раз те случаи, когда будут необходимы решения для трансформации корпоративного каталога. На удивление, даже решения по миграции Active Directory в Active Directory ранее были востребованы на рынке.

В свою очередь, мы планируем развивать наш продукт. В основу продукта заложена синхронизация разных корпоративных каталогов между собой. Уже сейчас мы получаем запросы рынка на синхронизацию FreeIPA с FreeIPA, или Samba с Samba, по разным причинам. И в этих запросах следующее: нужен «мост» между разными каталогами. Мы всегда рекомендуем сохранять процессы управления в Active Directory в неизменном виде до полного завершения миграции. Это подобно тому, как мост объединяет две стороны реки, обеспечивая им возможность сосуществования, коим и является Pragmatic Tools Migrator.

Если говорить о развитии нашего решения, работа не ограничивается только миграцией, реализованной в текущей версии. Мы также планируем расширять возможности в сторону класса IDM. С простым и надежным решением, позволяющим обеспечивать синхронизацию разных корпоративных каталогов, например, с HR-базами. И дополнительные возможности, например, миграцию файловых шар. Известно, что решения от Microsoft, такие как DFS, тоже распространены на российском рынке и продолжают сохраняться. Очевидно, что вместе с Active Directory эти сервера тоже надо будет куда-то мигрировать. И, собственно говоря, вопрос прав на файловых шарах и миграция всей экосистемы будет присутствовать, и мы тоже будем двигаться в этом направлении достаточно активно. Возможно, получат некоторое расширение для миграции каких-то других систем. Все будет сильно зависеть от запросов рынка.

А в данный момент понятно, что поддержка всех отечественных каталогов — это приоритет номер один.

Поделиться

Короткая ссылка