A utilização de Sistemas de Gerenciamento de Informações e Eventos de Segurança (SIEM) é fundamental para fortalecer a postura de segurança cibernética de uma empresa. Adotar melhores práticas nesse contexto é crucial por várias razões.
A configuração adequada do SIEM permite uma detecção mais eficaz de ameaças cibernéticas. A otimização das regras de correlação e a personalização das configurações são passos essenciais para identificar padrões suspeitos e atividades anômalas em tempo real.
Isso possibilita uma resposta proativa a potenciais ataques, mitigando riscos antes que possam causar danos significativos. Sendo assim vamos as melhores práticas na utilização do Eventlog Analyzer da ManageEngine:
Otimizando espaço no disco rígido
O espaço no disco rígido é predominantemente influenciado por dois fatores principais: o banco de dados e os arquivos compactados. O banco de dados, também conhecido como índice, armazena os dados de log mais recentes, que estão prontamente disponíveis para relatórios e pesquisas.
Por outro lado, os arquivos contêm registros históricos mais antigos. Vale ressaltar que os arquivos compactados exigem ser carregados no produto antes de serem acessíveis para pesquisa ou relatórios.
A capacidade do EventLog Analyzer de desempenhar suas funções essenciais pode ser comprometida caso seja hospedado em um ambiente sem os recursos de sistema adequados.
Otimização com Base no Volume de Logs
A quantidade de espaço necessário no disco rígido está intrinsecamente ligada ao volume de logs gerados no ambiente. Em cenários de alto fluxo de logs, é imperativo dispor de uma capacidade de armazenamento mais ampla para processar e armazenar adequadamente esses registros.
Contudo, se a demanda por espaço em disco estiver aumentando de maneira alarmante, é aconselhável verificar se está sendo coletado apenas o necessário. Implementar as seguintes alterações pode reduzir a necessidade de espaço em disco sem comprometer a segurança:
- Desative a auditoria de eventos irrelevantes do Windows.
- Certifique-se de que apenas os syslogs necessários são encaminhados para o servidor.
- Utilize filtros de coleta de log para eliminar ruídos.
Otimização com Base na Retenção
Os arquivos de log e as pastas de índice desempenham um papel crucial no aumento do tamanho dos logs armazenados. O espaço total em disco necessário, a qualquer momento, para armazenar os logs gerados por sua rede é a soma dos tamanhos das pastas de arquivo e índice.
- Dados arquivados: O índice arquivado reduz a velocidade da função de pesquisa, mas ocupa menos espaço em disco.
- Dados indexados: O índice bruto acelera a função de pesquisa, mas ocupa mais espaço em disco.
Os tamanhos dos arquivos e índices para um período específico dependem do volume total de logs brutos gerados durante esse intervalo.
Otimização de CPU e Memória RAM
Unidade de Processamento (CPU): A demanda de energia da CPU está diretamente vinculada ao volume de logs, aos perfis de alerta existentes e às regras de correlação em execução. Caso o uso da CPU esteja fora do padrão, recomenda-se realizar as seguintes ações:
- Configurar políticas para encaminhar apenas os logs essenciais.
- Revisar e garantir que apenas os perfis de alerta e regras de correlação indispensáveis estejam ativos.
Memória RAM: O processo de correlação consome considerável quantidade de RAM, portanto, é crucial assegurar que somente as regras de correlação necessárias estejam em uso.
Gerenciamento do Tamanho do Banco de Dados
Os registros de log são armazenados no banco de dados, passando por processos periódicos de compactação e arquivamento em arquivos compactados. Quanto mais longo for o período de retenção no banco de dados, maior será a demanda por espaço no disco rígido, o que pode resultar em um desempenho inferior do banco de dados.
O período de retenção padrão é definido em 32 dias, sendo possível ajustá-lo em Configurações > Administração > Configurações de Retenção do Banco de Dados. Recomenda-se minimizar esse valor para alcançar um desempenho ótimo.
Gestão do Tamanho do Arquivo
Os arquivos compactados são mantidos por um período específico antes de serem permanentemente excluídos. Dado que há a possibilidade de serem armazenados indefinidamente, a pasta de arquivos pode crescer continuamente.
O período de retenção dos arquivos é configurável para “sempre” e pode ser ajustado em Configurações > Exibir Arquivos Compactados > Configurações de Administração > Visualizar Arquivos Compactados.
O tamanho da pasta de arquivos também pode ser gerenciado de forma eficaz ao designar uma unidade dedicada separada como local de armazenamento ou transferir manualmente o conteúdo para uma unidade de fita ou dispositivo de armazenamento de alta capacidade em intervalos periódicos.
Mantenha o EventLog Analyzer seguro
Configuração de Instalação
A conta de usuário do sistema operacional utilizada para a instalação e execução do produto deve ser a mesma, possuindo permissões em todas as pastas e subpastas instaladas.
Embora não seja obrigatório utilizar a conta root em um sistema Linux, em um sistema Windows, apenas a conta de administrador padrão deve ser empregada para essas finalidades.
Configuração de Usuário
Recomenda-se modificar as senhas padrão das contas de usuário administrador e convidado no Cliente Web EventLog Analyzer, acessando Configurações > Configurações de Administrador > Gerenciar Técnico.
Certificação SSL
Para garantir a segurança na comunicação entre servidor e cliente no EventLog Analyzer, é possível utilizar o SSL (Secure Sockets Layer). O guia de certificação SSL proporciona passos detalhados sobre como adquirir a certificação SSL.
Melhores práticas para o Database
Banco de Dados Seguro
Visando uma instalação tranquila e eficiente, o EventLog Analyzer utiliza o usuário root/postgres padrão do MySQL ou PostgreSQL, sem senha.
No entanto, é recomendável atribuir uma senha a essa conta para reforçar a segurança do banco de dados. No caso do MS SQL, ao contrário, é essencial fornecer uma conta de usuário válida com as credenciais adequadas durante o próprio processo de instalação.
Otimize o Desempenho do Banco de Dados PostgreSQL
Para otimizar o desempenho do banco de dados PostgreSQL:
- Pare o EventLog Analyzer.
- Navegue até o diretório <caminho_do_EventLog_Analyzer>/pgsql/data/.
- Abra o arquivo postgres_ext.txt.
- Substitua os valores existentes dos parâmetros pelos valores mencionados abaixo.
- Salve e reinicie o EventLog Analyzer.
Otimize o Desempenho do Banco de Dados MySQL
Para aprimorar o desempenho do banco de dados MySQL, siga os passos abaixo:
- Interrompa o EventLog Analyzer.
- Acesse o diretório <caminho_do_EventLog_Analyzer>/bin.
- Abra o arquivo startDB.bat (ou startDB.sh, no caso de uma máquina Linux).
- Substitua o valor atual do parâmetro “–innodb_buffer_pool_size” por um valor apropriado, considerando o tamanho da RAM da máquina, conforme indicado na tabela abaixo. Por exemplo, se a RAM tiver um tamanho de 8 GB, o parâmetro deverá ser “–innodb_buffer_pool_size=3000M”.
- Salve as alterações e reinicie o EventLog Analyzer.
Backup do Banco de Dados
É altamente recomendável realizar backups quinzenais do banco de dados do EventLog Analyzer, proporcionando uma camada adicional de segurança contra perda de dados em caso de eventualidades.
Os arquivos do banco de dados estão localizados nas pastas <caminho_do_EventLog_Analyzer>/mysql ou <caminho_do_EventLog_Analyzer>/pgsql, dependendo da versão específica. Para realizar o backup, interrompa o serviço EventLog Analyzer e crie uma cópia de todos os arquivos e pastas no local.
Essa operação pode ser realizada manualmente ou por meio de software de backup de terceiros. As instruções para realizar o backup de dados do banco de dados MS SQL podem ser encontradas neste link. Além disso, é aconselhável manter uma cópia de backup dos arquivos compactados, localizados em <caminho_do_EventLog_Analisador>/arquivo.
Ao restaurar dados de um backup, assegure-se de que o número de compilação do produto seja o mesmo da época em que o backup foi criado.
Desempenho da pesquisa de log
Para garantir um desempenho equitativo, é aconselhável manter a relação entre heap e dados em 1.60. Isso implica a alocação de aproximadamente 1 GB de memória (heap) para cada 60 GB de dados no nó Elasticsearch (a relação máxima).
No entanto, para obter um desempenho otimizado, é possível reduzir essa proporção, como exemplificado por 1.30, o que resulta em um aumento de velocidade.
Nota: No Build 12320 mais antigo, a proporção recomendada de heap para dados é 1.30.
O Elasticsearch utiliza também o cache do sistema de arquivos para agilizar as pesquisas. Recomenda-se garantir espaço livre na RAM equivalente à memória heap alocada para o Elasticsearch.
Caso não seja possível, é importante assegurar que pelo menos 30% da RAM do servidor permaneça livre. Essa RAM livre é utilizada pelo sistema operacional para armazenar em cache os índices do Elasticsearch, melhorando o desempenho.
Observação: A alocação de heap para o Elasticsearch não deve ultrapassar 32 GB.
Exemplo:
Calcule o tamanho total dos dados armazenados no Elasticsearch Vamos supor que possuímos 100 GB de dados de pesquisa, então o tamanho do heap para o Elasticsearch deve ser no mínimo → 100/30 ~ 4GB A insuficiência de heap é a causa subjacente de vários problemas de desempenho, tais como:
Processamento lento de logs/desempenho de indexação Problemas no armazenamento em cache Atrasos nos resultados de pesquisa Falhas nas consultas O Elasticsearch pode ser executado em uma instância comum compartilhada (<ManageEngine>/elasticsearch/ES) ou local (<EventlogAnalyzer>/ES)
Determinar a Localização do Elasticsearch (diretório ES):
Para verificar a localização do Elasticsearch, siga estas etapas:
Quando o EventLog Analyzer é instalado como um aplicativo independente (ou seja, executado sem o Log360), o Elasticsearch local estará em uso, localizado no diretório <EventlogAnalyzer>\ES. Se o EventLog Analyzer tiver sido instalado junto com o Log360, a configuração padrão do Elasticsearch (ES comum) estará em uso, localizado no diretório <ManageEngine>\elasticsearch\ES.
Etapas para Verificar o Tamanho dos Dados do Elasticsearch:
- Navegue até o <diretório ES>\config.
- Abra o arquivo elasticsearch.yml na pasta de configuração.
- Procure a configuração path.data neste arquivo.
- Navegue até a pasta de dados especificada na configuração path.data e verifique o tamanho da pasta.
Para garantir o desempenho ideal, monitore e mantenha seus dados do Elasticsearch regularmente, limitando o tamanho do nó ES único entre 1,5 TB e 1,9 TB. Observação: em compilações mais antigas, como no Build 12320, o ES pode armazenar de 800 GB a 1,2 TB de dados.
Etapas para Ajustar o Heap (Memória):
- Navegue até o diretório ES, dependendo se é uma compilação independente ou um pacote de construção (com Log360).
- Vá até /ES/config.
- Abra o arquivo de configuração → es-additional-wrapper.conf e verifique o tamanho do heap.
Nota: Certifique-se de que o usuário conectado tenha permissões de escrita.
- O tamanho do heap é expresso em megabytes (MB). a. As configurações wrapper.java.initmemory e wrapper.java.maxmemory devem ser configuradas com o mesmo valor.
Neste exemplo, estão definidas como 1024, o que significa que a memória do Elasticsearch está configurada como (1024 MB/1024) = 1 GB. b. Se for necessário aumentar para 25 GB, ambos os valores precisam ser definidos como 25 * 1024 = 25600.
Aumento do Tamanho do Heap no Elasticsearch:
- Abra o arquivo de configuração es-additional-wrapper.conf.
- Modifique os valores wrapper.java.initmemory e wrapper.java.maxmemory para aumentar o tamanho do heap.
- Assegure-se de que ambos os valores de wrapper.java.initmemory e wrapper.java.maxmemory sejam idênticos. Caso contrário, o produto não iniciará corretamente.
- Se o produto estiver em execução, encerre o Elasticsearch acessando ES/bin e execute stopES.bat utilizando o prompt de comando do administrador ou simplesmente reinicie o EventLog Analyzer. Isso reiniciará o Elasticsearch com a nova pilha.
- Se o heap em <ManageEngine>\elasticsearch\ES foi atualizado, será necessário executar manualmente o comando stopES.bat em <ManageEngine>\elasticsearch\ES\bin antes de reiniciar o Analisador de Log de Eventos.
- No caso de erros OutOfMemory e LowMemory, o heap do Elasticsearch será automaticamente expandida até um terço da RAM disponível na máquina.
- É importante observar que aumentar o tamanho do heap nem sempre é a solução para melhorar o desempenho.
- Além do heap, outros fatores como disco e CPU também podem causar problemas de desempenho. Garantir que os Requisitos do Sistema sejam atendidos.
- Também é importante monitorar o uso de memória regularmente para garantir que o sistema esteja funcionando eficientemente e ajustar as configurações, se necessário.
- Lembre-se de que o aumento do tamanho do heap do Elasticsearch deve ser feito com consideração cuidadosa dos recursos disponíveis em sua máquina.
Garanta que o Disco não Seja um Obstáculo:
Prática Recomendada para Melhorar o Desempenho da Pesquisa:
Se o servidor estiver realizando cache de logs (ou seja, o processamento de logs estiver lento) ou se as consultas estiverem demoradas, considere as seguintes ações:
- Utilize armazenamento mais veloz, conforme indicado na página de Requisitos do Sistema.
- Verifique se o disco onde os dados estão armazenados não está fragmentado.
- No Monitor de Recursos do Windows, analise a guia Disco. Se a atividade do disco indicar que o Maior Tempo Ativo é constantemente 100%, isso sugere que o disco pode estar enfrentando problemas ou não ser suficientemente rápido.
Utilização de Nodes para pesquisa adicionais e distribuição de carga de pesquisa/indexação para melhor performance
Aproveite o recurso de Gerenciamento de Mecanismo de Busca no Log360 (Log360 → Admin → SearchEngineManagement) para incorporar nós adicionais do Elasticsearch. Isso possibilita a distribuição da carga de pesquisa e indexação, utilizando máquinas adicionais.
Caso o volume de dados seja demasiadamente extenso para um único node , é recomendável incorporar nodes adicionais para distribuir a carga de pesquisa e indexação.
Se a performance da pesquisa não atender às expectativas, a inclusão de nós adicionais pode ser benéfica. A adição de nós proporciona um processamento de logs mais eficiente e rápido.
Práticas Recomendadas para Otimização de Pesquisa:
Se o servidor estiver acumulando registros em cache (ou seja, se o processamento de logs estiver lento) ou se as pesquisas estiverem demoradas, considere o seguinte:
- Utilize armazenamento mais veloz, conforme especificado na página de Requisitos do Sistema.
- Certifique-se de que o disco onde os dados estão armazenados não esteja fragmentado.
- No Monitor de Recursos do Windows, acesse a guia Disco. Se a atividade do disco indicar que o Maior Tempo Ativo está constantemente em 100%, isso sugere possíveis problemas no disco ou que ele não é suficientemente rápido.
- Se o volume de dados for significativamente grande para um único nó, considere adicionar nós adicionais para distribuir a carga de pesquisa/indexação.
- Se o desempenho da pesquisa não atender às expectativas, a adição de nós adicionais pode ser benéfica.
- A inclusão de nós extras contribui para o processamento mais rápido de logs.
No EventLog Analyzer, o período de retenção padrão é de 32 dias (podendo ser ampliado em Configurações → Configurações de Banco de Dados na IU). Se estendido para 90 dias, 32 dias de dados são mantidos como dados ativos, acessíveis de maneira rápida. Dados além desse período são armazenados como dados frios, exigindo desarquivamento e carregamento no mecanismo de pesquisa. Como resultado, pesquisas além dos dados ativos demandarão mais tempo do que o habitual.
Ao realizar pesquisas de dados, tanto o heap (memória atribuída ao Elasticsearch) quanto o off-heap (RAM livre no sistema) são utilizados. A RAM livre no sistema facilita a leitura mais rápida dos índices pelo Elasticsearch. Portanto, é aconselhável manter, no mínimo, a mesma quantidade de RAM livre no servidor equivalente ao heap fornecido ao Elasticsearch para otimizar o desempenho. Caso isso não seja viável, assegure-se de que, no mínimo, 30% da RAM do servidor permaneça livre. Essa RAM livre é utilizada pelo sistema operacional para armazenar em cache os índices do Elasticsearch, proporcionando desempenho aprimorado.
É essencial contar com um disco com velocidade de leitura sequencial e aleatória satisfatória, pois o processo de busca envolve a iteração em vários arquivos, uma operação intensiva de I/O. Recomenda-se a preferência por SSDs, pois reduzem a carga de E/S e os tempos de espera de E/S, contribuindo para aproveitar plenamente a capacidade da CPU.
Conclusão
Em busca de um desempenho otimizado no ambiente do EventLog Analyzer, é crucial seguir as práticas recomendadas para garantir eficiência nos processos de pesquisa e indexação. Ao enfrentar desafios como registros em cache lentos ou consultas demoradas, a adoção de estratégias como o uso de armazenamento mais rápido, a verificação do estado do disco e a consideração de adicionar nós adicionais para distribuir a carga tornam-se imperativas.
Além disso, ao estender o período de retenção de dados, é fundamental estar ciente das implicações na velocidade das pesquisas, reconhecendo a diferença entre dados ativos e dados frios. A alocação adequada de recursos, como heap e off-heap, é essencial para otimizar o desempenho, enquanto a escolha de discos com boa velocidade de leitura, preferencialmente SSDs, é crucial para operações de busca eficientes.
A implementação cuidadosa dessas práticas recomendadas no gerenciamento do Elasticsearch e do banco de dados contribuirá significativamente para um ambiente de EventLog Analyzer mais eficaz, proporcionando respostas rápidas, processamento eficiente de logs e uma experiência global aprimorada para os usuários.
ACSoftware Parceira da ManageEngine no Brasil. – Fone / WhatsApp (11) 4063 9639.
PodCafé da TI – Podcast, Tecnologia e Cafeína.
