[Информационная безопасность] Хроники SSO: банк, токены и немного магии
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет! Меня зовут Артем Ивлев, и я занимаюсь архитектурой идентификации клиентов банка ВТБ. Наша задача — ответить на вопрос, кто использует наш банковский сервис: мобильный или интернет-банк, голосового помощника или просто один из многочисленных офисов. Для этого есть множество инструментов — и я хочу рассказать про становление одного из них. ПрологНа дворе 2019 год, экосистема банка растет как на дрожжах, и все острее нам нужны единая точка входа для клиентов и провайдер идентификации. А есть только каталог учетных записей и отдельные решения разных команд для аутентификации.Требований к тому, как все должно выглядеть, у нас еще не было. При этом мы сразу же начали говорить об аутентификации физических лиц не только в онлайн-банке, но и на ресурсах партнеров. Та самая кнопочка «Войти через ВТБ». 
Примерно так будет выглядеть вход через ВТБИз этого следовало, что нам нужно взять максимально универсальное решение и начать его использовать. В процессе использования мы смогли бы выяснить, что нам точно нужно, каких функций не хватает и т. д.Выбираем, по какому пути пойдемПрошерстив интернет, покурив магические квадраты Гартнера, начали смотреть на опенсорс-решения с поддержкой в России:• WSO2 Identity Server• Keycloak• OpenAMПо отзывам в сети и документации наиболее универсальным нам показалось решение от WSO2 с шиной для возможности подключения множества провайдеров аутентификации, провайдеров данных пользователя и т. д.
Архитектура WSO2 Identity ServerПервый прототип мы показали еще в 2019 году на общем выездном демо розничного бизнеса.Серебряная пуля есть (извини, Брукс) — это токенВ первую очередь мы поняли, что в OAuth 2 нам лучше всего использовать ID-токен JWT, который не требует обращения к серверу аутентификации для проверки при каждом запросе. Если вкратце, JWT — это пирамидка из трех частей:1. Заголовок (HEADER) рассказывает, что это за токен, как подписан и кем выдан.2. Тело (PAYLOAD) — набор параметров — позволяет узнать, какому сервису и для какого пользователя выдан этот токен, как долго этот токен будет жить.3. Криптографическая подпись (SIGNATURE) дает возможность проверить, что данные в теле токена не были изменены и что токен выдан именно тем сервером идентификации, которому мы доверяем.
Структура JSON Web Token (JWT)Все эти части — это одна большая строка, разделенная точками на блоки. Первые два блока кодированы с помощью алгоритма Base64.Использование ID-токена JWT сильно упростило жизнь: больше не нужно было при каждом запросе от мобильного устройства или браузера ходить в базу и проверять, кому и когда выдан токен. Вся информация — в самом токене. Достаточно просто поставить перед потребителями API Gateway, который проверит подпись токена с помощью открытого ключа.Как доработать пулю напильникомТокен, выпущенный на X минут, будет действителен, даже если пользователь нажмет «Выход» или от систем службы безопасности банка поступит сигнал срочно разлогинить этого пользователя из приложения. Решение давно придумали — хранить списки отозванных токенов и сверяться с ними на уровне API Gateway. Да, это тоже сверка с базой, но здесь множество существенно меньше и легко реализуется на кеше Redis с TimeToLive.Как сделать, чтобы злоумышленники не могли украсть токен, выданный определенному мобильному приложению или браузеру пользователя? Ведь технически можно утащить у пользователя что-то из браузера и даже из приложения. То есть нужно сделать так, чтобы злоумышленник, даже украв токен, не смог им воспользоваться.
Кадр из заставки мультсериала «Симпсоны»Как обычно, задача не нова и ее решение «уже было в "Симпсонах"» ( «Южный парк»). Делаем безопасную куку (HttpOnly, SameSite, Secure) и кладем в нее UUID. Потом от этого UUID делаем хеш, например, CRC32, — и кладем его уже в тело JWT. И все. Теперь достаточно для каждого запроса проверять, что хеш от нашей куки равен тому, который записан в тело токена. Безопасную куку утащить сложнее, так что пара «токен — кука» дает нам достаточно уверенности. Адаптивная аутентификация, или Почему нам пришлось идти своим путем В процессе входа пользователя много дополнительной магии. Это и проверки пользователя, его устройства, статистики по входам, географии, и аудит действий, и открытие сессий в бэк-системах, и уточнение необходимости второго фактора, и выбор этого самого второго фактора (СМС, push, что-то еще).Это и есть задача адаптивной аутентификации. И, с одной стороны, использование модуля позволило все эти задачи вписывать с помощью скриптового интерфейса WSO2 IS, но, с другой стороны, невозможно было реализовать красивый API для мобильных устройств или SPA. Дело в том, что вся адаптивная аутентификация идет на серверном уровне как генерация интерфейсов с помощью JSP. Это сложно адаптировать даже для современной веб-разработки, не говоря уже о API для мобильного приложения.После первых прототипов и попыток натянуть универсальность на пожелания коллег из мобильной и веб-платформ мы поняли, что эту часть придется переписывать. Для мобильного приложения и интернет-банка мы решили реализовать всю логику с помощью всего лишь одной ручки API/oauth2/token — в зависимости от входящих параметров она выдавала токен или ошибку с просьбой перейти на нужный шаг запроса второго фактора. Реализацию бизнес-логики решили внести прямиком в grant_type, параметр /oauth2/token, отвечающий на вопрос о нужном типе аутентификации.В итоге у нас получилась стройная логика. Есть сервис-провайдер — потребитель аутентификации. У него есть настройки, среди которых — набор grant type. Тем самым мы отлично понимаем, кто и с помощью каких логик входа к нам может прийти. Все, что не роняет прод, делает нас сильнееСледующая проблема, которую мы поймали, — невысокая производительность из-за довольно сложного использования базы данных для сценария аутентификации, в котором мы контролируем «что и почему» на уровне нашего кода. WSO2 IS слишком много читает и пишет в базу. Пришлось нам снова переписывать часть логики генерации токена. Убрали сессии из PostgreSQL в Redis. Это на порядок снизило нагрузку на базу. 
Комментарии излишни:)Но, как оказалось, этого тоже мало. Сама зависимость от базы для столь критичного сервиса — далеко не лучшее решение. В случае падения или недоступности базы (где хранятся в основном настройки и выданные токены, сессии-то мы уже оттуда убрали) мы не могли пустить пользователя в банк. Добавили проверку в случае недоступности базы — выдавать токены в аварийном порядке, если их не удается продлить через пять минут. То есть пользователи все равно смогут работать в приложении банка — но только пока жив первый выданный токен.Следующим шагом был переход от двух ЦОДов в режиме active-active к режиму active-passive, что снизило риски рассинхрона PostgreSQL и Redis. В худшем случае при падении ЦОД какой-то части пользователей придется перезайти в приложение.Ну и как финальный гвоздь в код выдачи токенов — решение полностью переписать остатки WSO2 IS. Последняя версия уже вообще не общается с базой при аутентификации пользователя. Остался только Redis, который хранит сессии аутентификации и выданные в них JWT и refresh-токены. Что дальше? Новые гориSSOнтыПри выдаче токена осталось так мало от вендорного WSO2 IS, что в скором времени мы сможем перейти от монолита, который умеет слишком много, к микросервисам, которые умеют только то, что нам нужно и с нужной нам производительностью. Сейчас у нас есть вход в банковское приложение в мобильной и веб-версиях. Но этого мало. Ведь у ВТБ есть множество других продуктов. Это «Мультибонус», «ВТБ Мобайл» и десятки, если не сотни, других наших проектов. Для всех требуются аутентификация и единая точка входа. 
Кадр из мультсериала «Рик и Морти»И еще есть масса внешних партнеров и поставщиков, которые, конечно, только обрадуются «четким» пользователям с паспортом и прочими данными. Поэтому мы работаем над единым логином ВТБ. Пользователю он даст возможность идентифицировать себя в каршеринге, страховой, стриминге или «Рогах и копытах» максимально безопасно и удобно (согласитесь, проще нажать на кнопку «Войти через ВТБ», а не фотографировать паспорт и вбивать данные вручную). А потребителю аутентификации ВТБ — очень удобный путь идентификации и данные пользователей в соответствии с федеральным законодательством.ЭпилогСкоро год, как наши первые релизы ушли в прод. Решение развивается и обрастает новыми возможностями. Не стоило ли нам сразу начать писать свое? Нужен ли вообще был WSO2 IS? История не терпит сослагательного наклонения, но я думаю, что в условиях крайне сжатых сроков и итеративной разработки мы бы, скорее всего, ничего не успели — а если бы и успели, это бы не дотягивало до наших стандартов и не позволило развиваться дальше. Так что мы выбрали вендорное решение и заодно использовали его, чтобы развивать собственные наработки и компетенции команды — и это дало отличный результат.ЗЫ: Буду рад обсудить вопросы по SSO, токенам и вообще аутентификации.ЗЗЫ: Про что хотите почитать в следующий раз? Аутентификацию, биометрию или цифровой профиль и использование Tarantool Data Grid?
===========
Источник:
habr.com
===========
Похожие новости:
- [Информационная безопасность] Откручивание SLL пиннинга в Android приложениях
- [Информационная безопасность] Провайдер криптопочты ProtonMail сообщил, когда было отправлено письмо о минировании самолёта Ryanair
- [Децентрализованные сети, Информационная безопасность, Криптография, Математика, Распределённые системы] Честное онлайн-голосование: миф или реальность?
- [Информационная безопасность, Разработка мобильных приложений, Разработка под Android, Google API] Обновляемся на новую версию API Android по наставлению Google
- [Информационная безопасность, Интервью, IT-компании] Высокотехнологичные аферисты
- [Настройка Linux, Информационная безопасность] Найти и не обезвредить: пишем пентесты с Kali Linux (перевод)
- [Информационная безопасность, Программирование, C++] Грехи C++ (перевод)
- [Информационная безопасность, Разработка под MacOS, Настольные компьютеры, Процессоры] В Apple M1 нашли уязвимость M1RACLES — возможна скрытая передача данных между приложениями, вплоть до видеопотока
- [Информационная безопасность, Законодательство в IT] Европейский суд по правам человека признал массовый сбор информации GCHQ незаконным
- [Информационная безопасность, Open source, Программирование, SQL] 8 лучших практик предотвращения SQL-инъекций (перевод)
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_oauth2, #_wso2, #_oidc, #_vtb (втб), #_autentifikatsija (аутентификация), #_sso, #_blog_kompanii_vtb (
Блог компании ВТБ
), #_informatsionnaja_bezopasnost (
Информационная безопасность
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 23:57
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Привет! Меня зовут Артем Ивлев, и я занимаюсь архитектурой идентификации клиентов банка ВТБ. Наша задача — ответить на вопрос, кто использует наш банковский сервис: мобильный или интернет-банк, голосового помощника или просто один из многочисленных офисов. Для этого есть множество инструментов — и я хочу рассказать про становление одного из них. ПрологНа дворе 2019 год, экосистема банка растет как на дрожжах, и все острее нам нужны единая точка входа для клиентов и провайдер идентификации. А есть только каталог учетных записей и отдельные решения разных команд для аутентификации.Требований к тому, как все должно выглядеть, у нас еще не было. При этом мы сразу же начали говорить об аутентификации физических лиц не только в онлайн-банке, но и на ресурсах партнеров. Та самая кнопочка «Войти через ВТБ».  Примерно так будет выглядеть вход через ВТБИз этого следовало, что нам нужно взять максимально универсальное решение и начать его использовать. В процессе использования мы смогли бы выяснить, что нам точно нужно, каких функций не хватает и т. д.Выбираем, по какому пути пойдемПрошерстив интернет, покурив магические квадраты Гартнера, начали смотреть на опенсорс-решения с поддержкой в России:• WSO2 Identity Server• Keycloak• OpenAMПо отзывам в сети и документации наиболее универсальным нам показалось решение от WSO2 с шиной для возможности подключения множества провайдеров аутентификации, провайдеров данных пользователя и т. д.  Архитектура WSO2 Identity ServerПервый прототип мы показали еще в 2019 году на общем выездном демо розничного бизнеса.Серебряная пуля есть (извини, Брукс) — это токенВ первую очередь мы поняли, что в OAuth 2 нам лучше всего использовать ID-токен JWT, который не требует обращения к серверу аутентификации для проверки при каждом запросе. Если вкратце, JWT — это пирамидка из трех частей:1. Заголовок (HEADER) рассказывает, что это за токен, как подписан и кем выдан.2. Тело (PAYLOAD) — набор параметров — позволяет узнать, какому сервису и для какого пользователя выдан этот токен, как долго этот токен будет жить.3. Криптографическая подпись (SIGNATURE) дает возможность проверить, что данные в теле токена не были изменены и что токен выдан именно тем сервером идентификации, которому мы доверяем.  Структура JSON Web Token (JWT)Все эти части — это одна большая строка, разделенная точками на блоки. Первые два блока кодированы с помощью алгоритма Base64.Использование ID-токена JWT сильно упростило жизнь: больше не нужно было при каждом запросе от мобильного устройства или браузера ходить в базу и проверять, кому и когда выдан токен. Вся информация — в самом токене. Достаточно просто поставить перед потребителями API Gateway, который проверит подпись токена с помощью открытого ключа.Как доработать пулю напильникомТокен, выпущенный на X минут, будет действителен, даже если пользователь нажмет «Выход» или от систем службы безопасности банка поступит сигнал срочно разлогинить этого пользователя из приложения. Решение давно придумали — хранить списки отозванных токенов и сверяться с ними на уровне API Gateway. Да, это тоже сверка с базой, но здесь множество существенно меньше и легко реализуется на кеше Redis с TimeToLive.Как сделать, чтобы злоумышленники не могли украсть токен, выданный определенному мобильному приложению или браузеру пользователя? Ведь технически можно утащить у пользователя что-то из браузера и даже из приложения. То есть нужно сделать так, чтобы злоумышленник, даже украв токен, не смог им воспользоваться.  Кадр из заставки мультсериала «Симпсоны»Как обычно, задача не нова и ее решение «уже было в "Симпсонах"» ( «Южный парк»). Делаем безопасную куку (HttpOnly, SameSite, Secure) и кладем в нее UUID. Потом от этого UUID делаем хеш, например, CRC32, — и кладем его уже в тело JWT. И все. Теперь достаточно для каждого запроса проверять, что хеш от нашей куки равен тому, который записан в тело токена. Безопасную куку утащить сложнее, так что пара «токен — кука» дает нам достаточно уверенности. Адаптивная аутентификация, или Почему нам пришлось идти своим путем В процессе входа пользователя много дополнительной магии. Это и проверки пользователя, его устройства, статистики по входам, географии, и аудит действий, и открытие сессий в бэк-системах, и уточнение необходимости второго фактора, и выбор этого самого второго фактора (СМС, push, что-то еще).Это и есть задача адаптивной аутентификации. И, с одной стороны, использование модуля позволило все эти задачи вписывать с помощью скриптового интерфейса WSO2 IS, но, с другой стороны, невозможно было реализовать красивый API для мобильных устройств или SPA. Дело в том, что вся адаптивная аутентификация идет на серверном уровне как генерация интерфейсов с помощью JSP. Это сложно адаптировать даже для современной веб-разработки, не говоря уже о API для мобильного приложения.После первых прототипов и попыток натянуть универсальность на пожелания коллег из мобильной и веб-платформ мы поняли, что эту часть придется переписывать. Для мобильного приложения и интернет-банка мы решили реализовать всю логику с помощью всего лишь одной ручки API/oauth2/token — в зависимости от входящих параметров она выдавала токен или ошибку с просьбой перейти на нужный шаг запроса второго фактора. Реализацию бизнес-логики решили внести прямиком в grant_type, параметр /oauth2/token, отвечающий на вопрос о нужном типе аутентификации.В итоге у нас получилась стройная логика. Есть сервис-провайдер — потребитель аутентификации. У него есть настройки, среди которых — набор grant type. Тем самым мы отлично понимаем, кто и с помощью каких логик входа к нам может прийти. Все, что не роняет прод, делает нас сильнееСледующая проблема, которую мы поймали, — невысокая производительность из-за довольно сложного использования базы данных для сценария аутентификации, в котором мы контролируем «что и почему» на уровне нашего кода. WSO2 IS слишком много читает и пишет в базу. Пришлось нам снова переписывать часть логики генерации токена. Убрали сессии из PostgreSQL в Redis. Это на порядок снизило нагрузку на базу.  Комментарии излишни:)Но, как оказалось, этого тоже мало. Сама зависимость от базы для столь критичного сервиса — далеко не лучшее решение. В случае падения или недоступности базы (где хранятся в основном настройки и выданные токены, сессии-то мы уже оттуда убрали) мы не могли пустить пользователя в банк. Добавили проверку в случае недоступности базы — выдавать токены в аварийном порядке, если их не удается продлить через пять минут. То есть пользователи все равно смогут работать в приложении банка — но только пока жив первый выданный токен.Следующим шагом был переход от двух ЦОДов в режиме active-active к режиму active-passive, что снизило риски рассинхрона PostgreSQL и Redis. В худшем случае при падении ЦОД какой-то части пользователей придется перезайти в приложение.Ну и как финальный гвоздь в код выдачи токенов — решение полностью переписать остатки WSO2 IS. Последняя версия уже вообще не общается с базой при аутентификации пользователя. Остался только Redis, который хранит сессии аутентификации и выданные в них JWT и refresh-токены. Что дальше? Новые гориSSOнтыПри выдаче токена осталось так мало от вендорного WSO2 IS, что в скором времени мы сможем перейти от монолита, который умеет слишком много, к микросервисам, которые умеют только то, что нам нужно и с нужной нам производительностью. Сейчас у нас есть вход в банковское приложение в мобильной и веб-версиях. Но этого мало. Ведь у ВТБ есть множество других продуктов. Это «Мультибонус», «ВТБ Мобайл» и десятки, если не сотни, других наших проектов. Для всех требуются аутентификация и единая точка входа.  Кадр из мультсериала «Рик и Морти»И еще есть масса внешних партнеров и поставщиков, которые, конечно, только обрадуются «четким» пользователям с паспортом и прочими данными. Поэтому мы работаем над единым логином ВТБ. Пользователю он даст возможность идентифицировать себя в каршеринге, страховой, стриминге или «Рогах и копытах» максимально безопасно и удобно (согласитесь, проще нажать на кнопку «Войти через ВТБ», а не фотографировать паспорт и вбивать данные вручную). А потребителю аутентификации ВТБ — очень удобный путь идентификации и данные пользователей в соответствии с федеральным законодательством.ЭпилогСкоро год, как наши первые релизы ушли в прод. Решение развивается и обрастает новыми возможностями. Не стоило ли нам сразу начать писать свое? Нужен ли вообще был WSO2 IS? История не терпит сослагательного наклонения, но я думаю, что в условиях крайне сжатых сроков и итеративной разработки мы бы, скорее всего, ничего не успели — а если бы и успели, это бы не дотягивало до наших стандартов и не позволило развиваться дальше. Так что мы выбрали вендорное решение и заодно использовали его, чтобы развивать собственные наработки и компетенции команды — и это дало отличный результат.ЗЫ: Буду рад обсудить вопросы по SSO, токенам и вообще аутентификации.ЗЗЫ: Про что хотите почитать в следующий раз? Аутентификацию, биометрию или цифровой профиль и использование Tarantool Data Grid? =========== Источник: habr.com =========== Похожие новости:
Блог компании ВТБ ), #_informatsionnaja_bezopasnost ( Информационная безопасность ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 23:57
Часовой пояс: UTC + 5