Logo

Artigo sobre segurança e privacidade (visão geral)Capítulo 10

Capítulo 10: Registro, monitoramento e resposta a incidentes

A observabilidade do FileBolt deve estar alinhada com os limites do Conhecimento Zero: o sistema deve identificar falhas, detectar ataques e quantificar o desempenho sem introduzir novos vetores de vazamento de dados confidenciais. Este capítulo define quais eventos são registrados, proíbe explicitamente o registro de certas informações, descreve métodos de alerta e detecção de anomalias, e detalha o processo de resposta a incidentes de segurança (IR) e os princípios de comunicação externa.

10.0 Resumo

  • SHOULD: Os registros e o monitoramento cobrem apenas eventos operacionais e de segurança necessários, utilizando agregação e amostragem para minimizar a retenção de detalhes brutos.
  • NÃO DEVE: quaisquer logs, APM ou relatórios de erros não devem conter CEK, fragmentos de URL (location.hash) ou URLs completos contendo fragmentos.
  • NÃO DEVE: não registre conteúdo de texto simples, partes descriptografadas ou material de chave derivável.
  • MUST: Estabelecer detecção e alerta para enumeração, força bruta, picos de tráfego e padrões anômalos, com medidas de contenção em vigor.
  • MUST: Manter um processo de Resposta a Incidentes (Triagem, Contenção, Análise Forense, Remediação, Revisão, Comunicação).

10.1 Eventos Registrados (Minimalismo)

Os logs e monitoramento do sistema DEVEM cobrir apenas o conjunto de eventos “necessários para operações e segurança”, evitando a ingestão de conteúdo do usuário ou credenciais confidenciais em sistemas de observabilidade. Os eventos são categorizados em Ciclo de Vida, Autenticação, Armazenamento/Rede e Proteção de Segurança, com agregação recomendada.

10.1.1 Transferir eventos do ciclo de vida

  • Criar transferência (gerar transferId)
  • Carregamento do pedaço concluído (registrado no nível do texto cifrado, não no texto simples)
  • Gravação/atualização de manifesto
  • Limpeza de expiração, exclusão/revogação de usuário (incluindo acionamento e conclusão de tarefa de limpeza)
  • Início/conclusão do download (medido no nível de download do texto cifrado)

10.1.2 Eventos de Autenticação e Autorização

  • Emissão de token de sessão, falha de validação (incompatibilidade de escopo, expirado, revogado, etc.)
  • Falha na validação do token de login de longo prazo (ação do administrador negada)
  • Padrões de acesso suspeitos: picos anômalos em 401/403/404

Observação: registre apenas "resultado e código de razão". NÃO DEVE registrar texto simples do token, texto simples do cabeçalho de autorização ou texto simples do parâmetro de assinatura.

10.1.3 Métricas de desempenho e integridade do sistema

  • Latência de solicitação (p50/p95/p99), taxas de erro, taxa de transferência
  • Taxas de falha de leitura/gravação de armazenamento de objetos, taxas de falha de busca de origem, contagens de novas tentativas
  • Anomalias de nós de borda, pendências de filas, taxas de sucesso de tarefas de limpeza em segundo plano
  • Tendências de largura de banda e tráfego (dimensões agregadas)

10.1.4 Eventos de Proteção de Segurança

  • Gatilhos de limitação de taxa, ocorrências de regras de WAF/firewall
  • Gatilhos de limite para suspeita de comportamento de enumeração/força bruta
  • Simultaneidade anômala e padrões de tráfego (alta simultaneidade da mesma fonte, consumo anormal de recursos)

10.1.5 Agregação e Amostragem

  • SHOULD: Agregue contagens e quantis de latência por minuto/hora para reduzir logs granulares.
  • SHOULD: Amostra de solicitações bem-sucedidas de alta frequência, retendo os detalhes necessários apenas para erros e caminhos anômalos.
  • SHOULD: retém campos de classificação estáveis (por exemplo, eventType, reasonCode) para eventos anômalos para facilitar a auditoria e a análise de máquina.

10.2 Informações Proibidas (CEK, Fragmento, Credenciais)

Uma chave para manter o compromisso de Conhecimento Zero é aplicar rigorosamente uma política de “Proibição de Dados Sensíveis” em todos os sistemas de observabilidade. Esta política deve abranger: logs de servidor, APM, relatórios de erros, monitoramento de terceiros, logs de clientes e saída do console do navegador.

10.2.1 O lado do servidor NÃO DEVE gravar

  • CEK (Chave de criptografia de conteúdo) e qualquer material derivável
  • Fragmento de URL (#...), location.hashe URLs completos contendo fragmentos
  • Conteúdo de texto simples: arquivo de texto simples, conteúdo de visualização, partes descriptografadas ou qualquer resumo de texto simples
  • Texto simples de credencial confidencial: tokens de sessão, tokens de longo prazo, texto simples do cabeçalho de autorização, texto simples do campo de assinatura em URLs assinados

Se o registro de URLs for necessário para depuração: MUST higienizar (remover fragmento; redigir ou remover consultas confidenciais) e impor isso no nível do código (sem depender de convenção manual).

10.2.2 O lado do cliente NÃO DEVE registrar

  • Não imprima location.href (pode conter fragmento) em ambientes de produção
  • Não inclua URLs com fragmentos, CEK ou noncePrefix em relatórios de erros
  • Os logs de depuração e as saídas da ferramenta de desenvolvimento devem ser desabilitados ou minimizados por padrão

SHOULD: encapsula uma função unificada de log/relatório no front-end que executa a limpeza de URL e a filtragem de campos confidenciais internamente antes da saída/relatório.

10.3 Métricas e alertas de monitoramento (disponibilidade, desempenho, segurança)

10.3.1 Alertas de disponibilidade e desempenho

  • Alertas de taxa de erro: picos em 5xx, aumento anormal em 4xx (distinguir falha de autenticação de abuso)
  • Alertas de latência: violações de limite p95/p99, anomalias de busca de origem regional
  • Alertas de armazenamento: aumento nas falhas de gravação no armazenamento de objetos e tempos limites de leitura
  • Alertas de tarefas de limpeza: backlog de limpeza de expiração, tentativas excessivas de tarefas de exclusão

10.3.2 Alertas de segurança

  • Aumento anormal na taxa de acerto do limite de taxa
  • Alta frequência 401/403/404 da mesma fonte, suspeita de enumeração/força bruta
  • Largura de banda/simultaneidade anormal de download de recurso único, suspeita de inundação de tráfego ou hotlinking
  • Mudanças críticas de política (por exemplo, regras WAF, mudanças de CSP/cabeçalho) devem acionar auditorias e alertas de mudança (se aplicável)

10.3.3 Governança de Alerta

  • SHOULD: categoriza alertas (P0/P1/P2) com caminhos de rotação/escalada.
  • SHOULD: aplique agregação de rejeição/janela a métricas ruidosas para evitar fadiga de alerta.
  • SHOULD: anexe informações mínimas de diagnóstico (código de motivo, gráfico de tendências, região/rota afetada) a cada alerta, excluindo dados confidenciais.

10.4 Detecção de anomalias e identificação de abuso

Os serviços de transferência de arquivos enfrentam naturalmente riscos de enumeração, força bruta, inundação de tráfego e abuso de recursos. Esta seção descreve sinais detectáveis ​​e princípios de resposta. Limites e estratégias específicos devem ser ajustados dinamicamente com base na escala do negócio e nos custos de falsos positivos.

10.4.1 Padrões de anomalias comuns

  • Enumeration: sondagem massiva de caminhos de transferId/recurso em pouco tempo, picos em 404/401/403.
  • Força Bruta: Tentativas de alta frequência em códigos de acesso/senhas/tokens, curva de taxa de falha anormal.
  • Inundação de tráfego: largura de banda anormal para recurso único, conexões simultâneas massivas da mesma fonte, downloads repetidos.
  • Anomalias de Protocolo: ordem irracional de blocos, uploads duplicados, interrupções/novas tentativas frequentes, padrões anormais de UA.

10.4.2 Estratégias de Mitigação (Princípios)

  • SHOULD: Limitação de taxas, banimento escalonado, mecanismos de desafio (se aplicável), políticas dinâmicas baseadas em ASN/Região/Impressão digital.
  • SHOULD: Adote estratégias mais suaves (por exemplo, atraso, otimização segmentada) para caminhos sensíveis a falsos positivos (usuários normais podem fazer downloads com frequência).
  • MUST: Reter gatilhos auditáveis (código de motivo, categoria de limite) para ações tomadas e fornecer canais de suporte (se aplicável).

10.5 Processo de Resposta a Incidentes

FileBolt DEVE estabelecer um processo de resposta a incidentes de segurança (IR) para garantir controle rápido de danos, capacidade de revisão e comunicação transparente. Os eventos que potencialmente afetem os compromissos de Conhecimento Zero (por exemplo, XSS, injeção na cadeia de abastecimento, fuga de fragmentos de registo) devem ser tratados como prioridade máxima.

  1. Triage: Classifique por escopo e gravidade do impacto (por exemplo, P0/P1/P2), defina caminhos de escalonamento e proprietários.
  2. Containment: Isole rapidamente as fontes de risco (banir fontes de ataque, desativar recursos temporariamente, reforçar políticas, alternar chaves/tokens).
  3. Análise Forense e Revisão: reconstruir a linha do tempo com base em registros e métricas mínimas; documentar decisões, impacto, remediação e melhorias.
  4. Remediação e Verificação: Implante patches, testes de regressão, verificação de segurança e novos testes de varredura de terceiros, se necessário.
  5. Comunicação e Divulgação: Explique de forma transparente aos usuários e ao público sem expandir a superfície de ataque; publicar relatórios de incidentes na página de status, se necessário.

A comunicação externa deve esclarecer: se o material principal ou o texto simples foi potencialmente exposto, o escopo do impacto, as medidas tomadas e as ações que os usuários precisam tomar (se houver).

10.6 Retenção de Dados e Controle de Acesso

Os registros e os dados de monitoramento são, por si só, ativos confidenciais. Períodos de retenção úteis mais curtos e controle de acesso com menos privilégios devem ser aplicados para minimizar riscos de vazamento e abuso.

  • SHOULD: defina períodos de retenção diferenciados para tipos de log (um pouco mais longos para erros e eventos de segurança, mais curtos ou nenhuma retenção para detalhes de solicitações bem-sucedidas).
  • SHOULD: Use o acesso com privilégios mínimos (RBAC) para plataformas de log e monitoramento e retenha auditorias de acesso.
  • SHOULD: Execute a higienização e minimização ao exportar/compartilhar logs (proibir o transporte de credenciais confidenciais e PII).

10.7 Princípios de Monitoramento e Integração de Terceiros

Ferramentas de rastreamento de erros/APM de terceiros podem coletar URLs, cabeçalhos, campos de formulário e informações do dispositivo por padrão. Se estiver usando monitoramento de terceiros, certifique-se de que os limites de coleta não violem os compromissos de Conhecimento Zero.

  • MUST: Não carregue scripts de terceiros nas páginas de download/descriptografia (consistente com o Capítulo 9).
  • MUST: configure explicitamente a coleção de terceiros: sem fragmentos, sem texto simples de cabeçalho sensível, sem conteúdo de texto simples.
  • SHOULD: Unifique a limpeza de URL para relatórios; proibir ou mascarar fortemente cargas potencialmente contendo campos confidenciais.
  • SHOULD: priorize métricas agregadas do lado do servidor em vez do rastreamento granular do lado do cliente para reduzir a superfície de coleta de endpoints.

10.8 IDs de reivindicação relacionadas (reservados)

Este capítulo aborda "Proibição de registro de dados confidenciais, alertas e IR, restrições de monitoramento de terceiros". Os IDs de reivindicação correspondentes serão adicionados ao Apêndice: Lista mestre de IDs de reivindicação como a única fonte autorizada.