Air gap не спасает: четыре практики, которые защитят закрытые кластеры Kubernetes

Когда в компании говорят об air gap, часто подразумевают лишь одно — отсутствие выхода в интернет. Отрезали внешнюю сеть, и кажется, что контур под контролем. Именно с этого допущения, по наблюдениям специалистов по контейнерным платформам, и начинаются самые серьёзные инциденты. В закрытой среде угрозу создают не столько внешние атакующие, сколько собственные процессы и упрощения, которые накапливаются со временем.

Подробности

В публикации рассматриваются типовые уязвимости air gap-среды Kubernetes, связанные с организацией внутренних процессов, а не с конкретными CVE. Среди основных проблем выделяются четыре. Первая — использование одного реестра образов на все зоны. Такая централизация упрощает администрирование, но размывает границы между контурами с разным уровнем доверия: образ, попавший в общий реестр, потенциально доступен всем зонам. Вторая — неподписанные артефакты. Без проверки подписи невозможно гарантировать, что в кластер разворачивается именно тот образ, который был собран и одобрен, а не подменённый или изменённый. Третья — устаревшая база уязвимостей. В закрытом контуре сканирование не получает обновлений извне автоматически, поэтому со временем база перестаёт отражать актуальные угрозы, и новые уязвимости остаются незамеченными. Четвёртая — автоматические политики, которые в стремлении защитить инфраструктуру могут, например, отключить кластеру сеть. Такая «забота» способна сама стать причиной отказа в обслуживании.

Что делать

Автор делится четырьмя практиками, которые помогают удерживать безопасность закрытых мультикластеров. Они выстроены вокруг перечисленных проблем. Во-первых, стоит отказаться от единого реестра на все зоны и разделять реестры по контурам доверия, чтобы образы не «протекали» между средами с разным уровнем защиты. Во-вторых, необходимо внедрять подпись артефактов и проверку подписей при развёртывании — это закрывает риск подмены образов. В-третьих, нужно обеспечивать регулярное обновление баз уязвимостей в закрытом контуре, заранее продумывая контролируемый канал доставки обновлений. В-четвёртых, автоматические политики следует проектировать осторожно, чтобы защитные механизмы не приводили к отключению критичных функций кластера. Итог: air gap — это не только отсутствие сетевого выхода, но и дисциплина внутренних процессов. Без контроля реестров, подписей, баз уязвимостей и автоматизации закрытый контур остаётся уязвимым.

Источник: Хабр — Информационная безопасность