Weblate için olaylara müdahale planı

Kapsam ve hedefler

Bu olaylara müdahale planı, bir Weblate ile işletilen dağıtımların gizliliğini, bütünlüğünü veya kullanılabilirliğini etkileyen olayları kapsar.

Not

Plan özellikle Weblate s.r.o. tarafından yapılmış dağıtımlar için tasarlanmıştır. Diğer dağıtımların, sağlayıcıya özel ve kuruluşa uygun adımları kendi ortamlarına uyarlaması gerekir.

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.

İletişim lojistiği

• İç iletişim:

  • İnsandan insana koordinasyon için birinci kanal olarak Signal kullanılır.

  • Gürültüyü önlemek için teknik uyarılar Signal üzerinden gönderilmez.

• Dış iletişim

  • Müşterilere ulaşmak için e-posta kullanılır.

  • Müşteri iletişim listeleri, hizmet kesintileri sırasında erişimi sağlamak için çeşitli konumlarda tutulur.

• Herkese açık duyurular

  • If an incident includes a Weblate product vulnerability, follow the product vulnerability reporting process and Güvenlik açığını açıklama ilkesi in Güvenlik açığı ve olay yönetimi.

Olay kategorileri ve önem düzeyi

Olay etkinliği

• Bir olayı, doğrulandığında veya rutin operasyonel gürültünün ötesinde hizmetin gizliliğini, bütünlüğünü veya kullanılabilirliğini etkilediğinden şüphelendiğinizde duyurun.

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

• Soruşturma sırasında kapsam veya etki değişirse olayı yeniden sınıflandırın.

Olay kategorileri

• Category 1 – Unauthorized Access

• Category 2 – Data Integrity Violation

• Category 3 – Service Outage or Degradation

• Category 4 – Misconfiguration or Deployment Error

Önem düzeyleri ve hizmet düzeyi anlaşmaları

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.

Önem düzeyi	Tanım	Hedefin kabul edilmesi	İlk hedef işlemi
Kritik	Toplam kesinti; Yöneticinin ele geçirilmesi; Etkin verilerin ele geçirilmesi; acil sınırlama gerekir.	< 30 dakika	< 4 saat
Yüksek	Çekirdek özellik sorunu; tek kullanıcının PII sızıntısı.	< 2 saat	12 saat
Orta	Başarımda düşme; küçük güvenlik sorunu.	1 iş günü	3 iş günü
Düşük	Kullanıcı arayüzü sorunları; deneme sorunları; güvenlik dışı sorunlar.	En iyi çaba	En iyi çaba

Olaylara müdahale yaşam döngüsü

Hazırlık

• PostgreSQL veri tabanının ve veri klasörünün düzenli olarak günlük yedeklerinin Weblate içindeki çevrimli yedekleme ile alınmasını sağlayın. Ayrıntılı bilgi almak için: Weblate yedeğini alma ve taşıma.

• Weblate tarafından doğru yapılandırılmış bir ters vekil sunucu (NGINX gibi) ve HTTPS (TLS 1.2+) kullanıldığından emin olun.

• Yönetici düzeyindeki hesaplar için iki adımlı doğrulamayı açın.

• Weblate kopyasını ve bağımlılıklarını (Python, Django, Celery, veri tabanı gibi) güncel tutun.

• Denetim ve uygulama günlüğü iletimi için GELF iletişim kuralını kullanarak SIEM sistemleriyle bütünleştirin.

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

Belirleme

• Sistem ve uygulama günlüklerini izleyin (journalctl, ters vekil sunucu günlükleri, Weblate uygulama ve denetim günlükleri).

• Oturum açma olaylarını, internet kancası yürütülmelerini ve itme/çekme hatalarını inceleyin.

• Şu uyarıları yapılandırın (Prometheus, Zabbix veya SIEM gibi): Birden fazla oturum açılması, beklenmeyen yeniden başlatmalar veya düzensiz sürüm denetimi sistemi işlemleri.

• 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.

Sınırlama

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

• Signal üzerinden insan tepkilerini koordine edin ve var olan izleme sistemlerinde teknik uyarı yapmayı sürdürün.

• For Category 1 or 2 incidents, create a manual Hetzner Cloud Snapshot before taking disruptive action when it is safe to do so.

  • Ad biçimi: IRP-[CaseID]-[YYYYMMDD]-Evidence.

  • Bunlar standart dönen yedeklemelerden ayrıdır ve inceleme için saklanmalıdır.

• Gerekiyorsa etkilenen sunucu ya da hizmete erişimi engelleyin (örneğin, güvenlik duvarı kuralları veya hizmet yalıtımı ile).

• Saldırı vektörünün bir parçasıysa dış bütünleştirmeleri (Git/webhooks) kapatın.

• Etkilenen kullanıcı hesaplarını derhal askıya alın.

• Etkilenen yönetim, API, VCS ve internet kancası kimlik doğrulama bilgilerini yapılabildiği şekilde iptal edin veya değiştirin.

• Sistem günlükleri, ters vekil sunucu günlükleri, Weblate uygulama ve denetim günlükleri, etkilenen yapılandırma durumu ve etkilenen kimlik doğrulama bilgilerinin veya bütünleştirmelerin listesi ile ilgili kanıtları koruyun.

Ortadan kaldırma

• Olmaması gereken izinsiz kod veya verileri kaldırın.

• Weblate veya sunucu bileşenlerini yükselterek bilinen güvenlik açıklarını kapatın.

• SHA-256 sağlama toplamlarını veya Git günlüklerini kullanarak binary dosyaların ve deponun bütünlüğünü doğrulayın.

Kurtarma

• Etkilenen hizmetleri veya verileri bilinen son iyi Weblate yedeklerinden geri yükleyin.

• Aşamalı bir yaklaşımla hizmetleri yeniden sunun.

• Normal trafiğe geri dönmeden önce temel nedenin kaldırıldığını veya telafi edici bir önlemin alındığını doğrulayın.

• Etkilenen kimlik doğrulama bilgilerini değiştirin ve geri yüklenen sistemin, depoların ve yapılandırmanın bütünlüğünü doğrulayın.

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

• Kurtarma sonrası en az 72 saat boyunca günlükleri ve sistem davranışını sürekli olarak izleyin.

Olay sonrası değerlendirme

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

• Tam bir olay zaman çizelgesi hazırlayın ve alınan önlemleri ekleyin.

• Kök neden analizi (RCS) yapın ve 10 iş günü içinde belgeleyin.

• Bulgulara göre güvenlik ilkesi ve olaylara müdahale planı belgelerini güncelleyin.

• Algılama ve kontrol altına alma yapılarının etkinliğini değerlendirin.

• Yönlendirme, uyarı ve dış iletişimin Güvenlik açığı ve olay yönetimi olması gerektiği gibi uygulanıp uygulanmadığını doğrulayın.

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