Семь ошибок безопасности (инфраструктура как код)

13 февраля 2021, 23:59

Проблема №1: Ярлыки безопасности

Проблема номер один — это неспособность обеспечить надлежащую безопасность, потому что для этого требуется много времени и знаний. Например, инженеры DevOps могут не требовать сертификатов на основе протокола SSL/TLS для всех микросервисов или не применять соответствующие роли управления идентификацией и доступом (IAM) к облачным ресурсам. Такие упущения могут сделать организации уязвимыми для злоумышленников, которые смогут сделать практически все, как только получат доступ к системе.

Соблюдение требований как кодекс может помочь решить эту проблему. Эта категория программного обеспечения применяет подход "инфраструктура как код" для автоматизации внедрения, проверки и мониторинга состояния соответствия требованиям, связанным с безопасностью, защитой данных и различными бюджетными ограничениями. Различные инструменты сканирования безопасности и тестирования на проникновение могут быть вставлены в конвейер DevOps, так что сканирование среды на предмет безопасности становится частью регулярного процесса развертывания при вводе версий в производство.

Проблема № 2: Не реализована сквозная автоматизация

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

Вспомните о тех случаях, когда система авиакомпании выходит из строя из-за неудачного обновления системы, что мешает путешественникам забронировать билет. Чаще всего такие сбои вызваны каким-то неправильно выполненным ручным процессом обновления, на устранение которого у технической команды уходит до 24 часов. Это хорошие примеры того, как неспособность внедрить сквозную автоматизацию может привести к недовольству клиентов и потере доходов.

Проблема № 3: Недостаточное автоматизированное тестирование

Разработчики признают ценность автоматизированного тестирования для своих приложений, но многие инженеры DevOps забывают применять подобное тестирование к своей инфраструктуре в качестве кода. Однако, как и приложения, инфраструктура по мере развития кода продолжает развиваться, и эти изменения могут привести к ошибкам, которые нарушают код. По этой причине крайне важно применять автоматизированное тестирование как к приложениям, так и к инфраструктуре как к коду, чтобы гарантировать правильную работу конфигураций инфраструктуры.

Проблема № 4: Игнорирование лучших практик оптимизации затрат

Мы видели реальные примеры, когда развертывание может стоить либо 1000, либо 100 000 долларов в месяц, в зависимости от того, как управляется облачная инфраструктура. Оптимизация может принимать форму правильного определения размера ресурсов, использования преимуществ спотовых экземпляров, идентификации незанятых ресурсов или работы на нескольких облачных платформах.

Тем не менее, в спешке, чтобы получить проект с нуля, некоторые инженеры DevOps забывают реализовать оптимизацию затрат в своей инфраструктуре как к коду. Конечно, потребуется больше времени для внедрения лучших практик оптимизации затрат, но ежемесячная экономия затрат на облачные технологии обеспечит быструю окупаемость этих инвестиций.

Проблема № 5: Создание облачного мусора

Очень легко создать новую инфраструктуру, но не так легко ее удалить. Это часто оставляет организации с бесхозными ресурсами в облаке, которые больше не нужны. И предприятия платят облачным провайдерам за этот “облачный мусор”, который все еще работает неиспользуемым на их платформах. По этой причине инженеры DevOps должны убедиться, что они автоматически не развертывают неиспользуемые ресурсы как часть своего кода инфраструктуры.

Проблема №6: Жесткое кодирование значений параметров

Жесткое кодирование-это практика встраивания специфичных для среды свойств или значений параметров непосредственно в исходный код для автоматизации DevOps. Пример такого анти-паттерна — это когда учетные данные администратора жестко закодированы в сценарии инфраструктуры как кода, что позволяет злоумышленникам использовать эти учетные данные и взломать инфраструктуру развертывания. Жестко закодированные значения также приводят к ошибкам, зависящим от конкретной среды, что затрудняет повторяемость и автоматизацию развертывания.

Проблема № 7: Монолитные скрипты

Иногда инженеры DevOps объединяют множество задач в один большой монолитный сценарий автоматизации. Если им нужен похожий сценарий, они скопируют и вставят исходный сценарий и перепишут несколько параметров. Такой подход приводит к инфраструктуре как коду, который становится слишком сложным для поддержания и расширения. Лучший подход-разбить код инфраструктуры на отдельные модули или стеки, а затем объединить их в автоматическом режиме во время развертывания. Есть несколько преимуществ для этого подхода. Во-первых, инженеры DevOps имеют больший контроль над тем, кто имеет доступ к различным частям их инфраструктурного кода. Во-вторых, это позволяет командам повторно использовать работу в будущих проектах. В-третьих, это помогает командам DevOps поддерживать и тестировать модули.