Os clusters do Amazon Redshift não são, por padrão, acessíveis publicamente.

Habilitar o acesso público a um cluster resulta em uma superfície de ataque mais ampla para a organização.

Exemplo 1: O exemplo a seguir mostra uma tarefa Ansible que habilita explicitamente o acesso público a um cluster do Amazon Redshift configurando o parâmetro publicly_accessible como yes .

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

Uma configuração incorreta de acesso público a um bucket do S3 é uma das principais causas das violações de dados.

Embora os buckets do S3 bloqueiem o acesso público por padrão, qualquer usuário autorizado pode atualizar as políticas de bucket ou listas de controle de acesso (ACLs) para permitir o acesso público.

Uma AMI do Amazon EC2 que mapeia um dispositivo de bloco não criptografado expõe os dados a acesso não autorizado e possível roubo.

Exemplo 1: A tarefa do Ansible a seguir cria uma AMI do Amazon EC2 e anexa um dispositivo de bloco sem criptografia de dados em repouso à AMI porque o parâmetro encrypted está definido como 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

Por padrão, um sistema de arquivos do EFS não é criptografado. Isso expõe os dados a acesso não autorizado e possível roubo.

Exemplo 1: A tarefa do Ansible a seguir configura um sistema de arquivos do EFS sem criptografia de dados em repouso porque o parâmetro encrypt está definido como no.

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

Uma camada de armazenamento de fluxo não criptografada do Amazon Kinesis expõe os dados a acesso não autorizado e possível roubo.

Exemplo 1: A tarefa do Ansible a seguir configura um fluxo do Kinesis sem criptografia de dados em repouso porque o parâmetro encryption_state está definido como 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

Por padrão, os Grupos de Logs do CloudWatch retêm os logs indefinidamente. Um valor de retenção não definido indica que as políticas de manipulação de dados organizacionais não foram consultadas para definir as configurações apropriadas. Isso pode resultar em despesas desnecessárias para a organização armazenar e gerenciar eventos de log.

Um invasor pode lançar um ataque de negação de carteira (DoW), solicitando persistentemente o registro de eventos espúrios por um longo período de tempo, o que pode impactar a organização financeiramente.

Exemplo 1: O exemplo a seguir mostra uma tarefa do Ansible que não consegue definir uma política de retenção.

- name: create a log_group in CloudWatchLogs
  community.aws.cloudwatchlogs_log_group:
    log_group_name: test-log-group
    tags: { "Name": "test-log-group", "Env" : "QA" }

Por padrão, a validação do arquivo de log do CloudTrail está desabilitada, o que evita que os investigadores confirmem que não houve violação externa dos arquivos de log do CloudTrail.

Isso permite que um invasor com os privilégios necessários execute alterações de configuração prejudiciais e as oculte modificando os logs do CloudTrail.

Exemplo 1: A seguinte tarefa Ansible define uma configuração do CloudTrail sem a validação da integridade do arquivo de log porque o parâmetro enable_log_file_validation está ausente.

- name: create a single region cloudtrail
  community.aws.cloudtrail:
    s3_bucket_name: mylogbucket
    s3_key_prefix: cloudtrail
    region: us-west-2