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á.
# 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html). 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
É 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html). Outros serviços aos quais é possível anexar perfis incluem o [Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/c-getting-started-using-spectrum.html), o [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-permissions.html) e o [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html).
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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html).
É 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.
**Topics**
+ [Exemplo: permissão para recuperar valores de segredos individuais](#auth-and-access_examples_identity_read)
+ [Exemplo: permissão para ler e descrever segredos individuais](#auth-and-access_examples-read-and-describe)
+ [Exemplo: permissão para recuperar um grupo de valores de segredos em um lote](#auth-and-access_examples_batch)
+ [Exemplo: curingas](#auth-and-access_examples_wildcard)
+ [Exemplo: Permissão para criar segredos](#auth-and-access_examples_create)
+ [Exemplo: negar uma AWS KMS chave específica para criptografar segredos](#auth-and-access_examples_kmskey)
## 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html). Para obter informações sobre como anexar uma política, consulte [Políticas baseadas em recursos](auth-and-access_resource-policies.md) e [Políticas baseadas em identidade](#auth-and-access_iam-policies).
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](#auth-and-access_examples_batch).
**Example 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. \$1
****
```
{
"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
**Example Ler e descrever um segredo**
É possível conceder acesso a um segredo anexando a seguinte política a uma identidade.
****
```
{
"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
**Example 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*,, e *SecretARN2**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`.](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_BatchGetSecretValue.html) .
****
```
{
"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.
**Example Acessar todos os segredos em um caminho**
A política a seguir concede acesso para recuperar todos os segredos com um nome que começa com "*TestEnv/*”.
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:TestEnv/*"
}
}
```
**Example Acessar metadados em todos os segredos**
A política a seguir concede `DescribeSecret` e permissões, começando com `List`: `ListSecrets` e `ListSecretVersionIds`.
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"secretsmanager:DescribeSecret",
"secretsmanager:List*"
],
"Resource": "*"
}
}
```
**Example 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](#auth-and-access_iam-policies).
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-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.
****
```
{
"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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html).
**Example 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](#auth-and-access_iam-policies).
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:CreateSecret",
"secretsmanager:ListSecrets"
],
"Resource": "*"
}
]
}
```
## Exemplo: negar uma AWS KMS chave 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](https://docs.aws.amazon.com/kms/latest/developerguide/control-access.html) no *Guia do desenvolvedor do AWS Key Management Service *.
**Example Negar a chave AWS gerenciada `aws/secretsmanager`**
A política a seguir nega o uso do 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 declaração,`Sid: "RequireCustomerManagedKeysOnSecrets"`, nega solicitações para criar ou atualizar segredos usando o. Chave gerenciada pela AWS `aws/secretsmanager`
1. A segunda declaração,`Sid: "RequireKmsKeyIdParameterOnCreate"`, nega solicitações para criar segredos que não incluam uma chave KMS, porque o Secrets Manager usaria por padrão o. Chave gerenciada pela AWS `aws/secretsmanager`
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RequireCustomerManagedKeysOnSecrets",
"Effect": "Deny",
"Action": [
"secretsmanager:CreateSecret",
"secretsmanager:UpdateSecret"
],
"Resource": "*",
"Condition": {
"StringLikeIfExists": {
"secretsmanager:KmsKeyArn": ""
}
}
},
{
"Sid": "RequireKmsKeyIdParameterOnCreate",
"Effect": "Deny",
"Action": "secretsmanager:CreateSecret",
"Resource": "*",
"Condition": {
"Null": {
"secretsmanager:KmsKeyArn": "true"
}
}
}
]
}
```