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

Uma instância do Amazon RDS acessível publicamente amplia desnecessariamente a superfície de ataque de uma organização. Os serviços abertos à interação com o público estão sujeitos a varreduras e investigações quase contínuas por parte dos invasores.

Exemplo 1: A tarefa do Ansible a seguir configura uma instância do RDS com acesso público porque publicly_accessible está definido como true.

- name: createdb
  community.aws.rds_instance:
    db_instance_identifier: test-db
    engine: aurora
    instance_type: db.t2.small
    username: "{{ username }}"
    password: "{{ password }}"
    cluster_id: test-cluster
    publicly_accessible: true

As configurações de acesso livre expõem os sistemas desnecessariamente e ampliam a superfície de ataque de uma organização. Os serviços abertos à interação com o público estão sujeitos a varreduras e investigações quase contínuas por entidades mal-intencionadas.

Isso é especialmente problemático quando um exploit de dia zero para um serviço exposto é descoberto e publicado (por exemplo, Heartbleed). Os invasores podem perseguir e pesquisar ativamente sistemas não corrigidos e expostos para explorá-los.

"PSQLSecurityGroup": {
    "Type": "AWS::EC2::SecurityGroup",
    "Properties": {
        "VpcId": {
            "Ref": "VpcId"
        },
        "GroupDescription": "Enable PSQL access via port 5432 to world",
        "SecurityGroupIngress": [
            {
                "CidrIp": "0.0.0.0/0",
                "FromPort": 5432,
                "IpProtocol": "tcp",
                "ToPort": 5432
            }
        ]
    }

Definir chaves de acesso para sua conta de usuário raiz da AWS coloca todos os seus recursos da AWS em risco se essa chave for comprometida.

Exemplo 1: O modelo de exemplo a seguir cria uma chave de acesso para a conta do usuário raiz.

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Resources": {
        "SecKeys": {
            "Type": "AWS::IAM::AccessKey",
            "Properties": {
            "UserName": "Root"
            }
        }
    }
}

As configurações de acesso livre expõem os sistemas desnecessariamente e ampliam a superfície de ataque de uma organização. Os serviços abertos à interação com o público estão sujeitos a varreduras e investigações quase contínuas por entidades mal-intencionadas.

Isso é especialmente problemático quando um exploit de dia zero para um serviço exposto é descoberto e publicado (por exemplo, Heartbleed). Os invasores podem perseguir e pesquisar ativamente sistemas não corrigidos e expostos para explorá-los.

"DbSecurity": {
  "Type": "AWS::RDS::DBSecurityGroup",
  "Properties": {
      "GroupDescription": "Ingress for Amazon RDS security group",
      "DBSecurityGroupIngress": {
          "CIDRIP": "0.0.0.0/0"
      }
  }
}

Por padrão, os clusters do Amazon Redshift não sã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 modelo de exemplo a seguir permite explicitamente o acesso público a um cluster do Amazon Redshift.

"Resources": {
    "RDCluster": {
      "Type": "AWS::Redshift::Cluster",
      "Properties": {
        "NodeType": "ds2.xlarge",
        "ClusterType": "single-node",
        "DBName": "rdb",
        "PubliclyAccessible": true,
        "MasterUsername": "rduser",
        "MasterUserPassword": {
          "Ref": "MasterUserPassword"
        }
      }
    }
}

Uma AWS IAM Principal define o acesso a um recurso para um usuário, serviço ou outra entidade. Em uma declaração IAM, há uma definição de uma IAM Principal que permite que todos acessem uma ação S3.

O acesso público a um bucket S3 devido a configurações incorretas é uma das principais causas de 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. Proíba este tipo de atualização habilitando a configuração BlockPublicPolicy e BlockPublicAcls, respectivamente, em uma propriedade S3 de PublicAccessBlockConfiguration.
Para se proteger também contra quaisquer políticas de bucket excessivamente permissivas e ACLs preexistentes, habilite as configurações RestrictPublicBuckets e IgnorePublicAcls.

Canais de comunicação não criptografados estão propensos a serem interceptados e adulterados.

Desativar a segurança de transporte expõe os dados a acesso não autorizado, possível roubo e adulteração.

Canais de comunicação não criptografados estão propensos a serem interceptados e adulterados.

Por padrão, a criptografia de transporte do grupo de replicação do ElastiCache está desabilitada. Isso expõe os dados a acesso não autorizado, possível roubo e adulteração.

Exemplo 1: O modelo de exemplo a seguir define um grupo de replicação do ElastiCache sem criptografia de transporte habilitada.

{
    "Resources": {
        "ReplicationGroup": {
            "Properties": {
            "Engine": "redis",
            "EngineVersion": "EngineVersion",
            "ReplicasPerNodeGroup": "NumReplicas",
            "PreferredMaintenanceWindow": "sat:07:00-sat:08:00",
            "AtRestEncryptionEnabled": true,
            "CacheParameterGroupName": "CacheParameterGroup",
            "SecurityGroupIds": [
                "SecurityGroup"
            ],
            "SnapshotRetentionLimit": "SnapshotRetentionLimit",
            "CacheNodeType": "CacheNodeType",
            "CacheSubnetGroupName": "CacheSubnetGroupName",
            "NumNodeGroups": "NumShards",
            "SnapshotWindow": "00:00-03:00",
            "ReplicationGroupDescription": "AWS::StackName"
            },
            "UpdatePolicy": {
            "UseOnlineResharding": true
            },
            "DeletionPolicy": "Snapshot",
            "UpdateReplacePolicy": "Snapshot",
            "Type": "AWS::ElastiCache::ReplicationGroup"
        }
    }
}

Por padrão, os clusters do Amazon Redshift não exigem criptografia de transporte. Isso expõe os dados a acesso não autorizado, adulteração e possível roubo.

Exemplo 1: O modelo de exemplo a seguir define um cluster do Amazon Redshift que não impõe segurança de transporte.

{
    "Resources": {
        "RedShiftParms": {
            "Type": "AWS::Redshift::clusterParameterGroup",
            "Properties": {
                "Description": "parameter group",
                "ParameterGroupFamily": "redshift-1.0",
                "Parameters": [
                    {
                        "ParameterName": "require_ssl",
                        "ParameterValue": "false"
                    }
                ]
            }
        }
    }
}

Por padrão, os Grupos do CloudWatch Log retêm logs indefinidamente. Um valor não definido indica que as políticas de tratamento de dados organizacionais não foram consultadas para definir as configurações apropriadas. Isso pode significar que a organização incorrerá em despesas desnecessárias no armazenamento e gerenciamento de eventos de registro que não são mais relevantes.

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 um modelo que não consegue definir uma política de retenção.

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Resources": {
        "MyLogGroup": {
            "Type": "AWS::Logs::LogGroup",
            "Properties": {
                "LogGroupName": "Service01LogGroup"
            }
        }
    }
}

Por padrão, os clusters do Amazon Redshift não capturam logs de auditoria. Isso pode permitir que um comportamento mal-intencionado não seja detectado, além de inibir a análise forense no caso de uma violação.

Exemplo 1: O modelo de exemplo a seguir define um cluster do Amazon Redshift sem registro de auditoria.

  "Resources": {
    "RedshiftClusterTest": {
      "Properties": {
        "NodeType": "dc1.large",
        "Port": 5439,
        "VpcSecurityGroupIds": [
          "${RedshiftSecurityGroup}"
        ],
        "ClusterSubnetGroupName": "RedshiftClusterSubnetGroup",
        "ClusterType": "single-node"
        "MasterUserPassword": "MasterUserPassword",
        "MasterUsername": "MasterUsername",
        "DBName": "${DatabaseName}",
        "IamRoles": ["RawDataBucketAccessRole.Arn"],
        "PubliclyAccessible": true
      },
      "Type": "AWS::Redshift::Cluster"
    }

A autenticação é um aspecto essencial da segurança. A confiabilidade do processo de autenticação depende da segurança e da força das credenciais de login. As políticas de senha que garantem que os usuários criem senhas fortes são cruciais para a implantação de sites seguros. A força da senha é uma medida da eficácia que ela oferece em resistir a adivinhações e ataques de força bruta. Alguns parâmetros que ajudam a definir a força da senha incluem características de senha, como comprimento, complexidade e aleatoriedade da senha.

Se um aplicativo lida com informações confidenciais e não usa criptografia no nível da mensagem, ele só deve ter permissão para se comunicar por meio de um canal de transporte criptografado.

Se um aplicativo lida com informações confidenciais e não usa criptografia no nível da mensagem, ele só deve ter permissão para se comunicar por meio de um canal de transporte criptografado. A tag <transportSender> não deve especificar http porque a comunicação com este URL não será criptografada.

Por padrão, os contêineres de armazenamento de Blob do Azure evitam o acesso anônimo a seus Blobs.

As configurações de acesso insuficientes expõem os sistemas e ampliam a superfície de ataque de uma organização. Os recursos abertos ao acesso público podem vazar acidentalmente dados confidenciais.

Exemplo 1: A tarefa do Ansible de exemplo a seguir define um contêiner de Armazenamento de Blobs do Azure com o parâmetro public_access definido como container. Isso permite acesso anônimo a todos os blobs e dados do Contêiner.

- name: Create container test
  azure_rm_storageblob:
    resource_group: testGroup
    storage_account_name: sa001
    container: testContainer
    ...
    public_access: container
    ...

Configurações excessivamente amplas expõem os sistemas e ampliam a superfície de ataque de uma organização. Os serviços abertos à interação com o público estão sujeitos a varreduras e investigações quase contínuas por parte dos invasores.

Isso é especialmente problemático quando um exploit de dia zero para um serviço exposto é descoberto e publicado (por exemplo, Heartbleed). Os invasores podem perseguir e pesquisar ativamente sistemas não corrigidos e expostos para explorá-los.

Exemplo 1: A tarefa do Ansible de exemplo a seguir permite tráfego de entrada irrestrito para um intervalo de portas, incluindo a porta de serviço RDP (3389).

- name: testFWRule
azure_rm_securitygroup:
    resource_group: testRG
    name: test
    rules:
    - name: rule001
        priority: 100
        direction: Inbound
        access: Allow
        protocol: "*"
        source_port_range: "*"
        destination_port_range: "3388-3398"
        source_address_prefix: "*"
        destination_address_prefix: "*"
    - name: rule002
        priority: 100
        direction: Inbound
        access: Allow
        protocol: "*"
        source_port_range: "*"
        destination_port_range: 22
        source_address_prefix: "*"
        destination_address_prefix: "*"