Безопасность облака и Kubernetes
Поверхность атаки Kubernetes и пути захвата кластера — доступ к kube-api, RBAC, привилегированные поды, hostPath, анонимный etcd и эскалация на уровне узла.
15 вопросов
JuniorТеорияОчень частоЧто такое наименьшие привилегии в облачном IAM и чем опасны wildcard-политики?
Что такое наименьшие привилегии в облачном IAM и чем опасны wildcard-политики?
Наименьшие привилегии — выдавать только нужные нагрузке действия и ресурсы через кратковременные роли, а не долгоживущих пользователей с ключами. Wildcard в поле действия или ресурса выдаёт всё, поэтому одна утёкшая учётка означает доступ ко всему аккаунту.
Типичные ошибки
- ✗Считать долгоживущие ключи доступа равноценными кратковременным ролям
- ✗Полагать wildcard-политику безопасной, пока учётка не утекла
- ✗Сужать права людям, оставляя машинным идентичностям широкие права
Уточняющие вопросы
- →Как permission boundaries ограничивают то, что может выдать делегированный админ?
- →Почему неиспользуемая роль с wildcard-ресурсом всё равно является находкой аудита?
JuniorТеорияОчень частоЧто делает бакет объектного хранилища публичным и чем помогает Block Public Access?
Что делает бакет объектного хранилища публичным и чем помогает Block Public Access?
Итоговый доступ — объединение bucket policy, ACL объектов и настроек аккаунта: открыть бакет может любой из них, поэтому он выглядит приватным, пока ACL его раскрывает. Block Public Access перекрывает всё это на уровне аккаунта, а сканирование ловит дрейф.
Типичные ошибки
- ✗Проверять только bucket policy и игнорировать ACL объектов
- ✗Считать раскрытие своего бакета зоной ответственности провайдера
- ✗Понимать Block Public Access как простое сокрытие бакета из списка
Уточняющие вопросы
- →Как инструменты контроля конфигураций
CSPMнаходят ставший публичным бакет? - →Почему бакет может быть приватным, а один объект — доступным всем?
MiddleТеорияОчень частоЧем опасна широкая cross-account trust policy, когда вендору нужен доступ на чтение к вашему бакету?
Чем опасна широкая cross-account trust policy, когда вендору нужен доступ на чтение к вашему бакету?
Trust policy определяет, кто может принять роль. Если она доверяет целому внешнему аккаунту или wildcard-принципалу, любая идентичность оттуда примет её и получит ваши права — проблема запутанного заместителя. Указывайте точного принципала и external ID.
Типичные ошибки
- ✗Доверять целому внешнему аккаунту вместо одной именованной роли
- ✗Думать, что политика прав вендора ограничивает, кто примет вашу роль
- ✗Считать external ID косметикой, а не защитой от запутанного заместителя
Уточняющие вопросы
- →Как обнаружить слишком широкие trust policy сразу по всем вашим аккаунтам?
- →Почему resource policy на бакете важна даже при суженной роли?
JuniorТеорияЧастоЧем security group отличается от network ACL и почему начинают с default-deny?
Чем security group отличается от network ACL и почему начинают с default-deny?
Security group учитывает состояние и привязана к нагрузке: обратный трафик разрешается сам, а правила только разрешающие. Network ACL не хранит состояние, фильтрует на границе подсети и поддерживает запрещающие правила. Оба стартуют закрытыми.
Типичные ошибки
- ✗Добавлять исходящее правило для обратного трафика, уже разрешённого stateful-группой
- ✗Считать, что новая security group открыта, пока не добавлены правила
- ✗Ожидать запрещающих правил в security group вместо network ACL
Уточняющие вопросы
- →Когда блокировать диапазон источников уместнее на уровне network ACL подсети?
- →Почему ссылка на другую группу безопаснее широкого диапазона адресов?
MiddleТеорияЧастоПочему отключённый облачный журнал аудита — тревожный признак и как защищают целостность логов?
Почему отключённый облачный журнал аудита — тревожный признак и как защищают целостность логов?
Журнал аудита — единственная запись о том, кто из идентичностей вызвал какой API, поэтому его отключение уничтожает доказательства и само по себе ход злоумышленника. Сливайте журналы в отдельный аккаунт только на дозапись, включите проверку целостности и алертите на остановку.
Типичные ошибки
- ✗Считать остановленный журнал рутинным шумом, а не сигналом инцидента
- ✗Держать приёмник логов в том же аккаунте, что и нагрузку
- ✗Полагать, что шифрование транспорта даёт целостность логов в покое
Уточняющие вопросы
- →Почему лог-аккаунт должен быть вне досягаемости администраторов нагрузок?
- →Какие права нельзя выдавать на приёмник журналов аудита?
MiddleДизайнЧастоВ вашем аналитическом бакете лежат выгрузки клиентов. Компания-партнёр из своего облачного аккаунта должна читать один префикс этого бакета своим сервисом отчётности; ваша внутренняя ETL-роль продолжает писать во все префиксы. Ограничения — ничто в бакете никогда не должно быть доступно анонимно; партнёр не получает от вас долгоживущих ключей доступа; guardrail уровня организации должен сделать публичную выдачу невозможной, даже если инженер по ошибке её напишет; каждое чтение партнёра должно связываться с именованной идентичностью в журнале аудита; решение должно пережить создание нового бакета в следующем квартале без повторного ревью. Опишите схему доступа — кому какие права, где живёт каждый контроль и как вы обнаружите дрейф.
В вашем аналитическом бакете лежат выгрузки клиентов. Компания-партнёр из своего облачного аккаунта должна читать один префикс этого бакета своим сервисом отчётности; ваша внутренняя ETL-роль продолжает писать во все префиксы. Ограничения — ничто в бакете никогда не должно быть доступно анонимно; партнёр не получает от вас долгоживущих ключей доступа; guardrail уровня организации должен сделать публичную выдачу невозможной, даже если инженер по ошибке её напишет; каждое чтение партнёра должно связываться с именованной идентичностью в журнале аудита; решение должно пережить создание нового бакета в следующем квартале без повторного ревью. Опишите схему доступа — кому какие права, где живёт каждый контроль и как вы обнаружите дрейф.
Block Public Access включён на уровне аккаунта, плюс guardrail организации запрещает любую публичную выдачу. Партнёр принимает вашу роль с external ID; политика бакета даёт ей чтение только одного префикса, а ETL-роли — запись. Чтения атрибутируются, дрейф ловит сканирование.
Типичные ошибки
- ✗Считать неугадываемое имя префикса средством контроля доступа
- ✗Выдавать доступ всему аккаунту партнёра вместо одной именованной роли
- ✗Полагаться на ручное ревью вместо guardrail уровня организации
Уточняющие вопросы
- →Как guardrail защитит новый бакет следующего квартала без ревью?
- →На что алертить, если роль партнёра начнёт читать другие префиксы?
MiddleДизайнЧастоВаша размещённая CI-система деплоит один сервис в продовый облачный аккаунт. Сейчас пайплайн хранит постоянный ключ доступа с правами администратора в секрете проекта. Ограничения — долгоживущих облачных учётных данных в CI быть не должно вовсе; продовый доступ получает только job деплоя из релизной ветки одного репозитория; учётка обязана истечь в пределах job; роль может обновлять только этот один сервис; скомпрометированный раннер не должен читать данные клиентов, создавать идентичности или отключать логирование; каждый деплой должен связываться с коммитом в журнале аудита; в следующем месяце так же подключится вторая команда. Опишите схему и контроли, удерживающие её в наименьших привилегиях.
Ваша размещённая CI-система деплоит один сервис в продовый облачный аккаунт. Сейчас пайплайн хранит постоянный ключ доступа с правами администратора в секрете проекта. Ограничения — долгоживущих облачных учётных данных в CI быть не должно вовсе; продовый доступ получает только job деплоя из релизной ветки одного репозитория; учётка обязана истечь в пределах job; роль может обновлять только этот один сервис; скомпрометированный раннер не должен читать данные клиентов, создавать идентичности или отключать логирование; каждый деплой должен связываться с коммитом в журнале аудита; в следующем месяце так же подключится вторая команда. Опишите схему и контроли, удерживающие её в наименьших привилегиях.
Замените хранимый ключ федерацией через OIDC — провайдер доверяет издателю CI, а trust policy роли фиксирует claim репозитория, ветки и job, поэтому токены кратковременны. Сузьте права до одного сервиса, добавьте permission boundary, а журнал аудита свяжет каждую сессию с коммитом.
Типичные ошибки
- ✗Считать постоянный админский ключ допустимым, раз секрет в CI зашифрован
- ✗Федерировать без фиксации claim репозитория и ветки в trust policy
- ✗Полагаться на историю job в CI вместо облачного журнала аудита
Уточняющие вопросы
- →Как подключить вторую команду, не расширяя существующую роль?
- →Какой сигнал покажет принятие деплой-роли из неожиданной ветки?
MiddleТеорияЧастоКак устроено конвертное шифрование и почему политика ключа KMS сама по себе даёт доступ?
Как устроено конвертное шифрование и почему политика ключа KMS сама по себе даёт доступ?
Данные шифруются дата-ключом, обёрнутым мастер-ключом, который не покидает сервис ключей; рядом с данными едет лишь обёрнутый ключ. Политика ключа — второй слой авторизации: она может выдать право на ключ даже там, где IAM-политика молчит, поэтому проверяйте оба.
Типичные ошибки
- ✗Думать, что мастер-ключ сам шифрует данные и покидает сервис ключей
- ✗Считать, что доступ к ключу решает только IAM
- ✗Полагать, что политика ключа может лишь сужать доступ, но не выдавать
Уточняющие вопросы
- →Как отдельный ключ на тенанта сужает радиус поражения при компрометации ключа?
- →Зачем смотреть политики ключей, когда аудируете доступ к зашифрованному бакету?
MiddleДебаггингЧастоУчётные данные роли инстанса всплывают в журнале аудита с внешнего адреса. Что настроено неверно?
Учётные данные роли инстанса всплывают в журнале аудита с внешнего адреса. Что настроено неверно?
Инстанс всё ещё принимает бестокенный протокол метаданных v1 и несёт роль с wildcard, поэтому дефект подделки запросов дал прочитать учётные данные роли и переиграть их вне хоста — выдаёт это чужой адрес. Требуйте IMDSv2 и hop limit в единицу, сузьте роль.
Открыть задачу →Типичные ошибки
- ✗Принимать чужой адрес источника за NAT-шлюз, а не за переигранные учётки
- ✗Оставлять HttpTokens в optional, раз IMDSv2 описан как обратно совместимый
- ✗Чинить только опции метаданных, оставляя wildcard-роль на месте
Уточняющие вопросы
- →Каким запросом по журналу найти все роли инстансов, использованные вне ваших диапазонов?
- →Почему hop limit равный единице важен, даже когда токены уже обязательны?
MiddleТеорияЧастоПочему облачные секреты держат в managed-хранилище, а не в env-переменных, и зачем ротация?
Почему облачные секреты держат в managed-хранилище, а не в env-переменных, и зачем ротация?
Переменные окружения, образы и user-data читает любой, кто может описать инстанс или открыть лог сборки, и они не истекают. Хранилище держит значение вне образа, пускает к чтению по IAM-политике, журналирует обращения и ротирует — утечка недолговечна.
Типичные ошибки
- ✗Считать переменную окружения приватной для читающего её процесса
- ✗Полагать, что неизменяемый образ машины нельзя прочитать обратно
- ✗Пропускать ротацию, раз хранилище секретов уже шифрует значение
Уточняющие вопросы
- →Как нагрузка аутентифицируется в хранилище секретов без стартового секрета?
- →Какой сигнал в логах покажет чтение секрета неожиданным принципалом?
MiddleДизайнЧастоВы размещаете сервис обработки платежей в облачной сети. Он должен читать и писать один бакет объектного хранилища и вызывать два API провайдера плюс ровно один внешний эндпоинт партнёра. Ограничения — входящих соединений из интернета к нему быть не должно; трафик к бакету не должен идти через публичный интернет; исходящий трафик куда-либо, кроме эндпоинта партнёра, должен быть невозможен, а не просто залогирован; операторам нужны административные сессии без публичного bastion-хоста; скомпрометированный контейнер приложения не должен дотянуться до других нагрузок компании; решение должно проверяться ревьюером, читающим только конфигурацию. Опишите схему сети и контроль на каждой границе.
Вы размещаете сервис обработки платежей в облачной сети. Он должен читать и писать один бакет объектного хранилища и вызывать два API провайдера плюс ровно один внешний эндпоинт партнёра. Ограничения — входящих соединений из интернета к нему быть не должно; трафик к бакету не должен идти через публичный интернет; исходящий трафик куда-либо, кроме эндпоинта партнёра, должен быть невозможен, а не просто залогирован; операторам нужны административные сессии без публичного bastion-хоста; скомпрометированный контейнер приложения не должен дотянуться до других нагрузок компании; решение должно проверяться ревьюером, читающим только конфигурацию. Опишите схему сети и контроль на каждой границе.
Разместите нагрузку в приватных подсетях без маршрута к интернет-шлюзу. К бакету и API провайдера ходите через приватные эндпоинты, чьи политики называют только ваши ресурсы. Вызов партнёра — через egress-прокси со списком разрешённых. Вместо bastion — сервис сессий и отдельный аккаунт.
Типичные ошибки
- ✗Считать публичную подсеть безопасной, пока не открыт входящий порт
- ✗Логировать egress вместо того, чтобы сделать чужие назначения недостижимыми
- ✗Ходить к объектному хранилищу через интернет-эндпоинт, раз трафик зашифрован
Уточняющие вопросы
- →Что даёт политика эндпоинта сверх самой политики бакета?
- →Как отдельный аккаунт ограничивает радиус поражения этой нагрузки?
JuniorТеорияИногдаПочему анонимный доступ к kube-api и привилегированные поды — самые опасные дефекты в кластере Kubernetes?
Почему анонимный доступ к kube-api и привилегированные поды — самые опасные дефекты в кластере Kubernetes?
Анонимный kube-api — control plane без учётных данных: чтение и создание ресурсов — контроль над кластером. Привилегированный под (privileged, hostPath, host network) — почти root на узле: монтирует ФС хоста, читает чужие секреты, сбегает.
Типичные ошибки
- ✗Недооценивать анонимный kube-api как доступ лишь к health-эндпоинтам
- ✗Считать привилегированный под изолированным наравне с обычным
- ✗Думать, что Kubernetes блокирует анонимный доступ по умолчанию
Уточняющие вопросы
- →Как привилегированный под с hostPath приводит к компрометации узла?
- →Почему доступ к kube-api эквивалентен контролю над кластером?
MiddleТеорияИногдаПочему уязвимость подделки серверных запросов SSRF раскрывает учётные данные роли инстанса и что меняет IMDSv2?
Почему уязвимость подделки серверных запросов SSRF раскрывает учётные данные роли инстанса и что меняет IMDSv2?
Сервис метаданных отвечает по link-local адресу, поэтому SSRF заставляет инстанс запросить учётные данные своей роли и вернуть их наружу — атакующий наследует её права в IAM. IMDSv2 требует сессионный токен и низкий hop limit, чего слепой SSRF не выдаст.
Типичные ошибки
- ✗Считать, что эндпоинт метаданных недостижим из кода приложения
- ✗Понимать IMDSv2 как изменение производительности, а не контроль доступа
- ✗Полагать, что данные роли лежат на диске, а не за сервисом метаданных
Уточняющие вопросы
- →Как проверить, какие инстансы всё ещё принимают протокол метаданных v1?
- →Почему hop limit равный одному важен для контейнеров в сети хоста?
SeniorДизайнИногдаВы строите модель угроз для управляемого кластера Kubernetes. Опишите поверхность атаки по четырём осям — инфраструктура (узлы/гипервизор), приложения (опубликованные сервисы и поды), kube-api (доступ и RBAC) и учётные данные (etcd, секреты). Какая ось несёт наибольший риск и требует укрепления в первую очередь и почему?
Вы строите модель угроз для управляемого кластера Kubernetes. Опишите поверхность атаки по четырём осям — инфраструктура (узлы/гипервизор), приложения (опубликованные сервисы и поды), kube-api (доступ и RBAC) и учётные данные (etcd, секреты). Какая ось несёт наибольший риск и требует укрепления в первую очередь и почему?
Инфраструктура — ОС/ядро узла, SSH, гипервизор. Приложения — открытые nodePort/ingress, Dashboard, привилегированные поды, недоверенные образы. kube-api — анонимный доступ, избыточный RBAC. Учётные данные — открытый etcd, секреты namespace. Первым укрепляют kube-api — это контроль над кластером.
Типичные ошибки
- ✗Сводить поверхность атаки кластера к единственному вектору (например, дашборду)
- ✗Считать привилегированный под и анонимный etcd безопасными
- ✗Игнорировать избыточные RBAC-права как путь от пода к контролю над кластером
Уточняющие вопросы
- →Почему избыточные RBAC-права на exec или secrets эскалируют до контроля над кластером?
- →Почему анонимный доступ к etcd так же опасен, как доступ к kube-api?
SeniorДизайнИногдаВы проектируете защиту данных для мультитенантной SaaS-платформы с регулируемыми записями клиентов в общей базе и общем бакете объектного хранилища. Ограничения — данные каждого тенанта должны оставаться нечитаемыми для другого, даже если баг приложения вернёт чужие строки; компрометация ключа одного тенанта не должна раскрывать остальных; команда платформы обязана делать бэкапы и миграции, никогда не имея доступа к открытому тексту; регулятор требует доказательства, кто мог расшифровать что в любой прошлый момент; офбординг тенанта должен делать его данные невосстановимыми в документированный срок; внутренний трафик сервисов защищён так же, как внешний. Опишите схему шифрования, разделения ключей и доступа, а также принимаемые компромиссы.
Вы проектируете защиту данных для мультитенантной SaaS-платформы с регулируемыми записями клиентов в общей базе и общем бакете объектного хранилища. Ограничения — данные каждого тенанта должны оставаться нечитаемыми для другого, даже если баг приложения вернёт чужие строки; компрометация ключа одного тенанта не должна раскрывать остальных; команда платформы обязана делать бэкапы и миграции, никогда не имея доступа к открытому тексту; регулятор требует доказательства, кто мог расшифровать что в любой прошлый момент; офбординг тенанта должен делать его данные невосстановимыми в документированный срок; внутренний трафик сервисов защищён так же, как внешний. Опишите схему шифрования, разделения ключей и доступа, а также принимаемые компромиссы.
Дайте каждому тенанту свой мастер-ключ с политикой, оборачивающий дата-ключи объектов, чтобы чужая строка осталась нечитаемым шифротекстом. Роли платформы получают бэкап и миграцию, но не грант на расшифровку. Изменения ключей и расшифровки идут в неизменяемый журнал; офбординг удаляет ключ.
Типичные ошибки
- ✗Полагаться на тенант-фильтр приложения вместо криптографического разделения
- ✗Оставлять ролям платформы грант на расшифровку, не нужный для бэкапов
- ✗Считать офбординг мягким удалением, а не уничтожением ключа тенанта
Уточняющие вопросы
- →Какой эксплуатационной ценой оборачивается ключ на тенанта при десяти тысячах тенантов?
- →Как доказать регулятору, кто мог расшифровать запись в прошлом году?
