Controle de Acesso no Qlik Sense

De Qknow
Ir para: navegação, pesquisa
QlikCiclesPicture.PNG

Página Principal >> Segurança >> Governança no Qlik Sense >> Controle de Acesso no Qlik Sense

Introdução

QlikSenseAccessControl01.PNG

O controle de acesso no ambiente Sense é baseado em propriedades (property-based) em termos de usuário, ambiente e recurso. Cada propriedade é definida por um valor resultando em uma estrutura tal como "grupo = vendedores" ou "recurso = aplicação". Cada requisição de acesso inclui propriedades para usuários, ambientes e recursos envolvidos na solicitação, além da ação que se deseja fazer (criar, atualizar, excluir, acessar).

Regras (rules) podem ser criadas baseando-se no conceito de propriedades (property-based) de tal maneira que um acesso a um recurso só será garantido se o resultado da avaliação da propriedade for TRUE (verdadeiro) para o recurso que está sendo acessado. Cada rule precisa definir a ação sobre qual recurso (ou recursos) além do usuário ou grupo, doutra forma a rule será criada mas não terá nenhum privilégio associado.

Sempre que uma requisição é feita as regras criadas no QMC são verificadas (avaliadas) para o recurso que estiver sendo requisitado. Nem todas as regras (rules) são testadas já que o Sense é inteligente o suficiente para verificar somente aquelas que fazem parte do recurso solicitado, evitando assim uma sobrecarga de testes em rules desnecessárias.

  Nota: Na documentação Qlik (Configuring Qlik Sense) o termo rules (regras) é substituído por roles (papéis) representando o mesmo item no QMC. 

Aplicação de Regras de Acesso

Sense - Designing Access Control.png

Por exemplo, se um usuário do grupo de vendedores requisita acesso a uma stream onde são publicados os relatórios trimestrais pela equipe financeira, uma regra pode ter sido estabelecida no recurso (neste caso a stream) para que somente os usuários do Active Directory provenientes do grupo Finance tenham acesso a stream. As propriedades de acesso seriam definidas em uma etapa de requisição e outra de aplicação da regra. A requisição é a ação do usuário ao tentar fazer uso do relatório, enquanto a aplicação da regra é o teste de permissão de acesso aplicado pelo engine.

Logo, algo semelhante a figura ao lado ocorre:

1. Uma requisição de acesso ocorre para um determinado recurso. No exemplo, o usuário Franco solicita fazer a leitura de um relatório publicado na stream Painéis. Os atributos complementares do usuário envolvem o user_id do domínio bem como o grupo em que ele está inserido, no exemplo, Vendas. Na requisição são recebidas as informações de propriedades a respeito do recurso a ser acessado.

2. Existem regras de acesso definidas para o recurso e serão aplicadas porque o usuário fez uma requisição que é contemplada por uma ou mais rules. Na definição da regra existe um acesso de leitura (read) na stream Painéis para todos os usuários que fazem parte de um grupo do domínio denominado Financeiro. Como não existem outras regras para o mesmo recurso apenas esta será aplicada.

3. No passo 3 são verificados os atributos das propriedades encaminhadas pelo usuário versus aquelas presentes na rule. A ação de leitura (read) passa pela verificação, seguido do nome do recurso (stream = Painéis) a ser acessado. A tipologia do objeto em questão também é verificado, pois podem existir diferentes tipos de elementos com o mesmo nome. A verificação do tipo é igualmente confirmado com sucesso. Por último, testa-se o nome do grupo do usuário e verifica-se que a regra de acesso permite que membros do Financeiro podem acessar a stream, mas membros de Vendas, não.

Este didático diagrama busca ensinar a forma teórica de como o Sense avalia o acesso aos recursos. Não é uma simples permissão, mas uma combinação de propriedades que precisam ser atendidas par a par para que a rule retorne verdadeiro (TRUE). Na prática múltiplas regras serão criadas ao longo da administração do Sense Server contando com inúmeros recursos, usuários, grupos e diferentes requisições (leitura, gravação, exclusão, atualização, etc.). Portanto, em algum momento é provável que múltiplas regras sejam aplicadas ao mesmo recurso, de maneira que o Sense responde a esta ação pela complementaridade das regras.

Isso significa que se um usuário pode fazer parte de mais de uma rule em virtude das regras estabelecidas e o resultado do acesso será uma combinação de ambas. Por exemplo, suponha que uma rule garanta ao usuário Franco leitura na stream Vendas, enquanto outra rule garante aos usuários do grupo do domínio Consultores a ação de update (atualização). Neste exemplo, assuma ainda que Franco faz parte do grupo Consultores. O resultado será uma combinação de ambas as rules e com isso o usuário terá acesso de leitura e atualização.

Este aspecto é importante pelo fato de que alguns sistemas (especialmente de banco de dados, como SQL Server) atuam na aplicação das regras da mais restritiva para a mais abrangente. Ou seja, se uma regra é mais restrita do que outra somente as permissões menos permissivas serão concedidas. No Sense, o contrário. A combinação das rules resultará em verdadeiro para o recurso combinando as permissões das várias regras aplicadas.

Criando Regras (Rules) de Acesso

O QMC é utilizado para criação de rules que serão aplicadas a diversos aspectos do ambiente Sense Server. Rules possuem contextos que se aplicam ao QMC, ao HUB ou a ambos. Esta configuração é especialmente importante porque dependendo de onde serão aplicadas poderá agir no ambiente inteiro ou apenas em uma das portas de entrada citadas (HUB ou QMC). Estas regras são criadas no rule editor acessível a partir do QMC em um endereço semelhante a:

https://seu_servidor/qmc
QlikSenseSecurityRules01.png

Uma vez autenticado no QMC com um usuário com privilégios suficientes para criação e edição de rules, é possível acessar o editor a partir do link Security Rules no painel do lado esquerdo da interface principal do console. A lista das rules instaladas com o Qlik Sense Server são apresentadas contendo diversas informações, incluindo o contexto (Context) e o tipo (Type). Context indica onde a rule será aplicada sendo possível apenas no QMC, apenas no HUB ou em ambos. É por esse motivo que membros da rule RootAdmin podem gerenciar todo o console mas não acessam os painéis, justamente porque essa rule pertence ao contexto QMC, mas não ao HUB.

Além das características de contexto as rules possuem tipologia que as definem como padrão (default) instaladas pelo Sense, somente para leitura (read only) e as criadas pelo administrador para inúmeras finalidades. Apesar de serem padrões instalados, as rules do tipo default podem ser modificadas pelo administrador para melhor aderência as regras da companhia.

QlikSenseSecurityRules02.png

Para criar uma nova rule basta acionar o botão Create New na parte inferior da janela. O editor será exibido contendo inúmeras opções, altamente sofisticadas. Observe que não existem permissões engessadas e qualquer regra de acesso pode ser derivada a partir do editor. Por exemplo, é possível estabelecer uma rule para que certos operadores sejam encarregados de acompanhar os processos de recarga dos painéis, sem com isso terem acesso aos próprios painéis ou a outros elementos da interface de administração. É totalmente personalizado! A primeira parte do editor refere-se a identificação da rule e os seguintes campos precisam ser preenchidos:

IDENTIFICATION

  • Create rule from template: Auxilia na criação da nova regra preenchendo parte dos campos com informações iniciais. No exemplo em questão, pretende-se criar uma rule para habilitar um usuário a realizar as tarefas de recarga. Para isso, basta selecionar Reload task access.
  • Name: Corresponde ao nome da rule que será criada com o propósito definido nos critérios. Entre com o nome que desejar, mas estabeleça um padrão que o guie facilmente na administração do ambiente. No exemplo, o nome da rule será ReloadOperators, ou Operadores de Recarga.
  • Disabled: Assinale essa opção se a criação da regra não deve entrar em vigor imediatamente. Ou seja, apesar de disponível e visível na lista de rules esta opção a manterá inativa até que se tenha autorização para efetivá-la. Neste exemplo a opção permanecerá desmarcada, fazendo com que a rule entre em vigor imediatamente.
  • Description: Auxilia nas tarefas administrativas na medida em que inclui um texto que será exibido em diversos locais do console. Assim outros administradores e operadores poderão entender rapidamente o propósito da rule. Entre com o texto que desejar.
QlikSenseSecurityRules03.png

BASIC

  • Actions: Informa as ações que serão permitidas ao usuário (ou critério estabelecido) no recurso selecionado. Note que ao escolher Reload task access na opção Create rule from template, automaticamente o tipo de recurso foi definido na seção ADVANCED.
  • As opções Create, Read, Update e Delete referem-se as ações que o usuário poderá realizar sobre o recurso filtrado na seção ADVANCED. Neste exemplo o operador Bruno.Costa poderá realizar todas as ações sobre todas as tarefas do tipo recarga (ReloadTask_*).

ADVANCED

Para regras que se aplicam a um único elemento não é necessário preencher manualmente os campos da opção ADVANCED, a não ser o item Context. Neste caso espera-se que a regra se aplique apenas ao QMC, por isso o valor Only in QMC é selecionado. Algumas considerações são importantes quando se utiliza as opções avançadas.

  • Resource filter: Aceita mais do que um elemento através dos operadores AND ou OR. Portanto, pode ser editado manualmente para regras mais sofisticadas. Note que neste exemplo o campo foi preenchido automaticamente pela seleção feita no campo Create rule from template.
  • Conditions: Especifica quais são as condições de acesso aos recursos. Neste caso foi determinado um usuário específico para acessar as tarefas de recarga. Como trata-se de uma ação em particular para um usuário específico, não há necessidade de editar o campo de condições.

Para finalizar a ação de criação da rule basta definir o contexto e clicar no botão Validate Rule seguido de Apply. Caso todos os campos estejam corretamente definidos uma mensagem aparecerá informando o sucesso da criação da rule.

Rules como Múltiplas Condições

QlikSenseSecurityRules04.png

Rules podem ser definidas para aderência a permissões com múltiplos condicionais. Ou seja, é possível utilizar os operadores OR ou AND para combinar as condições desejadas para uma rule. Na figura ao lado a regra anterior foi editada para compor outros requisitos digitados diretamente sobre a seção ADVANCED.

Neste caso mais de um usuário especificado poderá realizar as ações previstas na rule, por isso foi adicionado um condicional contendo o fragmento or ((user.name="franco.galati")) na condição. Logo, percebe-se que os operadores OR ou AND podem ser combinados para múltiplas restrições. Adicionalmente, se observado o campo Resource Filter é possível constatar que estes dois usuários poderão gerir não mais apenas tarefas de recarga, mas também ações sobre contas de usuários. Por isso o campo foi completado com ,User_*.

O uso de parênteses duplos na definição da condições auxilia no alinhamento entre as seções BASIC e ADVANCED ao clicar no botão Validade Rule. Porém, não é preciso manter a sintaxe nesse formato se o objetivo for a entrada da definição da regra totalmente escrita na seção ADVANCED. Um fato interessante sobre a criação das rules é que o usuário ou recurso não precisa existir antes da criação da condição.

Claro que neste caso as regras só se aplicarão quando o recurso for criado. Por exemplo, é possível criar uma rule para uma stream especifica sem que esta stream exista previamente no ambiente.

Usuários não são associados a rules como ocorre na inclusão de logins do Windows em grupos do sistema operacional. Ao invés disso, o usuário se encaixa a uma rule (regra) com base nas propriedades que foram definidas para o acesso, como nome do grupo, nome do recurso ou mesmo login do usuário. Portanto, uma regra será aplicada sempre que o usuário acessar o recurso para o qual esta foi atribuída. No exemplo deste artigo, a regra se aplicará sempre que houver uma tentativa de uso de tarefas de recarga.



Configuração para Usuários Anônimos

Para permitir acesso anônimo ao HUB é preciso configurar o ambiente para aceitar conexões não autenticadas. Adicionalmente, uma rule deve ser configurada para acesso a stream para a qual o usuário, após conectar-se ao HUB, terá acesso. Para o funcionamento de acessos não identificados outras condições precisam ser consideradas:

QlikSenseVirtualProxy02.png
  • Um usuário anônimo consome licenças de acesso do tipo login access pass.
  • Para o login pass, tokens devem ser destinados especificamente ao modelo não autenticado.
  • O serviço do proxy do Sense deve ser reconfigurado para aceitar conexões anônimas.
  • Uma rule deve ser configurada para habilitar usuários anônimos a ler a stream desejada.

Siga os procedimentos abaixo para configurar o acesso anônimo em um servidor Qlik Sense:

1. Autentique-se no QMC com um usuário que tenha privilégios administrativos.

2. Assumindo que já exista um conector para um serviço de diretórios configurado, clique em Virtual Proxies.

3. A partir da lista de virtual proxies clique no proxy desejado e no rodapé da página escolha Edit.

4. Na lista de propriedades na direita da janela, selecione Authentication. As seguintes opções serão exibidas.

QlikSenseVirtualProxy01.png

5. Selecione Allow anonymous user a partir da opção Anonymous access mode.

 Nota: Esta opção garante que o acesso será anônimo ao HUB, mas ainda permitirá que o usuário possa fazer o login se desejar.

Até esta etapa o servidor foi configurado para aceitar conexões anônimas ao HUB. Porém, isso não significa que o usuário terá acesso ao ambiente já que ainda carece de licenciamento. Não é possível atribuir um token diretamente aos usuários anônimos por motivos óbvios, não se sabe quem são. Mas é possível utilizar tokens em forma de passes para habilitar o usuário não identificado a estar licenciado pela sessão em uso. Para maiores informações sobre login access pass, veja este artigo sobre licenciamento. Siga os seguintes passos para completar a configuração de acesso anônimo:

QlikSenseLicense03.png

6. Ainda no QMC, acesse o menu principal para criação de uma rule que permita usuários anônimos. Use o atalho License and Tokens.

7. No menu a direita escolha Login access rules. No rodapé da página acione o botão Create New.

8. Entre com um nome (name) para a rule que será criada e o número de tokens que serão convertidos em passes. Em seguida escolha Apply.

QlikSenseTokens04.png

9. Ao ser exibida a janela Create license rule assinale a opção Advanced no menu a direita da janela.

10. Entre com a seguinte expressão para a condição da rule: user.isAnonymous().

11. Clique no botão Validate Rule e confirme que a regra é válida através da mensagem correspondente.

12. Finalize acionando o botão Apply. Neste momento o número de tokens definido será usado para passes de usuários anônimos.


É importante considerar que um token é equivalente a 10 passes de 60 minutos cada. Ou seja, um usuário anônimo usará um único token por até 10 horas dentro do prazo de 28 dias, ou 10 usuários anônimos utilizarão o token por até 1 hora. A qualquer momento novos tokens podem ser adicionados ao modelo de passe editando a rule recém criada. É importante destacar que o usuário anônimo não pode editar as aplicações (apps) disponíveis pois há uma rule em vigor (padrão da instalação) que proíbe essa ação. Adicionalmente, o usuário não autenticado (anônimo) só terá acesso a stream Everyone por padrão. Se necessário, outras streams podem ser criadas com regras de acesso a usuários anônimos.


Assuntos Relacionados


Envelope01.jpg
Procurando Algo? Fale Conosco!

Voltar | Página Principal

Página Principal >> Segurança >> Governança no Qlik Sense >> Controle de Acesso no Qlik Sense </span>