Exemplos de política de permissões - AWS Secrets Manager

Exemplos de política de permissões

Uma política de permissões é um texto estruturado JSON. Consulte Estrutura de documento de política JSON.

As políticas de permissões que você anexa a recursos e identidades são muito semelhantes. Alguns elementos que você inclui em uma política de acesso a segredos incluem:

  • Principal: a quem conceder acesso. Consulte Especificar um elemento principal no Manual do usuário do IAM. Ao anexar uma política a uma identidade, você não inclui um elemento Principal na política.

  • Action: o que eles podem fazer. Consulte Ações do Secrets Manager.

  • Resource: quais segredos eles podem acessar. Consulte Recursos do Secrets Manager.

    O caractere curinga (*) tem significados diferentes, que dependem de onde a política será anexada:

    • Em uma política anexada a um segredo, * significa que a política se aplica a este segredo.

    • Em uma política anexada a uma identidade, * significa que a política se aplica a todos os recursos, incluindo segredos, na conta.

Para anexar uma política a um segredo, consulte Anexar uma política de permissões a um segredo.

Para anexar uma política a uma identidade, consulte Anexar uma política de permissões a uma identidade.

Exemplo: Permissão para recuperar valores de segredos

Para conceder permissão para recuperar valores de segredos, você pode 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 Anexar uma política de permissões a um segredo e Anexar uma política de permissões a uma identidade.

Os exemplos a seguir mostram duas formas diferentes de conceder acesso a um segredo. O primeiro exemplo é uma política baseada em recursos que pode ser anexada a um segredo. Esse exemplo é útil quando você quer conceder acesso a um único segredo a vários usuários ou funções. O segundo exemplo é uma política baseada em identidades que pode ser anexada a um usuário ou função no IAM. Esse exemplo é útil quando você deseja conceder acesso a um grupo do IAM.

exemplo Ler um segredo (anexar a um segredo)

É possível conceder acesso a um segredo anexando a seguinte política ao segredo. Para usar essa política, consulte Anexar uma política de permissões a um segredo.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::AccountId:role/EC2RoleToAccessSecrets" }, "Action": "secretsmanager:GetSecretValue", "Resource": "*" } ] }

exemplo Ler um segredo (anexar a uma identidade)

É possível conceder acesso a um segredo anexando a seguinte política a uma identidade. Para usar essa política, consulte Anexar uma política de permissões a uma identidade. Se você anexar essa política à função EC2RoleToAccessSecrets, ela concederá as mesmas permissões que a política anterior.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Resource": "SecretARN" } ] }

Exemplo: curingas

Você pode usar curingas para incluir um conjunto de valores em um elemento de política.

exemplo Acessar todos os segredos em um caminho (anexar à identidade)

A política a seguir concede acesso para recuperar todos os segredos com um nome começando por “TestEnv/”. Para usar essa política, consulte Anexar uma política de permissões a uma identidade.

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:Region:AccountId:secret:TestEnv/*" } }

exemplo Acessar metadados em todos os segredos (anexar à identidade)

A política a seguir concede DescribeSecret e permissões, começando com List: ListSecrets e ListSecretVersionIds. Para usar essa política, consulte Anexar uma política de permissões a uma identidade.

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

exemplo Corresponder nome do segredo (anexar à identidade)

A política a seguir concede todas as permissões do Secrets Manager para um segredo por nome. Para usar essa política, consulte Anexar uma política de permissões a uma 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 você pode 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:Region:AccountId:secret:a_specific_secret_name-a1b2c3", "arn:aws:secretsmanager:Region:AccountId: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 (anexar à identidade)

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 Anexar uma política de permissões a uma identidade.

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

Exemplo: Permissões e VPCs

Se você precisar acessar o Secrets Manager de uma VPC, verifique se as solicitações para o Secrets Manager vêm da VPC ao incluir uma condição nas políticas de permissões. Para obter mais informações, consulte Condições do endpoint da VPC e Uso de um endpoint da VPC do AWS Secrets Manager.

Certifique-se de que as solicitações para acessar o segredo de outros serviços da AWS também venham da VPC. Caso contrário, essa política negará a eles o acesso.

exemplo Exigir que as solicitações sejam enviadas por meio de um endpoint da VPC (anexado ao segredo)

A política a seguir permite que um usuário execute operações do Secrets Manager somente quando a solicitação é fornecida por meio do endpoint do VPC vpce-1234a5678b9012c. Para usar essa política, consulte Anexar uma política de permissões a um segredo.

{ "Id": "example-policy-1", "Version": "2012-10-17", "Statement": [ { "Sid": "RestrictGetSecretValueoperation", "Effect": "Deny", "Principal": "*", "Action": "secretsmanager:GetSecretValue", "Resource": "*", "Condition": { "StringNotEquals": { "aws:sourceVpce": "vpce-1234a5678b9012c" } } } ] }

exemplo Exigir que as solicitações sejam provenientes de uma VPC (anexar ao segredo)

A política a seguir permite que os comandos criem e gerenciem segredos somente quando eles são provenientes da vpc-12345678. Além disso, a política permite operações que usam o acesso ao valor criptografado do segredo somente quando as solicitações são recebidas de vpc-2b2b2b2b. Você poderá usar uma política como essa se um aplicativo for executado em uma VPC, mas você usa uma segunda VPC isolada para funções de gerenciamento. Para usar essa política, consulte Anexar uma política de permissões a um segredo.

{ "Id": "example-policy-2", "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAdministrativeActionsfromONLYvpc-12345678", "Effect": "Deny", "Principal": "*", "Action": [ "secretsmanager:Create*", "secretsmanager:Put*", "secretsmanager:Update*", "secretsmanager:Delete*", "secretsmanager:Restore*", "secretsmanager:RotateSecret", "secretsmanager:CancelRotate*", "secretsmanager:TagResource", "secretsmanager:UntagResource" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:sourceVpc": "vpc-12345678" } } }, { "Sid": "AllowSecretValueAccessfromONLYvpc-2b2b2b2b", "Effect": "Deny", "Principal": "*", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:sourceVpc": "vpc-2b2b2b2b" } } } ] }

Exemplo: Controlar o acesso a segredos usando etiquetas

Você pode usar etiquetas para controlar o acesso aos segredos. O uso de etiquetas para controlar permissões é útil em ambientes que estão crescendo rapidamente e ajuda em situações em que o gerenciamento de políticas se torna um problema. Uma estratégia é anexar etiquetas a segredos e, em seguida, conceder permissões a uma identidade quando um segredo tem uma etiqueta específica.

exemplo Permitir acesso a segredos com uma etiqueta específica (anexar a uma identidade)

A política a seguir permite DescribeSecret em segredos com uma etiqueta com a chave “ServerName” e o valor “ServerABC”. Para usar essa política, consulte Anexar uma política de permissões a uma identidade.

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "secretsmanager:DescribeSecret", "Resource": "*", "Condition": { "StringEquals": { "secretsmanager:ResourceTag/ServerName": "ServerABC" } } } }

Exemplo: Limitar o acesso a identidades com etiquetas que correspondam às etiquetas dos segredos

Uma estratégia é anexar etiquetas a segredos e a identidades do IAM. Em seguida, crie políticas de permissões para permitir operações quando a etiqueta da identidade corresponder à etiqueta do segredo. Para obter um tutorial completo, consulte Definir permissões para acessar segredos com base em etiquetas.

O uso de etiquetas para controlar permissões é útil em ambientes que estão crescendo rapidamente e ajuda em situações em que o gerenciamento de políticas se torna um problema. Para obter mais informações, consulte O que é ABAC para a AWS?

exemplo Permitir acesso a funções que têm as mesmas etiquetas que os segredos (anexar a um segredo)

A política a seguir só concederá GetSecretValue à conta 123456789012 se a etiqueta AccessProject tiver o mesmo valor para o segredo e para a função. Para usar essa política, consulte Anexar uma política de permissões a um segredo.

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": { "AWS": "123456789012" }, "Condition": { "StringEquals": { "aws:ResourceTag/AccessProject": "${ aws:PrincipalTag/AccessProject }" } }, "Action": "secretsmanager:GetSecretValue", "Resource": "*" } }

Exemplo: entidade principal de serviço

Se a política de recurso anexada ao seu segredo incluir uma entidade principal de serviço da AWS, recomendamos o uso das chaves globais de condição aws:SourceArn e aws:SourceAccount. O ARN e os valores da conta só são incluídos no contexto de autorização quando uma solicitação chega ao Secrets Manager diretamente de outro serviço da AWS. Essa combinação de condições evita um potencial confused deputy scenario (cenário de substituto confuso).

Se um ARN de recurso incluir caracteres que não sejam permitidos em uma política de recurso, você não poderá usar esse ARN de recurso no valor da chave de condição aws:SourceArn. Em vez disso, use a chave de condição aws:SourceAccount. Para obter mais informações, consulte os requisitos do IAM.

Normalmente as entidades principais de serviço não são usadas como entidades principais em uma política anexada a um segredo, mas alguns dos serviços da AWS exigem isso. Para obter informações sobre as políticas de recursos que um serviço exige que você anexe a um segredo, consulte a documentação do serviço.

exemplo Permitir que um serviço acesse um segredo usando uma entidade principal de serviço (anexar a um segredo)

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "service-name.amazonaws.com" ] }, "Action": "secretsmanager:GetSecretValue", "Resource": "*", "Condition": { "ArnLike": { "aws:sourceArn": "arn:aws:service-name::123456789012:*" }, "StringEquals": { "aws:sourceAccount": "123456789012" } } } ] }