IAM-системы (Identity and Access Management) обеспечивают централизованную аутентификацию для бизнес-приложений и управление учётными данными. Успех построения систем централизованной аутентификации достигается за счёт грамотной организации внедрения. Опишем нюансы этого процесса.
- Введение
- Необходимость доработки ИС для поддержки используемых протоколов аутентификации
- Какие сессии пользователей прекращать и каким образом
- Используем многофакторную аутентификацию
- Учитываем сценарии работы системы
- Построение единого каталога пользователей
- Что внедрять сначала: IDM или IAM?
- Внедрение IAM-системы — это постановка новой практики
- Выводы
Введение
Одним из решений для снижения рисков в ИБ, связанных с парольной аутентификацией, а также для уменьшения количества заявок в службу техподдержки, обусловленных операциями с паролями, может быть внедрение в компании подхода Single Sign-On (SSO). Благодаря SSO можно пройти аутентификацию один раз, а затем получать доступ к защищённым ресурсам без необходимости повторно вводить учётные данные. При этом первый вход в систему выполняется с использованием многофакторной аутентификации. Для реализации подхода Single Sign-On крупные компании строят системы централизованной аутентификации на базе решений класса Identity and Access Management (IAM).
При подготовке этой статьи мы сопоставили ведущие практики и рекомендации со своим опытом внедрения IAM-решений, выбрали основные темы, которым не всегда уделяется должное внимание, но которые существенно влияют на общий успех построения систем централизованной аутентификации.
Основные рекомендации:
- Проведите «инвентаризацию» всех задействованных информационных систем (ИС) на предмет возможности интеграции с IAM-решениями, составьте планы по доработке этих систем и определите очерёдность их подключения к IAM.
- Реализуя функциональность Single Sign-On, не забудьте о Single Logout.
- Проработайте различные сценарии аутентификации в зависимости от типа пользователя, устройства, с которого осуществляется доступ, местонахождения пользователя, типа приложения.
- Если информация о пользователях у вас находится в разных хранилищах, проработайте вопросы построения единого каталога пользователей.
- Если думаете, с чего начать — с IDM или IAM, — начните с IAM.
Ключевая рекомендация:
- Построение системы централизованной аутентификации — это не внедрение софта, это постановка новой практики. Здесь в приоритете не скорость, а направление и непрерывное совершенствование системы. Не пытайтесь сделать систему наскоком, делайте «по кусочку».
Необходимость доработки ИС для поддержки используемых протоколов аутентификации
При построении системы централизованной аутентификации вам, вероятнее всего, придётся дорабатывать свои информационные системы. Наиболее часто встречающейся доработкой является обеспечение поддержки протоколов аутентификации SAML, OpenID Connect, OAuth 2.0.
Что делать на этапе подготовки к проекту? Необходимо обследовать планируемые к подключению ИС на предмет наличия там поддержки указанных протоколов, а также, если её нет, возможности доработки систем под нужды проекта. Часто случается, что внутри компании нет компетенции по доработкам или продукт может дорабатываться только вендором; этот нюанс может существенно повлиять на бюджет и сроки проекта. После обследования ИС составьте список очерёдности их подключения к IAM. В первую очередь стоит подключать те, которые уже готовы к интеграции и не нуждаются в доработке.
Какие сессии пользователей прекращать и каким образом
Во время построения системы централизованной аутентификации основной фокус направлен на обеспечение входа в приложения. При этом часто вопросу выхода уделяется значительно меньше внимания, а иногда про него просто забывают. Однако обеспечение корректного выхода в некоторых случаях может быть сложнее, чем разработка функциональности входа. Это происходит потому, что необходимо учитывать различные типы сессий пользователей.
При входе в приложения с помощью системы централизованной аутентификации пользователь имеет отдельные сессии в каждом приложении и отдельный сеанс в системе централизованной аутентификации. При этом запуск процесса выхода из приложений может произойти по разным причинам. Например, это может быть нажатие кнопки «Выйти» в каком-то из приложений или на странице системы централизованной аутентификации. Помимо того что пользователь может сам выйти из приложения, администратор может прекратить его сеанс в приложении или в системе централизованной аутентификации. Другая вероятность состоит в том, что сеанс пользователя истекает, если тот бездействует или находится в системе слишком долго.
В связи с этим важно принимать во внимание, какие сессии пользователей прекращать (или не прекращать) при наступлении указанных событий. Отвечает ли требованиям вариант, когда при наступлении любого из перечисленных событий в любом приложении прекращаются все сессии пользователя? Или необходимо прекращать сеансы выборочно в зависимости от события и типа приложения?
Также не стоит забывать о проработке вопроса о том, куда отправлять пользователя после выхода, на какую страницу. Если вы, например, отправляете пользователя на домашнюю страницу приложения, которая переадресует его на систему централизованной аутентификации, в которой у этого же пользователя всё ещё есть действующий сеанс, он будет возвращён обратно в приложение с созданным для него новым сеансом. Соответственно, вы получите увеличение запросов в службу поддержки с жалобами на то, что выход из системы не работает.
Не думайте только о Single Sign-On: не забывайте о Single Logout. Уделите этому вопросу достаточно внимания на этапе проектирования системы централизованной аутентификации.
Используем многофакторную аутентификацию
В системах централизованной аутентификации с реализованной функциональностью единого входа (Single Sign-On) пользователь предъявляет свои данные однократно. После успешной аутентификации ему обеспечивается сквозной доступ во все подключённые приложения. Вполне логично, что первичная аутентификация должна выполняться более надёжными способами. Это достигается с помощью многофакторной аутентификации для первого входа.
В случае если использовать многофакторную аутентификацию для всех пользователей не представляется возможным, необходимо провести ранжирование подключённых приложений по степени критической значимости. Тогда, используя для первого входа пароль, пользователь будет иметь доступ к некоторым малозначимым приложениям. При необходимости доступа ко значимому приложению система централизованной аутентификации попросит пользователя предъявить дополнительный фактор аутентификации, тем самым повышая уровень доверия к его сессии.
Именно поэтому так важно предусмотреть многофакторную аутентификацию на ранних этапах. Вполне возможно, вам придётся немного расширить бюджет проекта по построению системы централизованной аутентификации для закупки оборудования и ПО, обеспечивающего «многофакторку».
Учитываем сценарии работы системы
При проектировании системы централизованной аутентификации необходимо учитывать всё многообразие сценариев, которые могут возникнуть при работе системы.
Зачастую сценарии можно разбить на следующие категории:
- Тип пользователя (работник компании, клиент компании, работник компании-партнёра, подрядчик и т. д.).
- Устройство пользователя (стационарный компьютер, ноутбук, смартфон и т. д.).
- Местонахождение пользователя (офис, дом и т. д.).
- Тип доступа (веб, VPN, клиентское приложение и т. д.).
- Тип ресурса или приложения (корпоративное приложение, ресурсы партнёрской компании и т. д.)
Каждый отдельный сценарий может содержать как одну категорию, так и несколько.
На этапе проектирования системы централизованной аутентификации необходимо определить релевантные для вашей ситуации сценарии. Затем для каждого сценария решается, какой способ в системе централизованной аутентификации будет для него использоваться. Так, для внешних пользователей вполне возможна аутентификация с помощью социальных сетей. Для сотрудников компаний-партнёров вы, вероятно, предпочтёте настроить доверительные отношения между вашими системами централизованной аутентификации. Тогда работники компаний-партнёров будут аутентифицироваться «у себя» и получать доступ к вашим ресурсам.
В целом, сначала спроектируйте функциональную часть без привязки к какому-то программному продукту. Продукт вы выберете на следующем шаге.
Построение единого каталога пользователей
Служба каталогов (LDAP) является значимой частью инфраструктуры для аутентификации пользователей. Системы централизованной аутентификации используют службу каталогов в качестве хранилища информации о пользователях. Для работы системы SSO крайне рекомендуется иметь единое хранилище такой информации.
Если у вас крупная компания и пользователи раскиданы по разным службам каталогов, посмотрите, насколько трудно будет реализовать единое хранилище учётных записей. Если это «подъёмная» задача, то создайте этот единый каталог и дайте системе аутентификации с ним работать. Принцип разделения обязанностей, когда каждый занят своим делом, работает тут лучшим образом: каталог хранит пользователей, а система аутентификации удостоверяет личности, не заботясь о соотнесении (маппинге) учётных записей из разных каталогов.
Используйте несколько каталогов, когда есть значительные ограничения на построение единого каталога. Например, по корпоративным политикам безопасности нельзя делать так, чтобы во внутреннем каталоге (обычно это Active Directory) находились записи внешних пользователей. Тогда рядом с AD ставится отдельный каталог, в котором ведутся учётные записи для таких лиц. В этом случае функция IAM-систем, позволяющая использовать информацию о пользователях из нескольких каталогов, вам в помощь. Но не надо пытаться внутри системы аутентификации её силами объединять данные из нескольких десятков доменов, не имеющих доверительных отношений. Пусть каждый функциональный компонент занимается своим делом.
Что внедрять сначала: IDM или IAM?
Правильного или неправильного ответа на этот вопрос нет. Принято считать, что следует начать с IDM. Логика проста: надо навести порядок в учётных записях и правах доступа, а потом уже браться за аутентификацию.
Но всё же мы предлагаем начать с IAM-решений и служб каталогов. Почему? Проекты IDM, как правило, являются долгими и помимо внедрения технологии включают в себя автоматизацию множества бизнес-процессов, а зачастую — и их изменение. Понимание принципов работы бизнес-процессов, обсуждение их изменения, само изменение — всё это требует времени. В итоге проекты по IDM могут растянуться на годы, и может так случиться, что вам уже будет не до централизованной аутентификации.
Реализация платформы IAM обычно требует меньше времени. Разве не имеет смысла начинать работу над более коротким проектом для получения результата? К тому же, выполнив проект по IAM, вы сможете лучше подготовиться к проекту по IDM. Например, в ходе обоих проектов происходит подключение одних и тех же информационных систем, только в проекте IAM — с целью аутентификации, а в IDM — для управления учётными записями. Эти темы граничат друг с другом, и уже на этапе предварительного обследования информационной системы на проекте IAM могут выясниться требования по их доработке и для проекта IDM.
Начиная обсуждать в своей организации IDM, неплохо бы уже иметь функционирующую IAM-систему.
Внедрение IAM-системы — это постановка новой практики
В целом, к построению системы централизованной аутентификации не стоит подходить как к простому внедрению софта. По сути, вы не разворачиваете софт, а в рамках компании выстраиваете новую практику. Для её успеха необходимы не только софт и «железо», но новые компетенции в вашей команде, изменение организационных процессов.
Построение практики централизованной аутентификации меняет жизнь пользователей ваших информационных систем, эксплуатационного персонала. Да, рядовым пользователям вряд ли надо будет учиться чему-то новому. Исключением может быть случай, если вы вместе с IAM-решением стали использовать многофакторную аутентификацию. Тогда пользователей надо будет обучить работе с устройствами аутентификации.
Гораздо сложнее обстоят дела, например, с владельцами информационных ресурсов. Им необходимо понимать, что теперь их приложения должны обращаться за аутентификацией в новую централизованную систему. Новые приложения должны будут проектироваться уже исходя из требований по интеграции с ней. Информацию об изменениях необходимо будет донести до владельцев систем, снабдить их сведениями, которые помогут им перейти на новую практику. Для ИТ-инфраструктурщиков добавится новый критический сервис, отказ которого может парализовать работу всей компании. Это, естественно, потребует соответствующих изменений в работе и компетенциях эксплуатационного персонала.
В связи с этим к построению системы централизованной аутентификации применимы основные рекомендации по постановке практик. Не пытайтесь сделать всё в один момент. Например, не старайтесь подключить к системе все приложения сразу. Возьмите несколько систем, потренируйтесь на них. Не надо пытаться охватить все сценарии работы сразу. В приоритете — не скорость, а направление и непрерывность совершенствования системы. Не ждите немедленных успехов: это — новый образ жизни, а не какое-то разовое мероприятие.
Выводы
Система централизованной аутентификации на базе IAM-решений является критической системой в ИТ-ландшафте множества компаний. Любой сбой в её работе может привести к тому, что множество бизнес-приложений окажутся недоступными для пользователей.
Однако выгоды, которые можно получить в результате, перевешивают эти риски. Потому не стоит бояться внедрять их у себя в компании. На рынке достаточно достойных IAM-решений, и к текущему моменту уже накоплена практика их внедрения. Дорогу осилит идущий. Дерзайте!
