Ir para conteúdo principal

Gerenciando a segurança dos dados com o Section Access

O Section Access é usado para controlar a segurança de um aplicativo. Basicamente, ele é uma parte do script de carregamento de dados em que você adiciona uma tabela de segurança para definir quem consegue ver o quê. O Qlik Sense SaaS usa essas informações para reduzir os dados ao escopo apropriado quando o usuário abre o aplicativo, ou seja, alguns dados no aplicativo são ocultados do usuário com base em sua identidade. O Section Access está estreitamente integrado aos dados no aplicativo e depende dele para controlar o acesso. Essa forma de redução dinâmica de dados pode estar voltada para linhas de tabela, colunas de tabela ou uma combinação de ambas. Para mais informações, consulte Confiança e segurança na Qlik.

Seções no script de carregamento

O controle de acesso a dados é gerenciado por meio de uma ou mais tabelas de segurança carregadas da mesma maneira que os dados normalmente são carregados. Isso possibilita armazenar essas tabelas em um banco de dados padrão ou em uma planilha. As instruções de script que gerenciam as tabelas de segurança são fornecidas em uma seção de autorização, que no script é iniciada pela instrução Section Access.

Se uma seção de autorização for definida no script, a parte do script que carrega os dados do aplicativo deverá ser colocada em uma seção diferente, iniciada pela instrução Section Application.

Exemplo:  

Section Access; Load * INLINE [ ACCESS, USER.EMAIL, REDUCTION USER, USER1@example.com, * USER, USER2@example.com, 1 USER, USER3@example.com, 2 ADMIN, USER4@example.com, ]; Section Application; T1: Load *, NUM AS REDUCTION; LOAD Chr(RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

Observe que, depois de fazer alterações no script de carregamento, você sempre deve carregar os dados para que as alterações tenham efeito.

Campos do sistema do Section Access

Os níveis de acesso são atribuídos a usuários em uma ou mais tabelas de segurança carregadas na parte Section Access do script. Essas tabelas devem conter pelo menos dois campos do sistema: ACCESS, que é o campo que define o nível de acesso, e USERID ou USER.EMAIL . Outros campos opcionais do sistema podem ser adicionados dependendo do caso de uso. O conjunto completo de campos do sistema do section access está descrito abaixo.

ACCESS

Define o tipo de acesso que o usuário correspondente deve ter.

O acesso a aplicativos do Qlik Sense pode ser autorizado para usuários especificados. Na tabela de segurança, é possível atribuir os níveis de acesso ADMIN ou USER aos usuários. Um usuário com privilégios ADMIN tem acesso a todos os dados no aplicativo, a menos que limitado pela tabela de segurança. Um usuário com privilégios USER só pode acessar dados conforme definido na tabela de segurança. Se nenhum nível de acesso for atribuído, o usuário não poderá abrir o aplicativo.

USERID

Contém um caractere correspondente a um nome de usuário Qlik Sense SaaS. O Qlik Sense SaaS obterá as informações de logon do requerente IdP e as comparará com o valor nesse campo. Para conhecer uma maneira alternativa de verificar a identidade do usuário usando o endereço de e-mail, consulte USER.EMAIL. Para ambientes com várias nuvens, o requerente IdP pode ser mapeado em relação à sua identidade interna do Windows. Ao usar o Qlik Account, o requerente não pode ser mapeado em relação à identidade interna do Windows. O requerente IdP pode ser visualizado na seção Usuários do Management Console.

Um caractere curinga (*) é interpretado como todos os usuários, sujeito a outras condições especificadas na tabela de segurança. Por exemplo, na tabela de segurança a seguir, os usuários que estão em Qlik Sense Tenant Admins podem ver todos os valores REDUCTION listados.

Section Access; LOAD * INLINE [ ACCESS, USERID, GROUP, REDUCTION ADMIN, *, Qlik Sense Tenant Admins, * USER, QLIK-POC\SOMEOTHERUSER1, *, 1 USER, QLIK-POC\SOMEOTHERUSER2, *, 2 ... ];
Nota informativa O USERID e o NTNAME usam as mesmas informações de autenticação e, portanto, não é necessário verificar ambos na mesma linha na tabela de segurança. A diferença entre os dois campos é que NTNAME também verifica grupos.

NTNAME

Nota informativaNTNAME é um campo herdado do QlikView, e é recomendado usar USERID se o QlikView não estiver usando a mesma tabela de segurança.

Um campo que deve conter uma sequência de caracteres correspondente à versão NetBIOS de um nome de usuário ou grupo de domínio do Windows NT. Se um sistema de autenticação diferente for usado, ele deverá conter o nome de um usuário autenticado.

O Qlik Sense SaaS buscará as informações de logon da declaração subject do provedor de identidade e as comparará com o valor nesse campo.

USER.EMAIL

Contém uma sequência de caracteres correspondente a um endereço de e-mail de usuário. O Qlik Sense SaaS obterá essas informações do provedor de identidade e as comparará com o valor nesse campo.

GROUP

Contém um caractere correspondente a um grupo no Qlik Sense SaaS. O Qlik Sense SaaS obterá as informações da declaração “groups” do provedor de identidade e as comparará com o valor nesse campo.

Nota informativaOs grupos de usuários não têm suporte no Qlik Sense Business ou ao usar o Provedor de identidade (IdP) da Qlik.

OMIT

Contém o nome do campo que deve ser omitido para esse usuário específico. Os caracteres curinga podem ser usados e o campo pode ficar vazio.

Nota informativaÉ recomendado que você não aplique OMIT em campos de chave. Os campos chave que são omitidos estão visíveis no visualizador do modelo de dados, mas o conteúdo não está disponível, o que pode ser confuso para o usuário. Além disso, a aplicação de OMIT em campos que são usados em uma visualização pode resultar em uma visualização incompleta para usuários que não têm acesso aos campos omitidos.

Gerenciando o acesso do usuário a um aplicativo

Um usuário com USERID AD_DOMAIN\C não seria capaz de abrir o aplicativo porque esse ID de usuário não está listado na tabela de segurança.

O Section Access, em sua forma mais simples, pode ser usado para impedir que usuários específicos acessem um aplicativo. Os usuários têm acesso negado a um aplicativo por meio de exclusão. Em outras palavras, se o endereço de e-mail de um usuário específico não estiver listado na tabela de segurança, ele não poderá acessar o aplicativo. A única exceção a essa regra é se um curinga (*) for atribuído ao campo USER.EMAIL em uma das linhas da tabela de segurança. Um curinga, nesse caso, significa que todos os usuários autenticados podem acessar o aplicativo. Aqui está um exemplo de uma tabela de segurança com uma lista de IDs de usuário:

Section Access; LOAD * inline [ ACCESS, USER.EMAIL ADMIN, USER1@example.com USER, USER2@example.com USER, USER3@example.com ]; Section Application;

Um usuário com USER.EMAIL USER4@example.com não seria capaz de abrir o aplicativo, pois o endereço de e-mail do usuário não está listado na tabela de segurança.

Gerenciando o acesso dos usuários a dados específicos em um aplicativo

A redução dinâmica de dados limita o acesso a linhas e colunas nas tabelas de dados de um aplicativo do Qlik Sense depois que um usuário recebeu autorização para acessar esse aplicativo.

Gerenciando o acesso a dados em nível de linha

Restrinja o acesso a dados em nível de linha adicionando uma coluna de redução de dados à tabela de segurança na seção de acesso do script de carregamento. Registros (linhas) específicos podem ser ocultos dos usuários por meio da vinculação dos dados do Section Access aos dados reais. A seleção dos dados a serem exibidos ou excluídos é controlada pela presença de um ou mais campos de redução com nomes comuns nas partes Section Access e Section Application do script. Após o login do usuário, o Qlik Sense corresponde às seleções em campos de redução no Section Access a quaisquer campos no Application Section com exatamente os mesmos nomes de campo (que devem ser escritos em maiúsculas). Feitas as seleções, o Qlik Sense oculta permanentemente do usuário todos os dados excluídos por essas seleções. Se um curinga (*) for usado como um valor de campo na coluna de redução de dados, ele será interpretado como permitindo que o usuário acesse os registros associados a todos os campos de redução selecionados na tabela de segurança.

Nota informativa

O curinga * na coluna de redução de dados refere-se apenas a todos os valores na tabela de segurança. Se houver valores no Section Application que não estão disponíveis na coluna de redução da tabela de segurança, eles serão reduzidos.

Nota informativaTodos os nomes de campos usados na transferência descrita anteriormente e todos os valores nesses campos devem estar em letras maiúsculas, pois todos os nomes e valores de campo são, por padrão, convertidos em maiúsculas no Section Access.

Exemplo: Redução de dados em nível de linha com base na identidade do usuário

Section Access; Authorization: LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION ADMIN, USER1@example.com, * USER, USER2@example.com, 1 USER, USER3@example.com, 2 USER, USER4@example.com, * ]; Section Application; T1: LOAD *, NUM AS REDUCTION; LOAD RecNo() AS NUM AUTOGENERATE 3;

Neste exemplo, o campo REDUCTION (em maiúsculas) existe no Section Access e no Section Application (todos os valores de campo também estão em maiúsculas). Normalmente, os dois campos seriam totalmente diferentes e separados. Porém, ao usar o Section Access, esses campos são vinculados, e o número de registros exibidos ao usuário é reduzido.

O resultado será:

  • O usuário USER1@example.com poderá visualizar todos os campos e apenas os registros que outros usuários podem visualizar quando REDUCTION = 1 ou REDUCTION =2.
  • O usuário USER2@example.com poderá visualizar todos os campos, mas apenas os registros associados a REDUCTION=1.
  • O usuário USER3@example.com poderá visualizar todos os campos, mas apenas os registros associados a REDUCTION=2.
  • O usuário USER4@example.com poderá visualizar todos os campos e apenas os registros que outros usuários podem visualizar quando REDUCTION = 1 ou REDUCTION =2.

Gerenciando o acesso a dados em nível de coluna

Restrinja o acesso a dados em nível de coluna adicionando o campo do sistema OMIT à tabela de segurança no script do Section Access. O exemplo a seguir baseia-se no exemplo anterior, em que a redução de dados de linha já está em vigor.

Exemplo: Redução de dados de coluna com base na identidade do usuário

Section Access; LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION, OMIT ADMIN, USER1@example.com, *, USER, USER2@example.com, 1, USER, USER3@example.com, 2, NUM USER, USER4@example.com, 3, ALPHA ]; Section Application; T1: LOAD *, NUM AS REDUCTION; LOAD Chr( RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

O campo OMIT no Section Access define os campos que devem ser ocultos do usuário.

O resultado será:

  • O usuário USER1@example.com poderá visualizar todos os campos e apenas os registros que outros usuários podem visualizar neste exemplo quando REDUCTION for 1, 2 ou 3.
  • O usuário USER2@example.com poderá visualizar todos os campos, mas apenas os registros associados a REDUCTION=1.
  • O usuário USER3@example.com poderá visualizar todos os campos, exceto NUM, e apenas os registros associados a REDUCTION=2.
  • O usuário USER4@example.com poderá visualizar todos os campos, exceto ALPHA, e apenas os registros associados a REDUCTION=3.
Nota informativaAlgumas visualizações têm requisitos mínimos de dados que devem ser atendidos para que possam ser renderizadas. Como resultado, a indicação "Visualização incompleta" pode ser exibida quando um campo em nível de coluna é omitido da visualização de dados de um usuário.

Gerenciando o acesso a grupos de usuários

O Section Access oferece a opção de limitar o escopo dos dados visíveis aos usuários por meio da associação a grupos. Para restringir seus dados usando grupos de usuários, adicione o nome do campo GROUP à tabela de segurança no Section Access e defina valores para o campo GROUP .

Exemplo: Redução de dados com base em grupos de usuários

Section Access; LOAD * inline [ ACCESS, USERID, GROUP, REDUCTION, OMIT USER, *, ADMIN, *, USER, *, A, 1, USER, *, B, 2, NUM USER, *, C, 3, ALPHA USER, *, GROUP1, 3, ADMIN, AD_DOMAIN\DEV, *, *, ]; section application; T1: LOAD *, NUM AS REDUCTION; LOAD Chr( RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

O resultado será:

  • Os usuários pertencentes ao grupo ADMIN podem visualizar todos os dados e todos os campos.
  • Os usuários pertencentes ao grupo A podem ver dados associados a REDUCTION=1 em todos os campos.
  • Os usuários pertencentes ao grupo B podem visualizar dados associados a REDUCTION=2, mas não no campo NUM
  • Os usuários pertencentes ao grupo C podem visualizar dados associados a REDUCTION=3, mas não no campo ALPHA
  • Os usuários pertencentes ao grupo GROUP1 podem ver dados associados a REDUCTION=3 em todos os campos
  • O usuário AD_DOMAIN\DEV tem permissão para visualizar todos os dados em todos os campos.

O Qlik Sense SaaS compara o usuário com UserID e resolve o usuário em relação aos grupos na tabela. Se o usuário pertencer a um grupo com acesso permitido ou se o usuário corresponder, ele poderá acessar o aplicativo.

Carregando dados no Qlik Sense SaaS

Para carregar um aplicativo sem redução de dados no Qlik Sense SaaS, é recomendável usar o campo do sistema USER.EMAIL na tabela de segurança. O valor do campo USER.EMAIL deve ser o endereço de e-mail de usuários que são capazes de editar e carregar o aplicativo. Isso é válido para aplicativos em espaços compartilhados e gerenciados. Por exemplo:

Section Access; LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION ADMIN, test@example.com, * ];

Neste exemplo, o usuário com endereço de e-mail test@example.com é ADMIN e é capaz de carregar o aplicativo.

Se você estiver usando grupos, o exemplo a seguir funcionará igualmente para Qlik Sense e Qlik Sense SaaS:

Section Access; LOAD * inline [ ACCESS, GROUP, REDUCTION ADMIN, Developers, * ];

Você também pode mapear o USERID na tabela de segurança para o subject claim do Provedor de Identidade, conforme mostrado no exemplo a seguir. Essa configuração é sugerida para migrar do Qlik Sense para o Qlik Sense SaaS e para ambientes de várias nuvens. Para obter mais informações sobre como mapear o USERID para o subject claim, consulte Gerenciando o acesso do usuário em um ambiente de várias nuvens

Section Access; LOAD * inline [ ACCESS, USERID, REDUCTION ADMIN, AD_DOMAIN\DEV, * ];

Gerenciando o acesso do usuário em um ambiente de várias nuvens

Um ambiente de várias nuvens do Qlik Sense envolve uma combinação de mecanismos de autenticação de usuário. Normalmente, com o Qlik Sense Enterprise on Windows, o USERID na tabela de segurança do Section Access é verificado pelo serviço de proxy. No Qlik Sense SaaS, um provedor de identidade assume essa função de autenticação. Consequentemente, o Section Access configurado para um ambiente local, como o Qlik Sense Enterprise on Windows, não funcionará em um ambiente de nuvem.

Ao usar um provedor de identidade OIDC (Qlik IdP ou IdP personalizado) com o Qlik Sense SaaS, o subject claim é usado para identificar usuários ao efetuar login. Com o Section Access, o valor do campo USERID na tabela de segurança é comparado ao valor do subject claim. Ao configurar seu locatário, certifique-se de que o nome da conta SAM esteja mapeado para o subject claim do seu provedor de identidade. Assim, por exemplo, se o nome da sua conta SAM for AD_DOMAIN\\Dev, defina o subject claim como AD_DOMAIN\\Dev. Se quiser ver o valor da subject claim do IdP, anexe /api/v1/diagnose-claims à URL do locatário no navegador, por exemplo, your-tenant.us.qlikcloud.com/api/v1/diagnose-claims. Na resposta JSON, o subject claim é chamado sub.

Se você não consegue usar o nome da conta SAM, há uma maneira alternativa de autenticar um usuário. Como os endereços de e-mail tendem a permanecer os mesmos em ambientes diferentes, você pode usar o campo USER.EMAIL em vez de USERID na tabela de segurança. Aqui está um exemplo de tabela de segurança:

ACCESS USERID USER.EMAIL Comentário COUNTRY
USER ABC\Joe * Access-on-prem Estados Unidos
USER * joe.smith@example.com Access-in-cloud Estados Unidos
USER ABC\Ursula * Access-on-prem Alemanha
USER * ursula.schultz@example.com Access-in-cloud Alemanha
USER ABC\Stefan * Access-on-prem Sweden
USER * stefan.svensson@example.com Access-in-cloud Sweden

Script de autorização:

Section Access; LOAD * INLINE [ ACCESS, USERID, USER.EMAIL, COUNTRY USER, ABC\Joe, *, United States USER, *, joe.smith@example.com, United States USER, ABC\Ursula, *, Germany USER, *, ursula.schultz@example.com, Germany USER, ABC\Stefan, *, Sweden USER, *, stefan.svensson@example.com, Sweden ];

Observe que cada usuário tem dois registros: Um para acesso no local e outro para acesso na nuvem. Os curingas garantem que somente os campos de autenticação relevantes sejam usados. Nesse exemplo, COUNTRY é usado como um campo de redução de dados.

Campos de autorização do QlikView

Para compatibilidade com versões anteriores, o Qlik Sense SaaS reconhece os campos de autorização do QlikView. Apesar de USERID ser interpretado de maneira diferente no QlikView e no Qlik Sense SaaS, no Qlik Sense SaaS, ele será interpretado da mesma forma que no Qlik Sense: Ele será comparado com o nome do usuário autenticado.

PASSWORD, NTSID e NTDOMAINSID

Se um dos campos PASSWORD, NTSID e NTDOMAINSID for usado e contiver um valor relevante, o acesso ao documento será negado. Se o campo contiver um curinga (*), o acesso poderá ser concedido dependendo dos outros campos na tabela de autorização.

SERIAL

Se o campo SERIAL for usado e contiver um número de licença, a linha Section Access negará o acesso ao documento. Se o campo contiver um curinga (*), o acesso poderá ser concedido dependendo dos outros campos na tabela de autorização.

Além disso, no Qlik Sense SaaS, esse campo também pode ser usado para definir o ambiente. Isso significa que se o campo contiver a sequência de caracteres ‘QLIKCLOUD’, o acesso poderá ser concedido, dependendo dos outros campos da tabela de autorização.

Ambientes mistos

Se você planeja usar a mesma tabela de segurança no QlikView e no Qlik Sense SaaS, lembre-se do seguinte:

USERID tem diferentes significados no QlikView e no Qlik Sense SaaS e, se usado, pode causar problemas de segurança. Use NTNAME em vez disso ou combine-o com SERIAL, conforme descrito abaixo.

GROUP e campos que começam com ‘USER.’, como 'USER.NAME' e 'USER.EMAIL', são (ou serão) campos autorizadores no Qlik Sense SaaS. Se você usar esses campos no Section Access, o acesso poderá ser negado no Qlik Sense SaaS.

• O PASSWORD, NTSID e o NTDOMAINSID não podem ser usados no Qlik Sense SaaS. O acesso será negado, a menos que um caractere curinga seja usado.

• O SERIAL não pode ser usado para verificar o número da licença no Qlik Sense SaaS. No entanto, se esse campo contiver a sequência de caracteres ‘QLIKCLOUD’, o acesso poderá ser concedido. Isso significa que é possível ter uma tabela de segurança como a seguinte, em que a linha 1 concederá acesso no QlikView (mas não no Qlik Sense SaaS), enquanto a linha 2 concederá acesso no Qlik Sense SaaS (mas não no QlikView).

Tabela de segurança
Linha SERIAL USERID Comentário
1 4600 0123 4567 8901 * Concede acesso ao número de licença correto no QlikView.
2 QLIKCLOUD John Doe Concede acesso ao usuário correto no Qlik Sense SaaS.

Script de autorização:

Section Access; LOAD * INLINE [ ACCESS, USERID, SERIAL USER, *, 4600 0123 4567 8901 USER, John Doe, QLIKCLOUD ];

Usando o Section Access e o Insight Advisor Chat

Os aplicativos que usam o Section Access usam um usuário de índice para determinar a quantidade de informações que o Insight Advisor Chat recupera do aplicativo. O usuário de índice deve ser o usuário com o nível mais alto de acesso ao aplicativo no script do Section Access. Porém, os dados fornecidos aos usuários finais ainda são controlados pelas limitações do Section Access.

Nota de advertência

Se você tiver informações confidenciais em nomes de aplicativos, nomes de campos ou nomes de itens mestres, estas poderão ficar expostas ao disponibilizar aplicativos que usam o Section Access para o Insight Advisor Chat. As sugestões de aplicativos para consultas incluem aplicativos em fluxos aos quais os usuários têm acesso. Isso pode incluir aplicativos aos quais os usuários não têm acesso no Section Access de um aplicativo. Porém, a seleção desses aplicativos não terá nenhum efeito. Ao clicar em Dimensões ou Medidas para visualizar os itens disponíveis de um aplicativo usando o Section Access, os usuários podem ver itens aos quais não têm acesso. Porém, se eles clicarem nesses itens, nenhum dado será fornecido.

Por padrão, o proprietário do aplicativo é o usuário do índice. Você pode alterar o usuário de índice em Detalhes.

  1. No Qlik Cloud, navegue até o aplicativo.

  2. Clique em Mais no aplicativo e selecione Detalhes.

  3. Em Usuário do índice, selecione o usuário do índice.

  4. Clique em Voltar.

  5. Clique em Mais no aplicativo e selecione Carregar.

Diretrizes e dicas para usar o Section Access

Veja a seguir alguns fatos importantes e dicas úteis sobre o Section Access.

  • Todos os campos listados em comandos LOAD ou SELECT do Section Access devem ser escritos em maiúsculas. Converta todos os nomes de campo que contêm letras minúsculas no banco de dados para maiúsculas usando a função Upper antes de ler o campo pela instrução LOAD ou SELECT.

    Para obter mais informações, consulte Upper – função de script e gráfico.

  • Não é possível usar os nomes de campo de sistema do Section Access listados como nomes de campo no seu modelo de dados.
  • Os aplicativos devem ser publicados antes que os controles do Section Access sejam aplicados. Carregar o aplicativo não aplica nenhum script novo ou alterado de Section Access.
  • Um snapshot mostra os dados de acordo com os direitos de acesso do usuário que obtém o snapshot, e pode ser compartilhado em uma história. No entanto, quando os usuários retornam para uma visualização de uma história para ver os dados em tempo real no aplicativo, eles são limitados por seus próprios direitos de acesso.
  • Não atribua cores a valores de dimensão mestre ao usar o section access ou trabalhar com dados confidenciais, pois os valores poderão ficar expostos pela configuração de cores.
  • Para evitar a exposição de dados restritos, remova todos os arquivos anexados com as configurações de section access antes de publicar o aplicativo. Esses arquivos anexados serão incluídos quando o aplicativo for publicado. Se o aplicativo publicado for copiado, os arquivos anexos serão incluídos na cópia. No entanto, se restrições de acesso à seção tiverem sido aplicadas aos arquivos de dados anexos, as configurações de acesso à seção não serão mantidas quando os arquivos forem copiados, portanto os usuários do aplicativo copiado poderão ver todos os dados nos arquivos anexos.
  • Um curinga (*) é interpretado como todos os valores (listados) do campo na tabela. Se for utilizado em um dos campos do sistema (USERID, GROUP) em uma tabela carregada na seção de acesso do script, ele será interpretado como todos os valores possíveis desse campo (inclusive os não listados).
  • Campos de segurança podem ser colocados em tabelas diferentes.
  • Ao carregar dados de um arquivo QVD, a função Upper diminui a velocidade de carregamento.