Auditoria é o monitoramento e registro das ações selecionadas do banco de dados do usuário. Geralmente é usado para investigar atividades suspeitas ou monitorar e coletar dados sobre atividades específicas do banco de dados. Por exemplo, o administrador do banco de dados pode reunir estatísticas sobre quais tabelas estão sendo atualizadas, quantas operações são executadas ou quantos usuários simultâneos se conectam em momentos específicos.
Nesta postagem de blog, abordaremos os aspectos fundamentais da auditoria de nossos sistemas de banco de dados de código aberto, especialmente MySQL, MariaDB, PostgreSQL e MongoDB. Este artigo é direcionado a engenheiros de DevOps que geralmente têm menos experiência ou exposição em práticas recomendadas de conformidade de auditoria e boa governança de dados ao gerenciar a infraestrutura principalmente para os sistemas de banco de dados.
Auditoria de extrato
Auditoria de instruções MySQL
O MySQL tem o log geral de consulta (ou general_log), que basicamente registra o que o mysqld está fazendo. O servidor grava informações nesse log quando os clientes se conectam ou desconectam e registra cada instrução SQL recebida dos clientes. O log de consulta geral pode ser muito útil na solução de problemas, mas não é realmente criado para auditoria contínua. Ele tem um grande impacto no desempenho e deve ser ativado apenas em intervalos de tempo curtos. Existem outras opções para usar tabelas performance_schema.events_statements* ou Plugin de Auditoria.
Auditoria de instruções PostgreSQL
Para PostgreSQL, você pode habilitar o log_statment para "all". Os valores suportados para este parâmetro são none (off), ddl, mod e all (todas as instruções). Para "ddl", ele registra todas as instruções de definição de dados, como instruções CREATE, ALTER e DROP. Para "mod", ele registra todas as instruções DDL, além de instruções de modificação de dados, como INSERT, UPDATE, DELETE, TRUNCATE e COPY FROM.
Você provavelmente precisará configurar os parâmetros relacionados como log_directory, log_filename, logging_collector e log_rotation_age, conforme mostrado no exemplo a seguir:
log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_statement = 'all'
logging_collector = on
log_rotation_age = 10080 # 1 week in minutes As alterações acima requerem uma reinicialização do PostgreSQL, portanto, planeje cuidadosamente antes de aplicar ao seu ambiente de produção. Você pode então encontrar os logs atuais no diretório pg_log. Para o PostgreSQL 12, o local está em /var/lib/pgsql/12/data/pg_log/ . Observe que os arquivos de log tendem a crescer muito ao longo do tempo e podem consumir o espaço em disco significativamente. Você também pode usar log_rotation_size se tiver espaço de armazenamento limitado.
Auditoria de declaração do MongoDB
Para o MongoDB, existem 3 níveis de registro que podem nos ajudar a auditar as declarações (operações ou operações no termo MongoDB):
-
Nível 0 - Este é o nível de criador de perfil padrão onde o criador de perfil não coleta nenhum dado. O mongod sempre grava operações maiores que o limite slowOpThresholdMs em seu log.
-
Nível 1 - Coleta dados de perfil apenas para operações lentas. Por padrão, as operações lentas são aquelas mais lentas que 100 milissegundos. Você pode modificar o limite para operações “lentas” com a opção de tempo de execução slowOpThresholdMs ou o comando setParameter.
-
Nível 2 - Coleta dados de criação de perfil para todas as operações do banco de dados.
Para registrar todas as operações, defina db.setProfilingLevel(2, 1000), onde deve-se perfilar todas as operações com operações que demoram mais que os milissegundos definidos, neste caso, é 1 segundo (1000 ms) . A consulta a ser procurada na coleção de perfis do sistema para todas as consultas que levaram mais de um segundo, ordenadas por registro de data e hora decrescente, será. Para ler as operações, podemos usar a seguinte consulta:
mongodb> db.system.profile.find( { millis : { $gt:1000 } } ).sort( { ts : -1 } )Além disso, existe o projeto Mongotail, que simplifica o processo de criação de perfil da operação com uma ferramenta externa em vez de consultar diretamente a coleção de perfis.
Lembre-se de que não é recomendável executar auditoria de instrução completa nos servidores de banco de dados de produção, pois isso geralmente causa um impacto significativo no serviço de banco de dados com um enorme volume de log. A maneira recomendada é usar um plug-in de auditoria de banco de dados (como mostrado mais abaixo), que fornece uma maneira padrão de produzir logs de auditoria geralmente necessários para cumprir as certificações governamentais, financeiras ou ISO.
Auditoria de privilégios para MySQL, MariaDB e PostgreSQL
A auditoria de privilégios audita os privilégios e o controle de acesso aos objetos do banco de dados. O controle de acesso garante que os usuários que acessam o banco de dados sejam identificados positivamente e possam acessar, atualizar ou excluir os dados aos quais têm direito. Essa área geralmente é negligenciada pelo engenheiro de DevOps, o que torna o excesso de privilégios um erro comum ao criar e conceder um usuário de banco de dados.
Exemplos de privilégios excessivos são:
-
Os hosts de acesso do usuário são permitidos em um intervalo muito amplo, por exemplo, concedendo host ao usuário [email protected]' %', em vez de um endereço IP individual.
-
Privilégios administrativos sendo atribuídos a usuários de banco de dados não administrativos, por exemplo, um usuário de banco de dados para aplicativo está sendo atribuído com privilégio SUPER ou RELOAD.
-
Falta de controle de recursos contra qualquer tipo de uso excessivo, como Max User Connections, Max Queries Per Hour ou Max Conexões por hora.
-
Permitir que usuários de banco de dados específicos acessem outros esquemas também.
Para MySQL, MariaDB e PostgreSQL, você pode realizar auditoria de privilégios por meio do Esquema de Informações consultando as tabelas relacionadas à concessão, função e privilégios. Para MongoDB, use a seguinte consulta (requer a ação viewUser para outros bancos de dados):
mongodb> db.getUsers( { usersInfo: { forAllDBs: true } } )ClusterControl fornece um bom resumo dos privilégios atribuídos a um usuário de banco de dados. Vá para Gerenciar -> Esquemas e usuários -> Usuários e você obterá um relatório dos privilégios dos usuários, juntamente com as opções avançadas como Requer SSL, Máximo de conexões por hora e assim por diante.
ClusterControl suporta auditoria de privilégios para MySQL, MariaDB e PostgreSQL sob o mesmo usuário interface.
Auditoria de objetos de esquema
Os objetos de esquema são estruturas lógicas criadas pelos usuários. Exemplos de objetos de esquema são tabelas, índices, visualizações, rotinas, eventos, procedimentos, funções, gatilhos e outros. Basicamente, são objetos que contêm dados ou podem consistir apenas em uma definição. Comumente, alguém auditaria as permissões associadas aos objetos de esquema para detectar configurações de segurança ruins e entender a relação e as dependências entre os objetos.
Para MySQL e MariaDB, existem information_schema e performance_schema que podemos usar basicamente para auditar os objetos de esquema. Performance_schema é um pouco profundo na instrumentação como o próprio nome sugere. No entanto, o MySQL também inclui um esquema sys desde a versão 5.7.7, que é uma versão amigável de performance_schema. Todos esses bancos de dados são diretamente acessíveis e consultáveis pelos clientes.
Plugins/extensões de auditoria de banco de dados
A maneira mais recomendada de realizar auditoria de instrução é usando um plug-in ou extensão de auditoria, criado especificamente para a tecnologia de banco de dados em uso. MariaDB e Percona têm sua própria implementação de plug-in de auditoria, que é um pouco diferente do plug-in de auditoria do MySQL disponível no MySQL Enterprise. Os registros de auditoria incluem informações sobre a operação que foi auditada, o usuário que está executando a operação e a data e hora da operação. Os registros podem ser armazenados em uma tabela de dicionário de dados, chamada trilha de auditoria do banco de dados, ou em arquivos do sistema operacional, chamada trilha de auditoria do sistema operacional.
Para o PostgreSQL, existe o pgAudit, uma extensão do PostgreSQL que fornece registro detalhado de auditoria de sessão e/ou objeto por meio do recurso de registro padrão do PostgreSQL. É basicamente uma versão aprimorada do recurso log_statement do PostgreSQL com a capacidade de pesquisar e pesquisar facilmente os dados capturados para auditoria seguindo o log de auditoria padrão.
MongoDB Enterprise (pago) e Percona Server for MongoDB (gratuito) incluem um recurso de auditoria para instâncias mongod e mongos. Com a auditoria habilitada, o servidor irá gerar mensagens de auditoria que podem ser registradas no syslog, console ou arquivo (formato JSON ou BSON). Na maioria dos casos, é preferível registrar no arquivo no formato BSON, onde o impacto no desempenho é menor que o JSON. Esse arquivo contém informações sobre diferentes eventos do usuário, incluindo autenticação, falhas de autorização e assim por diante. Confira a documentação de auditoria para obter detalhes.
Trilhas de auditoria do sistema operacional
Também é importante configurar as trilhas de auditoria do sistema operacional. Para Linux, as pessoas normalmente usariam auditd. Auditd é o componente de espaço do usuário do Linux Auditing System e responsável por gravar registros de auditoria no disco. A visualização dos logs é feita com os utilitários ausearch ou aureport. A configuração das regras de auditoria é feita com o utilitário auditctl ou modificando os arquivos de regras diretamente.
As seguintes etapas de instalação são nossa prática comum ao configurar qualquer tipo de servidor para uso em produção:
$ yum -y install audit # apt install auditd python
$ mv /etc/audit/rules.d/audit.rules /etc/audit/rules.d/audit.rules.ori
$ cd /etc/audit/rules.d/
$ wget https://gist.githubusercontent.com/ashraf-s9s/fb1b674e15a5a5b41504faf76a08b4ae/raw/2764bf0e9bf25418bb86e33c13fb80356999d220/audit.rules
$ chmod 640 audit.rules
$ systemctl daemon-reload
$ systemctl start auditd
$ systemctl enable auditd
$ service auditd restartObserve que a reinicialização auditd do serviço de última linha é obrigatória porque a auditoria não funciona muito bem ao carregar regras com systemd. No entanto, o systemd ainda é necessário para monitorar o serviço auditd. Durante a inicialização, as regras em /etc/audit/audit.rules são lidas por auditctl. O próprio daemon de auditoria tem algumas opções de configuração que o administrador pode querer personalizar. Eles são encontrados no arquivo auditd.conf.
A linha a seguir é uma saída obtida de um log de auditoria configurado:
$ ausearch -m EXECVE | grep -i 'password' | head -1
type=EXECVE msg=audit(1615377099.934:11838148): argc=7 a0="mysql" a1="-NAB" a2="--user=appdb1" a3="--password=S3cr3tPassw0rdKP" a4="-h127.0.0.1" a5="-P3306" a6=2D6553484F5720474C4F42414C205641524941424C4553205748455245205641524941424C455F4E414D4520494E20282776657273696F6E272C202776657273696F6E5F636F6D6D656E74272C2027646174616469722729Como você pode ver acima, é fácil identificar uma senha de texto simples para MySQL ("--password=S3cr3tPassw0rdKP") usando o utilitário ausearch capturado pelo auditd. Esse tipo de descoberta e auditoria é vital para proteger nossa infraestrutura de banco de dados, onde uma senha de texto simples é inaceitável em um ambiente seguro.
Considerações finais
O log ou trilha de auditoria é um aspecto vital que geralmente é negligenciado pelos engenheiros de DevOps ao gerenciar infraestruturas e sistemas, sem falar no sistema de banco de dados, que é um sistema muito crítico para armazenar dados confidenciais e confidenciais. Qualquer exposição ou violação de seus dados privados pode ser extremamente prejudicial para os negócios e ninguém gostaria que isso acontecesse na atual era da tecnologia da informação.
