Эксплуатация уязвимостей в инфраструктуре — один из самых распространённых методов для проведения кибератак: злоумышленники используют его примерно в трети случаев. Урон зависит от того, насколько хорошо (или плохо) компания подготовлена к угрозам: дело может ограничиться небольшим убытком или дойти до потери доверия клиентов, штрафов от регуляторов и даже до банкротства. Например, недавно одну британскую компанию со 150-летней историей погубил слабый пароль одного из сотрудников.
В этой статье обсудим, как минимизировать риски безопасности с помощью модели «нулевого доверия» (Zero Trust): разберём, что такое Zero Trust, чем она отличается от классической модели Perimeter-based, почему именно модель Zero Trust актуальна для современных приложений и как она реализована в Deckhouse Kubernetes Platform.
Классическая модель безопасности Perimeter-based
Модель информационной безопасности определяет, с помощью каких принципов и мер обеспечивается безопасность системы.
Классическая модель безопасности — так называемая модель с внешним периметром (Perimeter-based). Периметр чётко обозначен и защищает всё, что расположено внутри него. Таким образом, Perimeter-based-модель предполагает, что злоумышленники находятся только за пределами периметра, в то время как внутри него — доверенная безрисковая среда.Главный минус этой модели в том, что она ориентирована на защиту от внешних угроз, но оставляет без особого внимания внутренние. Если злоумышленник проникнет за периметр, например через аккаунт внутреннего сотрудника, то сможет беспрепятственно копировать, шифровать или удалять данные.
Несмотря на такой существенный минус модели, до сих есть системы, для которых она подходит. Это госучреждения, военные и промышленные объекты, лаборатории. У инфраструктуры в таких организациях, как правило, есть чёткий внешний периметр: доступ вовне возможен только через одну или несколько строго определённых точек, которые усиленно защищают. Такие системы, как правило, статичны, а взаимодействия в них ограничены и предсказуемы. Однако в современном мире такие инфраструктуры в меньшинстве.
Риски современных Kubernetes-приложений
Большинство приложений сейчас разрабатывается на основе микросервисов — небольших отдельных служб, которые в совокупности и образуют приложение. В зависимости от их назначения микросервисы могут быть написаны на разных языках программирования и использовать разные технологии. Микросервис существует в изолированной среде — контейнере, который содержит все необходимые микросервису ресурсы. Поскольку контейнеров может быть много, необходимо ими управлять и организовывать их взаимодействие с внешним миром. В этом помогают системы оркестрации контейнеров, например Kubernetes.
В Kubernetes контейнеры организуются в группы (поды) и размещаются на узлах кластера. Узлы могут коммуницировать друг с другом и с другими компонентами внутри и извне кластера. Также в кластере может передаваться и храниться конфиденциальная информация (ключи, пароли). Подробнее о том, что такое Kubernetes и микросервисы, мы рассказывали в отдельной статье.
Как видно, приложения в Kubernetes работают в многоуровневой структуре: микросервис → контейнер → под → узел → кластер. Такая «слоистость» увеличивает поверхность атаки — количество точек, через которые злоумышленник может проникнуть в систему.
Вот несколько примеров угроз, которые актуальны, если в кластере Kubernetes не настроены или неверно настроены меры безопасности:
- Неавторизованные пользователи или сервисы могут получить несанкционированный доступ в кластер и взаимодействовать с конфиденциальными данными.
- При уязвимостях в настройке ролей и доступов злоумышленник может повысить свои привилегии в кластере до максимальных и поставить под угрозу целостность всей системы.
- Кластер может стать уязвимым для DDoS-атак, которые отнимают ресурсы и тем самым бьют по производительности приложений.
- Если в кластере не настроены шифрование и управление чувствительной информацией, данные могут перехватить и украсть.
Таким образом, кластер Kubernetes — это совокупность тесно взаимосвязанных компонентов, которые могут передавать друг другу секретную информацию и к которым можно получить доступ снаружи. Кроме того, это очень подвижная система: постоянно создаются и удаляются поды, движется трафик, меняются права доступа. Поэтому периметр в кластере существует лишь условно, а всё взаимодействие компонентов внутри кластера находится в «слепой зоне» периметра. Это значит, что кластер не будет качественно защищён, если организовать защиту по модели Perimeter-based.
Более подходящая для кластера Kubernetes модель безопасности — Zero Trust.
Модель безопасности Zero Trust
Как можно понять из названия, Zero Trust — это модель «нулевого доверия». При такой схеме не имеет значения, находятся пользователи и сервисы внутри кластера или вне его, — доверенных объектов просто не существует.
Основные принципы Zero Trust:
- Все пользователи и устройства считаются ресурсами системы, учитываются и должны соблюдать меры безопасности.
- Аутентификация и авторизация ждут всех пользователей и службы не только на входе в систему, но и при любых перемещениях внутри неё. При верификации контролируются не только учётные данные, например логин и пароль, но и метаданные: географическое положение, время обращения, поведенческие атрибуты. Например, если сотрудник компании запрашивает доступ к внутренним инструментам с верным логином и паролем, но с неучтённого устройства, из необычного места или в нетипичное время, это потребует дополнительных подтверждений.
- Доступ выдаётся только к одному компоненту системы. Для доступа к другому компоненту нужно проходить отдельные аутентификацию и авторизацию. При этом выдаются минимально необходимые права на ограниченное время (сеанс) — нет никаких «мастер-ключей от всех дверей» и неограниченных прав.
- Происходит постоянный мониторинг состояния системы. При аномалиях рассылаются предупреждения и ограничивается доступ.
- Трафик и конфиденциальная информация шифруются.
Таким образом, если безопасность приложения обеспечивается по модели Zero Trust, злоумышленник, даже проникнув в систему, получит доступ только к ограниченному числу компонентов, не сможет читать пакеты трафика и секретные данные и, скорее всего, будет довольно быстро обнаружен инструментами мониторинга.
Для компании защита информации на основе Zero Trust — это прежде всего возможность минимизировать урон от атак: избежать длительных простоев и сохранить критически важные для бизнеса данные и сервисы. Кроме того, если компания не допускает утечек и переживает атаки без существенных потерь, это повышает доверие клиентов к ней.
В сферах финансов, медицины, критической инфраструктуры и госсектора действуют особенно жёсткие стандарты безопасности, например PCI SSC, ISO 27001, приказы ФСТЭК России. В Zero Trust уже заложена большая часть этих требований, поэтому бизнесу, если он организует защиту инфраструктуры по этой модели, будет проще проходить аудиты и избегать юридических рисков.
Согласно отчёту Gartner, уже более половины мировых компаний частично или полностью внедрили у себя Zero Trust. Тем не менее, по данным того же отчёта, внедрённые меры покрывают в лучшем случае четверть рисков бизнеса. Так происходит потому, что переход на Zero Trust — сложный, длительный и дорогой процесс: компании не всегда понимают, с чего начать внедрение, какие элементы инфраструктуры защищать в первую очередь, какой бюджет и штат заложить на изменения. Иногда адаптация Zero Trust требует перестройки всей инфраструктуры и бизнес-процессов. Чтобы ускорить переход и не строить Zero Trust с нуля самим, можно рассмотреть готовые инструменты, которые позволят оперативно закрыть наиболее критичные уязвимости. При развёртывании приложений на базе Kubernetes таким инструментом может стать Deckhouse Kubernetes Platform (DKP).
Zero Trust в Deckhouse Kubernetes Platform
Deckhouse Kubernetes Platform соответствует основным стандартам безопасности: PSI SSC, CIS Kubernetes Benchmarks, требованиям ФСТЭК России.
Принципы Zero Trust реализованы в DKP на нескольких уровнях:
- Безопасность контейнеров и их групп (подов). Чаще всего атаки в кластере Kubernetes проводят с помощью повышения привилегий контейнеров и подов. Контейнеры создаются на основе образов, в которые может быть встроено вредоносное ПО, и оно также может повышать себе привилегии. В DKP для обеспечения безопасности контейнеров и подов применяются специальные контроллеры и политики безопасности (встроенные и собственные), которые ограничивают возможности контейнеров и выделяемые им ресурсы.
- Сетевая безопасность. Компоненты кластера Kubernetes общаются друг с другом и с внешним миром по сети. Чтобы контролировать это взаимодействие, а в случае атаки — локализовать её, сеть в кластере необходимо делить на сегменты. В DKP за сегментирование и безопасность сети отвечают сетевые политики и плагин Cilium.
- Управление доступом. Как мы уже говорили выше, доступ по модели Zero Trust организуется по строгим правилам: аутентификация и авторизация при каждом новом действии, минимально необходимый объём прав. Аутентификацию в DKP можно настроить через различных провайдеров, а авторизацию — с помощью разветвлённой ролевой модели.
- Хранение и передача секретов. В DKP встроен Deckhouse Stronghold Community Edition — младшая редакция нашего хранилища секретов, которое обеспечивает безопасное управление жизненным циклом паролей, сертификатов, токенов, ключей API и SSH-ключей, а также их автоматизированную доставку в приложения, запущенные в кластере Kubernetes.
- Шифрование внутреннего трафика. Трафик в кластере необходимо шифровать, чтобы его нельзя было прочитать, даже если удалось перехватить. В DKP это делается с применением Istio.
- Аудит безопасности кластера. В DKP есть инструменты для сканирования образов контейнеров на известные уязвимости и для проверки соответствия кластера требованиям безопасности. Платформа позволяет настраивать и применять политики и правила аудита, а также рассылать оповещения и формировать отчёты по итогу проверок. DKP также поддерживает мониторинг поведения и аномалий через встроенные инструменты наблюдаемости.
Подробнее о том, как модель Zero Trust реализована в DKP и какие решения для организации безопасности в кластере предлагает платформа, мы рассказываем на курсе «Инструменты безопасности в Deckhouse Kubernetes Platform». Первая лекция доступна в виде бесплатного мини-курса «Основы информационной безопасности в Kubernetes и Deckhouse Kubernetes Platform».