В 2017 году в истории Netflix Studios произошел переломный момент. От периода стремительного развития компания перешла к такому взрывному росту, который заставил ее разработчиков всерьез задуматься над вопросом: “Как будем масштабироваться?”. Стратегическое видение заключалось в том, чтобы создать Studio in the Cloud (“Студию в Облаке”) с приложениями, полностью поддерживающими каждую структуру. Группа безопасности, которая усердно разрабатывала эту концепцию, столкнулась с двумя явно противоречивыми приоритетами:
1) Оптимизация любых процессов безопасности как непременное условие скорейшего создания и развертывания приложений в общедоступном интернете.
2) Максимальное повышение общего уровня безопасности, необходимого для того, чтобы суммарные риски гигантского и растущего портфеля высокочувствительных активов с выходом в интернет не превзошли его стоимость.
Путь к разрешению этого противоречия — сотрудничество, которым гордится Netflix и которое служит примером того, как компания подходит к разработке инфраструктурных продуктов и партнерству в области безопасности продуктов.
Будет озвучено мнение двух команд Netflix: сначала Application Security (группа по обеспечению безопасности приложений), а затем Cloud Gateway (группа по обеспечению облачного шлюза).
Джулия и Патрик (Netflix Application Security):
Решая эту проблему, мы сосредоточились на двух наблюдениях. Прежде всего, было слишком много вопросов безопасности, над которыми каждой команде разработчиков ПО нужно было подумать: TLS-сертификаты, аутентификация, головные метки безопасности, регистрация запросов, ограничение скорости передачи и многие другие.
Для разработчиков существовали контрольные списки вопросов, отражающих требования безопасности. Однако эти списки были длинными и в основном составленными от руки — ни один из них не помогал ускорить разработку.
Ситуация усложнялась тем, что выполнение многих элементов из контрольного списка было вариативным: “новые приложения делают это, но устаревшие приложения делают то”, “приложения Java должны использовать этот подход, но приложения Ruby должны опробовать одну из этих четырех вещей”… И да, внутри контрольных списков были блок-схемы.
Для команд разработчиков одна только проработка блок-схем и вариантов выполнения приложений была неподъемной задачей. Поддержка разработчиками пограничных случаев с помощью этих контрольных списков, как и подтверждение того, что выбор каждой команды приводил к созданию архитектуры со всеми требуемыми свойствами безопасности, также не были масштабируемыми для инженеров по безопасности.
Второе наблюдение относилось к надежной аутентификации в качестве контроля наивысшего уровня. Отсутствие или неполная аутентификация в приложении была наиболее серьезной проблемой, с которой мы регулярно сталкивались, тогда как приложение со сверхнадежной историей аутентификации мы считали вне зоны риска. Такие концепции, как Zero Trust (нулевое доверие), Beyond Corp (Google-реализация Zero Trust) и Identity Aware Proxies (прокси-серверы с поддержкой идентификации), очевидно, демонстрируют одно и то же: 100-процентная аутентификация гарантированно станет свойством архитектуры приложения, а не реализованной в ней деталью.
Исходя из обоих этих наблюдений, мы посмотрели на задачу с принципиально важной для нас точки зрения: как можно ее продуктизировать? Инженеры Netflix часто используют принцип Paved Road (твердое покрытие). Для команд безопасности, работающих с большим портфолио, такой подход привлекателен тем, что помогает свести множество вопросов к булеву суждению: вместо “скажите, как приложение выполняет эту важную функцию безопасности?” достаточно просто “используете ли вы продукт “с твердым покрытием”, доказавший свою эффективность?”.
Итак, нам нужно было представить продукт, который отвечал бы требованиям большинства вопросов контрольного списка безопасности и предоставил гарантированную аутентификацию как свойство архитектуры. Для выполнения этой сверхзадачи мы обратились за помощью к нашим центральным инженерно-техническим группам.
Партнерство для повышения безопасности
Хосе и Артур (Netflix Cloud Gateway):
Наша команда Cloud Gateway разрабатывает и управляет Front Door в Netflix. Мы отвечаем за подключение подписчиков Netflix к облачным сервисам, маршрутизацию и управление интернет-трафиком. Наши шлюзы работают на базе флагманской технологии с открытым исходным кодом Zuul.
Когда Netflix Studios и наши партнеры по безопасности обратились к нам, проектное предложение было концептуально простым и соответствовало нашему модульному подходу, основанному на фильтрах. Чтобы опробовать его, мы развернули пользовательскую сборку Zuul (которую сначала назвали API Wall, а позже более ласково Wall-E) с новым фильтром для проводника системы единого входа Netflix, активировали его для всех запросов — вот и стратегия развертывания приложения, гарантирующая аутентификацию поддерживающим его сервисам.
Ликвидация контрольного списка
В процессе совместной работы над интеграцией системы единого входа с Wall-E мы создали довольно интересный шаблон добавления требований безопасности в качестве фильтров. Мы снова обратились к контрольному списку, чтобы выяснить, какие из его требований достаточно согласованы в разных приложениях, чтобы добавить их в качестве регулирующих фильтров.
Брандмауэр веб-приложений (WAF), предотвращение DDoS-атак, проверка головных меток безопасности и надежная регистрация — все это соответствует требованиям. Одно за другим требования контрольного списка “приказывали долго жить”, переходя из “вотчины индивидуального разработчика приложений” в “епархию Wall-E” (и согласованно реализуясь).
К этому моменту стало ясно, что мы достигли видения, изложенного в первоначальном запросе команды AppSec. В конечном итоге мы смогли обеспечить Wall-E такой уровень защиты, что основная масса вопросов контрольного списка, касающихся “пригодности для выхода в интернет” приложений Studio, свелась к одному пункту: готовы ли вы использовать Wall-E?
Челленджи первопроходцев
Первые пользователи Wall-E были отобраны вручную и вдохновлялись командой Application Security. В то время команде Cloud Gateway приходилось тесно сотрудничать с разработчиками приложений, чтобы обеспечить комфортный переход на новую технологию, не нарушающий работы пользователей.
Эти совместные усилия заняли у обеих сторон несколько недель. Уже в процессе первых консультаций стало ясно, что разработчики больше внимания уделяют процессу создания продукта, нежели вопросам повышения безопасности или улучшения инфраструктуры.
Встречи обычно заканчивались так: “Служба безопасности предложила поговорить с вами, и нам нравится идея оптимизации системы безопасности, но нужно решать задачи по созданию продукта. Давайте вернемся к этому вопросу в следующем квартале”. Консультации выявили пару проблем, которые предстояло преодолеть, чтобы избавить пользователей от испытаний, выпавших на долю “первопроходцев”:
- Настройка Wall-E для приложения занимала слишком много времени и усилий, так что при практическом подходе масштабирования достичь нельзя.
- Одних улучшений условий безопасности оказалось недостаточно, чтобы обеспечить органичное внедрение в культуру Netflix принципа “контекст, а не контроль”.
Мы были вынуждены улучшить показатели внедрения новой технологии. Сначала решили сосредоточиться на проблемах настройки путем совершенствования опыта разработчиков и автоматизации регистрации новых пользователей.
Опыт разработчиков как двигатель масштабирования
Разработчики в мире потоковой передачи Netflix формируют пользовательский интерфейс Netflix из сотен микросервисов. Все они находятся в зоне досягаемости благодаря сложным правилам маршрутизации. Каждая команда Netflix Studio разрабатывает собственные продукты с уникальным контентом и упрощенными требованиями к маршрутизации.
Чтобы поддержать эту довольно своеобразную модель, мы сделали еще одну вещь. В то время она казалась довольно простой, но с годами доказала впечатляющую эффективность. Мы попросили команды приложений интегрироваться с нами, создав файл YAML с контролем версий. Первоначально это было задумано как упрощенный и удобный для разработчиков способ сбора доменных имен и некоторых правил маршрутизации в верифицируемый пакет. Но вскоре мы поняли, что чисто случайно получили мощную модель: создали интент разработки.
Это небольшое ноу-хау стало своего рода чудом, полностью перевернувшим наши отношения с командами разработчиков: получив краткое, стандартизированное определение приложения, которое они намеревались представить, мы могли проактивно автоматизировать большую часть настройки.
Нужно указать доменное имя? Wall-E гарантирует его автоматическое представление при условии корректной конфигурации DNS и TLS. Использование этого опыта привело нас и к другой оптимизации — разработке запроса о предполагаемых группах пользователей и взаимосвязанных приложениях (для выбора конфигураций и утверждений OAuth). Теперь мы могли сказать разработчикам, что настройка Wall-E займет всего несколько минут и что наши инструменты автоматизируют ее полностью.
Движемся все быстрее и быстрее
Когда все перечисленное было собрано воедино, сторонние разработчики стали проявлять повышенное внимание к Studio. Имея типичное приложение “с твердым покрытием” без каких-либо необычных проблем с безопасностью, команда может переходить от “git init” к приложению, готовому к производству, полностью аутентифицированному, доступному через интернет менее чем за 10 минут.
Автоматизация настройки инфраструктуры в сочетании со сниженным уровнем рисков, позволяющим оптимизировать проверки безопасности, экономит разработчикам дни, если не недели, на каждом приложении. То обстоятельство, что мотивирующим фактором изначально была безопасность, не смущало разработчиков: они убедились на практике, что приложения, использующие Wall-E, раньше презентуются пользователям и быстрее возобновляются.
Это создало тот добродетельный цикл, невероятно радующий команды разработчиков основной технической продукции: большее количество пользователей делает инвестиции в амортизированную платформу более ценными, а также приносит больше идей и ясности понимания функциональных особенностей, которые, в свою очередь, привлекают больше пользователей. Наши успехи задали тон разработкам следующего года. Они велись по двум направлениям: устранение блокировок внедрения Wall-E и дальнейшее превращение “интента разработки” в легко поддерживаемые функции продукта.
Для решения проблемы блокировок внедрения мы, совместно с командой безопасности, задавали разработчикам один и тот же вопрос: есть ли что-нибудь, что мешает вам использовать Wall-E? Всякий раз, получая ответ на этот вопрос, мы пытались найти выход из положения.
Почти все блокировщики относились к системам, в которых (обычно по историческим причинам) какая-либо команда приложений решала как проблему аутентификации, так и задачи маршрутизации особым способом. Достаточно вспомнить устаревшие mTLS и различные схемы веб-перехвата.
Благодаря тому, что Wall-E является долговечным решением “с твердым покрытием”, у нас было достаточно “плюшек”, чтобы заставить эти команды отказаться от поддержки уникальных, потенциально опасных функций. Ценное предложение формулировалось не только как “позвольте помочь вам выполнить переход, и вы будете иметь дело только с входящим трафиком, который уже должным образом аутентифицирован”. К этому следовало дополнение: “можете отказаться от сервисов и ручных процессов, поддерживающих ваши специальные механизмы, и переложить всю ответственность за аутентификацию, интеграцию и мониторинг WAF, а также защиту от DDoS-атак на платформу”.
В целом, трудно переоценить значимость приверженности единому продукту “с твердым покрытием” в решении подобных проблем. Это создает поразительную прозрачность и оказывает стратегическое давление на команды, помогая соотносить используемые актуальные сервисы с документацией и экспертным анализом, которые их определяют. Разница между 2–4 “правдоподобными” методами и одним “твердым покрытием” довольно велика.
Кроме того, с меньшим количеством исключений и более четкими критериями приложений, готовых использовать “твердое покрытие”, наши команды AppSec Engineering и User Focused Security Engineering (UFSE) автоматизировали руководство по безопасности, чтобы дать разработчикам более подходящие автоматические подсказки для внедрения Wall-E. Панель мониторинга рисков безопасности каждого лидера рынка теперь включает показатель внедрения Wall-E, примерно ⅔ рекомендуемых приложений готовы к его внедрению. В настоящее время Wall-E поддерживает более 350 приложений, добавляя примерно 3 новых производственных приложения (в основном с выходом в интернет) в неделю.
В процессе внедрения Wall-E мы отслеживали различные сигналы о намерении разработчиков использовать хорошую функциональность для перехода от командной разработки к платформенной.
Одним из наиболее приятных примеров оказался UI-хостинг. Он появлялся снова и снова как странное исключение из общего правила “полной аутентификации” и как практически единственная вещь, требующая от UI-разработчиков одностраничных приложений (SPA) запуска реальных облачных экземпляров с необходимостью быть на связи для поддержки инфраструктуры.
В итоге родился авторитетный, декларативный сервис ресурсов, который абстрагировал статический хостинг файлов для групп приложений: разработчики обеспечили быстрое развертывание статических ресурсов. Безопасность гарантировали надежные “защитные ограждения” вокруг приложений пользовательского интерфейса, а у Netflix уменьшилось количество облачных инстансов для управления (и оплаты). Wall-E стал обязательным требованием для совершенствования опыта разработчиков пользовательского интерфейса, и это привело к еще более интенсивному процессу его внедрения.
Стремление выпускать продукт на рынок позволило эффективно использовать множество сложных, но “приятных” функций для повышения производительности труда разработчиков, таких как бесплатные Atlas-метрики и интеграция с инструментом отслеживания запросов Edgar.
От продукта к платформе
Возможно, вы заметили, как в ходе этого рассказа, чуть выше, проскользнуло слово “платформа”. У Netflix есть организация Developer Productivity: там заняты команды, призванные помогать другим разработчикам быть более эффективными. Большая часть их работы — это сбор интентов разработчиков и автоматизация точек взаимодействия в наших системах.
Поскольку эти команды пришли к выводу, что Wall-E является четким ответом на вопросы многих клиентов, они начали интегрировать свои инструменты для настройки Wall-E с учетом более высокого уровня интентов разработчиков, собранных ими. По сути, это превращает аутентификацию и маршрутизацию трафика (и все остальное, что обрабатывает Wall-E) из конкретного продукта, о котором разработчикам необходимо подумать и сделать выбор, в простую данность, которой разработчики могут доверять и, как правило, не париться по этому поводу.
В 2019 году 100% конфигурации приложений в Wall-E было выполнено разработчиками вручную. В 2021 году ситуация кардинально изменилась: теперь более 50% конфигурации приложений в Wall-E выполняется автоматизированными инструментами (которые действуют на абстракциях более высокого уровня от имени разработчиков).
Такое масштабирование и стандартизация не могли не отразиться на эффективности. Прогнозы количественной оценки внутренних рисков показывают внушительную экономию в годовом исчислении затрат на риски и реагирование на инциденты по всему портфелю Wall-E.
В этих приложениях меньшее количество ошибок, к тому же они менее серьезны и реже связаны с процессом эксплуатации по сравнению с приложениями, отличными от Wall-E. Поэтому нам редко требуется срочный ответ от владельцев приложений (мы называем это “не предлагать сервис в виде звонков клиентам среди ночи”). Время разработчика, сэкономленное на первоначальной настройке приложения и отказе от ненужных сервисов, повышает производительность команды еще на несколько месяцев в год.
Оглядываясь назад на основные приоритеты, с которыми мы отправились по этому пути (“рационализация любых процессов безопасности […]” и “максимальное повышение общего уровня безопасности […]”), можно сказать: эволюция Wall-E, ставшая частью платформы, укрепила и умножила первоначальный успех. В будущем все больше и больше разработчиков приложений смогут воспользоваться этими гарантиями безопасности, все меньше и меньше заботясь о них. Это результат, которым мы очень гордимся.
Итак, подытожим
Резюмируя сказанное, выделим несколько вещей, которые стоит взять на вооружение:
- Если у вас есть возможность выполнить что-то одно для управления большим портфелем продуктов безопасности, выбирайте сверхнадежную аутентификацию (предпочтительно в качестве свойства архитектуры).
- Группы безопасности и центральные инженерно-технические группы могут и должны быть готовыми к сотрудничеству, взаимно поддерживающему партнерству.
- “Продающее” предложение (четко сформулированное, определяющее ценность продукта, фирменное, выражающееся в числовых показателях), используемое даже для внутренних инструментов, полезно для стимулирования внедрения продукта и поиска его дополнительной ценности.
- Конкретный продукт делает “твердое покрытие” более понятным; булево “использует/не использует” значительно предпочтительнее различных вариантов с невнятными разъяснениями.
- Прицепите “вагон” безопасности к “локомотиву” производительности труда разработчиков.
- Собранный интент разработчиков — грозная сила, которая позволит многим командам повысить ценность продукта.
Что дальше
Мы убедились в невероятной силе партнерских отношений в области безопасности и инфраструктуры. Мы рады использовать свои победы для достижения нашей следующей цели: стать реальным поставщиком инфраструктуры-как-сервиса, создав полноценный Gateway API. Тем самым мы передаем права собственности на опыт разработчиков нашим партнерским командам из организации Developer Productivity. Это позволит нам сосредоточиться на челленджах, которые возникнут на нашем пути на следующем этапе: 1000 приложений с поддержкой Wall-E.
Читайте также:
- Введение в Веб-безопасность
- Безопасность наглядно: CORS
- Обнаружение вредоносного ПО с помощью алгоритмов МО на облачной платформе Google
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Netflix Technology Blog: Securing Netflix Studios At Scale
