Да, в первую очередь о ней. Идея была наглядно показать, что между привычной нам consumer-аутентификацией и корпоративной реальностью на сегодняшний день образовалась колоссальная пропасть, которую к великому сожалению не стремятся закрыть вендоры корпоративных решений и бизнес-систем. В итоге маркетинг некоторых решений по двухфакторной аутентификации часто формирует у заказчиков ложное представление о том, что достаточно "прикрыть" внешний периметр с VPN вторым фактором на базе TOTP, и всё будет хорошо. Этого было достаточно году эдак в 2010, но не сегодня. Сегодня нужно закрывать весь приклад, как внешний, так и внутренний, до которого удаётся дотянуться. А приклад-то и не готов.
Формально наличие OIDC в прикладе позволяет использовать его и для M2M-аутентификации (так называемой "межмашинной"). На практике же даже для аутентификации в API прикладной системы разработчики коробочных решений зачастую реализуют свою проприетарную схему аутентификации для получения даже обычного Access Token, не говоря уж о более сложных механизмах интеграции. Крайне редко в "коробках" для M2M предусмотрена интеграция с каким-то сторонним IdP. Чаще сам приклад считает, что он и есть IdP.
Справедливый вопрос, так как "обычный пароль" в нашей диаграмме выглядит как белая ворона на фоне SAML, RADIUS и OIDC. И логично было бы добавить и PKI-аутентификацию, раз уж мы заговорили про пароль.
Но есть нюанс - в исследовании речь про корпоративную аутентификацию, для которой первоочередным вопросом является "скручивание" прикладного ПО с централизованным корпоративным IAM-решением. PKI-аутентификация в случае успешной интеграции приклада с IAM становится зоной ответственности не самой прикладной системы, а IAM'а, даже при наличии функционала PKI-аутентификации в прикладной системе. При этом корпоративный IAM должен сделать так, чтобы для пользователей прикладной системы аутентификация по PKI работала плюс-минус универсально и идентично на фоне остальных прикладных систем.
Пароль же оставлен вот по какой причине. По-прежнему в энтерпрайзе из-за распространённости пароля он применяется в механизмах вроде Enterprise SSO и Web Authentication Proxy. Это когда используется подстановка имени пользователя и пароля в десктопное окошко аутентификации либо выполняется фоновый сабмит формы аутентификации с подстановкой креденшлов за пользователя. При этом за пользователя их хранит и подставляет IAM-система.
Штатно встроенная PKI-аутентификация де-факто есть в сетевых приложениях типа VPN/VDI и в операционных системах. По другим классам коробочных решений как наличие поддержки PKI, так и особенности работы PKI-аутентификации для пользователя - очень сильно разнятся, что не позволяет её рассматривать как полноценную замену корпоративному IAM'у. Обычно ей удобно закрыть какие-то локальные потребности в конкретной системе, но если систем с собственной PKI-аутентификацией становится три и более - это превращается в боль как для администраторов, так и для пользователей.
Проблема, которую пытаемся помочь решить чеклистом?
Во-первых, помочь сформировать и ощутить реальную потребность в тематике защиты учётных данных и связанных с этим процессов.
Во-вторых, понять, какое/какие решения закроют какие из вопросов, а какие на самом деле нет.
Идея чеклиста и статьи простая - выбрать те вопросы, которые вызывают больше всего опасений, фрустрации и прочей боли в нижней части спины. Далее по этим вопросам посмотреть, какое из решений позволит закрыть эти вопросы.
Это можетпомочь подобрать и внедрить тот класс решений, который действительно полезен для бизнеса и его текущих задач.
Если вы о «99 проблем» и картинке - то это всё обман, чтобы набрать классы на основе песни Jay-Z "99 problems".
Ланка шикарное место! Я бы еще добавил информации о еде. Замечательные блюда из свежей рыбы и лобстеров, которых только-только выловили! А фрукты! До Москвы они никогда не доходят в том виде, в каком они есть там!
Прекрасно, что в приложении сделали запись по расписанию, крайне полезная опция! Наконец-то сервис стал обрастать практичными фишками, при этом без «свистелок» :) Спасибо!
Мысль верна. Если хочется кататься с друзьями под музыку — можно кататься на машине. И музычка, и алкообщение.
Езда на велике с орущими колонками сильно напоминает гопника/школьника, слушающего музычку на мобилке. Какой усилитель ни выбери — будешь раздражать окружающих.
В корне не согласен. На практике выходит наоборот.
Понимание типов данных и их применения при разработке — да, очень важная вещь. Но на начальном этапе ребёнок хочет реализовать свои амбиции как можно скорее. И непонимание некоторых особенностей работы с типами может стать для ребёнка непреодолимой преградой. Чем проще и быстрее, но не в ущерб семантики языка, можно будет что-то делать — тем лучше для ребёнка.
Описаны хорошие, полезные вещи. Несомненно, они могут зажечь интерес к программированию.
Немного от темы, немного к юмору.
Однажды решили развивать Интернет в школах и в итоге школьники заполонили весь Интернет.
Теперь решили развивать программирование в школах. Что будет дальше?
Да, в самый левый.
Да, в первую очередь о ней. Идея была наглядно показать, что между привычной нам consumer-аутентификацией и корпоративной реальностью на сегодняшний день образовалась колоссальная пропасть, которую к великому сожалению не стремятся закрыть вендоры корпоративных решений и бизнес-систем. В итоге маркетинг некоторых решений по двухфакторной аутентификации часто формирует у заказчиков ложное представление о том, что достаточно "прикрыть" внешний периметр с VPN вторым фактором на базе TOTP, и всё будет хорошо. Этого было достаточно году эдак в 2010, но не сегодня. Сегодня нужно закрывать весь приклад, как внешний, так и внутренний, до которого удаётся дотянуться. А приклад-то и не готов.
Формально наличие OIDC в прикладе позволяет использовать его и для M2M-аутентификации (так называемой "межмашинной"). На практике же даже для аутентификации в API прикладной системы разработчики коробочных решений зачастую реализуют свою проприетарную схему аутентификации для получения даже обычного Access Token, не говоря уж о более сложных механизмах интеграции. Крайне редко в "коробках" для M2M предусмотрена интеграция с каким-то сторонним IdP. Чаще сам приклад считает, что он и есть IdP.
Справедливый вопрос, так как "обычный пароль" в нашей диаграмме выглядит как белая ворона на фоне SAML, RADIUS и OIDC. И логично было бы добавить и PKI-аутентификацию, раз уж мы заговорили про пароль.
Но есть нюанс - в исследовании речь про корпоративную аутентификацию, для которой первоочередным вопросом является "скручивание" прикладного ПО с централизованным корпоративным IAM-решением. PKI-аутентификация в случае успешной интеграции приклада с IAM становится зоной ответственности не самой прикладной системы, а IAM'а, даже при наличии функционала PKI-аутентификации в прикладной системе. При этом корпоративный IAM должен сделать так, чтобы для пользователей прикладной системы аутентификация по PKI работала плюс-минус универсально и идентично на фоне остальных прикладных систем.
Пароль же оставлен вот по какой причине. По-прежнему в энтерпрайзе из-за распространённости пароля он применяется в механизмах вроде Enterprise SSO и Web Authentication Proxy. Это когда используется подстановка имени пользователя и пароля в десктопное окошко аутентификации либо выполняется фоновый сабмит формы аутентификации с подстановкой креденшлов за пользователя. При этом за пользователя их хранит и подставляет IAM-система.
Штатно встроенная PKI-аутентификация де-факто есть в сетевых приложениях типа VPN/VDI и в операционных системах. По другим классам коробочных решений как наличие поддержки PKI, так и особенности работы PKI-аутентификации для пользователя - очень сильно разнятся, что не позволяет её рассматривать как полноценную замену корпоративному IAM'у. Обычно ей удобно закрыть какие-то локальные потребности в конкретной системе, но если систем с собственной PKI-аутентификацией становится три и более - это превращается в боль как для администраторов, так и для пользователей.
Проблема, которую пытаемся помочь решить чеклистом?
Во-первых, помочь сформировать и ощутить реальную потребность в тематике защиты учётных данных и связанных с этим процессов.
Во-вторых, понять, какое/какие решения закроют какие из вопросов, а какие на самом деле нет.
Идея чеклиста и статьи простая - выбрать те вопросы, которые вызывают больше всего опасений, фрустрации и прочей боли в нижней части спины. Далее по этим вопросам посмотреть, какое из решений позволит закрыть эти вопросы.
Это может помочь подобрать и внедрить тот класс решений, который действительно полезен для бизнеса и его текущих задач.
Если вы о «99 проблем» и картинке - то это всё обман, чтобы набрать классы на основе песни Jay-Z "99 problems".
www.ivideon.com/tv/v1/b48beeddde1790de73b24b40d610b31a/1310720/
Присмотрелся — видео на сайте идёт по HTTPS. Но не заметил на сайте упоминаний о безопасности хранимого у них видео. Может кто повнимательнее?
алкообщение.Езда на велике с орущими колонками сильно напоминает гопника/школьника, слушающего музычку на мобилке. Какой усилитель ни выбери — будешь раздражать окружающих.
Понимание типов данных и их применения при разработке — да, очень важная вещь. Но на начальном этапе ребёнок хочет реализовать свои амбиции как можно скорее. И непонимание некоторых особенностей работы с типами может стать для ребёнка непреодолимой преградой. Чем проще и быстрее, но не в ущерб семантики языка, можно будет что-то делать — тем лучше для ребёнка.
Немного от темы, немного к юмору.
Однажды решили развивать Интернет в школах и в итоге школьники заполонили весь Интернет.
Теперь решили развивать программирование в школах. Что будет дальше?