
Temos algumas contas enormes da AWS e fui encarregado de implementar diretrizes para monitorar recursos e garantir que o monitoramento seja configurado para todos os recursos existentes e futuros.
Existe alguma maneira de impedir a criação/modificação de recursos invocando regras baseadas em opções de recursos e/ou condições personalizadas? Por exemplo, não permita que uma instância do RDS seja criada, a menos que tenha o monitoramento aprimorado habilitado, ou não permita que nenhuma instância do EC2 seja criada sem alguns alarmes específicos do CloudWatch.
Examinei Políticas/Guarda-corpos, mas não parece ser robusto o suficiente. O que outras pessoas estão usando neste cenário?
EDITARTenho observado o AWS Config como uma solução potencial, mas parece haver muitas limitações. Por exemplo, posso auditar clusters RDS para ver se eles possuem alarmes criados para determinadas métricas, mas não posso fazer o mesmo para instâncias RDS.
Responder1
Impedir a criação de recursos com SCP
Em alguns casos, você pode usar Políticas de Controle de Serviço para este tipo de requisito, mas apenas em relação às propriedades do recurso que está sendo criado - AFAIK não funcionará dizer "você não pode criar uma instância do EC2 se um alarme do CloudWatch não tiver foi criado".
A AWS tem alguns exemplos de políticas de controle de serviço emesta página, vou copiar um abaixo. Usei essa técnica para fazer coisas como impedir a criação de instâncias do EC2 se ela não estiver criptografada, se o volume EBS não estiver criptografado e impedir a criação de RDS se o armazenamento não estiver criptografado.
Exemplo de SCP da Amazon: com este SCP, qualquer inicialização de instância que não use o tipo de instância t2.micro será negada.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RequireMicroInstanceType",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringNotEquals":{
"ec2:InstanceType":"t2.micro"
}
}
}
]
}
Correção Automática
Você pode considerar a correção automática após a criação dos recursos. Algo como o AWS Config pode ser notificado sempre que um recurso é criado, executar um script Lambda, que você pode executar um código personalizado para detectar o estado e configurar recursos relacionados. Novamente, isso é personalizado, mas já fizemos isso no passado. Por exemplo, quando um bucket S3 é criado, ativamos o registro em log e o controle de versão, a menos que uma tag específica esteja em vigor.
Da mesma forma, você pode excluir recursos que não estejam em conformidade, em vez de corrigi-los automaticamente.
Impedindo a criação de recursos com permissões IAM
Em vez de remover recursos que não são compatíveis, você pode reduzir as permissões dos usuários para que eles não possam criar recursos diretamente e implementar algum tipo de sistema de autoatendimento que configure recursos para eles, com todos os recursos relacionados necessários definidos acima. Eu não fiz isso sozinho, então não posso dizer exatamente como fazer.
Isso pode ser tão simples quanto permitir que os modelos do CloudFormation fornecidos sejam executados em uma função de serviço, mas não permitir que os usuários tenham permissões para criar os recursos diretamente.