Этот кейс будет полезен для тех, кто планирует централизованное управление пользователями и данными в корпоративных сервисах, в том числе продуктах Atlassian (Jira и Confluence), через Microsoft Active Directory.
Что для Jira-админа хорошо, то для системного администратора камень преткновения
Оптимизация управления доступами и повышение безопасности с помощью централизованной системы управления учетными данными
Основная проблематика безопасности корпоративных данных при оффбординге сотрудников
Основная проблематика миграции пользователей между пользовательскими каталогами
Поиск вариантов переноса пользователей из одной директории (Jira ID) в другую (AD)
— Миграция пользователей при помощи плагина
— Перенос пользователей при помощи SQL запроса
— Перенос пользователей кастомным скриптом на Java (финальный вариант)
— Призрачные пользователи при клонировании данных с Jira ID в Microsoft Active Directory
Итоги миграции и управления учетными данными
Что для Jira-админа хорошо, то для системного администратора «здесь мои полномочия все» камень преткновения
В крупных организациях за управление доступами обычно отвечает специализированная команда или отдел, занимающийся вопросами безопасности. Если команда состоит из нескольких человек, они могут быть разделены на подгруппы, каждая из которых отвечает за определенный сервис или уровень безопасности. Если же в организации работает только один системный администратор, он берет на себя всю ответственность за управление доступами.
По умолчанию, пользователи в корпоративные аккаунты Jira и Confluence добавляются независимо от других корпоративных сервисов. Это означает, что Jira-администратор самостоятельно добавляет пользователей и полностью управляет ими: деактивирует учетные записи уволенных сотрудников и создает новые для новых коллег.
Этот подход (автономная раздача доступов к продуктам Atlassian) удобен и быстр для небольших компаний с количеством сотрудников до 30 человек.
По итогу, в такой компании выполняется двойная работа по администрированию учетными записями:
- и системному администратору приходится настраивать пользователей на уровне всей организации (создавая почтовые ящики, которые затем используются для предоставления доступа к другим сервисам компании: порталам, внутренним социальным сетям, системе контроля версий кода, системе бронирования ресурсов, планировщикам встреч и так далее);
- и Jira-админу приходится настраивать доступы в Jira и Confluence отдельно.
Оптимизация управления доступами и повышение безопасности с помощью централизованной системы управления учетными данными
Недавно мы столкнулись с подобным кейсом. Сисадмин выдавал все необходимые доступы, кроме Jira и Confluence, а Jira-админ уже отдельно заводил пользователей в эти два сервиса. Нам необходимо было исключить эту двойную работу и повысить безопасность корпоративных данных путем централизации управления пользователями и ресурсами при помощи LDAP.
LDAP (Lightweight Directory Access Protocol) — это протокол доступа к каталогам, который используется для централизованного хранения и управления информацией о пользователях и ресурсах в сети. Например, есть компания с множеством сотрудников, каждый из которых имеет учетную запись для входа в компьютеры, почтовые ящики и другие системы. LDAP позволяет хранить эту информацию в одном месте, как в большой книге с данными.
Чтобы добавить нового сотрудника в систему без LDAP, нужно вручную создать учетную запись для него на каждом компьютере и в каждой системе. С LDAP — создается (соответственно, отключается) единая запись о сотруднике с указанием, к каким ресурсам он имеет доступ. Это делает процесс добавления пользователя во все системы намного проще и менее подверженным ошибкам.
В качестве LDAP выбрали Microsoft Active Directory (AD) — это сервис для управления идентификацией и доступом к ресурсам в сетевой среде Windows.
Требовалось подключить управление доступами через AD к сервисам Atlassian и регулярно актуализировать каталог пользователей. Далее вход в Jira и Confluence осуществляется с использованием единых ко всем системам корпоративной почты и пароля, выданных одним центром управления (специалистом или IT-отделом).
Основная проблематика безопасности корпоративных данных при оффбординге сотрудников
Основная проблема компаний, которые не используют LDAP и SSO, является то, что при отключении уволенных сотрудников от корпоративных сервисов, их доступ по почте к Jira не прекращается. Более того, при удалении сисадмином учетных записей сотрудника вручную, может возникнуть пропуск отключения от какого-либо сервиса.
Факт, что корпоративную почту утилизировали, не означает, что почтой и паролем нельзя воспользоваться на третье стороннем сервисе — можно. Как раз таки в те моменты, когда с опозданием удалили доступ или вообще пропустили удалить учетную запись.
LDAP и SSO существуют для того, чтобы эти корпоративные почты централизованно отключать во всех сервисах контура компании.
Основная проблематика миграции пользователей между пользовательскими каталогами
Обычно в компании, когда устанавливают Jira, подключают ее к существующей Active Directory. Однако в нашем случае требовалось обратное: Jira была установлена ранее, а решение о подключении AD было принято позже.
При интеграции Active Directory с Jira Internal Directory по инструкции от Atlassian столкнулись с проблемой — после подключения AD к Jira у нас создались совершенно новые пользователи, которые вообще не были никак связаны с прошлой активностью сотрудников в Jira (назначенные задачи, комментарии, доступы к проектам и др.).
Пользователи не перетекли в новую директорию, как ожидалось (баг, который у нас воспроизвелся), а был создан новый набор пользователей по данным, которые хранятся в MS AD. К сожалению, хоть они и выглядели одинаково, те же имена и почты, эти пользователи не имели никакой связи с учетками, которыми пользовались сотрудники ранее. То есть Петров Вася c почтой vpetrov@zzzz.ru из Jira != (не равно) Василий Петров c почтой vpetrov@zzzz.ru из AD.
Когда сотрудники пробовали войти в Jira с использованием новой учетной записи, им открывался просто пустой экран, в результате чего они не могли продолжить работу.
Поиск вариантов переноса пользователей из одной директории (Jira ID) в другую (AD)
Перед нами стала задача объединить две учетные записи в одну таким образом, чтобы это произошло незаметно для пользователей и не вызвало случайного повреждения данных.
В Jira у нас было 400 пользователей, в Confluence – 700. Если бы количество пользователей было около 20-30 человек, мы могли бы переназначить задачи вручную и справиться в течение недели. Однако, с таким большим количеством пользователей, это невозможно сделать вручную. Нам необходимо было централизованно переключить всех пользователей, чтобы компания могла продолжать работу без прерываний.
Мы начали искать варианты.
Миграция пользователей при помощи плагина
В начале нашего поиска мы обратились к уже готовым решениям на маркетплейсе Atlassian. Среди всех нашли плагин (User Management от TechTime), который мог нам помочь. По описанию он делал то, что в принципе и было нужно. Но получилось, что именно на Jira у него возникали внутренние ошибки и проблемы (операции зависали посреди выполнения). Никаких результатов по итогу мы не получили, так как по логам ошибок нельзя было разобраться что пошло не так.
Мы отбросили этот вариант, так как на переписку с вендором не было времени.
Перенос пользователей при помощи SQL запроса
Мы обратились к базе данных заказчика, для изучения структуры пользователей в Jira. Провели анализ всех связей между 21 таблицей (пользователи, группы, комментарии, задачи и др.), определив в какие из связей необходимо внести изменения, чтобы перенести все данные с одного пользователя на другого.
В результате исследования, мы хотели разработать специальный SQL запрос, который переместит всю активность с первого профиля пользователя (в Jira ID) во второй его профиль (в созданный через связь в MS AD). Однако, в момент разработки запроса, стало понятно, что это решение очень рискованное и опасное: вероятно было упустить таблицу и, тем самым, найти не всю информацию о пользователе.
Любые манипуляции с базой данных делать крайне нежелательно (именно в плане изменений, удалении подобных операций) — лучше только смотреть.
Мы решили отказаться от этого способа, из-за больших рисков потерять и «поломать» больше, чем достигнуть.
Перенос пользователей кастомным скриптом на Java (финальный вариант)
Чтобы не допустить никаких деструктивных операций, как удаление данных или прямые изменения в БД, было решено разработать собственный скрипт с использованием языка Java для клонирования пользователей из директории Jira в новую директорию Active Directory. Для этого мы исследовали Java API Jira, программу Crowd (для управления пользователями в экосистеме Atlassian) и Confluence.
Этот подход позволил пользователям авторизоваться через AD используя свои доменные пароли, где вся истории аккаунтов были сохранены: задачи, комментарии и полный функционал; будто ничего и не изменилось.
Вместо того чтобы создавать новых пользователей через AD автоматически, скрипт перенес текущих пользователей из Jira в директорию, где должны были создаться новые пользователи от Active Directory.
Скрипт помогает мигрировать пользователей между директориями с сохранением всех пользовательских настроек.
Призрачные пользователи при клонировании данных из Jira ID в Microsoft Active Directory
Кастомный скрипт, конечно, может быть полезным инструментом, однако, невозможно предвидеть абсолютно все аспекты и поведение клонированной базы пользователей и их данных. Корректность переноса может стать ясной только при активном использовании этой БД.
Например, позже мы столкнулись с проблемой отображения «призрачных» пользователей — пользователей, которых нигде в системе не было, но появлялись при упоминании в комментариях задач. Эта проблема возникла из-за специфической ошибки кэша пользователей. Однако, нам удалось решить эту проблему благодаря «dark» фиче Jira, которую знают только 5% всех Jira-админов.
Напишите нам, если хотите чтобы ваша Jira была в надежных руках.
Итоги миграции и управления учетными данными
Чем раньше вы приступите к внедрению LDAP, тем легче будет осуществить миграцию и процесс интеграции с Jira. Если компания уже имеет сотни сотрудников, рекомендуем не откладывать данный процесс. Это поможет:
- оптимизировать процесс и снизить время затраченное на предоставление доступов.
- создать централизованную систему управления доступом из одной точки.
- снять часть рутинных задач с Jira-админа, освободив его время для более важных и стратегических задач.
- не запоминать и не хранить множество паролей от разных систем (для пользователей).
- повысить безопасность данных компании и предотвратить их утечку за ее пределы.
Если у вас возникли вопросы или вам нужна помощь с подключением Jira к каталогу LDAP — напишите нам!
P.S. Мы также можем помочь с приобретением лицензий на продукты Atlassian и другие зарубежные сервисы.
