Weblate 사고 대응 계획

범위 및 목표

이 IRP는 Weblate 운영 배포의 기밀성, 무결성 또는 가용성에 영향을 미치는 사고를 다룹니다.

참고

이 계획은 Weblate s.r.o.가 운영하는 배포를 위해 특별히 설계되었습니다. 다른 배포는 공급자별 및 조직적 단계를 자체 환경에 맞게 조정해야 합니다.

Handling an incident

One team member handles the incident and names an available teammate as a backup. They coordinate investigation, containment, recovery, reporting, and user communication, asking other teammates or outside specialists for help when needed. The backup takes over when the handler is unavailable.

Use Incident reporting for reporting decisions, deadlines, and a private incident note. No separate management approval is needed to begin responding.

커뮤니케이션 체계

  • 내부 커뮤니케이션:

    • 주요 채널은 인력 간 조율을 위한 Signal 입니다.

    • 노이즈를 방지하기 위해 기술적 알림은 Signal 외부에 유지됩니다.

  • 외부 커뮤니케이션:

    • 이메일 을 사용하여 고객에게 연락합니다.

    • 고객 연락처 목록은 서비스 중단 시 접근을 보장하기 위해 여러 곳에 유지됩니다.

  • 공개 공지:

사고 분류 및 심각도

사고 발동

  • 일상적인 운영 노이즈를 넘어 서비스의 기밀성, 무결성 또는 가용성에 영향을 미치는 것으로 확인되거나 강력히 의심되는 이벤트가 있을 때 사고를 선언합니다.

  • Whoever identifies the incident alerts teammates through Signal. An available teammate takes responsibility, records the initial severity, and names a backup.

  • 조사 중 범위나 영향이 변경되면 사고를 재분류합니다.

사고 분류

  • 카테고리 1 – 무단 접근

  • 카테고리 2 – 데이터 무결성 위반

  • 카테고리 3 – 서비스 중단 또는 성능 저하

  • 카테고리 4 – 잘못된 구성 또는 배포 오류

심각도 수준 및 SLA

These are operational response targets, not a statement of continuous staffing. Assess product-security reporting separately using Incident reporting; these targets do not extend reporting deadlines.

심각도

정의

목표 확인 시간

목표 초기 조치

긴급

전체 중단; 관리자 침해; 활발한 데이터 유출; 즉시 격리가 필요합니다.

< 30분

< 4시간

높음

핵심 기능 장애; 단일 사용자의 PII 유출.

< 2시간

12시간

중간

성능 저하; 사소한 보안 문제.

영업일 1일

영업일 3일

낮음

UI 버그; 스테이징 문제; 비보안 오류.

최선 노력

최선 노력

사고 대응 생명주기

준비

  • Weblate의 내장 백업 및 로테이션을 사용하여 PostgreSQL 데이터베이스와 데이터 디렉터리의 정기적인 일일 백업을 보장합니다. Weblate 백업 및 이전 을 참조하세요.

  • Weblate가 HTTPS (TLS 1.2+)를 사용하는 적절히 구성된 리버스 프록시 (예: NGINX)를 사용하는지 확인합니다.

  • 모든 관리자 수준 계정에 2FA를 활성화합니다.

  • Weblate 인스턴스와 종속성 (Python, Django, Celery, 데이터베이스 등)을 최신 상태로 유지합니다.

  • 감사 및 애플리케이션 로그 전달을 위해 GELF 프로토콜을 사용하여 SIEM 시스템과 통합합니다.

  • Complete the preparation checklist in Incident reporting and keep private contact and access details current.

식별

  • 시스템 및 애플리케이션 로그를 모니터링합니다 (journalctl, 리버스 프록시 로그, Weblate 애플리케이션 및 감사 로그).

  • 로그인 이벤트, 웹훅 실행 및 push/pull 실패를 분석합니다.

  • 다수의 로그인 실패, 예기치 않은 재시작 또는 비정상적인 VCS 동작에 대한 알림을 구성합니다 (Prometheus, Zabbix 또는 SIEM을 통해).

  • Record awareness times and assess authority and user notifications using Incident reporting, without waiting for a complete investigation.

  • Assess whether a security incident caused accidental or unlawful destruction, loss, or alteration of personal data, or unauthorized disclosure or access, and follow Personal-data breach notifications. This includes availability or integrity breaches without disclosure, such as accidental deletion or ransomware destruction. Seek privacy advice where needed while continuing investigation and reporting preparation.

Personal-data breach notifications

The incident handler determines whether Weblate acts as controller or processor for the affected processing and records the assessment in the private incident note. Under GDPR Article 33:

  • As controller, notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the personal-data breach, unless the breach is unlikely to result in a risk to individuals’ rights and freedoms. Record the reason for a decision not to notify.

  • If notification takes longer than 72 hours, include the reasons for the delay. Where information cannot be supplied together, provide it in stages without undue further delay.

  • As processor, notify the controller without undue delay after becoming aware of a personal-data breach; do not wait for the controller’s 72-hour deadline.

The controller’s supervisory-authority notification must include the following information under Article 33(3):

  • The nature of the breach, including, where possible, the categories and approximate numbers of affected individuals and personal-data records.

  • The name and contact details of the person who can provide further information, such as the incident handler or a data protection officer if one is appointed.

  • The likely consequences of the breach.

  • Measures taken or proposed to address the breach, including measures to reduce its adverse effects where appropriate.

Identify information that is not yet available and provide it in follow-up notifications without undue further delay. Do not wait for exact counts before notifying the authority.

As controller, separately assess communication to affected individuals under GDPR Article 34. If the breach is likely to create a high risk to their rights and freedoms, inform them without undue delay unless an Article 34(3) exception applies. This applies even without active exploitation or a severe product-security incident. Notification to the supervisory authority does not replace this communication.

Explain the breach in clear language, giving a contact for further information, likely consequences, measures taken or proposed, and actions individuals can take. Record the assessment and any exception relied on: effective protection of the affected data, such as encryption making it unreadable to unauthorized people, or subsequent measures ensuring the high risk is no longer likely. If individual communication would involve disproportionate effort, use public communication or a similar measure that informs individuals equally effectively. See the EDPB data-breach guidance.

Record breach-awareness timestamps, recipients, and deadlines separately from CRA reporting. A CRA submission does not replace a GDPR notification, and the two reporting clocks may start at different times.

격리

  • Maintain the private incident note from Incident reporting, including timeline updates, reporting deadlines, and submission receipts.

  • Signal 에서 인력 대응을 조율하고 기술적 알림은 기존 모니터링 시스템에 유지합니다.

  • 카테고리 1 또는 2 사고의 경우, 안전한 경우 파괴적 조치를 취하기 전에 수동 Hetzner 클라우드 스냅샷 을 생성합니다.

    • 이름 형식: IRP-[CaseID]-[YYYYMMDD]-Evidence.

    • 이것은 표준 순환 백업과 별개이며 분석을 위해 보존해야 합니다.

  • 필요에 따라 영향을 받은 호스트 또는 서비스를 격리합니다 (예: 방화벽 규칙 또는 서비스 격리를 통해).

  • 외부 연동 (Git/웹훅)이 공격 벡터의 일부인 경우 비활성화합니다.

  • 영향을 받은 사용자 계정을 즉시 중지합니다.

  • 해당하는 경우 영향을 받은 관리자, API, VCS 및 웹훅 자격 증명을 폐기하거나 교체합니다.

  • 시스템 로그, 리버스 프록시 로그, Weblate 애플리케이션 및 감사 로그, 영향을 받은 구성 상태, 영향을 받은 자격 증명 또는 연동 목록을 포함한 관련 증거를 보존합니다.

제거

  • 무단 코드 또는 데이터를 제거합니다.

  • Weblate 또는 서버 구성 요소를 업그레이드하여 알려진 취약점을 패치합니다.

  • SHA-256 체크섬 또는 Git 로그를 사용하여 바이너리 및 저장소 무결성을 검증합니다.

복구

  • 최근 알려진 정상 Weblate 백업에서 영향을 받은 서비스 또는 데이터를 복원합니다.

  • 단계적 접근 방식으로 서비스를 재도입합니다.

  • 정상 트래픽을 복원하기 전에 근본 원인이 제거되었거나 보상 제어가 마련되었는지 확인합니다.

  • 영향을 받은 자격 증명을 교체하고 복원된 시스템, 저장소 및 구성의 무결성을 확인합니다.

  • The handler records the decision to return to normal operations, checking recovery with the backup or another teammate where practical.

  • 복구 후 최소 72시간 동안 로그와 시스템 동작을 지속적으로 모니터링합니다.

사고 후 검토

  • Timeline: Hold a short team review within 5 business days of incident closure.

  • 전체 사고 타임라인과 취해진 조치를 작성합니다.

  • 근본 원인 분석 (RCA)을 수행하고 영업일 10일 이내에 문서화합니다.

  • 조사 결과를 기반으로 보안 정책과 IRP 문서를 업데이트합니다.

  • 탐지 및 격리 메커니즘의 효과를 검토합니다.

  • 에스컬레이션, 알림 및 외부 커뮤니케이션이 취약점 및 사고 처리 에 따라 예상대로 수행되었는지 확인합니다.

  • Check for outstanding reports, promised updates, and delayed disclosures before closing the incident note.