Monitoramento da atividade do banco de dados: o que observar e como fazer
Oct 20, 2026
O monitoramento da atividade do banco de dados existe porque as ferramentas nativas de auditoria no SQL Server, Oracle, MySQL e PostgreSQL não detectam leituras sensíveis, valores antes e depois, nem adulterações por contas privilegiadas que devem ser monitoradas de perto. Ele registra de forma independente quem se conectou, o que mudou e se alguém alterou o próprio rastro. Limite a coleta a tabelas regulamentadas, encaminhe registros para um SIEM e ajuste alertas com base em uma linha de base de atividade normal.
Bancos de dados armazenam os registros de clientes, pagamentos e saúde que reguladores, atacantes e auditores mais valorizam. As facilidades nativas de auditoria no SQL Server, Oracle, MySQL e PostgreSQL capturam alterações em objetos e permissões, mas oferecem pouca visibilidade sobre quem leu linhas sensíveis.
O Relatório de Segurança de Dados e Identity Netwrix 2026 constatou que 75% das exposições de dados sensíveis começam com identidades comprometidas ou permissões mal configuradas. A auditoria nativa oferece a menor visibilidade onde essas identidades têm mais poder: contas privilegiadas que podem editar o próprio registro de auditoria.
O monitoramento da atividade do banco de dados gera um registro independente de acessos, alterações e ações administrativas, para que as equipes de segurança possam investigar incidentes, comprovar conformidade e detectar usos indevidos antes que uma conta comprometida ou uma alteração silenciosa na configuração se torne uma violação reportável.
O que é monitoramento de atividade de banco de dados?
O monitoramento da atividade do banco de dados (DAM) é uma disciplina de segurança que captura, armazena e analisa a atividade de usuários e administradores dentro de um banco de dados, independentemente do próprio mecanismo do banco de dados. Sob demanda, responde quem se conectou, o que foi lido ou alterado e se alguém modificou a configuração de auditoria.
DAM acompanha o monitoramento de desempenho, mas tem um propósito diferente. As ferramentas de desempenho rastreiam CPU, I/O e latência de consultas para manter o motor saudável. DAM, por sua vez, captura a instrução SQL, identidade do usuário, endereço IP do cliente e timestamp, para que você possa vincular a atividade a uma pessoa ou serviço nomeado.
Uma ferramenta DAM coleta essas informações por meio de um network tap, um agente host, ou da própria função de auditoria do banco de dados, e as encaminha para um repositório fora do banco para que o registro sobreviva a uma conta de administrador comprometida.
Por que o monitoramento da atividade do banco de dados é importante
Para um administrador de banco de dados (DBA) ou analista de segurança, a parte difícil de qualquer incidente ou auditoria é provar quem mexeu em quê. Sem uma trilha independente no banco de dados, as equipes reconstróem essa prova manualmente a partir de logs parciais, geralmente com prazo.
Dados sensíveis concentram-se na camada do banco de dados
Registros de clientes, dados de titulares de cartão e protected health information (PHI) vivem em tabelas de banco de dados. Qualquer dado regulamentado passa por um banco de dados em algum momento. Quando o acesso ao banco de dados não é monitorado, os ativos mais sensíveis do ambiente perdem sua camada mais próxima de responsabilidade, e todo controle subsequente depende de uma trilha que nunca foi capturada.
Os logs nativos do banco de dados não podem suportar uma investigação
O rastreamento padrão do SQL Server captura alterações de objetos e permissões, mas não a atividade SELECT, e mantém apenas 100 MB de histórico. Pior ainda, A Microsoft alerta que os sysadmins podem adulterar a trilha de auditoria, razão pela qual NIST SP 800-53 AU-9(2) exige que os registros de auditoria sejam armazenados em um sistema separado daquele auditado.
Os frameworks de conformidade exigem um registro de auditoria do banco de dados
Cada estrutura principal trata a atividade do banco de dados como evidência. PCI DSS v4.0.1 O Requisito 10 exige 12 meses de acesso registrado a dados do titular do cartão e integridade do registro de auditoria. O 45 CFR 164.312(b) da HIPAA exige mecanismos que registrem e examinem a atividade em sistemas ePHI.
No seu relatório de inspeção de 2023 sobre Ernst & Young Incorporated (Publicação PCAOB nº 104-2024-113), o PCAOB citou a empresa por não avaliar como os responsáveis pelo controle do cliente revisaram as alterações diretas no banco de dados por trás do seu sistema contábil, em uma auditoria do controle interno sobre o relatório financeiro sob SOX.
O RGPD Artigo 5(2) exige que os responsáveis demonstrem conformidade com os princípios do regulamento, incluindo mostrar quem acessou os dados pessoais.
Contas comprometidas e uso indevido interno surgem primeiro no banco de dados
Um login válido parece legítimo para todos os sistemas, exceto para aquele que registra o que foi feito, por isso o roubo de credenciais e o uso indevido interno raramente acionam os controles perimetrais. O 2026 Data Breach Investigations Report da Verizon descobriu que o abuso de credenciais esteve presente em 39% das violações em algum ponto da cadeia de ataque, e o monitoramento contínuo do banco de dados é frequentemente o primeiro lugar para detectar o movimento lateral que se segue.
Netwrix Auditor registra valores antes e depois de eventos de acesso e alteração em ambientes híbridos Microsoft. Solicite uma demonstração.
Atividades de banco de dados que você precisa monitorar
As categorias abaixo têm peso suficiente em segurança ou conformidade para justificar suas próprias regras de detecção. Juntas, elas cobrem quem entrou, o que foi lido ou alterado e se alguém manipulou o registro: as perguntas com que toda investigação começa.
Eventos de autenticação e conexão
Os registros de login são o primeiro lugar onde uma credencial roubada se torna visível. Logins falhos revelam tentativas de adivinhar senhas ou credential stuffing, enquanto logins bem-sucedidos de fontes incomuns revelam credenciais sendo usadas onde não deveriam.
Os logons privilegiados e de contas de serviço merecem atenção especial, pois uma conta de serviço que de repente se conecta de uma nova estação de trabalho em vez de sua camada usual de aplicação quase sempre vale a pena ser investigada. Oracle habilita uma predefined failed-logon policy por padrão em novos bancos de dados, embora os atualizados frequentemente precisem ser ativados manualmente.
Leituras de dados sensíveis e exportações em massa
A visibilidade direta de quem consultou tabelas regulamentadas diferencia saber que ocorreu uma exposição de provar o que foi levado. O acesso pela primeira vez a uma tabela que um usuário nunca tocou e a extração em massa por meio de ferramentas como bcp ou expdp, são os padrões de leitura que mais valem a pena observar, o mesmo comportamento que os controles de data loss prevention monitoram no endpoint.
Alterações no esquema e na configuração
Alterações no esquema e na configuração podem destruir dados ou cegar a monitoração destinada a capturar todo o resto. CREATE, ALTER, e DROP declarações contra tabelas e procedimentos armazenados precisam de seus próprios alertas, e alterações na configuração de auditoria merecem a resposta mais rápida. A Microsoft fornece xp_cmdshell desativado por padrão no SQL Server porque ativá-lo dá a um invasor um shell de comando.
Privilégios novos ou escalados
Uma única concessão de privilégio pode transformar uma conta limitada em uma que lê tudo ou desativa completamente o registro de auditoria. Alterações na associação a funções, novos logins e qualquer adição ao papel de sysadmin no SQL Server, ou um papel DBA equivalente no Oracle, são alertas inegociáveis, o mesmo privilege escalation padrão monitorado na camada de identidade. O princípio do menor privilégio é o controle básico. A política ORA_ACCOUNT_MGMT da Oracle cobre isso, mas vem desativada por padrão.
Alterações de dados em tabelas sensíveis
Quando um salário ou saldo de conta muda sem autorização, a primeira pergunta é qual era o valor antes da mudança. Os registros nativos de auditoria registram apenas o texto da declaração, não os valores das linhas, portanto, um mecanismo separado deve preservar o conteúdo antes e depois, como o Change Data Capture do SQL Server, o registro binário de imagem de linha do MySQL ou os PostgreSQL triggers. Alertas sobre mudanças em massa ou fora do horário em tabelas reguladas correspondem ao MITRE T1565, Data Manipulation.
Atividade que quebra o padrão normal
Regras básicas detectam atividades que parecem comuns isoladamente, mas incomuns para a conta que as executa, como um usuário consultando 10 tabelas em cinco minutos ou uma conta de aplicativo conhecida conectando-se de um novo endereço IP.
Esta é a única categoria que depende da análise SIEM em vez da configuração nativa de auditoria, a mesma abordagem de linha de base comportamental que identity threat detection usa na camada de conta.
Como implementar o monitoramento da atividade do banco de dados
Siga os cinco passos na ordem, pois cada um depende do anterior. O que você definir no passo 1 determina qual método de coleta se encaixa no passo 2, e assim por diante.
Eles também assumem uma equipe pequena que não pode revisar manualmente cada evento, então várias etapas abaixo dependem de implantações graduais e linhas de base automatizadas em vez de triagem manual.
1. Defina o escopo do que será monitorado
Comece inventariando quais bancos de dados contêm dados regulados ou sensíveis para os negócios, como folha de pagamento, titulares de cartão, saúde ou propriedade intelectual, e classifique-os por fator regulatório. Esse inventário só importa quando você sabe quais tabelas contêm campos sensíveis, então execute primeiro data classification; pule esta etapa, e uma especificação de auditoria de folha de pagamento não terá nada para apontar.
As apostas são reais: a pesquisa por trás do Netwrix 2026 Data and Identity Security Report descobriu que 57% das organizações não mantêm continuamente um inventário de dados sensíveis, então a maioria das equipes começa essa etapa no escuro.
Depois de mapear bancos de dados sensíveis, estenda o mesmo inventário para as contas privileged, compartilhadas e de serviço que os acessam, e comprometa-se a monitorar cada sessão privileged na íntegra, mesmo quando o registro de usuários regulares for seletivo.
CIS Safeguard 8.5 estabelece o mínimo para esse compromisso. No mínimo, capture nome de usuário, carimbo de data/hora e endereços de origem e destino para cada ativo que contenha dados sensíveis.
2. Escolha um método de coleta que corresponda ao seu ambiente
A captura passiva de rede via uma porta SPAN é o ponto de partida se você precisar de zero carga no servidor. No entanto, essa troca por carga zero custa a visibilidade em Transport Layer Security (TLS) com segredo avançado, conexões locais e bancos de dados gerenciados na nuvem.
Quando bloquear uma declaração é mais importante do que vê-la, um proxy inline é mais adequado, pois termina o TLS por si só, embora esse mesmo controle adicione latência e torne o proxy uma dependência de disponibilidade.
Se as conexões locais ainda precisarem de cobertura depois disso, e a equipe puder tolerar o custo da CPU mais o trabalho de revalidação que cada atualização do kernel ou do banco de dados traz, um agente host fecha essa lacuna. Equipes que executam banco de dados como serviço (DBaaS) ou que precisam de visibilidade em procedimentos armazenados e criptografia, chegam lá combinando auditoria nativa com coleta sem agente.
Oracle relata uma sobrecarga de CPU de dígito médio único para auditoria nativa de até 360.000 registros de auditoria por hora. A coleta sem agente adiciona carga extra, então teste a combinação antes de implementá-la.
Na prática, a maioria das equipes combina métodos de qualquer forma, pois a documentação AVDF da Oracle recomenda emparelhar o monitoramento de rede com a auditoria de banco de dados para que cada um cubra os pontos cegos do outro.
3. Defina políticas e limites de alerta que uma pequena equipe possa atuar
Ative as regras em etapas, não todas de uma vez, pois ativar tudo no primeiro dia sobrecarrega uma equipe pequena com falsos positivos. Comece essa implantação gradual com adulteração de auditoria e concessões de sysadmin, mapeadas a partir das seis categorias de atividade acima, pois essas duas têm a menor tolerância para alertas perdidos.
NIST SP 800-94 alerta que um sistema recém-implantado normalmente gera muitos falsos positivos antes que suas regras estejam totalmente ajustadas ao ambiente, razão pela qual a abordagem em etapas é importante aqui.
Regras de volume e padrão de acesso exigem um tratamento diferente. Execute-as como anomalias, ajustadas com pelo menos uma semana de dados base, na mesma ordem de magnitude que a Microsoft Sentinel usa para sua própria regra de anomalia de linhas afetadas, que treina por 14 dias.
Espere que esses limites permaneçam locais ao seu ambiente em vez de seguir um número universal, pois a anomalia para uma equipe é 100 linhas, para outra é 500.000, e somente sua própria linha de base revela qual é qual.
4. Centralize eventos do banco de dados e correlacione-os com o contexto de identidade
Centralize primeiro a coleta de logs, conforme CIS Safeguard 8.9 exige, e use uma ferramenta que filtre grandes conjuntos de eventos para um conjunto que um humano possa revisar, conforme recomendado pelo NIST SP 800-61 Rev. 3. Uma vez que esse pipeline exista, correlacione cada evento com a conta por trás dele, pois um log centralizado sem contexto de identidade ainda o deixa lendo instruções SQL brutas em vez de nomes.
No Microsoft Sentinel, essa correlação ocorre por meio de tabelas específicas. Direcione eventos de auditoria do Azure SQL para a tabela SQLSecurityAuditEvents (ou AzureDiagnostics em configurações antigas), eventos do Windows do SQL Server para SecurityEvent, e alertas do Defender para SecurityAlert; depois use a tabela IdentityInfo para associar a pessoa por trás de cada conta.
Os usuários do Splunk e IBM QRadar podem seguir o mesmo padrão com suas próprias consultas de identidade; o benefício é transformar "alguém executou um SELECT grande" em "uma conta de contratado adicionada ao sysadmin há duas horas executou um SELECT grande."
5. Teste, ajuste e mantenha o pipeline de monitoramento
Teste toda a pipeline com atividade representativa antes de confiar nela em produção. Adicione um login de teste a um papel de servidor, altere uma especificação de auditoria e execute uma exportação de 600 linhas, depois confirme se cada alerta chega com a identidade correta anexada. Uma pipeline que registra o evento, mas perde o contexto da identidade, está apenas pela metade construída.
Reconstrua as linhas de base sempre que os aplicativos mudarem e verifique periodicamente as políticas de auditoria, pois Oracle's AVDF documentation alerta que um DBA pode modificá-las ou excluí-las. Recupere e revise as configurações conforme o cronograma; CIS Safeguard 8.1 exige essa revisão pelo menos anualmente.
A retenção merece a mesma disciplina. Defina-a para o mandato mais rigoroso aplicável, com o piso de 12 meses do PCI DSS como base, e mantenha também a configuração de diagnóstico que alimenta um pipeline Azure SQL na sua lista monitorada, pois excluí-la pode interromper silenciosamente a coleta.
Como a Netwrix ajuda você a monitorar a atividade do banco de dados
A maior parte do trabalho acima, desde definir o escopo até correlacionar o contexto de identidade, aplica-se independentemente das ferramentas que você usa. Netwrix Auditor cobre a coleta, alertas e detalhes antes e depois para SQL Server e Oracle, e Netwrix Access Analyzer adiciona a camada de permissão e dados sensíveis.
Rastreamento de logons e acesso privilegiado
Netwrix Auditor SQL Server monitoring registra logons bem-sucedidos e falhados e rastreia a atividade do DBA, incluindo ações privilegiadas e alterações de função do servidor. Seu Oracle Database monitoring software monitora logons bem-sucedidos e falhados e monitora instruções SQL e privilégios. Para qualquer fonte, você pode configurar alertas para enviar e-mail a um analista ou executar um script que você definir como uma ação de resposta.
Os relatórios do Auditor também servem como evidência de conformidade. First National Bank and Trust of Beloit usa Netwrix Auditor como sua principal solução para conformidade com OCC e agora gasta uma hora, em vez de uma semana, para se preparar para auditorias. Bank of the South o utiliza para proteger dados críticos para os negócios e cumprir PCI DSS e GLBA, economizando pelo menos 40 horas por ano na preparação para auditorias.
Capturando valores antes e depois das alterações de dados
Netwrix Auditor for SQL Server funciona por padrão no modo sem gatilhos, lendo o log de rastreamento a cada cinco minutos sem carga adicional e informando quem mudou o quê e quando. O modo baseado em gatilhos adiciona valores antes e depois para INSERT, UPDATE e DELETE, que a auditoria nativa não pode fornecer, ao custo de carga adicional em servidores com alto volume de transações.
Conectando atividade a dados sensíveis
Netwrix Auditor aplica contexto de dados sensíveis ao nível da tabela em modo sem gatilho, usando as tabelas e políticas que você configurou, para que os relatórios possam sinalizar atividades contra tabelas reguladas. Para descoberta e análise de permissões mais profundas no SQL Server e Oracle, Netwrix Access Analyzer mapeia permissões efetivas e revela dados superexpostos, além do que o Auditor cobre sozinho.
Implantação com impacto mínimo na produção
Netwrix Auditor coleta remotamente, então somente o modo baseado em gatilho acessa as tabelas monitoradas. A coleta Oracle é feita via Oracle Instant Client no servidor Auditor a cada dez minutos, e a leitura de rastreamento do SQL Server ocorre a cada cinco minutos. Complementos encaminham registros de atividade para Splunk, IBM QRadar e ArcSight para equipes que já centralizam em um SIEM.
Coloque o monitoramento da atividade do banco de dados em prática
Comece com a instância que contém seus dados mais regulados, estabeleça uma linha de base e expanda somente após o primeiro conjunto de alertas gerar resultados acionáveis.
Para cargas de trabalho gerenciadas na nuvem, a cobertura depende da fonte de dados e do modelo de implantação. Netwrix Access Analyzer descobre dados sensíveis e analisa permissões em SQL Server, Azure SQL, Amazon RDS para SQL Server e Oracle.
Solicite uma demonstração para ver como Netwrix pode ajudar a monitorar a atividade do banco de dados, centralizar o registro de auditoria e detectar usos indevidos antes que se tornem uma violação.
Perguntas frequentes sobre monitoramento de atividade de banco de dados
Compartilhar em
Saiba Mais
Sobre o autor
