Gerenciando a segurança com section access

Você pode usar o section access no script de carregamento de dados para gerenciar o acesso a dados em nível de linha. Dessa forma, um único arquivo pode ser usado para conter os dados para usuários ou grupos de usuários.O Qlik Sense usa as informações no section access para autorização em nível de linha e reduz dinamicamente os dados para que os usuários vejam apenas aqueles que eles têm permissão de ver.

A segurança é criada no próprio arquivo, o que significa que um arquivo baixado também estará protegido até certo ponto. No entanto, se as demandas de segurança forem altas, o download de arquivos e o uso offline devem ser evitados. Os arquivos devem ser publicados apenas pelo servidor do Qlik Sense. Como todos os dados serão mantidos em um arquivo, o tamanho desse arquivo poderá ser potencialmente muito grande.

O aplicativo deve ser publicado antes que os controles do section access sejam aplicados. O carregamento do aplicativo não aplicará nenhum script novo ou alterado do section access.

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

Seções no script

O controle de acesso em nível de linha é gerenciado por meio de uma ou várias tabelas de segurança carregadas da mesma maneira como os dados são normalmente 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 estiver 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.

Example:

Section Access;

AuthorizationTable:

Load ACCESS, USERID, REGION From ... ;

Section Application;

Load ... From ... ;

Campos do sistema de seção de acesso

Os níveis de acesso são atribuídos aos usuários em uma ou várias tabelas, carregadas no section access. Essas tabelas podem conter vários campos do sistema específicos do usuário diferentes, geralmente USERID, e o campo que define o nível de acesso, ACCESS. Todos os campos do sistema de section access serão usados para autenticação ou autorização. O conjunto completo de campos do sistema de seção de acesso está descrito abaixo.

ACCESS

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

O acesso a aplicativos Qlik Sense pode ser autorizado para usuários ou grupos de usuários especificados. Na tabela de segurança, é possível atribuir os níveis de acesso ADMIN ou USER aos usuários. Se nenhum nível de acesso for atribuído, o usuário não poderá abrir o aplicativo.

Uma pessoa com privilégios de ADMIN tem acesso a todos os dados no aplicativo. Uma pessoa com privilégios de USER só pode acessar os dados definidos na tabela de segurança.

Se o section access for usado em um cenário de geração de aplicativo on-demand (ODAG) no aplicativo de amostra, o usuário INTERNAL\SA_API deverá ser incluído ADMIN na tabela do section access. Por exemplo:

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

NTNAME

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 logon do sistema operacional e as comparará com o valor nesse campo.

USERID

Contém um caractere correspondente a um nome de usuário Qlik Sense. O Qlik Sense obterá informações de logon do proxy e as comparará com o valor neste campo.

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 autorização. A diferença entre os dois campos é que NTNAME também verifica grupos.

USER.EMAIL

Atualmente sem suporte, corresponderá apenas a um curinga no Qlik Sense.

GROUP

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

Quando você usa grupos para reduzir dados e deseja acessar o Qlik Management Console, o usuário da conta INTERNAL\SA_SCHEDULER ainda é necessário.

SERIAL

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

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. Uma forma fácil de fazer isso é usar um subcampo.

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

O Qlik Sense compara o usuário com UserID e resolve o usuário com base nos grupos da tabela. Se o usuário pertencer a um grupo com acesso permitido ou se o usuário corresponder, ele poderá acessar o aplicativo.

Se você tiver se bloqueado de um aplicativo ao configurar o acesso da seção, é possível abrir o aplicativo sem dados e editar a seção de acesso no script de carga 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.

Como a mesma lógica interna, que é a marca do Qlik Sense, também é usada na seção de acesso, os campos de segurança podem ser colocados em tabelas diferentes. Todos os campos listados em instruções LOAD ou SELECT do section access devem ser escritos 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.

Um curinga (*) é interpretado como todos os valores (listados) desse campo, ou seja, um valor listado em qualquer lugar nesta 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).

Ao carregar dados de um arquivo QVD, a função Upper diminui a velocidade de carregamento.

Se você tiver habilitado a seção de acesso, não poderá usar os nomes de campo do sistema da seção de acesso listados neste como nomes de campo em seu modelo de dados.

Example:

Neste exemplo, apenas usuários do grupo Finanças podem abrir o documento.

Acesso ao documento
Acessar	Grupo
USER	Financeiro

Redução dinâmica de dados

O Qlik Sense oferece suporte para a redução dinâmica de dados, na qual parte dos dados em um aplicativo pode ser oculta do usuário, com base no login de section access:

Campos (colunas) podem ser ocultos com o uso do campo do sistema OMIT.
Os registros (linhas) podem ser ocultos, vinculando os dados de section access com os dados reais: A seleção de valores a serem exibidos ou excluídos é controlada pela existência de um ou mais campos com nomes comuns no section access e no aplicativo de seção. Após o login do usuário, o Qlik Sense corresponde às seleções nos campos do section access a quaisquer campos no section application com exatamente os mesmos nomes de campo (que devem ser escritos em maiúsculas). Depois de feitas as seleções, o Qlik Sense ocultará permanentemente do usuário todos os dados que foram excluídos por estas seleções.

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.

Se você quiser habilitar o recarregamento do script em uma tarefa Qlik Management Console, o usuário da conta do INTERNAL\SA_SCHEDULER com acesso ADMIN será necessário.

Example: Redução de dados com base no ID do usuário

Section Access; LOAD * inline [ ACCESS, USERID, REDUCTION, OMIT USER, 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;

Agora, 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 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 pode visualizar todos os campos, mas apenas os registros associados a REDUCTION=1.
O usuário B pode visualizar todos os campos, exceto NUM, e apenas os registros associados a REDUCTION=2.
O usuário C pode visualizar todos os campos, exceto ALPHA, e apenas os registros associados a REDUCTION=3.

Example: 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;