Пять политик инфраструктуры, которые не дадут вашему облаку сжигать деньги и безопасность

Разработчику нужен SSH-доступ к продакшен-серверу для быстрой отладки. Он открывает порт 22 на 0.0.0.0/0, чтобы подключиться с домашнего IP. Отладка завершена, тикет закрыт, а правило группы безопасности остаётся открытым на три месяца. Никто не замечает, пока не приходит счёт за облако с сюрпризом: кто-то поднял инстанс m5.24xlarge в dev-аккаунте, работающий 24/7, без тегов, с именем test123.

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

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

Безопасность: бескомпромиссная база

Политики безопасности — самые критичные, потому что нарушения имеют немедленные и очевидные последствия. Классический пример — блокировка правил групп безопасности, открывающих SSH или порты баз данных на 0.0.0.0/0. Разработчики часто открывают их для временного доступа и забывают закрыть. Политика, отклоняющая такие правила на этапе пайплайна, предотвращает случайное выставление продакшен-ресурсов в интернет.

Другие распространённые политики безопасности:

  • Требование шифрования на диске для S3-бакетов и EBS-томов
  • Блокировка устаревших версий TLS на балансировщиках нагрузки
  • Принудительное использование HTTPS для всех публичных эндпоинтов
  • Обязательное включение VPC Flow Logs для продакшен-сред
  • Использование IAM-ролей вместо долгоживущих ключей доступа

Политики безопасности обычно имеют жёсткий режим отказа: если проверка не пройдена, пайплайн останавливается, и ресурс не создаётся. Режима предупреждения для порта, открытого на весь интернет, быть не может.

Стоимость: предотвращение случайных финансовых потерь

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

Типичные политики стоимости:

  • Блокировка дорогих типов инстансов (например, m5.24xlarge или r5.metal) в непродакшен-средах
  • Ограничение количества EBS-томов или GPU на аккаунт
  • Требование использования Spot-инстансов для отказоустойчивых нагрузок
  • Установка максимальных размеров хранилищ для баз данных
  • Принудительное включение расписаний автоматической остановки для сред разработки

Политики стоимости помогают командам оставаться в рамках бюджета, особенно когда у многих разработчиков есть доступ к облаку. Без них чья-то минутная удобство может обернуться сюрпризом в счете для всей команды.

Теги: метаданные, которые поддерживают работу

Тегирование звучит скучно, пока не нужно выяснить, кто владеет ресурсом, работающим уже шесть месяцев. Теги вроде owner, environment, cost-center и project необходимы для отслеживания затрат, автоматизации очистки и отладки инцидентов.

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

  • Каждый ресурс должен иметь тег owner с валидным email-адресом
  • Каждый ресурс должен иметь тег environment: dev, staging или production
  • Каждый ресурс должен иметь тег cost-center, соответствующий бюджетному коду команды

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

Имена: единообразие для людей и автоматизации

Имена ресурсов важнее, чем думает большинство команд. Бакет с именем test123 и другой с именем data-barang сложно искать, сложно автоматизировать и сложно отлаживать. Политики именования обеспечивают единообразные шаблоны, чтобы команды эксплуатации и инструменты автоматизации могли быстро находить ресурсы.

Распространённые политики именования:

  • Все S3-бакеты должны начинаться с названия проекта
  • Все группы безопасности должны иметь префикс, указывающий на среду
  • Все RDS-инстансы должны следовать шаблону {project}-{env}-{function}
  • Все IAM-роли должны включать имя сервиса и уровень разрешений

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

Соответствие требованиям: перевод внешних правил в код

Политики соответствия обрабатывают требования внешних регуляторов, таких как PCI DSS, HIPAA, SOC 2 или GDPR. Они не опциональны. Они переводят юридические и нормативные требования в автоматические проверки, выполняемые до развёртывания любого ресурса.

Примеры политик соответствия:

  • Все продакшен-базы данных должны использовать шифрование на диске
  • Весь доступ к продакшен-ресурсам должен логироваться в центральном аудиторском следе
  • Все данные должны храниться в одобренных географических регионах
  • Все резервные копии должны быть зашифрованы и храниться в отдельном аккаунте
  • Весь API-доступ должен использовать многофакторную аутентификацию

Политики соответствия часто сложнее всего согласовывать, потому что они исходят извне команды разработки. Но кодирование их как кода делает их последовательными, проверяемыми и гораздо более простыми в обеспечении, чем ручные чек-листы.

Как эти политики взаимодействуют

Эти пять категорий не работают изолированно. Один EC2-инстанс проверяется сразу по нескольким политикам: правила групп безопасности, тип инстанса, теги, шаблон имени и требования соответствия. Хороший пайплайн выполняет все эти проверки до создания ресурса, а не после.

Следующая диаграмма показывает, как пять категорий политик соотносятся друг с другом и с пайплайном развёртывания:

flowchart TD A[Триггер пайплайна] --> B{Безопасность и соответствие} B -->|Пройдено| C{Стоимость} B -->|Не пройдено| D[Отклонить ресурс] C -->|Пройдено| E{Тегирование} C -->|Не пройдено| D E -->|Пройдено| F{Именование} E -->|Не пройдено| G[Предупреждение или отклонение] F -->|Пройдено| H[Создать ресурс] F -->|Не пройдено| G D --> I[Оповестить команду] G --> I

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

Практический чек-лист для начала

Если вы новичок в политиках инфраструктуры, начинайте с малого. Выберите одну категорию и автоматизируйте одну проверку. Вот последовательность, которая работает для большинства команд:

  • Первая неделя: Добавьте политику безопасности, блокирующую публичный SSH-доступ. Жёсткий отказ пайплайна.
  • Вторая неделя: Добавьте политику тегирования, требующую теги owner и environment. Начните с предупреждения, затем через две недели переключитесь на жёсткий отказ.
  • Третья неделя: Добавьте политику стоимости, блокирующую дорогие типы инстансов в dev-аккаунтах. Предупреждение при нарушении, эскалация тимлиду.
  • Четвёртая неделя: Внедрите соглашения об именовании для наиболее распространённых типов ресурсов в вашем аккаунте.
  • Второй месяц: Проанализируйте требования соответствия и закодируйте три главных как автоматические проверки.

Цель — не написать все политики сразу. Цель — набрать инерцию, решив сначала самые болезненные проблемы.

Что важнее всего

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

Начните с политики, которая причиняет больше всего боли сегодня. Для большинства команд это либо группа безопасности, открытая на весь интернет, либо загадочный ресурс, увеличивающий счёт. Автоматизируйте эту проверку, затем переходите к следующей. Со временем ваш пайплайн станет страховочной сеткой, которая ловит ошибки до того, как они превратятся в инциденты.