A última violação não começou no servidor do app. Começou no dashboard.
Com um 0‑day recente do Metabase nas manchetes e roubos em massa de data warehouses estampados em processos judiciais, é hora de admitir algo desconfortável: sua ferramenta de BI faz parte da produção. Se ela consegue alcançar dados de clientes, pivotar para seu warehouse ou emitir tokens na nuvem, merece a mesma disciplina de engenharia que você aplica ao seu serviço principal. A maioria das equipes não faz isso. Os atacantes sabem.
Por que atacantes adoram sua stack de BI
Dashboards concentram valor. Uma única conta de serviço de BI comprometida pode destravar um warehouse inteiro, atravessar todos os tenants e exportar PII no throughput máximo — muitas vezes com menos limites de taxa e alarmes do que suas APIs voltadas ao cliente. BI também é onde boas intenções viram padrões ruins: papéis permissivos para que analistas consigam trabalhar, segredos embutidos para manter cron jobs rodando e links públicos ou convites compartilhados que sobrevivem ao estagiário que os criou.
Dois padrões recentes devem estar no seu quadro de riscos:
- 0‑days na camada de aplicação em BI self‑hosted: Metabase, Superset, Redash e afins são apps web complexos que você expõe a usuários internos. Quando chega um exploit remoto, é uma linha reta de RCE para chaves da nuvem, credenciais JDBC ou movimento lateral para dentro do seu warehouse.
- Exfiltração do warehouse via credenciais roubadas ou com privilégios excessivos: Acabamos de ver atacantes drenarem dados de dezenas de tenants Snowflake usando contas comprometidas e controles fracos em torno de stages externos e grandes conjuntos de resultados. Ferramentas de BI frequentemente armazenam credenciais de serviço perfeitas para esse trabalho.
Se você ainda pensa em BI como “interno” e portanto seguro, está jogando segurança de 2015 contra adversários de 2026.
Um framework de decisão para CTOs: torne o BI um sistema Tier‑0
Aqui vai um plano concreto. Dez decisões, sem buzzwords. Dá para orquestrar a maior parte em 90 dias.
1) Promoção: BI para Tier‑0 com SLOs e SLAs de patch
Trate o BI como produção:
- SLA de patch: CVEs críticos ≤ 72 horas, altos ≤ 7 dias. Publique o SLA e alerte sobre desvios.
- SLOs: SLOs de disponibilidade, latência de autenticação e latência de consultas para medir risco ao negócio quando você isolar ou desabilitar recursos durante incidentes.
- IaC para tudo: Infraestrutura imutável para a stack de BI. Nada de dashboards “pets” morando numa VM artesanal sob a conta de alguém.
2) Isolamento de rede: privado, não público
- Coloque os servidores de BI em sub-redes privadas. Sem IPs públicos. Acesso via seu ZTNA/VPN com verificações de postura de dispositivo.
- Use endpoints de VPC/PrivateLink para acesso ao warehouse (Snowflake, BigQuery, Redshift, Databricks) para que consultas nunca trafeguem pela internet pública.
- Bloqueie a saída para a internet do BI exceto para endpoints aprovados (SSO, endpoints de fornecedores). Force todo o restante do tráfego por um proxy de saída com logs.
3) Identidade até o dado: sem senhas estáticas
- Use autenticação de curta duração atrelada à identidade para bancos e warehouses: AWS RDS IAM para Postgres/MySQL, Cloud SQL IAM no GCP, Snowflake com par de chaves ou OAuth com TTL de 1–8 horas vinculado a um service principal nomeado.
- Elimine usuários compartilhados. Toda consulta deve resolver para uma pessoa ou um serviço nomeado com papel estreito. Provisionamento com SCIM e desprovisionamento automático no offboarding.
- Desative a autenticação local no BI. Exija apenas SSO+MFA. Sem redefinições de senha, sem login por senha.
4) Autorize no nível de linha e coluna
- Implemente RLS (row‑level security) no warehouse, não na ferramenta de BI. Passe a identidade do usuário de BI como parâmetro de sessão e deixe o warehouse impor visibilidade.
- Use mascaramento de colunas para PII e segredos. Valor completo só para papéis que precisam; todos os demais veem campos mascarados ou tokenizados.
- Prefira marts materializados e sanitizados em vez de conectar o BI a tabelas brutas de produção.
5) Menor privilégio significa “sem stages, sem UDFs, sem COPY”
- Em Snowflake/Databricks, crie papéis BI_readonly que não podem criar stages, funções externas nem compartilhar dados. Eles podem select apenas de views aprovadas e nada mais.
- Bloqueie COPY INTO para locais externos a partir de papéis de BI. Esse é o caminho mais rápido de exfiltração.
- Defina limites de tamanho de WAREHOUSE e QUERY_ACCELERATION off para papéis de BI a fim de limitar raio de impacto e abuso de custos.
6) Controles de saída que realmente bloqueiam exfiltração
- Restrinja os servidores de BI a fazer upload apenas para um bucket S3/GCS em allow‑list na sua conta, com Object Ownership aplicado e acesso público bloqueado.
- Force exportações do BI através de um serviço broker que carimbe linhagem, aplique watermarks, verifique regras de DLP e armazene metadados de auditoria antes de entregar ao usuário um link de download.
- Limite o tamanho de conjuntos de resultados (por exemplo, 100 mil linhas ou 100 MB por consulta) e cotas diárias de exportação por usuário e por time.
7) Segredos: curta duração ou nada
- Armazene todas as credenciais em um serviço gerenciado de segredos (AWS Secrets Manager, GCP Secret Manager) e gire em ≤ 30 dias. Para serviço‑para‑warehouse, prefira tokens OAuth/IAM com TTL ≤ 8 horas.
- Nada de segredos em arquivos de ambiente ou configs do app empacotadas nas imagens. Injete em tempo de execução via sidecar ou integração nativa.
- Desative chaves de API para incorporação que contornem SSO. Onde a incorporação for necessária, use tokens assinados, de curta duração e com escopo a uma única visualização.
8) Governança de consultas: limites de gasto e comportamento
- Defina limites de tempo (ex.: 5 minutos) e limiares de custo por consulta e por usuário. Mate varreduras descontroladas.
- Implemente revisões de acesso a datasets a cada 90 dias com expiração automática. Se ninguém renovar o acesso, ele desaparece.
- Exija aprovação por pares para criar links públicos ou exportações agendadas, com data de expiração por padrão (ex.: 14 dias).
9) Logging, detecções e canários
- Envie logs do app de BI e logs de consultas do warehouse para um SIEM central. Construa alertas para formatos de consulta incomuns (SELECT * from tabelas largas, varreduras completas repentinas, conjuntos de resultados massivos) e comportamento anômalo de exportação.
- Plante tabelas‑isca e colunas‑isca (campos de PII atraentes e não referenciados) visíveis apenas para papéis de BI. Qualquer acesso dispara um alerta.
- Grave replays de sessão do BI para administradores, como você faria para um console de produção.
10) Disciplina de patching e plugins
- Assine avisos de segurança dos fornecedores (Metabase, Superset, Redash). Automatize verificações de versão contra um manifesto canônico.
- Proíba plugins arbitrários. Faça triagem, assine e fixe versões de plugins. Desative execução dinâmica de código dentro do BI quando possível.
- Tire snapshot da imagem do BI diariamente e teste o restore semanalmente. Em um 0‑day, você vai querer reimplantar rapidamente para um estado conhecido como bom.
Padrões arquiteturais que reduzem risco sem matar a velocidade
Não conecte o BI diretamente ao OLTP
É tentador apontar o BI para a réplica de leitura de produção. Não faça isso. Os padrões de consulta são hostis ao OLTP e você estende seu raio de impacto sobre seus dados mais sensíveis. Em vez disso:
- Construa marts analíticos (dbt/ELT) apenas com as colunas de que você precisa, pré‑agregados quando fizer sentido e mascarados adequadamente.
- Janelas de atualização que atendam às necessidades do negócio (horária/diária), não “ao vivo”. Dashboards ao vivo quase nunca valem o risco, a menos que sejam métricas operacionais oriundas de telemetria sem PII.
Torne a incorporação segura ou não faça
- Use tokens de incorporação assinados com TTL de 5–15 minutos e escopos por visualização. Nada de tokens estáticos; nada de chaves globais de incorporação.
- Sirva dashboards incorporados por um proxy de backend que injete identidades e aplique RLS/CLS de forma consistente, não a partir do navegador.
Centralize exportações através de um broker
A maior parte do vazamento acontece durante “download CSV”. Centralize esse caminho:
- Exportações do BI gravam em um bucket controlado. Um serviço broker então verifica regras de DLP, carimba linhagem, aplica formatação/watermarks consistentes e produz uma URL assinada com TTL de 10 minutos.
- Exponha um livro‑razão de exportações por time com códigos de motivo. Se as pessoas souberem que seus pares podem ver grandes exportações, o comportamento melhora.
Incidente: seu BI acabou de sofrer um 0‑day. E agora?
Quando seu fornecedor de BI publicar um aviso crítico — ou você captar um canário disparando — trate como um incidente de produção. Um runbook prático:
- Isole: Remova o BI do caminho de rede (security group deny), pause o compartilhamento externo e faça snapshot da instância e do disco para fins forenses.
- Revogue: Gire credenciais do warehouse, clientes OAuth e quaisquer chaves de nuvem acessíveis a partir do nó de BI. No Snowflake, desabilite stages externos e os papéis afetados até concluir o escopo.
- Escopo: Consulte logs de auditoria do warehouse para o service principal do BI e quaisquer usuários admin. Procure formatos de consulta incomuns, janelas de tempo, tamanhos de resultados e comandos COPY/UNLOAD.
- Contenha: Imponha temporariamente cotas mais rígidas (limites de resultado menores, TTLs mais curtos) e pause exportações agendadas em toda a organização.
- Restaure: Reimplante o BI a partir de uma imagem fixada e corrigida. Reabilite papéis progressivamente após uma revisão de acessos.
- Notifique: Se houver risco material a dados de clientes, prepare sua divulgação com cronograma, categorias de dados afetadas e os controles adotados.
Meça tempo para isolar, tempo para revogar e tempo para restaurar como faria em qualquer P1. Se isso levar dias, você acabou de montar seu deck para pedir recursos no próximo trimestre.
BI SaaS vs self‑hosted: os trade‑offs reais
Ir de SaaS (Looker, Mode, Hex, entre outros) não vai salvá‑lo de identidade ou governança de dados ruins, mas tira patching e a maioria dos 0‑days na camada de app do seu prato. Trade‑offs:
- BI SaaS: Menos dor com patching, consoles de administração maduros e auditorias SOC2/ISO do fornecedor. Mas a postura de egress de dados agora inclui um terceiro. Você vai querer PrivateLink/padrões de peering de VPC, garantias de isolamento entre tenants e compromissos de residência de dados em contrato.
- BI self‑hosted: Você controla tudo — rede, plugins, data plane —, mas assume cada CVE, migração e atualização da cadeia de suprimentos. Isso pode funcionar bem se você já roda uma plataforma de dados privada e tem disciplina de infra. Caso contrário, você está inventando uma superfície de segurança de produto que não planejou.
Minha regra prática: se você não consegue aplicar patch a um CVE crítico em toda sua frota de BI em ≤ 72 horas e girar credenciais do warehouse em ≤ 24 horas, escolha SaaS com conectividade privada. Do contrário, faça self‑hosted com os controles deste playbook.
Minimização de dados vence controles engenhosos
O controle mais eficaz é não ter o dado em primeiro lugar:
- Classifique e elimine: Identifique colunas de PII no seu warehouse e remova‑as dos marts que alimentam o BI, a menos que sejam absolutamente necessárias. Substitua por agregados ou tokens.
- Snapshots com TTL: Defina políticas de expiração em tabelas de staging e artefatos intermediários para que “temporário” não vire “para sempre”.
- Privacidade diferencial para métricas que não precisam de fidelidade em nível de linha.
Time pequeno? Um 30‑60‑90 prático
Dias 0–30: feche os buracos óbvios
- Elimine IPs públicos do BI; exija SSO+MFA; desative a autenticação local.
- Mova o BI para sub‑redes privadas com saída via proxy; coloque endpoints do warehouse em allow‑list via PrivateLink.
- Gire todas as credenciais de warehouse e de serviços do BI; remova usuários compartilhados; habilite logs de auditoria.
- Defina limites conservadores de resultado e limites diários de exportação por usuário; pause links públicos e exportações agendadas sem revisão.
Dias 31–60: identidade e autorização
- Implemente autenticação a warehouses baseada em IAM/OAuth com TTLs de 1–8 horas.
- Empurre RLS/CLS para o warehouse; migre consultas do BI para views e marts homologados.
- Crie papéis de menor privilégio para o BI (sem stages/UDFs/COPY). Adicione tabelas/colunas‑canário e alertas.
Dias 61–90: governança e resiliência
- Coloque de pé um broker de exportação com checagens de DLP e watermarks; roteie todos os downloads por ele.
- Documente e treine o runbook de incidente 0‑day do BI; meça tempos de isolar/revogar/restaurar.
- Automatize pinning de versões e rollouts de patch; defina e faça cumprir SLAs de patch.
Parceiros nearshore podem ajudar a executar as partes chatas e necessárias: IaC, codificação de políticas, integração SCIM/SSO e runbooks testáveis. Nada disso é glamouroso. Tudo isso evita finais de semana muito públicos.
Como é o estado ideal
Quando você acerta, sua superfície de BI se parece com seu console de produção:
- Engenheiros entregam dashboards do mesmo jeito que entregam serviços: via code review, CI e imagens fixadas.
- Analistas se autenticam com SSO+MFA; toda consulta mapeia para uma pessoa; acessos expiram se não usados.
- PII nunca aparece em marts por padrão; quando aparece, mascaramento e RLS/CLS se aplicam automaticamente via políticas compartilhadas.
- Exportações são visíveis, com rate‑limit, watermarks e auditáveis. Exfiltração é difícil e óbvia.
- Quando cair o próximo 0‑day, você isola em minutos, revoga em horas, restaura em um dia — com uma trilha documental limpa.
Você não chega lá comprando uma ferramenta. Você chega lá tratando o BI pelo que ele é: um sistema de produção com um grande botão vermelho escrito “download”.
Principais lições
- Pare de chamar BI de “interno”. Se toca dados de clientes, é produção. Promova a Tier‑0 com SLOs reais e SLAs de patch.
- Mate a exposição pública. Coloque o BI em sub‑redes privadas com ZTNA, PrivateLink para warehouses e egress travado.
- Nada de credenciais estáticas. Use autenticação de curta duração atrelada à identidade para data stores; proíba usuários compartilhados e logins locais.
- Autorize no warehouse. Aplique RLS/CLS e menor privilégio; bloqueie stages, UDFs e COPY/UNLOAD para papéis de BI.
- Centralize e governe exportações. Limite tamanho de resultados, adicione DLP via broker, aplique watermarks em tudo e audite agressivamente.
- Treine o runbook de 0‑day. Meça tempos de isolar/revogar/restaurar como qualquer P1. Se você não consegue aplicar patch em 72 horas, repense sua abordagem — ou vá de SaaS com conectividade privada.