Olá, Habr!
Meu nome é Alexey Shmelev, e lidero o grupo de análise e segurança de dados na "Garda". Somos especializados na configuração de "regras decisivas" em produtos da "Garda", como DBF e DLP. Nossa missão é ajustar políticas para atender aos requisitos dos clientes e às regulamentações de proteção de informações. O resultado do nosso trabalho é uma solução que detecta eventos de segurança de forma mais eficaz em uma infraestrutura ou sistema de informação específico.
Primeiramente, é importante notar que vazamentos de dados em clientes ocorrem com menos frequência durante a operação do DBF do que se poderia imaginar. Frequentemente, vazamentos são o resultado de configurações incorretas ou processos legados. Assim, entre os eventos "interessantes" registrados pela solução, estão a extração de dados de tabelas sensíveis, a violação do princípio do menor privilégio e a ordem de acesso aos dados armazenados no banco de dados. Tudo isso é consequência do não cumprimento das políticas corporativas de segurança da informação. Cada uma dessas ações isoladamente pode ser facilmente explicada por uma tarefa urgente, um legado histórico ou um "remendo temporário que se tornou permanente". No entanto, quando várias dessas anomalias ocorrem, ou a mesma anomalia começa a aparecer com mais frequência, um padrão consistente se forma, dificultando investigações e diluindo responsabilidades. Nesse ruído, é fácil perder um incidente real.
Abaixo estão dez padrões que encontramos em projetos com mais frequência. Eu os organizei em ordem decrescente de frequência, do que vemos em quase todas as implementações até casos raros, mas não menos interessantes. Para cada caso, analisarei como a anomalia se manifesta, por que ocorre, quais riscos o cliente enfrenta e como transformar a situação de uma "zona de ruído cinza" para um processo gerenciável.
1. Trabalho de Administradores sob Contas Técnicas
- Frequência: 🟣🟣🟣🟣⚪ (muito alta)
- Perigo: 🟣🟣🟣⚪⚪ (médio)
O servidor de aplicação acessa o banco de dados através de contas técnicas (CTs). Para implementar processos de negócios no sistema de informação, as CTs possuem um conjunto amplo de privilégios em relação aos dados armazenados no banco de dados: seleção, modificação e exclusão. De acordo com os requisitos de segurança, como o PCI DSS, o uso interativo de contas de aplicação de CTs é proibido. Elas só podem ser usadas em casos excepcionais: com necessidade de produção, com justificativa e comprovação documental da gerência. Na prática, no entanto, os administradores frequentemente trabalham através delas. Sob uma única conta, são executadas tanto as requisições da aplicação quanto as operações manuais de SQL.
Encontramos isso em mais da metade dos clientes. No subsistema de auditoria embutido no SGBD, o trabalho sob CTs aparece como ações de um único sujeito. Na realidade, são diferentes tipos de atividade e, o mais importante, diferentes pessoas executando operações sob a mesma conta. Como resultado, é impossível determinar quem realizou a ação e separar a atividade da aplicação da atividade de usuários privilegiados que utilizam as CTs.
Como o DBF vê: O DBF constrói um perfil comportamental da conta: tipo de requisições, frequência, IP e parâmetros de conexão. O complexo detecta desvios se o login no banco de dados não for feito a partir dos IPs dos servidores de aplicação e, ao mesmo tempo, forem utilizados, por exemplo, editores SQL ou clientes de terminal do SGBD. O uso interativo de CTs difere da atividade da aplicação pela estrutura e propriedades das requisições SQL, bem como pelos parâmetros da sessão com o servidor de banco de dados.
Perigos: Não é possível determinar quem executou a ação, pois todas as operações são realizadas sob a mesma conta.
O que fazer: Separar as contas. A aplicação trabalha através de CTs, os administradores – através de contas pessoais. Proibir o uso interativo de CTs. Configurar no DBF o controle do uso de CTs e registrar desvios nos parâmetros da sessão com o banco de dados.
2. Contas Padrão em Produção
- Frequência: 🟣🟣🟣🟣⚪ (alta)
- Perigo: 🟣🟣🟣🟣🟣 (crítico)
Todos os SGBDs possuem contas padrão: postgres no PostgreSQL, sys e system no Oracle, sa no MSSQL, root no MySQL. Formalmente, de acordo com PCI DSS e GOST R 57580, seu uso deve ser minimizado, ou seja, apenas por necessidade de produção. Na ausência desta, essas contas devem ser removidas ou bloqueadas. Na prática, essa regra nem sempre é seguida. Frequentemente, essas contas continuam sendo usadas – em alguns lugares são mantidas para o funcionamento dos servidores de aplicação, em outros, scripts de serviço estão vinculados a elas, e às vezes os administradores simplesmente se acostumaram a trabalhar sob elas.
Na prática, as contas padrão vivem há muito tempo como contas privilegiadas completas na infraestrutura de produção. Em um dos clientes, por exemplo, o controle das contas padrão mostrou o uso ativo da conta postgres. E não apenas para manutenção. A partir dela, outras contas em produção eram gerenciadas.
Como o DBF vê: O complexo registra todos os acessos ao banco de dados a partir de contas padrão e constrói perfis de seu uso legítimo. Se, por exemplo, operações de gerenciamento de contas de banco de dados ou extração em massa de dados de tabelas são executadas a partir de sa ou postgres, o complexo registra um desvio.
Perigos: Contas padrão estão entre os primeiros alvos de ataques de cibercriminosos. A comprometimento de tais contas pode levar a sérias consequências negativas, pois frequentemente possuem o conjunto máximo de privilégios.
O que fazer: Entender por que as contas padrão estão sendo usadas. Se não for uma necessidade de produção, é importante primeiro criar contas de serviço separadas com o conjunto mínimo necessário de privilégios. Em seguida, migrar serviços e processos de negócios para trabalhar sob elas. Em caso de necessidade justificada, é importante controlar o uso de contas padrão. No DBF, vale a pena destacar uma regra separada: quaisquer ações sob contas padrão, exceto tarefas programadas, devem ser consideradas um evento crítico e imediatamente enviadas ao SOC.
3. Credenciais Compartilhadas entre Vários Administradores
- Frequência: 🟣🟣🟣⚪⚪ (médio)
- Perigo: 🟣🟣🟣🟣⚪ (alto)
Idealmente, os administradores para a manutenção de servidores de banco de dados devem usar contas pessoais. Mas isso é apenas no ideal. O caso em que um servidor era administrado por um funcionário, que depois se demitiu, o sistema escalou, o número de administradores aumentou, mas a conta permaneceu compartilhada – está longe de ser um caso isolado.
Como o DBF vê: Ao construir o perfil de uma conta, o DBF registra o número de IPs únicos e contas do sistema operacional a partir das quais a conexão é feita sob um único login. Se o perfil de uma conta tiver vários IPs e logins de SO, é um marcador de alerta.
O modelo comportamental registra não apenas as requisições em si, mas também a forma como o usuário se conecta ao banco de dados – de onde e através de quais ferramentas ele se conectou. Por exemplo, pode ser um editor SQL ou a linha de comando (CLI).
Alerta no "Garda DBF" ao usar uma conta não personificada
Perigos: É mais difícil para os profissionais de segurança investigar incidentes. Além disso, contas não personificadas são usadas por administradores para ocultar suas ações ilegítimas.
O que fazer: Implementar acesso personalizado. Para tarefas temporárias, usar mecanismos de acesso JIT com auditoria obrigatória de sessões. Registrar fatos de conexão sob uma única conta de diferentes IPs, bem como de diferentes contas de SO.
4. Modificações Manuais de Dados em Produção
- Frequência: 🟣🟣🟣⚪⚪ (médio)
- Perigo: 🟣🟣🟣⚪⚪ (médio)
Operações INSERT e UPDATE são uma parte normal da vida de qualquer SGBD. Em produção, elas ocorrem milhares de vezes por dia e, por si só, não causam problemas. Normalmente, essas modificações passam pelo servidor de aplicação e pela lógica de negócios. Ela dita as regras do jogo: quais dados podem ser alterados e sob quais condições. Mas se as mesmas modificações começarem a ser feitas diretamente através de um editor SQL, e ainda em horários atípicos, isso já é um motivo para desconfiar. Por exemplo, em um dos casos, um funcionário do departamento técnico com direitos elevados precisava urgentemente fazer correções em produção. O DBF registrou uma anomalia, pois os dados começaram a ser alterados em intervalos de tempo atípicos para atualizações de aplicação. Formalmente, a pessoa não violou o regulamento, mas o que chamou a atenção do DBF foi a mudança de contexto. Do ponto de vista do sistema, não é apenas o fato da correção que é importante, mas também como ela ocorre.
Como o DBF vê: O sistema analisa requisições SQL e as compara com a fonte de conexão (nome da aplicação e endereço IP). Se comandos UPDATE ou INSERT vierem de uma fonte atípica ou forem executados em um horário incomum, um alerta correspondente é gerado.
Perigos: Modificações diretas no banco de dados contornam a lógica de negócios da aplicação (a camada que valida as operações e registra seu contexto). Por exemplo, um administrador se conecta ao banco de dados através de um cliente SQL e executa manualmente um UPDATE, contornando o backend. A alteração de dados não através da aplicação pode violar a lógica de seu funcionamento e levar à indisponibilidade dos dados.
O que fazer: Excluir completamente tais cenários em produção geralmente é impossível, portanto, é melhor usar vários níveis de controle. Onde permitido, restringir os direitos de operações DML usando um modelo de acesso baseado em funções, e para correções urgentes, introduzir um processo separado com registro de alterações e auditoria posterior. No DBF, vale a pena configurar alertas adicionais para cenários atípicos.
5. Aumento de Privilégios Contornando Políticas de SI
- Frequência: 🟣🟣⚪⚪⚪ (abaixo da média)
- Perigo: 🟣🟣🟣🟣⚪ (alto)
Como conceder direitos aos usuários corretamente? Na visão ideal, estritamente de acordo com os regulamentos de segurança da informação. A violação dessas regras é como uma rachadura na fundação. No início, ela é imperceptível, mas depois leva a um crescimento descontrolado de privilégios e, em última análise, a vazamentos ou falhas. Mas mesmo onde tudo está escrito em preto no branco, há espaço para um "caminho acelerado". Em um dos casos com a ajuda do DBF, descobrimos tal incidente: normalmente, os privilégios eram concedidos através da interface do sistema de informação. Ao mesmo tempo, no banco de dados, era chamada uma procedure na qual eram passados o login, a lista de direitos e os objetos de acesso. Na empresa, tudo é geralmente transparente, controlado, documentado. Mas aqui, nos logs, apareceu uma operação SQL direta GRANT. O que chamou a atenção foi que ela foi executada manualmente e que os privilégios foram atribuídos a um funcionário comum (não de entre os usuários privilegiados). A atribuição direta de privilégios via SQL violava todos os regulamentos internos. Isso se tornou um motivo para investigação.
Como o DBF vê: O DBF registra todas as operações de aumento de privilégios – via GRANT, ao alterar as configurações de uma conta via ALTER ROLE/USER, bem como através de funções e procedures. Um alerta é gerado ao registrar o método de aumento de privilégios que difere do típico para este sistema de informação. Além disso, para o DBF, "atipicidade" não é apenas o tipo de operação SQL, mas também a combinação de sinais contextuais. Por exemplo, quando, como em nosso caso, um administrador executou a operação GRANT de seu notebook pessoal à meia-noite através do terminal psql.
Perigos: Crescimento descontrolado de privilégios e aumento do risco de vazamento de dados.
O que fazer: Operações de aumento de privilégios devem ser realizadas apenas dentro de cenários acordados: quando é necessário alterar algo de forma planejada ou emergencial. Nada de "eu mesmo rapidamente concedo via psql, depois formalizo". Essa abordagem há muito tempo deve ser deixada para trás.
6. Picos de Autenticação Falha (Brute-force)
- Frequência: 🟣🟣⚪⚪⚪ (abaixo da média)
- Perigo: 🟣🟣🟣🟣⚪ (alto)
A atividade de cibercriminosos dentro do perímetro pode incluir várias técnicas de adivinhação de logins e senhas para bancos de dados. Ao mesmo tempo, picos de erros de autenticação nem sempre indicam atividade ilegítima. Falhas e erros de configuração de serviços também podem apresentar um quadro semelhante. No entanto, alguns clientes particularmente vigilantes se preocupam até mesmo com esses picos. Assim, em um dos casos, as suspeitas surgiram por dois motivos. Primeiro, todos os erros foram sob a conta do sistema sa no servidor MSSQL. Segundo, não havia nenhuma atividade observada sob essa conta antes do pico. Tudo indicava ações ilegítimas. Os eventos registrados foram repassados às unidades especializadas para investigação posterior.
Como o DBF vê: O DBF agrega eventos de autenticação falha em um intervalo de tempo selecionado e rastreia fatos de ultrapassagem de limite. O uso de contas de sistema como sa não é para produção. Seu uso é permitido apenas em casos excepcionais, portanto, devem ser desativadas sempre que possível.
Perigos: Como já mencionei, contas de sistema possuem privilégios elevados, portanto, em caso de comprometimento, um invasor pode obter acesso total ao banco de dados com todas as consequências decorrentes. Mesmo que tais eventos sejam gerados não por um invasor, mas por um script esquecido, eles não devem ser ignorados, pois um ataque real pode ser perdido em meio a esse "ruído".
O que fazer: Reagir não aos eventos de autenticação falha em si, mas à ultrapassagem dos limites. A prática mostra que o número de erros de autenticação em sistemas de produção é geralmente bastante grande e nem todos exigem atenção dos serviços de SI. Em metade dos casos, descobre-se que algum serviço simplesmente está tentando acessar o banco de dados com uma senha antiga. Contas de sistema como sa – não são para produção. Seu uso é permitido apenas em casos excepcionais, portanto, devem ser desativadas onde for possível.
7. Acesso Direto a Dados de Clientes VIP no Servidor de Banco de Dados
- Frequência: 🟣🟣⚪⚪⚪ (abaixo da média)
- Perigo: 🟣🟣🟣🟣🟣 (anomalia crítica para o setor financeiro)
Em instituições financeiras, os dados de contas de clientes VIP são monitorados com especial cuidado. E isso é correto. Apenas um pequeno círculo de funcionários tem acesso a eles, e todos os acessos são feitos por eles a partir da aplicação. Se as informações sobre VIPs forem solicitadas diretamente, por exemplo, através de um editor SQL, isso é considerado uma anomalia que requer reação imediata. Honestamente, encontrei tal desvio pela primeira vez. Aconteceu assim: em um dos clientes, o acesso aos dados de clientes "especialmente importantes" foi colocado sob controle. Os resultados do monitoramento não demoraram a aparecer. Literalmente, após algumas semanas, o DBF registrou fatos de acesso a esses dados por usuários privilegiados. Por que isso poderia acontecer em princípio? Neste caso, foi uma violação do princípio do menor privilégio. A propósito, as empresas frequentemente o negligenciam.
Como o DBF vê: O complexo classifica os dados por tipos e níveis de confidencialidade, ou o complexo obtém informações sobre a "marcação" dos dados de um sistema externo. As listas formadas são usadas posteriormente como critério para a política de monitoramento, que rastreia todas as requisições a esses objetos, independentemente de sob qual conta elas são feitas. Em seguida, o complexo registra requisições atípicas: quando o volume de extração excede o limite ou a requisição não vem do endereço IP do servidor de aplicação.
Perigos: Alto risco de vazamento de dados "sensíveis" como resultado de ações ilegítimas de insiders.
O que fazer: Realizar uma auditoria dos privilégios de acesso dos usuários a dados "sensíveis". Colocar todos os acessos a tabelas VIP e PII sob controle do complexo. Dar atenção especial aos acessos a tais tabelas por administradores de banco de dados.
8. SELECT * Desnecessário
- Frequência: 🟣🟣⚪⚪⚪ (abaixo da média)
- Perigo: 🟣🟣🟣⚪⚪ (médio)
A consulta SELECT * por si só não é uma anomalia. No entanto, elas podem causar problemas de desempenho e segurança. Operações típicas para aplicações são a extração de dados com indicação explícita dos campos das tabelas. Portanto, a presença de operações SELECT * em acessos ao banco de dados pode indicar atividade ilegítima. Por exemplo, em uma organização, uma semana após o servidor de banco de dados ser colocado sob controle do complexo, foi possível identificar tais consultas, aplicando um filtro por conteúdo e propriedades das consultas SQL. As respostas às consultas detectadas continham dados pessoais de clientes. É verdade que não houve vazamento como tal, um alarme falso. Acontece que os funcionários simplesmente decidiram coletar estatísticas manualmente. Agiram dentro de suas responsabilidades. Mas o próprio fato de extração completa de dados de tabelas sensíveis sempre requer atenção. Aqui, como dizem, é melhor pecar pelo excesso de cautela.
Como o DBF vê: O DBF analisa o tráfego SQL, identifica consultas do tipo SELECT * e as compara com a lista de tabelas com dados de acesso restrito. Se a extração envolver objetos com rótulos PII/VIP ou tabelas com dados pessoais, o sistema avalia adicionalmente o número de linhas retornadas, a frequência de acessos e o desvio da linha de base. Para serviços regulares, SELECT *, especialmente em tabelas "sensíveis", é considerado um padrão atípico.
Perigos: Potencial exfiltração de dados.
O que fazer: Colocar acessos do tipo SELECT * sob controle. Ao mesmo tempo, atenção especial deve ser dada às consultas executadas sob contas de usuários privilegiados. Em combinação com listas de tabelas com dados de acesso restrito, a política de monitoramento emitirá um alerta pronto.
9. Exportação de Dados do Banco de Dados
- Frequência: 🟣🟣⚪⚪⚪ (abaixo da média)
- Perigo: 🟣🟣🟣⚪⚪ (médio)
Operações de exportação permitem descarregar o conteúdo das tabelas diretamente em um arquivo ou terminal. Por exemplo, no PostgreSQL, o comando COPY TO é responsável por isso. Ele é usado em processos legítimos como backup (pg_dump), coleta de relatórios, migrações. Se o comando for executado fora desses processos, isso pode indicar atividade ilegítima. Em um dos projetos, com a ajuda da análise comportamental, conseguimos identificar tais fatos. Os perfis de comportamento foram construídos apenas no âmbito da atividade de execução de COPY TO. As anomalias registradas em relação à aplicação utilizada e ao login do banco de dados indicavam sinais de exportação ilegítima de dados.
Como o DBF vê: Com a ajuda da análise comportamental, o DBF avalia o contexto e o método de execução das operações de exportação, comparando-os com valores de referência (legítimos). Por exemplo, a execução do comando COPY TO não através de pg_dump indica ou o início de um novo processo de negócios, ou atividade ilegítima de um usuário privilegiado.
Perigos: Exportação de dados do banco de dados é o primeiro passo para a exfiltração. Os dados podem sair do perímetro protegido e levar a um vazamento.
O que fazer: Tentar reduzir as operações de exportação de dados a cenários regulamentados e apenas onde elas são realmente necessárias. Colocar todas as operações de exportação de dados sob o controle do complexo DBF, e também registrar desvios nos parâmetros de execução dessas operações.
10. Atribuição em Massa de Papéis Predefinidos
- Frequência: 🟣⚪⚪⚪⚪ (raro)
- Perigo: 🟣🟣🟣🟣⚪ (alto)
Papéis predefinidos são conjuntos de privilégios pré-instalados no SGBD, destinados à conveniência de gerenciamento de direitos de acesso. Alguns deles contêm um conjunto amplo e potencialmente perigoso de privilégios. Por exemplo, leitura e gravação de quaisquer dados, acesso ao sistema de arquivos e execução de programas no servidor de banco de dados. A atribuição desses papéis a usuários de banco de dados deve ser feita apenas quando houver necessidade justificada. Em um dos clientes, no PostgreSQL, registramos não apenas um caso isolado, mas uma atribuição em massa do papel pg_read_all_data a usuários de uma unidade estrutural. Neste banco de dados, o cliente armazenava dados pessoais, entre outros. E embora o desenvolvimento posterior dos eventos seja desconhecido para mim, tais incidentes quase sempre indicam administração "preguiçosa": "é mais fácil conceder a todos do que investigar".
Como o DBF vê: A análise de conteúdo de requisições ao banco de dados no DBF permite identificar sinais de atribuição de papéis predefinidos. O complexo registra todas as operações de atribuição de privilégios a usuários de banco de dados, atribuindo níveis de criticidade aos eventos e aumentando assim sua prioridade.
Perigos: Violação do princípio do menor privilégio, aumento do risco de vazamento de dados.
O que fazer: Primeiro, observar o princípio do menor privilégio: atribuir aos usuários o conjunto mínimo necessário de direitos de acesso aos dados. Segundo, realizar auditorias regulares dos direitos de acesso dos usuários aos dados no banco de dados. E por último – configurar alertas no DBF para a execução de operações de atribuição de conjuntos "perigosos" de privilégios a usuários de banco de dados.
Por que "tudo funciona" não significa "tudo está bem"?
Nenhum desses eventos por si só, é claro, constitui um grande incidente. E sempre haverá algo para explicar os "desvios" dos regulamentos: houve uma correção urgente em produção ou simplesmente os dados foram extraídos manualmente "para relatório". Sem problemas, o negócio continua funcionando. Mas se olharmos mais de perto, fica claro que a auditoria se transforma em burocracia. É nessa "zona cinza" que é mais fácil esconder um incidente real. Para evitar que isso aconteça, é necessário o DBF. Ele, essencialmente, funciona como um check-up oportuno dos processos de manuseio de dados. Se não for feito a tempo, você pode gastar enormes recursos na eliminação das consequências.
