0Pricing
Security+ Academy · Урок

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

Сканируйте Terraform, CloudFormation и диаграммы Helm с помощью средств безопасности IaC (Checkov, tfsec), чтобы выявлять неправильные настройки до их попадания в рабочую среду.

«Сканирование безопасности инфраструктуры как кода» — бесплатный урок Security+ Academy на CoddyKit. Это урок 4 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Security+ Academy, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Security+ Academy содержит 4 уроков всего.

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

Инструменты Infrastructure as Code (IaC), такие как Terraform, AWS CloudFormation, Ansible и Helm, позволяют описывать инфраструктуру в конфигурационных файлах, управляемых системой контроля версий. Это дает огромные преимущества — воспроизводимость, возможность аудита и автоматизацию, — но создает и критический риск для безопасности: неправильные конфигурации в файлах IaC массово создают небезопасную инфраструктуру. Один неправильно настроенный модуль Terraform, развернутый в 50 средах, одновременно создает 50 уязвимых систем. Сканирование безопасности IaC решает эту проблему, проверяя конфигурационные файлы до их применения и перенося контроль безопасности на более ранний этап рабочего процесса разработчика.

Распространенные неправильные конфигурации IaC

Средства сканирования безопасности ищут наиболее распространенные неправильные конфигурации IaC, обнаруживаемые в реальных облачных средах: хранилища S3 с включенным публичным доступом или без шифрования при хранении; группы безопасности с входящими правилами 0.0.0.0/0 для чувствительных портов (22, 3389, 1433); базы данных без шифрования или с публичным доступом; политики IAM с подстановочными знаками * для ресурсов или действий; отключенный CloudTrail в регионе; ключи KMS без ротации; и балансировщики нагрузки с прослушивателями HTTP вместо HTTPS. Эти результаты во многом соответствуют проверкам облачных эталонов безопасности, например CIS AWS Foundations.

# Dangerous Terraform: public S3 bucket + no encryption
resource 'aws_s3_bucket' 'data' {
  bucket = 'my-data-bucket'
  # Missing: server_side_encryption_configuration
  # Missing: aws_s3_bucket_public_access_block
}

Checkov: политики как код для инфраструктуры как кода

Checkov (от Bridgecrew/Prisma Cloud) — популярный инструмент статического анализа с открытым исходным кодом для инфраструктуры как кода, поддерживающий Terraform, CloudFormation, манифесты Kubernetes, диаграммы Helm и Dockerfiles. В него входит более 1 000 встроенных политик, сопоставленных с эталонами CIS, GDPR, SOC 2 и HIPAA. Запуск checkov -d . сканирует все файлы инфраструктуры как кода в текущем каталоге и формирует цветной отчёт о пройденных, непройденных и пропущенных проверках с путями к ресурсам и рекомендациями по устранению проблем. Checkov можно интегрировать в конвейеры CI/CD, чтобы блокировать развёртывания, если критические проверки не пройдены.

# Install and run Checkov on Terraform files
pip install checkov
checkov -d ./terraform/ --framework terraform

# Fail CI pipeline on HIGH severity findings
checkov -d ./terraform/ --check HIGH --hard-fail-on HIGH

tfsec: сканер безопасности Terraform

tfsec (теперь входит в возможности Trivy по сканированию инфраструктуры как кода) — специализированный сканер безопасности Terraform, глубоко анализирующий синтаксис HCL, благодаря чему он может отслеживать значения в модулях и файлах переменных. В отличие от более простых сканеров, tfsec способен обнаруживать неправильные настройки, когда проблема охватывает несколько файлов, — например, правило группы безопасности, которое выглядит безопасным само по себе, но применяется к ресурсу, определённому в другом файле. tfsec формирует результаты с уровнями серьёзности (CRITICAL, HIGH, MEDIUM, LOW), идентификаторами CWE и прямыми ссылками на документацию по устранению проблем, что позволяет разработчикам сразу принимать меры.

# Install tfsec and scan Terraform directory
brew install tfsec
tfsec ./terraform/ --format json

# Or use Trivy for unified IaC + container scanning
trivy config ./terraform/

Секреты в файлах инфраструктуры как кода

Одна из наиболее критичных проблем безопасности инфраструктуры как кода — секреты, жёстко заданные в конфигурационных файлах: пароли, ключи API, закрытые ключи TLS и строки подключения к базам данных, зафиксированные в Git. Поскольку репозитории инфраструктуры как кода часто используются несколькими командами и хранятся вместе с историей системы управления версиями, секрет, зафиксированный хотя бы один раз, фактически оказывается навсегда скомпрометированным (история Git неизменяема). Такие инструменты, как Checkov, detect-secrets, git-secrets и TruffleHog, сканируют данные в поисках шаблонов секретов. Решение заключается в использовании входных переменных, значения которых берутся из переменных окружения или хранилищ секретов, а не задаются жёстко.

# Bad: hardcoded password in Terraform
resource 'aws_db_instance' 'main' {
  password = 'supersecret123'  # NEVER DO THIS
}

# Good: read from variable, inject from secrets manager
variable 'db_password' { sensitive = true }
resource 'aws_db_instance' 'main' {
  password = var.db_password
}

Политики как код: OPA и Sentinel

Средства политик как кода (PaC) позволяют командам безопасности создавать пользовательские правила в виде кода и применять их единообразно. Open Policy Agent (OPA) вместе с Conftest позволяет писать политики Rego для проверки любых структурированных данных — планов Terraform, манифестов Kubernetes и значений Helm — в конвейерах CI/CD. HashiCorp Sentinel встроен в Terraform Enterprise и Cloud и позволяет, например, задать правило «для всех корзин S3 должно быть включено шифрование», применяемое на этапе планирования и блокирующее любое применение изменений, нарушающее это правило. Эти инструменты позволяют формализовать требования безопасности в виде кода и хранить их версии вместе с управляемой ими инфраструктурой.

# Example Conftest OPA policy: deny public S3
# deny[msg] {
#   input.resource.aws_s3_bucket[name]
#   input.resource.aws_s3_bucket_public_access_block == null
#   msg := sprintf('Bucket %v lacks public access block', [name])
# }

Обнаружение отклонений: конфигурация и реальное состояние

Отклонение конфигурации возникает, когда фактическое состояние развёрнутой инфраструктуры расходится с её определением в инфраструктуре как коде, часто потому, что кто-то внёс изменение вручную через облачную консоль. Правило группы безопасности, добавленное вручную, чтобы «временно» разблокировать доступ разработчику, превращается в постоянную уязвимость. Инструменты обнаружения отклонений непрерывно сравнивают желаемое состояние (файлы инфраструктуры как кода) с фактическим развёрнутым состоянием и сообщают о расхождениях. AWS Config, обнаружение отклонений в Terraform Cloud и инструменты CSPM (Prisma Cloud, Wiz) предоставляют такую возможность. Неправильные настройки безопасности, внесённые через консоль, обнаруживаются до того, как их найдут злоумышленники.

# Terraform: detect drift between state and actual cloud resources
terraform plan -refresh-only
# If output shows changes, someone modified infrastructure outside Terraform

Неизменяемая инфраструктура и GitOps

Неизменяемая инфраструктура означает, что серверы и конфигурации никогда не изменяются на месте: вместо этого изменения создают новые ресурсы (новые AMI, новые образы контейнеров) и заменяют старые. В сочетании с GitOps (при котором все изменения инфраструктуры должны проходить через запрос на включение изменений в Git, запускающий процессы сканирования инфраструктуры как кода и согласования) это устраняет отклонения конфигурации по самой своей архитектуре: если что-то нельзя изменить вручную, оно не может отклониться от заданного состояния. Такие инструменты, как ArgoCD для Kubernetes и Atlantis для Terraform, реализуют процессы GitOps, в которых любое отклонение вызывает автоматическое приведение состояния к заданному или оповещение.

Различие между SAST и сканированием инфраструктуры как кода

Сканирование безопасности инфраструктуры как кода иногда путают с SAST (статическим тестированием безопасности приложений), однако эти средства анализируют разные артефакты. SAST анализирует исходный код приложений (Python, Java, JavaScript) на наличие уязвимостей, таких как внедрение SQL или переполнение буфера. Сканирование инфраструктуры как кода анализирует конфигурационные файлы инфраструктуры на наличие неправильных настроек безопасности облака — исходный код приложения при этом не затрагивается. Полный конвейер DevSecOps включает оба вида проверок: SAST для кода приложений и сканирование инфраструктуры как кода для файлов инфраструктуры. Оба запускаются в CI/CD до любого развёртывания. Некоторые унифицированные платформы (Snyk IaC, Prisma Cloud) объединяют сканирование приложений и инфраструктуры в одном инструменте.

Интеграция сканирования инфраструктуры как кода в CI/CD

Эффективное сканирование безопасности инфраструктуры как кода должно быть автоматизировано и обязательно, а не выполняться по желанию. Типичная интеграция с CI/CD выглядит так: при каждом запросе на включение изменений запускаются Checkov и tfsec; конвейер завершается ошибкой, если обнаружены результаты уровня CRITICAL; результаты публикуются в виде комментариев к запросу на включение изменений, чтобы разработчики их видели; ведётся список подавленных результатов с документированными обоснованиями; каждую ночь выполняется сканирование развёрнутых ресурсов на наличие отклонений. Перехватчики перед фиксацией, использующие такие инструменты, как pre-commit вместе с Checkov, могут обнаружить проблемы ещё до того, как код попадёт в конвейер. Важно управлять ложными срабатываниями: разработчики, которые видят слишком много нерелевантных результатов, начинают их игнорировать.

# GitHub Actions: IaC security scanning
# - name: Run Checkov IaC Scan
#   uses: bridgecrewio/checkov-action@master
#   with:
#     directory: terraform/
#     framework: terraform
#     soft_fail: false  # fail PR on findings
#     output_format: sarif  # upload to GitHub Security tab

Безопасность состояния Terraform

Файл состояния Terraform (terraform.tfstate) содержит полный перечень всех управляемых ресурсов, часто включая конфиденциальные выходные значения, например пароли баз данных, закрытые ключи TLS и идентификаторы ключей доступа IAM в открытом виде. Файлы состояния никогда нельзя фиксировать в Git. Вместо этого используйте удалённый сервер хранения (AWS S3 с блокировкой через DynamoDB, Terraform Cloud или состояние под управлением GitLab) с включённым шифрованием на стороне сервера. Доступ к серверу хранения состояния необходимо строго контролировать через IAM: любой, кто может прочитать файл состояния, способен перечислить все сведения об инфраструктуре и потенциально извлечь встроенные секреты.

# Secure Terraform remote backend
terraform {
  backend 's3' {
    bucket         = 'my-terraform-state'
    key            = 'prod/terraform.tfstate'
    region         = 'us-east-1'
    encrypt        = true
    kms_key_id     = 'arn:aws:kms:us-east-1:123:key/abc'
    dynamodb_table = 'terraform-state-lock'
  }
}

Быстрая проверка

Проверьте своё понимание концепций CompTIA Security+ (SY0-701), рассмотренных в этом уроке.

Итоги урока

В этом уроке Вы узнали, что неправильные настройки инфраструктуры как кода, такие как общедоступные корзины S3, открытые группы безопасности и секреты, заданные жёстко, автоматически обнаруживаются такими инструментами, как Checkov и tfsec, до развёртывания; средства политик как кода (OPA/Conftest, HashiCorp Sentinel) позволяют применять пользовательские организационные требования безопасности в виде автоматических блокирующих этапов конвейера; а файлы состояния Terraform необходимо хранить в зашифрованных удалённых хранилищах со строгим контролем доступа, поскольку они могут содержать конфиденциальные сведения о ресурсах. Далее мы рассмотрим жизненный цикл APT и способы, которыми передовые угрозы сохраняются внутри сетей.

Часто задаваемые вопросы

Урок «Сканирование безопасности инфраструктуры как кода» бесплатный?

Да — полный текст урока «Сканирование безопасности инфраструктуры как кода» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Security+ Academy, подпишись на CoddyKit PRO. Курс Security+ Academy содержит 4 уроков всего.

Чему я научусь в уроке «Сканирование безопасности инфраструктуры как кода»?

Сканируйте Terraform, CloudFormation и диаграммы Helm с помощью средств безопасности IaC (Checkov, tfsec), чтобы выявлять неправильные настройки до их попадания в рабочую среду. Ты практикуешь Security+ Academy с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать Security+ Academy?

Предыдущий опыт не требуется. Security+ Academy на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 4 из 4.

Сколько времени занимает урок «Сканирование безопасности инфраструктуры как кода»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке Security+ Academy?

Да. Каждый урок Security+ Academy включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

  1. Безопасность контейнеров: усиление образов и защита во время выполнения
  2. Безопасность Kubernetes: RBAC, сетевые политики и безопасность подов
  3. Безсерверные системы и безопасность функций
  4. Сканирование безопасности инфраструктуры как кода
← Назад к Security+ Academy