☰

Imponer la supervisión de los recursos de AWS

tag-icon • tag-icon amazon-web-services security monitoring infrastructure
Imponer la supervisión de los recursos de AWS

Tenemos un par de cuentas enormes de AWS y se me ha asignado la tarea de implementar pautas para monitorear los recursos y garantizar que el monitoreo esté configurado para todos los recursos existentes y futuros.

¿Hay alguna forma de evitar la creación/modificación de recursos invocando reglas basadas en opciones de recursos y/o condiciones personalizadas? Por ejemplo, no permita que se cree una instancia RDS a menos que tenga habilitada la supervisión mejorada, o no permita que se cree ninguna instancia EC2 sin algunas alarmas específicas de CloudWatch.

He investigado Políticas/Guardrails pero no parece ser lo suficientemente sólido. ¿Qué están usando otras personas en este escenario?

EDITARHe estado considerando AWS Config como una posible solución, pero parece haber muchas limitaciones. Por ejemplo, tengo la capacidad de auditar los clústeres de RDS para ver si tienen alarmas creadas para determinadas métricas, pero no puedo hacer lo mismo con las instancias de RDS.

Respuesta1

Prevenir la creación de recursos con SCP

En algunos casos, puede utilizar Políticas de control de servicios para este tipo de requisitos, pero solo en relación con las propiedades del recurso que se está creando. AFAIK, no funcionará decir "no puede crear una instancia EC2 si no se ha activado una alarma de CloudWatch". sido creado".

AWS tiene algunos ejemplos de políticas de control de servicios enesta página, Copiaré uno a continuación. He utilizado esta técnica para hacer cosas como evitar la creación de una instancia EC2 si no está cifrada, si el volumen de EBS no está cifrado y evitar la creación de RDS si el almacenamiento no está cifrado.

Ejemplo de SCP de Amazon: con este SCP, se deniegan los lanzamientos de cualquier instancia que no utilice el tipo de instancia 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"
        }
      }
    }
  ]
}

Remediación automática

Podría considerar la corrección automática después de que se creen los recursos. Algo como AWS Config puede recibir una notificación cada vez que se crea un recurso, ejecutar un script Lambda, que luego puede ejecutar código personalizado para detectar el estado y configurar recursos relacionados. Nuevamente, esto es una costumbre, pero lo hemos hecho en el pasado. Por ejemplo, cuando se crea un depósito de S3, activamos el registro y el control de versiones a menos que existiera una etiqueta específica.

De la misma manera, podría eliminar recursos que no cumplan con las normas en lugar de corregirlos automáticamente.

Impedir la creación de recursos con permisos de IAM

En lugar de eliminar recursos que no cumplen, podría considerar reducir los permisos para los usuarios para que no puedan crear recursos directamente y establecer algún tipo de sistema de autoservicio que configure recursos para ellos, con todos los recursos relacionados necesarios configurados. arriba. No lo he hecho yo mismo, por lo que no puedo decir exactamente cómo hacerlo.

Esto podría ser tan simple como permitir que las plantillas de CloudFormation que usted proporcione se ejecuten bajo una función de servicio, pero no permitir a los usuarios permisos para crear los recursos directamente.

información relacionada