Sensitivity labels no Power BI: como classificar dados

O dado sensível não vaza no Power BI, ele vaza no Excel que saiu dele#

O buraco de governança mais comum em empresas que usam Power BI não está no relatório. Está no que acontece depois dele. Alguém abre um dashboard de folha de pagamento, clica em "Exportar para Excel", salva na área de trabalho, anexa num e-mail e manda para um fornecedor. Naquele instante, CPF, salário e dados de saúde de colaboradores saíram do ambiente corporativo controlado e viraram um arquivo solto, sem senha, sem rastreamento, sem qualquer restrição. O relatório continuava seguro. O dado, não. É esse cenário que os sensitivity labels no Power BI foram feitos para impedir.

Os rótulos de confidencialidade, também chamados de rótulos de sensibilidade, vêm do Microsoft Purview Information Protection e permitem classificar relatórios e conjuntos de dados, aplicar proteção e criptografia, e fazer com que essa proteção acompanhe o dado mesmo quando ele é exportado. Este artigo cobre o que esses rótulos são de verdade, como funciona a herança a partir da fonte, o que a criptografia realmente protege ao exportar, onde estão os limites da ferramenta, e como tudo isso apoia a conformidade com a LGPD. Direto e sem vender mágica.

Rótulo de confidencialidade é classificação mais proteção, não só uma etiqueta colorida#

O primeiro mal-entendido é achar que um rótulo é só um carimbo visual, aquela tarja "Confidencial" no canto do relatório. Ele é isso, mas é muito mais. Um sensitivity label é uma configuração de metadado que viaja junto com o arquivo e carrega duas coisas: a classificação (o quão sensível é aquele dado) e a proteção associada (o que pode e o que não pode ser feito com ele).

A classificação é a parte que a maioria das empresas já entende. Você define uma taxonomia, algo como Público, Interno, Confidencial e Altamente Confidencial, e aplica o rótulo correspondente a cada relatório ou conjunto de dados. Até aí, é organização.

A proteção é onde mora o valor real. Um rótulo pode aplicar criptografia, restringir quem abre o arquivo, bloquear impressão, bloquear cópia de conteúdo e impedir exportação. Como a criptografia e as permissões ficam gravadas no próprio arquivo, elas continuam valendo fora do Power BI. É essa diferença que separa um rótulo decorativo de um controle de segurança de verdade.

Camada	O que faz	Exemplo prático
Classificação	Nomeia o nível de sensibilidade do dado	Marcar o dataset de RH como "Altamente Confidencial"
Marcação visual	Adiciona cabeçalho, rodapé ou marca d'água	Tarja "Confidencial" visível no relatório e nos exports
Proteção e criptografia	Restringe abrir, copiar, imprimir e exportar	Só o time de RH descriptografa o Excel exportado
Metadado persistente	Faz o rótulo viajar com o arquivo	O PDF continua rotulado mesmo salvo fora da empresa

O ponto que vale gravar: no Power BI, o rótulo classifica tanto o relatório quanto o conjunto de dados (o modelo semântico) por trás dele. Isso importa por causa da herança, que é o próximo assunto.

A herança da fonte é o que torna o rótulo escalável em vez de manual#

Rotular relatório por relatório, na mão, não escala. Numa empresa com centenas de relatórios, alguém sempre vai esquecer de marcar o dashboard novo, e é justamente o esquecido que vaza. A herança resolve isso.

O rótulo pode ser herdado da fonte de dados. Na prática, isso funciona em algumas direções que vale distinguir:

• Herança do conjunto de dados para o relatório. Quando um relatório é construído sobre um modelo semântico já rotulado como Confidencial, ele nasce herdando essa classificação. O analista não precisa lembrar de aplicar nada.
• Herança da fonte de dados para o conjunto de dados. Quando um dataset do Power BI puxa dados de fontes que já têm rótulo aplicado no Microsoft Purview, como um data warehouse ou arquivos no armazenamento, a classificação mais restritiva pode ser propagada automaticamente para o conjunto de dados no Power BI.
• Herança na hora do export. Quando o usuário exporta para Excel, PowerPoint ou PDF, o arquivo gerado herda o rótulo do relatório de origem, junto com a proteção que aquele rótulo carrega.

O efeito combinado é o que interessa: a classificação se origina o mais perto possível da fonte e desce a cadeia inteira sem depender de disciplina manual em cada etapa. Se o dado nasce sensível no banco, ele chega sensível no relatório e sai sensível no Excel. Essa continuidade é a diferença entre governança que funciona e governança que existe só no slide. É o tipo de arquitetura que estruturamos dentro dos serviços de governança de dados, começando pela classificação na origem, na camada de engenharia de dados, e não no relatório final.

A criptografia que segue o dado ao exportar é o recurso que realmente muda o jogo#

Volto ao cenário do começo, porque é aqui que a promessa se cumpre ou não. Sem rótulo com proteção, o "Exportar para Excel" é uma porta aberta. Com rótulo com proteção configurada, o arquivo exportado sai criptografado e com as permissões coladas nele.

Isso significa, concretamente, que o Excel, o PowerPoint ou o PDF gerado a partir de um relatório protegido carrega as mesmas regras: quem não tem permissão não abre, mesmo que receba o arquivo por e-mail, mesmo que copie para um pen drive, mesmo fora da rede da empresa. A proteção não está no Power BI, está no arquivo. Esse é o recurso que efetivamente tapa o buraco do dado que "escapa" da ferramenta.

Vale ser honesto sobre os limites, porque consultor que só elogia a ferramenta não está ajudando:

• A proteção por criptografia depende do rótulo ter criptografia configurada. Um rótulo apenas de marcação visual não impede ninguém de reencaminhar o arquivo. Marca d'água não é cadeado.
• Exportações para formatos que não suportam a proteção, ou caminhos de export que não a preservam, podem sair sem o cadeado. Isso precisa ser testado no seu tenant, não presumido.
• O rótulo não protege contra quem tira uma foto da tela com o celular, nem contra quem transcreve os números na mão. Nenhuma tecnologia protege.
• Rótulo não substitui Row-Level Security. Um controla o que sai do relatório e como sai protegido; o outro controla qual linha cada pessoa vê dentro do relatório. São controles complementares.

Nada disso invalida o recurso. Só delimita para que ele serve. Sensitivity label com criptografia resolve o vazamento por export e por reencaminhamento, que é o cenário mais frequente e mais caro. Ele não resolve todos os cenários de segurança, e ninguém deveria vendê-lo como se resolvesse.

Como implantar sensitivity labels no Power BI sem quebrar a operação#

A tentação é ligar tudo de uma vez com o rótulo mais restritivo. É o jeito mais rápido de gerar um enxame de tíquetes de "não consigo abrir meu relatório" e queimar a iniciativa antes dela pegar. A sequência que funciona é gradual.

Etapa	O que fazer	Cuidado principal
1. Taxonomia	Definir os níveis de rótulo com o jurídico e a segurança	Poucos níveis claros valem mais que muitos ambíguos
2. Habilitar no tenant	Ativar sensitivity labels para o Power BI no Purview e no admin	Definir quem pode aplicar e alterar rótulos
3. Marcação primeiro	Começar só com classificação e marca visual, sem criptografia	Deixar a empresa se acostumar antes de restringir
4. Herança	Rotular os conjuntos de dados centrais e deixar herdar	Priorizar as fontes com dado pessoal e financeiro
5. Proteção	Ligar criptografia e restrição de export nos níveis mais altos	Testar cada caminho de export antes de generalizar
6. Monitorar	Acompanhar uso, exports e rótulos aplicados no Purview	Revisar periodicamente o que está sem rótulo

Duas recomendações de quem já viu isso dar errado. Primeiro: comece pela classificação sem criptografia, e só depois ligue a proteção nos níveis mais sensíveis. Isso dá tempo de a empresa entender os rótulos antes de sentir as restrições. Segundo: rotule os conjuntos de dados centrais e certificados primeiro, porque são eles que alimentam a maior parte dos relatórios, e a herança faz o trabalho pesado a partir daí. Essa lógica de tratar o modelo semântico como o ponto de controle é a mesma que defendemos nos serviços de Power BI: governança nasce no modelo, não no visual.

A ligação com a LGPD é direta, mas o rótulo é meio, não é conformidade pronta#

Aqui é preciso ser preciso, porque muita gente confunde ferramenta com conformidade. A classificação de dados apoia a conformidade com a LGPD, a Lei nº 13.709/2018, mas não a entrega sozinha. O que os sensitivity labels fazem é operacionalizar princípios que a lei exige.

A LGPD determina que o tratamento de dados pessoais siga princípios como segurança, prevenção e minimização, e que o controlador adote medidas técnicas capazes de proteger os dados de acessos não autorizados. Rótulo de confidencialidade é uma dessas medidas técnicas. Ele materializa, dentro do Power BI, obrigações que de outra forma ficariam só no papel da política de privacidade.

• Saber onde está o dado pessoal. Classificar relatórios e conjuntos de dados dá à empresa um inventário de onde há dado sensível, algo que a LGPD pressupõe para qualquer resposta a incidente ou pedido de titular.
• Proteger o dado de acesso indevido. A criptografia e a restrição de export são medidas técnicas concretas de segurança, exatamente o que o artigo de segurança da lei cobra.
• Reduzir a superfície de vazamento. O rótulo que segue o export ataca diretamente o cenário mais comum de incidente, o dado que sai da ferramenta e circula sem controle.
• Demonstrar diligência. Ter classificação e proteção configuradas é evidência de que a empresa adotou medidas, o que pesa em qualquer avaliação da autoridade.

O que o rótulo não faz: ele não define base legal, não gerencia consentimento, não responde pedido de titular e não substitui o encarregado de dados. Ele é uma peça técnica de um programa de privacidade, não o programa inteiro. Tratamos essa fronteira em detalhe no artigo sobre governança de dados, Power BI e LGPD, que conecta rótulos, RLS, workspaces e Microsoft Purview num desenho único. Quem vende sensitivity label como "solução de LGPD" está simplificando demais, e você deveria desconfiar.

Perguntas frequentes#

O que são sensitivity labels no Power BI? São os rótulos de confidencialidade do Microsoft Purview Information Protection aplicados ao Power BI. Eles classificam relatórios e conjuntos de dados por nível de sensibilidade e podem aplicar proteção, incluindo marcação visual, criptografia e restrição de exportação. A classificação e a proteção ficam gravadas como metadado e acompanham o arquivo.

O rótulo protege o arquivo mesmo depois de exportado? Sim, quando o rótulo tem criptografia configurada. Ao exportar para Excel, PowerPoint ou PDF, o arquivo gerado herda o rótulo e a proteção associada. As permissões de abrir, copiar e imprimir continuam valendo fora do Power BI. Se o rótulo for apenas de marcação visual, sem criptografia, o arquivo não fica cadeado, só carimbado.

Preciso rotular cada relatório manualmente? Não, e esse é o ganho principal da herança. Um relatório construído sobre um conjunto de dados já rotulado herda a classificação. Conjuntos de dados que puxam de fontes rotuladas no Purview podem herdar o rótulo mais restritivo dessas fontes. O caminho recomendado é rotular os modelos centrais e deixar a herança propagar para baixo.

Sensitivity label substitui Row-Level Security? Não, são controles complementares. RLS decide qual linha de dado cada usuário enxerga dentro do relatório. O rótulo decide como o relatório e seus exports ficam classificados e protegidos. Um ambiente maduro usa os dois: RLS para minimizar o que cada pessoa vê, rótulo para proteger o que sai da ferramenta.

Sensitivity label garante conformidade com a LGPD? Não garante sozinho. A classificação de dados apoia a conformidade com a LGPD, a Lei nº 13.709/2018, por materializar medidas técnicas de segurança e minimização que a lei exige. Mas ela não define base legal, não gerencia consentimento nem responde pedidos de titular. É uma peça técnica de um programa de privacidade mais amplo, não o programa inteiro.

Por onde começar a implantação sem travar a operação? Comece pela taxonomia de níveis definida com jurídico e segurança, habilite os rótulos no tenant, e aplique primeiro só classificação e marcação visual, sem criptografia. Deixe a empresa se acostumar, rotule os conjuntos de dados centrais para acionar a herança, e só depois ligue a proteção com criptografia nos níveis mais sensíveis, testando cada caminho de exportação antes de generalizar.

Fechando#

Sensitivity labels não são um recurso cosmético e também não são uma bala de prata de conformidade. São a peça técnica que faz a classificação de dado sair do papel e virar proteção que acompanha o arquivo, especialmente no momento mais perigoso, que é a exportação. Bem implantados, com herança a partir da fonte e criptografia nos níveis certos, eles fecham o buraco por onde o dado sensível costuma vazar, e dão à empresa evidência concreta de diligência sob a LGPD.

Se a sua empresa já tem Power BI rodando mas nenhum controle sobre o que sai dele, esse é o ponto certo para começar. Quer estruturar classificação, herança e proteção de dados no seu ambiente sem travar a operação? Fale com a gente.