Облачное управление идентичностью: что это и как работает

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

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

Модели

Централизованная. Один справочник идентичностей, к которому обращаются все приложения. Просто в управлении, легко проверяется.

Федеративная. Несколько провайдеров доверяют друг другу. Применяется, когда нужно пускать пользователей из сторонних организаций, не заводя их у себя.

Смешанная. Собственный каталог во внутренней сети связан с облачным провайдером. Типичный вариант при постепенном переходе: часть систем остаётся на прежней схеме.

Многоарендная. Один сервис обслуживает несколько независимых организаций с полной изоляцией данных между ними. Обязательна для продуктов, у которых клиенты — компании.

Протоколы

Протокол	Задача
OpenID Connect	Аутентификация и единый вход
OAuth 2.0	Делегирование доступа приложениям
SAML	Аутентификация в корпоративных системах
SCIM	Синхронизация учётных записей
LDAP	Доступ к внутреннему каталогу

Практический смысл в том, что все они открытые. Провайдер, поддерживающий стандарты, может быть заменён; провайдер с собственным протоколом привязывает к себе навсегда.

Что это даёт

Доступность вне сети. Вход работает одинаково из офиса, из дома и в поездке — без построения защищённых каналов до внутренней инфраструктуры.

Отсутствие обслуживания. Обновления, отказоустойчивость и масштабирование — на стороне поставщика.

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

Единая точка контроля. Права, политики и журнал в одном месте вместо разрозненных настроек.

Масштабирование. Рост числа пользователей не требует пересмотра архитектуры.

О чём стоит подумать заранее

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

Где хранятся данные. Для многих организаций расположение серверов имеет значение — как из-за требований регуляторов, так и из соображений задержек.

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

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

На что смотреть при выборе

Поддержка стандартов. OIDC и OAuth 2.0 — минимум. Их отсутствие означает привязку к поставщику.

Способы аутентификации. Наличие passkeys, а не только SMS-кодов, определяет устойчивость к фишингу.

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

Журналирование. Записи должны содержать реальные адреса пользователей, а не адреса внутренних узлов, иначе разбор инцидента затруднён.

Гибкость ролевой модели. Права должны описываться так, как устроена ваша организация.

Многоарендность, если вы обслуживаете компании-клиентов.

Как это устроено в Keydee

Keydee — облачный провайдер идентичности с многоарендной моделью:

• Организации изолированы — пользователь одной компании не получает доступа к данным другой.
• Подключение по OIDC — единая схема для веба, мобильных приложений и API.
• Аутентификация: пароль, TOTP, passkeys; требование второго фактора задаётся политикой компании.
• Роли описывают права в границах организации и передаются приложениям в токене.
• Сессии управляемы: активные видны, любую можно завершить; приложения уведомляются о выходе.
• Журнал фиксирует события с реальным IP-адресом пользователя.

Главное

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

Меняется место, где всё это живёт, а не необходимость этим заниматься.