9 вопросов по теме «DevOps: Облако и безопасность» на собеседовании

Короткий ответ: IAM-пользователь — это статичные ключи, которые живут, пока их не отзовут; роль — временные креденшелы, которые сервис получает через trust policy и которые ротируются автоматически. Воркладу всегда роль: instance profile на VM, IRSA/workload identity в Kubernetes, OIDC-federation из CI.

Подробно:

1. Статичные ключи текут — попадают в git, логи и образы; сами не ротируются; отзыв ручной и обычно уже после инцидента.
2. Роль = временная сессия — STS выдаёт креденшелы на часы, scoped на конкретные права; утёкшая сессия умирает сама.
3. Механизм важно назвать — EC2: instance profile; EKS: IRSA/workload identity; CI: OIDC — пайплайн обменивает свой identity-токен на роль, и в настройках CI нет ни одного секрета.

⚠️ Частая ошибка: «положим ключ в секрет-менеджер». Удобнее — да, но ключ остаётся долгоживущим: проблема не в месте хранения, а в самом существовании статичного ключа.

Короткий ответ: Три слоя подсетей минимум в двух AZ: публичные — только LB и NAT gateway; приватные — приложение; изолированные — база. Из интернета напрямую достижим только LB, egress приложения идёт через NAT, у базы маршрута наружу нет вообще.

Подробно:

            Internet
               │
        ┌──────▼──────┐  public subnets (AZ-a, AZ-b)
        │  ALB │ NAT  │
        └──────┬──────┘
        ┌──────▼──────┐  private subnets: app
        │  app nodes  │──egress──► NAT ─► Internet
        └──────┬──────┘
        ┌──────▼──────┐  isolated subnets: data
        │     DB      │  (маршрута наружу нет)
        └─────────────┘

1. Route tables — публичные подсети смотрят на Internet Gateway; приватные — на NAT (только исходящий трафик); у изолированных выхода наружу нет вовсе.
2. Цепочка секьюрити-групп — db-SG разрешает 5432 только от app-SG, app-SG — только от lb-SG: правила ссылаются на группы, а не на CIDR.
3. ≥2 AZ — LB, приложение и реплика базы в разных зонах, иначе падение одной AZ кладёт всё.

Схема vendor-neutral: в Yandex Cloud те же роли играют NAT-шлюз и группы безопасности.

⚠️ Частая ошибка: сделать app-подсети публичными «чтобы ходить по SSH». Доступ — через bastion или SSM-класс агента, а не публичные IP на приложении.

Короткий ответ: Секьюрити-группа stateful и висит на инстансе/ENI: разрешили входящий трафик — ответный пройдёт сам. NACL stateless и висит на подсети: обратный трафик надо разрешать явно, включая эфемерные порты; зато NACL умеет deny и порядок правил.

Подробно:

На практике ~95% контроля делают секьюрити-группами; NACL добавляют точечно — например, забанить конкретный CIDR на уровне подсети, потому что deny группа не умеет.

⚠️ Частая ошибка: написать в NACL только входящее правило и удивляться таймаутам — ответный трафик уходит с эфемерных портов (1024–65535), и в stateless-списке его нужно явно разрешить в outbound.

Короткий ответ: Центральное хранилище (Vault или облачный secrets manager), в git — только ссылки на секреты, никогда значения. Ключевое следствие: ротация — это контракт с приложением. Секрет, который нельзя ротировать без даунтайма, — отложенный инцидент.

Подробно:

1. Единый источник — секреты живут в одном месте с аудитом доступа: кто, когда и какой секрет читал.
2. Два способа доставки:

3. Ротация — требование к коду — приложение должно уметь перечитать секрет: по TTL, по сигналу или переподключением при ошибке аутентификации. Иначе ротация = даунтайм, и её «на потом» не делают годами.
4. Аудит — доступ к секретам логируется; аномалия в логе — ранний сигнал компрометации.

⚠️ Частая ошибка: секреты «управляются», но ни один ни разу не ротировался. Проверка простая: сможете ли вы сменить пароль базы сегодня без остановки сервиса?

Короткий ответ: Главное — динамические секреты: Vault выпускает короткоживущие креденшелы (например, к базе) под конкретный инстанс сервиса, с lease и автоматическим отзывом. Ментальный сдвиг: секреты перестают распространяться и становятся эфемерными.

Подробно:

1. Динамические секреты — сервис запрашивает доступ к БД, Vault на лету создаёт пользователя с TTL; истёк lease — креденшелы отозваны. Через час утечке нечего красть.
2. Identity-based аутентификация — kubernetes auth method: под подтверждает себя service account'ом, и bootstrap-секрета у приложения нет вообще — решена «проблема нулевого секрета».
3. Центральный аудит — каждый доступ к каждому секрету в логе.
4. Transit — encryption-as-a-service: приложения шифруют данные, не видя ключей.

⚠️ Частая ошибка: внедрить Vault как «зашифрованный key-value» и раздавать из него те же вечные пароли — получается дорогая версия переменных CI, динамика не используется.

Короткий ответ: Сначала триаж, а не паника: смотрим severity, эксплуатируемость и наличие фикса — из 40 CVE реально опасны обычно единицы. Затем пересборка на пропатченном минимальном базовом образе. Системно — сканер как gate в CI и автоматические обновления базового образа.

Подробно:

1. Триаж — Critical/High с доступным фиксом чинить сейчас; уязвимость в библиотеке, которую контейнер даже не загружает, — понизить в приоритете. Все 40 не равны.
2. Пересборка — обновить базовый образ до пропатченного, а лучше сузить поверхность: slim/distroless вместо полного дистрибутива — меньше пакетов, меньше CVE в принципе.
3. Пин по digest — image@sha256:…, а не :latest: сборка воспроизводима, обновление базы — осознанный коммит, а не сюрприз в ночной сборке.
4. Профилактика — сканер (класс Trivy) в CI с политикой порогов: Critical/High с фиксом блокируют сборку, шумные Low идут в отчёт; бот регулярно поднимает базовый образ отдельным PR.

⚠️ Частая ошибка: две крайности — блокировать сборку на любой CVE (команда тонет в шуме и отключает gate) или молча игнорировать все 40. Работает только политика с порогами.

Короткий ответ: Подпись решает задачу provenance в supply chain: криптографическая подпись над digest'ом образа (cosign/sigstore) доказывает, кто его собрал и что он не изменён по пути. Проверка — на admission: policy-контроллер в кластере пускает только подписанные образы.

Подробно:

1. Что подписывается — не тег, а digest: тег :v1.2 можно перезаписать, sha256 — нет. Подпись хранится в том же registry рядом с образом.
2. Где проверяется — admission-контроллер (класс Kyverno/Gatekeeper): под с неподписанным или подписанным чужим ключом образом просто не шедулится. Проверять «при push» бессмысленно — атакующий этот шаг не выполняет.
3. Сканирование ≠ подпись — это защита от разных угроз:

Зрелый уровень — подписывать не только образ, но и attestations: SBOM, результаты сканирования, provenance сборки (SLSA).

⚠️ Частая ошибка: «у нас приватный registry, подпись не нужна». Скомпрометированный CI или учётка с push-правами кладёт вредоносный образ именно в приватный registry — подпись с проверкой на admission ловит и это.

Короткий ответ: base64 — это кодирование, а не шифрование: раскодируется одной командой. По умолчанию секреты лежат в etcd открытым текстом и доступны любому, у кого есть доступ к etcd, широкий RBAC или root на ноде.

Подробно:

1. Кто читает — доступ к etcd (и к его бэкапам!), get secrets через API при щедром RBAC, root на ноде, куда под смонтировал секрет.
2. Минимум — включить encryption-at-rest для etcd (KMS-провайдер) и зажать RBAC: get/list на secrets — только тем, кому реально нужно.
3. Правильный источник — external-secrets-оператор: в git и манифестах — ссылка, значение приезжает из Vault или облачного менеджера, там же аудит и ротация.
4. Не в env — переменные окружения видны в /proc/<pid>/environ, попадают в crash-дампы и логи «на всякий случай»; секрет файлом в томе безопаснее, и его можно обновить без рестарта пода.

⚠️ Частая ошибка: «они же в base64» как аргумент защиты. base64 -d — вот и вся «защита».

Короткий ответ: Шаг ноль — ротация. Креденшел считается скомпрометированным с момента попадания в историю: копия уже могла разойтись по клонам и форкам. Только потом чистка истории и профилактика.

Подробно:

1. ротация ──► 2. аудит ──► 3. чистка истории ──► 4. профилактика
   (сразу)      (логи         (filter-repo;         (secret-scanning
                 доступа)      форки остаются!)       в pre-commit и CI)

1. Ротировать немедленно — отозвать ключ, сменить пароль. Всё остальное может подождать, это — нет.
2. Аудит — где креденшел использовался; по логам доступа (класс CloudTrail) проверить, не было ли с него обращений за окно утечки.
3. Чистить историю — git filter-repo + force push, понимая ограничение: существующие клоны, форки и кэши платформы старую историю сохраняют. Чистка — гигиена, а не защита.
4. Профилактика — секрет-сканер в pre-commit и как CI-gate (класс gitleaks), push protection на уровне платформы.

⚠️ Частая ошибка: начать с «удалим коммит». Пока вы переписываете историю, ключ работает и уже мог быть скопирован — первым действием всегда ротация.