У нас есть пара огромных учетных записей AWS, и мне было поручено реализовать инструкции по мониторингу ресурсов и обеспечить настройку мониторинга для всех существующих и будущих ресурсов.
Есть ли способ предотвратить создание / изменение ресурса, вызвав правила на основе параметров ресурса и / или пользовательских условий? Например, не разрешайте создание экземпляра RDS, если для него не включен расширенный мониторинг, или не разрешайте создание любого экземпляра EC2 без каких-либо определенных сигналов тревоги CloudWatch.
Я просмотрел Политики / Защитные ограждения, но, похоже, он недостаточно надежен. Что используют другие люди в этом сценарии?
РЕДАКТИРОВАТЬ Я рассматривал AWS Config как потенциальное решение, но, похоже, здесь есть много ограничений. Например, у меня есть возможность проводить аудит кластеров RDS, чтобы увидеть, есть ли в них аварийные сигналы, созданные для определенных показателей, но я не могу сделать то же самое для экземпляров RDS.
Предотвращение создания ресурсов с помощью SCP
В некоторых случаях вы можете использовать политики управления службами для этого типа требований, но только в отношении свойств создаваемого ресурса - AFAIK не получится сказать, что «вы не можете создать экземпляр EC2, если сигнал тревоги CloudWatch не сработал. был создан ".
У AWS есть несколько примеров политик управления сервисами на эта страница, Я скопирую один ниже. Я использовал эту технику, чтобы предотвратить создание экземпляра EC2, если он не зашифрован, если том EBS не зашифрован, и предотвратить создание RDS, если хранилище не зашифровано.
Пример SCP от Amazon: с помощью этого SCP запрещается запуск любого экземпляра, не использующего тип экземпляра t2.micro.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RequireMicroInstanceType",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringNotEquals":{
"ec2:InstanceType":"t2.micro"
}
}
}
]
}
Автоматическое исправление
Вы можете рассмотреть возможность автоматического исправления после создания ресурсов. Что-то вроде AWS Config может получать уведомления каждый раз при создании ресурса, запускать скрипт Lambda, который затем можно запускать собственный код для определения состояния и настройки связанных ресурсов. Опять же, это обычай, но мы делали это раньше. Например, когда создается корзина S3, мы включили ведение журнала и управление версиями, если не был указан конкретный тег.
Таким же образом вы можете удалить ресурсы, которые не соответствуют требованиям, вместо автоматического исправления.
Предотвращение создания ресурсов с разрешениями IAM
Вместо удаления ресурсов, которые не соответствуют требованиям, вы можете уменьшить разрешения для пользователей, чтобы они не могли напрямую создавать ресурсы, и внедрить какую-то систему самообслуживания, которая настраивает для них ресурсы со всеми необходимыми связанными ресурсами. вверх. Сам я этого не делал, поэтому не могу точно сказать, как это сделать.
Это может быть так же просто, как разрешить шаблонам CloudFormation, которые вы предоставляете, работать под ролью службы, но не разрешать пользователям напрямую создавать ресурсы.