ແຜນການຕອບໂຕ້ອຸບັດຕິເຫດສຳລັບ Weblate

ຂອບເຂດ ແລະ ຈຸດປະສົງ

IRP ນີ້ກວມເອົາອຸບັດຕິເຫດທີ່ມີຜົນກະທົບຕໍ່ຄວາມລັບ, ຄວາມຖືກຕ້ອງສົມບູນ, ຫຼື ຄວາມພ້ອມໃຊ້ງານຂອງການຕິດຕັ້ງທີ່ດຳເນີນງານໂດຍ Weblate.

Note

ແຜນນີ້ຖືກອອກແບບມາໂດຍສະເພາະສຳລັບການຕິດຕັ້ງທີ່ດຳເນີນງານໂດຍ 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 ເພື່ອຫຼີກລ່ຽງສຽງລົບກວນ.

• ການສື່ສານພາຍນອກ:

  • ອີເມລ ຖືກໃຊ້ເພື່ອຕິດຕໍ່ລູກຄ້າ.

  • ລາຍຊື່ຕິດຕໍ່ລູກຄ້າຖືກເກັບຮັກສາໄວ້ໃນຫຼາຍສະຖານທີ່ເພື່ອຮັບປະກັນການເຂົ້າເຖິງໃນລະຫວ່າງທີ່ບໍລິການຢຸດສະງັກ.

• ການເປີດເຜີຍຕໍ່ສາທາລະນະ:

  • ຖ້າອຸບັດຕິເຫດລວມເຖິງຊ່ອງໂຫວ່ຂອງຜະລິດຕະພັນ Weblate, ໃຫ້ປະຕິບັດຕາມຂະບວນການລາຍງານຊ່ອງໂຫວ່ຂອງຜະລິດຕະພັນ ແລະ ນະໂຍບາຍການເປີດເຜີຍຊ່ອງໂຫວ່ ໃນ ການຈັດການຊ່ອງໂຫວ່ ແລະ ອຸບັດຕິເຫດ.

ປະເພດອຸບັດຕິເຫດ ແລະ ລະດັບຄວາມຮຸນແຮງ

ການເປີດໃຊ້ງານອຸບັດຕິເຫດ

• ປະກາດອຸບັດຕິເຫດເມື່ອເຫດການໃດໜຶ່ງໄດ້ຮັບການຢືນຢັນ ຫຼື ສົງໄສຢ່າງຍິ່ງວ່າມີຜົນກະທົບຕໍ່ຄວາມລັບ, ຄວາມຖືກຕ້ອງສົມບູນ, ຫຼື ຄວາມພ້ອມໃຊ້ງານຂອງບໍລິການນອກເໜືອຈາກສຽງລົບກວນໃນການເຮັດວຽກປະຈຳວັນ.

• 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 – ການຕັ້ງຄ່າຜິດພາດ ຫຼື ຂໍ້ຜິດພາດໃນການຕິດຕັ້ງ

ລະດັບຄວາມຮຸນແຮງ ແລະ SLAs

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; ບັນຫາສະເຕຈຈິງ; ຂໍ້ຜິດພາດທີ່ບໍ່ກ່ຽວກັບຄວາມປອດໄພ.	ສຸດຄວາມສາມາດ	ສຸດຄວາມສາມາດ

ວົງຈອນການຕອບໂຕ້ອຸບັດຕິເຫດ

ການກຽມພ້ອມ

• ຮັບປະກັນການສຳຮອງຂໍ້ມູນຖານຂໍ້ມູນ PostgreSQL ແລະ ໄດເຣັກທໍຣີຂໍ້ມູນເປັນປະຈຳທຸກວັນ ໂດຍໃຊ້ລະບົບສຳຮອງຂໍ້ມູນໃນຕົວຂອງ Weblate ພ້ອມການໝູນວຽນ, ເບິ່ງ ການສຳຮອງຂໍ້ມູນ ແລະການຍ້າຍ Weblate.

• ຮັບປະກັນວ່າ Weblate ໃຊ້ Reverse Proxy (ເຊັ່ນ: NGINX) ທີ່ຕັ້ງຄ່າຢ່າງຖືກຕ້ອງພ້ອມ HTTPS (TLS 1.2+).

• ເປີດໃຊ້ 2FA ສຳລັບບັນຊີລະດັບແອດມິນທັງໝົດ.

• ຮັກສາ Weblate instance ແລະ ບັນດາ Dependencies ຂອງມັນ (Python, Django, Celery, ຖານຂໍ້ມູນ, ແລະ ອື່ນໆ) ໃຫ້ທັນສະໄໝຢູ່ສະເໝີ.

• ເຊື່ອມຕໍ່ກັບລະບົບ SIEM ໂດຍໃຊ້ໂປຣໂຕຄໍ GELF ສຳລັບການສົ່ງ Log ການກວດສອບ ແລະ Log ຂອງແອັບພລິເຄຊັນ.

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

ການລະບຸຕົວຕົນ

• ຕິດຕາມກວດສອບ Log ຂອງລະບົບ ແລະ ແອັບພລິເຄຊັນ (journalctl, Log ຂອງ reverse proxy, Log ຂອງແອັບພລິເຄຊັນ ແລະ ການກວດສອບຂອງ Weblate).

• ວິເຄາະເຫດການການເຂົ້າສູ່ລະບົບ, ການປະມວນຜົນ webhook, ແລະ ຄວາມຜິດພາດໃນການ push/pull.

• ຕັ້ງຄ່າການແຈ້ງເຕືອນ (ຜ່ານ Prometheus, Zabbix, ຫຼື SIEM) ສຳລັບການເຂົ້າສູ່ລະບົບລົ້ມເຫຼວຫຼາຍຄັ້ງ, ການຣີສະຕາດແບບບໍ່ຄາດຄິດ, ຫຼື ການເຄື່ອນໄຫວ VCS ທີ່ຜິດປົກກະຕິ.

• 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 Cloud Snapshot ດ້ວຍຕົນເອງກ່ອນທີ່ຈະດຳເນີນການທີ່ມີຜົນກະທົບ ເມື່ອສາມາດເຮັດໄດ້ຢ່າງປອດໄພ.

  • ຮູບແບບຊື່: IRP-[CaseID]-[YYYYMMDD]-Evidence.

  • ສິ່ງເຫຼົ່ານີ້ແຍກຕ່າງຫາກຈາກການສຳຮອງຂໍ້ມູນແບບໝູນວຽນມາດຕະຖານ ແລະ ຕ້ອງໄດ້ຮັບການຮັກສາໄວ້ເພື່ອການວິເຄາະ.

• ແຍກໂຮສ ຫຼື ບໍລິການທີ່ໄດ້ຮັບຜົນກະທົບອອກຕາມຄວາມຈຳເປັນ (ຕົວຢ່າງໂດຍກົດລະບຽບ Firewall ຫຼື ການແຍກບໍລິການ).

• ປິດການເຊື່ອມຕໍ່ພາຍນອກ (Git/webhooks) ຖ້າມັນເປັນສ່ວນໜຶ່ງຂອງຊ່ອງທາງການໂຈມຕີ.

• ລະງັບບັນຊີຜູ້ໃຊ້ທີ່ໄດ້ຮັບຜົນກະທົບທັນທີ.

• ຍົກເລີກ ຫຼື ປ່ຽນແປງຂໍ້ມູນຢືນຢັນຕົວຕົນ (credentials) ຂອງແອດມິນ, API, VCS, ແລະ webhook ທີ່ໄດ້ຮັບຜົນກະທົບຕາມຄວາມເໝາະສົມ.

• ຮັກສາຫຼັກຖານທີ່ກ່ຽວຂ້ອງ, ລວມເຖິງ Log ຂອງລະບົບ, Log ຂອງ reverse proxy, Log ຂອງແອັບພລິເຄຊັນ ແລະ ການກວດສອບຂອງ Weblate, ສະຖານະການຕັ້ງຄ່າທີ່ໄດ້ຮັບຜົນກະທົບ, ແລະ ລາຍຊື່ credentials ຫຼື ການເຊື່ອມຕໍ່ທີ່ໄດ້ຮັບຜົນກະທົບ.

ການກຳຈັດ

• ລຶບລະຫັດ ຫຼື ຂໍ້ມູນທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດອອກ.

• ແກ້ໄຂຊ່ອງໂຫວ່ທີ່ຮູ້ຈັກໂດຍການອັບເກຣດ Weblate ຫຼື ສ່ວນປະກອບຂອງເຊີບເວີ.

• ກວດສອບຄວາມຖືກຕ້ອງສົມບູນຂອງ Binary ແລະ Repository ໂດຍໃຊ້ SHA-256 checksums ຫຼື Git logs.

ການກູ້ຄືນ

• ກູ້ຄືນບໍລິການ ຫຼື ຂໍ້ມູນທີ່ໄດ້ຮັບຜົນກະທົບຈາກຂໍ້ມູນສຳຮອງຂອງ Weblate ທີ່ດີຄັ້ງຫຼ້າສຸດ.

• ນຳບໍລິການກັບມາໃຊ້ງານໃໝ່ໂດຍແບ່ງເປັນໄລຍະ.

• ຢືນຢັນວ່າສາເຫດຕົ້ນຕໍໄດ້ຖືກກຳຈັດອອກ ຫຼື ມີການຄວບຄຸມຊົດເຊີຍແລ້ວກ່ອນທີ່ຈະຟື້ນຟູການຈະລາຈອນປົກກະຕິ.

• ປ່ຽນແປງ credentials ທີ່ໄດ້ຮັບຜົນກະທົບ ແລະ ກວດສອບຄວາມຖືກຕ້ອງສົມບູນຂອງລະບົບ, repositories, ແລະ ການຕັ້ງຄ່າທີ່ກູ້ຄືນມາ.

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

• ຕິດຕາມ Log ແລະ ພຶດຕິກຳຂອງລະບົບຢ່າງຕໍ່ເນື່ອງຢ່າງໜ້ອຍ 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.