4.7 Управление идентификацией и доступом

Обзор и мотивация

Каждый запрос, попадающий в ваши системы, несёт неявное утверждение: мне разрешено это делать. Управление идентификацией и доступом (IAM) это дисциплина решения о том, истинно ли это утверждение. Она отвечает на два отдельных вопроса, которые люди постоянно смешивают. Аутентификация доказывает, кто вы. Авторизация решает, что вам можно делать, когда вы это доказали. Держите эти две идеи раздельно в голове, и половина путаницы в этой области исчезнет.

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

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

Ключевые принципы

Аутентификация и авторизация разные проблемы. Доказательство идентичности и предоставление разрешения требуют раздельных проектов и раздельных рецензий.
Одна идентичность, много систем. Консолидируйтесь на единственном источнике истины на каждую популяцию идентичностей; разрастание каталогов это дефект безопасности.
Наименьшие привилегии по умолчанию. Начинайте с нулевого доступа и добавляйте намеренно, для людей и машин одинаково.
Каждые учётные данные временны. Предпочитайте краткоживущие автоматически выдаваемые учётные данные долгоживущим секретам.
Отзыв так же важен, как предоставление. Доступ, переживший свою нужду, чистый риск.
Устойчивость к фишингу побеждает запоминаемость. Двигайте аутентификацию к ключам доступа (passkeys) и аппаратно подкреплённым факторам.
Машины тоже идентичности. Нагрузки, конвейеры и сервисы нуждаются в управляемой идентичности, а не общих статических ключах.
Доступ это жизненный цикл, а не событие. Предоставляйте, пересматривайте и отзывайте по расписанию и доказывайте, что вы это делали.

Рекомендации

Разделяйте аутентификацию и авторизацию и централизуйте обе

Аутентифицируйтесь через одного провайдера идентичности (IdP), систему, проверяющую идентичность и выдающую токены, которым доверяют другие системы. Затем позвольте каждому приложению принимать собственные решения об авторизации по идентичности и атрибутам, которые несёт этот токен. Это разделение позволяет усилить аутентификацию один раз для всех, сохраняя тонкую логику разрешений рядом с данными, которые она защищает. Принимайте единый вход (SSO), когда одна аутентификация даёт доступ ко многим приложениям, чтобы у ваших людей был один сильный вход вместо сорока слабых. Федерация распространяет то же доверие через организационные границы, позволяя идентичностям партнёра получать доступ к вашим системам, не заставляя вас управлять их паролями.

Используйте современные протоколы по их настоящему назначению

Три стандарта выполняют большую часть работы, и у каждого своя задача. OpenID Connect (OIDC) это слой идентичности поверх OAuth 2.0; используйте его, чтобы ответить на вопрос кто этот пользователь для веб- и мобильного входа. OAuth 2.0 это рамка авторизации для делегированного доступа; используйте её, чтобы позволить приложению вызывать API от имени пользователя, ни разу не видя его пароль (глава 2.3). Security Assertion Markup Language (SAML) более старый федеративный стандарт на основе XML; он остаётся рабочей лошадью для корпоративного SSO в устоявшиеся бизнес-приложения. Частая ошибка тянуться к OAuth для прямой аутентификации. OAuth даёт доступ к ресурсам; OIDC стоит над ним, чтобы установить идентичность. Выбирайте OIDC для нового пользовательского входа, держите SAML там, где этого требует ваш корпоративный каталог, и не изобретайте собственный формат токена.

Делайте аутентификацию устойчивой к фишингу

Одни пароли неоправданы в масштабе. Требуйте многофакторной аутентификации (MFA), сочетающей то, что вы знаете, то, что у вас есть, и то, чем вы являетесь, для каждой человеческой учётной записи без исключений. Затем идите дальше слабых факторов: одноразовые коды по SMS поддаются фишингу и подмене SIM-карты. Сильное направление ключи доступа (passkeys) и лежащий в их основе стандарт WebAuthn (API браузера для аутентификации с открытым ключом), привязывающие вход к закрытому ключу, хранимому в оборудовании, и к реальному источнику (origin) сайта, так что фальшивая страница не может собрать ничего, что стоило бы украсть. Ключи доступа также беспарольные, за что вас поблагодарят пользователи. Воспринимайте восстановление учётной записи и сброс пароля как часть поверхности аутентификации, потому что атакующий, не способный победить вашу MFA, просто атакует поток сброса.

Управляйте жизненным циклом «пришёл-перешёл-ушёл» и отзывайте быстро

Идентичность это жизненный цикл. Пришедшему (joiner) нужен правильный доступ с первого дня. Перешедшему (mover), меняющему роли, нужен новый доступ и, что критично, нужно убрать старый, иначе он медленно накапливает ключи от всего здания. Ушедший (leaver) должен быстро потерять весь доступ, в идеале в течение минут после последнего дня, по каждой системе. Управляйте этим из авторитетного источника, обычно системы кадров, чтобы изменение статуса там автоматически предоставляло и отзывало нижестоящее. Автоматизируйте. Ручные контрольные списки при уходе всегда что-то упускают, а упущенная учётная запись та, что появляется в отчёте об инциденте.

Выберите модель авторизации и выражайте её как политику-как-код

Предоставляйте разрешения через управление доступом на основе ролей (RBAC), где вы назначаете разрешения ролям должностных функций и людей ролям, потому что его просто осмыслять и легко проверять. Тянитесь к управлению доступом на основе атрибутов (ABAC) там, где нужны решения с учётом контекста по атрибутам вроде отдела, классификации данных, местоположения или времени суток. Большинство зрелых организаций ведут гибрид: RBAC для грубых предоставлений, ABAC для тонких условий. Что бы вы ни выбрали, выражайте авторизацию как политику-как-код: правила, записанные в версионируемой, тестируемой, подлежащей рецензии форме, а не вбитые щелчками в консоли. Политика-как-код делает решения о доступе проверяемыми, сравнимыми и согласованными между средами и позволяет протестировать изменение разрешения до его выпуска.

Принуждайте наименьшие привилегии доступом точно в срок и PAM

Применяйте принцип наименьших привилегий: каждая идентичность получает минимум нужного доступа и ничего сверх. Постоянная привилегия враг, потому что разрешение, предоставленное навсегда, это разрешение, доступное любому атакующему, попавшему на эту учётную запись в любое время. Предпочитайте доступ точно в срок (just-in-time, JIT), когда человек запрашивает повышенные права на ограниченное окно, получает их после утверждения и автоматически теряет, когда окно закрывается. Для самых опасных учётных записей принимайте управление привилегированным доступом (PAM): систему, прячущую административные учётные данные в хранилище, посредничающую в привилегированных сессиях и записывающую их и выдающую повышение по требованию. Цель нулевой постоянный административный доступ, чтобы даже полностью скомпрометированный ноутбук не давал ничего долговечного.

Давайте машинам и нагрузкам настоящую идентичность

Люди лишь половина ваших идентичностей. Сервисы, конвейеры, контейнеры и функции все аутентифицируются перед чем-то, и слишком часто делают это долгоживущим секретом, вставленным в файл конфигурации. Заменяйте статические ключи управляемой идентичностью нагрузок: краткоживущими учётными данными, автоматически выдаваемыми нагрузке по тому, где она работает и чем является. Используйте взаимный TLS (mTLS), когда обе стороны соединения предъявляют сертификаты, для аутентификации между сервисами. Держите оставшиеся секреты в выделенном менеджере секретов с ротацией, никогда в исходном коде или образах (глава 4.2). Краткоживущие автоматически ротируемые учётные данные нагрузок устраняют самую частую причину утечек облачных учётных данных.

Сделайте идентичность плоскостью управления и пересматривайте доступ непрерывно

В архитектуре нулевого доверия (глава 4.1) идентичность место, где политика решается и принуждается, поэтому вкладывайтесь туда соответственно. Затем замкните контур проверками доступа, также называемыми рецертификацией: по расписанию владелец каждой системы подтверждает, что каждому человеку и машине с доступом он по-прежнему нужен, и отзывает то, что они не могут обосновать. Подавайте каждое событие аутентификации и авторизации в след аудита, отвечающий на вопрос кто к чему получал доступ, когда и по какой политике (глава 4.6). Проверки доступа то, как вы боретесь с накоплением привилегий, медленным накоплением разрешений, ни одно из которых по отдельности не выглядело неразумным, но вместе делающих учётную запись слишком могущественной.

Компромиссы: плюсы и минусы

Решение	Плюсы	Минусы
Централизованный IdP с SSO	Один сильный вход, согласованная политика, лёгкий аудит	Единая точка отказа; сбой запирает всех
RBAC	Просто, проверяемо, знакомо	Взрыв ролей; грубо для чувствительных к контексту потребностей
ABAC	Тонко, с учётом контекста, масштабируется с атрибутами	Труднее проектировать, тестировать и осмыслять
Ключи доступа / WebAuthn	Устойчивы к фишингу, беспарольные, сильные	Потоки восстановления и потери устройства требуют аккуратного проекта
Доступ точно в срок	Почти нулевая постоянная привилегия	Трение; нужны быстрые надёжные пути утверждения
Федерация с партнёрами	Нет внешнего управления паролями; ограниченное доверие	Доверие зависит от собственной гигиены партнёра
Долгоживущие ключи сервисов	Тривиально просто настроить	Склонны к утечкам; главная причина взломов учётных данных

Центральное напряжение между безопасностью и трением. Каждое средство контроля, сжимающее поверхность атаки (MFA на всём, повышение JIT, короткие сроки жизни учётных данных), также добавляет шаг в чей-то день, а люди обходят слишком мешающие средства. Разрешайте это, делая безопасный путь лёгким: SSO, чтобы сильная аутентификация была одним касанием, ключи доступа, чтобы не набирать пароль, и автоматическое предоставление, чтобы правильный доступ просто появлялся. Тратьте бюджет трения там, где радиус поражения наибольший, на привилегированный и эксплуатационный доступ, и держите повседневный доступ почти без трения.

Вопросы для обсуждения с командой

Как быстро вы реально можете отозвать весь доступ человека, уходящего сегодня, и как вы знаете, что это сработало? Скорость отзыва прямая мера зрелости вашей идентичности, потому что ушедший, чей доступ задерживается, это немониторимая учётная запись с реальными разрешениями. В большой организации с десятками несвязанных систем честный ответ нередко «мы не уверены», а пробел обычно в приложениях, которые так и не были подключены к центральному провайдеру идентичности. Принесите настоящий недавний уход и проследите каждую систему, которой он мог коснуться, проверяя временные метки того, когда каждый доступ действительно закончился. Решите цель, например полный отзыв в течение часа после изменения статуса в системе кадров, и инструментируйте её, чтобы доказывать, а не надеяться. Если какая-то система опирается на то, что кто-то вспомнит ручной шаг, это учётная запись, которую использует будущий взлом.
Где у вас всё ещё есть постоянный привилегированный доступ и долгоживущие статические учётные данные и что потребовалось бы, чтобы их устранить? Постоянные права администратора и постоянные ключи сервисов два актива, которые атакующие хотят больше всего, потому что они долговечны и могущественны. Составьте опись каждого человека с постоянным включённым эксплуатационным или административным доступом и каждого сервиса, аутентифицирующегося статическим ключом, затем честно спросите, какие из них могли бы перейти на повышение точно в срок или краткоживущую идентичность нагрузок. Конкурирующее соображение эксплуатационный страх: команды держат постоянный доступ, потому что моменты экстренного доступа с ним кажутся безопаснее, поэтому нужно сделать экстренное повышение быстрым и надёжным, прежде чем забирать постоянные права. Принесите список на обсуждение и ранжируйте пункты по радиусу поражения, нацеливаясь сначала на эксплуатационный и административный доступ. Конечное состояние нулевой постоянный административный доступ и ни одного статического ключа, переживающего единственное развёртывание.
Есть ли у вас одна авторитетная идентичность на человека и на нагрузку или несколько и чего вам стоит это разрастание? Разрастание каталогов, когда один и тот же человек существует как пять учётных записей в пяти системах с дрейфующими атрибутами, место, где рождаются пробелы отзыва и осиротевший доступ. Консолидация на единственном источнике истины на популяцию идентичностей одно из вложений наибольшего рычага, доступных большой команде, потому что каждое нижестоящее средство контроля зависит от знания, что две записи один и тот же человек. Принесите опись ваших хранилищ идентичности и отобразите, какие авторитетны, а какие удобные копии, которыми никто не управляет. Компромисс в том, что консолидация большая непривлекательная миграция, конкурирующая с работой над функциями за внимание. Решите, оправдывает ли постоянная цена разрастания в боли аудита и риске взлома финансирование этой миграции сейчас, а не после следующего инцидента.
Действительно ли ваши сильнейшие факторы аутентификации устойчивы к фишингу и что мешает вам окончательно отказаться от паролей? Фактор, который атакующий не может использовать для фишинга, тот, что прекращает кражу учётных данных как вашего доминирующего пути взлома, а ключи доступа, привязанные к WebAuthn, единственный широко развёртываемый вариант, проходящий эту планку. В большой организации честная картина обычно смешанная: ключи доступа для одних, одноразовые коды по SMS для других и длинный хвост унаследованных приложений, всё ещё принимающих один пароль. Конкурирующее соображение реально, потому что ключи доступа переносят трудную проблему на восстановление и потерю устройства, а неуклюжий поток восстановления становится новой мягкой мишенью, на которую атакующий просто переключается. Принесите числа покрытия по типу фактора, список приложений, всё ещё откатывающихся к паролю, и спроектированный путь восстановления учётной записи, которому вы доверяли бы против решительной попытки социальной инженерии. В корпоративной и государственной среде привяжите цель к любому предписанному уровню гарантии, поскольку система высокой гарантии, всё ещё допускающая фишингуемый фактор, имеет и пробел соответствия, и пробел безопасности.
Как вы решаете, какой доступ получает каждая идентичность, и можете ли вы сравнить, протестировать и доказать это решение до выпуска? Разрыв между «кто-то вбил разрешения щелчками в консоли» и «рецензированной версионируемой политикой» это разница между моделью доступа, которую можно проверить, и той, за которую можно только извиняться. Для большой команды давление в том, чтобы позволить каждому приложению растить собственные заказные правила, что тихо порождает взрыв ролей на стороне RBAC и нетестируемые условия на стороне ABAC, пока никто не может сказать, что на самом деле разрешает данное предоставление. Конкурирующее соображение скорость поставки, потому что выражение авторизации как политики-как-кода добавляет шаг рецензии, которого нет у щелчка по консоли, а команды под сроком обижаются на трение, пока первый проваленный аудит или избыточно широкое предоставление не докажет их правоту за них. Принесите настоящее изменение разрешения и проследите, как оно было бы предложено, протестировано, рецензировано и откатано, плюс подсчёт, сколько у вас ролей и сколько из них никто не может объяснить. В корпоративной и государственной среде аудитор попросит вас показать, кто именно мог получить доступ к записи и по какому правилу в данный день, и только сравнимая тестируемая политика отвечает на это без аврала.
Когда проверка доступа в последний раз отозвала что-то реальное и кто отвечает, когда накопление привилегий остаётся без контроля? Проверки доступа средство контроля, борющееся с медленным накоплением разрешений, ни одно из которых по отдельности не выглядело неразумным, а проверка, никогда ничего не отзывающая, театр проверок, производящий бумаги вместо безопасности. В большой организации режим отказа печать «не глядя»: владельцы систем рецертифицируют сотни записей за один присест, одобряя все, потому что по-настоящему оценивать каждую утомительно, а стимул сохранить доступ сильнее стимула его урезать. Конкурирующее соображение в том, что содержательные проверки стоят времени владельцев и иногда ломают чей-то рабочий процесс, когда пропадает доступ, на который тот тихо опирался, поэтому проверку нужно делать целевой и управляемой риском, а не недифференцированным списком. Принесите долю отзывов вашего последнего цикла, среднее число прав на человека и свидетельства того, кто владеет рецертификацией каждой системы. В корпоративной и государственной среде назовите подотчётное должностное лицо для каждой проверки и ритм, которого от него требуют, потому что накопление привилегий, которое никто не обязан ловить, именно то условие, которое эксплуатируют и аудиторы, и атакующие.

Взгляд по секторам

Стартап. Покупайте идентичность, не стройте её. Единый размещённый провайдер идентичности с SSO, обязательными ключами доступа и отзывом в один щелчок даёт горстке инженеров корпоративного уровня положение за плату на место. Опирайтесь на встроенную идентичность нагрузок провайдера, чтобы в вашем конвейере не было ни одного долгоживущего облачного ключа, и используйте OIDC и OAuth 2.0 готовыми, а не изобретайте обработку токенов, сопровождение которой вам не потянуть.

Малый бизнес. Без специалиста по идентичности в штате отдавайте предпочтение SSO и MFA, уже входящим в оплачиваемые инструменты, и включайте их, а не ищите отдельную платформу. Воспринимайте проблему «пришёл-перешёл-ушёл» как короткий письменный контрольный список, привязанный к тому, кто отвечает за найм, и предпочитайте ключи доступа, потому что они снимают бремя службы поддержки по сбросу паролей, на которое вы не можете выделить никого. Избегайте общих входов, поскольку это дешёвая привычка, позже делающая невозможными атрибуцию и отзыв.

Крупная организация. Работа это консолидация и управление по многим каталогам и командам: один авторитетный провайдер идентичности, управляемый системой кадров, автоматизированные потоки «пришёл-перешёл-ушёл», RBAC для должностных функций с ABAC для контекста и управление привилегированным доступом с записью сессий. Выражайте авторизацию как политику-как-код, чтобы изменения были сравнимыми и тестируемыми, проводите плановые проверки доступа, которые действительно отзывают, и стандартизируйте интерфейс, чтобы приложения подключались к центральной идентичности, а не растили каждое свой вход.

Государственный сектор. Правила закупок, прозрачность и публичная подотчётность определяют проект. Привязывайте аутентификацию к аппаратным учётным данным вроде смарт-карт PIV или CAC, задавайте уровни гарантии идентичности по NIST SP 800-63, чтобы системы повышенного риска требовали факторов повышенной гарантии, и храните неизменяемые журналы аудита, отвечающие, кто именно к чему получал доступ и когда. Публикуйте простыми словами обращение с идентичностью для граждан, держите стеки идентичности клиентов и персонала раздельными и обеспечьте, чтобы каждое привилегированное действие в чувствительной системе проходило через посредника и записывалось для аудиторов, которые спросят.

Примеры

Стартап. Стартап из двадцати человек не может укомплектовать команду идентичности, поэтому покупает её. Каждый сотрудник входит через единственного размещённого провайдера идентичности с SSO в почту, хостинг кода, облачную консоль и внутреннее приложение, а ключи доступа обязательны, так что паролей для фишинга нет. Отзыв в один щелчок: отключение человека в провайдере идентичности обрывает доступ везде сразу. Для собственного продукта они используют OIDC для пользовательского входа и OAuth 2.0, чтобы интеграции вызывали их API с ограниченными токенами. Аутентификация сервиса в облаке использует встроенную идентичность нагрузок провайдера, так что нигде в их конвейере нет ни одного долгоживущего облачного ключа. Это стоит скромную плату на место и покупает им положение идентичности сильнее, чем у многих корпораций.

Крупная организация. Международный банк десятилетие копил четыре каталога и сотни приложений, одни федеративные по SAML, другие со своими локальными входами. Он финансирует программу консолидации: один авторитетный провайдер идентичности, управляемый системой кадров, с автоматизированными потоками «пришёл-перешёл-ушёл», предоставляющими при найме и отзывающими в течение минут после увольнения. RBAC покрывает стандартные должностные функции, а ABAC принуждает правила местонахождения данных и допуска для трансграничного доступа. У администраторов нет постоянного эксплуатационного доступа; они запрашивают повышение точно в срок через систему управления привилегированным доступом, записывающую каждую сессию. Ежеквартальные проверки доступа вынуждают владельцев систем рецертифицировать или отзывать, а каждое решение выражено как политика-как-код, так что аудиторы могут сравнить, что именно изменилось и когда.

Государственный сектор. Федеральное ведомство выдаёт смарт-карты персональной проверки идентичности (PIV) и военный эквивалент, общую карту доступа (CAC), своему персоналу, так что аутентификация привязана к аппаратным учётным данным, а не паролю. Его программа идентичности следует федеральному подходу управления идентичностью, учётными данными и доступом (FICAM) и задаёт уровни гарантии идентичности по руководству Национального института стандартов и технологий NIST SP 800-63, так что системы повышенного риска требуют учётных данных повышенной гарантии. Сервисы для граждан используют отдельный стек идентичности клиентов на более низком уровне гарантии с сильной MFA. Проверки доступа и неизменяемые журналы аудита напрямую питают свидетельства непрерывной авторизации ведомства (глава 4.6), а каждое привилегированное действие в секретной системе проходит через посредника и записывается.

Бизнес-обоснование: мотивы, ROI и TCO

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

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

Антипаттерны и ловушки

Осиротевшие учётные записи. Доступ, переживший человека или цель, особенно немониторимые сервисные учётные записи и забытые подрядчики.
Постоянный администратор везде. Всегда включённый привилегированный доступ вместо повышения точно в срок, дающий любой скомпрометированной учётной записи администратора долговечную силу.
Долгоживущие статические ключи. Учётные данные сервисов, вставленные в конфигурацию или CI, никогда не истекающие и в итоге утекающие.
Разрастание каталогов. Один человек как много неуправляемых учётных записей, так что ни одно изменение никогда не распространяется полностью.
Общие учётные записи. Учётные данные, используемые несколькими людьми, разрушающие атрибуцию и делающие отзыв невозможным.
SMS как сильный фактор. Воспринимание поддающихся фишингу одноразовых кодов с подменой SIM как достаточной MFA.
Взрыв ролей. Столько узких ролей RBAC, что модель становится непроверяемой и никто не знает, что даёт роль.
Отзыв как ручной контрольный список. Человеческие шаги при уходе, неизбежно упускающие ту единственную важную учётную запись.
OAuth для аутентификации. Воспринимание токена доступа как доказательства идентичности вместо использования OIDC.
Театр проверок. Рецертификации доступа, проштампованные без чьей-либо настоящей оценки необходимости.

Модель зрелости

Уровень 1, Начальный: У каждого приложения свой вход. Пароли без последовательной MFA. Предоставление и отзыв ручные, реактивные и медленные; осиротевшие учётные записи копятся. Учётные данные сервисов долгоживущие статические ключи. Нет проверок доступа; разрешения предоставляются и больше не пересматриваются.
Уровень 2, Развитие: SSO покрывает основные приложения через центрального провайдера идентичности, но покрытие неравномерно по командам. MFA обязательна для большей части человеческого доступа. Существует базовый RBAC. «Пришёл-перешёл-ушёл» частично автоматизирован из системы кадров. Часть привилегированных учётных записей в хранилище. Проверки доступа происходят время от времени и непоследовательно.
Уровень 3, Стандартизация: Консолидированный провайдер идентичности авторитетен для персонала, с автоматизированным предоставлением и быстрым отзывом, принуждаемыми по организации. Устойчивая к фишингу MFA стандартна и документирована. RBAC плюс ABAC выражены как политика-как-код. Управление привилегированным доступом с записью сессий на месте. Идентичность нагрузок заменяет большинство статических ключей. Плановые проверки доступа принуждаются и проверяются по письменной политике, которой следует каждая команда.
Уровень 4, Управление: Программа идентичности измеряется относительно базовых значений и управляется данными. Вы отслеживаете время отзыва от изменения статуса в системе кадров до полного отзыва, покрытие MFA и ключами доступа по популяциям, число учётных записей с постоянным привилегированным доступом, число всё ещё используемых долгоживущих статических ключей, числа осиротевших учётных записей и доли отзывов проверок доступа. Метрики несут цели, например полный отзыв в течение часа и ноль новых чистых предоставлений постоянного администратора, а нарушение порога запускает расследование, а не пожатие плеч. Изменения авторизации тестируются в конвейере, а каждое решение «пускать или нет» по предоставлению доступа управляется свидетельствами, а не привычкой.
Уровень 5, Оркестрация: Идентичность непрерывно улучшаемая плоскость управления для нулевого доверия, интегрированная с безопасностью, риском и планированием «пришёл-перешёл-ушёл» по организации. Ключи доступа по умолчанию, а пароли выводятся. Нулевая постоянная привилегия достигается повышением точно в срок, а все нагрузки используют краткоживущие автоматически ротируемые учётные данные и mTLS. Авторизация полностью политика-как-код. Проверки доступа непрерывны и управляются риском, отзыв почти мгновенный, и каждое решение автоматически производит свидетельства аудита. Модель адаптируется по мере сдвигов сигналов риска, ужесточая или ослабляя доступ динамически, а не по фиксированному ритму.

Идеи для обсуждения

Что потребовалось бы для достижения нулевого постоянного административного доступа и какой путь экстренного доступа сделал бы это безопасным?
Где ABAC стоит своей сложности в вашей среде против оставания на простом RBAC?
Насколько агрессивно следует выводить пароли в пользу ключей доступа и какой поток восстановления их заменит?
Какие приложения всё ещё вне вашего центрального провайдера идентичности и что удерживает их там?
Как давать партнёрам и клиентам ограниченный доступ, не наследуя их гигиену безопасности?
Какая единственная метрика лучше всего отражает скорость вашего отзыва доступа и измеряете ли вы её сегодня?

Главные выводы

Аутентификация доказывает, кто вы; авторизация решает, что вам можно. Проектируйте и рецензируйте их раздельно.
Консолидируйтесь на одном авторитетном провайдере идентичности с SSO; разрастание каталогов дефект безопасности, а не удобство.
Автоматизируйте жизненный цикл «пришёл-перешёл-ушёл» и делайте отзыв быстрым и доказуемым.
Используйте OIDC для пользовательского входа, OAuth 2.0 для делегированного доступа к API и SAML там, где этого требует корпоративный каталог; не используйте OAuth как аутентификацию.
Двигайте аутентификацию к устойчивым к фишингу ключам доступа и WebAuthn; требуйте MFA повсюду и воспринимайте слабые факторы как временную меру.
Принуждайте наименьшие привилегии доступом точно в срок и управлением привилегированным доступом; стремитесь к нулевым постоянным правам администратора.
Давайте машинам настоящую идентичность с краткоживущими учётными данными нагрузок и mTLS; устраняйте долгоживущие статические ключи.
Делайте идентичность плоскостью управления для нулевого доверия (глава 4.1) и замыкайте контур непрерывными проверками доступа и свидетельствами аудита (глава 4.6).

Источники и дополнительное чтение

National Institute of Standards and Technology, SP 800-63: Digital Identity Guidelines (identity assurance, authentication, and federation levels)
National Institute of Standards and Technology, SP 800-207: Zero Trust Architecture
National Institute of Standards and Technology, SP 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations
National Institute of Standards and Technology, SP 800-53: Security and Privacy Controls, Access Control (AC) and Identification and Authentication (IA) families
The OAuth 2.0 Authorisation Framework, IETF RFC 6749, and the OAuth 2.0 Security Best Current Practice
OpenID Connect Core 1.0 specification, OpenID Foundation
Security Assertion Markup Language (SAML) 2.0 specification, OASIS
Web Authentication (WebAuthn) Level 2, W3C Recommendation, and FIDO2 / FIDO Alliance passkey specifications
Federal Identity, Credential, and Access Management (FICAM) architecture and playbooks, U.S. General Services Administration
FIPS 201, Personal Identity Verification (PIV) of Federal Employees and Contractors
Open Policy Agent (OPA) documentation, Cloud Native Computing Foundation (policy-as-code for authorisation)