Olay Müdahale Planı

Yürürlük: 2 Haziran 2026

Bu Olay Müdahale Planı ("Plan"), STANDOUT Inc.'in ("biz") VATES hizmetini ("Hizmet") etkileyen güvenlik olaylarını, hizmet kesintilerini ve veri ihlallerini nasıl tespit ettiğini, bunlara nasıl müdahale ettiğini, bunlardan nasıl kurtulduğunu ve bunlardan nasıl ders çıkardığını tanımlar. Plan, NIST SP 800-61 Rev.2 ve ISO/IEC 27035'e atıfta bulunur ve otomatik izleme araçlarının tespitin ön saflarında yer aldığı tasarım ilkesi üzerine kurulmuştur.

1. Amaç ve Kapsam

Bu Plan'ın hedefleri şunlardır:

• Hizmet'in kullanılabilirliğini, gizliliğini veya bütünlüğünü etkileyebilecek olayları zamanında tespit etmek.
• Etkiyi en aza indiren kontrol altına alma ve kurtarma prosedürlerini tanımlamak.
• Etkilenen Müşterilere ve düzenleyici otoritelere yönelik bildirim yükümlülüklerine uymak.
• Yapılandırılmış olay sonrası analiz yoluyla operasyonel kalitenin sürekli iyileştirilmesini sağlamak.

Bu Plan, Hizmet'in üretim ortamına (EC2, Cloudflare ve ilgili SaaS sağlayıcıları), Hizmet'ten üst düzey AI sağlayıcılarına giden iletişim yoluna ve Müşteri verilerini tutan tüm depolamaya uygulanır.

2. Olay Tanımı ve Önem Sınıflandırması

2.1 Bir Olayın Tanımı

Bu Plan'ın amaçları doğrultusunda, bir olay, aşağıdakilerden bir veya daha fazlasıyla eşleşen herhangi bir olaydır:

• Şüpheli yetkisiz erişim, kimlik bilgisi ele geçirme veya sistem sızması.
• Kişisel veriler dahil olmak üzere Müşteri verilerinin yetkisiz ifşası, değiştirilmesi veya kaybı.
• Hizmet'in temel işlevselliğini etkileyen kesinti veya önemli performans düşüşü.
• Kötü amaçlı yazılım bulaşması, fidye yazılımı veya tedarik zinciri saldırıları dahil güvenlik tehditleri.
• Büyük ölçekli etkiyle sonuçlanan operasyonel hata, hatalı yapılandırma veya yazılım kusuru.

2.2 Önem Sınıflandırması

Her olay, tespit anında aşağıdaki önem düzeylerinden birine sınıflandırılır:

• P1 (Kritik): Toplam Hizmet kesintisi veya kişisel verileri içeren doğrulanmış veri ihlali. Anında müdahale gerektirir.
• P2 (Yüksek): Temel işlevselliğin önemli ölçüde bozulması, belirli Müşteriler için kullanılamama veya kimlik doğrulama anormallikleri. İlk müdahale bir saat içinde gereklidir.
• P3 (Orta): Kısmi işlevsel bozulma veya geçici çözümleri bulunan performans düşüşü. Mesai saatleri içinde müdahale kabul edilebilir.
• P4 (Düşük): Sınırlı kullanıcı etkisi olan olaylar, küçük log bütünlüğü kayması veya izleme araçlarının azalan yedekliliği. Bir sonraki planlı gözden geçirme döngüsünde ele alınır.

3. Müdahale Yapısı

3.1 Sorumlu Taraf

Bu Plan için sorumlu taraf, STANDOUT Inc.'in Managing Director'ı ve VATES geliştirmesinin başı olan Takuya Aoki'dir. Bir olay sırasında tüm karar verme yetkisi ve harici bildirim yetkisi, sorumlu tarafta toplanır.

3.2 Otomatik Tespit Araçları

Hizmet, aşağıdaki araçlardan oluşan, tamamen otomatik bir sürekli izleme duruşu işletir. Bunlar, sorumlu taraftan bağımsız olarak çalışır ve eşik koşulları karşılandığında anında bildirimi tetikler.

• Cloudflare Health Check: Üretim origin'ini birden fazla coğrafi noktadan 60 saniyelik aralıklarla yoklar.
• HetrixTools: Üretim uç noktalarını, Cloudflare'den bağımsız bir yol üzerinden birden fazla küresel noktadan izler.
• Sentry: Uygulama istisnalarını gerçek zamanlı olarak yakalar ve sorumlu tarafı bilgilendirir.
• Cloudflare WAF (Managed Rules + OWASP Core Ruleset): Bilinen saldırı desenlerini Block modunda engeller.
• Cloudflare DDoS Protection: DDoS saldırılarını ağ katmanında, SSL/TLS katmanında ve HTTP katmanında sürekli ve otomatik olarak hafifletir.
• Anomali Tespiti Toplu İşi (systemd timer): Denetim loglarını her beş dakikada bir tarar ve üç kategoriyi tespit eder: yüksek istek oranı, yüksek yetkilendirme reddi oranı ve kaba kuvvet denemeleri.
• Hız Sınırlama: Kullanım uç noktalarında tenant başına istek hız sınırlama ve kimlik doğrulama uç noktalarında IP tabanlı hız sınırlama; fazla trafiği otomatik olarak reddeder.
• Yapılandırılabilir Güvenlik Uyarıları: Müşteriler, hangi operasyonel olayların (düşük bakiye, yeni bir konumdan giriş, engellenen erişim, tekrarlanan giriş başarısızlıkları) e-posta bildirimlerini tetikleyeceğini, olay başına hassasiyet eşikleriyle seçebilir.
• Denetim Logu Altyapısı: Her API çağrısını hash zincirli, kurcalamayı belli eden bir denetim logunda (SHA-256, tenant başına sıra) kaydeder ve girdileri bağımsız doğrulama için birleştirir.
• Durum Panosu (9 sağlık pill'i): Denetim, anomali, GeoIP, yedekleme, silme toplu işi, katalog kapsamı, mutabakat kayması, killswitch ve hizmet sağlığını tek bir ekranda görselleştirir.
• Otomatik Yedekleme: SQLite anlık görüntülerini GPG AES-256 ile şifreler ve 30 günlük nesli saklar.

3.3 Ön Saf Müdahalenin Otomasyona Devri

Tespit ve triyaj aşamaları, ön saf olarak yukarıdaki otomatik araçlar tarafından yürütülür. Sorumlu taraf, yalnızca eşiği aşan bildirimleri aldığında müdahale eder. Bu tasarım, 7/24 tespit kapsamının, sorumlu tarafın konumuna veya müsaitliğine bağlı olmaksızın fiziksel olarak kurulmasını sağlar.

4. Müdahale Süreci

4.1 Tespit

Bölüm 3.2'de açıklanan otomatik araçlardan bir veya daha fazlası bir anormallik tespit ettiğinde, sorumlu taraf Sentry, e-posta ve pano uyarıları aracılığıyla anında bilgilendirilir. Müşteri raporları [email protected] adresinden alınır ve aynı akışta biletlenir.

4.2 Triyaj

Bir bildirim alındığında, sorumlu taraf şunları inceleyerek önemi doğrular:

• Etki kapsamı (tüm Müşteriler / belirli Müşteri / bireysel Instance).
• Kişisel verilerin, kimlik doğrulama bilgilerinin veya faturalandırma bilgilerinin etkilenip etkilenmediği.
• Harici faktörlerin katılımı (üst düzey AI sağlayıcı kesintileri, Cloudflare kesintileri, AWS kesintileri).
• Bilinen saldırı desenleriyle korelasyon (WAF logları, anomali tespiti sonuçları, GeoIP uyarıları).

4.3 Kontrol Altına Alma

Öneme bağlı olarak, aşağıdaki kontrol altına alma önlemlerinden bir veya daha fazlası uygulanır:

• Anında izolasyon için etkilenen Instance'ların state machine aracılığıyla askıya alınması.
• Kaynak IP adreslerinin bir deny list'e eklenmesi (Müşteri başına veya genel).
• JWT jti ile toplu oturum iptali.
• killswitch'in etkinleştirilmesi (tam trafik durdurma, son çare önlemi).
• L7 saldırılarına karşı Cloudflare "Under Attack Mode"un etkinleştirilmesi.

4.4 Kurtarma

Kontrol altına alma sonrasında, kök nedenler ortadan kaldırılır ve aşağıdakiler gerçekleştirilir:

• Gerektiğinde yedekten geri yükleme (prosedürler docs/RESTORE.md içinde belgelenmiştir).
• Etkilenen kimlik bilgilerinin döndürülmesi (API anahtarları, JWT secret'ları, yedekleme şifreleme anahtarları vb.).
• Üretime yamaların, yapılandırma düzeltmelerinin ve kod düzeltmelerinin uygulanması.
• Staging ve üretim ortamlarında doğrulama.
• İzleme araçları aracılığıyla en az 24 saat sürekli gözlem.

4.5 Olay Sonrası

Kurtarma doğrulandıktan sonra, sorumlu taraf:

• Zaman çizelgesini, kök nedeni, etki kapsamını ve müdahale eylemlerini belgeler.
• Önleyici önlemleri belirler ve uygulama yol haritasına dahil eder.
• Uygun olduğunda, etkilenen Müşterileri ve düzenleyici otoriteleri bilgilendirir (bkz. Bölüm 5).
• İyileştirmeleri bu Plan'a ve ilgili operasyonel belgelere geri besler.

5. Müşteri ve Düzenleyici Bildirimi

5.1 Kişisel Veri İhlali Bildirimi

Kişisel verilerin yetkisiz olarak ele geçirilmesi, kaybı veya ifşası doğrulanırsa, aşağıdakiler uyarınca bildirimde bulunuruz:

• AB Genel Veri Koruma Tüzüğü (GDPR) 33. Madde: Farkına varılmasından itibaren 72 saat içinde denetim otoritesine bildirim.
• GDPR 34. Madde: Yüksek risk belirlendiğinde, etkilenen veri sahiplerine gereksiz gecikme olmaksızın bildirim.
• Kişisel Bilgilerin Korunması Kanunu (Japonya): Geçerli kabine kararnameleri ve kuralları uyarınca Kişisel Bilgileri Koruma Komisyonu'na raporlama ve veri sahiplerine bildirim.
• Diğer Geçerli Yargı Bölgeleri: Geçerli ulusal veya bölgesel veri koruma yasalarının gerektirdiği bildirimler.

5.2 Hizmet Kesintisi Bildirimi

P1 veya P2 olarak sınıflandırılan hizmet kesintileri için, beklenen kurtarma zaman çizelgesi ve varsa geçici hafifletmeler dahil olmak üzere, etkilenen Müşterileri gereksiz gecikme olmaksızın bilgilendiririz. Bildirim kanalları [email protected] ve Hizmet yönetim konsoludur.

5.3 Bildirim Yöntemi

Bildirimler öncelikle Müşteri'nin kayıtlı adresine e-posta ile, gerektiğinde yönetim konsolundaki banner'larla desteklenerek iletilir.

6. Post-Mortem ve Öğrenme Döngüsü

Bir P1 veya P2 olayının ardından, sorumlu taraf bir Post-Mortem gerçekleştirir ve aşağıdaki öğeleri belgeler. Belge dahili olarak saklanır ve talep üzerine Müşterilere ve denetçilere açıklanır.

• Tespitten kurtarmaya kadar olayların zaman çizelgesi.
• Kök neden analizi (teknik ve operasyonel faktörler).
• Nicelleştirilmiş etki kapsamı.
• Müdahale sürecinin değerlendirilmesi.
• Önleyici önlemler ve hedef son tarihler.

Post-Mortem'ler, bireysel hesap verebilirlik yerine yapısal iyileştirmeye odaklanan Blameless Post-Mortem olarak yürütülür.

7. Plan Bakımı ve Gözden Geçirme

7.1 Periyodik Gözden Geçirme

Bu Plan, en az yılda bir kez ve ayrıca herhangi bir önemli olaydan sonra, Hizmet mimarisinde önemli değişiklikler olduğunda ve geçerli yasa ve düzenlemelerde değişiklikler olduğunda gözden geçirilir.

7.2 Revizyon Geçmişi

Bu Plan'ın revizyon geçmişi dahili olarak tutulur ve talep üzerine Müşterilere ve denetçilere açıklanır.

8. İletişim

Bir olayı bildirmek veya bu Plan hakkında sorular iletmek için:

STANDOUT Inc.
E-posta: [email protected]

Son güncelleme: 2 Haziran 2026