KVKK
Lunixi, 6698 sayılı Kişisel Verilerin Korunması Kanunu kapsamında kural olarak veri işleyen konumundadır; veri sorumlusu sizin kurumunuzdur. Aydınlatma metni, açık rıza yönetimi, VERBİS kaydı ve ilgili kişi başvurularının nihai cevabı sizin sorumluluğunuzdadır.
Bu sayfa hukuki bir yorum sunmaz. Platformun bugün fiilen ne yaptığını anlatır: hangi alanın şifrelendiğini, hangisinin şifrelenmediğini, verinin ne kadar saklandığını ve silme talebinin teknik olarak nasıl işletildiğini.
Hukuk teyidi bekliyor. Bu sayfadaki madde atıfları ve saklama süreleri, koddaki yapılandırma ve geliştirici notlarından türetilmiştir. Kanun maddesi yorumu, süre gerekçesi ve nihai uygunluk değerlendirmesi hukuk müşavirliği tarafından teyit edilmemiştir. Kendi hukukçunuzla doğrulamadan bu sayfayı uyum kanıtı olarak kullanmayın.
Rol dağılımı
| Konu | Veri sorumlusu (siz) | Veri işleyen (Lunixi) |
|---|---|---|
| Hukuka uygunluk sebebinin belirlenmesi | ✅ | — |
| Aydınlatma yükümlülüğü ve açık rıza | ✅ | — |
| VERBİS kaydı | ✅ | — |
| İlgili kişi başvurusunun cevaplanması | ✅ | Teknik destek: veri çıkarma ve silme uçları |
| Teknik ve idari tedbirler | ✅ (kendi ortamınızda) | ✅ (platform tarafında) |
| Saklama ve imha politikasının belirlenmesi | ✅ | Politikanın teknik olarak işletilmesi |
Şifreleme
Alan bazlı şifreleme
Kimlik doğrulama verisi alan bazında AES-256-GCM ile şifrelenir. Şifreleme, kimliği doğrulanmış ek veri (AAD) kullanır ve AAD kiracıId:kolonAdı biçimindedir — yani bir kiracının şifreli değeri başka bir kiracıya ya da başka bir kolona taşınamaz; taşınırsa çözme işlemi doğrulama hatası verir.
Her kiracının kendi veri şifreleme anahtarı (DEK) vardır. DEK'ler açık halde saklanmaz; bir anahtar şifreleme anahtarı (KEK) ile sarmalanır ve veritabanında yalnızca sarmalanmış hali durur. DEK rotasyonu varsayılan olarak 90 gündür.
KEK sağlayıcısı yapılandırılabilir: yerel anahtar, bulut KMS veya HSM. Kurulumunuzda hangisinin kullanıldığı bir yapılandırma kararıdır — donanım destekli anahtar yönetimi istiyorsanız bunu kurulum sırasında talep edin. Varsayılan kurulum yerel anahtar sağlayıcısını kullanır.
Hangi alanlar şifreli — ve hangileri değil
Dürüst olmak gerekirse: "tüm kişisel veri şifrelidir" demiyoruz, çünkü doğru değil. Bugünkü durum:
Şifreli saklanan (kimlik doğrulama müşteri kaydı):
| Alan | Biçim |
|---|---|
| Ad, soyad | AES-256-GCM zarf |
| E-posta | AES-256-GCM zarf |
| Telefon | AES-256-GCM zarf |
| T.C. kimlik numarası | AES-256-GCM zarf |
| Doğum tarihi (tam) | AES-256-GCM zarf |
| Adres, şirket adresi | AES-256-GCM zarf |
| Ticaret sicil numarası | AES-256-GCM zarf |
| Beyan edilen müşteri profili | AES-256-GCM zarf |
| Kimlik belgesi görüntüleri | AES-256-GCM (ikili veri) |
Arama ve tekilleştirme için ayrıca kör indeks (peppered hash) tutulur — e-posta, telefon, TCKN ve sicil numarası için. Kör indeks düz metin değildir; ham değere geri dönülemez, yalnızca eşitlik karşılaştırması yapılabilir.
Şifresiz (düz metin) saklanan:
| Alan | Neden | Not |
|---|---|---|
| Doğum yılı (yalnız yıl) | Operasyonel filtreleme | Tam doğum tarihi ayrıca şifreli tutulur |
| Uyruk / ikamet ülkesi, adres ülkesi | Yönlendirme ve kural seçimi | |
| Şirket unvanı | Fatura, panel ve arama yollarında okunur | Şahıs şirketinde gerçek kişi adına denk gelebilir |
Kurumun ticari/hukuki unvanı (legal_name) | Fatura kesimi, panel, arama | Gerçek kişi tacirde kişisel veridir. Denetim anlık görüntüsünde maskelenir, canlı kolon düz metindir |
| Kart hamili adı | Kart kaydı gösterimi | Kart numarasının kendisi HSM şifrelidir — bkz. PCI DSS |
| Serbest biçimli ek alanlar | Entegrasyon esnekliği | Buraya kişisel veri yazarsanız şifrelenmez — yazmayın |
legal_name ve kart hamili adı bugün düz metindir. Bu bir açık iyileştirme kalemidir ve kodda da böyle kayıtlıdır. Loglara ve hata izlerine yazılmaları engellenmiştir (aşağıya bakın), ancak bu kayıt anında şifreleme değildir. Bu iki alanı bilerek yazıyoruz ki kendi risk değerlendirmenizi doğru yapabilesiniz.
Belge görüntüleri ve nesne depolama
Kimlik belgesi ve selfie görüntüleri nesne depolamaya yazılmadan önce uygulama katmanında şifrelenir — kiracı başına AES-256-GCM zarf. Bu bir tercih değil, açılış koşuludur: depolama tarafında sunucu tarafı şifreleme (SSE) yapılandırılmamışsa servis, uygulama katmanı şifrelemesi açık olmadığı sürece başlamayı reddeder. Yani şifrelenmemiş belge nesnesi yazılabilecek bir yapılandırma bırakılmamıştır.
Cüzdanda telefon numarası
Cüzdan tarafında telefon numarası hiçbir zaman düz metin olarak saklanmaz. Kayıt anında iki türev üretilir:
- Peppered HMAC-SHA256 — eşleştirme ve tekillik için; ham numaraya geri dönülemez
- Maske — kullanıcıya gösterim için (ilk basamaklar + son iki hane)
Pepper ortam yapılandırmasından gelir ve güvensiz varsayılanı yoktur: pepper tanımlı değilse servis açılışta hata verip başlamaz.
Alıcı IBAN'ı
Banka gönderimlerinde alıcı IBAN'ı AES-256-GCM ile şifrelenir; ayrıca maskeli gösterim ve HMAC parmak izi tutulur. Şifreleme anahtarı tanımlı değilse servis başlamaz — düz metne düşme (fallback) yolu yoktur.
Log ve hata izlerinde redaksiyon
Platformun tamamında ortak bir redaksiyon katmanı vardır ve gerçekten bağlıdır — merkezi log altyapısına, hata izleme (Sentry) akışına ve servisler arası hata filtrelerine.
Redaksiyon iki eksende çalışır:
- Alan adı ekseni —
tckn,tcKimlik,nationalId,passport,taxNumber,cardholder,firstName,dateOfBirthgibi anahtar parçaları taşıyan alanlar maskelenir - İçerik ekseni — serbest metin içinde geçen 13–19 haneli sayı dizileri Luhn doğrulamasından geçirilir, 11 haneli sayılar TCKN kontrol basamağı algoritmasıyla doğrulanır. Yalnız doğrulamayı geçenler maskelenir; rastgele sipariş numaraları bozulmaz.
Redaksiyon log hijyenidir, kayıt anında şifreleme değildir. Düz metin saklanan bir alanın loglarda maskelenmesi, o alanın veritabanında şifreli olduğu anlamına gelmez.
Saklama ve imha
Bu bölüm kimlik tespiti (KYC) ve kimlik/cihaz sinyalleri tarafını anlatır. Diğer ürünlerin saklama süreleri, süre sonundaki davranışı ve hukuki askı kuralları kendi sayfalarındadır: dolandırıcılık önleme ve cüzdan.
Saklama süresi ülke bazında çözülür:
| Kapsam | Varsayılan süre |
|---|---|
| Genel varsayılan | 1825 gün (5 yıl) |
| Türkiye | 2920 gün (8 yıl) |
| Biyometrik görüntüler (Türkiye kural seti) | 90 gün |
Süreler ortam yapılandırmasıyla kurulum bazında değiştirilebilir.
Otomatik imha varsayılan olarak kapalıdır. İmha işleri planlanır ve kuyruğa alınır, ancak fiilen silme yapılması kurulum bazında açıkça etkinleştirilmelidir. Kendi kurulumunuzda bunun açık olup olmadığını teyit edin — kapalıysa süresi dolan kayıtlar silinmez, yalnızca imhaya aday olarak işaretlenir.
İmha motoru saga tabanlıdır:
- Silinecek her nesne, hiçbir silme yapılmadan önce değiştirilemez bir manifestoya yazılır
- İlerleme kontrol noktalarıyla yürütülür — çökme sonrası kaldığı yerden devam eder, baştan başlamaz
- Tamamlandığında imzalı bir imha sertifikası üretilir (özet + imza + anahtar kimliği), imha kaydına iliştirilir
Biyometrik görüntüler için ayrı bir zamanlayıcı vardır ve kod tarafında 7 günlük sert alt sınır uygulanır — yapılandırma bunun altına inemez.
Silme ve ilgili kişi başvuruları
Aşağıdaki uçlar operatör uçlarıdır — kimlik doğrulama gerektirir ve yetki (RBAC) kontrolünden geçer.
| İşlem | Uç | Gerekli yetki |
|---|---|---|
| Silme talebi başlat | POST /kyc/admin/sessions/:sessionId/erasure | kyc:document_delete |
| Veri sahibi dışa aktarımı | GET /kyc/admin/sessions/:sessionId/dsar-export | kyc:view_reports |
| Silme taleplerini listele | GET /kyc/admin/erasure-requests | kyc:view_reports |
| Açık rıza geri çekme | POST /kyc/admin/sessions/:sessionId/consent/withdraw | kyc:document_delete |
Veri sahibinin kendisinin kullanabileceği bir silme ucu yoktur. İlgili kişi başvurusunu siz alır, kendi süreçlerinizde değerlendirir ve kararı bu operatör uçlarıyla uygularsınız. Lunixi başvuruyu sizin adınıza değerlendirmez.
Dışa aktarma işleminin kendisi de denetim izine yazılır — yani "kimin verisi, ne zaman, kim tarafından dışa aktarıldı" sorusunun cevabı kayıtlıdır.
Silme kanıtı
- Kimlik doğrulama tarafında kanıt, imhaya ait imzalı imha sertifikası ile özet zincirli denetim kaydıdır: her satır kendi içeriğinin ve bir önceki satırın özetinden türetilir, bu sayede araya kayıt eklenmesi veya zincirin yeniden bağlanması tespit edilebilir.
- Kimlik/cihaz sinyalleri tarafında ayrıca yalnızca ekleme yapılabilen (append-only) bir silme olay tablosu vardır; satırlar güncellenemez ve silinemez, bu veritabanı düzeyinde zorlanır. Bu tablo ham kişisel veri tutmaz — yalnızca takma adlaştırılmış seçici özetlerini tutar.
Yurt dışına aktarım
Türkiye'de üretilen veri kendi altyapımızda barındırılır. Depolama hedefi ve anahtar yönetimi kurulum yapılandırmasıyla belirlenir; bölge bazlı ayrı kurulum yapılabilir. Kurulumunuza özgü barındırma ve aktarım tablosu için [email protected] adresinden yazılı teyit isteyin.
Yurt dışına aktarım gerekiyorsa taahhütname, bağlayıcı şirket kuralları veya Kurul izni gibi hukuki zemin veri sorumlusu olarak sizin kurmanız gereken bir konudur. Bu sayfa o değerlendirmeyi yapmaz.
İlgili sayfalar
- GDPR — AB kişisel verisi için işleme modeli ve DPA
- MASAK — Türkiye'deki aklama ile mücadele yükümlülükleri
- PCI DSS — kart verisinin nasıl işlendiği
Veri İşleme Sözleşmesi ve kuruluma özgü teknik tedbir listesi için [email protected].