Configurar Data Anonymization na Sophos Firewall

Data anonymization cifra informações de identificação nos logs e relatórios da Sophos Firewall. Isto inclui, em particular, nomes de utilizador, endereços IP, endereços MAC e endereços de e-mail. Um administrador autorizado pode voltar a apresentar estas informações para uma análise legítima.

O procedimento seguro é curto:

1. Documentar o objetivo, as saídas afetadas e o processo de aprovação.
2. Preparar duas contas pessoais de administrador como authorizers.
3. Ativar a função em System services > Data anonymization e selecionar ambos os authorizers.
4. Utilizar um evento de teste controlado para verificar se o Log viewer e a pesquisa continuam a funcionar.
5. Apresentar deliberadamente a identidade com um authorizer e realizar um teste negativo do acesso não autorizado.
6. Adicionar exceções apenas para casos individuais justificados.
7. Verificar separadamente as exportações CSV e os relatórios PDF efetivamente gerados.

⚠️ Data Anonymization não elimina dados nem garante a proteção de todos os caminhos de dados externos. Remote Syslog, Sophos Central, CTR, ficheiros da Advanced Shell e backups são verificados separadamente. Uma exportação só é partilhada depois de o ficheiro concreto ser verificado quanto a identidades sensíveis.

O que Data Anonymization protege

A Sophos descreve a função como a cifragem de identidades em logs e relatórios. São mencionados especificamente:

• nomes de utilizador;
• endereços IP;
• endereços MAC;
• endereços de e-mail.

Isto reduz a exposição desnecessária durante a análise diária e o reporting. Por exemplo, um NOC pode investigar um problema por hora, regra e ação sem ver imediatamente todas as identidades de utilizadores ou clientes. Continua a ser possível uma divulgação controlada para um caso legítimo de segurança ou privacidade.

A função não substitui, no entanto, os direitos de acesso, as regras de retenção ou o transporte protegido. Um relatório anonimizado pode continuar a conter nomes de firewalls, URLs, nomes de regras, carimbos de data/hora e eventos de segurança. Estas informações também podem ser confidenciais.

O que não é assumido de forma geral

A ajuda atual da Sophos confirma o efeito em logs e relatórios e a possibilidade de apresentar informações no Log viewer. No entanto, não descreve todos os caminhos de saída possíveis com o mesmo nível de detalhe. Por isso, a definição on-box não é automaticamente aplicada aos seguintes caminhos de dados:

• Remote Syslog ou SIEM;
• Sophos Central Firewall Reporting;
• Consolidated Troubleshooting Reports e logs de suporte individuais;
• ficheiros em /log na Advanced Shell;
• backups e exportações de configuração;
• e-mails já enviados ou ficheiros PDF e CSV armazenados.

O Remote Syslog continua a exigir o procedimento específico de proteção e validação descrito em Enviar Syslog da Sophos Firewall de forma segura para um SIEM. Os relatórios centrais são verificados separadamente, conforme descrito em Sophos Central Firewall Reporting.

Preparar os authorizers e o duplo controlo

Ao ativar a função, são selecionados administradores como Authorizer. Esta função pode apresentar identidades anonimizadas depois de uma nova autenticação. A Sophos recomenda pelo menos dois authorizers. Se o administrador com sessão iniciada também estiver registado como authorizer, é necessária a aprovação de pelo menos outro authorizer.

Por isso, antes da ativação são preparadas duas contas pessoais, por exemplo:

• privacy.authorizer1
• privacy.authorizer2

Estes nomes são exemplos e são substituídos por duas contas de administrador claramente atribuídas a pessoas. Uma conta de equipa partilhada seria inadequada, porque a divulgação, a aprovação e a revisão posterior deixariam de poder ser atribuídas a uma pessoa. Configurar administradores e perfis de Device Access em segurança explica como criar contas pessoais e perfis limitados.

São também definidos previamente os seguintes pontos:

• os casos de suporte, segurança ou privacidade em que a divulgação é permitida;
• quem solicita e aprova a análise;
• como são documentados o ticket, o objetivo, o período e as identidades afetadas;
• quando uma exceção expira e volta a ser revista;
• que administrador local de recuperação permanece disponível se um authorizer não funcionar.

A ativação é interrompida se estiver disponível apenas um administrador funcional ou se o segundo authorizer ainda não tiver passado um teste positivo.

Ativar Data Anonymization

1. Iniciar sessão no WebAdmin com uma conta pessoal de administrador.
2. Abrir System services > Data anonymization.
3. Selecionar Enable data anonymization.
4. Selecionar pelo menos os dois authorizers preparados.
5. Selecionar Apply.
6. Se o administrador com sessão iniciada estiver selecionado como authorizer, fornecer com o segundo authorizer a aprovação exigida pela Sophos.
7. Recarregar a página e verificar se a definição ativada continua a ser apresentada.

A alteração não é combinada com alterações aos perfis de administrador, MFA ou destinos dos logs. Uma única alteração é mais fácil de verificar e reverter.

Gerar um evento de teste controlado

O teste de aceitação utiliza um cliente piloto conhecido, por exemplo 10.20.30.25, e um utilizador de teste claramente atribuído, como privacy.test. O endereço IP privado é um exemplo. É substituído por um cliente piloto real da rede de gestão ou de teste para que o evento gerado possa ser identificado de forma inequívoca no Log viewer local.

Para o teste são documentados a hora, a Source, a Destination, o serviço e o Firewall Rule ID esperado. Em seguida, o cliente piloto gera uma ligação curta e permitida cuja regra tem Log firewall traffic ativado. Isto permite distinguir uma função de anonimização operacional da simples ausência de um evento correspondente.

Se o evento não aparecer, deve verificar-se primeiro o caminho de logging normal. Associar corretamente os serviços e os ficheiros de log da Sophos Firewall ajuda nesta verificação. Data Anonymization não corrige o logging de regras desativado nem um Log viewer bloqueado.

Realizar testes positivos e negativos no Log viewer

1. Abrir Log viewer e selecionar o módulo relevante.
2. Limitar o período e os filtros ao evento de teste documentado.
3. Verificar se os campos de utilizador e endereço aparecem anonimizados.
4. Executar uma pesquisa de texto livre com as informações anonimizadas visíveis. A Sophos confirma que a pesquisa também funciona com informações anonimizadas.
5. Como authorizer registado, utilizar o botão Data anonymization e introduzir as próprias credenciais de autenticação atuais da conta.
6. Verificar se a identidade esperada fica visível para a análise.
7. Fechar a vista autorizada e utilizar um administrador de teste que não esteja registado como authorizer para verificar se as informações não podem ser apresentadas.

Um teste bem-sucedido do authorizer apenas comprova este caminho específico do WebAdmin. Ainda não comprova que PDF, CSV, Central, Syslog ou os arquivos de suporte utilizem a mesma apresentação.

Adicionar exceções apenas com justificação

Uma exceção impede que a identidade selecionada seja cifrada em logs e relatórios. Pode ser definida para utilizadores, endereços IP, endereços MAC ou endereços de e-mail. Não é uma função de pesquisa mais cómoda, mas uma divulgação deliberada.

Um caso justificável pode ser uma identidade técnica de serviço que um processo operacional automatizado tenha de distinguir em texto simples. Mesmo assim, a exceção precisa de:

• um objetivo documentado;
• o menor âmbito de identidade possível;
• um owner;
• uma data de expiração ou revisão;
• um teste positivo da exceção e um teste negativo de uma identidade que permaneça anonimizada.

O procedimento documentado é:

1. Adicionar a exceção específica em System services > Data anonymization.
2. Selecionar Apply.
3. Introduzir o nome de utilizador e a palavra-passe de um authorizer.
4. Selecionar Save.
5. Gerar um novo evento de teste e verificar a apresentação real.

Depois de uma autenticação bem-sucedida, as identidades selecionadas não são cifradas. Um intervalo de rede amplo, um grupo de utilizadores completo sem justificação individual ou uma exceção permanentemente aberta não são utilizados como predefinição.

Verificar realmente os ficheiros PDF e CSV

A vista do WebAdmin é apenas uma parte do teste de aceitação. As saídas podem ser posteriormente armazenadas fora da firewall, enviadas por e-mail ou copiadas para um sistema de tickets.

Verificar um relatório PDF agendado

Nos relatórios locais por e-mail, não se espera pela próxima execução regular depois da ativação. O agendamento é executado com Generate now e é inspecionado o PDF efetivamente recebido. Agendar relatórios da Sophos Firewall e enviá-los por e-mail descreve o processo completo de envio e validação.

São verificados pelo menos os seguintes pontos:

• campos de utilizador, IP, MAC e e-mail;
• exceções pretendidas;
• URLs, nomes de regras e outros conteúdos sensíveis;
• destinatários, transporte de e-mail e retenção na caixa de correio.

Um PDF gerado anteriormente não se torna uma nova prova de aceitação depois de uma alteração posterior da definição. Para o teste é gerado um ficheiro novo.

Verificar uma exportação CSV do Log viewer

O Log viewer pode exportar a vista atual como CSV. A ajuda atual da Sophos confirma a exportação, mas não descreve separadamente o âmbito de anonimização do ficheiro. Por isso, é aberta uma pequena exportação do evento de teste controlado e verificada campo a campo.

Este caminho de exportação só é utilizado em produção depois de as identidades anonimizadas e as exceções pretendidas aparecerem corretamente. Em seguida, o ficheiro é armazenado em segurança ou eliminado. Um nome de ficheiro sem uma identidade não impede que o conteúdo inclua dados sensíveis.

Validar HA e caminhos de dados externos

Num cluster HA, Data Anonymization é novamente verificado depois de um failover controlado. É gerada uma nova sessão de teste no nó que está agora ativo e o processo do Log viewer é repetido. Uma sessão WebAdmin existente ou um teste efetuado apenas no antigo Primary não constituem prova suficiente.

Remote Syslog, Central Reporting, CTR e os logs da Advanced Shell são tratados como caminhos de dados separados:

1. Definir o destino e a responsabilidade.
2. Gerar um evento de teste controlado.
3. Verificar a saída efetivamente recebida ou descarregada.
4. Documentar o acesso, a retenção e a eliminação segura.

Se um caminho de dados externo continuar a conter texto simples, isso não é ocultado com uma exceção ampla nem desativando o logging local. Em vez disso, o acesso e o transporte do sistema afetado são reforçados ou a exportação é interrompida até que o requisito de privacidade esteja esclarecido.

Delimitar os erros de forma sistemática

As identidades continuam a aparecer em texto simples

Primeiro, verifica-se se Enable data anonymization continua ativo e se o evento visível foi gerado depois da alteração mais recente. Em seguida, verificam-se as exceções para utilizadores e endereços IP, MAC ou de e-mail. Um evento pode conter várias identidades; uma exceção para o Source IP não explica automaticamente um nome de utilizador visível.

Depois, repõe-se o Log viewer, gera-se um novo evento de teste e verifica-se novamente a vista. PDFs antigos, transferências do browser ou screenshots não constituem prova fiável da definição atual.

Um authorizer não consegue apresentar uma identidade

Verificar se a conta pessoal está realmente selecionada como authorizer e se são utilizadas as próprias credenciais de autenticação atuais. Se o administrador com sessão iniciada for também authorizer, é planeada a aprovação necessária por outro authorizer.

Os perfis de administrador, MFA e a origem do login não são alterados ao mesmo tempo. Se a apresentação continuar a falhar apesar da seleção correta e de um login normal bem-sucedido, são documentados a hora, o browser, a conta e a mensagem visível. Os authorizers não são removidos antes de estarem disponíveis um segundo acesso testado e um caminho de recuperação.

Um ficheiro PDF ou CSV difere do Log viewer

Os caminhos são avaliados separadamente. Para PDF, são documentados o tipo de relatório, a hora de geração e Generate now. Para CSV, são registados o módulo, os filtros e a hora de exportação. Para Central, Syslog ou arquivos de suporte, não se promete a anonimização local; verifica-se o ficheiro ou a plataforma de destino real.

Os serviços de reporting ou logging não são reiniciados e os dados dos relatórios não são eliminados apenas porque uma saída é apresentada de forma diferente. Primeiro, cria-se um teste reproduzível com um ficheiro novo.

Reverter em segurança

As definições anteriores são documentadas antes do piloto. Se a nova configuração não cumprir os requisitos operacionais acordados, o estado anterior é restaurado em System services > Data anonymization através de uma alteração autorizada. Em seguida, são verificados um novo evento de log, a vista do authorizer, uma exportação CSV e, se necessário, um PDF.

As exceções são primeiro removidas ou repostas no âmbito anterior. Os ficheiros já exportados continuam a existir separadamente e têm de ser tratados de acordo com as regras aplicáveis de retenção e eliminação. A reversão da definição da firewall não remove as cópias de caixas de correio, SIEM, tickets ou casos de suporte.

Checklist de operação

• objetivo, owner e processo de aprovação documentados
• dois authorizers pessoais passaram um teste positivo
• administrador local de recuperação disponível
• Enable data anonymization ativo e confirmado depois de recarregar
• evento de log controlado visível de forma anonimizada
• apresentação pelo authorizer bem-sucedida e acesso não autorizado rejeitado
• exceções limitadas, justificadas e com data de revisão
• novo PDF e CSV do Log viewer verificados
• Syslog, Central, CTR e logs de shell avaliados separadamente
• failover HA validado com um novo evento
• ficheiros já exportados protegidos e tratados de acordo com a retenção

Perguntas frequentes

Data Anonymization elimina dados pessoais?

Não. A Sophos descreve a função como a cifragem de identidades em logs e relatórios. Um administrador autorizado pode voltar a tornar as informações visíveis depois da autenticação. Isto não é equivalente à eliminação nem a uma anonimização irreversível.

O Remote Syslog e o Sophos Central são anonimizados automaticamente?

A descrição atual da função não o confirma expressamente para estes caminhos de dados. Por isso, utiliza-se um evento controlado para verificar o que é visível no destino Syslog real, no Central, no CTR ou num ficheiro descarregado.

Um único authorizer é suficiente?

A interface permite um ou mais authorizers, mas a Sophos recomenda pelo menos dois. Se o administrador com sessão iniciada também for authorizer, é necessário pelo menos outro authorizer para a aprovação. Para uma operação protegida contra lockout, são portanto utilizadas duas contas pessoais e testadas.