Com o uso do Docker#

Esta seção é destinada ao administrador da distribuição Docker do Sherpa Orchestrator. Os comandos exigem acesso ao servidor e ao Docker Compose. Os arquivos de cliente e as imagens devem ter a mesma versão. É necessário verificar se a distribuição instalada contém o parâmetro ou script necessário.

Diagnóstico após instalação e atualização#

O instalador e o script de atualização oferecem a execução do diagnóstico. Para repetir a verificação, utiliza-se este comando no diretório de instalação:

cd /opt/SherpaOrchestrator
sudo bash sh_scripts/diagnostics.sh

São verificados os contêineres, componentes selecionados, versões, espaço livre, conexão com o banco de dados, migrações, Vault, SIEM, nginx, Armazenamento, interface web e logs. As correções oferecidas pelo script exigem confirmação separada. Antes de confirmar, é necessário ler a descrição da ação.

Um resultado sem observações indica que as verificações implementadas foram concluídas com sucesso. Isso não substitui o teste de um cenário de usuário ou da entrega ao SIEM. Em caso de erro, é necessário registrar o nome da verificação e a mensagem, corrigir a causa e repetir o diagnóstico. A verificação de migrações desta distribuição não comprova a conformidade de todos os objetos do esquema do banco de dados.

Retenção de métricas do sistema#

O parâmetro STORE_SYSTEM_METRICS_DAYS em .env define o número de dias de retenção das métricas do sistema. O padrão é 30. O valor 0 desativa a limpeza automática dessas métricas. Deve ser usado um número inteiro não negativo.

O agendador exclui registros antigos. Reduzir o prazo pode excluir um histórico que não será recuperado ao aumentar o valor posteriormente. Esse parâmetro não define a retenção de Trabalhos, auditoria ou mensagens de Robôs.

Exemplo: para manter os últimos 14 dias de métricas do sistema, defina em .env:

STORE_SYSTEM_METRICS_DAYS=14

Para aplicar o prazo, recrie somente o contêiner backend na janela de manutenção acordada:

cd /opt/SherpaOrchestrator
sudo docker compose up -d --no-deps --force-recreate orchestrator

Requisitos de senhas#

Estes parâmetros de .env se aplicam a novas senhas de Usuários e Contas ao criar um registro ou alterar a senha:

O comprimento é verificado em bytes e pode ser diferente do número de caracteres para texto não ASCII. Os comprimentos mínimo e máximo devem ser inteiros positivos. Se o máximo for menor que o mínimo, será utilizado o mínimo. Valores de comprimento e expressões regulares inválidos são substituídos pelos padrões. A expressão regular deve ser informada sem delimitadores.

Alterar a política não modifica as senhas armazenadas. Se uma nova senha for rejeitada, é necessário verificar seu comprimento e formato. Para aplicar alterações nas variáveis de ambiente, o contêiner backend deve ser recriado durante uma janela de manutenção acordada:

cd /opt/SherpaOrchestrator
sudo docker compose up -d --no-deps --force-recreate orchestrator

Reiniciar um contêiner não recarrega as variáveis de ambiente de .env.

Backup e migração#

Antes de atualizar ou migrar, é necessário ter um backup verificado. O dump do banco de dados não inclui Armazenamento, configuração ou segredos do Vault. O conteúdo do backup e suas limitações estão descritos em Backup e recuperação.

A migração de uma distribuição local para Docker exige a mesma versão, o mesmo servidor e o mesmo mecanismo de banco de dados. É necessário preservar HOST_IP, a chave de criptografia, os bancos principal e de arquivo, Armazenamento, certificados e a instalação original para reversão. Durante a cópia e a verificação, o aplicativo e os demais processos de escrita devem ser interrompidos.

Antes da migração, é necessário obter com o suporte técnico da Sherpa o procedimento de migração de local para Docker para a versão e o banco de dados utilizados. Alterar servidor, IP, versão ou mecanismo de banco exige um plano separado. Não se deve executar simultaneamente as instalações antiga e nova com o mesmo banco de produção.

A mudança para um novo servidor mantendo o banco de dados pode exigir a restauração do vínculo das licenças. Antes de começar, é necessário obter com o suporte técnico da Sherpa o procedimento para a versão e o banco utilizados: MariaDB ou PostgreSQL. Um administrador executa o procedimento após criar um backup. O acesso temporário a setup.php e os arquivos temporários devem ser removidos imediatamente após a verificação.

Auditoria de banco de dados e SIEM#

A auditoria do banco pode conter consultas SQL e valores sensíveis. Antes de ativá-la, é necessário definir permissões, retenção, rotação e espaço livre. A ativação pode exigir reiniciar o banco durante uma janela de manutenção. Para uma fonte de auditoria MariaDB separada, é necessário obter com o suporte técnico da Sherpa os procedimentos de configuração do plugin e monitoramento para a versão utilizada.

A integração SIEM padrão exige uma distribuição completa com orchestrator-siem-exporter. Em uma instalação nova, o componente é selecionado no instalador. Durante uma atualização, no menu de componentes. Antes de começar, é necessário obter com o suporte técnico da Sherpa o procedimento de instalação ou atualização com SIEM para a versão e o banco utilizados. A seguir são apresentados os requisitos e a verificação, não o procedimento completo de instalação.

O receptor SIEM deve aceitar Syslog por uma conexão protegida TLS, o formato RFC 5424 e a separação de mensagens RFC 6587 octet-counting. Esses requisitos definem o formato e o transporte dos eventos. O backend do Orchestrator estabelece a conexão.

O administrador do SIEM fornece:

• endereço e porta do receptor;
• nome do servidor indicado no certificado;
• certificado de uma autoridade certificadora (CA) confiável para verificar o receptor;
• certificado e chave privada do cliente se for exigida verificação mútua de certificados (mTLS).

O administrador do Orchestrator configura:

• SYSLOG_HOST — endereço fornecido pelo administrador do SIEM;
• SYSLOG_PORT — porta de recebimento de eventos;
• SYSLOG_TLS_* — configurações de certificados e conexão protegida. Os nomes e valores específicos devem ser conferidos nos arquivos da distribuição instalada;
• credenciais de serviço — para o componente de integração acessar a fonte de auditoria;
• SIEM_DB_FILTER — filtro dos eventos de auditoria do banco enviados ao SIEM.

Um SYSLOG_HOST vazio não habilita o envio. Os dados podem continuar acumulando com a auditoria ativa. O exportador envia os eventos da fonte de auditoria do banco de dados aceitos pelo filtro. Isso não é uma cópia de todas as ações do Usuário na interface. As regras de detecção e os alertas são configurados separadamente no SIEM.

Para verificar a entrega, o administrador do banco de dados executa uma consulta segura com uma conta comum autorizada e o administrador do SIEM procura o marcador nos eventos recebidos:

SELECT 'SHERPA_SIEM_CHECK_001' AS marker;

O filtro deve permitir select. O usuário de serviço da integração é excluído da exportação. Um diagnóstico bem-sucedido sem o recebimento do evento de teste não confirma a entrega. Se o receptor permanecer indisponível, é necessário monitorar a fila, os logs e o espaço livre.