Planear, exportar e monitorizar relatórios Sophos Central
O Sophos Central disponibiliza logs e relatórios diferentes consoante a licença e o produto. No entanto, um relatório só tem valor operacional quando o período, os filtros, os destinatários, a responsabilidade e a retenção estão definidos. Uma vista guardada sem responsável torna-se pouco fiável, o mais tardar, quando o administrador muda ou o plano de envio expira.
Distinguir log, relatório e dashboard
| Área | Finalidade |
|---|---|
| Log | investigar eventos individuais ou ações administrativas |
| Report | guardar, exportar ou enviar dados filtrados como avaliação repetível |
| Dashboard | observar o estado atual e tendências numa vista de trabalho |
Um relatório PDF não substitui dados brutos para uma investigação nem um arquivo SIEM de longo prazo. Para alterações administrativas, a fonte correta continua a ser o Sophos Central Audit Log.
Que logs aparecem em Reports
As entradas visíveis em Reports dependem da licença, dos produtos ativados e da função do administrador. O Central reúne aí várias fontes de dados com finalidades distintas:
| Log | Conteúdo e responsabilidade |
|---|---|
| Events | eventos dos dispositivos geridos; a avaliação operacional pertence ao runbook de Endpoint ou Server correspondente. |
| Malware and PUAs blocked | excerto simplificado do Event Log para malware e aplicações potencialmente indesejadas detetados e bloqueados. |
| Audit Logs | atividades administrativas no Central; a visibilidade e a exportação dependem da função. |
| Data Loss Prevention | eventos acionados por regras DLP em computadores ou servidores. |
| Message History | mensagens processadas pelo Sophos Email para as caixas de correio protegidas. |
Estes logs não devem ser combinados num único indicador de segurança. Uma área DLP ou Message History vazia pode dever-se a falta de licença, produto, função ou a um filtro e não prova automaticamente que não ocorreram eventos.
Reconhecer relatórios legacy e mais recentes
Na lista de relatórios guardados, o Central indica se uma entrada utiliza o formato legacy mais antigo. Esta distinção é importante porque os limites não são iguais.
A lista apresenta o nome do relatório, autor, formato e frequência agendada. As barras Report Templates e Actively Scheduled não contabilizam relatórios legacy. Por isso, o número do gráfico não prova que já não existam agendas antigas; numa passagem de responsabilidades deve verificar-se sempre a lista completa. A maioria dos logs e relatórios gerais continua a utilizar o formato legacy.
Para relatórios legacy aplicam-se, por administrador:
- no máximo 25 relatórios agendados e 25 não agendados;
- no máximo 10.000 eventos por relatório ou log;
- visibilidade, em princípio, apenas para o autor;
- paragem automática do envio por e-mail após seis meses.
Administradores Partner e Enterprise não podem assumir simplesmente estes relatórios pessoais legacy no tenant do cliente. Se o autor sair da empresa, os relatórios necessários devem ser recriados antes do offboarding sob uma conta administrativa operacional adequada.
Os formatos de relatório mais recentes têm outras características. Atualmente, cada administrador pode agendar até 100 relatórios desse formato. Administradores autorizados, parceiros e administradores Enterprise podem vê-los. O formato novo não está automaticamente disponível para todos os produtos e é utilizado, entre outros, para MDR e Central Firewall. A identificação de formato apresentada no portal é, portanto, determinante, não o nome do relatório.
Após seis meses, abre-se, edita-se e guarda-se novamente um relatório legacy ainda necessário. Isto reinicia o período de envio. A intervenção é documentada com o responsável e a próxima data de revisão, em vez de prolongar o mesmo relatório repetidamente sem controlo.
Planear o relatório do ponto de vista funcional
Antes de guardar, definem-se finalidade e âmbito:
- Que questão operacional deve o relatório responder?
- Que produtos, grupos, dispositivos e períodos devem ser incluídos?
- Quem avalia o resultado e até quando?
- A saída contém dados pessoais ou relevantes para a segurança?
- É necessária uma fotografia pontual, um relatório recorrente ou um fluxo de dados SIEM?
Um nome claro contém função, âmbito e frequência, por exemplo Endpoint Health - Produktion - wöchentlich. Nomes como Test, Report 2 ou o nome de uma pessoa dificultam a passagem posterior.
O caminho operacional começa em Reports. Consoante o relatório, o período pode ser limitado com From e To. Os mosaicos de categoria filtram os resultados visíveis, por exemplo Active no relatório Computers; outras vistas permitem filtros de grupo e a procura de valores concretos. Depois de cada alteração de filtro, valida-se a plausibilidade do número de resultados antes de guardar ou exportar a vista.
Print abre uma vista otimizada para impressão. Segue-se a caixa de diálogo do browser com Ctrl+P ou Cmd+P no macOS. Um relatório reutilizável é criado através de Save as Custom Report: atribuir um nome, selecionar a Frequency pretendida e confirmar com Save.
Guardar e enviar
Consoante o relatório, estão disponíveis vista de impressão, CSV e PDF. Nem todos os relatórios suportam todas as opções. CSV é adequado para filtragem e correlação, PDF para uma fotografia legível.
Ao guardar um Custom Report, pode enviar-se um link ou um anexo. Para informações pessoais, deve preferir-se o link, porque o destinatário tem de iniciar sessão no Central e o ficheiro não fica permanentemente em várias caixas de correio. Anexos são enviados apenas a destinatários definidos e não são encaminhados através de listas de distribuição abertas.
O e-mail agendado é enviado ao administrador que criou o relatório. Se outra pessoa assumir a responsabilidade, o relatório é novamente guardado ou planeado sob a conta operacional prevista; um reencaminhamento silencioso da caixa de correio pessoal não constitui uma transferência de responsabilidade fiável.
Relatórios legacy são agendados semanal ou mensalmente. Um envio mensal exige um período selecionado de pelo menos 30 dias. Filtros e período são testados integralmente antes de guardar; se não puderem ser alterados posteriormente como pretendido, cria-se um novo relatório e remove-se o antigo de forma controlada.
O idioma do relatório segue a conta Central Admin que configurou o envio. No acesso por parceiro, o idioma do tenant do cliente pode ser determinante. Um idioma inesperado não deve, por isso, ser confundido com uma falha do modelo.
Utilizar corretamente o Co-Branding
Em Global Settings > Platform > Co-branding, Super Admins e Admins podem carregar o logótipo da empresa. Este aparece no Self-Service Portal e nos relatórios PDF de Endpoint e Server suportados. Um logótipo do parceiro pode ser adotado se este tiver aberto o tenant do cliente a partir do Partner Portal.
Se existirem logótipos do parceiro e do cliente, o do parceiro aparece no canto superior direito e o do cliente no canto superior esquerdo do relatório. Antes de um envio externo, gera-se por isso uma amostra PDF e verifica-se o tenant correto, as marcas corretas e o conteúdo confidencial.
Para mudar para outro logótipo ou regressar ao logótipo Sophos, é necessário remover primeiro o logótipo existente e guardar depois a nova seleção. O Co-Branding não altera o conteúdo nem as permissões do relatório e não é uma funcionalidade de segurança. Apenas ajuda os utilizadores a reconhecer um portal empresarial oficial ou um relatório previsto.
Operação e passagem de responsabilidades
Um controlo mensal verifica:
- último envio bem-sucedido e próxima execução;
- responsável funcional e destinatários válidos;
- formato do relatório e os respetivos limites;
- alterações de licença e de função;
- volume de dados e possível limite de 10.000 eventos;
- data de expiração dos relatórios legacy;
- necessidade e retenção das exportações.
No offboarding de um administrador, relatórios legacy pessoais, dashboards, API Credentials e regras de alerta são verificados em conjunto. A simples eliminação do administrador não deve provocar uma falha despercebida de monitorização ou de evidências de conformidade.