Registo de auditoria de transferência: monitorize quem descarregou o quê

Um registo de auditoria de transferência de ficheiros regista cada evento significativo na vida de uma transferência — upload, tentativas de palavra-passe, autenticação bem-sucedida, intervalos de bytes servidos, endereços IP, User-Agents e eliminação final — num log de escrita apenas que sobrevive a falhas de disco e satisfaz o Artigo 30 do RGPD, a HIPAA 164.312(b), o SOC 2 CC7.2 e o Requisito 10 do PCI DSS 4.0. O registo responde à pergunta que cada responsável por resposta a incidentes recebe às 2 da manhã: quem descarregou o .pdf, quando, de onde e em que dispositivo. Sem ele, está a adivinhar.

Que eventos pertencem ao log

Seis eventos cobrem a maioria dos cenários forenses. Primeiro, conclusão do upload: IP do remetente, tamanho do ficheiro, SHA-256 do texto cifrado, tipo MIME declarado. Segundo, criação do link: expiração, máximo de downloads, flag de palavra-passe, flag de 2FA. Terceiro, tentativas de acesso: timestamp, /24 de IP, booleano de palavra-passe correcta, família de User-Agent. Quarto, início de download: ID de sessão, primeiro byte servido. Quinto, conclusão do download: total de bytes, duração, código HTTP 2xx/4xx. Sexto, eliminação: gatilho (expiração, máximo atingido, revogação manual), timestamp, confirmação de zeroficação. Ignore qualquer um destes e terá uma lacuna que o auditor nota.

Armazenamento de escrita apenas que resiste à adulteração

O log tem de resistir à modificação mesmo por administradores. Uma abordagem: escrever eventos para um bucket AWS S3 com Object Lock em modo Governance (modo compliance para HIPAA) e retenção de 90 dias. Outra: transmitir para o ClickHouse com a garantia FINAL do MergeTree, com hash em raízes Merkle diárias publicadas num boletim público. A ancoragem em blockchain — registar a raiz diária no Bitcoin via OpenTimestamps — custa cerca de €0,30/dia e dá-lhe prova criptográfica de que nenhum evento foi falsificado. Para a maioria das equipas, o S3 Object Lock mais separação IAM é suficiente.

Formatos estruturados que os auditores conseguem analisar

As linhas JSON funcionam, mas os auditores preferem syslog RFC 5424 ou o mais recente OCSF (Open Cybersecurity Schema Framework) para ingestão em SIEM. Cada evento recebe campos como activity_id, severity_id, time, actor.user.email_hash, src_endpoint.ip, file.hashes.sha256. O Splunk, Datadog e Elastic analisam todos OCSF nativamente. Para equipas mais pequenas, uma exportação CSV com colunas (timestamp_utc, event_type, transfer_id, ip_hash, outcome, bytes) depositada numa pasta partilhada trimestralmente satisfaz o requisito de evidência sem comprar uma licença SIEM.

Tratamento de IPs ao abrigo do RGPD

Os endereços IP são dados pessoais ao abrigo do RGPD (confirmado pelo processo Breyer v. Alemanha, 2016). Não pode simplesmente registar IPs completos indefinidamente. Haxeie-os com HMAC-SHA256 usando uma chave de rotação diária, o que quebra a correlação após 24 horas enquanto preserva a análise forense do mesmo dia. Retenha IPs brutos apenas durante uma investigação activa com interesse legítimo documentado ao abrigo do Artigo 6(1)(f). Alguns serviços armazenam apenas prefixos /24, o que mantém a geolocalização mas perde a atribuição individual — uma troca justa para um nível gratuito. Documente a sua escolha na política de privacidade para que os titulares de dados possam exercer os direitos do Artigo 15.

Sincronização de tempo e não-repúdio

Um registo de auditoria só é credível se os timestamps forem precisos. Corra chrony ou systemd-timesyncd contra NIST ou time.cloudflare.com da Cloudflare, e inclua um campo clock_skew_ms em cada evento para que um analista forense conheça o intervalo de confiança. Para não-repúdio, assine cada ficheiro de log com Ed25519 usando uma chave armazenada no AWS KMS ou numa YubiHSM. A assinatura prova que o log não foi alterado após o facto e não poderia ter sido falsificado sem comprometer o HSM — o tipo de prova que um tribunal aceita.

Períodos de retenção por regulamentação

As diferentes frameworks exigem janelas diferentes. A HIPAA exige 6 anos a partir da data de criação ou última utilização, o que for mais tarde (45 CFR 164.316(b)(2)). O PCI DSS 4.0 exige 12 meses imediatamente acessíveis mais 12 em armazenamento frio. O SOC 2 remete para a sua política, mas os auditores olham mal para qualquer coisa abaixo de um ano. O Artigo 5(1)(e) do RGPD diz "não mais do que necessário" — interprete como corresponder à retenção dos registos comerciais que o log suporta. Defina a retenção por tenant no seu esquema de base de dados e execute um trabalho de purga mensal que re-assina os segmentos restantes.

Geração de relatórios que os humanos lêem

Os logs brutos não satisfazem o pedido de um regulador. Crie um gerador de relatórios que filtre por ID de transferência, intervalo de datas ou hash de email do receptor e produza um PDF com timestamp contendo o logótipo da empresa, tabela de eventos e a assinatura Ed25519 que verifica a autenticidade. Inclua uma página de capa com o hash SHA-256 do próprio relatório para que o receptor possa detectar alterações. Ferramentas como WeasyPrint ou Typst processam isto de forma limpa a partir de um template Jinja2. O HexaTransfer exporta relatórios em PDF e CSV; os auditores normalmente pedem ambos.

Alertas sobre anomalias

O registo é inútil se ninguém o lê. Defina regras que desencadeiem alertas: mais de 5 falhas de palavra-passe em 10 minutos, downloads de um intervalo de IP que não corresponde ao país do remetente, acesso fora do horário comercial para ficheiros de saúde, ou qualquer surto de 4xx num único link. Encaminhe alertas para PagerDuty para equipas SOC ou um webhook do Slack para operadores individuais. Afine os limiares trimestralmente; alertas ruidosos são ignorados, o que derrota o propósito. Documente o conjunto de regras para que os auditores vejam que pensou na detecção, não apenas no registo.

A eliminação como evento registado

A última entrada na vida de uma transferência é o seu apagamento. Registe o gatilho (temporizador de expiração, contagem máxima de downloads, revogação manual), o método de zeroficação (número de passagens, tipo de dispositivo) e o SHA-256 pós-eliminação da região do disco para provar que nada reconhecível ficou. Isto é importante para confirmações de direito de apagamento ao abrigo do Artigo 17 do RGPD e para limiares de notificação de violação HIPAA. O log da eliminação sobrevive ao próprio ficheiro — por vezes durante anos — o que é exactamente como um sistema em conformidade deve comportar-se.

Experimente em hexatransfer.com — gratuito, sem conta, até 10 GB.