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, los grupos de registro de CloudWatch conservan los registros de forma indefinida. Un valor de retención no establecido indica que no se han consultado las directivas de gestión de datos de la organización para establecer las configuraciones adecuadas. Esto podría conllevar gastos innecesarios para la organización relativos a almacenamiento y gestión de eventos de registro.

Un atacante puede lanzar un ataque de denegación de billetera (DoW) al provocar persistentemente un registro de eventos falso durante un período prolongado, lo que puede afectar de forma financiera a la organización.

Ejemplo 1: El siguiente ejemplo muestra una tarea de Ansible que no define una directiva de retención.

- 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" }

De forma predeterminada, la validación del archivo de registro de CloudTrail está deshabilitada, lo que evita que los investigadores confirmen que no ha habido manipulaciones externas en los archivos de registro de CloudTrail.

Esto permite que un atacante con los privilegios necesarios realice cambios de configuración dañinos y los oculte modificando los registros de CloudTrail.

Ejemplo 1: La siguiente tarea de Ansible establece una configuración de CloudTrail sin validación de la integridad del archivo de registro porque falta el parámetroenable_log_file_validation.

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

Una instancia de RDS de Amazon de acceso público amplía innecesariamente la superficie de ataque de una organización. Los servicios abiertos a la interacción con el público están sujetos a análisis y sondeos casi continuos por parte de los atacantes.

Ejemplo 1: La siguiente tarea de Ansible configura una instancia de RDS con acceso público porque publicly_accessible está establecido en 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

Las configuraciones de acceso dinámico exponen innecesariamente los sistemas y amplían la superficie de ataque de una organización. Los servicios abiertos a la interacción con el público están 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 (por ejemplo, Heartbleed). Los atacantes pueden perseguir y buscar activamente sistemas expuestos y sin revisión que puedan aprovechar.

"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
            }
        ]
    }

La definición de claves de acceso para su cuenta de usuario raíz de AWS pone en riesgo todos sus recursos de AWS si esta clave se ve comprometida.

Ejemplo 1: La siguiente plantilla de ejemplo crea una clave de acceso para la cuenta de usuario raíz.

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

Las configuraciones de acceso dinámico exponen innecesariamente los sistemas y amplían la superficie de ataque de una organización. Los servicios abiertos a la interacción con el público están 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 (por ejemplo, Heartbleed). Los atacantes pueden perseguir y buscar activamente sistemas expuestos y sin revisión que puedan aprovechar.

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

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: La siguiente plantilla de ejemplo habilita explícitamente el acceso público a un clúster de Amazon Redshift.

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

Una entidad principal ded IAM de AWS define el acceso a un recurso para un usuario, servicio u otra entidad. En una instrucción IAM, hay una definición de una entidad principal de IAM que permite que todos accedan a una acción S3.

El acceso público a un contenedor de S3 debido a configuraciones incorrectas 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. Prohíba este tipo de actualización habilitando la configuración deBlockPublicPolicy yBlockPublicAcls respectivamente en una propiedad S3 dePublicAccessBlockConfiguration.
Para protegerse también contra las directivas de contenedor excesivamente permisivas y las ACL, respectivamente, habilite la configuración de RestrictPublicBuckets y IgnorePublicAcls.

Los canales de comunicación no cifrados son propensos al espionaje y manipulaciones.

Deshabilitar la seguridad del transporte expone los datos a accesos no autorizados, posibles robos y manipulaciones.

Los canales de comunicación no cifrados son propensos al espionaje y manipulaciones.

De forma predeterminada, el cifrado de transporte del grupo de replicación de ElastiCache está deshabilitado. Esto expone los datos a accesos no autorizados, posibles robos y manipulaciones.

Ejemplo 1: La siguiente plantilla de ejemplo define un grupo de replicación de ElastiCache sin el cifrado de transporte habilitado.

{
    "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"
        }
    }
}

De forma predeterminada, los clústeres de Amazon Redshift no requieren cifrado de transporte. Esto expone los datos a acceso no autorizado, manipulaciones y posible robo.

Ejemplo 1: La siguiente plantilla de ejemplo define un clúster de Amazon Redshift que no aplica seguridad de transporte.

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

De forma predeterminada, los grupos de registro de CloudWatch conservan los registros de forma indefinida. Un valor no establecido indica que no se han consultado las directivas de gestión de datos de la organización para establecer las configuraciones adecuadas. Esto podría implicar que la organización incurra en gastos innecesarios para almacenar y administrar eventos de registro que ya no son relevantes.

Un atacante puede lanzar un ataque de denegación de billetera (DoW) al provocar persistentemente un registro de eventos falso durante un período prolongado, lo que puede afectar de forma financiera a la organización.

Ejemplo 1: El siguiente ejemplo muestra una plantilla que no define una directiva de retención.

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

De forma predeterminada, los clústeres de Amazon Redshift no capturan registros de auditoría. Esto puede permitir que el comportamiento malintencionado no sea detectado y se inhiba el análisis forense en caso de infracción.

Ejemplo 1: La siguiente plantilla de ejemplo define un clúster de Amazon Redshift sin registro de auditoría.

  "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"
    }

La autenticación es un aspecto esencial de la seguridad. La fiabilidad del proceso de autenticación depende de la seguridad y solidez de las credenciales de inicio de sesión. Las políticas de contraseñas que garantizan que los usuarios creen contraseñas seguras son cruciales para implementar sitios web seguros. La seguridad de la contraseña es una medida de la eficacia que proporciona para resistir ante posibles ataques de adivinación y de fuerza bruta. Algunos parámetros que ayudan a definir la seguridad de la contraseña incluyen características de contraseña como la longitud, la complejidad y la aleatoriedad de la contraseña.

Si una aplicación administra información confidencial y no usa cifrado a nivel de mensaje, solo debe poder comunicarse a través de un canal de transporte encriptado.

Si una aplicación administra información confidencial y no usa cifrado a nivel de mensaje, solo debe poder comunicarse a través de un canal de transporte encriptado. La etiqueta <transportSender> no debe especificar http, porque la comunicación con esta dirección URL no se cifrará.

De forma predeterminada, los contenedores de almacenamiento de blobs de Azure impiden el acceso anónimo a sus blobs.

Las configuraciones de acceso insuficientes exponen los sistemas y amplían la superficie de ataque de una organización. Los recursos abiertos al acceso público pueden filtrar involuntariamente datos confidenciales.

Ejemplo 1: La siguiente tarea de Ansible de ejemplo define un contenedor de almacenamiento de blobs de Azure con el parámetro public_access establecido en container. Esto permite el acceso anónimo a todos los blobs y datos del contenedor.

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

Las configuraciones demasiado amplias exponen los sistemas y amplían la superficie de ataque de una organización. Los servicios abiertos a la interacción con el público están sujetos a análisis y sondeos casi continuos por parte de los atacantes.

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

Ejemplo 1: La siguiente tarea de Ansible de ejemplo permite el tráfico entrante sin restricciones a una variedad de puertos, incluido el puerto de servicio 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: "*"