Exemplos de políticas baseadas em identidade do Amazon Aurora

Por padrão, os conjuntos de permissões e perfis não têm permissão para criar nem modificar recursos do Aurora. Eles também não podem executar tarefas usando o AWS Management Console, a AWS CLI ou AWS uma API. Um administrador deve criar políticas do IAM que concedam aos conjuntos de permissões e perfis permissão para executar operações de API específicas nos recursos especificados de que precisam. Depois, o administrador deve anexar essas políticas aos conjuntos de permissões e perfis que exigem essas permissões.

Para saber como criar uma política baseada em identidade do IAM usando esses exemplos de documentos de política JSON, consulte Criar políticas na guia JSON no Guia do usuário do IAM.

Práticas recomendadas de políticas

As políticas baseadas em identidade determinam se alguém pode criar, acessar ou excluir recursos do Amazon RDS em sua conta. Essas ações podem incorrer em custos para a Conta da AWS. Ao criar ou editar políticas baseadas em identidade, siga estas diretrizes e recomendações:

• Comece com as políticas gerenciadas pela AWS e avance para as permissões de privilégio mínimo: para começar a conceder permissões a seus usuários e workloads, use as políticas gerenciadas pela AWS que concedem permissões para muitos casos de uso comuns. Eles estão disponíveis na sua Conta da AWS. Recomendamos que você reduza ainda mais as permissões definindo políticas gerenciadas pelo cliente da AWS específicas para seus casos de uso. Para obter mais informações, consulte Políticas gerenciadas pela AWS ou Políticas gerenciadas pela AWS para funções de trabalho no Guia do usuário do IAM.

• Aplique permissões de privilégio mínimo: ao definir permissões com as políticas do IAM, conceda apenas as permissões necessárias para executar uma tarefa. Você faz isso definindo as ações que podem ser executadas em recursos específicos sob condições específicas, também conhecidas como permissões de privilégio mínimo. Para obter mais informações sobre como usar o IAM para aplicar permissões, consulte Políticas e permissões no IAM no Guia do usuário do IAM.

• Use condições nas políticas do IAM para restringir ainda mais o acesso: você pode adicionar uma condição às políticas para limitar o acesso a ações e recursos. Por exemplo, você pode escrever uma condição de política para especificar que todas as solicitações devem ser enviadas usando SSL. Você também pode usar condições para conceder acesso a ações de serviço, se elas forem usadas por meio de um AWS service (Serviço da AWS) específico, como o AWS CloudFormation. Para obter mais informações, consulte Elementos de política JSON do IAM: Condition no Manual do usuário do IAM.

• Use o IAM Access Analyzer para validar suas políticas do IAM a fim de garantir permissões seguras e funcionais: o IAM Access Analyzer valida as políticas novas e existentes para que elas sigam a linguagem de política do IAM (JSON) e as práticas recomendadas do IAM. O IAM Access Analyzer oferece mais de 100 verificações de política e recomendações acionáveis para ajudar você a criar políticas seguras e funcionais. Para obter mais informações, consulte Validação de políticas do IAM Access Analyzer no Guia do usuário do IAM.

• Exija autenticação multifator (MFA): se você tiver um cenário que exija usuários raiz ou usuários do IAM em sua conta, ative a MFA para obter segurança adicional. Para exigir a MFA quando as operações de API forem chamadas, adicione condições de MFA às suas políticas. Para obter mais informações, consulte Configuração de acesso à API protegido por MFA no Guia do usuário do IAM.

Para obter mais informações sobre as práticas recomendadas do IAM, consulte Práticas recomendadas de segurança no IAM no Guia do usuário do IAM.

Usar o console do Aurora

Para acessar o console do Amazon Aurora, você deve ter um conjunto mínimo de permissões. Essas permissões devem permitir que você liste e visualize detalhes sobre os recursos do Amazon Aurora em sua Conta da AWS. Se você criar uma política baseada em identidade que seja mais restritiva que as permissões mínimas necessárias, o console não funcionará como pretendido para entidades (usuários ou perfis) com essa política.

Não é necessário conceder permissões mínimas do console para usuários que fazem chamadas somente à AWS CLI ou à API do AWS. Em vez disso, permita o acesso somente às ações que correspondem à operação da API que você está tentando executar.

Para garantir que essas entidades ainda possam usar o console do Aurora, anexe também a seguinte política gerenciada pela AWS às entidades.

AmazonRDSReadOnlyAccess

Para obter mais informações, consulte Adicionar permissões a um usuário no Guia do usuário do IAM.

Permitir que os usuários visualizem suas próprias permissões

Este exemplo mostra como você pode criar uma política que permite que os usuários do IAM visualizem as políticas gerenciadas e em linha anexadas a sua identidade de usuário. Essa política inclui permissões para concluir essa ação no console ou de forma programática usando a AWS CLI ou a API da AWS.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ViewOwnUserInfo",
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:ListGroupsForUser",
                "iam:ListAttachedUserPolicies",
                "iam:ListUserPolicies",
                "iam:GetUser"
            ],
            "Resource": ["arn:aws:iam::*:user/${aws:username}"]
        },
        {
            "Sid": "NavigateInConsole",
            "Effect": "Allow",
            "Action": [
                "iam:GetGroupPolicy",
                "iam:GetPolicyVersion",
                "iam:GetPolicy",
                "iam:ListAttachedGroupPolicies",
                "iam:ListGroupPolicies",
                "iam:ListPolicyVersions",
                "iam:ListPolicies",
                "iam:ListUsers"
            ],
            "Resource": "*"
        }
    ]
}

Permitir que um usuário crie instâncias de Bancos de Dados em uma conta da AWS

Veja a seguir um exemplo de política que permite ao usuário com o ID 123456789012 criar instâncias de Bancos de Dados para a sua conta da AWS. A política exige que o nome da nova instância de banco de dados comece com test. A nova instância de banco de dados também deve usar o mecanismo de banco de dados MySQL e a classe de instância de banco de dados db.t2.micro. Além disso, a nova instância de banco de dados deve usar um grupo de opções e um grupo de parâmetros de banco de dados que começa com default e deve usar o grupo de sub-redes default.

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Sid": "AllowCreateDBInstanceOnly",
         "Effect": "Allow",
         "Action": [
            "rds:CreateDBInstance"
         ],
         "Resource": [
            "arn:aws:rds:*:123456789012:db:test*",
            "arn:aws:rds:*:123456789012:og:default*",
            "arn:aws:rds:*:123456789012:pg:default*",
            "arn:aws:rds:*:123456789012:subgrp:default"
         ],
         "Condition": {
            "StringEquals": {
               "rds:DatabaseEngine": "mysql",
               "rds:DatabaseClass": "db.t2.micro"
            }
         }
      }
   ]
}

A política inclui uma única instrução que especifica as seguintes permissões para o usuário do :

• A política permite que o usuário crie uma instância de banco de dados usando a operação de API CreateDBInstance (isso também se aplica ao comando create-db-instance da AWS CLI e ao AWS Management Console).

• O elemento Resource especifica que o usuário pode realizar ações em ou com recursos. Você especifica recursos usando um nome de recurso da Amazon (ARN). O ARN inclui o nome do serviço ao qual o recurso pertence (rds), a região da AWS (* indica qualquer região neste exemplo), o número de conta da AWS (123456789012 é o número de conta neste exemplo) e o tipo de recurso. Para obter mais informações sobre como criar ARNs, consulte Trabalhar com nomes de recurso da Amazon (ARNs) no Amazon RDS.

  O elemento Resource neste exemplo especifica as restrições da política a seguir em recursos para o usuário:

  • O identificador de instância de banco de dados para a nova instância de banco de dados deve começar com test (por exemplo, testCustomerData1, test-region2-data).

  • O grupo de opções para a nova instância de banco de dados deve começar com default.

  • O grupo de parâmetros de banco de dados para a nova instância de banco de dados deve começar com default.

  • O grupo de sub-redes para a nova instância de banco de dados deve ser o grupo de sub-redes default.

• O elemento Condition especifica que o mecanismo de banco de dados deve ser MySQL e a classe da instância de banco de dados deve ser db.t2.micro. O elemento Condition especifica as condições quando uma política deve entrar em vigor. Você pode adicionar permissões ou restrições usando o elemento Condition. Para obter mais informações sobre como especificar condições, consulte Chaves de condição de políticas do Aurora. Este exemplo especifica condições rds:DatabaseEngine e rds:DatabaseClass. Para obter informações sobre valores de condição válidos para o rds:DatabaseEngine, consulte a lista no parâmetro Engine em CreateDBInstance. Para obter informações sobre os valores de condição válidos para rds:DatabaseClass, consulte Mecanismos de banco de dados compatíveis para classes de instância de banco de dados.

A política não especifica o elemento Principal porque, em uma política baseada em identidade, não se especifica o principal que obtém as permissões. Quando você anexar uma política um usuário, o usuário será o principal implícito. Quando você anexa uma política de permissão a um perfil do IAM, o principal identificado na política de confiança do perfil obtém as permissões.

Para obter uma lista de ações do Aurora, consulte Ações definidas pelo Amazon RDS na Referência de autorização do serviço.

Permissões necessárias para usar o console

Para um usuário trabalhar com o console, esse usuário deve ter um conjunto de permissões mínimo. Essas permissões permitem que o usuário descreva os recursos do Amazon Aurora para a conta da AWS e forneça outras informações relacionadas, inclusive informações de segurança e rede do Amazon EC2.

Se você criar uma política do IAM que seja mais restritiva que as permissões mínimas necessárias, o console não funcionará como pretendido para os usuários com essa política do IAM. Para garantir que esses usuários ainda consigam usar o console, associe também a política gerenciada AmazonRDSReadOnlyAccess ao usuário, conforme descrito em Gerenciamento do acesso usando políticas.

Não é necessário conceder permissões mínimas do console para usuários que fazem chamadas somente à AWS CLI ou à API do Amazon RDS.

A seguinte política concede acesso completo a todos os recursos do Amazon Aurora para a conta raiz da AWS:

AmazonRDSFullAccess             
         

Permitir que um usuário execute qualquer ação de descrição em qualquer recurso do RDS

A seguinte política de permissões concede permissões a um usuário para executar todas as ações que começam com Describe. Essas ações mostram informações sobre um recurso do RDS, como uma instância de banco de dados. O caractere curinga (*) no elemento Resource indica que as ações são permitidas para todos os recursos do Amazon Aurora que pertencem à conta.

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Sid": "AllowRDSDescribe",
         "Effect": "Allow",
         "Action": "rds:Describe*",
         "Resource": "*"
      }
   ]
}

Permitir que um usuário crie uma instância de banco de dados que usa o grupo de parâmetros de banco de dados e o grupo de sub-redes especificados.

A seguinte política de permissões concede permissões para permitir que um usuário crie apenas uma instância de banco de dados que deve usar o grupo de parâmetros de banco de dados mydbpg e o grupo de sub-rede de banco de dados mydbsubnetgroup.

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Sid": "VisualEditor0",
         "Effect": "Allow",
         "Action": "rds:CreateDBInstance",
         "Resource": [
            "arn:aws:rds:*:*:pg:mydbpg",
            "arn:aws:rds:*:*:subgrp:mydbsubnetgroup"
         ]
      }
   ]
}

Conceder permissão para ações em um recurso com uma tag específica com dois valores diferentes

Você pode usar condições em sua política baseada em identidade para controlar o acesso aos recursos do Aurora com base em tags. A política a seguir concede permissão para realizar a operação de API CreateDBSnapshot em instâncias de banco de dados com a etiqueta stage definida como development ou test.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"AllowAnySnapshotName",
         "Effect":"Allow",
         "Action":[
            "rds:CreateDBSnapshot"
         ],
         "Resource":""arn:aws:rds:*:123456789012:snapshot:*""
      },
      {
         "Sid":"AllowDevTestToCreateSnapshot",
         "Effect":"Allow",
         "Action":[
            "rds:CreateDBSnapshot"
         ],
         "Resource":""arn:aws:rds:*:123456789012:db:*"",
         "Condition":{
            "StringEquals":{
                "rds:db-tag/stage":[
                  "development",
                  "test"
               ]
            }
         }
      }
   ]
}

A política a seguir concede permissão para realizar a operação de API ModifyDBInstance em instâncias de banco de dados com a etiqueta stage definida como development ou test.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"AllowChangingParameterOptionSecurityGroups",
         "Effect":"Allow",
         "Action":[
            "rds:ModifyDBInstance"
         ],
         "Resource":" [
            "arn:aws:rds:*:123456789012:pg:*",
            "arn:aws:rds:*:123456789012:secgrp:*",
            "arn:aws:rds:*:123456789012:og:*"
         ]
      },
      {
         "Sid":"AllowDevTestToModifyInstance",
         "Effect":"Allow",
         "Action":[
            "rds:ModifyDBInstance"
         ],
         "Resource":"arn:aws:rds:*:123456789012:db:*",
         "Condition":{
            "StringEquals":{
                "rds:db-tag/stage":[
                  "development",
                  "test"
               ]
            }
         }
      }
   ]
}
            
            

Impedir que um usuário exclua uma instância de banco de dados

A seguinte política de permissões concede permissões para impedir que um usuário exclua uma instância de banco de dados específica. Por exemplo, você pode querer negar a capacidade de excluir suas instâncias de banco de dados de produção para qualquer usuário que não seja um administrador.

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Sid": "DenyDelete1",
         "Effect": "Deny",
         "Action": "rds:DeleteDBInstance",
         "Resource": "arn:aws:rds:us-west-2:123456789012:db:my-mysql-instance"
      }
   ]
}

Negar todo o acesso a um recurso

É possível negar acesso explicitamente a um recurso. As políticas de negação têm precedência sobre as políticas de permissão. A política a seguir nega explicitamente a um usuário a capacidade de gerenciar um recurso:

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Effect": "Deny",
         "Action": "rds:*",
         "Resource": "arn:aws:rds:us-east-1:123456789012:db:mydb"
      }
   ]
}

Políticas de exemplo: usar chaves de condição

Os seguintes exemplos mostram como você pode usar chaves de condição em políticas de permissões do IAM do Amazon Aurora.

Exemplo 1: conceder permissão para criar uma instância de banco de dados que usa um mecanismo de banco de dados específico e não é MultiAZ

A seguinte política usa uma chave de condição do RDS e permite que um usuário crie apenas instâncias de banco de dados que usam o mecanismo de banco de dados MySQL e não use o MultiAZ. O elemento Condition indica a exigência de que o mecanismo de banco de dados seja MySQL.

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Sid": "AllowMySQLCreate",
         "Effect": "Allow",
         "Action": "rds:CreateDBInstance",
         "Resource": "*",
         "Condition": {
            "StringEquals": {
               "rds:DatabaseEngine": "mysql"
            },
            "Bool": {
               "rds:MultiAz": false
            }
         }
      }
   ]
}

Exemplo 2: negar explicitamente a permissão para criar instâncias de bancos de dados para determinadas classes de instância de banco de dados e criar instâncias de bancos de dados que usam IOPS provisionadas

A seguinte política nega explicitamente a permissão para criar instâncias de bancos de dados que usam as classes de instância de banco de dados r3.8xlarge e m4.10xlarge, que são as classes de instância de banco de dados maiores e mais caras. Essa política também impede que os usuários criem instâncias de banco de dados que usam IOPS provisionadas, que resultam em custos adicionais.

A negação explícita da permissão substitui quaisquer outras permissões concedidas. Isso garante que as identidades não obtenham acidentalmente permissão que você nunca deseja conceder.

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Sid": "DenyLargeCreate",
         "Effect": "Deny",
         "Action": "rds:CreateDBInstance",
         "Resource": "*",
         "Condition": {
            "StringEquals": {
               "rds:DatabaseClass": [
                  "db.r3.8xlarge",
                  "db.m4.10xlarge"
               ]
            }
         }
      },
      {
         "Sid": "DenyPIOPSCreate",
         "Effect": "Deny",
         "Action": "rds:CreateDBInstance",
         "Resource": "*",
         "Condition": {
            "NumericNotEquals": {
               "rds:Piops": "0"
            }
         }
      }
   ]
}

Exemplo 3: limitar o conjunto de chaves de tag e valores que podem ser usados para identificar um recurso

A política a seguir usa uma chave de condição do RDS e permite a adição de uma tag com a chave stage a ser adicionada a um recurso com os valores test, qa e production.

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Effect": "Allow",
         "Action": [
            "rds:AddTagsToResource",
            "rds:RemoveTagsFromResource"
         ],
         "Resource": "*",
         "Condition": {
            "streq": {
               "rds:req-tag/stage": [
                  "test",
                  "qa",
                  "production"
               ]
            }
         }
      }
   ]
}

Especificar condições: usar tags personalizadas

O Amazon Aurora oferece suporte para especificar condições em uma política do IAM usando tags personalizadas.

Por exemplo, suponha que você adicione uma tag chamada environment às suas instâncias de banco de dados com valores como beta, staging, production e assim por diante. Se fizer isso, você poderá criar uma política que restrinja determinados usuários a instâncias de banco de dados com base no valor da tag environment.

nota

Os identificadores de tags personalizados diferenciam maiúsculas de minúsculas.

A tabela a seguir lista os identificadores de tags do RDS que você pode usar em um elemento Condition.

Identificador de tag do RDS	Aplica-se a
db-tag	Instâncias de bancos de dados, incluindo réplicas de leitura
snapshot-tag	DB snapshots
ri-tag	Instâncias de bancos de dados reservadas
og-tag	Grupos de opções de banco de dados
pg-tag	Grupos de parâmetros do banco de dados
subgrp-tag	Grupos de sub-redes de banco de dados
es-tag	Assinaturas de eventos
cluster-tag	clusters de banco de dados
cluster-pg-tag	Grupos de parâmetros de cluster de banco de dados
cluster-snapshot-tag	Snapshots de cluster de banco de dados

A sintaxe de uma condição de tag personalizada é a seguinte:

"Condition":{"StringEquals":{"rds:rds-tag-identifier/tag-name": ["value"]} }

Por exemplo, o seguinte elemento Condition se aplica a instâncias de banco de dados com uma tag environment e um valor de tag de production.

"Condition":{"StringEquals":{"rds:db-tag/environment": ["production"]} }

Para obter informações sobre como criar tags, consulte Marcar recursos do Amazon RDS.

Importante

Se você gerenciar o acesso aos recursos do RDS usando tags, recomendamos proteger o acesso às tags para os seus recursos do RDS. Você pode gerenciar o acesso a tags, criando políticas para as ações AddTagsToResource e RemoveTagsFromResource. Por exemplo, a seguinte política nega aos usuários a capacidade de adicionar ou remover tags para todos os recursos. Você pode então criar políticas para permitir que usuários específicos adicionem ou removam tags.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"DenyTagUpdates",
         "Effect":"Deny",
         "Action":[
            "rds:AddTagsToResource",
            "rds:RemoveTagsFromResource"
         ],
         "Resource":"*"
      }
   ]
}

Para obter uma lista de ações do Aurora, consulte Ações definidas pelo Amazon RDS na Referência de autorização do serviço.

Políticas de exemplo: usar tags personalizadas

Os seguintes exemplos mostram como você pode usar tags personalizadas em políticas de permissões do IAM do Amazon Aurora. Para obter mais informações sobre como adicionar tags a um recurso do Amazon Aurora, consulte Trabalhar com nomes de recurso da Amazon (ARNs) no Amazon RDS.

nota

Todos os exemplos usam a região us-west-2 e contêm IDs de conta fictícios.

Exemplo 1: conceder permissão para ações em um recurso com uma tag específica com dois valores diferentes

A política a seguir concede permissão para realizar a operação de API CreateDBSnapshot em instâncias de banco de dados com a etiqueta stage definida como development ou test.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"AllowAnySnapshotName",
         "Effect":"Allow",
         "Action":[
            "rds:CreateDBSnapshot"
         ],
         "Resource":""arn:aws:rds:*:123456789012:snapshot:*""
      },
      {
         "Sid":"AllowDevTestToCreateSnapshot",
         "Effect":"Allow",
         "Action":[
            "rds:CreateDBSnapshot"
         ],
         "Resource":""arn:aws:rds:*:123456789012:db:*"",
         "Condition":{
            "StringEquals":{
                "rds:db-tag/stage":[
                  "development",
                  "test"
               ]
            }
         }
      }
   ]
}

A política a seguir concede permissão para realizar a operação de API ModifyDBInstance em instâncias de banco de dados com a etiqueta stage definida como development ou test.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"AllowChangingParameterOptionSecurityGroups",
         "Effect":"Allow",
         "Action":[
            "rds:ModifyDBInstance"
         ],
         "Resource":" [
            "arn:aws:rds:*:123456789012:pg:*",
            "arn:aws:rds:*:123456789012:secgrp:*",
            "arn:aws:rds:*:123456789012:og:*"
         ]
      },
      {
         "Sid":"AllowDevTestToModifyInstance",
         "Effect":"Allow",
         "Action":[
            "rds:ModifyDBInstance"
         ],
         "Resource":"arn:aws:rds:*:123456789012:db:*",
         "Condition":{
            "StringEquals":{
                "rds:db-tag/stage":[
                  "development",
                  "test"
               ]
            }
         }
      }
   ]
}
            
            

Exemplo 2: negar explicitamente a permissão para criar uma instância de banco de dados que usa grupos de parâmetros de banco de dados especificados

A seguinte política nega explicitamente a permissão para criar uma instância de banco de dados que usa grupos de parâmetros de banco de dados com valores de tag específicos. Você poderá aplicar essa política se precisar que um grupo de parâmetros de banco de dados específico criado pelo cliente sempre seja usado ao criar instâncias de bancos de dados. As políticas que utilizam Deny são mais frequentemente usadas para restringir o acesso que foi concedido por uma política mais ampla.

A negação explícita da permissão substitui quaisquer outras permissões concedidas. Isso garante que as identidades não obtenham acidentalmente permissão que você nunca deseja conceder.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"DenyProductionCreate",
         "Effect":"Deny",
         "Action":"rds:CreateDBInstance",
         "Resource":"arn:aws:rds:*:123456789012:pg:*",
         "Condition":{
            "StringEquals":{
               "rds:pg-tag/usage":"prod"
            }
         }
      }
   ]
}

Exemplo 3: conceder permissão para executar ações em uma instância de banco de dados com um nome de instância prefixado com um nome de usuário

A seguinte política permite chamar qualquer API (exceto para AddTagsToResource ou RemoveTagsFromResource) em uma instância de banco de dados que tem um nome prefixado com o nome do usuário e que tem uma tag stage igual a devo ou sem tag stage.

A linha Resource na política identifica um recurso pelo seu Nome de Recurso Amazon (ARN). Para obter mais informações sobre como usar ARNs com recursos do Amazon Aurora, consulte Trabalhar com nomes de recurso da Amazon (ARNs) no Amazon RDS.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"AllowFullDevAccessNoTags",
         "Effect":"Allow",
         "NotAction":[
            "rds:AddTagsToResource",
            "rds:RemoveTagsFromResource"
         ],
         "Resource":"arn:aws:rds:*:123456789012:db:${aws:username}*",
         "Condition":{
            "StringEqualsIfExists":{
               "rds:db-tag/stage":"devo"
            }
         }
      }
   ]
}