Идентичность как новый периметр

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

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

Зачем это знать защитнику

Раньше «защитить компанию» означало «обнести её стеной»: всё ценное внутри сети, снаружи — файрвол. Сегодня этой стены фактически нет. Приложения переехали в облако (почта, документы, CRM), сотрудники работают из дома и с телефонов, подключаются партнёры и подрядчики. Спрашивать «этот запрос пришёл изнутри нашей сети?» стало почти бессмысленно — «внутри» больше не существует как чёткое понятие. Зато у каждого запроса есть идентичность: кто его делает. Поэтому именно управление личностями и их правами превращается в главный контур обороны — логическое продолжение нулевого доверия из предыдущих уроков.

Почему периметр размывается

Несколько сдвигов одновременно разрушили старую модель «крепости».

Облако (SaaS). Корпоративные приложения живут у внешних провайдеров; защитить их «своим файрволом» невозможно — они в принципе за его пределами.
Удалённая работа. Сотрудник может войти откуда угодно и с любого устройства; «офисная сеть» перестала быть границей доверия.
Мобильность и BYOD. Личные телефоны и ноутбуки получают доступ к рабочим данным.
Интеграции. Сервисы общаются между собой по API через интернет, у каждого — своя машинная идентичность.

В сумме это значит: устойчивая, проверяемая личность — то немногое, что остаётся постоянным и контролируемым в каждом запросе.

SSO и поставщик идентичности (IdP)

Когда приложений десятки, у каждого свой логин и пароль — это и неудобно, и опасно: люди переиспользуют пароли, а отзыв доступа уволенного сотрудника превращается в обход всех систем. Решение — единый поставщик идентичности (IdP, Identity Provider) и единый вход (SSO, Single Sign-On). Пользователь аутентифицируется один раз у доверенного IdP, а приложения доверяют его подтверждению через стандартные протоколы.

// Поток единого входа (упрощённо)
Пользователь --> Приложение:   хочу войти
Приложение   --> IdP:          подтверди личность этого пользователя
IdP          --> Пользователь: пройди аутентификацию (пароль + MFA)
IdP          --> Приложение:   токен «это действительно сотрудник X, роль Y»
Приложение   --> Пользователь: доступ предоставлен

Безопасность здесь возрастает не вопреки удобству, а благодаря ему: MFA настраивается в одном месте, политики едины, а блокировка учётки в IdP мгновенно закрывает доступ ко всем приложениям сразу. Для машинного взаимодействия аналогично используют выдачу и проверку токенов (OAuth 2.0/OIDC) вместо «вечных» паролей в конфигах.

Условный доступ

Условный доступ (conditional access) — это правила, по которым система решает судьбу каждого входа, исходя из контекста, а не просто факта верного пароля. Движок политик взвешивает сигналы и выбирает действие:

ЕСЛИ пользователь в группе "финансы"
  И устройство управляемое и зашифрованное
  И вход из ожидаемой страны
  И оценка риска низкая
ТО разрешить доступ
ИНАЧЕ ЕСЛИ риск средний
ТО потребовать повторный MFA
ИНАЧЕ заблокировать и уведомить службу безопасности

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

Как это работает под капотом

В основе — доверие к утверждениям (claims). После аутентификации IdP выпускает подписанный токен, в котором перечислены утверждения: идентификатор пользователя, его роли и группы, способ и время входа, иногда оценка риска. Приложение не хранит пароли и не проверяет их само — оно лишь убеждается, что токен подписан доверенным IdP и ещё действителен, и из утверждений выводит, что разрешить. Доступ к ресурсам определяется ролями и атрибутами личности (RBAC/ABAC), а не сетевым адресом. Поскольку всё завязано на токенах с коротким сроком жизни и на централизованных политиках, права можно менять и отзывать мгновенно — это и делает идентичность управляемым «периметром».

Как защититься

Раз личность стала рубежом обороны, её и защищают в первую очередь:

MFA по умолчанию для всех учётных записей — компрометация пароля не должна давать вход.
Централизация через IdP/SSO — единые политики, единое и мгновенное отключение уволенных и скомпрометированных учёток.
Условный доступ — решения по контексту (устройство, геолокация, риск), повышение требований при аномалиях.
Минимальные привилегии и регулярный пересмотр прав — убирайте лишние и накопившиеся со временем доступы.
Особый контроль привилегированных учёток и машинных идентичностей: короткоживущие токены вместо «вечных» секретов в коде.
Мониторинг идентичности — следите за аномальными входами и всплесками отказов; компрометация учётки часто видна именно в журналах аутентификации.

Итоги

Облако, удалёнка и интеграции размыли сетевую границу — «внутри сети» перестало означать «доверенный».
Главным контролируемым свойством каждого запроса стала проверенная идентичность — она и есть новый периметр.
SSO/IdP централизуют вход и отзыв доступа; машинное взаимодействие переводят на токены вместо постоянных паролей.
Условный доступ принимает решение по контексту (устройство, место, риск), реализуя «проверяй каждый запрос» на уровне личности.