Комментарии 8
оценивалась доля использования пяти различных методов аутентификации: "обычные" пароли, доменная аутентификация, RADIUS, SAML и OpenID Connect.
А где в этом списке асимметричная криптография: сертификаты и ssh-ключи?
Насколько я понимаю, смысл статьи именно в пользовательской аутентификации. Много ли бухгалтеров знают, что такое ssh-ключ?
Да, в первую очередь о ней. Идея была наглядно показать, что между привычной нам consumer-аутентификацией и корпоративной реальностью на сегодняшний день образовалась колоссальная пропасть, которую к великому сожалению не стремятся закрыть вендоры корпоративных решений и бизнес-систем. В итоге маркетинг некоторых решений по двухфакторной аутентификации часто формирует у заказчиков ложное представление о том, что достаточно "прикрыть" внешний периметр с VPN вторым фактором на базе TOTP, и всё будет хорошо. Этого было достаточно году эдак в 2010, но не сегодня. Сегодня нужно закрывать весь приклад, как внешний, так и внутренний, до которого удаётся дотянуться. А приклад-то и не готов.
Формально наличие OIDC в прикладе позволяет использовать его и для M2M-аутентификации (так называемой "межмашинной"). На практике же даже для аутентификации в API прикладной системы разработчики коробочных решений зачастую реализуют свою проприетарную схему аутентификации для получения даже обычного Access Token, не говоря уж о более сложных механизмах интеграции. Крайне редко в "коробках" для M2M предусмотрена интеграция с каким-то сторонним IdP. Чаще сам приклад считает, что он и есть IdP.
В статье прямым текстом было, что речь в том числе про VPN и GitLab. Впрочем, это осталось на картинке-диаграмме.
Справедливый вопрос, так как "обычный пароль" в нашей диаграмме выглядит как белая ворона на фоне SAML, RADIUS и OIDC. И логично было бы добавить и PKI-аутентификацию, раз уж мы заговорили про пароль.
Но есть нюанс - в исследовании речь про корпоративную аутентификацию, для которой первоочередным вопросом является "скручивание" прикладного ПО с централизованным корпоративным IAM-решением. PKI-аутентификация в случае успешной интеграции приклада с IAM становится зоной ответственности не самой прикладной системы, а IAM'а, даже при наличии функционала PKI-аутентификации в прикладной системе. При этом корпоративный IAM должен сделать так, чтобы для пользователей прикладной системы аутентификация по PKI работала плюс-минус универсально и идентично на фоне остальных прикладных систем.
Пароль же оставлен вот по какой причине. По-прежнему в энтерпрайзе из-за распространённости пароля он применяется в механизмах вроде Enterprise SSO и Web Authentication Proxy. Это когда используется подстановка имени пользователя и пароля в десктопное окошко аутентификации либо выполняется фоновый сабмит формы аутентификации с подстановкой креденшлов за пользователя. При этом за пользователя их хранит и подставляет IAM-система.
Штатно встроенная PKI-аутентификация де-факто есть в сетевых приложениях типа VPN/VDI и в операционных системах. По другим классам коробочных решений как наличие поддержки PKI, так и особенности работы PKI-аутентификации для пользователя - очень сильно разнятся, что не позволяет её рассматривать как полноценную замену корпоративному IAM'у. Обычно ей удобно закрыть какие-то локальные потребности в конкретной системе, но если систем с собственной PKI-аутентификацией становится три и более - это превращается в боль как для администраторов, так и для пользователей.
Исследование: лишь около 10% корпоративных систем поддерживают современную аутентификацию