Object-Level Security (OLS) no Power BI: como esconder colunas

Tem coluna que nem deveria existir para quem está olhando o relatório#

Chega a hora em que esconder linhas não basta. O diretor comercial pode ver o faturamento por região, mas não pode ver a coluna de salário do vendedor. O analista de operação precisa da tabela de pedidos, mas a tabela de custo unitário do fornecedor é confidencial e não pode aparecer para ele em hipótese alguma. É aqui que entra o Object-Level Security, o recurso do Power BI que permite esconder colunas e tabelas inteiras de um papel específico, ao ponto de o objeto simplesmente deixar de existir para aquele usuário.

O erro clássico é achar que dá para resolver isso escondendo a coluna no relatório ou removendo do visual. Não resolve. Uma coluna oculta no visual continua no modelo, continua acessível por quem monta um relatório novo, por quem usa Analisar no Excel, por quem conecta via XMLA. Segurança de verdade não é esconder na tela, é impedir o acesso ao objeto. Neste artigo eu mostro o que o Object-Level Security faz, onde ele difere do RLS, como configurar por ferramenta externa e por TMSL, e o cuidado que quase todo mundo esquece: o relatório que referencia o objeto oculto quebra para quem não tem permissão.

Object-Level Security esconde o objeto, RLS filtra a linha#

A confusão entre os dois recursos é a raiz de quase todo projeto de segurança mal feito que eu já peguei para arrumar. Eles resolvem problemas diferentes e, na maioria dos casos sérios, trabalham juntos.

O Row-Level Security (RLS) filtra linhas. Ele mantém a tabela e todas as colunas visíveis, mas restringe quais registros o usuário enxerga. O gerente da filial Sul vê a tabela de vendas inteira, com todas as colunas, mas só as linhas da região Sul. A estrutura do modelo é idêntica para todo mundo, o que muda é o conjunto de dados retornado.

O Object-Level Security (OLS) esconde o objeto. Ele remove a coluna ou a tabela inteira da visão do papel. Para o usuário sem permissão, aquele objeto não existe: não aparece no painel de campos, não pode ser usado em medida, não retorna em consulta nenhuma. É a diferença entre "você vê a coluna salário, mas só das pessoas da sua equipe" (RLS) e "você não sabe que existe uma coluna chamada salário" (OLS).

Aspecto	Row-Level Security (RLS)	Object-Level Security (OLS)
O que restringe	Linhas (registros)	Colunas e tabelas inteiras
O objeto fica visível?	Sim, a coluna aparece	Não, o objeto some do modelo
Como se define	Filtros DAX por papel	Metadados de permissão por papel
Configuração no Desktop	Nativa, no Gerenciar funções	Não exposta, exige ferramenta externa
Uso típico	Restringir por região, unidade, cliente	Ocultar dado sensível: salário, custo, CPF
Risco de quebrar visual	Baixo	Alto, se o visual referencia o objeto oculto

Na prática, os dois se complementam. Para dado sensível e conformidade com a LGPD, a combinação é o padrão: OLS remove as colunas que uma pessoa jamais pode ver, e RLS filtra as linhas que ela até pode ver, mas só do escopo dela. Um trata a existência do dado, o outro trata a abrangência. Se você ainda está estruturando isso do zero, vale ler nosso material sobre governança de dados no Power BI e LGPD antes de sair configurando papéis.

O Power BI Desktop não expõe OLS, e isso é de propósito#

Aqui vem a primeira surpresa de quem procura o recurso: não existe botão de Object-Level Security no Power BI Desktop. Você abre o Gerenciar funções, configura o RLS com filtros DAX, e não encontra em lugar nenhum a opção de esconder uma coluna por papel. Não é bug, é como o produto foi desenhado. O OLS vive na camada de metadados do modelo tabular e é configurado por ferramentas externas que enxergam essa camada.

As duas formas suportadas são:

• Tabular Editor, a ferramenta externa mais usada para editar o modelo tabular. Você define, papel por papel, quais tabelas e colunas ficam com permissão negada. É a forma visual, mais rápida para configurar e revisar.
• TMSL (Tabular Model Scripting Language), o script JSON que descreve operações sobre o modelo. Você aplica o OLS via XMLA endpoint, executando um script que define o metadata de permissão dos objetos. É a forma que você automatiza em pipeline, versiona em Git e roda em deploy.

Ambas atuam sobre a mesma propriedade: a permissão de metadados de cada objeto por papel, que assume basicamente dois estados, Default (herda o comportamento normal, objeto visível) e None (acesso negado, objeto oculto). No Tabular Editor você marca isso numa árvore de objetos. No TMSL você declara num bloco tablePermissions dentro da definição do papel.

Um recorte de TMSL para negar uma coluna a um papel tem esta forma:

{
  "createOrReplace": {
    "object": { "database": "VendasCorp", "role": "Comercial" },
    "role": {
      "name": "Comercial",
      "tablePermissions": [
        {
          "name": "Colaboradores",
          "columnPermissions": [
            { "name": "Salario", "metadataPermission": "none" }
          ]
        }
      ]
    }
  }
}

Nesse exemplo, o papel Comercial perde acesso à coluna Salario da tabela Colaboradores. Para esconder a tabela inteira, você define o metadataPermission como none no nível da tabela, e não da coluna. Vale registrar: o OLS é aplicado ao dataset publicado no Serviço, então o fluxo real é configurar por Tabular Editor ou TMSL contra o modelo, publicar, e mapear os usuários aos papéis no Power BI Service. A gestão dos papéis e dos membros continua sendo feita no Serviço, igual ao RLS.

Passo a passo enxuto pelo Tabular Editor#

Para quem vai pela via visual, o caminho é direto:

1. Publique o modelo no workspace e conecte o Tabular Editor ao dataset pelo XMLA endpoint, ou abra o arquivo do modelo localmente.
2. Crie ou selecione o papel (Role) que vai receber a restrição. O mesmo papel que carrega o RLS pode carregar o OLS.
3. Navegue até a tabela ou coluna sensível e defina a Object-Level Security daquele papel como None.
4. Salve as alterações de volta no modelo (Save to database, se estiver via XMLA).
5. No Power BI Service, associe os usuários ou grupos ao papel em Segurança do dataset.
6. Teste com a conta certa antes de liberar. Testar é onde o projeto se salva ou se afunda.

O visual que referencia um objeto oculto quebra, e você precisa planejar isso#

Este é o ponto que separa quem leu a documentação de quem já apanhou em produção. Quando um papel tem uma coluna ou tabela escondida por OLS, qualquer visual do relatório que use aquele objeto quebra para o usuário daquele papel. Não é que o número some ou apareça em branco: o visual retorna erro para quem não tem permissão. Para quem tem permissão, o mesmo relatório funciona normalmente.

A razão é lógica. Se o objeto não existe para aquele papel, uma medida ou um visual que dependa dele não tem como ser resolvido. O motor não tem o que retornar, então devolve erro. E o efeito é em cascata: uma medida DAX que referencia a coluna oculta também quebra, mesmo que o visual não mostre a coluna diretamente. Basta a fórmula tocar no objeto negado.

O que isso significa na prática de projeto:

• Um relatório único para vários papéis com OLS diferente é uma armadilha. Se a página tem um visual de salário e o papel Comercial não pode ver salário, aquele Comercial abre a página e encontra um visual quebrado.
• A saída limpa costuma ser separar. Ou você faz relatórios distintos por público, ou desenha as páginas de forma que os objetos sensíveis fiquem isolados em páginas ou visuais que só o público autorizado acessa.
• Toda medida que depende de coluna sob OLS precisa ser mapeada. Antes de aplicar a restrição, levante onde aquele objeto é usado: em visuais, em medidas, em colunas calculadas, em relacionamentos.

A tabela abaixo resume o comportamento esperado, que é o que você deve validar no teste:

Situação do usuário	Objeto sob OLS	Resultado no relatório
Papel com permissão	Coluna visível	Visual funciona normalmente
Papel sem permissão	Coluna oculta, não usada no visual	Página abre sem erro
Papel sem permissão	Coluna oculta, usada num visual	Visual retorna erro
Papel sem permissão	Medida que referencia coluna oculta	Medida e visual quebram
Papel sem permissão	Tabela inteira oculta, com relacionamento	Avaliar impacto no modelo e em medidas ligadas

Repare na última linha. Esconder uma tabela inteira é mais delicado do que esconder uma coluna, porque a tabela participa de relacionamentos. Se ela está no meio de um caminho de filtro, negar acesso a ela pode afetar o comportamento de medidas que dependem daquela cadeia. Não é motivo para não usar, é motivo para testar com atenção redobrada.

OLS bem feito é planejamento de modelo, não configuração de última hora#

Depois de arrumar vários projetos onde o OLS foi colado no fim, eu insisto num ponto: segurança em nível de objeto se decide no desenho do modelo, não na véspera de publicar. Algumas práticas que economizam retrabalho:

• Mapeie o dado sensível antes de codar. Salário, custo, margem, CPF, dados de saúde. Saber o que é confidencial define a arquitetura, inclusive se aquilo entra ou não no modelo. Às vezes a resposta certa é nem trazer a coluna.
• Padronize a nomenclatura de papéis. O mesmo papel que carrega o RLS deve carregar o OLS correspondente. Um papel Comercial que filtra linhas por região e esconde a coluna de custo é mais fácil de auditar do que papéis espalhados.
• Versione o OLS. Configurando por TMSL você coloca a definição de segurança no Git e roda no deploy. Isso vale ouro para auditoria e para reconstruir o ambiente. É parte do trabalho de governança de dados que sustenta o modelo no tempo.
• Cuide das medidas DAX. Como uma fórmula que toca no objeto oculto quebra para o papel restrito, a organização das medidas importa. Modelo limpo, com medidas bem separadas, sofre menos com OLS. Se esse é o seu gargalo, revise as boas práticas de modelagem e DAX.
• Teste com todos os papéis. Não confie na configuração, confie no teste. Assuma cada papel, abra cada relatório e confirme o que aparece e o que quebra. É o único jeito honesto de garantir.

Vale a franqueza: OLS não é uma camada de segurança perfeita e absoluta. Ele controla o acesso lógico ao objeto no modelo tabular publicado, o que é forte e suficiente para a grande maioria dos casos de dado sensível. Mas ele convive com o resto da governança: controle de quem publica, quem tem acesso ao workspace, quem pode editar o dataset, quem consegue baixar o arquivo. Segurança de dados é o conjunto, não um recurso isolado. É por isso que tratamos OLS dentro de um trabalho maior de Power BI e de arquitetura de dados, e não como um checkbox no fim do projeto.

Perguntas frequentes#

Object-Level Security e RLS podem ser usados juntos no mesmo papel?

Sim, e essa é a configuração recomendada para dado sensível e LGPD. O mesmo papel pode ter RLS filtrando as linhas que o usuário vê e OLS escondendo as colunas ou tabelas que ele não pode ver de jeito nenhum. Um trata a abrangência do dado, o outro trata a existência dele. Juntos cobrem os dois vetores de exposição.

Por que não consigo configurar OLS direto no Power BI Desktop?

Porque o Power BI Desktop não expõe esse recurso na interface. O OLS vive na camada de metadados do modelo tabular e é configurado por ferramentas externas, como o Tabular Editor, ou por script TMSL aplicado via XMLA endpoint. O Desktop só expõe o RLS, no Gerenciar funções. Não é limitação de licença, é como o produto foi desenhado.

O que acontece com um visual que usa uma coluna escondida por OLS?

Ele quebra para o usuário que não tem permissão sobre aquela coluna. O visual retorna erro em vez de mostrar o dado. Para quem tem permissão, o mesmo visual funciona normalmente. Por isso é arriscado servir um relatório único para papéis com OLS diferente: quem não tem acesso encontra visuais quebrados. O caminho seguro costuma ser separar relatórios ou isolar os objetos sensíveis.

Esconder a coluna no visual ou marcar como oculta no modelo não é a mesma coisa?

Não. Ocultar no visual ou marcar como Hidden no modelo é cosmético: o objeto continua no modelo e acessível por quem monta relatório novo, usa Analisar no Excel ou conecta via XMLA. OLS é controle de acesso real: o objeto deixa de existir para o papel restrito, em qualquer forma de consumo do dataset. Se o dado é confidencial, ocultar não basta.

Dá para esconder uma tabela inteira, não só uma coluna?

Sim. O OLS aplica-se tanto a colunas quanto a tabelas inteiras. Esconder a tabela toda é mais delicado porque ela participa de relacionamentos, e negar acesso pode afetar medidas que dependem daquele caminho de filtro. Funciona bem, mas exige teste cuidadoso do impacto no restante do modelo antes de liberar.

Como versiono e automatizo a configuração de OLS?

Usando TMSL. Você descreve as permissões de metadados dos objetos por papel num script JSON e aplica via XMLA endpoint no seu processo de deploy. Assim a definição de segurança fica versionada em Git, auditável e reproduzível, em vez de depender de alguém clicar na ferramenta manualmente. É a prática que sustenta segurança consistente em ambientes com dev, homologação e produção.

Fechando#

Object-Level Security é o recurso certo quando esconder linhas não basta e a coluna ou a tabela inteira precisa desaparecer para determinado papel. Configure por Tabular Editor ou TMSL, combine com RLS para dado sensível, mapeie onde cada objeto é usado antes de aplicar e teste com cada papel, porque um visual que referencia o objeto oculto quebra para quem não tem permissão. Feito com planejamento, é uma camada sólida de conformidade e proteção de dado confidencial.

Se você precisa proteger dado sensível no seu ambiente Power BI sem quebrar os relatórios que já rodam, fale com a gente. A Fynx desenha a segurança do modelo junto com a arquitetura, do jeito que se sustenta no tempo.