Exemplos de políticas de controle de recursos

Os exemplos de políticas de controle de recursos (RCPs) exibidos neste tópico são apenas para fins informativos. Para exemplos de perímetro de dados, consulte Exemplos de políticas de perímetro de dados em. GitHub

Antes de usar esses exemplos

Antes de usar esses exemplos RCPs em sua organização, faça o seguinte:

• Analise e personalize cuidadosamente o RCPs de acordo com seus requisitos exclusivos.

• Teste minuciosamente o RCPs em seu ambiente com os AWS serviços que você usa.

Os exemplos de políticas nesta seção demonstram a implementação e o uso de RCPs. Eles não são destinados a ser interpretado como recomendações oficiais ou práticas recomendadas da AWS a serem implementadas exatamente como mostrado. É sua responsabilidade testar cuidadosamente todas as políticas para verificar se elas são adequadas para resolver os requisitos comerciais de seu ambiente. Políticas de controle de recursos baseadas em negação podem, sem querer, limitar ou bloquear o uso de AWS serviços, a menos que você adicione as exceções necessárias à política.

Exemplos gerais

RCPFullAWSAccess

A política a seguir é uma política AWS gerenciada e é automaticamente anexada à raiz da organização, a cada UO e a cada conta da sua organização, quando você ativa as políticas de controle de recursos (RCPs). Você não pode desanexar essa política. Esse RCP padrão permite que todos os diretores e ações acessem seus recursos, ou seja, até você começar a criar e anexar RCPs, todas as suas permissões existentes do IAM continuarão funcionando da mesma forma. Você não precisa testar o efeito dessa política, pois ela permitirá que o comportamento de autorização existente continue para seus recursos.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

Proteção delegada confusa entre serviços

Alguns Serviços da AWS (serviços de chamada) usam seu AWS service (Serviço da AWS) principal para acessar AWS recursos de outros Serviços da AWS (chamados serviços). Quando um ator que não pretendia ter acesso a um AWS recurso tenta usar a confiança de um AWS service (Serviço da AWS) diretor para interagir com recursos aos quais ele não deveria ter acesso, isso é conhecido como o problema do substituto confuso entre serviços. Para obter mais informações, consulte O problema confuso do deputado no Guia do usuário do IAM

A política a seguir exige que AWS service (Serviço da AWS) os diretores que acessam seus recursos só o façam em nome das solicitações da sua organização. Essa política aplica o controle somente às solicitações aws:SourceAccount presentes, para que as integrações de serviços que não exijam o uso de aws:SourceAccount não sejam afetadas. Se o aws:SourceAccount estiver presente no contexto da solicitação, a Null condição será avaliada comotrue, fazendo com que a aws:SourceOrgID chave seja aplicada.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RCPEnforceConfusedDeputyProtection",
            "Effect": "Deny",
            "Principal": "*",
            "Action": [
                "s3:*",
                "sqs:*",
                "secretsmanager:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEqualsIfExists": {
                    "aws:SourceOrgID": "my-org-id"
                },
                "Bool": {
                    "aws:PrincipalIsAWSService": "true"
                },
                "Null": {
                    "aws:SourceAccount": "false"
                }
            }
        }
    ]
}

Restrinja o acesso somente a conexões HTTPS aos seus recursos

A política a seguir exige que o acesso aos seus recursos ocorra somente em conexões criptografadas via HTTPS (TLS). Isso pode ajudar a evitar que possíveis invasores manipulem o tráfego da rede.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EnforceSecureTransport",
            "Effect": "Deny",
            "Principal": "*",
            "Action": [
                "sts:*",
                "s3:*",
                "sqs:*",
                "secretsmanager:*",
                "kms:*"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:SecureTransport": "false"
                }
            }
        }
    ]
}

Controles consistentes de políticas de bucket do Amazon S3

O RCP a seguir contém várias declarações para impor controles de acesso consistentes nos buckets do Amazon S3 em sua organização.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EnforceS3TlsVersion",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": "*",
            "Condition": {                
                "NumericLessThan": {
                    "s3:TlsVersion": [
                        "1.2"
                    ]
                }
            }
        },
        {
            "Sid": "EnforceKMSEncryption",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "*",
            "Condition": {
                "Null": {
                    "s3:x-amz-server-side-encryption-aws-kms-key-id": "true"
                }
            }
        }
    ]
}

• O ID da declaração EnforceS3TlsVersion — Exigir uma versão mínima de TLS 1.2 para acessar os buckets do S3.

• O ID da declaração EnforceKMSEncryption — Exija que os objetos sejam criptografados no lado do servidor com chaves KMS.