Um grande projeto de business intelligence (BI) com muitos usuários e equipes e informações confidenciais exige uma arquitetura de segurança multifacetada. Essa arquitetura deve fornecer aos administradores e arquitetos de BI a capacidade de minimizar a quantidade de informações acessíveis aos usuários. Para uma solução simples de gerenciar AmazonQuickSight permissões de acesso de usuário e ativo, você pode usar o Interface de linha de comando da AWS (AWS CLI) ou Console de gerenciamento da AWS para editar manualmente a função de usuário do QuickSight e o acesso ao painel. Contudo, em casos específicos, uma empresa pode facilmente ter centenas ou milhares de utilizadores e grupos, e estes métodos de gestão de acesso não são eficientes. Recebemos um grande número de solicitações para fornecer uma abordagem programável avançada para implantar e gerenciar uma arquitetura de segurança centralizada QuickSight.
Esta postagem descreve as práticas recomendadas para autenticação QuickSight e controle de acesso granular de autorização e fornece um aplicativo em nuvem centralizado com um Kit de desenvolvimento em nuvem da AWS (AWS CDK) para download. Uma das vantagens de nossa solução é que as empresas podem implantar a estrutura de segurança para administrar o controle de acesso de seu BI sem sair da AWS.
Todas as configurações são salvas no Armazenamento de parâmetros do AWS Systems Manager. O Parameter Store fornece armazenamento seguro e hierárquico para gerenciamento de dados de configuração e gerenciamento de segredos. Você pode armazenar dados como nome de usuário, permissões de usuário, senhas e sequências de banco de dados como valores de parâmetro. Você pode fazer referência Gerente de Sistemas AWS parâmetros em seus scripts e fluxos de trabalho de configuração e automação usando o nome exclusivo que você especificou quando criou o parâmetro.
O modelo de aplicativo AWS CDK se ajusta à infraestrutura de integração contínua e implantação contínua (CI/CD) e concede ou revoga todas as autenticações e autorizações com base em uma política definida prescrita pela AWS. Isso evita possíveis erros humanos cometidos por desenvolvedores ou administradores de BI. Os desenvolvedores de BI podem editar parâmetros de configuração para lançar novos painéis para os usuários finais. Ao mesmo tempo, os administradores de BI podem editar outro conjunto de parâmetros para gerenciar usuários ou grupos. Esse design de CI/CD do AWS CDK preenche as lacunas entre as atividades de desenvolvimento e operação, aplicando a automação na criação e implantação de aplicativos de BI.
Requisitos de segurança
No design de aplicativos de BI corporativos, a multilocação é um caso de uso comum, que atende vários conjuntos de usuários com uma infraestrutura. Os locatários podem ser clientes diferentes de um fornecedor independente de software (ISV) ou departamentos diferentes de uma empresa. Em um design multilocatário, cada locatário compartilha os painéis, as análises e outros ativos do QuickSight. Cada usuário, que pode ver todos os outros usuários pertencentes ao mesmo locatário (por exemplo, ao compartilhar conteúdo), permanece invisível para outros locatários. Dentro de cada locatário, a equipe de administração de BI precisa criar diferentes grupos de usuários para controlar a autorização de dados, incluindo permissões de acesso a ativos e acesso a dados em nível granular.
Vamos discutir detalhadamente alguns casos de uso de permissões de acesso a ativos. Em uma aplicação de BI, diferentes ativos são geralmente categorizados de acordo com domínios de negócios (como um painel operacional ou painel de resumo executivo) e classificação de dados (críticos, altamente confidenciais, somente internos e públicos). Por exemplo, você pode ter dois painéis para analisar dados de resultados de vendas. A aparência de ambos os painéis é semelhante, mas a classificação de segurança dos dados é diferente. Um painel, denominado Sales Critical Dashboard, contém colunas e linhas críticas de dados. O outro painel, denominado Painel altamente confidencial de vendas, contém colunas e linhas de dados altamente confidenciais. Alguns usuários recebem permissão para visualizar ambos os painéis, e outros têm permissão de nível de segurança mais baixo e só podem acessar o Painel Altamente Confidencial de Vendas.
No caso de uso a seguir, abordamos o acesso a dados em nível granular da seguinte forma:
- Acesso em nível de linha (RLS) – Para os usuários que podem acessar o Sales Critical Dashboard, alguns deles só podem visualizar dados dos EUA. No entanto, alguns utilizadores globais podem visualizar os dados de todos os países, incluindo os EUA e o Reino Unido.
- Acesso em nível de coluna (CLS) – Alguns usuários só podem visualizar colunas de dados de informações não pessoalmente identificáveis (PII) de um conjunto de dados, enquanto a equipe de RH pode visualizar todas as colunas do mesmo conjunto de dados.
Projetos grandes podem ter vários locatários, centenas de grupos e milhares de usuários em uma conta QuickSight. A equipe líder de dados deseja implantar um protocolo para criação e autenticação de usuários, a fim de reduzir o custo de manutenção e o risco de segurança. A arquitetura e o fluxo de trabalho descritos nesta postagem ajudam o líder de dados a atingir esse objetivo.
Além disso, para evitar erros humanos na operação diária, queremos que essas permissões de segurança sejam concedidas e revogadas automaticamente e se encaixem na infraestrutura de CI/CD. Os detalhes são explicados posteriormente neste post.
Visão geral da arquitetura
O diagrama a seguir mostra a arquitetura da conta QuickSight desta solução.
- Os autores criam painéis e atualizam o AWS Systems Manager Parameter Store para liberar painéis para diferentes grupos
- Os administradores aprovam as solicitações dos autores
- Os administradores atualizam o gerenciamento de usuários (funções, namespace) editando o AWS Systems ManagerParameter Store
- DevOps implanta as atualizações com AWS CDK
*Grupos: grupos de permissão de acesso a objetos controlam o proprietário/visualizador dos objetos. Grupos de segmentos de dados combinados com RLS/CLS controlam o acesso aos dados.
*Conjuntos de dados: contém todos os dados, restritos por segurança em nível de linha (RLS) e segurança em nível de coluna (CLS)
O diagrama a seguir ilustra o fluxo de trabalho de autenticação da arquitetura:
* Primeiro login no QuickSight: Se o usuário do QuickSight não estiver cadastrado antes do primeiro login, um leitor será criado e esse leitor poderá visualizar apenas o painel da landing page, que é compartilhado com todos os usuários desta conta. A página inicial fornece a lista de relatórios que esse usuário pode visualizar.
O diagrama a seguir ilustra o fluxo de trabalho de autorização da arquitetura.
Detalhes do diagrama de autorização:
- As informações do usuário (departamento, equipe, localização geográfica) são armazenadas no Amazon Redshift, Amazon Athena ou qualquer outro banco de dados. Combinados com o mapeamento de grupo de usuários, os bancos de dados RLS são criados para controlar o acesso aos dados.
- Atribuição de permissões por hora:
- De acordo com o mapeamento de nome de funcionário de grupo (usuário) (membership.csv) e mapeamento de função de grupo (/qs/console/roles), uma função AWS Lambda cria grupos, registra, usuários, atribui membros de grupo, remove associações de grupo, promove leitores para autor ou administrador e exclui usuários se eles forem rebaixados de autor ou administrador para leitor.
- De acordo com o mapeamento do painel de grupo em /qs/config/access, uma função AWS Lambda atualiza as permissões do painel para grupos do QuickSight.
- De acordo com o mapeamento de namespace de grupo em member.csv, uma função AWS Lambda cria grupos QuickSight no namespace especificado.
- Parâmetros de amostra de permissões de acesso a objetos e segmentos de dados:
- Parâmetros de amostra da função de usuário QuickSight:
- Dados de amostra de member.csv:
Nesta solução, namespaces personalizados são implantados para dar suporte à multilocação. O default
namespace é para todos os usuários internos de uma empresa (nós o chamamos de OkTank). OkTank cria o 3rd-Party
namespace para usuários externos. Se precisarmos oferecer suporte a mais locatários, poderemos criar mais namespaces personalizados. Por padrão, estamos limitados a 100 namespaces por conta da AWS. Para aumentar esse limite, entre em contato com a equipe de produto QuickSight. Para obter mais informações sobre multilocação, consulte Incorpore análises multilocatário em aplicativos com o Amazon QuickSight.
Em cada namespace, criamos diferentes tipos de grupos. Por exemplo, no default
namespace, criamos o BI-Admin
e BI-Developer
grupos para o admin
e author
Comercial. Pra reader
, implantamos dois tipos de grupos QuickSight para controlar permissões de acesso a ativos e acesso a dados: grupos de permissão de acesso a objetos e grupos de segmentos de dados.
A tabela a seguir resume como os grupos de permissões de acesso a objetos controlam as permissões.
Nome do grupo | Namespace | Permissão | Notas |
critical |
Padrão | Visualize ambos os painéis (contendo dados críticos e dados altamente confidenciais) | |
highlyconfidential |
Padrão | Visualizar apenas o painel altamente confidencial de vendas | |
BI-Admin |
Padrão | Gerenciamento de contas e edição de todos os ativos | Usuários no BI-Admin grupo são atribuídos Admin Função de usuário do QuickSight. |
BI-Developer |
Padrão | Editar todos os ativos | Usuários no BI-Developer grupo recebe a função de usuário Autor QuickSight. |
Power-reader |
Padrão | Visualize todos os ativos e crie análises ad hoc para executar relatórios analíticos de autoatendimento |
Usuários no No entanto, este grupo não pode salvar nem compartilhar seus relatórios ad hoc. |
3rd-party |
Namespaces não padrão (3rd-party espaço para nome, por exemplo) |
Só pode compartilhar com leitores (3rd-party-reader grupo, por exemplo) no mesmo namespace |
Em namespaces não padrão, também podemos criar outros grupos de permissão de acesso a objetos, que são semelhantes ao grupo crítico no namespace padrão. |
Para obter mais informações sobre grupos, usuários e funções de usuário do QuickSight, consulte Gerenciar o acesso do usuário no Amazon QuickSight, Provisionamento de usuários para Amazon QuickSight e Uso de painéis administrativos para uma visualização centralizada de objetos do Amazon QuickSight.
O segundo tipo de grupos (grupos de segmentos de dados), combinados com segurança em nível de linha conjuntos de dados e segurança em nível de coluna, controle o acesso aos dados conforme descrito na tabela a seguir.
Nome do grupo | Namespace | Permissão | Objetivo |
USA |
Padrão | Visualize apenas dados dos EUA em qualquer painel | Nível de linha |
GBR |
Padrão | Visualize apenas dados do Reino Unido em qualquer painel | Nível de linha |
All countries |
Padrão | Visualize dados de todos os países em qualquer painel | Nível de linha |
non-PII |
Padrão | Não é possível visualizar os números da Previdência Social, a renda anual e todas as outras colunas de dados PII | Nível de coluna |
PII |
Padrão | Pode visualizar todas as colunas, incluindo dados PII | Nível de coluna |
Podemos configurar grupos semelhantes em namespaces não padrão.
Esses diferentes grupos podem se sobrepor. Por exemplo, se um usuário pertence aos grupos USA
, Critical
e PII
, eles poderão visualizar dados dos EUA em ambos os painéis, com todas as colunas. O diagrama de Venn a seguir ilustra as relações entre esses grupos.
Em resumo, podemos definir uma arquitetura de segurança multifacetada combinando recursos do QuickSight, incluindo namespace, grupo, usuário, RLS e CLS. Todas as configurações relacionadas são salvas no Parameter Store. A lista de usuários do QuickSight e as informações de mapeamento de usuários do grupo estão em um Serviço de armazenamento simples da Amazon (Amazon S3) como um arquivo CSV (denominado membership.csv
). Este arquivo CSV pode ser resultado de consultas LDAP. Diversos AWS Lambda funções são programadas para serem executadas de hora em hora (você também pode invocar essas funções sob demanda, como diária, semanal ou qualquer granularidade de tempo que atenda às suas necessidades) para ler os parâmetros e o membership.csv
. De acordo com a configuração definida, as funções do Lambda criam, atualizam ou excluem grupos, usuários e permissões de acesso a ativos.
Quando as configurações de segurança necessárias são concluídas, uma função Lambda chama as APIs QuickSight para obter as informações atualizadas e registrar os resultados em um bucket S3 como arquivos CSV. A equipe de administração de BI pode criar conjuntos de dados com esses arquivos e visualizar os resultados em painéis. Para mais informações, veja Uso de painéis administrativos para uma visualização centralizada de objetos do Amazon QuickSight e Criação de um console administrativo no Amazon QuickSight para analisar métricas de uso.
Além disso, os erros das funções Lambda e os eventos de exclusão do usuário são armazenados neste bucket S3 para revisão pela equipe administrativa.
Automação
O diagrama a seguir ilustra o fluxo de trabalho geral das funções do Lambda.
Usamos um método programável para criar e configurar grupos e usuários automaticamente. Para qualquer solicitação de registro de usuário ad hoc (como o usuário não está registrado no membership.csv
ainda devido à latência), desde que o usuário possa ser autenticado, ele poderá assumir o Gerenciamento de acesso e identidade da AWS (IAM) papel quicksight-fed-user
para autoprovisionamento como um leitor QuickSight. Esse leitor autoprovisionado só pode visualizar um painel da página inicial, que fornece a lista de painéis e grupos correspondentes. De acordo com o mapeamento dashboard-grupo, esse novo leitor pode solicitar adesão a um determinado grupo para acessar os dashboards. Se o proprietário do grupo aprovar o aplicativo, as funções do Lambda por hora adicionarão o novo usuário ao grupo na próxima vez que forem executadas.
O pipeline de CI/CD começa no AWS CDK. O administrador e autor do BI pode atualizar os parâmetros do Systems Manager para liberar novos painéis ou outros ativos do QuickSight na pilha do AWS CDK granular_access_stack.py
. O administrador do BI pode atualizar os parâmetros do Systems Manager na mesma pilha para criar, atualizar ou excluir namespaces, grupos ou usuários. Em seguida, a equipe de DevOps pode implantar a pilha AWS CDK atualizada para aplicar essas alterações aos parâmetros do Systems Manager ou a outros recursos da AWS. As funções do Lambda são acionadas de hora em hora para chamar APIs e aplicar alterações à conta QuickSight relacionada.
Escala
As funções Lambda são restritas ao tempo de execução máximo de 15 minutos. Para superar esta limitação, podemos converter as funções Lambda para Cola AWS Scripts de shell Python com as seguintes etapas de alto nível:
- Baixar boto3 arquivos de roda de pypi.org.
- Faça upload do arquivo wheel em um bucket S3.
- Faça o download do Funções lambda e mescle-os em um script Python e crie um script de shell Python do AWS Glue.
- Adicione o caminho S3 do arquivo wheel Boto3 ao caminho da biblioteca Python. Se você tiver vários arquivos para adicionar, separe-os com vírgula.
- Programe este trabalho do AWS Glue para ser executado diariamente.
Para mais informações, consulte Programar scripts ETL do AWS Glue em Python e Usando bibliotecas Python com AWS Glue.
Pré-requisitos
Você deve ter os seguintes pré-requisitos para implementar esta solução:
- Uma conta QuickSight Enterprise
- Conhecimento básico de Python
- Conhecimento básico de SQL
- Conhecimento básico de BI
Crie os recursos
Crie seus recursos baixando a pilha do AWS CDK no site GitHub repo.
No granular_access
pasta, execute o comando cdk deploy granular-access
para implantar os recursos. Para mais informações, veja Workshop de introdução ao AWS CDK: Workshop Python.
Implante a solução
Ao implantar a pilha AWS CDK, ela cria cinco funções Lambda, conforme mostrado na captura de tela a seguir.
A pilha também cria recursos de suporte adicionais em sua conta.
A granular_user_governance
função é acionada pelo Amazon CloudWatch regra de evento qs-gc-everyhour
. As informações dos grupos e usuários estão definidas no arquivo membership.csv
. O nome do bucket S3 é armazenado no armazenamento de parâmetros /qs/config/groups
. O diagrama a seguir mostra o fluxograma desta função.
- Defina o destino de
granular_user_governance
para outra função Lambda,downgrade_user
, comsource=Asynchronous invocation
econdition=On Success
.
O diagrama a seguir é um fluxograma desta função.
Para evitar quebrar o acesso crítico aos ativos do QuickSight governados por Administrador ou Autor, rebaixamos um administrador ou autor excluindo o usuário administrador ou autor e criando um novo usuário leitor com a função Lambda downgrade_user
. O granular_user_governance
A função lida com o downgrade de admin para autor ou com a atualização de autor para admin.
- Defina o destino de
downgrade_user
para a função Lambdagranular_access_assets_govenance
comsource=Asynchronous invocation
econdition=On Success
.
O diagrama a seguir mostra um fluxograma desta função.
- Defina o destino de
downgrade_user
para a função Lambdacheck_team_members
comsource=Asynchronous invocation
econdition=On Failure
.
A check_team_members
A função simplesmente chama APIs QuickSight para obter informações de namespaces, grupos, usuários e ativos e salva os resultados no bucket S3. A chave S3 é monitoring/quicksight/group_membership/group_membership.csv
e monitoring/quicksight/object_access/object_access.csv
.
Além dos dois arquivos de saída da etapa anterior, os logs de erros e os logs de exclusão de usuários (logs de downgrade_user
) também são salvos no monitoring/quicksight
pasta.
- Defina o destino de
granular_access_assets_govenance
para a função Lambdacheck_team_members
comsource=Asynchronous invocation
econdition=On Success
orcondition=On Failure
.
Crie conjuntos de dados de segurança em nível de linha
Como etapa final, criamos conjuntos de dados RLS. Isso permite alterar os registros do painel com base nos usuários que visualizam os painéis.
QuickSight oferece suporte a RLS aplicando um conjunto de dados gerenciado pelo sistema que subseleciona registros do conjunto de dados do painel. O mecanismo permite que o administrador forneça um conjunto de dados de filtragem (o conjunto de dados RLS) com username
or groupname
colunas, que são filtradas automaticamente para o usuário que está logado. Por exemplo, um usuário chamado YingWang
pertence ao grupo QuickSight BI
, portanto, todas as linhas do conjunto de dados RLS que correspondem ao nome de usuário YingWang
ou nome do grupo BI
são filtrados. As linhas que permanecem no RLS após a aplicação dos filtros de nome de usuário e de grupo são então usadas para filtrar ainda mais os conjuntos de dados do painel, combinando colunas com os mesmos nomes. Para obter mais informações sobre segurança em nível de linha, consulte Usando segurança em nível de linha (RLS) para restringir o acesso a um conjunto de dados.
Nesta solução, exportamos as informações de amostra do usuário para o arquivo membership.csv
, que é armazenado em um bucket S3. Neste arquivo, fornecemos alguns grupos de amostra para definição do conjunto de dados RLS. Esses grupos são os grupos de segmentos de dados, conforme descrito no design geral da arquitetura. A captura de tela a seguir mostra alguns dos grupos e os usuários desses grupos.
A granular_user_governance
A função cria esses grupos e adiciona os usuários relacionados como membros desses grupos.
Como criamos o conjunto de dados RLS? Digamos que temos uma mesa chamada employee_information
no banco de dados de RH da nossa organização. A captura de tela a seguir mostra alguns dados de amostra.
Com base nas employee_information
tabela, criamos uma visão chamada rls
para um conjunto de dados RLS. Veja o seguinte código SQL:
A captura de tela a seguir mostra nossos dados de amostra.
Agora que temos a tabela pronta, podemos criar o conjunto de dados RLS com o seguinte SQL customizado:
A captura de tela a seguir mostra nossos dados de amostra.
Para o grupo quicksight-fed-all-countries
, definimos o username
, country
e city
como nulo, o que significa que todos os usuários deste grupo podem visualizar os dados de todos os países.
Para o nível de país, apenas as regras de segurança definidas no groupname
e país columns
são usados para filtragem. O username
e city
colunas são definidas como nulas. Os usuários no quicksight-fed-usa
grupo pode visualizar os dados dos EUA e os usuários no quicksight-fed-gbr
grupo pode visualizar os dados do GBR.
Para cada usuário com groupname
definido como nulo, eles só poderão visualizar o país e a cidade específicos atribuídos ao seu nome de usuário. Por exemplo, TerryRigaud
só pode visualizar dados de Austin, nos EUA.
No QuickSight, várias regras em um conjunto de dados RLS são combinadas com OR.
Com essas regras RLS multifacetadas, podemos definir um padrão abrangente de acesso a dados.
limpar
Para evitar cobranças futuras, exclua os recursos criados executando o seguinte comando:
Conclusão
Esta postagem discutiu como os administradores de BI podem projetar e automatizar a autenticação QuickSight e o controle de acesso granular de autorização. Combinamos recursos de segurança do QuickSight, como segurança em nível de linha e coluna, grupos e namespaces para fornecer uma solução abrangente. O gerenciamento dessas mudanças por meio de “BIOps” garante um mecanismo robusto e escalável para gerenciar a segurança do QuickSight. Aprender mais, inscreva-se para uma demonstração do QuickSight.
Sobre os autores
Ying wang é engenheiro sênior de visualização de dados com prática especializada global em dados e análise em serviços profissionais da AWS.
Amir Bar ou é arquiteto de dados principal na AWS Professional Services. Depois de 20 anos liderando organizações de software e desenvolvendo plataformas e produtos de análise de dados, ele agora compartilha sua experiência com grandes clientes empresariais e os ajuda a dimensionar sua análise de dados na nuvem.
- "
- &
- 100
- Acesso
- gerenciamento de acesso
- Conta
- atividades
- Ad
- Adicional
- admin
- Todos os Produtos
- Amazon
- análise
- analítica
- APIs
- Aplicação
- aplicações
- arquitetura
- ativo
- Ativos
- austin
- Autenticação
- autorização
- Automação
- AWS
- AWS Lambda
- MELHOR
- melhores práticas
- fronteira
- construir
- Prédio
- negócio
- inteligência de negócios
- chamada
- casos
- alterar
- acusações
- Cidades
- classificação
- Na nuvem
- código
- comum
- Empresa
- conteúdo
- países
- Criar
- Clientes
- painel de instrumentos
- dados,
- acesso a dados
- Análise de Dados
- gestão de dados
- Visualização de dados
- banco de dados
- bases de dados
- Demanda
- Design
- destruir
- detalhe
- desenvolvedores
- Desenvolvimento
- DevOps
- domínios
- engenheiro
- Empreendimento
- clientes corporativos
- Evento
- eventos
- executivo
- exportar
- Funcionalidades
- filtros
- Primeiro nome
- primeira vez
- caber
- Quadro
- função
- futuro
- Global
- subsídios
- Grupo
- Como funciona o dobrador de carta de canal
- hr
- HTTPS
- Centenas
- IAM
- Dados de identificação:
- Incluindo
- Passiva
- Crescimento
- INFORMAÇÕES
- Infraestrutura
- integração
- Inteligência
- IT
- Trabalho
- juntar
- Chave
- Conhecimento
- página de destino
- grande
- ldap
- principal
- APRENDER
- Nível
- Biblioteca
- Limitado
- Line
- Lista
- localização
- longo
- de grupos
- Membros
- nomes
- números
- ordem
- Outros
- Outros
- proprietário
- senhas
- padrão
- Pii
- Plataformas
- Privacidade
- Diretor
- Produto
- Produtos
- projeto
- projetos
- público
- Python
- Leitor
- leitores
- registros
- reduzir
- Registo
- Relacionamentos
- Relatórios
- Requisitos
- Recursos
- Resultados
- rever
- Risco
- regras
- Execute
- corrida
- vendas
- Escala
- segurança
- Autoatendimento
- Serviços
- conjunto
- Partilhar
- ações
- concha
- simples
- So
- Redes Sociais
- Software
- SQL
- armazenamento
- loja
- ajuda
- suportes
- sistemas
- tempo
- Uk
- união
- Atualizar
- Atualizações
- us
- Estados Unidos
- usuários
- Ver
- visualização
- semanal
- Roda
- QUEM
- dentro
- de gestão de documentos
- anos