ShamashAi Push Abonelik Paneli: Ayrılan Çalışanın Cihazı Nasıl İptal Edilir

Pazartesi 09:42: Ayrılan Çalışanın Telefonu Hâlâ Alarm Alıyor

Bir üretim firmasının IT yöneticisi Pazartesi sabahı garip bir durum fark ediyor: iki hafta önce ayrılan Ahmet'in kişisel telefonuna hâlâ ShamashAi'dan kritik alarmlar gidiyor. Cuma akşamı firewall'da tespit edilen BRUTE_FORCE_DETECTED olayı için bildirim gönderilmiş, ama Ahmet artık şirkette çalışmıyor. Yönetici alarm paneline bakıyor — sistemde Ahmet'in kullanıcı hesabı zaten kapatılmış, Active Directory'den silinmiş. Ama Ahmet'in mobil cihazı hâlâ push aboneliği listesinde duruyor çünkü push token'lar kullanıcı hesaplarından bağımsız olarak ShamashAi veritabanında tutuluyor.

Bu durum hem KVKK uyumluluk riski hem operasyonel güvenlik açığı yaratıyor. Kişisel verilerin şirket sistemlerinde tutulması Madde 12 kapsamında hukuki sorumluluk getiriyor; ayrıca eski çalışanın dahili güvenlik olaylarından haberdar olması sızıntı riski anlamına geliyor. Geleneksel yöntemle yönetici ShamashAi'ın API dokümantasyonuna bakıp manuel SQL sorgusu yazmak veya destek çağrısı açmak zorunda kalıyordu. ShamashAi'nin Push Abonelik Yönetim Paneli bu senaryoyu çözmek için tasarlandı: Settings → Notification Policy sayfasındaki "Subscribed Devices" bölümü tüm aktif push endpoint'lerini label, kullanıcı cihaz bilgisi, son push zamanı ve istatistiklerle birlikte listeler; admin tek tıkla iptal eder, işlem dbo.audit_log tablosuna kaydedilir.

Push Abonelikleri Neden Görünmez?

ShamashAi mobil uygulaması ilk açıldığında cihaz Firebase Cloud Messaging (FCM) veya Apple Push Notification Service (APNs) üzerinden bir push token alır ve bunu POST /push/subscribe endpoint'ine gönderir. Bu token kullanıcı hesabına değil, cihaz kimliği + uygulama instance'ına bağlıdır. Yani:

• Kullanıcı Active Directory'den silinse bile push token ShamashAi veritabanında (dbo.push_subscriptions tablosunda) aktif kalır.
• Birden fazla çalışan aynı cihazı kullanıyorsa (örneğin nöbet telefonu) tek bir token birden fazla kişiye ait olayları alabilir.
• Çalışan şirket telefonunu geri verip kişisel telefonuna geçerse eski token unutulur, yeni token oluşur — toplamda iki abone.

Geleneksel SIEM sistemlerinde push abonelikleri genellikle kullanıcı profili altında gizlidir veya hiç arayüz sunmaz; yönetici sadece kendi cihazını yönetebilir. ShamashAi'nin admin paneli ise proje seviyesinde tüm abonelikleri tek bir sayfada toplar.

Subscribed Devices Paneli: Tüm Endpoint'ler Tek Ekranda

Settings → Notification Policy sayfasının altındaki "Subscribed Devices" bölümü şu bilgileri gösterir:

GET /push/subscriptions

Bu endpoint proje seviyesinde tüm aktif push aboneliklerini döndürür. Örnek yanıt yapısı:

{ "subscriptions": [ { "id": "sub_8a3f21", "label": "Ahmet - iPhone 13 Pro", "user_agent": "ShamashAi-iOS/2.4.1 (iPhone14,2; iOS 16.5)", "min_severity": "HIGH", "created_at": "2026-09-14T08:22:11Z", "last_push_at": "2026-11-01T19:47:33Z", "push_count": 142, "push_failed": 0, "subscribed_event_types": ["BRUTE_FORCE_DETECTED", "M365_RISKY_SIGNIN", "BACKUP_FAILED"] }, { "id": "sub_9c21b7", "label": "Mehmet - Samsung Galaxy S23", "user_agent": "ShamashAi-Android/2.3.8 (SM-S911B; Android 13)", "min_severity": "MEDIUM", "created_at": "2026-10-28T14:11:02Z", "last_push_at": "2026-11-02T07:03:21Z", "push_count": 37, "push_failed": 2, "subscribed_event_types": ["AUTH_FAIL_USER", "CERT_EXPIRING"] } ], "total": 2 }

Panelde her satır bir cihazı temsil eder:

• Label: Kullanıcı uygulamadan abone olurken "iPhone - Ahmet" gibi özel isim verebilir; verilmezse user_agent string'inden otomatik üretilir.
• User Agent: Cihaz modeli ve işletim sistemi bilgisi. IT yöneticisi "iPhone 13 Pro" görünce hangi cihaz olduğunu anlar.
• Min Severity: Kullanıcı hangi kritiklik seviyesi üzerindeki olayları almak istiyor (LOW, MEDIUM, HIGH, CRITICAL).
• Subscribed Event Types: Kullanıcı sadece belirli event type'lara abone olabilir (örneğin sadece BRUTE_FORCE_DETECTED ve BACKUP_FAILED).
• Last Push At: Son bildirimin gönderildiği zaman. Eğer iki hafta önce ayrılan Ahmet'in cihazı hâlâ dün bildirim aldıysa bu sütun 2026-11-01T19:47:33Z gösterir.
• Push Count / Failed: Toplam kaç bildirim gönderildi, kaçı başarısız oldu. push_failed > 0 ise cihaz ulaşılamıyor olabilir (uygulama silinmiş, token expire olmuş).

Yönetici bu listede "Ahmet - iPhone 13 Pro" satırını görür, last_push_at son iki gün içinde olduğunu fark eder ve anlar ki eski çalışan hâlâ alarm alıyor.

Tek Tıkla İptal: DELETE /push/subscriptions/:id

Yönetici satırın sağındaki "Unsubscribe" butonuna tıklar. ShamashAi web arayüzü şu isteği gönderir:

DELETE /push/subscriptions/sub_8a3f21 Authorization: Bearer {admin_jwt}

Backend (Node.js Fastify) şu adımları yürütür:

javascript // routes/push.js - ShamashAi API fastify.delete('/push/subscriptions/:id', { preHandler: [fastify.authenticate, fastify.requireRole('admin')], schema: { params: { type: 'object', required: ['id'], properties: { id: { type: 'string' } } } } }, async (request, reply) => { const { id } = request.params; const adminUser = request.user.email;

// 1. Abonelik kaydını bul const sub = await fastify.db.query( 'SELECT label, user_agent FROM dbo.push_subscriptions WHERE id = @id', { id } ); if (!sub.recordset[0]) { return reply.code(404).send({ error: 'Subscription not found' }); }

// 2. Kaydı sil await fastify.db.query( 'DELETE FROM dbo.push_subscriptions WHERE id = @id', { id } );

// 3. Audit log'a kaydet await fastify.db.query(` INSERT INTO dbo.audit_log (action, actor, target, metadata, timestamp) VALUES (@action, @actor, @target, @metadata, GETUTCDATE()) `, { action: 'push.unsubscribe', actor: adminUser, target: id, metadata: JSON.stringify({ label: sub.recordset[0].label, user_agent: sub.recordset[0].user_agent, reason: 'admin_revoke' }) });

reply.send({ success: true }); });

İşlem tamamlandığında:

1. dbo.push_subscriptions tablosundan kayıt silinir. 2. dbo.audit_log tablosuna push.unsubscribe action'ı kaydedilir; hangi admin, hangi cihazı, ne zaman iptal ettiği görünür. 3. Bir sonraki alarm geldiğinde backend bu token'a bildirim göndermez (token listede yok).

KVKK Madde 12: Çalışan Ayrılınca Abonelik Silme Zorunluluğu

KVKK Madde 12 "kişisel verilerin işlenme şartları ortadan kalktığında silinmesi" hükmünü getirir. Çalışan ayrıldığında:

• Active Directory hesabı kapatılır → ama push token bağımsız bir kaynaktır.
• Cihazda ShamashAi uygulaması kalıyorsa token aktif kalır, yeni alarmlar eski çalışanın telefonuna düşer.
• KVKK denetiminde "ayrılan çalışan verilerini ne kadar sürede siliyorsunuz?" sorusu sorulur; push abonelikleri bu kapsamdadır.

ShamashAi'nin audit log kaydı ISO 27001:2022 Annex A.8.15 (Logging) ve KVKK uyumluluk kanıtı olarak kullanılabilir:

sql SELECT action, actor, target, metadata, timestamp FROM dbo.audit_log WHERE action = 'push.unsubscribe' AND timestamp >= '2026-10-01' ORDER BY timestamp DESC;

Bu sorgu son bir aydaki tüm iptal işlemlerini gösterir; denetçiye "çalışan ayrılınca 48 saat içinde push aboneliğini iptal ediyoruz" politikasını kanıtlamak için kullanılır.

Toplu İptal: Birden Fazla Cihazı Temizleme

Bazı senaryolarda yönetici birden fazla cihazı iptal etmek isteyebilir:

• Şirket 20 kişilik bir departmanı kapatıyor, tüm çalışanların cihazlarını tek seferde temizlemek gerekiyor.
• Pilot test sırasında 10 test cihazı kaydedilmiş, production'a geçerken hepsini silmek gerekiyor.
• push_failed sayısı yüksek olan (örneğin > 5) cihazlar artık ulaşılamıyor, liste temizlenmeli.

ShamashAi dokümantasyonu şu an toplu silme endpoint'i sunmuyor; bu özellik roadmap'te. Geçici çözüm olarak IT yöneticisi aşağıdaki SQL script'ini SQL Server Management Studio'dan çalıştırabilir:

sql -- push_failed > 5 olan tüm abonelikleri sil DELETE FROM dbo.push_subscriptions WHERE push_failed > 5;

-- Audit log'a toplu silme kaydı ekle INSERT INTO dbo.audit_log (action, actor, target, metadata, timestamp) VALUES ( 'push.bulk_unsubscribe', 'admin@example.com', 'multiple', '{"filter": "push_failed > 5", "deleted_count": 12}', GETUTCDATE() );

Ancak bu manuel müdahale audit log'u otomatik olarak doldurmaz (yukarıdaki INSERT script'i manuel eklenir); gelecek sürümlerde web arayüzünde "Select All" + "Bulk Unsubscribe" butonu planlanıyor.

Min Severity ve Event Type Filtrelerini Admin Tarafından Düzenleme

Şu anki ShamashAi sürümünde admin, mevcut bir aboneliğin min_severity veya subscribed_event_types ayarlarını web panelinden değiştiremiyor. Kullanıcı bu ayarları sadece mobil uygulamadan (Settings → Notifications) düzenleyebilir. Yönetici sadece:

1. Mevcut ayarları görüntüleyebilir (GET /push/subscriptions). 2. Aboneliği tamamen iptal edebilir (DELETE /push/subscriptions/:id).

Örnek senaryo: Yönetici, bir çalışanın min_severity: LOW ayarıyla çok fazla bildirim aldığını görüyor ve bunu HIGH yapmak istiyor. Şu an için yapabileceği:

• Çalışandan mobil uygulamadan değiştirmesini istemek.
• Veya aboneliği iptal edip çalışandan yeniden abone olmasını istemek (bu durumda push_count sıfırlanır).

Admin tarafından düzenleme özelliği (PATCH /push/subscriptions/:id) roadmap'te ancak release tarihi belirlenmedi. Pilot programı kapsamında bu ihtiyaç varsa özel geliştirme olarak tartışılabilir.

Push Count ve Failed İstatistikleri: Sorunlu Cihazları Tespit Etme

push_count ve push_failed metrikleri operasyonel sağlık göstergesi olarak kullanılır:

• push_failed = 0: Cihaz sağlıklı, tüm bildirimler ulaşıyor.
• push_failed > 0 ve push_failed / push_count < 0.1: Geçici ağ sorunları, kabul edilebilir.
• push_failed / push_count > 0.3: Cihaz büyük olasılıkla artık ulaşılamıyor (uygulama silinmiş, token expire olmuş, cihaz fabrika ayarlarına döndürülmüş).

Yönetici "Subscribed Devices" panelinde push_failed sütununu sıralayarak sorunlu cihazları bulabilir ve iptal edebilir. Bu sayede ShamashAi backend'i gereksiz yere Firebase/APNs'e istek göndermez, maliyet ve kaynak tüketimi azalır.

Gelecek sürümlerde otomatik temizleme özelliği planlanıyor: push_failed > 10 olan ve son 7 günde başarılı push almayan abonelikler otomatik olarak silinecek, dbo.audit_log'a push.auto_cleanup action'ı kaydedilecek.

Entegrasyon: Employee Offboarding Workflow ile Bağlantı

Orta ölçekli Türk firmaları genellikle çalışan ayrılma sürecini manuel yönetir: İK Excel listesinde çalışanı işaretler, IT departmanına mail gönderir, IT yöneticisi Active Directory, e-posta, VPN hesaplarını kapatır. ShamashAi push abonelikleri bu checklist'e eklenmelidir:

Örnek Offboarding Checklist:

1. Active Directory hesabını devre dışı bırak. 2. E-posta kutusunu yedekle ve 30 gün sonra sil. 3. VPN ve VDI erişimini iptal et. 4. ShamashAi push aboneliklerini kontrol et ve iptal et. 5. Fiziksel erişim kartını devre dışı bırak.

ShamashAi dokümantasyonu şu an API üzerinden otomatik offboarding entegrasyonu için örnek sunmuyor. Eğer firma HR sisteminde (örneğin InnFlow, Logo) webhook desteği varsa, çalışan ayrılma olayında DELETE /push/subscriptions/:id çağrısı yapılabilir. Ancak bu entegrasyon için önce çalışanın hangi push aboneliklerine sahip olduğunu bulmak gerekir; GET /push/subscriptions endpoint'i şu an kullanıcı e-postasına göre filtreleme sunmuyor.

Geçici çözüm: Yönetici label alanında çalışan adını aratarak manuel bulur. Gelecek sürümlerde GET /push/subscriptions?filter=label:contains:Ahmet sorgu desteği eklenebilir.

Örnek Senaryo: Nöbet Telefonu Yönetimi

Bir IT ekibi 7/24 nöbet tutuyor, nöbetçi "Nöbet Telefonu" adlı ortak bir cihaz kullanıyor. Her hafta farklı kişi bu telefonu alıyor. ShamashAi mobil uygulaması bu cihazda kurulu ve label: "Nöbet Telefonu - IT Ekibi" ile kayıtlı.

Sorun: Nöbet değiştiğinde yeni kişi telefonun bildirim ayarlarını kendi tercihine göre değiştirmek istiyor (örneğin min_severity: MEDIUM yerine HIGH). Ancak push aboneliği cihaza bağlı olduğundan, eski ayarlar kalıyor.

Çözüm:

1. Yönetici "Subscribed Devices" panelinde "Nöbet Telefonu" satırını bulur. 2. Mevcut min_severity ve subscribed_event_types ayarlarını görür. 3. Şu an admin tarafından düzenleme olmadığından, nöbetçiye "Mobil uygulamadan Settings → Notifications'a git, ayarları güncelle" talimatı verir. 4. Veya aboneliği iptal eder, nöbetçiden yeniden abone olmasını ister (bu durumda eski push_count metrikleri kaybolur).

Gelecek sürümlerde "shared device" modu planlanıyor: Bir cihaz birden fazla kullanıcı profiline bağlanabilecek, her kullanıcı kendi bildirim tercihlerini ayarlayabilecek.

Limitler ve Dürüst Notlar

• Admin panelinde toplu silme yok: Şu an her abonelik tek tek iptal edilmeli. 50+ cihaz varsa zahmetli olur; SQL script'i ile manuel müdahale gerekir.
• Kullanıcı e-postasına göre filtreleme yok: GET /push/subscriptions endpoint'i tüm abonelikleri döndürür, "Ahmet'in tüm cihazlarını göster" filtresi sunmaz. Yönetici label alanında arama yaparak manuel bulur.
• Admin tarafından abonelik düzenleme yok: Mevcut bir aboneliğin min_severity veya event_types ayarları admin tarafından değiştirilemez; sadece iptal edilebilir.
• Otomatik temizleme yok: push_failed yüksek olan cihazlar otomatik olarak silinmez; yönetici manuel kontrol etmelidir.
• Offboarding API entegrasyonu örneği yok: HR sistemi ile otomatik entegrasyon için dokümantasyonda hazır kod örneği bulunmaz; özel geliştirme gerekir.

Sonuç

ShamashAi'nin Push Abonelik Yönetim Paneli, çalışan ayrılma sürecindeki kritik bir boşluğu doldurur: IT yöneticisi artık "ayrılan çalışanın telefonu hâlâ alarm alıyor mu?" sorusunu kolayca cevaplayabilir ve tek tıkla iptal edebilir. dbo.audit_log kaydı KVKK Madde 12 uyumluluğu için kanıt sağlar; push_count ve push_failed metrikleri operasyonel sağlık izleme imkanı verir. Şu anki sürümde toplu silme ve admin tarafından düzenleme özellikleri yok; bu ihtiyaçlar için SQL script'i veya gelecek sürümler beklenir.

Pilot programı 30 gün ücretsiz: shamashai.com.tr/iletisim