O blog da AWS

Controle de acesso centralizado fim-a-fim para plataforma de dados

Por Luiz Yanai, Arquiteto Especialista Sênior de Analytics na AWS Brasil.

Organizações que adotam análise de dados em escala enfrentam um desafio recorrente: como garantir que cada pessoa enxergue apenas os dados aos quais tem direito, de forma consistente, do data lake até o painel de BI — sem multiplicar regras de acesso em cada ferramenta. Quando as permissões vivem em silos (uma cópia no Amazon Athena, outra no Amazon Quick Sight, outra no data lake), o resultado é um modelo difícil de auditar e propenso a erros.

Neste post, mostramos como integrar o Amazon Quick Sight ao Amazon Athena usando Trusted Identity Propagation (TIP) do AWS IAM Identity Center, com o controle de acesso centralizado no AWS Lake Formation e o acesso ao bucket de resultados governado pelo Amazon S3 Access Grants. Com essa arquitetura, a identidade corporativa do usuário (vinda do seu provedor de identidade) é propagada de ponta a ponta, e as permissões são definidas uma única vez no Lake Formation com base em usuários e grupos do diretório.

Também detalhamos os erros mais comuns dessa jornada de configuração e suas causas, além das limitações que você precisa conhecer antes de adotar o padrão.

Por que Trusted Identity Propagation?

Tradicionalmente, ao conectar o Quick Sight ao Athena, o serviço usava uma IAM service role para executar as consultas. Isso significa que todos os usuários compartilhavam a mesma identidade técnica perante o data lake, e qualquer controle fino (linha, coluna) precisava ser recriado para o QuickSight. Existe a integração do Quick Sight com o AWS Lake Formation, mas ela é baseada em usuários e grupos do Quick Sight para permitir controle fino de acesso.

Com o TIP, isso muda. O TIP é um recurso do IAM Identity Center, construído sobre o framework OAuth 2.0, que permite propagar a identidade do usuário entre serviços AWS. Na prática:

– O usuário faz login no Quick Sight via SSO (IAM Identity Center).
– Ao consultar o Athena, a identidade do usuário é propagada com o contexto de identidade.
– O Lake Formation avalia as permissões para o usuário e seus grupos do diretório.
– O acesso ao S3 (resultados da consulta) é concedido via S3 Access Grants à mesma identidade.

O benefício: governança centralizada no Lake Formation, experiência de single sign-on e auditoria de acesso por identidade corporativa real (e não por uma role genérica).

Visão geral da solução

A arquitetura conecta quatro serviços sob a mesma instância do IAM Identity Center:

1. Amazon Quick Sight — configurado com autenticação IAM Identity Center; cria um data source Athena com propagação de identidade habilitada.
2. Amazon Athena — um workgroup habilitado para IAM Identity Center (TIP).
3. AWS Lake Formation — governa as permissões de catálogo (database, tabela, coluna, linha) para usuários e grupos do diretório.
4. Amazon S3 Access Grants — governa o acesso ao local de resultados do Athena com base na identidade do diretório.

O fluxo de uma consulta é o seguinte:

Figura 1 – Fluxo de propagação de identidade pelo Amazon Quick Sight, Amazon Athena, AWS Lake Formation e S3 Access Grants.

Importante: todos os recursos — instância do IAM Identity Center, workgroup do Athena, Lake Formation e S3 Access Grants — devem estar na mesma região da AWS.

Pré-requisitos

– Uma conta AWS com IAM Identity Center habilitado (instância de organização ou de conta).
– Usuários e grupos provisionados no IAM Identity Center (sincronizados do seu IdP via SCIM, como Okta, Microsoft Entra ID, entre outros).
– Conta do Quick Sight Enterprise configurada com autenticação IAM Identity Center.
– Catálogo de dados governado pelo Lake Formation.
– Permissões administrativas para Athena, Lake Formation, IAM e S3.

Passo a passo da configuração

Nos exemplos a seguir, usamos a conta 111122223333, a região us-east-1, o workgroup meu-workgroup, o grupo do IDC BI_AUTHORS e o bucket de resultados s3://meu-bucket/athena-results/. Ajuste para os seus valores.

1. Criar um workgroup do Athena habilitado para IAM Identity Center

No console do Athena, crie um workgroup com Authentication = IAM Identity Center.
Atenção: não é possível converter um workgroup existente — ele precisa nascer IDC-enabled.
Habilite também o S3 Access Grants para os resultados da consulta.

Anote o IdentityCenterApplicationArn do workgroup — você vai precisar dele:

aws athena get-work-group --work-group meu-workgroup --region us-east-1

Ao criar o workgroup com autenticação IAM Identity Center, uma aplicação IDC é criada automaticamente. Porém, nenhum usuário ou grupo tem acesso a ela por padrão e precisa ser realizado.

Atribua o grupo que terá acesso ao workgroup:

aws sso-admin create-application-assignment \
--application-arn "arn:aws:sso::111122223333:application/ssoins-xxxx/apl-xxxx" \
--principal-id "<group-id>" \
--principal-type GROUP \
--region us-east-1

O --application-arn é o IdentityCenterApplicationArn do workgroup (obtido no passo anterior). O --principal-id é o ID do grupo no Identity Store.

Para obter o ID do grupo:

aws identitystore list-groups --identity-store-id <identity-store-id> --region us-east-1

Repita o comando para cada grupo que precisar acessar o workgroup via Quick Sight.

2. Autorizar a propagação de identidade no Quick Sight

aws quicksight update-identity-propagation-config \
--aws-account-id 111122223333 \
--service ATHENA \
--authorized-targets "arn:aws:sso::111122223333:application/ssoins-xxxx/apl-xxxx" \
--region us-east-1

O --authorized-targets espera o ARN da aplicação IDC do workgroup (campo IdentityCenterApplicationArn), não o ARN do workgroup. Esse é um erro comum.

3. Criar o data source do Athena com propagação de identidade

aws quicksight create-data-source \
--aws-account-id 111122223333 \
--data-source-id meu-athena-tip \
--name "Athena TIP" \
--type ATHENA \
--data-source-parameters '{
"AthenaParameters": {
"WorkGroup": "meu-workgroup",
"IdentityCenterConfiguration": { "EnableIdentityPropagation": true }
}
}' \
--region us-east-1

Para workgroups IDC, use IdentityCenterConfiguration.EnableIdentityPropagation = true em vez de uma RoleArn. Caso contrário, o Quick Sight tenta usar a service role e falha.

4. Conceder permissões no Lake Formation aos grupos do diretório

# Tornar a database visível
aws lakeformation grant-permissions --region us-east-1 \
--principal '{"DataLakePrincipalIdentifier":"arn:aws:identitystore:::group/"}' \
--resource '{"Database":{"CatalogId":"111122223333","Name":"minha_database"}}' \
--permissions "DESCRIBE"
# Conceder leitura na tabela
aws lakeformation grant-permissions --region us-east-1 \
--principal '{"DataLakePrincipalIdentifier":"arn:aws:identitystore:::group/"}' \
--resource '{"Table":{"CatalogId":"111122223333","DatabaseName":"minha_database","Name":"minha_tabela"}}' \
--permissions "SELECT" "DESCRIBE"

5. Configurar o S3 Access Grants para o local de resultados

Primeiro, associe a instância do IAM Identity Center ao S3 Access Grants (pré-requisito para conceder a grupos do diretório):

aws s3control associate-access-grants-identity-center \
--account-id 111122223333 \
--identity-center-arn "arn:aws:sso:::instance/ssoins-xxxx" \
--region us-east-1

Crie a IAM role que o S3 Access Grants assume (note a ação sts:SetContext):

aws iam create-role --role-name s3ag-athena-results \
--assume-role-policy-document '{
"Version":"2012-10-17",
"Statement":[{
"Effect":"Allow",
"Principal":{"Service":"access-grants.s3.amazonaws.com"},
"Action":["sts:AssumeRole","sts:SetContext"]
}]
}'

Conceda à role permissões de leitura e escrita no bucket de resultados:

aws iam put-role-policy --role-name s3ag-athena-results \
--policy-name S3ResultsAccess \
--policy-document '{
"Version":"2012-10-17",
"Statement":[{
"Effect":"Allow", "Action":["s3:GetObject","s3:PutObject","s3:DeleteObject","s3:ListBucket","s3:GetBucketLocation"],
"Resource":["arn:aws:s3:::meu-bucket/athena-results/*","arn:aws:s3:::meu-bucket"]
}]
}'

Registre o local e crie o grant para o grupo do diretório:

aws s3control create-access-grants-location \
--account-id 111122223333 \
--location-scope "s3://meu-bucket/athena-results/" \
--iam-role-arn "arn:aws:iam::111122223333:role/s3ag-athena-results" \
--region us-east-1
aws s3control create-access-grant \
--account-id 111122223333 \
--access-grants-location-id \
--access-grants-location-configuration '{"S3SubPrefix":"*"}' \
--grantee '{"GranteeType":"DIRECTORY_GROUP","GranteeIdentifier":""}' \
--permission READWRITE \
--region us-east-1

6. Garantir que as roles do caminho suportem sts:SetContext

Este é o detalhe que mais gera atrito. A propagação de identidade usa a ação STS sts:SetContext. Toda role no caminho da identidade precisa permiti-la na trust policy:

– A service role do Quick Sight (aws-quicksight-service-role-v0):

aws iam update-assume-role-policy \
--role-name aws-quicksight-service-role-v0 \
--policy-document '{
"Version":"2012-10-17",
"Statement":[{
"Effect":"Allow",
"Principal":{"Service":"quicksight.amazonaws.com"},
"Action":["sts:AssumeRole","sts:TagSession","sts:SetSourceIdentity","sts:SetContext"]
}]
}'

– A role da data location do Lake Formation. Aqui há um ponto crítico: a localização dos dados não pode estar registrada com a service-linked role
(AWSServiceRoleForLakeFormationDataAccess), porque SLRs não suportam SetContext. Registre o prefixo dos dados com uma IAM role comum que inclua sts:SetContext:

aws iam create-role --role-name lf-tip-data-location \
--assume-role-policy-document '{
"Version":"2012-10-17",
"Statement":[{
"Effect":"Allow",
"Principal":{"Service":"lakeformation.amazonaws.com"},
"Action":["sts:AssumeRole","sts:SetContext"]
}]
}'
aws lakeformation register-resource --region us-east-1 \
--resource-arn "arn:aws:s3:::meu-bucket/dados/" \
--role-arn "arn:aws:iam::111122223333:role/lf-tip-data-location"

O Lake Formation usa sempre o registro mais específico. Registrar um prefixo com uma role TIP-capable preserva o registro do bucket usado por outros serviços.

7. Criar o dataset e validar

Crie o dataset no Quick Sight a partir do data source TIP (será sempre direct query) e valide pelo portal, logado via SSO como um usuário do grupo autorizado.

Erros comuns e suas causas

Durante a configuração, estes são os erros que você provavelmente encontrará:

Erro Causa Solução
ValidationException em update-identity-propagation-config ARN do workgroup em vez do ARN da aplicação IDC Use o IdentityCenterApplicationArn
IAM_ASSUME_ROLE_FAILURE ao criar o data source Workgroup IDC tentando usar service role Use EnableIdentityPropagation=true
Database/tabela não aparece no dataset Sem grants no Lake Formation para o grupo IDC Conceda DESCRIBE/SELECT ao grupo
Failure while assuming role through STS Trust policy sem sts:SetContext Adicione sts:SetContext à role
Cannot vend credentials from service-linked role ... SetContext Data location registrada com SLR Re-registre com IAM role comum

Dica: mudanças de entitlement (Lake Formation e S3 Access Grants) em workgroups TIP podem levar até uma hora para entrar em vigor.

Limitações que você precisa conhecer

Antes de adotar o padrão em produção, considere as limitações documentadas:

No Amazon Quick Sight com TIP:

  • SPICE não é suportado — apenas datasets em direct query.
  • SQL personalizado (Custom SQL) no data source fica desabilitado.
  • Também ficam indisponíveis: Q Topics, threshold alerts, email reports, stories, scenarios, exportações para CSV/Excel/PDF e detecção de anomalias.
  • O controle de acesso fino deve ser feito no Lake Formation (recomendado). Scope-down policies, se usadas, são avaliadas contra o usuário final.

No Amazon Athena com workgroup IDC:

  • Não é possível alterar o método de autenticação após a criação do workgroup.
  • Consultas não rodam pelo console do Athena — apenas via interfaces com IDC (EMR Studio, SageMaker Unified Studio) ou via Quick Sight com TIP.
  • Timeout padrão de 30 minutos (máximo de 1 hora).
  • Mudanças de permissão de usuários/grupos podem levar até 1 hora para refletir.
  • Incompatível com Athena para Spark, acesso federado à API do Athena e drivers JDBC/ODBC com Lake Formation.
  • Disponível apenas em um subconjunto de regiões da AWS.

Performance:

  • Combinações de muitos grupos IDC, muitas databases/tabelas e muitas regras do Lake Formation podem aumentar a latência. Mantenha apenas o necessário.

Conclusão

Com Trusted Identity Propagation, você centraliza o controle de acesso no AWS Lake Formation e no Amazon S3 Access Grants, propaga a identidade corporativa do usuário do Quick Sight até o data lake e simplifica a auditoria — tudo isso com uma experiência de single sign-on. O ponto de atenção principal é garantir que todas as roles do caminho da identidade permitam a ação sts:SetContext e que as data locations do Lake Formation usadas pelo TIP não estejam registradas com service-linked roles.

Avalie as limitações (especialmente a ausência de SPICE, Custom SQL e Q Topics) frente aos seus requisitos de negócio. Para cenários que exigem governança forte e auditoria por identidade, o ganho de simplicidade e segurança costuma compensar.

Saiba mais

Autor

Luiz Yanai - Analytics Specialist SA Luiz Yanai é arquiteto especialista sênior em Data & AI na AWS atuando com clientes nativos na nuvem e empresas do ramo financeiro em suas jornadas para se tornarem data-driven. Possui 20 anos de experiência em arquitetura e desenvolvimento de soluções envolvendo sistemas empresariais e de missão crítica sendo que os últimos 5 anos estão focados na nuvem AWS.