> For the complete documentation index, see [llms.txt](https://docs.powermonitor.com.br/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.powermonitor.com.br/principais-funcionalidades/auditoria-e-seguranca.md).

# Auditoria e Segurança

Auditoria e Segurança do Power Monitor: quem tem e quem tinha acesso a quê, quem viu cada relatório e de onde, service principals, RLS, compartilhamento direto, assinaturas e risco comportamental, com

"Quem tinha acesso a este relatório no dia em que os números vazaram?" O portal do Power BI responde quem tem acesso **hoje**, workspace por workspace. O log de atividade guarda os eventos por um tempo limitado, num formato que ninguém consegue ler sem montar um projeto de dados.

O Power Monitor coleta, guarda e organiza tudo isso para você responder em minutos o que a auditoria, o jurídico ou a segurança da informação perguntarem.

## Quem tem acesso, por qual caminho

A **Auditoria de Permissões** e o **Dashboard de Permissões** mostram todas as permissões de workspaces, itens do Fabric, gateways, conexões e Power Embedded, incluindo o acesso **herdado de grupos** e **de workspace**. Achados de risco aparecem prontos: contas externas com permissão de escrita, workspaces sem administrador, acessos que talvez não devessem existir.

<figure><picture><source srcset="/files/g6ZYuGygy8sgjTZZi2wh" media="(prefers-color-scheme: dark)"><img src="https://243386050-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSidDR54hIYDyuvbsnXwG%2Fuploads%2Fgit-blob-d1993487d5dcc13932d8457f6e962a55aed064c4%2Fpm-dashboards-permissoes-revisao-acesso.png?alt=media" alt="Dashboard de Permissões com os acessos que merecem revisão"></picture><figcaption><p>Dashboard de Permissões: acessos que merecem revisão</p></figcaption></figure>

## Quem tinha acesso, numa data passada

O **Histórico de permissões** registra quem ganhou, perdeu ou mudou de acesso ao longo do tempo e responde, para qualquer data coberta, **quem tinha acesso** a um workspace ou artefato. É a pergunta que toda investigação de incidente começa fazendo.

<figure><picture><source srcset="/files/T9rEhCYyolgqe9ZknM2W" media="(prefers-color-scheme: dark)"><img src="https://243386050-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSidDR54hIYDyuvbsnXwG%2Fuploads%2Fgit-blob-306c4e0be6acfc30097ce1cb07b9b1faa6cd2359%2Fpm-auditoria-historico-permissoes-quem-tinha-acesso.png?alt=media" alt="Histórico de permissões respondendo quem tinha acesso numa data passada"></picture><figcaption><p>Quem tinha acesso em uma data</p></figcaption></figure>

## Quem viu o quê, e de onde

* **Geral de Eventos:** todas as atividades do Power BI e do Fabric (visualizações, edições, exclusões, compartilhamentos, Copilot, administração), com atalho para as **ações críticas**.
* **Visualizações de Relatórios:** quem abriu cada relatório ou dashboard, com país, estado e cidade de origem do acesso.
* **Alertas de acesso:** acessos de um país novo, saltos de distância improváveis entre dois acessos e acessos simultâneos.

## Risco comportamental

Um **score diário de 0 a 100**, por pessoa, que compara a atividade de cada um com o próprio histórico e aponta mudanças que merecem atenção: um pico de exportações, uma conta que volta depois de meses parada, acessos de locais distantes em pouco tempo. Cada score mostra os fatores que o compõem, sem caixa-preta, e a organização decide se liga o recurso e os sinais de rede. Ajuda a encontrar o risco antes que ele vire incidente.

<figure><picture><source srcset="/files/DI9zTvzQOXVdKD3i1AF4" media="(prefers-color-scheme: dark)"><img src="https://243386050-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSidDR54hIYDyuvbsnXwG%2Fuploads%2Fgit-blob-4f8a330b5da84a95a5c216bd00c0beccfef08fc2%2Fpm-auditoria-risco-comportamental.png?alt=media" alt="Tela Risco comportamental com o ranking por pessoa e a tendência"></picture><figcaption><p>Risco comportamental por pessoa</p></figcaption></figure>

## As auditorias que ninguém faz à mão

* **Service Principals:** aplicativos com permissão direta no ambiente, com destaque para escrita e administração de workspace por terceiros.
* **Segurança em Nível de Linha:** roles de RLS de cada modelo, membros e filtros, e os achados (modelo rotulado sem RLS, role sem membros ou sem filtro).
* **Compartilhamento Direto:** quem acessa um item sem ter acesso ao workspace dele.
* **Assinaturas de E-mail:** relatórios com assinatura agendada e quantos assinantes são de domínio externo.
* **Revisões de acesso:** campanhas em que os responsáveis por cada workspace confirmam, pessoa a pessoa, quem deve continuar com acesso, com registro de cada decisão.

## E a auditoria do próprio Power Monitor

Logins, páginas acessadas, alterações de configuração, consentimentos, e-mails enviados e ações executadas sobre capacidades também ficam registrados. Quem administra o Power Monitor também é auditável.

## Por que isso importa

* **Compliance sem planilha:** LGPD, ISO 27001 e SOC 2 pedem trilha histórica; ela já está pronta.
* **Investigação em minutos:** quem tinha acesso, quem viu e de onde, numa só ferramenta.
* **Menor superfície de risco:** acessos excessivos, externos e esquecidos aparecem antes da auditoria.

## Páginas relacionadas

* [Auditoria](/power-monitor/auditoria.md): todas as telas do módulo
* [Dashboard de Permissões](/power-monitor/dashboards/dashboard-de-permissoes.md)
* [Permissões e Acessos](/principais-funcionalidades/permissoes-e-acessos.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.powermonitor.com.br/principais-funcionalidades/auditoria-e-seguranca.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
