Вопросы по безопасности инфраструктуры на собеседовании

Безопасность в собесе эксплуатации звучит как набор практических ситуаций: как ротировать пароль базы без простоя, что остаётся открытым после увольнения инженера, почему контейнер не должен работать от root и как понять, что в прод едет именно ваш образ.

Что спрашивают

• +Секреты: хранилище против файла на сервере, ротация с перекрытием, динамические учётки
• +Доступы: SSH по ключам и бастион, отдельная учётка на сервис, долгоживущие токены
• +Сертификаты: цепочка доверия, автопродление и мониторинг срока, взаимный TLS
• +Цепочка поставки и харденинг: сканирование образов, подпись и SBOM, непривилегированный пользователь, профиль безопасности пода

Из чего состоит тема

Так тема разложена в тренажёре: движок ведёт прогресс по каждой подтеме отдельно и возвращает те, где вы ошибаетесь.

• Доступы и least privilege7
• Секреты и Vault7
• TLS и сертификаты6
• Уязвимости и supply chain6
• Харденинг и DevSecOps6

Разборы подтем

Конспект по каждой: что это, как отвечать вслух, на чём валятся, плюс вопросы для самопроверки.

• Секреты: хранилище и ротация7 вопросов
• Доступы: SSH, бастион, минимальные права7 вопросов
• TLS-сертификаты в эксплуатации6 вопросов
• Цепочка поставки: сканеры, подписи, SBOM6 вопросов
• Харденинг контейнеров и гейты в CI6 вопросов

Примеры вопросов с разбором

1. #dvo_access1 / 9
   Какая настройка SSH на прод-серверах базовая?

   A)Сменить порт на нестандартный: это отсекает атаки

   B)Разрешить пароли, но включить длинные и сложные

   C)Только ключи, вход root запрещён, доступ через бастион

   D)Открыть доступ извне, но включить журналирование

   показать ответ и разбор

   +C)Только ключи, вход root запрещён, доступ через бастион

   // разбор: Пароли подбирают, ключи — нет. Прямой вход под root лишает журнал имени того, кто пришёл: заходят под своей учёткой и повышают права через sudo. Бастион (или VPN) убирает сервисы из открытого интернета и даёт одну точку контроля и записи сессий. Смена порта отсекает шумных ботов, но это косметика поверх перечисленного, а не защита.

2. #dvo_hardening2 / 9
   Почему в образе просят прописать непривилегированного пользователя?

   A)Root внутри контейнера — это root на ядре хоста при побеге

   B)От root процессы работают медленнее из-за проверок ядра

   C)Иначе логи контейнера будут писаться от чужого владельца

   D)Root не даёт контейнеру слушать порты выше тысячи

   показать ответ и разбор

   +A)Root внутри контейнера — это root на ядре хоста при побеге

   // разбор: Пользователи в контейнере и на хосте — это одни и те же числовые идентификаторы, если не включён user namespace. Значит, root в контейнере равен root на узле, и любая дыра в рантайме или неудачное монтирование превращается в полный доступ к машине. Плюс от root проще навредить самому себе: правки в системных каталогах образа, файлы с чужими правами на смонтированных томах.

3. #dvo_secrets3 / 9
   Секреты лежат в файле .env на каждом сервере. Что даёт переход на хранилище секретов?

   A)Приложение перестаёт видеть секреты в открытом виде

   B)Единое место, аудит обращений и ротация без обхода серверов

   C)Секреты становятся частью образа и едут вместе с релизом

   D)Отпадает необходимость ограничивать права на файлы

   показать ответ и разбор

   +B)Единое место, аудит обращений и ротация без обхода серверов

   // разбор: Файл на сервере невозможно ни отозвать, ни проверить: неизвестно, кто его читал и сколько копий разошлось по ноутбукам. Хранилище даёт одну точку выдачи, журнал обращений, разграничение по ролям и ротацию без обхода машин. Приложение получает значение в память при старте или по запросу — в открытом виде оно всё равно окажется, но время его жизни и круг доступа резко сужаются.

4. #dvo_supply_chain4 / 9
   Зачем сканировать собранные образы, если код прошёл ревью?

   A)В базовом слое и зависимостях есть уязвимости

   B)Сканер проверяет корректность Dockerfile и порядок инструкций

   C)Так измеряется размер образа и находятся лишние слои

   D)Сканер подтверждает, что образ собран из нужной ветки

   показать ответ и разбор

   +A)В базовом слое и зависимостях есть уязвимости

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

5. #dvo_tls_certs5 / 9
   Клиент ругается на самоподписанный сертификат внутреннего сервиса. Почему?

   A)Такой сертификат не поддерживает современные версии протокола

   B)У него слишком короткий срок действия, клиенты это отвергают

   C)В нём нет имени сервиса, потому проверка не проходит

   D)Его некому подтвердить: подписи доверенного центра нет

   показать ответ и разбор

   +D)Его некому подтвердить: подписи доверенного центра нет

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

6. #dvo_access6 / 9
   Все сервисы ходят в облако под одной учётной записью с полными правами. Чем это плохо, кроме принципа?

   A)Провайдер ограничивает число операций на учётную запись

   B)Взлом одного сервиса открывает всё сразу

   C)Такие учётки не годятся для автоматических пайплайнов

   D)Журнал доступа не ведётся для учёток с широкими правами

   показать ответ и разбор

   +B)Взлом одного сервиса открывает всё сразу

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

7. #dvo_hardening7 / 9
   Какой набор ограничений ставят поду в кластере по умолчанию?

   A)Привилегированный режим с полным набором прав для совместимости

   B)Корневая ФС на чтение, минимум прав и capabilities

   C)Доступ к сети хоста и монтирование его файловой системы

   D)Отключение проб и ограничений ресурсов ради скорости старта

   показать ответ и разбор

   +B)Корневая ФС на чтение, минимум прав и capabilities

   // разбор: Базовый профиль такой: контейнер не root, корневая файловая система только на чтение (данные — во временный том), запрещено повышение привилегий, набор capabilities урезан до необходимого, включён стандартный профиль seccomp. Всё это описывается в securityContext и проверяется на допуске в кластер, чтобы правила не зависели от аккуратности автора манифеста.

8. #dvo_secrets8 / 9
   Пароль от базы не менялся три года. Как провести ротацию без простоя?

   A)Сменить пароль ночью и перезапустить сервисы разом

   B)Раздать новый пароль сервисам заранее и включить его по расписанию

   C)Отключить проверку пароля на время переключения

   D)Завести вторую учётную запись, перевести сервисы, погасить старую

   показать ответ и разбор

   +D)Завести вторую учётную запись, перевести сервисы, погасить старую

   // разбор: Ротация без простоя строится на перекрытии: какое-то время действуют оба набора данных. Для базы это вторая роль с теми же правами: сервисы переезжают на неё выкаткой, а старую отключают, убедившись по журналу подключений, что ею никто не пользуется. Тот же приём для ключей API — два активных ключа с перекрытием — и для сертификатов, где новый корень добавляют в доверенные заранее.

9. #dvo_supply_chain9 / 9
   Сканер показывает критическую уязвимость в системной библиотеке базового образа. Приложение её не использует. Что делать?

   A)Добавить исключение в сканер: раз не используется, риска нет

   B)Заменить базовый образ на другой дистрибутив

   C)Пересобрать на свежем базовом образе и зафиксировать новый дайджест

   D)Удалить библиотеку из образа отдельной инструкцией в конце сборки

   показать ответ и разбор

   +C)Пересобрать на свежем базовом образе и зафиксировать новый дайджест

   // разбор: Обычный путь — обновление: свежий базовый образ приносит исправленный пакет, сборка перезапускается, дайджест пинится заново. «Мы это не вызываем» — слабый аргумент: зависимость может дёрнуть библиотеку неявно, а проверять это на каждом релизе никто не будет. Исключения оформляют осознанно и со сроком, когда обновления ещё нет, а сервис нужен в проде.

Частые вопросы

• Почему контейнер не должен работать от root?

  Без user namespace идентификаторы пользователей общие с хостом, поэтому root в контейнере это root на узле при любом побеге из изоляции. Плюс легче навредить себе через смонтированные тома. Штатный минимум это непривилегированный пользователь и урезанные capabilities.

• Как правильно ротировать пароль без простоя?

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