Ключевые моменты
• Нулевое доверие – это модель безопасности, которая вызвала много шумихи, но, несмотря на маркетинговый шум, она имеет конкретную и непосредственную ценность для организаций, заботящихся о безопасности.
• По своей сути, нулевое доверие переводит авторизацию от «проверки один раз на периметре» к «проверке везде и всегда».
• Для этого нулевое доверие требует переосмысления понятия идентификации и отказа от идентификации на основе местоположения, например, IP-адреса.
• Пользователи Kubernetes имеют явное преимущество при реализации нулевого доверия на сетевом уровне благодаря сеткам сервисов на базе sidecar, которые обеспечивают аутентификацию и авторизацию на самом гранулированном уровне, не требуя изменений в приложениях.
• Хотя сервисные сетки могут помочь, безопасность Kubernetes остается сложной и тонкой темой, требующей понимания нескольких уровней стека.
Нулевое доверие – это мощная модель безопасности, которая находится на переднем крае современных методов обеспечения безопасности. Это также термин, вокруг которого много шумихи и ажиотажа, что затрудняет понимание его сути. Так что же такое нулевое доверие, и что конкретно оно означает для Kubernetes? В этой статье мы рассмотрим, что такое нулевое доверие с инженерной точки зрения, и создадим базовую основу для понимания его последствий как для операторов Kubernetes, так и для команд безопасности.
Введение
Если вы разрабатываете современное облачное программное обеспечение, будь то Kubernetes или что-то другое, вы наверняка слышали о термине «нулевое доверие». Модель безопасности с нулевым доверием стала настолько важной, что федеральное правительство США обратило на нее внимание: Белый дом недавно выпустил меморандум с изложением федеральной стратегии нулевого доверия, согласно которой все федеральные агентства США должны соответствовать определенным стандартам безопасности с нулевым доверием к концу 2024 финансового года; Министерство обороны создало эталонную архитектуру нулевого доверия; а Агентство национальной безопасности опубликовало руководство по укреплению Kubernetes, в котором описаны лучшие практики безопасности с нулевым доверием в Kubernetes.
Благодаря такой шумихе «нулевое доверие», безусловно, привлекло к себе пристальное внимание маркетинга. Но, несмотря на шум, нулевое доверие – это не просто пустой термин, а воплощение некоторых глубоких и преобразующих идей для будущего безопасности. Итак, что такое нулевое доверие и почему оно вдруг стало таким важным? И что означает нулевое доверие конкретно для пользователей Kubernetes?
Что такое нулевое доверие?
Как и следовало ожидать, нулевое доверие в основе своей связано с доверием. Это модель для решения одного из основных вопросов безопасности: разрешен ли X доступ к Y? Другими словами, доверяем ли мы X доступ к Y?
Конечно, «ноль» в нулевом доверии – это некоторое преувеличение. Для того чтобы программное обеспечение работало, очевидно, что что-то должно доверять чему-то другому. Таким образом, нулевое доверие – это не столько полное устранение доверия, сколько сокращение его до необходимого минимума (известный принцип наименьших привилегий) и обеспечение его соблюдения на каждом этапе.
Это может казаться вполне логичным. Но, как и в случае со многими новыми идеями в области технологий, лучший способ понять нулевое доверие – это понять, на что оно является реакцией. Нулевое доверие – это отказ от идеи, что безопасности периметра достаточно. В модели защиты периметра вы создаете «твердую оболочку» вокруг своих уязвимых компонентов. Например, вокруг вашего центра обработки данных может быть установлен брандмауэр, задача которого – не допустить проникновения плохого трафика и нарушителей. Эта модель, иногда называемая «замковым подходом», имеет интуитивный смысл: стены замка существуют для того, чтобы не допустить проникновения плохих игроков. Если вы находитесь внутри замка, значит, по определению, вы хороший игрок.
Модель нулевого доверия утверждает, что безопасности по периметру уже недостаточно. Согласно модели нулевого доверия, даже в пределах периметра безопасности вы должны рассматривать пользователей, системы и сетевой трафик как недоверенные.
В эталонной архитектуре Министерства обороны это хорошо сформулировано:
«Ни один субъект, система, сеть или служба, работающие вне или внутри периметра безопасности, не заслуживают доверия. Вместо этого мы должны проверять все и вся, что пытается получить доступ. Это кардинальная смена парадигмы в философии защиты нашей инфраструктуры, сетей и данных: от однократной проверки на периметре до постоянной проверки каждого пользователя, устройства, приложения и транзакции».
Конечно, нулевое доверие не означает отбрасывание брандмауэров – глубокая оборона является важным компонентом любой стратегии безопасности. Это также не означает, что мы можем игнорировать все другие важные компоненты безопасности, такие как регистрация событий и управление цепочками поставок. Нулевое доверие просто требует, чтобы мы перенесли проверку доверия с «один раз на периметре» на «каждый раз, везде».
Однако, чтобы сделать это правильно, нам необходимо переосмыслить некоторые фундаментальные предположения о том, что означает «доверие» и как мы его фиксируем.
Идентичность
Одним из самых непосредственных последствий нулевого доверия является то, что оно меняет наше представление об идентичности и то, как мы присваиваем ее, особенно системную идентичность.
В модели периметра ваше местоположение фактически является вашей личностью. Если вы находитесь внутри брандмауэра, вам доверяют, если за его пределами – нет. Таким образом, системы на основе периметра могут разрешать доступ к важным системам на основе таких вещей, как IP-адрес клиента.
В мире нулевого доверия этого уже недостаточно. Ваш IP-адрес указывает только на местоположение и, таким образом, больше не является достаточным для определения того, доверяют ли вам доступ к определенному ресурсу. Вместо этого нам нужна другая форма идентификации: привязка к рабочей нагрузке, пользователю или системе каким-то внутренним образом. И эта идентичность должна быть проверяема каким-то способом, который сам по себе не требует доверия к сети.
Это важное требование со многими последствиями. Системы, обеспечивающие сетевую безопасность, но полагающиеся на сетевые идентификаторы, такие как IP-адреса, например, IPSec или Wireguard, не являются достаточными для нулевого доверия.
Политика
Вооружившись нашей новой моделью идентификации, нам теперь нужен способ определения типа доступа, который имеет каждая личность. В описанном выше подходе к периметру обычно предоставляется полный доступ к конфиденциальному ресурсу для ряда IP-адресов. Например, мы можем настроить фильтрацию IP-адресов, чтобы гарантировать, что только IP-адресам изнутри брандмауэра будет разрешен доступ к конфиденциальной службе. При нулевом доверии вместо этого необходимо обеспечить минимально необходимый уровень доступа. Доступ к ресурсу должен быть максимально ограниченным, основанным на идентификации и любых других значимых факторах.
Хотя код нашего приложения мог бы сам принимать такие решения об авторизации, мы обычно вместо этого фиксируем их с помощью некоторой формы политики, указанной вне приложения. Наличие явной политики позволяет нам проводить аудит и изменять доступ без изменения кода приложения.
Для достижения целей нулевого доверия эти политики могут быть очень сложными. У нас может быть политика, которая ограничивает доступ к службе только теми вызывающими службами, которым необходимо получить к ней доступ (то есть, используя идентификатор рабочей нагрузки с обеих сторон). Мы можем расширить эту возможность и разрешить доступ только к определенным интерфейсам (HTTP-маршруты, методы gRPC) этой службы. Мы можем сделать это еще более тщательно и ограничить доступ на основе идентификации пользователя, ответственного за запрос. Целью во всех случаях является наименьшая привилегия – доступ к системам и данным должен предоставляться только в случае крайней необходимости.
Исполнение
Наконец, нулевое доверие требует, чтобы мы выполняли аутентификацию (подтверждение личности) и авторизацию (подтверждение того, что политика разрешает действие) на максимально возможном гранулярном уровне. Каждая система, предоставляющая доступ к данным или вычислениям, должна обеспечивать соблюдение границ безопасности, начиная с периметра и заканчивая отдельными компонентами.
Как и в случае с политикой, это обеспечение принудительного исполнения в идеале осуществляется единообразно во всем стеке. Вместо того, чтобы каждый компонент использовал свой собственный код исполнения, использование единого уровня исполнения позволяет проводить аудит и отделять проблемы разработчиков приложений от проблем операторов и команд безопасности.
Нулевое доверие для Kubernetes
Столкнувшись с необходимостью переосмыслить идентификацию с самых первых принципов, представить доверие в виде политик произвольной выразительности и обеспечить нашу инфраструктуру новыми механизмами принуждения на каждом уровне, вполне естественно испытать момент паники. И я уже говорил, что мы должны сделать это к 2024 финансовому году?
Хорошей новостью является то, что, по крайней мере, для пользователей Kubernetes некоторые аспекты принятия нулевого доверия значительно упрощаются. При всех своих недостатках и сложностях Kubernetes – это платформа с четко выраженной областью применения, хорошо определенной моделью безопасности и четкими механизмами расширения. Это делает ее плодотворной территорией для реализации нулевого доверия.
Одним из наиболее прямых способов решения проблемы сетей нулевого доверия в Kubernetes является сетка сервисов. Сервисная сетка использует преимущества мощной концепции Kubernetes «sidecar», в которой контейнеры платформы могут быть динамически вставлены во время развертывания рядом с контейнерами приложений в качестве формы позднего связывания операционной функциональности.
Сервисные сетки используют этот подход sidecar для добавления прокси в капсулы приложений во время выполнения и подключения этих прокси для обработки всего входящего и исходящего трафика. Это позволяет сервисной сетке предоставлять функции, отделенные от кода приложения. Такое разделение проблем между приложением и платформой является ключевым для ценностного предложения сервисной сетки: конечно, эти функции могут быть реализованы непосредственно в приложении, но, разделив их, мы позволяем командам безопасности и разработчикам проводить итерации независимо друг от друга, работая при этом над общей целью – безопасным, но полнофункциональным приложением.
Поскольку сервисная сетка по умолчанию обрабатывает сетевое взаимодействие с приложением и от него, она имеет все возможности для решения проблем нулевого доверия:
1. Идентификация рабочей нагрузки может быть получена из идентификатора капсулы в Kubernetes, а не из ее IP-адреса.
2. Аутентификация может быть осуществлена путем обертывания соединений во взаимный TLS, вариант TLS, в котором личность проверяется на обеих сторонах соединения с помощью криптографического доказательства.
3. Политика авторизации может быть выражена в терминах Kubernetes, например, с помощью пользовательских определений ресурсов (CRD), что делает политику явной и отделенной от приложения.
4. Самое главное, что обеспечение соблюдения правил осуществляется на уровне отдельных капсул равномерно по всему стеку. Каждая капсула выполняет свою собственную аутентификацию и авторизацию, что означает, что сети никогда не доверяют.
Вместе они обеспечивают большинство наших целей нулевого доверия (по крайней мере, для кластеров Kubernetes!). У нас есть идентификация рабочей нагрузки, а не сетевая идентификация; принудительное применение на самом гранулированном уровне – на уровне кластера; а также последовательный и единообразный способ применения аутентификации и авторизации во всем нашем стеке, без изменения приложения.
В рамках базовой структуры различные реализации сервисной сетки обеспечивают различные компромиссы. Например, Linkerd – это сетка сервисов с открытым исходным кодом и выпускной проект Cloud Native Computing Foundation, который обеспечивает реализацию, ориентированную в первую очередь на простоту, получая идентификацию рабочей нагрузки непосредственно из Kubernetes ServiceAccounts, чтобы обеспечить «нулевую конфигурацию», включенный по умолчанию взаимный TLS. Аналогичным образом, микропрокси Linkerd на базе Rust обеспечивают минималистичную реализацию нулевого доверия.
Конечно, простое добавление сервисной сетки в кластер не является панацеей. После установки необходимо взять на себя работу по определению, обновлению и оценке политик авторизации. Операторы кластера должны внимательно следить за тем, чтобы все вновь созданные капсулы были сопряжены со своим компонентом sidecar. И, конечно, сама сервисная сетка должна обслуживаться, контролироваться и обновляться, как и любое программное обеспечение на кластере. Однако, панацея или нет, сервисная сетка обеспечивает переход от стандартного незашифрованного, неаутентифицированного трафика в кластере к стандартному зашифрованному, аутентифицированному трафику с надежными идентификаторами рабочих нагрузок и богатой системой авторизации – это большой шаг к нулевому доверию.
Заключение
Нулевое доверие – это мощная модель безопасности, которая находится на переднем крае современной практики безопасности. Если вы сможете прорваться сквозь маркетинговый шум вокруг нее, то увидите некоторые глубокие и важные преимущества принятия нулевого доверия. И хотя нулевое доверие требует некоторых радикальных изменений основных идей, таких как идентификация, пользователи Kubernetes, по крайней мере, имеют большие преимущества, если они смогут принять сервисную сетку и перейти от чисто периметральной сетевой безопасности к «непрерывной проверке каждого пользователя, устройства, приложения и транзакции».
Источник: https://bit.ly/3SKRpQb
