Skip to content

Шпаргалка по безопасности Infrastructure as Code

Введение

Infrastructure as Code (IaC), также известная как программно-определяемая инфраструктура, позволяет быстро и согласованно настраивать и развёртывать компоненты инфраструктуры, описывая их в виде кода, а также обеспечивает воспроизводимые развёртывания в различных средах.

Лучшие практики безопасности

Ниже приведены некоторые лучшие практики безопасности IaC, которые легко интегрируются в жизненный цикл разработки программного обеспечения:

Разработка и распространение

  • IDE-плагины — используйте стандартные плагины безопасности в интегрированной среде разработки (IDE), которые помогают раннему выявлению потенциальных рисков и значительно сокращают время на устранение проблем на более поздних этапах цикла разработки. Такие плагины, как TFLint, Checkov, Docker Linter, docker-vulnerability-extension, Security Scan, Contrast Security и другие, помогают в оценке безопасности IaC.
  • Моделирование угроз — выстраивайте ландшафт моделирования угроз на ранних этапах цикла разработки, чтобы обеспечить достаточную видимость высокорисковых и высоконагруженных частей кода и гибкость для внедрения безопасности на всех этапах с целью надёжного управления активами.
  • Управление секретами — секреты — это конфиденциальные данные и информация, например токены приложений для аутентификации, пароли и ключи SSH (Secure Shell). Проблема не в самих секретах, а в том, где вы их храните. Если вы используете простой текстовый файл или системы управления версиями, такие как Git, секреты могут быть легко раскрыты. Инструменты с открытым исходным кодом, такие как truffleHog, git-secrets, GitGuardian и аналогичные, могут использоваться для обнаружения небезопасного управления секретами. Подробнее см. Шпаргалку по управлению секретами.
  • Контроль версий — контроль версий — это практика отслеживания и управления изменениями в программном коде. Убедитесь, что все изменения в IaC фиксируются с необходимой информацией для возможности отката. Важно фиксировать эти изменения вместе с поддерживаемыми функциями, а не отдельно от них. Требования к инфраструктуре для той или иной функции должны быть частью ветки или запроса на слияние этой функции. Git, как правило, используется в качестве системы контроля версий исходного кода.

  • Принцип наименьших привилегий — определяйте политики управления доступом на основе принципа наименьших привилегий, уделяя особое внимание следующим аспектам:

    • Определение того, кто уполномочен и кто не уполномочен создавать, обновлять, запускать и удалять скрипты и инвентаризацию.
    • Ограничение разрешений авторизованных пользователей IaC тем минимумом, который необходим для выполнения их задач. Скрипты IaC должны обеспечивать, чтобы разрешения, предоставляемые создаваемым ресурсам, были ограничены лишь тем, что требуется для выполнения их работы.

  • Статический анализ — анализирует код в изоляции, выявляя риски, неправильные конфигурации и нарушения соответствия требованиям, относящиеся только к самому IaC. Такие инструменты, как kubescan, Snyk, Coverity и другие, могут использоваться для статического анализа IaC.

  • Проверка зависимостей с открытым исходным кодом — анализирует зависимости с открытым исходным кодом, такие как пакеты ОС, библиотеки и т. д., для выявления потенциальных рисков. Такие инструменты, как BlackDuck, Snyk, WhiteSource Bolt for GitHub и аналогичные, могут использоваться для анализа зависимостей с открытым исходным кодом в IaC.
  • Сканирование образов контейнеров — сканирование образов подразумевает анализ содержимого и процесса сборки образа контейнера с целью обнаружения проблем безопасности, уязвимостей или потенциальных рисков. Инструменты с открытым исходным кодом, такие как Dagda, Clair, Trivy, Anchore и другие, могут использоваться для анализа образов контейнеров. CI/CD-конвейер и консолидированная отчётность — включение проверок безопасности в CI/CD-конвейер позволяет анализировать каждое изменение кода, исключает необходимость ручного вмешательства и обеспечивает ведение истории соответствия требованиям. Наряду с консолидированной отчётностью, эти интеграции ускоряют разработку безопасной кодовой базы IaC. Инструменты с открытым исходным кодом, такие как Jenkins, могут использоваться для построения CI/CD-конвейеров, а DefectDojo и OWASP Glue могут помочь в объединении проверок и визуализации их результатов на единой панели мониторинга.
  • Подписывание артефактов — цифровое подписывание артефактов во время сборки и проверка подписанных данных перед использованием защищают артефакты от подмены между сборкой и временем выполнения, тем самым обеспечивая целостность и происхождение артефакта. Инструменты с открытым исходным кодом, такие как TUF, помогают в цифровом подписывании артефактов.

Развёртывание

  • Управление инвентаризацией:
    • Ввод в эксплуатацию — при каждом развёртывании ресурса убедитесь, что ресурс помечен тегами, отслеживается и регистрируется в рамках управления инвентаризацией.
    • Вывод из эксплуатации — при инициировании удаления ресурса убедитесь, что базовые конфигурации очищены, данные надёжно удалены, а ресурс полностью удалён как из среды выполнения, так и из системы управления инвентаризацией.
    • Тегирование — крайне важно правильно помечать облачные активы тегами. В ходе операций IaC непомеченные активы, скорее всего, превратятся в «призрачные ресурсы», что затрудняет обнаружение, визуализацию и получение наблюдаемости в облачной среде и может привести к дрейфу состояния. Такие «призрачные ресурсы» могут увеличивать затраты на оплату, усложнять обслуживание и снижать надёжность. Единственное решение — тщательное тегирование и мониторинг непомеченных ресурсов.
  • Динамический анализ — динамический анализ помогает оценить существующие среды и сервисы, с которыми система будет взаимодействовать или на которых будет работать. Это помогает выявить потенциальные риски, обусловленные совместимостью. Инструменты с открытым исходным кодом, такие как ZAP, Burp, GVM и другие, могут использоваться для динамического анализа.

Среда выполнения

  • Неизменяемость инфраструктуры — идея неизменяемой инфраструктуры заключается в том, чтобы строить компоненты инфраструктуры в точном соответствии с заданными спецификациями. Никаких отклонений, никаких изменений. Если требуется изменить спецификацию, весь набор инфраструктуры создаётся заново на основе обновлённых требований, а предыдущая инфраструктура выводится из эксплуатации как устаревшая.
  • Журналирование — ведение записей является критически важным аспектом контроля рисков. Следует включить журналирование — как журналы безопасности, так и журналы аудита — при подготовке инфраструктуры, поскольку они помогают оценивать риски безопасности, связанные с чувствительными активами. Они также помогают анализировать первопричины инцидентов и выявлять потенциальные угрозы. Инструменты с открытым исходным кодом, такие как ELK и другие, могут использоваться для анализа журналов.
  • Мониторинг — непрерывный мониторинг помогает выявлять нарушения безопасности и соответствия требованиям, обнаруживать атаки и предоставлять оповещения о таких инцидентах. Некоторые решения также используют новые технологии, такие как AI, для раннего выявления потенциальных угроз. Инструменты с открытым исходным кодом, такие как Prometheus, Grafana и другие, могут использоваться для мониторинга облачной инфраструктуры.
  • Обнаружение угроз во время выполнения — внедрение решения для обнаружения угроз во время выполнения помогает распознавать неожиданное поведение приложений и оповещать об угрозах во время выполнения. Инструменты с открытым исходным кодом, такие как Falco и другие, могут использоваться для обнаружения угроз во время выполнения. Некоторые приложения, например Contrast (Contrast Community Edition), также могут обнаруживать атаки из списка OWASP Top 10 на приложение во время выполнения и помогать блокировать их для защиты приложения.

Ссылки