O mecanismo de segurança do QlikView pode ser configurado de duas maneiras diferentes: ele pode ser criado no script do documento QlikView ou pode ser configurado com o QlikView Publisher.
Autenticação e autorização
A autenticação é qualquer processo pelo qual você verifica se uma pessoa é quem ela diz ser. O QlikView pode permitir que o sistema operacional Windows faça a autenticação, solicite um ID de Usuário e Senha (diferentes do ID de Usuário e Senha do Windows) ou que use a chave de licença do QlikView como um método simples de autenticação.
A autorização consiste em descobrir se a pessoa, uma vez identificada, tem permissão para o recurso. O QlikView pode permitir que o sistema operacional Windows faça a autorização ou ele mesmo pode fazê-lo. No caso de ele mesmo fazer a autenticação, é necessário criar uma tabela de segurança no script.
Segurança Usando o QlikView Publisher
Se o QlikView Publisher for configurado para controlar a segurança, cada arquivo QlikView será dividido em vários arquivos, cada um contendo os dados relativos ao usuário ou ao grupo de usuários pertinente. Esses arquivos serão armazenados em pastas com as configurações de segurança corretas do sistema operacional, isto é, o QlikView permitirá que o sistema operacional controle a autenticação e a autorização.
No entanto, não será criada nenhuma segurança no próprio arquivo, assim, não haverá proteção para download de arquivos.
Os tamanhos de arquivo geralmente serão menores, já que um único arquivo será dividido em vários outros e o usuário só abrirá o arquivo que contiverem seus próprios dados. No entanto, isso significa também que um QlikView Server possivelmente usará mais memória se todos os dados forem mantidos em um arquivo, já que, algumas vezes, serão carregados vários arquivos contendo os mesmos dados.
Para obter mais informações, consulte a documentação do QlikView Publisher,
Segurança Usando a Seção de Acesso no Script do QlikView
Se o Section Access no script do QlikView estiver configurada para controlar a segurança, poderá ser criado um único arquivo para reter os dados de vários usuários ou grupos de usuários. O QlikView utilizará as informações contidas no Section Access para autenticação e autorização e reduzirá dinamicamente os dados, para que o usuário visualize apenas seus próprios dados.
A segurança será criada no próprio arquivo, dessa forma, o download de arquivos também estará protegido. No entanto, se a demanda por segurança for alta, os downloads de arquivos e o uso off-line serão impedidos. Os arquivos devem ser publicados somente pelo QlikView Server.
Como todos os dados serão mantidos em um arquivo, o tamanho desse arquivo poderá ser potencialmente grande.
Os documentos QlikView podem ser colocados como invisíveis no modo off-line. Para fazer com que um documento offline do usuário fique invisível, adicione o seguinte atributo na seção de informação de um documento do usuário usando o QMC:
- Nome: Invisível
- Valor: Verdadeiro
Todas as informações abaixo referem-se ao método de segurança de uso do Section Access no script QlikView.
Seções no Script
O acesso em nível de linha é gerenciado por meio de uma ou várias tabelas de segurança carregadas da mesma maneira que os dados são normalmente carregados. Isso possibilita armazenar essas tabelas em um banco de dados padrão ou em uma planilha. Os comandos de script que gerenciam as tabelas de segurança são fornecidos em uma seção de autorização, que, no script, é iniciado pelo comando 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 pelo comando Section Application.
Exemplo:
Níveis de Acesso na Seção de Acesso
O acesso a documentos QlikView pode ser autorizado para usuários ou grupos de usuários especificados. Na tabela de segurança, é possível atribuir 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 documento QlikView.
Uma pessoa com acesso ADMIN pode alterar tudo no documento. Utilizando a página Segurança nas caixas de diálogo Propriedades de Documento e Propriedades de Pasta, uma pessoa com acesso ADMIN pode limitar as possibilidades dos usuários de modificar o documento. Uma pessoa com privilégios de USER não pode acessar as páginas de Segurança.
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 na seção de acesso. Essas tabelas contêm vários campos do sistema específicos do usuário, geralmente USERID e PASSWORD, e o campo que define o nível de acesso, ACCESS. Todos os campos do sistema de Seção de Acesso serão usados na autenticação ou autorização. O conjunto completo de campos do sistema de seção de acesso está descrito a seguir.
Nenhuma, todas ou qualquer combinação de campos de segurança pode ser carregada na seção de acesso. Portanto, não é necessário usar USERID - uma autorização pode ser feita usando outros campos, por exemplo, apenas número de série.
| Campo | Descrição |
|---|---|
| ACESSO | Campo que define o tipo de acesso que o usuário correspondente deverá ter. |
| ID DO USUÁRIO | Um campo que deve conter um ID de usuário aceito. O QlikView solicitará uma ID de Usuário e a comparará com o valor desse campo. Essa ID de usuário não é a mesma do Windows. |
| USER.EMAIL | Atualmente sem suporte, corresponderá apenas a um curinga no QlikView. |
| SENHA | Campo que deve conter uma senha aceita. O QlikView solicitará uma Senha e irá compará-la com o valor desse campo. Essa senha não é a mesma do Windows. |
| NÚMERO DE SÉRIE | Um campo que deve conter um número correspondente ao número de série do QlikView ou a string 'QLIKVIEW'. Exemplo: 4900 2394 7113 7304 O QlikView verificará o número de série do usuário ou a string 'QLIKVIEW' e o comparará com o valor neste campo. |
| NOME NT | Campo que deve conter uma cadeia de caracteres correspondente a um nome de usuário ou nome de grupo do 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 QlikView lerá as informações de login do sistema operacional para compará-las com o valor desse campo. |
| SID DE DOMÍNIO DO NT | Campo que deve conter uma cadeia de caracteres correspondente a uma SID de Domínio do Windows NT. Exemplo: S-1-5-21-125976590-4672381061092489882 O QlikView lerá as informações de login do sistema operacional para compará-las com o valor desse campo. |
| SID DO NT | Campo que deve conter uma SID do Windows NT. Exemplo: S-15-21-125976590-467238106-1092489882-1378 O QlikView lerá as informações de login do sistema operacional para compará-las com o valor desse campo. |
| OMIT |
Campo que deve conter o 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 isto é usar um subcampo. Nota informativaVocê não deve aplicar OMIT em campos chaves, já que isso alterará a estrutura de dados subjacente. O que pode criar ilhas lógicas e inconsistências de cálculo.
|
O QlikView comparará o número de série do QlikView com o campo SERIAL, o nome e os grupos de usuário do Windows NT com NTNAME, a SID do Domínio do Windows NT com NTDOMAINSID e a SID do Windows NT com NTSID. Além disso, solicitará um ID de Usuário e uma Senha para compará-los com os campos USERID e PASSWORD.
Se a combinação encontrada de ID de usuário, senha e propriedades do ambiente também forem encontradas na tabela Seção de Acesso, o documento será aberto com o nível de acesso correspondente. Caso contrário, o QlikView negará ao usuário o acesso ao documento. Se a ID do Usuário e/ou a Senha não forem inseridas corretamente em três tentativas, o procedimento completo de logon deverá ser repetido.
Como a mesma lógica interna, que é a marca do QlikView, também é usada na seção de acesso, os campos de segurança podem ser colocados em tabelas diferentes. (Dessa forma, um gerente do sistema pode colocar um documento QlikView fora das tabelas de segurança. Nesse caso, um número de série, uma senha ou outro item correto é simulado por um clique no valor do campo correspondente.)
No procedimento de logon, o QlikView consultará primeiramente SERIAL, NTNAME, NTDOMAINSID e NTSID para verificar se essas informações são suficientes para conceder o acesso do usuário ao documento. Em caso positivo, o QlikView abrirá o documento sem solicitar a ID do Usuário e a Senha.
Se apenas alguns dos campos de acesso forem carregados, será utilizado um dos requisitos apropriados apresentados anteriormente.
Todos os campos listados em comandos Load ou Select na seção de acesso devem ser escritos em MAIÚSCULAS. Qualquer nome de campo que contenha letras minúsculas na base de dados será convertido para letras maiúsculas usando a função upper antes de ser lido pelo comando Load ou Select.
Upper – função de script e gráfico
Entretanto, a ID de usuário e a senha inseridas pelo usuário final ao abrir os documentos QlikView não são sensíveis a maiúsculas.
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 de sistema (USERID, PASSWORD, NTNAME ou SERIAL), 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).
Exemplo 1:
Apenas o número de série é verificado. Um computador específico obtém acesso ADMIN. Todos os outros obtêm acesso USER. Note que um asterisco pode ser usado para marcar “qualquer número de série”.
| ACESSO | NÚMERO DE SÉRIE |
|---|---|
| ADMIN | 4900 2394 7113 7304 |
| USER | * |
Exemplo 2:
O administrador e o servidor no qual o QlikView é executado como um job batch recebem acesso ADMIN. Todos os demais no Domínio recebem acesso USER ao inserir “USER” como ID de usuário e senha.
| ACESSO | NÚMERO DE SÉRIE | SID DE DOMÍNIO DO NT | ID DO USUÁRIO | SENHA |
|---|---|---|---|---|
| ADMIN | * | S-1-5-21-125976590-467238106-1092489882 | ADMIN | ADMIN |
| ADMIN | 4900 2394 7113 7304 | * | * | * |
| USER | * | S-1-5-21-125976590-467238106-1092489882 | USER | USER |
Ambientes mistos
Se você planeja usar a mesma tabela de autorização no QlikView e no Qlik Sense SaaS, há algumas coisas a serem observadas:
• USERID tem significados diferentes no QlikView e no Qlik Sense SaaS e pode, se usado, causar problemas de segurança. Em vez disso, use NTNAME ou combine-o com SERIAL conforme descrito a seguir.
• GROUP e campos que começam com 'USER.', como 'USER.NAME' e 'USER.EMAIL', etc. são (ou serão) campos de autenticação no Qlik Sense Enterprise SaaS. Se você usar esses campos no Section Access, o acesso poderá ser negado no Qlik Sense SaaS.
• PASSWORD, NTSID e NTDOMAINSID não podem ser usados no Qlik Sense SaaS. O acesso será negado, a menos que um curinga seja usado.
• 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 string 'QLIKCLOUD' ou 'QLIKVIEW', o acesso poderá ser concedido. Isso significa que é possível ter uma tabela de autorização como a seguinte, em que a linha 1 concederá acesso no QlikView (mas não no Qlik Sense SaaS), e a linha 2 concederá acesso no Qlik Sense SaaS (mas não no QlikView).
| Linha | NÚMERO DE SÉRIE | ID DO USUÁRIO | 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 Enterprise SaaS. |
| Linha | NÚMERO DE SÉRIE | ID DO USUÁRIO | Comentário |
|---|---|---|---|
| 1 | QLIKVIEW | * | Concede acesso ao QlikView. |
| 2 | QLIKCLOUD | John Doe | Concede acesso ao usuário correto no Qlik Sense Enterprise SaaS. |
Restrições na Funcionalidade do QlikView
Os controles encontrados na página Propriedades do documento: Segurança e na página Propriedades da pasta: Segurança permitem cancelar o acesso a determinados itens de menu e proíbem alterações no layout. Se essas configurações devem ser utilizadas como medidas de proteção reais, é importante que os usuários do documento façam login como USER. Qualquer pessoa que efetue login como ADMIN pode alterar a configuração de segurança a qualquer momento.
Um usuário que tenha aberto o documento com direitos USER não acessa as páginas Segurança nos diálogos de Propriedades.
Redução dinâmica de dados
O QlikView e o QlikView Server suportam um recurso pelo qual parte dos dados em um documento pode ser oculta do usuário, com base no login de Seção de Acesso.
Primeiramente, os campos (colunas) podem ser ocultos pelo uso do campo do sistema OMIT.
Em seguida, os registros (linhas) podem ser ocultos vinculando os dados da Seção de Acesso aos dados reais: A seleção de valores a serem mostrados/excluídos é controlada pela existência de um ou mais campos com nomes comuns em seção de acesso e seção de aplicativo. Depois do login do usuário, o QlikView tentará copiar as seleções nos campos de Seção de Acesso em quaisquer campos de section application, exatamente com os mesmos nomes de campo (os nomes de campos devem ser escritos em MAIÚSCULAS). Depois de feitas as seleções, o QlikView ocultará permanentemente do usuário todos os dados que foram excluídos por essas seleções.
Para que esse procedimento ocorra, a opção Redução inicial de dados baseada no Section Access na página Propriedades do documento: Abertura deve estar selecionada. Se esse recurso for utilizado em documentos que deverão ser distribuídos por outros meios que não sejam pelo QlikView Server, a opção Carga Binária Proibida na mesma página das Propriedades do Documento deverá ser selecionada para manter a proteção dos dados.
Exemplo:
section access;
LOAD * inline [
ACCESS, USERID, REDUCTION, OMIT
ADMIN, ADMIN, *,
USER, A, 1
USER, B, 2, NUM
USER, C, 3, ALPHA
];
section application;
T1:
LOAD *,
NUM AS REDUCTION;
LOAD
Chr( RecNo()+ord('A')-1) AS ALPHA,
RecNo() AS NUM
AUTOGENERATE 3;
O campo REDUCTION (em maiúsculas) agora existe com Seção de Acesso e Seção de Aplicativo (todos os valores de campo também estão em maiúsculas). Normalmente, os dois campos seriam totalmente diferentes e separados, mas, se a opção Redução Inicial de Dados baseada na Seção de Acesso tiver sido selecionada, eles vincularão e reduzirão o número de registros exibidos para o usuário.
O campo OMIT em Seção de Acesso define os campos que devem ser ocultados do usuário.
O resultado será o seguinte:
O usuário A pode ver todos os campos, mas somente os registros conectados a REDUCTION=1.
O usuário B pode ver todos os campos, exceto NUM, e somente os registros conectados a REDUCTION=2.
O usuário C pode ver todos os campos, exceto ALPHA, e somente os registros conectados a REDUCTION=3.
Restrições de acesso herdadas
Uma carga binária fará com que as restrições de acesso sejam herdadas pelo novo documento QlikView. Uma pessoa com direitos ADMIN para esse novo documento pode alterar os direitos de acesso desse novo documento incluindo uma nova seção access. Uma pessoa com direitos USER pode executar o script e alterá-lo, incluindo assim, seus próprios dados no arquivo binário carregado. Uma pessoa com direitos USER não pode alterar os direitos de acesso. Isso possibilita que o administrador de uma base de dados também controle o acesso de usuários aos documentos QlikView binários carregados.
Criptografia
A comunicação entre o QlikView Server e o cliente Windows do QlikView é criptografada. No entanto, se o cliente AJAX for usado, a comunicação não será encriptada.
Além disso, todos os documentos QlikView são encriptados, o que torna as informações ilegíveis aos visualizadores, depuradores, etc.
Você também pode criptografar dados confidenciais em arquivos QVD com pares de chaves fornecidos pelo cliente, o que permite controlar quem obtém acesso aos seus dados. Consulte Criptografia QVD (somente em inglês).
