Какие типичные (банальные) уязвимости инфраструктуры вы знаете?

«Какие типичные (банальные) уязвимости инфраструктуры вы знаете?» — вопрос из категории Безопасность, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

В процессе аудита инфраструктуры я часто сталкиваюсь с повторяющимися, но критичными уязвимостями:

  1. Незакрытые публичные порты: Самая распространенная проблема — оставленные открытыми порты SSH (22), RDP (3389) или баз данных (3306, 5432) для всего интернета (0.0.0.0/0). Это прямой путь для брутфорса. Я всегда настраиваю Security Groups/VPC Firewall Rules, разрешая доступ только с доверенных IP-адресов.

  2. Слабые или учетные данные по умолчанию: Использование паролей вроде admin:admin или оставление дефолтных ключей доступа в облачных сервисах. Я внедряю политику сложных паролей и, где возможно, полностью отключаю парольную аутентификацию в пользу ключей SSH или IAM-ролей.

  3. Устаревшее и непропатченное ПО: Запуск серверов с уязвимыми версиями ОС, веб-серверов (Apache, Nginx) или сред выполнения (Java, PHP). В моем пайплайне есть этап автоматического сканирования уязвимостей (например, с Trivy) и регулярного обновления через менеджеры пакетов.

  4. Секреты в коде и системах контроля версий: Случайный коммит файла .env или hardcoded credentials в Dockerfile.

    # ПЛОХО: Секрет в слое образа
    ENV DB_PASSWORD="SuperSecret123"

    Я использую секреты как переменные окружения, передаваемые во время рантайма, или внешние хранилища вроде HashiCorp Vault.

  5. Избыточные привилегии: Запуск контейнеров и демонов от имени root, назначение ролей AdministratorAccess в AWS сервисам, которым это не требуется. Я применяю принцип наименьших привилегий: запускаю контейнеры от непривилегированного пользователя, а в облаке создаю кастомные IAM-политики с минимальным набором разрешений.

  6. Незашифрованные данные: Трафик между сервисами по HTTP или хранение чувствительных данных в S3-бакетах без шифрования. Я принудительно применяю HTTPS через TLS-сертификаты (например, от Let's Encrypt) и включаю шифрование на стороне сервера (SSE) для облачных хранилищ.

  7. Отсутствие мониторинга и логирования: Если не настроены алерты на подозрительную активность (множественные failed logins) и не ведутся логи доступа, атака может долго оставаться незамеченной. Я настраиваю централизованное логирование (ELK Stack, Loki) и алерты в Prometheus/Grafana или CloudWatch.