Porquê armazenar os registos de auditoria fora da aplicação de servidor doméstico que monitorizam?
Os registos de auditoria devem ser armazenados fora da aplicação do servidor doméstico monitorizado, porque um processo comprometido pode frequentemente alterar, eliminar ou interromper as suas próprias provas locais.
Os registos da aplicação podem registar ações de administradores, falhas de início de sessão, acesso a ficheiros, utilização de tokens, execuções de automatizações, chamadas a ferramentas de IA, alterações de permissões e eliminações. Estes registos são mais valiosos depois de a aplicação apresentar falhas ou estar sob o controlo de um atacante — precisamente o momento em que os registos armazenados na respetiva base de dados ou volume com permissões de escrita são menos fiáveis. A recolha externa cria uma fronteira independente de falha e de autoridade. As secções abaixo explicam o encaminhamento remoto, o armazenamento apenas para acrescentar, a correlação, a retenção, a privacidade e os testes necessários para provar que as provas sobrevivem.
Os Registos Locais Partilham a Fronteira de Falha e de Permissões da Aplicação
Normalmente, uma aplicação precisa de permissão para criar e rodar os seus registos locais. Se um atacante obtiver a identidade da aplicação ou a função de administrador da base de dados, essas mesmas permissões podem permitir a eliminação seletiva, a alteração de marcas temporais ou o apagamento completo dos registos.
A OWASP Logging Cheat Sheet exige proteção contra a adulteração de registos durante o transporte e após o armazenamento. Manter a única cópia dentro do processo monitorizado deixa as provas sob a autoridade do componente suspeito.
Os instantâneos do sistema de ficheiros podem recuperar alguns registos locais eliminados, mas podem ser executados com pouca frequência e continuar acessíveis para escrita através da mesma conta de administrador ou de armazenamento comprometida.
O Encaminhamento Remoto Obriga um Atacante a Atravessar Outra Fronteira
Um encaminhador de registos envia eventos para outro serviço ou máquina à medida que ocorrem. Depois de recebidos, a aplicação monitorizada não deve ter permissões de API nem de sistema de ficheiros para reescrever entradas antigas.
O registo centralizado recolhe os registos num repositório separado, onde os eventos de vários sistemas podem ser pesquisados em conjunto. Comprometer a aplicação de origem deixa de conceder automaticamente controlo sobre o histórico de auditoria armazenado.
O destino pode ser outro servidor de baixo consumo, um dispositivo de segurança, um serviço de registo gerido ou um conjunto de dados isolado num NAS com uma identidade separada. A independência é mais importante do que a distância física.
Armazene localmente os registos em buffer durante interrupções temporárias, mas limite o tamanho do buffer e encaminhe os dados após a recuperação. Caso contrário, uma interrupção do servidor de registos pode encher o volume da aplicação ou criar silenciosamente uma lacuna nas provas.
O Armazenamento Apenas para Acrescentar e Resistente a Adulteração Protege o Histórico
A localização remota, por si só, é insuficiente quando os administradores ou as credenciais de ingestão podem atualizar linhas históricas arbitrárias. O modelo de armazenamento deve privilegiar a adição de novos eventos em vez da edição dos existentes.
Um registo apenas para acrescentar preserva registos sequenciais sem atualizações normais no local nem eliminações. A retenção de objetos imutáveis, as políticas de escrita única, as cadeias de hash e os pontos de controlo assinados podem tornar ainda mais detetáveis as alterações não autorizadas.
Nenhum design é absolutamente imune a adulteração quando um único administrador controla todos os sistemas e chaves de recuperação. O objetivo prático é obter resistência à adulteração e provas de alterações através de identidades independentes e controlos de armazenamento distintos.
Os Registos Externos Correlacionam Ações Entre Fronteiras de Serviços
Um fluxo de trabalho doméstico pode passar por um proxy inverso, um fornecedor de identidade, uma aplicação, uma base de dados, um serviço de armazenamento, um motor de automatização e uma API externa. Um registo local da aplicação vê apenas parte da sequência.
A OWASP identifica a falta de telemetria de auditoria como um problema de visibilidade nos sistemas que obtêm dados e executam ferramentas. IDs de pedido partilhados, IDs de utilizador, IDs de evento, endereços de origem e marcas temporais permitem ao arquivo de registos externo reconstruir qual o serviço que executou cada passo.
A sincronização temporal faz parte destas provas. Grandes diferenças entre relógios podem fazer com que uma sequência correta entre vários serviços pareça estar fora de ordem.
As orientações da ZimaSpace para separar os registos dos contentores também impedem que o crescimento e a rotação dos registos operacionais fiquem interligados com o estado insubstituível da aplicação.
A Retenção e os Controlos de Acesso Mantêm as Provas Úteis e Privadas
Os registos de auditoria podem conter nomes de utilizador, endereços IP, nomes de ficheiros, termos de pesquisa, identidades de dispositivos, credenciais falhadas e rotinas domésticas. Movê-los para fora da aplicação concentra metadados sensíveis num novo local.
As orientações modernas sobre registos resistentes a adulteração tratam os controlos de integridade dos registos como uma combinação de escolhas de recolha, transporte, armazenamento, acesso e análise. Utilize transporte encriptado, uma identidade de ingestão dedicada, acesso de analistas apenas para leitura, uma política de retenção documentada e alertas para lacunas no encaminhamento.
Teste gerando um evento administrativo conhecido, confirmando que chega externamente, eliminando ou recriando a aplicação e verificando se o registo histórico continua disponível para consulta. Em seguida, desligue o coletor e confirme que o sistema comunica a lacuna, em vez de fingir que o registo está completo.
A arquitetura de registos é bem-sucedida quando um comprometimento da aplicação pode interromper os relatórios futuros, mas não pode reescrever silenciosamente as provas já aceites pelo arquivo independente.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
Estado em tempo de execução vs. estado persistente no Home Assistant: o que tem de sobreviver ao reinício?
O Home Assistant não persiste todos os valores em tempo real; a configuração, os registos, os estados restaurados selecionados, o histórico e os dados...
Como é que o Home Assistant autentica sessões locais e remotas?
As sessões locais e remotas do Home Assistant utilizam o mesmo modelo de identidade do lado do servidor; o acesso remoto altera a rota...
Porque é que as consultas ao histórico do Home Assistant podem ficar mais lentas à medida que os dados do Recorder aumentam?
O crescimento do gravador pode aumentar o custo das consultas do Histórico quando o intervalo solicitado abrange mais linhas, as falhas de cache aumentam...
