Соучредитель и директор по продуктам компании Strata Identity Эрик Лич рассказывает на портале eWeek о практике оркестровки, помогающей справиться с проблемами переноса идентификационных данных в облако.

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

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

Знайте свои идентификационные данные

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

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

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

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

Еще одним распространенным препятствием является обеспечение согласованности и качества данных. Например, большинство организаций используют различные источники идентификационных данных, такие как Active Directory (AD), LDAP, базы данных SQL, а также приложения, содержащие идентификационные данные. Все эти источники данных необходимо рационализировать и интегрировать. Если данные идентификации и сопутствующие атрибуты отображаются неправильно, организация может столкнуться с проблемой неадекватного доступа к приложениям и сервисам.

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

Хуже того, некоторые организации пытаются избежать этих проблем, просто откладывая переход в облако. Зачастую это подрывает проекты цифровой трансформации, направленные на повышение эффективности и конкурентоспособности.

Оркестровка перехода в облако

Для решения этих проблем необходимы другое мышление и другие инструменты. Одной из лучших практик является использование уровня оркестровки для организации перехода между устаревшими и облачными системами идентификации. Это заменяет масштабную миграцию гибким, постепенным переносом идентификационных данных и приложений в облачную систему идентификации.

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

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

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

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

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

Например, больше не нужно переписывать приложения, чтобы они функционировали в облаке и хорошо работали с такими протоколами, как OpenID Connect и SAML. Обычно переписывание приложений для работы с этими современными системами идентификации и стандартными протоколами отнимает столько времени и средств, что блокирует весь прогресс.

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