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 Fusion (anteriormente 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 definir o limite de aprovação

Ao ativar a função, são selecionados um ou mais administradores como Authorizer. Esta atribuição autoriza a desanonimização; no Log viewer, um authorizer tem de fornecer as suas credenciais de autenticação. A Sophos recomenda pelo menos dois authorizers. Se o administrador com sessão iniciada também estiver registado como authorizer, a Sophos exige a aprovação de pelo menos outro authorizer.

Daqui resulta um limite importante: isto não comprova um duplo controlo técnico para cada divulgação. A ajuda do SFOS 22.0 apenas confirma autorização e nova autenticação no Log viewer. Se a política interna exigir duas pessoas para cada análise, aplique também esse processo organizacional e valide-o separadamente da autenticação do produto.

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.

Authorizer não é um perfil de Device Access separado. Os perfis fornecem acesso baseado em funções ao WebAdmin e à API através de None, Read-only ou Read-write; um utilizador local é criado em Authentication > Users com o tipo Administrator e um perfil. A Sophos não indica um perfil mínimo para Data Anonymization. Antes da alteração, verifique portanto se ambas as contas previstas conseguem realmente aceder à página necessária e ao Log viewer, sem atribuir um perfil não documentado.

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 uma conta de administrador funcional ou se o login normal no WebAdmin do segundo authorizer previsto não tiver sido testado com sucesso. A função de authorizer só pode ser testada depois da atribuição.

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, obter a aprovação de pelo menos outro authorizer quando a interface a solicitar.
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 não registado como authorizer para verificar que as identidades não são divulgadas. A falha exata pode variar consoante as permissões; o teste só é bem-sucedido se o administrador de teste não receber identidades em texto simples.

Um teste bem-sucedido do authorizer apenas comprova este caminho específico do WebAdmin. Ainda não comprova que PDF, CSV, Sophos Fusion, 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.

Delimitar HA, backups e caminhos de dados externos

A página Data Anonymization do SFOS 22.0 não contém afirmações específicas da função sobre sincronização HA ou conteúdo dos backups. Por isso, nenhum destes pontos é apresentado como garantido. Num cluster HA existente, um novo evento de teste após um failover planeado é uma validação operacional útil, mas a Sophos não o documenta como pré-requisito desta função.

A Sophos confirma, em geral, que um backup contém toda a configuração da firewall e é cifrado. O restauro substitui a configuração atual, elimina o backup armazenado na firewall e reinicia a firewall; restaurar um estado anterior elimina alterações posteriores. Sem outras provas, isto não determina como são tratadas as identidades históricas anonimizadas. Depois de um restauro, verifique novamente a definição, os authorizers, as exceções e um novo evento de log.

Nos restauros HA, o backup é restaurado no Primary atual e depois sincronizado com o Auxiliary; o reinício ocorre sem failover e causa downtime. Um backup sem configuração HA desativa HA. Restaurar um backup não é, portanto, um rollback simples apenas para Data Anonymization.

Remote Syslog, Sophos Central Firewall 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.

Resolver problemas 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, se o perfil de Device Access permite o acesso necessário e se são utilizadas as credenciais atuais da própria conta. Se o administrador com sessão iniciada também for authorizer, considerar a aprovação de outro authorizer descrita pela Sophos; não presumir uma segunda aprovação para cada ação do Log viewer se a interface não a solicitar.

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 Sophos Fusion, 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

Antes do piloto, registe três estados em System services > Data anonymization: Enable data anonymization, a lista de authorizers e cada exceção. Se a alteração não cumprir os requisitos acordados, reponha exatamente estes valores no estado registado através de uma alteração autorizada e selecione Apply. Restaurar um backup seria desproporcionado, pois substitui a configuração, reinicia a firewall e pode interromper HA.

A Sophos não documenta uma função Reset separada nem indica se a desativação altera retroativamente a apresentação de identidades já armazenadas. Valide o regresso com um novo evento de log, a vista do authorizer, uma exportação CSV e, se necessário, um PDF recém-gerado; não faça afirmações sobre entradas históricas sem as inspecionar.

Reponha as exceções no âmbito anterior. Os ficheiros já exportados continuam a existir separadamente e devem ser tratados segundo as regras aplicáveis. A reversão da definição não remove 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, Sophos Fusion, CTR e logs de shell avaliados separadamente
• comportamento HA verificado com um novo evento quando existe um cluster
• authorizers e exceções registados antes de um restauro; restauro não usado como rollback padrão
• 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 Fusion 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 Sophos Fusion, 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ária a aprovação de pelo menos outro authorizer. Contudo, a ajuda não comprova uma segunda aprovação obrigatória para cada divulgação no Log viewer. Para uma operação resiliente continuam a ser utilizadas duas contas pessoais e testadas.