O problema clássico: do piloto à produção
Um padrão recorrente em projetos de análise de dados na nuvem é o seguinte: a prova de conceito (POC) funciona muito bem com um time pequeno, mas trava quando as equipes de segurança e conformidade analisam o plano de produção. Um modelo de permissões que funciona para dez usuários piloto costuma quebrar quando cinco departamentos inteiros entram na equação. Agentes podem retornar dados fora do escopo pretendido, e equipes de auditoria têm dificuldade para rastrear como datasets, agentes e Spaces se conectam.
Foi justamente para endereçar esse problema que a AWS publicou um guia técnico detalhado sobre como estruturar o Amazon QuickSight — dashboards, Chat Agents, Flows e Spaces com bases de conhecimento — de forma que a segurança se sustente à medida que usuários e departamentos são adicionados.
O cenário de referência: AnyCompany
O guia usa como base uma empresa fictícia chamada AnyCompany: 5.000 funcionários, 5 departamentos e 5 localidades. Três perfis de usuário precisam acessar os mesmos dados, mas em níveis diferentes:
- Liderança de RH: acesso completo, incluindo salários e risco de saída voluntária (attrition).
- Gestores de departamento: apenas métricas operacionais da própria equipe.
- Todos os funcionários: políticas da empresa e tendências agregadas e anonimizadas.
Expor um único dataset a todos os três perfis e depender exclusivamente de permissões para controlar o acesso cria uma superfície de risco considerável. Uma única configuração incorreta pode expor dados salariais para toda a empresa.
A solução: segurança na arquitetura dos dados
A abordagem proposta pela AWS modela um dataset de origem em três visões alinhadas com os níveis de autorização de cada perfil. Cada visão se conecta a um agente dedicado, que por sua vez alimenta um dashboard específico para aquele público. Ações externas são controladas por um Flow com revisão humana obrigatória.
A lógica central é simples e poderosa: remover os dados antes que cheguem ao usuário, em vez de depender de configurações de permissão para bloquear o acesso. Se a coluna de salário não existe no dataset do gestor, nenhum erro de configuração pode expô-la.
Os quatro padrões validados
1. Modelagem de datasets (Dataset Shaping)
O primeiro passo é criar três datasets a partir da mesma fonte de dados:
- anycompany-employees-full: todas as 30 colunas, para a liderança de RH.
- anycompany-employees-manager: 4 colunas sensíveis removidas (salário anual, percentual de bônus, data e motivo de desligamento), para gestores de departamento.
- anycompany-employees-aggregated: apenas resumos por departamento e localidade (25 linhas no total), para todos os funcionários.
Remover colunas no nível do dataset é estruturalmente mais seguro do que ocultá-las via permissões. O dado simplesmente não existe nos datasets downstream — nenhuma configuração incorreta pode expor o que não está lá.
2. Segurança em nível de linha — Row-Level Security (RLS)
A Segurança em Nível de Linha (RLS) do Amazon QuickSight restringe quais linhas cada usuário pode ver, com base na identidade. A configuração é feita no nível do dataset, por meio de um dataset de mapeamento que associa usuários ou grupos a valores de coluna específicos — e essa restrição se propaga automaticamente para todas as análises e dashboards vinculados.
Para o dataset de gestores, cria-se um arquivo CSV de regras com duas colunas: UserName e Department. Cada gestor recebe uma linha correspondendo ao seu departamento. O administrador de RH recebe cinco linhas para acesso completo. Um ponto de atenção importante: qualquer divergência no nome de usuário — mesmo um único caractere — faz com que a consulta retorne zero linhas. O guia recomenda usar o campo calculado username() em uma análise para confirmar o formato exato.
3. Isolamento de agentes (Agent Isolation)
Cada Chat Agent deve se conectar a exatamente um dataset, dimensionado para o seu público. O guia descreve três agentes:
- Executive Insights Agent: conectado ao dataset completo, compartilhado apenas com o grupo
hr-leadership. - Manager Assistant Agent: conectado ao dataset de gestores com RLS aplicado, compartilhado apenas com
dept-managers. - Employee Self-Service Agent: conectado ao dataset agregado e à base de conhecimento com documentos de políticas, compartilhado com todos os funcionários.
Antes de declarar qualquer agente pronto para produção, a AWS recomenda testes com consultas adversariais — perguntas que tentam extrair dados fora do escopo pretendido. Por exemplo: pedir o salário de um funcionário específico ao agente de todos os funcionários deve resultar em recusa, porque esse dado simplesmente não existe no dataset conectado.
4. Classificação de documentos e Spaces
Um Space organiza documentos e fornece respostas fundamentadas em uma base de conhecimento. O princípio de segurança aqui é o mesmo: excluir documentos sensíveis em vez de depender de permissões para bloqueá-los. Todos os documentos em uma base de conhecimento são consultáveis por qualquer pessoa com acesso de Visualizador — portanto, a única forma de impedir o acesso a conteúdo sensível é mantê-lo fora da base desde o início.
O guia exemplifica com um arquivo de feedback individual de funcionários (employee_feedback_full_dataset.pdf) que é deliberadamente excluído do Space compartilhado. Se a liderança de RH precisar desses dados, a recomendação é criar um Space separado, compartilhado exclusivamente com esse grupo.
Os Spaces usam um modelo de dois níveis de acesso: Proprietários (podem visualizar, consultar e fazer upload) e Visualizadores (podem visualizar e consultar, sem upload). Usuários não adicionados não têm acesso algum.
Flows com revisão humana obrigatória
Flows encadeiam múltiplas etapas e podem pausar para revisão humana antes de continuar. O guia descreve a criação de um Flow chamado Weekly Attrition Risk Alert, com quatro etapas:
- Etapa 1: Consulta o dataset e filtra funcionários com alto risco de saída voluntária.
- Etapa 2: Processa os resultados filtrados (aproximadamente 300 funcionários, com base na taxa de ~25% no dataset sintético).
- Etapa 3: Pausa a execução até que um aprovador designado revise e aprove explicitamente.
- Etapa 4: Após aprovação, envia alertas para o grupo de gestores de departamento.
O Flow só avança para a notificação externa após aprovação humana explícita — nenhuma ação sai do sistema sem revisão. Credenciais de sistemas externos devem ser armazenadas no AWS Secrets Manager, nunca embutidas na definição do Flow.
Auditoria com AWS CloudTrail
O AWS CloudTrail registra automaticamente os eventos de gerenciamento do Amazon QuickSight (chamadas de API) sem configuração adicional. Com um trail ativo na conta, é possível verificar consultas de agentes, acessos a datasets, execuções de Flows e alterações de permissões no histórico de eventos, filtrando pela origem quicksight.amazonaws.com. Cada evento registra a identidade do usuário, o timestamp, o nome do evento e o ARN do recurso.
Como a segurança escala com a adoção
O modelo baseado em grupos permite adicionar novos funcionários com uma simples mudança de associação de grupo — sem reconfigurar acessos. Novos datasets ou Spaces só precisam ser criados quando surge uma fronteira de confidencialidade genuinamente nova. Na fase piloto, um dataset e um agente por público é suficiente. Ao escalar para 50 ou mais equipes, a estrutura se mantém.
Framework de governança
O guia propõe um framework de governança com proprietários e revisores definidos para cada tipo de ativo:
- Datasets: proprietário = responsável pelos dados; revisor = equipe de segurança; cadência trimestral.
- Dashboards: proprietário = líder de analytics; revisor = grupo consumidor; cadência trimestral.
- Chat Agents: proprietário = construtor do agente; revisor = responsável pelos dados + segurança; cadência mensal.
- Bases de conhecimento: proprietário = dono do conteúdo; revisor = responsável pelos dados; cadência mensal.
- Flows: proprietário = dono do processo; revisor = equipe de segurança; revisão a cada mudança.
- Spaces: proprietário = administrador do Space; revisor = responsável pelos dados; cadência trimestral.
Roteiro de implantação em fases
- Semanas 1–2 (POC com guardrails): um dataset por público, RLS desde o primeiro dia, testes adversariais.
- Semanas 3–4 (expansão piloto): Space e base de conhecimento, separação de permissões, Flows com portões de aprovação.
- Semanas 5–8 (hardening para produção): todos os departamentos, revisões adversariais trimestrais.
- Escala enterprise (contínuo): logs de auditoria, checklist antes de cada novo ativo, revisões periódicas de acesso.
Checklist de prontidão para produção
O guia inclui um checklist de verificações booleanas que qualquer membro da equipe pode executar antes de colocar um novo ativo em produção:
Datasets: dataset dimensionado para um único público; colunas sensíveis removidas (não apenas ocultadas); RLS aplicado e testado com pelo menos duas contas; permissões atribuídas a grupos, não a indivíduos.
Chat Agents: agente conectado a exatamente um dataset; tópicos excluem colunas que não devem ser consultáveis; agente recusa consultas sobre registros individuais quando o dataset não os contém; agente recusa consultas sobre colunas excluídas.
Spaces e bases de conhecimento: cada documento classificado antes do upload; nenhum documento contém Informações de Identificação Pessoal (PII) a menos que necessário para o público; permissões de visualização, consulta e upload configuradas separadamente; upload restrito a proprietários de conteúdo.
Flows: Flow usa dataset protegido por RLS e com colunas removidas; etapa de aprovação humana existe antes de qualquer ação externa; credenciais externas armazenadas no AWS Secrets Manager; AWS CloudTrail ativo e capturando eventos do Flow.
Recursos adicionais
Para aprofundar o tema, a AWS disponibiliza documentação complementar: Segurança em nível de linha no Amazon QuickSight, Gerenciamento de grupos, Guia do usuário do AWS CloudTrail, Guia do usuário do AWS Secrets Manager, Amazon Bedrock Guardrails para controles de segurança em IA, e um post sobre monitoramento centralizado para administração do Amazon QuickSight com dashboards baseados em AWS CloudTrail. O repositório de código com scripts e datasets sintéticos está disponível no repositório GitHub de referência.
Fonte
Securing Amazon Quick from POC to production: Agents, Flows, and Spaces (https://aws.amazon.com/blogs/machine-learning/securing-amazon-quick-from-poc-to-production-agents-flows-and-spaces/)
Leave a Reply