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 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, USERID, REDUCTION USER, AD_DOMAIN\ADMIN, * USER, AD_DOMAIN\A, 1 USER, AD_DOMAIN\B, 2 USER, AD_DOMAIN\C, 3 ADMIN, INTERNAL\SA_SCHEDULER, ]; 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.

Se o Section Access for usado em um cenário de carregamento, INTERNAL\SA_SCHEDULER, que é o usuário do serviço programador, precisará de acesso ADMIN para executar carregamentos. Por exemplo:

Section Access; LOAD * inline [ ACCESS, USERID ADMIN, INTERNAL\SA_SCHEDULER ];

Se você não quiser usar a conta INTERNAL\SA_SCHEDULER, consulte Usando representação para carregar dados para conhecer um método alternativo.

Se o Section Access for usado em um cenário de geração de aplicativo sob demanda (ODAG) no aplicativo modelo, o usuário INTERNAL\SA_API deverá ser incluído como ADMIN na tabela do Section Access. Por exemplo:

Section Access; LOAD * inline [ ACCESS, USERID ADMIN, INTERNAL\SA_API ];

USERID

Contém uma string correspondente a um nome de domínio e nome de usuário do Qlik Sense. O Qlik Sense obterá as informações de logon do serviço de proxy e as comparará com o valor nesse campo.

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 ... ];

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

NTNAME é 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 a 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 buscará as informações de login do sistema operacional e as comparará com o valor nesse campo.

GROUP

Contém um caractere correspondente a um grupo no Qlik Sense. O Qlik Sense resolverá o usuário fornecido pelo serviço proxy nesse grupo.

SERIAL

SERIAL é um campo herdado do QlikView e não será usado se você estiver usando apenas o Qlik Sense.

Contém uma sequência de caracteres correspondente à plataforma. Se o campo contiver a string ‘QLIKSENSE’ ou um curinga ‘*’, o acesso poderá ser concedido dependendo dos outros campos da tabela de segurança.

Se o campo SERIAL contiver um número de licença, a linha Section Access negará o acesso ao documento. Essa configuração só é válida no QlikView.

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.

É 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

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 um ID de 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 USERID 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, USERID ADMIN, AD_DOMAIN\ADMIN USER, AD_DOMAIN\A USER, AD_DOMAIN\B ]; Section Application;

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.

Quando o Qlik Sense está comparando o campo de redução no Section Access aos campos no modelo de dados, os seguintes comportamentos são esperados:

Se um valor de campo no modelo de dados corresponder ao campo de redução no Section Access, o aplicativo será aberto mostrando os dados associados à correspondência para o usuário especificado. Outros dados serão ocultados.
Se o valor do campo de redução não corresponder a nenhum dos valores no modelo de dados, o aplicativo não será aberto para um USUÁRIO normal. No entanto, abrirá sem redução para um usuário marcado como ADMIN.

O uso de vários campos redutores no Section Access não é recomendado, pois permitirá outras combinações de acesso além das pretendidas.

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.

Todos 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.

Por padrão, se você quiser habilitar o carregamento do script em uma tarefa do Qlik Management Console, o usuário da conta do INTERNAL\SA_SCHEDULER com acesso ADMIN será necessário. Se você não quiser usar a conta INTERNAL\SA_SCHEDULER, consulte Usando representação para carregar dados para conhecer um método alternativo.

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

Section Access; Authorization: LOAD * inline [ ACCESS, USERID, REDUCTION ADMIN, AD_DOMAIN\ADMIN, * USER, AD_DOMAIN\A, 1 USER, AD_DOMAIN\B, 2 USER, AD_DOMAIN\C, * ADMIN, INTERNAL\SA_SCHEDULER, * ]; 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 ADMIN poderá visualizar todos os campos e apenas os registros que outros usuários podem visualizar quando REDUCTION = 1 ou REDUCTION =2.
O usuário A poderá visualizar todos os campos, mas apenas os registros associados a REDUCTION=1.
O usuário B poderá visualizar todos os campos, mas apenas os registros associados a REDUCTION=2.
O usuário C 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, USERID, REDUCTION, OMIT ADMIN, AD_DOMAIN\ADMIN, *, USER, AD_DOMAIN\A, 1, USER, AD_DOMAIN\B, 2, NUM USER, AD_DOMAIN\C, 3, ALPHA ADMIN, INTERNAL\SA_SCHEDULER, *, ]; 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 ADMIN 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 A poderá visualizar todos os campos, mas apenas os registros associados a REDUCTION=1.
O usuário B poderá visualizar todos os campos, exceto NUM, e apenas os registros associados a REDUCTION=2.
O usuário C poderá visualizar todos os campos, exceto ALPHA, e apenas os registros associados a REDUCTION=3.

Algumas 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, INTERNAL\SA_SCHEDULER, *, *, ]; 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 têm permissão para ver todos os campos e apenas os registros que outros usuários podem ver neste exemplo quando REDUCTION é 1, 2 ou 3.
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 Qlik Sense 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.

Usando representação para carregar dados

Por padrão, a conta interna do sistema, SA_SCHEDULER, é usada para executar tarefas de carregamento. Essa conta tem privilégios elevados e, tecnicamente, pode usar qualquer fonte de dados. No entanto, há uma configuração no QMC que usa a representação para executar tarefas de carregamento com as permissões do proprietário do aplicativo em vez da conta interna do sistema. Ao definir essa configuração, o proprietário do aplicativo, e não SA_SCHEDULER, é usado para carregamentos, o que significa que você não adiciona SA_SCHEDULER na tabela do Section Access, mas, em vez disso, adiciona o proprietário do aplicativo. Dentro de uma cadeia de tarefas, os aplicativos podem ter diferentes proprietários com permissões para fontes dependentes dos direitos de acesso de cada proprietário. Consulte Cluster de serviços (somente em inglês) para obter mais informações.

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 Cloud, 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 Cloud, 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.

Usando o Section Access e o Insight Advisor Chat

Para fazer com que aplicativos usando o Section Access estejam disponíveis no Insight Advisor Chat, você deve garantir que os seguintes usuários do serviço tenham acesso de administrador no script do Section Access:

INTERNAL/sa_repository: Isso disponibiliza o script do Section Access com o serviço de repositório para controlar o acesso do usuário.
INTERNAL/sa_scheduler: Isso permite que o aplicativo seja carregado usando tarefas do QMC.

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 exemplo:

Section Access; LOAD * inline [ USERID ,ACCESS INTERNAL\sa_repository ,ADMIN INTERNAL\sa_scheduler ,ADMIN DOMAINNAME\user1 ,ADMIN DOMAINNAME\user2 ,USER DOMAINNAME\user3 ,USER ];

Quando esses usuários estiverem no script do Section Access, você poderá disponibilizar o aplicativo para o Insight Advisor Chat. Assim que o aplicativo for carregado, ele estará disponível no Insight Advisor Chat.

Diretrizes e dicas para usar o Section Access

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

Todos os nomes de campo e valores listados em instruções LOAD ou SELECT na seção de acesso devem ser escritas em maiúsculas. Converta em maiúsculas todos os nomes de campo no banco de dados que contenham letras minúsculas, usando a função Upper antes de ler o campo com a 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.
Se você se bloqueou de um aplicativo definindo o Section Access, poderá abrir o aplicativo sem dados e editar o Section Access no script de carregamento de dados. Isso requer que você tenha acesso para editar e executar o script de carga de dados.
Para obter mais informações, consulte Abrindo um aplicativo sem dados.
Uma carga binária fará com que as restrições de acesso sejam herdadas pelo novo aplicativo Qlik Sense.

Esta página ajudou?

Se você encontrar algum problema com esta página ou seu conteúdo - um erro de digitação, uma etapa ausente ou um erro técnico - informe-nos como podemos melhorar!

Deixe seu feedback aqui