As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Exemplos de política 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
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 serem interpretados como recomendações oficiais ou práticas recomendadas da AWS a serem implementadas exatamente como mostrado. É sua responsabilidade testar cuidadosamente quaisquer políticas baseadas quanto à sua adequação para resolver os requisitos de negócios do 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
Tópicos
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.
Proteção contra o problema do substituto confuso 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 Problema do substituto confuso 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 que possuem o parâmetro aws:SourceAccount, de forma que as integrações de serviço que não exigem o uso de aws:SourceAccount não sejam afetadas. Se o parâmetro aws:SourceAccount estiver presente no contexto da solicitação, a condição Null será avaliada como true, fazendo com que a chave aws:SourceOrgID seja aplicada.
Restringir o acesso apenas a conexões HTTPS aos seus recursos
A política a seguir exige que o acesso aos recursos ocorra apenas em conexões criptografadas via HTTPS (TLS). Isso pode ajudar a evitar que possíveis invasores manipulem o tráfego da rede.
Controles consistentes de política de bucket do Amazon S3
A seguinte RCP contém várias instruções para impor controles de acesso consistentes aos buckets do Amazon S3 em sua organização.
-
ID da declaração
EnforceS3TlsVersion– exige uma versão mínima do TLS 1.2 para acessar os buckets do S3. -
ID da declaração
EnforceKMSEncryption– exige que os objetos sejam criptografados no lado do servidor com chaves KMS.