Глава 3. Моделирование угроз

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

По окончанию успешного сеанса моделирования угроз, вы получаете возможность определения следующего:

При моделировании угроз в отрасли обычно следуют одним из таких подходов:

Существуют и прочие подходы {Прим. пер.: например, см. Threat Modeling: 12 Available Methods Наталии Шевченко}, но предыдущие три наиболее часто применяются в нашей отрасли.

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

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

Компоненты Kubernetes работают совместно для обеспечения того, чтобы все запущенные внутри этого кластера микрослужбы функционировали ожидаемым образом. Когда вы развёртываете микрослужбу в как DaemonSet, компоненты Kubernetes будет обеспечивать что в каждом узле будет иметься один исполняющий эту службу под, причём, ни более, ни менее. Итак, что же происходит за сценой? Давайте взглянем на схему, чтобы показать на верхнем уровне взаимодействие компонентов:

 

Рисунок 3-1

Взаимодействие между компонентами Kubernetes

Быстро резюмируем что эти компоненты делают:

Следует отметить, что с etcd взаимодействует только kube-apiserver. Прочие компоненты Kubernetes, таких как kube-scheduler, kube-controller-manager и cloud-controller-manager взаимодействуют с запущенным в узлах зозяев kube-apiserver для осуществления их обязанностей. На своих узлах исполнителей, и kubelet, и kube-proxy взаимодействуют с kube-apiserver.

Давайте рассмотрим в качестве примера того как общаются друг с другом эти компоненты создание DaemonSet:

 

Рисунок 3-2

Создание DaemonSet в Kubernetes

Для создания DaemonSet мы применяем такие шаги:

Обратите внимание, что не все взаимодействия между компонентами по умолчанию безопасные. Это определяется настройками таких компонентов. Мы обсудим это более подробно в Главе 6, Защита компонентов кластера.

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

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

Приводимая ниже схема выделяет различных злоумышленников в экосистеме Kubernetes:

 

Рисунок 3-3

Злоумышленники в средах Kubernetes

Как вы можете видеть из этой схемы, конечный пользователь обычно взаимодействует через маршруты HTTP/HTTPS, выставляемые имеющимися контроллерами ingress, балансировщиками нагрузки или соответствующими подами. Конечный пользователь обладает наинизшими полномочиями. Внутренний злоумышленник, с другой стороны, обладает ограниченным доступом к имеющемся в кластере ресурсам. Привилегированный злоумышленник имеет больше всего полномочий и обладает возможностью изменения всего кластера. Эти три категории злоумышленников помогают определять серьёзность угроз. Некая угроза, в которую вовлечён конечный пользователь имеет более высокий уровень серьёзности по сравнению с угрозой со стороны привилегированного злоумышленника. Хотя на схеме эти роли и кажутся изолированными, злоумышленник способен измениться из конечного пользователя во внутреннего злоумышленника, применяя атаку с повышением полномочий.

Со своим новым пониманием компонентов и злоумышленников Kubernetes, мы отправляемся в путешествие моделирования угроз некого кластера Kubernetes. В своей следующей таблице мы рассматриваем все основные компоненты, узлы и поды Kubernetes. Узлы и поды это основополагающие объекты Kubernetes, которые исполняют рабочие нагрузки. Обратите внимание, что все эти компоненты выступают ресурсами и подлежат защите от угроз. Когда любой из этих компонентов превращается в скомпрометированный, это может повлечь следующий этап некой атаки, например, эскалации полномочий. Кроме того, заметьте, что kube-apiserver и etcd являются мозгом и сердцем кластера Kubernetes. Когда скомпрометирован любой из них, это будет окончанием игры.

Приводимая далее таблица выделяет все угрозы в конфигурации кластера Kubernetes по умолчанию. Эта таблица к тому же высвечивает как разработчики и администраторы кластера способны защищать свои ресурсы от таких угроз:

Данная таблица выделяет лишь некоторые из угроз. Имеются и прочие угрозы, которые будут обсуждены в последующих главах. Мы надеемся, что предыдущая таблица вдохновит вас задуматься на обсуждение вслух того что подлежит защите и как это защищать в вашем кластере Kubernetes.

Теперь, когда мы рассмотрели угрозы в неком кластере Kubernetes, давайте перейдём к обсуждению того чем отличается моделирование угроз для некого разрабатываемого в Kubernetes приложения. Развёртывание в Kubernetes дополнительно увеличивает сложность в моделирование угроз. Kubernetes прибавляет дополнительные подлежащие рассмотрению вопросы, ресурсы, злоумышленников и новые меры безопасности, которые требуется учитывать перед исследованием угроз для вашего развёрнутого приложения.

Давайте рассмотрим простой пример трёхуровневого веб приложения:

 

Рисунок 3-4

Моделирование угроз в традиционном веб приложении

В среде Kubernetes то же самое приложение выглядит несколько иначе:

 

Рисунок 3-5

Моделирование угроз в трёхуровневом веб приложении в Kubernetes

Как показано на предыдущей схеме, все наши веб сервер, сервер приложений и базы данных запущены внутри подов. Давайте проведём сопоставление на верхнем уровне моделирования угроз между традиционной веб архитектурой и естественной для облачных решений ахитектуры:

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

В этой главе мы начали с введения в базовые понятия моделирования угроз. Мы обсудили все важные ресурсы, угрозы и всех злоумышленников в средах Kubernetes. Мы рассмотрели разные меры безопасности и стратегии снижения рисков для улучшения положения безопасности в вашем кластере Kubernetes.

Далее мы прошлись по моделированию угроз приложения, приняли во внимание развёртываемые в Kubernetes приложения м сопоставили их с традиционным моделированием угроз монолитных приложений. Та сложность, которая вносится построением Kubernetes, усложняет моделирование угроз, причём, как мы показали: следует защищать больше ресурсов и бороться с большим количеством злоумышленников. К тому же, дополнительные меры безопасности не обязательно означают большую безопасность.

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

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

Trail of Bits and Atredis Partners проделали хорошую работу по моделированию угроз компонентов Kubernetes. Вы можете обнаружить её в белых страницах.

Обратите внимание, что цель, масштабы и подход к моделированию угроз в предыдущем техническом документе отличались. Так что и результаты будут несколько иными.