Segurança

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 a Seção de Acesso 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 na Seção de Acesso 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 deverão ser publicados pelo QlikView Server somente.

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 documento off-line do usuário fique invisível, adicione o seguinte atributo na seção de informação sobre documentos de um documento do usuário usando o QMC:

  • Nome: Invisível
  • Valor: Verdadeiro

Todas as informações a seguir referem-se ao método de segurança do uso da Seção de Acesso no script do QlikView.

Seções no Script

O controle de acesso é gerenciado por meio de uma ou várias tabelas de segurança carregadas da mesma forma que o QlikView normalmente carrega os dados. É possível, por essa razão, armazenar essas tabelas em uma base de dados normal. Os comandos de script que gerenciam as tabelas de segurança são fornecidos na seção de acesso, que é iniciada no script pelo comando seção de acesso.

Se uma seção de acesso estiver definida no script, a parte do script que carrega os dados “normais” deve ser colocada em uma seção diferente, iniciada pelo comando section application.

Exemplo:  

Section Access;

Load * inline

[ACCESS,USERID,PASSWORD

ADMIN, A,X

USER,U,Y ];

Section Application;

Load... ... from... ...

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.

Nota: Os privilégios de ADMIN são relevantes apenas para documentos locais. Os documentos abertos em um Server sempre são acessados com privilégios de USER.

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. Dessa forma, não é necessário usar USERID – a autorização pode ser feita usando outros campos, por exemplo, somente pelo número de série.

 

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.
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 que corresponde ao número de série do QlikView.
Exemplo: 4900 2394 7113 7304.
O QlikView verificará o número de série do usuário para compará-lo com o valor nesse 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.
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 extrairá as informações de login do sistema operacional e as comparará 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 extrairá as informações de login do sistema operacional e as comparará 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: Você 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.

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

O caractere curinga, isto é, * é interpretado como todos os valores (listados) desse campo, isto é, os valores listados em qualquer lugar nessa 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).

Nota: Ao carregar dados de um arquivo QVD, o uso da função upper diminuirá a velocidade de carregamento.
Nota: Para gerar tabelas de acesso em comandos inline, use o Assistente de Tabelas de Restrição de Acesso.
Nota: 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.

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

Restrições na Funcionalidade do QlikView

Os controles encontrados na página Propriedades de Documento: Segurança e na página Propriedades de Pasta: Segurança permitem cancelar o acesso a determinados itens de menu e proíbem fazer 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 na Seção de Acesso na página Propriedades do Documento:Abrindo 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.

Nota: Todos os nomes de campos usados na transferência descrita anteriormente e todos os valores desses campos devem estar em letras maiúsculas, pois todos os nomes e valores de campo são, por padrão, convertidos em maiúsculas na seção de acesso.

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,

RechNo() 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.