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íticas baseadas em identidade para o Amazon QLDB
Por padrão, usuários e funções não têm permissão para criar ou modificar recursos do QLDB. Eles também não podem realizar tarefas usando a AWS API AWS Management Console, AWS Command Line Interface (AWS CLI) ou. Para conceder aos usuários permissão para executar ações nos recursos de que eles precisam, um administrador do IAM pode criar políticas do IAM. O administrador pode então adicionar as políticas do IAM aos perfis, e os usuários podem assumir os perfis.
Para saber como criar uma política baseada em identidade do IAM usando esses exemplos de documento de política JSON, consulte Criação de políticas do IAM no Guia do Usuário do IAM.
Para obter detalhes sobre ações e tipos de recurso definidos pelo QLDB, incluindo o formato dos ARNs para cada tipo de recurso, consulte Ações, recursos e chaves de condição do Amazon QLDB na Referência de autorização do serviço.
Sumário
- Melhores práticas de política
- Uso do console do QLDB
- Permitir que os usuários visualizem suas próprias permissões
- Executando transações de dados
- Exportar um diário para um bucket do Amazon S3
- Fluxo de um diário para o Kinesis Data Streams
- Atualização de ledgers do QLDB com base em tags
Melhores práticas de política
As políticas baseadas em identidade determinam se alguém pode criar, acessar ou excluir recursos do QLDB 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 AWS gerenciadas e avance para as permissões de privilégios mínimos — Para começar a conceder permissões aos seus usuários e cargas de trabalho, use as políticas AWS gerenciadas que concedem permissões para muitos casos de uso comuns. Eles estão disponíveis no seu Conta da AWS. Recomendamos que você reduza ainda mais as permissões definindo políticas gerenciadas pelo AWS cliente que sejam 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 perfis 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 atributos 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 atributos. 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 às ações de serviço se elas forem usadas por meio de uma ação específica AWS service (Serviço da AWS), como AWS CloudFormation. Para obter mais informações, consulte Elementos de política JSON do IAM: condições 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 cem 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.
-
Exigir autenticação multifator (MFA) — Se você tiver um cenário que exija usuários do IAM ou um usuário root, ative Conta da AWS 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 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.
Uso do console do QLDB
Para acessar o console da Amazon QLDB 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 QLDB em seu. Conta da AWS Se você criar uma política baseada em identidade que seja mais restritiva do 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.
Você não precisa permitir permissões mínimas do console para usuários que estão fazendo chamadas somente para a API AWS CLI ou para a AWS API. Em vez disso, permita o acesso somente a ações que correspondam a operação de API que estiverem tentando executar.
Para garantir que usuários e funções tenham acesso total ao console do QLDB e a todos os seus recursos, anexe a AWS seguinte política gerenciada às entidades. Para obter mais informações, consulte AWS políticas gerenciadas para o Amazon QLDB e Adicionar permissões a um usuário no Guia do usuário do IAM.
AmazonQLDBConsoleFullAccess
Permissões do histórico de consultas
Além das permissões do QLDB, alguns atributos do console exigem permissões para o Database Query Metadata Service (prefixo do serviço: dbqms). Esse é um serviço somente interno que gerencia suas consultas recentes e salvas no editor de consultas do console para QLDB e outros Serviços da AWS. Para obter uma lista completa das ações da API DBQMS, consulte Database Query Metadata Service na Referência de Autorização de Serviço.
Para permitir permissões de histórico de consultas, você pode usar a política AWS gerenciada ConsoleFullAccessAmazonQLDB. Essa política usa um caractere curinga (dbqms:*) para permitir todas as ações do DBQMS para todos os recursos.
Ou você pode criar uma política do IAM personalizada e incluir as seguintes ações do DBQMS. O editor de consultas PartiQL no console do QLDB exige permissões para usar essas ações para atributos do histórico de consultas.
dbqms:CreateFavoriteQuery dbqms:CreateQueryHistory dbqms:DeleteFavoriteQueries dbqms:DeleteQueryHistory dbqms:DescribeFavoriteQueries dbqms:DescribeQueryHistory dbqms:UpdateFavoriteQuery
Permissões completas do console sem histórico de consultas
Para permitir acesso total ao console do QLDB sem nenhuma permissão de histórico de consultas, você pode criar uma política personalizada do IAM que exclua todas as ações do DBQMS. Por exemplo, o documento de política a seguir permite as mesmas permissões concedidas pela política AWS gerenciada AmazonQLDB ConsoleFullAccess, exceto ações que começam com o prefixo do serviço. dbqms
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "qldb:CreateLedger", "qldb:UpdateLedger", "qldb:UpdateLedgerPermissionsMode", "qldb:DeleteLedger", "qldb:ListLedgers", "qldb:DescribeLedger", "qldb:ExportJournalToS3", "qldb:ListJournalS3Exports", "qldb:ListJournalS3ExportsForLedger", "qldb:DescribeJournalS3Export", "qldb:CancelJournalKinesisStream", "qldb:DescribeJournalKinesisStream", "qldb:ListJournalKinesisStreamsForLedger", "qldb:StreamJournalToKinesis", "qldb:GetBlock", "qldb:GetDigest", "qldb:GetRevision", "qldb:TagResource", "qldb:UntagResource", "qldb:ListTagsForResource", "qldb:SendCommand", "qldb:ExecuteStatement", "qldb:ShowCatalog", "qldb:InsertSampleData", "qldb:PartiQLCreateIndex", "qldb:PartiQLDropIndex", "qldb:PartiQLCreateTable", "qldb:PartiQLDropTable", "qldb:PartiQLUndropTable", "qldb:PartiQLDelete", "qldb:PartiQLInsert", "qldb:PartiQLUpdate", "qldb:PartiQLSelect", "qldb:PartiQLHistoryFunction" ], "Effect": "Allow", "Resource": "*" }, { "Action": [ "kinesis:ListStreams", "kinesis:DescribeStream" ], "Effect": "Allow", "Resource": "*" }, { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "*", "Condition": { "StringEquals": { "iam:PassedToService": "qldb.amazonaws.com" } } } ] }
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 programaticamente usando a API AWS CLI ou 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": "*" } ] }
Executando transações de dados
Para interagir com a API de dados transacionais do QLDB (sessão QLDB) executando instruções PartiQL em um ledger, você deve conceder permissão para a ação da APISendCommand. O documento JSON a seguir é um exemplo de uma política que concede permissão somente para a ação da API SendCommand no ledger myExampleLedger.
Para usar essa política, substitua us-east-1, 123456789012 e, no exemplo, por suas próprias informações. myExampleLedger
{ "Version": "2012-10-17", "Statement": [ { "Sid": "QLDBSendCommandPermission", "Effect": "Allow", "Action": "qldb:SendCommand", "Resource": "arn:aws:qldb:us-east-1:123456789012:ledger/myExampleLedger" } ] }
Se myExampleLedger usar o modo de ALLOW_ALL permissões, essa política concederá permissões para executar todos os comandos do PartiQL em qualquer tabela no ledger.
Você também pode usar uma política AWS gerenciada para conceder acesso total a todos os recursos do QLDB. Para ter mais informações, consulte AWS políticas gerenciadas para o Amazon QLDB.
Permissões padrão para ações do PartiQL e recursos de tabela
Para ledgers no modo de permissões STANDARD, você pode consultar os seguintes documentos de política do IAM como exemplos de concessão das permissões PartiQL apropriadas. Para obter uma lista das permissões necessárias para cada comando do PartiQL, consulte as Referência de permissões PartiQL.
Tópicos
Permitir acesso total a todas as ações
O documento de política JSON a seguir concede acesso total para usar todos os comandos PartiQL em todas as tabelas no myExampleLedger. Essa política produz o mesmo efeito do uso do modo de ALLOW_ALL permissões para o ledger.
Para usar essa política, substitua us-east-1, 123456789012 e, no exemplo, por suas próprias informações. myExampleLedger
{ "Version": "2012-10-17", "Statement": [ { "Sid": "QLDBSendCommandPermission", "Effect": "Allow", "Action": "qldb:SendCommand", "Resource": "arn:aws:qldb:us-east-1:123456789012:ledger/myExampleLedger" }, { "Sid": "QLDBPartiQLFullPermissions", "Effect": "Allow", "Action": [ "qldb:PartiQLCreateIndex", "qldb:PartiQLDropIndex", "qldb:PartiQLCreateTable", "qldb:PartiQLDropTable", "qldb:PartiQLUndropTable", "qldb:PartiQLDelete", "qldb:PartiQLInsert", "qldb:PartiQLUpdate", "qldb:PartiQLRedact", "qldb:PartiQLSelect", "qldb:PartiQLHistoryFunction" ], "Resource": [ "arn:aws:qldb:us-east-1:123456789012:ledger/myExampleLedger/table/*", "arn:aws:qldb:us-east-1:123456789012:ledger/myExampleLedger/information_schema/user_tables" ] } ] }
Acesso total a todas as ações com base nas tags da tabela
O documento de política JSON a seguir usa uma condição baseada nas tags de recursos da tabela para conceder acesso total ao uso de todos os comandos do PartiQL em todas as tabelas do myExampleLedger. As permissões são concedidas somente se a tag da tabela environment tiver o valor development.
Atenção
Este é um exemplo de uso de um caractere curinga (*) para permitir todas as ações PartiQL, incluindo operações administrativas e de leitura/gravação em todas as tabelas em um livro contábil do QLDB. Em vez disso, é uma prática recomendada especificar explicitamente cada ação a ser concedida, e apenas o que esse usuário, função ou grupo precisa.
Para usar essa política, substitua us-east-1, 123456789012 e, no exemplo, por suas próprias informações. myExampleLedger
{ "Version": "2012-10-17", "Statement": [ { "Sid": "QLDBSendCommandPermission", "Effect": "Allow", "Action": "qldb:SendCommand", "Resource": "arn:aws:qldb:us-east-1:123456789012:ledger/myExampleLedger" }, { "Sid": "QLDBPartiQLFullPermissionsBasedOnTags", "Effect": "Allow", "Action": [ "qldb:PartiQL*" ], "Resource": [ "arn:aws:qldb:us-east-1:123456789012:ledger/myExampleLedger/table/*", "arn:aws:qldb:us-east-1:123456789012:ledger/myExampleLedger/information_schema/user_tables" ], "Condition": { "StringEquals": { "aws:ResourceTag/environment": "development" } } } ] }
Acesso de leitura/gravação
O documento de política JSON a seguir concede permissões para selecionar, inserir, atualizar e excluir dados em todas as tabelas do myExampleLedger. Essa política não concede permissões para redigir dados ou alterar o esquema, por exemplo, criar e eliminar tabelas e índices.
nota
Uma UPDATE declaração exige permissões para as ações qldb:PartiQLUpdate e qldb:PartiQLSelect da tabela que está sendo modificada. Quando você executa uma instrução UPDATE, ela executa uma operação de leitura além da operação de atualização. A exigência de ambas as ações garante que somente os usuários que têm permissão para ler o conteúdo de uma tabela recebam permissões UPDATE.
Da mesma forma, uma declaração DELETE exige permissões para as ações qldb:PartiQLDelete e qldb:PartiQLSelect.
Para usar essa política, substitua us-east-1, 123456789012 e, no exemplo, por suas próprias informações. myExampleLedger
{ "Version": "2012-10-17", "Statement": [ { "Sid": "QLDBSendCommandPermission", "Effect": "Allow", "Action": "qldb:SendCommand", "Resource": "arn:aws:qldb:us-east-1:123456789012:ledger/myExampleLedger" }, { "Sid": "QLDBPartiQLReadWritePermissions", "Effect": "Allow", "Action": [ "qldb:PartiQLDelete", "qldb:PartiQLInsert", "qldb:PartiQLUpdate", "qldb:PartiQLSelect", "qldb:PartiQLHistoryFunction" ], "Resource": [ "arn:aws:qldb:us-east-1:123456789012:ledger/myExampleLedger/table/*", "arn:aws:qldb:us-east-1:123456789012:ledger/myExampleLedger/information_schema/user_tables" ] } ] }
Acesso somente leitura
O documento de política JSON a seguir concede permissões somente para leitura em todas as tabelas do myExampleLedger. Para usar essa política, substitua us-east-1, 123456789012 e, no exemplo, por suas próprias informações. myExampleLedger
{ "Version": "2012-10-17", "Statement": [ { "Sid": "QLDBSendCommandPermission", "Effect": "Allow", "Action": "qldb:SendCommand", "Resource": "arn:aws:qldb:us-east-1:123456789012:ledger/myExampleLedger" }, { "Sid": "QLDBPartiQLReadOnlyPermissions", "Effect": "Allow", "Action": [ "qldb:PartiQLSelect", "qldb:PartiQLHistoryFunction" ], "Resource": [ "arn:aws:qldb:us-east-1:123456789012:ledger/myExampleLedger/table/*", "arn:aws:qldb:us-east-1:123456789012:ledger/myExampleLedger/information_schema/user_tables" ] } ] }
Acesso somente leitura a uma tabela específica
O documento de política JSON a seguir concede permissões somente para leitura em uma tabela específica em myExampleLedger. Nesse exemplo, o ID da tabela é Au1EiThbt8s0z9wM26REZN.
Para usar essa política, substitua us-east-1, 123456789012 e Au1 8S0Z9WM26rezn no exemplo por myExampleLedgersuas próprias informações. EiThbt
{ "Version": "2012-10-17", "Statement": [ { "Sid": "QLDBSendCommandPermission", "Effect": "Allow", "Action": "qldb:SendCommand", "Resource": "arn:aws:qldb:us-east-1:123456789012:ledger/myExampleLedger" }, { "Sid": "QLDBPartiQLReadOnlyPermissionsOnTable", "Effect": "Allow", "Action": [ "qldb:PartiQLSelect", "qldb:PartiQLHistoryFunction" ], "Resource": [ "arn:aws:qldb:us-east-1:123456789012:ledger/myExampleLedger/table/Au1EiThbt8s0z9wM26REZN" ] } ] }
Permitir acesso para criar tabelas
O documento de política JSON a seguir concede permissão para criar tabelas em myExampleLedger. A ação qldb:PartiQLCreateTable requer permissões para o tipo de recurso da tabela. No entanto, o ID da tabela nova não é conhecido no momento em que você executa uma instrução CREATE TABLE. Portanto, uma política que concede a permissão qldb:PartiQLCreateTable deve usar um caractere curinga (*) na tabela ARN para especificar o recurso.
Para usar essa política, substitua us-east-1, 123456789012 e, no exemplo, por suas próprias informações. myExampleLedger
{ "Version": "2012-10-17", "Statement": [ { "Sid": "QLDBSendCommandPermission", "Effect": "Allow", "Action": "qldb:SendCommand", "Resource": "arn:aws:qldb:us-east-1:123456789012:ledger/myExampleLedger" }, { "Sid": "QLDBPartiQLCreateTablePermission", "Effect": "Allow", "Action": [ "qldb:PartiQLCreateTable" ], "Resource": [ "arn:aws:qldb:us-east-1:123456789012:ledger/myExampleLedger/table/*" ] } ] }
Permitir acesso para criar tabelas com base nas tags de solicitação
O documento de política JSON a seguir usa uma condição baseada na chave de contexto aws:RequestTag para conceder permissão para criar tabelas em myExampleLedger. As permissões são concedidas somente se a tag de solicitação environment tiver o valor development. Marcar tabelas na criação requer acesso às ações qldb:PartiQLCreateTable e qldb:TagResource. Para saber como marcar tabelas na criação de tags, consulte Tabelas de marcação.
Para usar essa política, substitua us-east-1, 123456789012 e, no exemplo, por suas próprias informações. myExampleLedger
{ "Version": "2012-10-17", "Statement": [ { "Sid": "QLDBSendCommandPermission", "Effect": "Allow", "Action": "qldb:SendCommand", "Resource": "arn:aws:qldb:us-east-1:123456789012:ledger/myExampleLedger" }, { "Sid": "QLDBPartiQLCreateTablePermission", "Effect": "Allow", "Action": [ "qldb:PartiQLCreateTable", "qldb:TagResource" ], "Resource": [ "arn:aws:qldb:us-east-1:123456789012:ledger/myExampleLedger/table/*" ], "Condition": { "StringEquals": { "aws:RequestTag/environment": "development" } } } ] }
Exportar um diário para um bucket do Amazon S3
Etapa 1: Permissões de exportação do diário QLDB
No exemplo a seguir, você concede a um usuário suas Conta da AWS permissões para realizar a qldb:ExportJournalToS3 ação em um recurso contábil do QLDB. Você também concede permissões para realizar a ação iam:PassRole no recurso de perfil do IAM que deseja passar para o serviço QLDB. Isso é necessário para todas as solicitações de exportação de diário.
Para usar essa política, substitua us-east-1, 123456789012 e qldb-s3-export no exemplo por suas myExampleLedgerpróprias informações.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "QLDBJournalExportPermission", "Effect": "Allow", "Action": "qldb:ExportJournalToS3", "Resource": "arn:aws:qldb:us-east-1:123456789012:ledger/myExampleLedger" }, { "Sid": "IAMPassRolePermission", "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::123456789012:role/qldb-s3-export", "Condition": { "StringEquals": { "iam:PassedToService": "qldb.amazonaws.com" } } } ] }
Estapa 2: Permissões do Amazon S3 bucket
No exemplo a seguir, você usa um perfil do IAM para conceder acesso ao QLDB para gravar em um dos seus buckets do Amazon S3, DOC-EXAMPLE-BUCKET. Isso também é necessário para todas as exportações de diários do QLDB.
Além de conceder a permissão s3:PutObject, a política também concede a permissão s3:PutObjectAcl para definir as permissões de lista de controle de acesso (ACL) para um objeto.
Para usar essa regra de exemplo, substitua DOC-EXAMPLE-BUCKET1 pelo nome do bucket do Amazon S3.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "QLDBJournalExportS3Permissions", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:PutObjectAcl" ], "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*" } ] }
Em seguida, você anexa essa política de permissões a uma perfil do IAM que o QLDB pode assumir para acessar seu bucket do Amazon S3. O documento JSON a seguir é um exemplo de uma política de confiança que permite que o QLDB assuma o perfil do IAM para qualquer recurso do QLDB somente na conta 123456789012.
Para usar essa política, substitua us-east-1 e 123456789012 no exemplo com suas próprias informações.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "qldb.amazonaws.com" }, "Action": [ "sts:AssumeRole" ], "Condition": { "ArnEquals": { "aws:SourceArn": "arn:aws:qldb:us-east-1:123456789012:*" }, "StringEquals": { "aws:SourceAccount": "123456789012" } } } ] }
Fluxo de um diário para o Kinesis Data Streams
Etapa 1: permissões de fluxo de diário do QLDB
No exemplo a seguir, você concede a um usuário suas Conta da AWS permissões para realizar a qldb:StreamJournalToKinesis ação em todos os sub-recursos de fluxo do QLDB em um livro contábil. Você também concede permissões para realizar a ação iam:PassRole no recurso de perfil do IAM que deseja passar para o serviço QLDB. Isso é necessário para todas as solicitações de fluxos de diário.
Para usar essa política, substitua us-east-1, 123456789012 e, no exemplo myExampleLedger, por suas próprias informações. qldb-kinesis-stream
{ "Version": "2012-10-17", "Statement": [ { "Sid": "QLDBJournalStreamPermission", "Effect": "Allow", "Action": "qldb:StreamJournalToKinesis", "Resource": "arn:aws:qldb:us-east-1:123456789012:stream/myExampleLedger/*" }, { "Sid": "IAMPassRolePermission", "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::123456789012:role/qldb-kinesis-stream", "Condition": { "StringEquals": { "iam:PassedToService": "qldb.amazonaws.com" } } } ] }
Etapa 2: permissões do Kinesis Data Streams
No exemplo a seguir, você usa uma função do IAM para conceder acesso ao QLDB para gravar registros de dados em seu stream de dados do Amazon Kinesis,. stream-for-qldb Isso é necessário para todos os fluxos de diário QLDB.
Para usar essa política, substitua us-east-1, 123456789012 e, no exemplo, por suas próprias informações. stream-for-qldb
{ "Version": "2012-10-17", "Statement": [ { "Sid": "QLDBStreamKinesisPermissions", "Action": [ "kinesis:PutRecord*", "kinesis:DescribeStream", "kinesis:ListShards" ], "Effect": "Allow", "Resource": "arn:aws:kinesis:us-east-1:123456789012:stream/stream-for-qldb" } ] }
Em seguida, você anexa essa política de permissões a um perfil do IAM que o QLDB pode assumir para acessar seu fluxo de dados do Kinesis. O documento JSON a seguir é um exemplo de uma política de confiança que permite que o QLDB assuma um perfil do IAM em qualquer stream do QLDB na conta somente 123456789012 para o ledger myExampleLedger.
Para usar essa política, substitua us-east-1, 123456789012 e, no exemplo, por suas próprias informações. myExampleLedger
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "qldb.amazonaws.com" }, "Action": [ "sts:AssumeRole" ], "Condition": { "ArnEquals": { "aws:SourceArn": "arn:aws:qldb:us-east-1:123456789012:stream/myExampleLedger/*" }, "StringEquals": { "aws:SourceAccount": "123456789012" } } } ] }
Atualização de ledgers do QLDB com base em tags
Você pode usar condições em sua política baseada em identidade para controlar o acesso aos recursos do QLDB com base em tags. Este exemplo mostra como é possível criar uma política que permite atualizar um ledger. No entanto, a permissão é concedida somente se a tag do ledger Owner tiver o valor do nome de usuário desse usuário. Essa política também concede as permissões necessárias concluir essa ação no console.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "ListLedgersInConsole", "Effect": "Allow", "Action": "qldb:ListLedgers", "Resource": "*" }, { "Sid": "UpdateLedgerIfOwner", "Effect": "Allow", "Action": "qldb:UpdateLedger", "Resource": "arn:aws:qldb:*:*:ledger/*", "Condition": { "StringEquals": {"aws:ResourceTag/Owner": "${aws:username}"} } } ] }
Você pode anexar essa política aos usuários na sua conta. Se um usuário chamado richard-roe tentar atualizar um ledger do QLDB, o ledger deverá ser marcado como Owner=richard-roe ou owner=richard-roe. Caso contrário, ele terá o acesso negado. A chave da tag de condição Owner corresponde a Owner e a owner porque os nomes de chaves de condição não diferenciam letras maiúsculas de minúsculas. Para obter mais informações, consulte Elementos de política JSON do IAM: condições no Manual do usuário do IAM.
