APIs destinadas apenas para fins de depuração são usadas.

Por padrão, os fluxos de tarefas em um aplicativo Fusion não são diretamente acessíveis a partir de uma solicitação GET: sempre que um URL tenta invocar o fluxo de tarefas, ele recebe um código de status HTTP 403. No entanto, confiar em uma configuração implícita sempre carece de clareza e pode levar a um comportamento indesejado se a configuração padrão for alterada posteriormente.

Exemplo 1: O seguinte trecho de um arquivo de definição de fluxo de tarefas mostra o mesmo fluxo de tarefas definida com a configuração implícita url-invoke-disallowed por padrão.

...
    <task-flow-definition id="password">
        <default-activity>PasswordPrompt</default-activity>
        <view id="PasswordPrompt">
            <page>/PasswordPrompt.jsff</page>
        </view>
        <use-page-fragments/>
    </task-flow-definition>
...

O armazenamento de chaves de criptografia em campos de classe estática permite a recuperação fácil por uma entidade que pode acessar a memória de processo (por exemplo, dispositivo com raiz) ou despejos de memória de processo (por exemplo, despejos de memória).

Uma prática comum de desenvolvimento é adicionar código "back door" (porta dos fundos), projetado especificamente para fins de depuração ou teste, que não se destina a ser enviado ou implantado com o aplicativo. Quando esse tipo de código de depuração é acidentalmente deixado no aplicativo, o aplicativo fica aberto a modos não intencionais de interação. Esses pontos de entrada "back door" criam riscos de segurança, pois não são levados em consideração durante procedimentos de design ou teste e não se enquadram nas condições operacionais esperadas do aplicativo.

Por padrão, os volumes EBS não são criptografados.
Exemplo 1: O exemplo a seguir expõe os dados a um possível roubo e acesso não autorizado.

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

Por padrão, as instâncias do Amazon RDS não são criptografadas. Isso expõe os dados a um possível roubo e acesso não autorizado.

Por padrão, os clusters do Amazon Redshift não são criptografados. Isso expõe os dados a acesso não autorizado e possível roubo.

Um bucket do Amazon S3 é criado sem criptografia no lado do servidor. A criptografia atenua as violações de dados tornando os dados ilegíveis para qualquer pessoa sem as credenciais adequadas. A criptografia em repouso pode ajudar a atender alguns requisitos de conformidade industrial e governamental, como GDPR, HIPAA e PCI.

Os métodos de Gateway da API AWS que são publicamente acessíveis podem expor a organização a ataques.

Exemplo 1: O modelo de exemplo a seguir define os métodos de Gateway da API AWS acessíveis publicamente.

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Resources": {
        "MyMethod0": {
            "Type": "AWS::ApiGateway::Method",
            "Properties": {
                "RestApiId": "MyAPIID",
                "ResourceId": "MyResourceID",
                "HttpMethod": "GET",
                "AuthorizationType": "NONE"
            }
        },
        "MyMethod1": {
            "Type": "AWS::ApiGateway::Method",
            "Properties": {
                "RestApiId": "MyAPIID",
                "ResourceId": "MyResourceID",
                "HttpMethod": "POST",
                "AuthorizationType": "NONE",
                "ApiKeyRequired": false
            }
        }
    }
}

Uma configuração curinga para lambda principais viola o princípio de privilégios mínimos e permite que um invasor invoque o lambda de qualquer conta.

Exemplo 1: O modelo de exemplo a seguir define um lambda principal curinga.

{
    "Resources": {
        "LambdaPerm": {
            "Type": "AWS::Lambda::Permission",
            "Properties": {
            "SourceAccount": "AWS::AccountId",
            "SourceArn": "bucket.Arn",
            "FunctionName": "function.Arn",
            "Action": "lambda:InvokeFunction",
            "Principal": "*"
            }
        }
    },
    "AWSTemplateFormatVersion": "2010-09-09",
    "Description": "Lambda Permission"
}

Por padrão, as instâncias do Amazon DocumentDB não são criptografadas. Isso expõe os dados a acesso não autorizado e possível roubo.

Exemplo 1: O exemplo a seguir mostra um modelo que define um Amazon DocumentDB com criptografia desabilitada.

"Resources": {
    "DocDBDefault": {
        "Type": "AWS::DocDB::DBCluster",
        "Properties": {
            "MasterUsername": "name",
            "MasterUserPassword": "password"
        }
    }

Por padrão, os volumes EBS não são criptografados.
Exemplo 1: O exemplo a seguir expõe os dados a um possível roubo e acesso não autorizado.

"Resources": {
    "EBSVOLExample": {
        "Type": "AWS::EC2::Volume",
        "Properties": {
            "Encrypted": false,
        }
    }
}

Por padrão, os Grupos de Replicação do Amazon ElastiCache não são criptografados. Isso expõe os dados a acesso não autorizado e possível roubo.

Exemplo 1: O modelo de exemplo a seguir define um Grupo de Replicação do Amazon ElastiCache com criptografia desabilitada.

{
    "Description": "ElastiCache redis",
    "Resources": {
        "MyReplicationGroup": {
            "Type": "AWS::ElastiCache::ReplicationGroup",
            "Properties": {
                "AutomaticFailoverEnabled": true,
                "CacheNodeType": {
                    "Ref": "CacheNodeType"
                },
                Cache  "ParameterGroupName": {
                    "Ref": "CacheParameterGroup"
                },
                "CacheSubnetGroupName": {
                    "Ref": "CacheSubnetGroupName"
                },
                "Engine": "redis",
                "EngineVersion": {
                    "Ref": "EngineVersion"
                },
                "NumNodeGroups": {
                    "Ref": "NumShards"
                },
                "ReplicasPerNodeGroup": {
                    "Ref": "NumReplicas"
                },
                "PreferredMaintenanceWindow": "sat:10:00-sat:08:00",
                "SecurityGroupIds": [
                    {
                        "Ref": "SecurityGroup"
                    }
                ],
                "SnapshotRetentionLimit": {
                    "Ref": "SnapshotRetentionLimit"
                },
                "SnapshotWindow": "00:00-03:00"
            },
            "UpdatePolicy": {
                "UseOnlineResharding": true
            }
        }
    }
}

Canais de comunicação de dados protegidos de forma insuficiente podem colocar dados organizacionais críticos em risco de roubo, adulteração ou divulgação.

Por padrão, os clusters do Neptune DB não são criptografados. Isso expõe os dados a um possível roubo e acesso não autorizado por invasores.

Exemplo 1: O modelo de exemplo a seguir não permite a criptografia em repouso.

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Description": "My Neptune DB cluster",
    "Resources": {
        "NeptuneDBCluster": {
            "Type": "AWS::Neptune::DBCluster",
            "Properties": {
                "BackupRetentionPeriod": 10,
                "DBClusterIdentifier": "MyDBClusterIdentifier",
                "DBClusterParameterGroupName": "MyNeptuneDBClusterParameterGroup",
                "DBSubnetGroupName": "MyNeptuneDBSubnetGroup",
                "IamAuthEnabled": true,
                "Port": 8080,
                "PreferredBackupWindow": "NeptuneDBClusterPreferredBackupWindow",
                "PreferredMaintenanceWindow": "NeptuneDBClusterPreferredMaintenanceWindow"
            }
        }
    }
}

Por padrão, as instâncias do Amazon RDS não são criptografadas. Isso expõe os dados a um possível roubo e acesso não autorizado.

"Resources": {
    "RDSDBExample": {
        "Type": "AWS::RDS::DBInstance",
        "Properties": {
            "StorageEncrypted": false,
            "DBName": "Test DB",
            "DBInstanceClass": "db.m4.large"
        }
    }
}

Canais de comunicação de dados protegidos de forma insuficiente podem colocar dados organizacionais críticos em risco de roubo, adulteração ou divulgação.

Por padrão, os clusters do Amazon Redshift não são criptografados. Isso expõe os dados a acesso não autorizado e possível roubo.

Exemplo 1: O modelo a seguir define um cluster Redshift sem criptografia habilitada.

"Resources": {
    "RedshiftClusterTest": {
        "Type": "AWS::Redshift::Cluster",
        "Properties": {
            "DBName": "mydb",
            "MasterUsername": "master",
            "MasterUserPassword": "masterPass",
            "NodeType": "ds2.xlarge",
            "ClusterType": "single-node",
        }
    }

Um bucket do Amazon S3 é criado sem criptografia no lado do servidor. A criptografia atenua as violações de dados tornando os dados ilegíveis para qualquer pessoa sem as credenciais adequadas. Como tal, a criptografia em repouso é uma medida para atender a alguns requisitos de conformidade industrial e governamental, como GDPR, HIPAA e PCI.

Canais de comunicação de dados protegidos de forma insuficiente podem colocar dados organizacionais críticos em risco de roubo, adulteração ou divulgação.