Немного (в)водной
Kubernetes (или K8s) — это расширяемая платформа, которая становится стандартом среди систем оркестрации при построении Cloud Native приложений. Сейчас все больше компаний переходят на Kubernetes. Поскольку он является одной из самых критичных составляющих DevOps-процесса, возникает вопрос: “С чего начинать формирование безопасности Kubernetes?”
Как и у любой системы, сложности с Kubernetes возникают уже на этапе настройки безопасной конфигурации и обслуживания: интерфейсы CRI, CNI, CSI, точки встраивания и изменения, CRD, кастомные операторы и контроллеры, различные версии API и т.д. При этом далеко не все команды разработки в полной мере знают, как все работает внутри инфраструктуры.
В каждой организации Kubernetes уникален и удовлетворяет конкретные потребности. Поэтому чужие истории успеха, рассказывающие об использовании того или иного инструмента могут быть совершенно неэффективны для вашей компании.
Незащищен по умолчанию
В Kubernetes существует множество механизмов безопасности: RBAC, NetworkPolicy, PodSecurityPolicy (seccomp, AppArmor, SeLinux) и т.д. Но они по умолчанию отключены. Сделано это для того, чтобы первый опыт использования платформы был удачным, а запуск или перенос приложений не был ничем усложнен. При миграции в новое окружение дополнительные ограничения создают проблемы в работе приложений, которые могут сказаться на процессах всей компании.
Злоумышленники быстро и без особых усилий находят ошибки конфигурации с помощью сканирования портов в течение нескольких минут после деплоя. Атакующий может успешно эксплуатировать уязвимости на стороне сервера. Это прямой путь к утечке конфиденциальных данных, которой так боится любой бизнес.
Усугубляет ситуацию и тот факт, что угрозы постоянно изменяются и эволюционируют. Злоумышленник способен успешно проводить атаки и долго оставаться незамеченным благодаря особым знаниям, которыми не владеют те, кто защищает свои приложения и инфраструктуру.
Если ИБ-специалист отвечает за безопасность всей инфраструктуры, то атакующему стоит найти всего один изъян и уделить внимание одной конкретной области, чтобы скомпрометировать всю систему.
Таким образом, мы живем в мире, где атакующий всегда находится на шаг впереди. Наша задача — изменить подобный порядок вещей и опередить злоумышленника.
Черная кошка в темном Kubernetes
Необходимо стремиться к безопасности, которая достигается в первую очередь через понимание себя (своей системы), а не через понимание угроз. Угрозы быстро меняются, что дает атакующему значительное преимущество. Эту ситуацию можно изменить через понимание того, как все работает, и в дальнейшем сравнивать текущее и желаемое состояние защищенности системы. Прежде чем выбирать превентивные меры, необходимо научиться детектировать угрозы и досконально изучить все свои приложения. Поскольку Kubernetes стремится к самоизучению, самоконтролю и самоизлечению, современные системы должны быть обеспечены механизмами, направленными на самозащиту.
Большинство ИБ-инструментов смотрят на решение проблемы, как на поиск черной кошки в темной комнате, где черная кошка – это что-то плохое, а комната – окружение, в котором нужно найти “что-то плохое”. В настоящее время все инфраструктуры сложные, многогранные, и не все знают, как работают их системы и приложения. Cloud native apps не являются исключением.
Задача внутренней команды – включить в этой комнате свет и увидеть все, что происходит в инфраструктуре, чтобы идентифицировать все негативные аспекты без оглядки на возможности атакующего или любое другое аномальное поведение.
Подходы к безопасности облачных технологий
Первое решение для обеспечения безопасности K8s необходимо выбрать исходя из простоты использования и легкости интеграции с другими решениями.
Выделим подходы, которые стоит рассмотреть при работе с инфраструктурой Kubernetes:
- Подход Zero Trust (“нулевое доверие”) – модель безопасности, при которой нет доверия ни к кому и ни к чему, т.е. все пользователи и устройства должны подтверждать свои данные каждый раз, когда они запрашивают доступ к какому-либо ресурсу внутри или за пределами сети;
- Графовая модель – модель безопасности и представления данных, основанная на графе, который показывает все возможные последовательности действий или отношения между процессами. Согласно специалистам ИБ из Microsoft, сейчас безопасность думает списками, а нападающий – графами, и пришло время использовать против злоумышленников их же оружие;
- Безопасность Runtime – технология безопасности, которая обнаруживает и блокирует аномалии в приложениях в реальном времени с помощью добавления функций защиты в среду исполнения;
- Поиск аномалий, которые связаны не только с атаками, но также с проблемами некачественно написанного кода или неправильной конфигурацией.
Не так давно на рынке появился удачный пример решения, которое сочетает все модели безопасности и подходы, перечисленные выше. Luntry воплощает в себе опыт аудитов безопасности и пентестов в традиционных и облачных инфраструктурах. Luntry – это автоматизированный инструмент для обнаружения аномалий в реальном времени, который разработан на основе eBPF, графовой теории и машинного обучения, для Kubernetes-инфраструктур. Платформу используют команды для защиты от неизвестного, связанного как с безопасностью, так и с неправильной работой приложений.
Luntry подойдет вашей компании, если вам нужна удобная и эффективная платформа для работы подразделений ИТ и ИБ, при этом не требующая уникальных навыков от специалистов, работающих с ней.
Выводы и напутствия
Каждая инфраструктура Kubernetes уникальна, а следовательно, уникальны поверхность атаки и модель угроз. Значит, подход к вопросам обеспечения безопасности в каждом случае будет иметь свою специфику. Инфраструктура K8s сложная, но это утверждение не должно быть оправданием.
Помните о том, что безопасность – это не состояние, а процесс. Инструменты и подходы должны не “латать дыры”, а выстраивать процесс внутри компании. Так, например, использование инструмента поиска или анализа инцидентов будет совершенно неэффективным, если команда безопасности не успевает их разбирать.
Таким образом, чтобы внедрением нового механизма безопасности не сломать систему и не помешать функционированию приложений, разбирайтесь в том, как устроена ваша инфраструктура. Тогда знакомство и работа с безопасностью будут приятными, а не отталкивающими.
