Skip to content

Permissões e Segurança ​

Caminho: Usuários / Grupos > Editar > Acesso aos Dados / Funções do Sistema

O controle de segurança do HEC é dividido em três camadas complementares:

CamadaO que defineOnde configurar
Acesso a DadosQuais áreas, aplicações e tabelas o usuário pode acessarAba Acesso aos Dados
Restrições (Linhas e Colunas)Quais registros e campos específicos ele pode visualizarAba Acesso aos Dados > Gerenciar Acesso da Tabela
Funções de SistemaQuais ações operacionais ele pode executar (criar, editar, excluir, publicar)Aba Funções do Sistema

👁️ Aba: Acesso aos Dados ​

A aba Acesso aos Dados separa claramente dois mundos: o que é consumo de BI (DataViz) e o que é construção de dados (DW e ETL). Cada alteração feita nesta tela é salva imediatamente.

📊 1. Eixo DataViz (Para quem consome BI) ​

Controla o que os usuários e grupos conseguem enxergar nas telas de inteligência. A estrutura de organização é simples:

📁 Mesa (área ou departamento) ➔ 📱 Aplicação (conjunto de dashboards e relatórios)

  • Mesas de Aplicação (allow-list): A Mesa funciona como uma pasta que agrupa aplicações de um mesmo tema (ex.: Comercial, Operações). As mesas nascem trancadas. Ao liberar uma mesa, o usuário passa a ter acesso às aplicações contidas nela.
  • Aplicações Bloqueadas (Exceções): Se você quer liberar quase toda a mesa, mas precisa esconder uma aplicação específica (com todos os seus gráficos e relatórios), basta expandir a linha da mesa e marcar essa aplicação como bloqueada.
  • Tabelas do DataViz: Lista as tabelas disponíveis para alimentar as aplicações. Ao clicar em Gerenciar Acesso em uma tabela, você configura a governança detalhada:
    • Filtros de Linha (Restrições / RLS): Filtros obrigatórios que o usuário não pode remover (ex.: Filial = 'Matriz' ou Vendedor = 10).
    • Colunas Escondidas (CLS): Oculte campos confidenciais (ex.: Margem de Lucro, Custo, Salário).
    • Vigência e Exportação: Defina uma data de expiração para o acesso ou desative a permissão de download (Excel, CSV, PDF).
    • Permissões de Cadastro (Writeback): Em tabelas editáveis, controle quem tem permissão para Ler, Criar, Atualizar, Excluir e Importar registros.

🗄️ 2. Eixo DW e ETL (Para quem constrói e integra dados) ​

Controla quem tem permissão para construir e manter a engenharia de dados da plataforma.

  • Mesas de Dados (allow-list): Nascem trancadas. Governam quem pode visualizar e editar tabelas no HorusDW e fluxos no HorusETL. Se o usuário for um desenvolvedor de dados, você pode marcar a opção de liberar todas as mesas de dados (atuais e futuras) de uma só vez.
  • Conexões de Dados: Define quais credenciais e conexões de bancos de dados o usuário ou grupo pode utilizar para criar integrações no ETL.

IMPORTANT

Mesa de Dados não bloqueia Aplicações nem Dashboards. A Mesa de Dados trava apenas a tela de construção técnica (DW e ETL). Se um usuário tiver acesso a uma Mesa de Aplicação (e à aplicação desejada) e às tabelas necessárias liberadas para consulta, os relatórios e dashboards abrirão normalmente para ele, mesmo que ele não tenha acesso à Mesa de Dados onde a tabela original reside.


⚠️ Colinha de Segurança: Como Funcionam as Restrições (RLS) ​

As Restrições de Linha são filtros automáticos e invisíveis injetados em todas as consultas que o usuário realiza nos relatórios e dashboards. O usuário não consegue remover nem contornar esses filtros, mesmo via API ou exportação.

No entanto, para que uma restrição funcione com segurança, existe uma regra fundamental de modelagem que você precisa conhecer.

A Regra de Ouro do Modelo de Dados ​

Em modelos analíticos (modelo estrela), as consultas combinam tabelas de Dimensão (cadastros: Vendedores, Filiais, Clientes) com tabelas de Fato (históricos e movimentações: Vendas, Metas, Contas a Pagar).

  1. A restrição deve ser aplicada na tabela de Dimensão (ex.: na tabela Vendedores, aplique ID_VENDEDOR = 10).
  2. Toda tabela Fato usada na aplicação DEVE ter ligação com essa Dimensão.

O Grande Perigo (Exemplo Real) ​

Imagine o seguinte cenário:

  • Você quer liberar o BI para o seu Representante Comercial (João).
  • Você restringe a tabela Vendedores para que ele veja apenas Vendedor = João.
  • Em seguida, você libera uma aplicação comercial que traz relatórios de Vendas e também um relatório financeiro de Contas a Pagar / DRE.

O que acontece?

  • Nos relatórios de Vendas: a tabela de vendas está ligada a vendedores. O filtro age perfeitamente e o João só vê as vendas dele.
  • No relatório de Contas a Pagar / DRE: contas a pagar não têm vendedor. Como o sistema não encontra nenhuma relação entre o financeiro e a tabela de vendedores, a restrição não tem como ser aplicada!
  • O perigo: O João verá as despesas e o DRE da empresa inteira, sem nenhum filtro!

Como Evitar Esse Problema (Boas Práticas) ​

  • 🎯 Mantenha Aplicações Coesas: Em uma aplicação voltada para vendedores, inclua apenas dashboards e relatórios cujos dados se relacionem com vendedor (pedidos, metas, faturamento, comissões).
  • 🔒 Use Aplicações Bloqueadas: Se uma mesa liberada contiver uma aplicação com dados corporativos gerais que não possuem ligação com o perfil restrito (ex.: uma aplicação de Controladoria), bloqueie essa aplicação inteira para ele.
  • 📁 Crie Mesas Específicas para Perfis Restritos: Tenha uma Mesa de Aplicação dedicada (ex: Portal do Representante ou Acesso Externo) contendo exclusivamente aplicações preparadas e seguras para aquele público.

⚙️ Aba: Funções do Sistema ​

A aba Funções do Sistema define as capacidades operacionais do usuário ou grupo. É uma matriz onde você habilita ou desabilita ações (Ver, Criar, Editar, Excluir, Publicar, Bloquear) para cada módulo da plataforma.

Principais Módulos ​

MóduloO que controla
AplicaçõesCriação, edição e exclusão de Aplicações de BI, Dashboards e Relatórios.
TabelasCriação e gestão de tabelas no Data Warehouse.
Mesas de DadosCriação de novas mesas no DW.
Mesas PublicadasGestão e organização das mesas de visualização no BI.
Dataflows (ETL)Construção e edição de fluxos de dados no ETL.
Ger. UsuáriosPermissão para cadastrar e gerenciar outros usuários.
Ger. GruposPermissão para criar e administrar grupos de acesso.
CredenciaisConfiguração de conexões com bancos de dados externos.
DatamartsAdministração de áreas de Datamarts.
ArmazenamentoGestão de arquivos globais do tenant (uploads, arquivos públicos/privados).
AlertasCriação e configuração de notificações automáticas.
Usar IAPermissão para interagir com recursos de inteligência artificial.

Regras Essenciais ​

  • 🚫 O botão "Bloquear" tem precedência total: Se você marcar "Bloquear" em uma função diretamente no usuário, ela ficará bloqueada mesmo que ele participe de um grupo que conceda essa função.
  • 📤 "Publicar" é uma permissão, não um privilégio exclusivo de admin: Qualquer colaborador pode receber o direito de publicar aplicações ou tabelas, mas ele só poderá publicar nas mesas às quais já tem acesso.
  • 🛡️ Comportamento inicial:
    • A maioria das funções nasce negada: você precisa liberar explicitamente para a pessoa ou grupo usar (ex.: Aplicações, ETL, Ger. Usuários).
    • Algumas funções já nascem disponíveis por padrão e só precisam de ação caso você queira impedi-las (ex.: Usar IA).
  • 👑 Administradores do Tenant: Possuem acesso global. Bloqueios configurados em grupos não afetam administradores; para restringir um admin, a restrição deve ser aplicada diretamente no cadastro dele.