📁 Безопасность и DevSecOps

Короткий ответ Git хранит полную историю, поэтому секрет, попавший в коммит, остаётся доступным даже после удаления файла; секреты нужно передавать через переменные окружения, менеджер секретов или volume, а не хардкодить в исходный код. Как это работает подробнее Git — система с полной историей изменений; удаление строки в новом коммите не удаляет её из истории, секрет можно найти через git log/git blame или просто скачав архив репозитория. Любой, у кого есть доступ к репозиторию (включая форки, CI-логи, бэкапы), получает секрет. Пример кода Что использовать на практике Практика. секреты передают через переменные окружения, монтируемые файлы/volume или через специализированные системы (Vault, AWS Secrets Manager, Kubernetes Secret), которые разделяют доступ к конфигурации и доступ к значению секрета. Для публичных и приватных репозиториев одинаково важно включить сканирование на секреты (gitleaks, git-secrets) в CI. Проверка. Ожидаемое поведение: даже после удаления .env новым коммитом и git rm .env, старый

Читать полностьюcredential-rotation

Короткий ответ Аутентификация — это подтверждение личности субъекта («кто вы»), а авторизация — это проверка, какие действия этому субъекту разрешены («что вам можно делать»); система может правильно аутентифицировать пользователя и при этом справедливо отказать ему в конкретном действии из-за авторизации. Как это работает подробнее при обращении к системе сначала проверяется, что субъект действительно тот, за кого себя выдаёт (пароль, токен, сертификат, MFA) — это аутентификация. После этого отдельный механизм (RBAC, ACL, IAM policy) проверяет, разрешено ли аутентифицированному субъекту конкретное действие над конкретным ресурсом — это авторизация. Пример кода Что использовать на практике Практика. в Kubernetes аутентификация происходит через токен service account или сертификат клиента, а авторизация — через RBAC (Role/RoleBinding); в облаке аутентификация — вход через IAM-учётные данные, авторизация — IAM policy, прикреплённая к пользователю или роли. Ошибка 401 означает проблему аутентификации, 403 — авто

Читать полностьюaccess-control

Короткий ответ Kubernetes Secret хранит конфиденциальные данные отдельно от ConfigMap и ограничивает доступ через RBAC, но по умолчанию значение закодировано только в base64 — это кодирование для удобства передачи, а не шифрование, и без дополнительных мер (encryption at rest) секрет читается в открытом виде. Как это работает подробнее ConfigMap и Secret имеют одинаковую структуру (пары ключ-значение), но Secret предполагает более строгие ограничения доступа через RBAC и не выводится полностью в некоторых командах kubectl describe. Однако сами данные в etcd по умолчанию хранятся в base64, что легко декодируется (base64 -d) любым, кто получил доступ к объекту или к etcd. Пример кода Что использовать на практике Практика. для реальной защиты включают encryption at rest для etcd (EncryptionConfiguration), ограничивают RBAC на чтение Secret, используют внешние системы управления секретами (Vault, External Secrets Operator) для хранения и инжекта значений, а не хранят чувствительные данные напрямую в манифестах. П

Читать полностьюconfigmap

Короткий ответ Принцип наименьших привилегий — предоставление субъекту (пользователю, сервису, процессу) минимального набора прав, необходимого для выполнения его задач, и не больше. Как это работает подробнее вместо выдачи широких ролей (admin, root, *:*) права формируются по конкретным действиям и ресурсам, которые действительно нужны. Это ограничивает «блаcт-радиус» при компрометации аккаунта или сервиса — злоумышленник получит доступ только к тому, что разрешено скомпрометированному субъекту. Пример кода Что использовать на практике Практика. при создании IAM-роли или сервис-аккаунта начинают с пустого набора прав и добавляют только используемые действия (например, доступ на чтение к одному S3-бакету, а не ко всем ресурсам аккаунта). Регулярно пересматривают права (access review), особенно после смены задач сотрудника или сервиса. Проверка. Ожидаемое поведение: сервис с такой политикой сможет читать объекты только из example-reports-bucket и получит AccessDenied при попытке обратиться к любому другому бак

Читать полностьюaccess-control

Короткий ответ SBOM — это машиночитаемый «список состава» артефакта (всех включённых библиотек и их версий); при обнаружении новой уязвимости в конкретной библиотеке SBOM позволяет быстро найти все артефакты и сервисы, где она используется, без повторного ручного анализа каждого проекта. Как это работает подробнее при сборке образа или пакета SBOM-генератор (Syft, cdxgen) анализирует все установленные зависимости и их точные версии и сохраняет результат в стандартном формате (SPDX, CycloneDX) рядом с артефактом или в отдельном реестре. Это снимок состава на момент сборки, независимый от последующего сканирования уязвимостей. Пример кода Что использовать на практике Практика. SBOM хранят централизованно для всех выпущенных артефактов и прогоняют через него поиск при появлении новой громкой уязвимости (как в случае с Log4Shell) — вместо того, чтобы вручную проверять каждый сервис, делают запрос по всем SBOM на наличие конкретной библиотеки и версии. SBOM также требуют некоторые заказчики/регуляторы как часть до

Читать полностьюci-cd

Короткий ответ Нужно внедрить admission-контроллер политик (OPA Gatekeeper или Kyverno), который проверяет каждый создаваемый/изменяемый объект на соответствие заданным правилам и блокирует или помечает нарушающие ресурсы прямо в момент применения, а не ждать периодического аудита постфактум. Как это работает подробнее admission-контроллер подключается к API-серверу как webhook и получает запрос на создание/изменение ресурса до его сохранения в etcd; политика (написанная на Rego для OPA Gatekeeper или YAML-декларативно для Kyverno) проверяет объект по заданным правилам и возвращает allow/deny. Это превращает требования безопасности из документации в технически применяемый контроль. Пример кода Что использовать на практике Практика. политики сначала вводят в режиме «audit»/dry-run (только логируют нарушения без блокировки), собирают статистику, чтобы не сломать существующие легитимные случаи, обсуждают с командами исключения, и только затем переводят в режим «enforce» (блокировка). Нужные исключения оформляют

Читать полностьюadmission-control

Короткий ответ Административные права дают возможность изменять и удалять любые ресурсы, что при ошибке или компрометации аккаунта приводит к максимально возможному ущербу; роль read-only ограничивает субъекта просмотром данных без возможности их изменить, резко снижая потенциальный ущерб даже при компрометации. Как это работает подробнее уровень прав определяет «блаcт-радиус» — что именно может сделать скомпрометированный или ошибочно действующий субъект. Административная роль обычно включает действия create/update/delete над широким набором ресурсов, тогда как read-only ограничивается get/list/describe и не позволяет вносить изменения. Пример кода Что использовать на практике Практика. для большинства задач мониторинга, дежурств первой линии, аналитики достаточно read-only доступа; административные права выдают точечно и временно (например, через запрос доступа с ограничением по времени — just-in-time access) только тем, кому они действительно нужны для конкретной задачи. Проверка. Ожидаемое поведение: поль

Читать полностьюaccess-control

Короткий ответ Сначала немедленно ротируют (меняют) скомпрометированный пароль в самой базе данных и во всех местах, где он использовался, затем оценивают, кто мог получить доступ к репозиторию за период утечки, и только после этого очищают историю Git — порядок важен, потому что очистка истории без ротации не устраняет реальную угрозу. Как это работает подробнее удаление файла новым коммитом не удаляет секрет из истории Git — он остаётся доступен через старые коммиты, форки, локальные клоны у разработчиков и кэши CI. Поэтому единственная гарантированная защита — сделать утёкший пароль бесполезным, сменив его в системе, где он применяется. Пример кода Что использовать на практике Практика. порядок действий — 1) сменить пароль/ключ в БД или сервисе; 2) обновить secret-хранилище и перезапустить сервисы, использующие его; 3) проверить логи доступа к БД за период утечки на подозрительную активность; 4) очистить историю репозитория (git filter-repo/BFG) и уведомить всех с локальными клонами о необходимости их пере

Читать полностьюcredential-rotation

Короткий ответ По умолчанию в Kubernetes сетевой трафик между Pod'ами не ограничен, если не применены NetworkPolicy и CNI-плагин, который их поддерживает; нужно проверить, поддерживает ли используемый CNI NetworkPolicy, и явно создать политику, разрешающую входящий трафик к Pod'ам БД только от Pod'ов приложения. Как это работает подробнее NetworkPolicy — это «allow-list» поверх сети, которая без политик полностью открыта (flat network) для трафика между всеми Pod'ами кластера. Если ни одна NetworkPolicy не выбирает Pod, трафик к нему не ограничен независимо от namespace. Важно: сами объекты NetworkPolicy ничего не делают, если установленный CNI-плагин (например, Flannel в базовой конфигурации) не реализует их применение — нужен CNI с поддержкой (Calico, Cilium, большинство managed-решений облаков). Пример кода Что использовать на практике Практика. сначала проверяют, что CNI поддерживает NetworkPolicy (тестовой политикой deny-all и проверкой, действительно ли трафик блокируется), затем вводят политику «defaul

Читать полностьюkubernetes