Políticas baseadas em identidade - AWS Secrets Manager
Exemplo: permissão para recuperar valores de segredos individuaisExemplo: permissão para ler e descrever segredos individuaisExemplo: permissão para recuperar um grupo de valores de segredos em um loteExemplo: curingasExemplo: Permissão para criar segredosExemplo: negar uma chave do AWS KMS específica para criptografar segredos

Políticas baseadas em identidade

É possível anexar políticas de permissões a identidades do IAM: usuários, grupos de usuários e funções. Em uma política baseada em identidades, especifique que segredos a identidade pode acessar e que ações a identidade pode executar nos segredos. Para obter mais informações, consulte Adicionar e remover permissões de identidade do IAM.

É possível conceder permissões a um perfil que representa uma aplicação ou um usuário em outro serviço. Por exemplo, uma aplicação em execução em uma instância do Amazon EC2 pode precisar de acesso a um banco de dados. É possível criar um perfil do IAM anexado ao perfil de instância do EC2 e usar uma política de permissões para conceder ao perfil acesso ao segredo que contém credenciais para o banco de dados. Para obter mais informações, consulte Uso de um perfil do IAM para conceder permissões a aplicações em execução em instâncias do Amazon EC2. Outros serviços aos quais é possível anexar perfis incluem o Amazon Redshift, o AWS Lambda e o Amazon ECS.

Você também pode conceder permissões a usuários autenticados por um sistema de identidade diferente do IAM. Por exemplo, é possível associar perfis do IAM a usuários de aplicações móveis que fazem login usando o Amazon Cognito. O perfil concede à aplicação credenciais temporárias com as permissões na política de permissões da função. Em seguida, é possível usar uma política de permissões para conceder ao perfil acesso ao segredo. Para obter mais informações, consulte Provedores de identidade e federação.

É possível usar políticas baseadas em identidades para:

  • Conceder um acesso de identidade a vários segredos.

  • Controlar quem pode criar novos segredos e quem pode acessar segredos que ainda não foram criados.

  • Conceder a um grupo do IAM acesso a segredos.

Exemplo: permissão para recuperar valores de segredos individuais

Para conceder permissão para recuperar valores de segredos, é possível anexar políticas a segredos ou identidades. Para obter ajuda na determinação do tipo de política a ser usado, consulte Políticas baseadas em identidades e políticas baseadas em recursos. Para obter informações sobre como anexar uma política, consulte Políticas baseadas em recursos e Políticas baseadas em identidade.

Esse exemplo é útil quando você deseja conceder acesso a um grupo do IAM. Para conceder permissão para recuperar um grupo de segredos em uma chamada de API em lote, consulte Exemplo: permissão para recuperar um grupo de valores de segredos em um lote.

exemplo Ler um segredo criptografado usando uma chave gerenciada pelo cliente

Se um segredo for criptografado usando uma chave gerenciada pelo cliente, será possível conceder acesso para ler o segredo anexando a política a seguir a uma identidade. \

JSON
{
"Version":"2012-10-17",		 	 	 
"Statement": [
{
  "Effect": "Allow",
  "Action": "secretsmanager:GetSecretValue",
  "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName-AbCdEf"
},
{
  "Effect": "Allow",
  "Action": "kms:Decrypt",
  "Resource": "arn:aws:kms:us-east-1:123456789012:key/key-id"
}
]
}

Exemplo: permissão para ler e descrever segredos individuais

exemplo Ler e descrever um segredo

É possível conceder acesso a um segredo anexando a seguinte política a uma identidade.

JSON
{
"Version":"2012-10-17",		 	 	 
"Statement": [
  {
    "Effect": "Allow",
    "Action": [
      "secretsmanager:GetSecretValue",
      "secretsmanager:DescribeSecret"
      ],
      "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName-AbCdEf"
    }
]
}

Exemplo: permissão para recuperar um grupo de valores de segredos em um lote

exemplo Ler um grupo de segredos em um lote

É possível conceder acesso para recuperar um grupo de segredos em uma chamada de API em lote anexando a seguinte política a uma identidade. A política restringe o chamador para que ele só possa recuperar os segredos especificados por SecretARN1, SecretARN2 e SecretARN3, mesmo que a chamada em lote inclua outros segredos. Se o chamador também solicitar outros segredos na chamada de API em lote, o Secrets Manager não os retornará. Para obter mais informações, consulte BatchGetSecretValue..

JSON
{
"Version":"2012-10-17",		 	 	 
"Statement": [
{
  "Effect": "Allow",
  "Action": [
    "secretsmanager:BatchGetSecretValue",
    "secretsmanager:ListSecrets"
  ],
  "Resource": "*"
},
{
  "Effect": "Allow",
  "Action": [
    "secretsmanager:GetSecretValue"
  ],
  "Resource": [
    "arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName1-AbCdEf",
    "arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName2-AbCdEf",
    "arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName3-AbCdEf"
    ]
}
]
}

Exemplo: curingas

É possível usar curingas para incluir um conjunto de valores em um elemento de política.

exemplo Acessar todos os segredos em um caminho

A política a seguir concede acesso para recuperar todos os segredos com um nome começando por “TestEnv/”.

JSON
{
    "Version":"2012-10-17",		 	 	 
    "Statement": {
        "Effect": "Allow",
        "Action": "secretsmanager:GetSecretValue",
        "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:TestEnv/*"
    }
}
exemplo Acessar metadados em todos os segredos

A política a seguir concede DescribeSecret e permissões, começando com List: ListSecrets e ListSecretVersionIds.

JSON
{
"Version":"2012-10-17",		 	 	 
"Statement": {
"Effect": "Allow",
"Action": [
  "secretsmanager:DescribeSecret",
  "secretsmanager:List*"
],
"Resource": "*"
}
}
exemplo Correspondência de nome de segredo

A política a seguir concede todas as permissões do Secrets Manager para um segredo por nome. Para usar essa política, consulte Políticas baseadas em identidade.

Para corresponder um nome de segredo, crie o ARN para o segredo reunindo a região, o ID da conta, o nome do segredo e o caractere curinga (?) para corresponder caracteres aleatórios individuais. O Secrets Manager anexa seis caracteres aleatórios a nomes de segredos como parte do ARN para que você possa usar esse curinga para corresponder a esses caracteres. Se você usar a sintaxe "another_secret_name-*", o Secrets Manager corresponderá não apenas ao segredo previsto com os seis caracteres aleatórios, mas também a "another_secret_name-<anything-here>a1b2c3".

Como é possível prever todas as partes do ARN de um segredo, exceto os seis caracteres aleatórios, o uso da sintaxe '??????' do caractere curinga permite que você conceda com segurança permissões a um segredo que ainda não existe. Mas observe que, se você excluir o segredo e recriá-lo com o mesmo nome, o usuário receberá automaticamente permissão para o novo segredo, mesmo que os 6 caracteres tenham sido alterados.

JSON
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "secretsmanager:*",
            "Resource": [
                "arn:aws:secretsmanager:us-east-1:123456789012:secret:a_specific_secret_name-a1b2c3",
                "arn:aws:secretsmanager:us-east-1:123456789012:secret:another_secret_name-??????"
            ]
        }
    ]
}

Exemplo: Permissão para criar segredos

Para conceder permissões a um usuário para criar um segredo, recomendamos anexar uma política de permissões a um grupo do IAM ao qual o usuário pertence. Consulte Grupos de usuários do IAM.

exemplo Criar segredos

A política a seguir concede permissão para a criação de segredos e a visualização de uma lista de segredos. Para usar essa política, consulte Políticas baseadas em identidade.

JSON
{
"Version":"2012-10-17",		 	 	 
"Statement": [
{
  "Effect": "Allow",
  "Action": [
    "secretsmanager:CreateSecret",
    "secretsmanager:ListSecrets"
  ],
  "Resource": "*"
}
]
}

Exemplo: negar uma chave do AWS KMS específica para criptografar segredos

Importante

Para negar uma chave gerenciada pelo cliente, recomendamos que você restrinja o acesso usando uma política de chaves ou uma concessão de chaves. Para obter mais informações, consulte Autenticação e controle de acesso para o AWS KMS no Guia do desenvolvedor do AWS Key Management Service.

exemplo Negar a chave gerenciada pela AWSaws/secretsmanager

A política a seguir nega o uso da Chave gerenciada pela AWS aws/secretsmanager para criar ou atualizar segredos. Essa política exige que os segredos sejam criptografados usando uma chave gerenciada pelo cliente. A política inclui duas instruções:

  1. A primeira instrução, Sid: "RequireCustomerManagedKeysOnSecrets", nega solicitações para criar ou atualizar segredos usando a Chave gerenciada pela AWS aws/secretsmanager.

  2. A segunda instrução, Sid: "RequireKmsKeyIdParameterOnCreate", nega solicitações para criar segredos que não incluam uma chave KMS, pois o Secrets Manager usaria, por padrão, a Chave gerenciada pela AWS aws/secretsmanager.

JSON
{
"Version":"2012-10-17",		 	 	 
"Statement": [
  {
      "Sid": "RequireCustomerManagedKeysOnSecrets",
      "Effect": "Deny",
      "Action": [
          "secretsmanager:CreateSecret",
          "secretsmanager:UpdateSecret"
      ],
      "Resource": "*",
      "Condition": {
          "StringLikeIfExists": {
              "secretsmanager:KmsKeyArn": "<key_ARN_of_the_AWS_managed_key>"
          }
      }
  },
  {
      "Sid": "RequireKmsKeyIdParameterOnCreate",
      "Effect": "Deny",
      "Action": "secretsmanager:CreateSecret",
      "Resource": "*",
      "Condition": {
          "Null": {
              "secretsmanager:KmsKeyArn": "true"
          }
      }
  }
]
}