Plano de resposta de incidente para o Weblate

Escopo and objetivos

Este IRP cobre incidentes que impactam a confidencialidade, integridade, ou disponibilidade de implementações operadas pelo Weblate.

Nota

Este plano é especificamente desenhado para implementações operadas pelo Weblate s.r.o. Outras implementações precisam de adaptar passos específicos ao fornecedor e à organização para o seu próprio ambiente.

Funções e responsabilidades

  • Responsável pela Resposta a Incidentes (IRL): Coordena todas as fases do processo de resposta.

  • Administrador de Sistema: Executa medidas de contenção e recuperação.

  • Agente de Segurança: Avalia o impacto e consequências regulamentares.

  • Agente de Proteção de Dados (DPO): Avalia se dados pessoas (PII) foi comprometida e gere notificações GDPR obrigatórias.

  • Responsável pelas comunicações: Gere as notificações destinadas às partes interessadas internas e a entidades externas, caso seja necessário.

Logísticas de comunicação

  • Comunicação Interna:

    • O canal primário é Signal para coordenação entre humanos.

    • Alertas técnicos permanecem fora do Signal para evitar ruído.

  • Comunicação Externa:

    • E-mail é usado para comunicar com clientes.

    • As listas de contacto de cliente são mantidas em várias localizações para assegurar acesso durante falhas de serviço.

  • Divulgação Pública:

Categorias de incidente e gravidade

Ativação de incidente

  • Declare um incidente quando um evento é confirmado ou fortemente suspeito de afetar confidencialidade, integridade, ou disponibilidade do serviço para além de ruído operacional de rotina.

  • O Agente de Segurança declara o incidente, assina a gravidade inicial, e aponta o Líder de Resposta do Incidente (IRL).

  • Se o Agente de Segurança está indisponível, qualquer operador sénior pode declarar o incidente e transferir a responsabilidade assim que for possível.

  • Reclassifique o incidnete se o âmbito ou mudanças de impacto mudarem durante investigação.

Categorias de incidente

  • Categoria 1 – Acesso Não Autorizado

  • Categoria 2 – Violação de Integração de Dados

  • Categoria 3 – Falha ou Degradação do Serviço

  • Categoria 4 – Configuração Incorreta ou Erro de Implementação

Níveis de gravidade e SLAs

Gravidade

Definição

Confirmação de Alvo

Ação Alvo Inicial

Crítico

Falha total; Administrador comprometido; violação de dados ativa; exige contenção imediata.

< 30 minutos

< 4 horas

Alta

Falha em funcionalidade principal; vazar de PII de um utilizador individual.

< 2 horas

12 horas

Média

Degradação de desempenho; Pequena falha de segurança.

1 Dia Útil

3 Dias Úteis

Baixa

Erros de UI; Problemas de staging; Erros sem ser de segurança.

Melhor Esforço

Melhor Esforço

Ciclo de vida de resposta a incidentes

Preparação

  • Assegure-se de cópias de seguranças diárias da base de dados PostgreSQL e do diretório de dados usando a cópia de segurança incluída do Weblate com rotação, veja Efetuar cópias de segurança e mover o Weblate.

  • Assegure-se que o Weblate utiliza um proxy inverso devidamente configurada (p.ex., NGINX) com HTTPS (TLS 1.2+).

  • Ativar 2FA para todas as contas ao nível de administrador.

  • Mantenha a instância Weblate e as suas dependências (Python, Django, Celery, base de dados, etc.) atualizadas.

  • Integre co sistemas SIEM usando o protocolo GELF para auditoria e redirecionamento de registo da aplicação.

Identificação

  • Monitorize o sistema s registos da aplicação (journalctl, registos de proxy inverso, registos da aplicação Weblate e de auditoria).

  • Analise eventos de início de sessão, execuções de webhook, e falhas de push/pull.

  • Configure alertas (através do Prometheus, Zabbix, ou SIEM) para múltiplas falhas de início de sessão, reiniciar inesperados, ou ações VCS irregulares.

Contenção

  • Cria um relatório de incidente com um ID de caso e linha de tempo com atualizações conforme ações são tomadas.

  • Coordena uma resposta humana no Signal e mantém alertas técnicas nos sistemas de monitorização existentes.

  • Para incidentes de Categoria 1 ou 2, crie um manual Hetzner Cloud Snapshot antes de tomar ações disruptivas quando é seguro para tal.

    • Formato do nome: IRP-[CaseID]-[YYYYMMDD]-Evidence.

    • Estes são separados de cópias de segurança rotativas padrão e devem ser preservado para análise.

  • Isole o anfitrião ou serviço afetado conforme preciso (por exemplo por regras de firewall ou isolação de serviço).

  • Desative integrações externas (Git/webhooks) se são parte de um vetor de ataque.

  • Suspender as contas dos utilizadores afetados imediatamente.

  • Revogar ou rodas credenciais administrativas, API, VCS, e de webhook conforme aplicável.

  • Preserva evidência relevante, incluíndo registos de sistema, registos de proxy reverso, aplicação Weblate e registos de auditoria, estado de configuração afetada, e a lista das credenciais ou integrações afetadas.

Erradicação

  • Remove qualquer código ou dados não autorizados.

  • Corrija vulnerabilidades conhecidas ao atualizar o Weblate ou componentes de servidor.

  • Valide integridade de repositório e binários usando somas de verificação SHA-256 ou registos Git.

Recuperação

  • Restaure serviços afetados ou dados a partir da última cópia de segurança Weblate que se saiba que está em bom estado.

  • Avaliação PII: DPO determina se a falha requer uma notificação GDPR de 72 horas.

  • Reintroduza serviços com uma abordagem por fases.

  • Confirme que o problema raiz foi removido ou um controlo compensante é inserido antes de restaurar tráfego normal.

  • Gire credenciais afetadas e verifique a integridade do sistema restaurado, repositórios, e configuração.

  • O Agente de Segurança e IRL aprovam o retorno a operações normais.

  • Monitorize registos e comportamento de sistema de forma contínua pelo menos durante 72 horas após a recuperação.

Revisão após o incidente

  • Linha temporal: Faça uma reunião de revisão dentro de 5 dias úteis do terminar do incidente.

  • Compile uma linha temporal do incidente e as ações tomadas.

  • Faça uma Análise da Causa Raiz (RCA) e documente-a dentro de 10 dias úteis.

  • Atualize políticas de segurança e documentação IRP com base nas conclusões.

  • Faça uma revisão da eficácia dos mecanismos de deteção e contenção.

  • Verifique se um escalar, alerta, e comunicação externa seguiu Tratamento de vulnerabilidades e incidentes conforme esperado.