El acceso no controlado a recursos críticos o confidenciales puede afectar significativamente a una organización de varias maneras, incluida la divulgación o manipulación de datos críticos.

Las configuraciones de acceso dinámico pueden exponer los sistemas y amplían la superficie de ataque de una organización. Los servicios abiertos a la interacción con el público suelen estar sujetos a análisis y sondeos casi continuos por parte de entidades malintencionadas.

Esto es especialmente problemático cuando se descubre y publica una vulnerabilidad de día cero para un servicio expuesto, como Heartbleed. Los atacantes pueden perseguir y buscar activamente sistemas expuestos y sin revisión que puedan aprovechar.

Las directivas IAM que permiten el acceso sin restricciones a los recursos ponen en riesgo a una organización. Las directivas mal estructuradas socavan la capacidad de una organización para controlar y gestionar los cambios en los recursos.

Una configuración comodín para los principales lambda infringe el principio de privilegios mínimos y permite que un atacante invoque el lambda desde cualquier cuenta.

Ejemplo 1: La siguiente tarea de Ansible de ejemplo define un principal lambda comodín.

- name: Create Lambda policy statement for S3 event notification
  community.aws.lambda_policy:
    action: lambda:InvokeFunction
    function_name: functionName
    principal: *
    statement_id: lambda-s3-demobucket-access-log
    source_arn: arn:aws:s3:us-west-2:123456789012:demobucket
    source_account: 123456789012
    state: present

De forma predeterminada, los clústeres de Amazon Redshift no son de acceso público.

Permitir el acceso público a un clúster amplía la superficie de ataque de la organización.

Ejemplo 1: El siguiente ejemplo muestra una tarea de Ansible que habilita explícitamente el acceso público a un clúster de Amazon Redshift configurando el parámetro publicly_accessible en yes .

- name: example1
  community.aws.redshift:
    identifier: mycluster
    command: create
    db_name: mydb
    node_type: ds1.xlarge
    username: "{{ username }}"
    password: "{{ password }}"
    publicly_accessible: yes

El acceso no controlado a recursos críticos o confidenciales puede afectar significativamente a una organización de varias maneras, incluida la divulgación o manipulación de datos críticos.

Una mala configuración del acceso público a un contenedor S3 es una de las principales causas de vulneraciones de datos.

Aunque los contenedores S3 bloquean el acceso público de forma predeterminada, cualquier usuario autorizado puede actualizar las directivas de contenedor o las listas de control de acceso (ACL) para permitir el acceso público.

El acceso no controlado a recursos críticos o confidenciales puede afectar significativamente a una organización de varias maneras, incluida la divulgación o manipulación de datos críticos.

Los canales de comunicación de datos insuficientemente protegidos pueden poner los datos críticos de la organización en riesgo de robo, manipulación o divulgación.

Las distribuciones de Amazon CloudFront se pueden configurar incorrectamente para permitir la comunicación sin autenticar o sin cifrar, o utilizar un protocolo obsoleto. Tales configuraciones incorrectas pueden comprometer y permitir que un atacante, que resida en una red compartida, husmee y manipule los datos en tránsito.

Los canales de comunicación de datos insuficientemente protegidos pueden poner los datos críticos de la organización en riesgo de robo, manipulación o divulgación.

El cifrado en reposo no está habilitado. Esto expone los datos a accesos no autorizados y posibles robos.

El cifrado en reposo no está habilitado. Esto expone los datos a accesos no autorizados y posibles robos.

De forma predeterminada, los volúmenes de EBS no están cifrados.
Ejemplo 1: La siguiente plantilla de ejemplo expone los datos a posible robo y acceso no autorizados.

	Resources:
  	  EBSVOLExample:
    	Type: AWS::EC2::Volume
    	Properties:
      	  Encrypted: false
	

Una AMI de Amazon EC2 que asigna un dispositivo de bloqueo sin cifrar expone los datos a accesos no autorizado y a posibles robos.

Ejemplo 1: La siguiente tarea de Ansible crea una AMI de Amazon EC2 y adjunta un dispositivo de bloqueo sin cifrado de datos en reposo a la AMI porque el parámetro encrypted está establecido en false.

- name: Basic AMI Creation
  amazon.aws.ec2_ami:
    state: present
    instance_id: i-xxxxxx
    name: test_ami
    device_mapping:
      device_name: /dev/sda
      encrypted: false

De forma predeterminada, un sistema de archivos EFS no está cifrado. Esto expone los datos al acceso no autorizado y posible robo.

Ejemplo 1: La siguiente tarea de Ansible configura un sistema de archivos EFS sin cifrado de datos en reposo porque el parámetro encrypt está establecido en no.

- name: EFS provisioning
  community.aws.efs:
    state: present
    name: myTestEFS
    encrypt: no
    targets:
      - subnet_id: subnet-12345678
        security_groups: [ "sg-87654321" ]

Una capa de almacenamiento de flujos de Amazon Kinesis sin cifrar expone los datos a accesos no autorizados y a posibles robos.

Ejemplo 1: La siguiente tarea de Ansible configura un flujo de Kinesis sin cifrado de datos en reposo porque el parámetro encryption_state está establecido en disabled.

- name: Set up Kinesis Stream with 10 shards and wait for the stream to become active
  community.aws.kinesis_stream:
    name: test-stream
    shards: 10
    wait: yes
    wait_timeout: 600
    encryption_state: disabled
  register: test_stream

De forma predeterminada, las instancias de RDS de Amazon no están cifradas. Esto expone los datos a posible robo y acceso no autorizados.

Los canales de comunicación de datos insuficientemente protegidos pueden poner los datos críticos de la organización en riesgo de robo, manipulación o divulgación.

De forma predeterminada, los clústeres de Amazon Redshift no están cifrados. Esto expone los datos al acceso no autorizado y posible robo.