Аутентификация в Edge и передача идентификаторов, не использующих токены

Технологический блог Netflix, 9 февраля.

Авторы: члены команды AIM Karen Casella, Travis Nelson, Sunny Singh;
Графика и участие: Justin Ryan, Satyajit Thadeshwar

Перевод @middlejava

Как может подтвердить большинство разработчиков, работа с протоколами безопасности и идентификационными токенами, также, как и с аутентификацией пользователей и устройств, может быть сложной задачей. Представьте, что у вас есть несколько протоколов, несколько токенов, более 200 миллионов пользователей и тысячи типов устройств, и проблема при этом может расширяться. Несколько лет назад мы решили разобраться с этой проблемой, запустив новую инициативу, и в итоге создали новую команду, чтобы перенести сложную обработку аутентификации пользователей и устройств, а также различных протоколов безопасности и токенов на границу сети, управляемой набором централизованных сервисов и одной командой. В процессе мы изменили end-to-end передачу идентификаторов внутри сети сервисов, чтобы использовать криптографически верифицируемый объект идентификатора, не использующий токены.

Далее вы узнаете больше об этом путешествии и о том, как мы смогли:

Netflix начинался как веб-сайт, который позволял участникам управлять DVD очередями. Позже он был расширен возможностью потоковой передачи контента. Стриминговые устройства появились немного позже, но первые устройства были ограничены в возможностях. Со временем возможности устройств расширились, и функции, которые когда-то были доступны только на веб-сайте, стали доступны через стриминговые устройства. Масштабы сервисов Netflix быстро росли, при этом поддерживалось более 2000 типов устройств.

Сервисы, поддерживающие эти функции, теперь столкнулись с возросшей нагрузкой, связанной с возможностью работы со множеством токенов и протоколов безопасности для идентификации пользователей и устройств, а также авторизации доступа к этим функциям. Вся система была довольно сложной и начинала становиться хрупкой. Кроме того, архитектура слоя Edge эволюционировала в модель PaaS (платформа как услуга), и нам предстояло принять несколько сложных решений о том, как и где выполнять обработку токенов идентификации.

Чтобы продемонстрировать сложность системы, ниже приведено описание того, как работал процесс входа пользователя в систему до изменений, описанных в этой статье:

На самом верхнем уровне шаги, связанные с этим (сильно упрощенным) процессом, заключаются в следующем:

У этой модели были некоторые проблемы, например:

В приведенном выше примере показан один процесс, работающий с одним протоколом (HTTP/S) и одним типом токенов (куки). В стриминговых продуктах Netflix используется несколько протоколов и токенов, как показано ниже:

Эти токены использовались и потенциально изменялись несколькими системами в стриминговой экосистеме Netflix, например:

Чтобы еще больше усложнить ситуацию, существовало множество способов передачи этих токенов или содержащихся в них данных из системы в систему. В некоторых случаях токены вскрывались, и элементы идентификационных данных извлекались в виде простых примитивов или строк для использования в вызовах API или передавались из системы в систему через заголовки контекста запроса или даже в качестве параметров URL. Не было никаких проверок целостности токенов или содержащихся в них данных.

Тем временем масштабы деятельности Netflix росли в геометрической прогрессии. В настоящее время у Netflix более 200 миллионов подписчиков с миллионами активных устройств в месяц. Мы обслуживаем более 2,5 миллионов запросов в секунду, большой процент из которых требует той или иной формы аутентификации. В старой архитектуре каждый из этих запросов приводил к вызову API для проверки подлинности клэймов, представленных в запросе, как показано ниже:

Чтобы еще больше усложнить ситуацию, команда инженеров Edge находилась в процессе перехода от старой серверной архитектуры API к новому подходу на основе PaaS. Когда мы перешли на EdgePaaS, фронтенд-сервисы были перенесены c Java API на BFF (бэкенд для фронтенд), он же NodeQuark, как показано ниже:

Эта модель позволяет фронтенд инженерам владеть и управлять своими сервисами за пределами ядра фреймворка API. Однако это создало еще один уровень сложности - как сервисы NodeQuark будут работать с токенами идентификации? Сервисы NodeQuark написаны на JavaScript, и терминация такого сложного протокола, как MSL, была бы сложной и накладной, как и репликация всей логики управления токенами.

Подводя итог, мы столкнулись со сложным и неэффективным решением для обработки токенов аутентификации и идентификации на больших масштабах. У нас было несколько типов и источников идентификационных токенов, каждый из которых требовал специальной обработки, логика которой повторялась в разных системах. Критически важные идентификационные данные распространялись по всей экосистеме сервера в произвольной форме (inconsistent fashion).

Мы поняли, что для решения этой проблемы необходима единая модель идентификации. Нам нужно обработать токены аутентификации (и протоколы) вверху цепочки. Мы сделали это, перенеся аутентификацию и терминацию протокола на границу сети, и создали новый объект идентификации с защищенной целостностью, не использующий токены, для распространения по всей экосистеме сервера.

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

На верхнем уровне Zuul (облачный шлюз) должен был стать конечной точкой для проверки токенов и шифрования/дешифрования полезной нагрузки. В случае, если Zuul не сможет обработать эти операции (небольшой процент), например, если токены отсутствуют, нуждаются в обновлении или иным образом недействительны, Zuul делегирует эти операции новому набору сервисов аутентификации Edge для обработки обмена криптографическими ключами и создания или обновления токенов.

Сервисы аутентификации Edge (EAS) - это:

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

Основной паттерн того, как EAS обрабатывает запросы, выглядит следующим образом:

Для каждого запроса, поступающего в сервис Netflix, Inbound Filter (входящий фильтр) EAS в Zuul проверяет токены, предоставленные клиентом устройства, и либо передает запрос в Passport Injection Filter (фильтр вставки паспортов), либо передает обработку в один из сервисов аутентификации Edge. Passport Injection Filter генерирует идентификатор, не использующий токены, для распространения далее по остальной части экосистемы сервера. При отправке ответа работает Outbound Filter (исходящий фильтр) EAS, обращаясь при необходимости к сервисам аутентификации Edge, генерирует токены, необходимые для отправки обратно на клиентское устройство.

Архитектура системы теперь принимает следующий вид:

Обратите внимание, что токены никогда не пересекают границу шлюза Edge/EAS. Протокол безопасности MSL терминируется на Edge, все токены вскрываются, а идентификационные данные расходятся по экосистеме сервера без использования токенов.

При удачном стечении обстоятельств Zuul сможет обработать большой процент валидных и неистекших токенов, а сервисы аутентификации Edge обработают оставшиеся запросы.

Сервисы EAS спроектированы быть отказоустойчивыми, например, когда Zuul определяет, что куки валидны, но срок их действия истек, а запрос на обновление к EAS зафейлился или потерялся:

В этом неуспешном сценарии фильтр EAS в Zuul не будет строгим и отправит обработанный идентификатор дальше и укажет, что при следующем запросе должен быть повторно запланирован вызов обновления.

Легко изменяемая структура идентификаторов не подходила, потому что это означало бы передачу менее надежных идентификаторов от сервиса к сервису. Требовалась структура идентификаторов, не использующая токены.

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

Как отмечалось выше, модель Паспорта имеет формат Protocol Buffer. На самом верхнем уровне определение Паспорта выглядит следующим образом:

Элемент Header содержит имя сервиса, создавшего Паспорт. Но более интересно то, что связано с пользователем и устройством.

Элемент UserInfo содержит всю информацию, необходимую для идентификации пользователя, от имени которого выполняются запросы, а элемент DeviceInfo содержит всю информацию, необходимую для устройства, с которого пользователь посещает Netflix:

И UserInfo, и DeviceInfo содержат Source и PassportAuthenticationLevel для запроса. Список Source представляет собой виды клэймов с использованным протоколом и сервисами, использованными для валидации клэймов. PassportAuthenticationLevel - это уровень доверия, установленный нами клэйму аутентификации.

Приложения, находящиеся ниже по потоку, могут использовать эти значения для принятия решений по авторизации и/или пользовательском опыте.

Целостность Паспорта защищена с помощью HMAC (кода аутентификации сообщений на основе хэша), который представляет собой особый тип MAC, включающий криптографическую хэш-функцию и секретный криптографический ключ. Он может использоваться для одновременной проверки как целостности данных, так и подлинности сообщения.

Целостность пользователя и устройства определяется как:

Версия 1 элемента Integrity использует SHA-256 для HMAC, который кодируется как ByteArray. В будущих версиях Integrity может использоваться другая хэш-функция или кодировка. В версии 1 поле HMAC содержит 256 бит из MacSpec.SHA_256.

Защита целостности гарантирует, что поля Паспорта не будут изменены после его создания. Клиентские приложения могут использовать Passport Introspector (Интроспектор Паспорта) для проверки целостности Паспорта перед использованием любого из содержащихся в нем значений.

Сам объект Passport непрозрачен; клиенты могут использовать Интроспектор Паспорта для извлечения Паспорта из заголовков и содержимого из него самого. Интроспектор Паспорта - это обертка над двоичными данными Паспорта. Клиенты создают Интроспектор с помощью фабрики, после чего обращаются к основным методам доступа:

В protobuf-определении Паспорта, указанном выше, задаются Действия Паспорта:

Действия Паспорта - это явные сигналы, посылаемые сервисами, находящимися ниже по потоку, когда выполняется обновление идентификатора пользователя или устройства. Сигнал используется EAS для создания или обновления соответствующего типа токена.

Закончим примером того, как все эти решения работают вместе.

С переносом аутентификации и терминации протокола в Edge и введением Паспорта в качестве идентификатора, описанный ранее процесс входа в систему превратился в следующее:

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

Наличие структуры, являющейся каноническим идентификатором, очень полезно. Альтернативы, в которых циркулируют примитивы идентификаторов, являются хрупкими и трудными для отладки. Если идентификатор клиента изменился от сервиса A к сервису D в цепочке вызовов, кто его изменил? Как только структура идентификатора пройдет через все ключевые системы, относительно легко добавить новые типы внешних токенов, новые уровни доверия или новые способы представления идентификаторов.

Наличие такой структуры, как Паспорт, позволяет определить сервисы, которые могут сформировать Паспорт, а другие сервисы могут его свалидировать. Когда Паспорт рассылается, и мы видим его в логах, его можно открыть, свалидировать и узнать, что это за идентификатор. Мы также знаем источник Паспорта и можем отследить его до того места, где он появился в системе. Это значительно упрощает отладку любых аномалий, связанных с идентификаторами.

Передача единообразной структуры нижестоящим системам означает, что эти системы могут легко получать идентификаторы устройства и пользователя, используя библиотеку-интроспектор. Вместо того, чтобы иметь отдельный обработчик для каждого типа внешнего токена, можно использовать общую структуру.

За счет переноса обработки токенов из этих систем в сервисы аутентификации Edge (EAS) нижестоящие системы добились значительных улучшений по ЦПУ, задержкам запросов и метрикам сборки мусора, что помогло снизить нагрузку на кластер и затраты на облако. Следующие примеры этих улучшений получены из основного сервиса API.

В предыдущей реализации было необходимо нести расходы на расшифровку/терминацию дважды за запрос, потому что нам нужна была возможность маршрутизации на границе, но и также требовалась расширенная терминация в нижестоящем сервисе. Некоторое улучшение производительности связано с объединением этих вещей - MSL-запросы теперь нужно обрабатывать только один раз.

Перенос обработки токенов привел к снижению процессорных затрат на 30% на запрос и снижению средней нагрузки на 40%. На следующем графике показано соотношение CPU к RPS (меньше - лучше):

Время отклика всех вызовов сервиса API значительно улучшилось: средняя задержка сократилась на 30%, а задержка 99-го перцентиля снизилась на 20%:

Сервис API также значительно сократил давление и количество пауз GC, что показано в метриках Stop The World Garbage Collection:

Абстрагирование разработчиков микросервисов от проблем, связанных с аутентификацией и идентификаторами, означает, что разработчики могут сосредоточиться на своей основных задачах. Изменения в этой области теперь вносятся один раз и в одном наборе специализированных сервисов, а не распределяются по нескольким.

В настоящее время мы расширяем сервисы аутентификации Edge для поддержки многофакторной аутентификации с помощью нового сервиса под названием «Резистор». Мы выборочно вводим второй фактор для подозрительных соединений, основываясь на моделях машинного обучения. По мере внедрения новых процессов мы вводим новые факторы, например, одноразовые пароли (OTP), отправляемые по электронной почте или на телефон, push-уведомления на мобильные устройства и сторонние приложения для аутентификации. Мы также можем изучить возможность многофакторной аутентификации для пользователей, которые хотят повысить безопасность своих учетных записей.

Теперь, когда у нас есть проверенный идентификатор, проходящий через систему, мы можем использовать его в качестве надежного сигнала для принятия решений об авторизации. В прошлом году мы начали исследовать новую Стратегию Доступа к Продуктам (Product Access Strategy - PACS) и в настоящее время работаем над ее внедрением в прод, чтобы получить ряд новых возможностей в стриминговом продукте Netflix. На базе PACS недавно запустили систему контроля доступа на Streamfest, неделю бесплатного Netflix в Индии.

Члены команды представили эту работу на QCon в Сан-Франциско (и были двумя из трех лучших участников конференции!):

Авторы являются членами команды управления доступом и идентификацией в Netflix. Мы гордимся тем, что являемся экспертами в области разработки распределенных систем, эксплуатации и управления идентификацией. И мы нанимаем сеньоров инженеров-программистов! Если вам интересно, свяжитесь с нами через LinkedIn.

Перевод @middlejava

Тэги: #токен , #аутентификация , #авторизация , #netflix , #cloud , #microservice , #api , #gateway , #zuul , #highload