1. KVKK’da “kim ne yaptı?” sorusunu kanıtla: RBAC + audit trail çerçevesi
KVKK uyumunda teknik tedbirlerin amacı “log var” demek değil; kanıt üretmektir. Denetimde ve ihlal analizinde aranan şey şudur: kim, hangi kayda, hangi aksiyonla temas etti (görüntüleme/değişiklik/silme/export) ve bu olayın zaman çizelgesi nedir? RBAC (erişim kontrolü) bu aksiyonların kimler tarafından yapılabileceğini sınırlar; audit trail ise olan biteni kanıtlanabilir şekilde kaydeder.
Ne yapmalıyım? (başlangıç çerçevesi)
- • Paneldeki kritik ekranları ve aksiyonları çıkarın (view/edit/delete/export).
- • RBAC’ı ekran + aksiyon bazında tasarlayın (sadece sayfa erişimi yetmez).
- • Kritik aksiyonları audit event olarak standardize edin (actor-action-object).
- • Logları sunucuda güvenli saklayın (masking + şifreleme + erişim kısıtı + bütünlük).
2. KVKK İçin Erişim Kontrolü (RBAC) Nasıl Kurgulanmalı?
RBAC (Role Based Access Control), panelde “herkes her şeyi görmesin” yaklaşımını sistematik hale getirir. KVKK perspektifinde RBAC’ın amacı sadece güvenlik değil; aynı zamanda izlenebilirlik (audit) ve sorumluluk üretmektir. Çünkü erişim sınırı olmayan bir panelde, loglar da anlamını kaybeder: herkes her şeyi yapabiliyorsa, “kim yaptı?” sorusu kaosa döner.
Rol tasarımının temel prensibi: ekran + aksiyon
RBAC’ı “rol = sayfa erişimi” gibi düşünmek yetersizdir. Doğru model iki katmandır: (1) Ekran erişimi (hangi modülü görebilir?), (2) Aksiyon yetkisi (ne yapabilir: görüntüleme/oluşturma/güncelleme/silme/export/kullanıcı yönetimi). Bu yaklaşım hem otelde hem B2B panellerde aynı şekilde çalışır.
Örnek rol seti (otel / B2B)
- •Admin: kullanıcı/rol yönetimi, kritik ayarlar (en az sayıda kişi)
- •Editör: içerik ve sınırlı kayıt güncelleme (ör. kampanya metni)
- •Operatör: günlük operasyon işlemleri (rezervasyon notu, lead takibi)
- •Viewer (salt okuma): raporlama/izleme (export yok veya sınırlı)
Mini örnek (otel): Operatör rezervasyon ekranını görür ama “misafir iletişim bilgisi export” yetkisi yoktur. Yönetici sadece dashboard’ı görür; ham misafir listesine girmez.
Mini Check (RBAC)
- • Roller ekran + aksiyon bazında tanımlandı mı?
- • Admin sayısı minimuma indirildi mi?
- • Export işlemleri ayrı bir izin mi?
- • Kullanıcı yönetimi ayrı rol/izin altında mı?
- • MFA/2FA özellikle admin için zorunlu mu?
Ne yapmalıyım?
- • Paneldeki kritik ekranları listeleyin (misafir/rezervasyon/sözleşme/teklif).
- • Her ekran için aksiyon seti çıkarın (view/edit/delete/export).
- • Export yetkisini ayrılaştırın ve kısıtlayın.
- • Admin hesaplarını azaltın, MFA zorunlu yapın.
- • Rol değişikliklerini de loglamayı planlayın (audit).
3. Kullanıcı ve Yetki Yönetimi: Kim, Neyi, Ne Kadar Görmeli?
RBAC kurgusunda bir sonraki adım “kapsam”tır: kullanıcı sadece rolüne göre değil, çoğu zaman veri kapsamına göre de sınırlandırılmalıdır. Örneğin bir otelde departman bazlı, B2B’de müşteri/portföy bazlı erişim gerekebilir. Bu yaklaşım; “role + scope” modelidir.
Scope (kapsam) örnekleri
- •Otel: departman, tesis, marka, tarih aralığı, pazar/dil, rezervasyon kanalı
- •B2B: müşteri hesabı, teklif pipeline aşaması, sözleşme klasörü, ürün grubu
En sık yapılan hata: “viewer” rolünün bile export yapabilmesi
Sözleşme, misafir listesi veya teklif ekranlarında export açık kaldığında, veri hızla panel dışına çıkar ve kontrol kaybolur. KVKK teknik tedbir mantığında export; en kritik risk yüzeylerinden biridir.
Mini Check (rol + scope)
- • “Rol + kapsam” (scope) ihtiyacı belirlendi mi?
- • Viewer rolünde export kapalı mı/sınırlı mı?
- • Kullanıcı yaşam döngüsü var mı? (işten ayrılan → hesap kapatma)
- • Parola politikası + MFA uygulanıyor mu?
- • Yetki değişiklikleri audit log’a yazılıyor mu?
Ne yapmalıyım?
- • Portföy/departman bazlı kapsam gereksinimini çıkarın.
- • Export izinlerini “default kapalı” yapın.
- • Kullanıcı kapatma sürecini checklist’e bağlayın.
- • Yetki değişikliklerini audit’e alın.
- • Bu mimariyi sunucu güvenliğiyle birlikte ele alın.
4. Hangi Aksiyonlar Loglanmalı?
Kısa cevap: kişisel veriye temas eden her kritik aksiyon loglanmalı ve sorgulanabilir olmalıdır. “Hata logu” tek başına yeterli değildir; en az üç log türü gerekir: erişim (access), değişiklik (change), hata (error). Otel/B2B panellerinde özellikle görüntüleme ve export aksiyonları, denetim ve ihlal analizinde en çok ihtiyaç duyulan izlerdir.
Loglama türleri: erişim, değişiklik, hata
- •Erişim logu: kullanıcı X, ekran Y’yi görüntüledi (timestamp + IP + cihaz)
- •Değişiklik logu: kayıt Z’de alan A, eski→yeni değer (diff)
- •Hata logu: sistem hatası/istisna (PII maskeleme şart)
Rol–Yetki ve Log Aksiyon Tablosu (örnek)
| Ekran | Aksiyon | Rol | Loglanır mı? | Not |
|---|---|---|---|---|
| Misafir kartı | view | Operatör | Evet | PII erişimi: görüntüleme iz bırakmalı |
| Misafir kartı | export | Viewer | Hayır | Export default kapalı olmalı |
| Rezervasyon | update | Operatör | Evet | Diff (eski→yeni) önerilir |
| Sözleşme/teklif | delete | Admin | Evet | Silme mutlaka audit + gerekçe ile |
| Kullanıcı/rol yönetimi | permission change | Admin | Evet | Yetki değişikliği audit’te zorunlu |
| Giriş | login failure | Tüm roller | Evet | Brute force tespiti için kritik |
Mini Check (audit kapsamı)
- • view/update/delete/export aksiyonları audit’e giriyor mu?
- • Login success/failure loglanıyor mu?
- • Yetki değişiklikleri loglanıyor mu?
- • Loglarda diff (eski→yeni) yaklaşımı var mı?
- • Hata loglarında PII maskeleme uygulanıyor mu?
Ne yapmalıyım?
- • “Kritik ekranlar” listesini çıkarın (misafir/rezervasyon/sözleşme/teklif).
- • Bu ekranlarda view + export’u zorunlu audit kapsamına alın (export izinle).
- • Değişiklik loglarında diff yaklaşımı uygulayın.
- • Login olaylarını merkezi toplayın.
- • Log formatını standartlaştırın (korrelasyon ID).
5. Logları Ne Kadar Süre Saklamalıyım? Retention ve Güvenlik
Bu içerik hukuki süre yorumu vermez; teknik kabiliyete odaklanır: retention, logların saklama süresini ve erişimini yönetebilme becerisidir. KVKK bağlamında kritik olan; süreyi yönetmek ve logların güvenliğini sağlamaktır. Teknik olarak loglar “sınırsız” bırakılmamalı, dönemsel döndürülmeli ve gerektiğinde silinebilir/anonimleştirilebilir olmalıdır.
Log saklama ve güvenlik: 5 temel kural
- Minimum veri: Loglarda gereğinden fazla hassas veri tutmayın (ör. tam kart bilgisi asla).
- Masking: e-posta/telefon/token gibi alanları maskeleyin.
- Bütünlük: Logların değiştirilemezliğini destekleyin (erişim kısıtı + immutability yaklaşımı).
- Şifreleme: At-rest ve transit şifreleme uygulayın.
- Erişim: Loglara erişim RBAC + audit ile yönetilsin.
Neden bu kurgu ihlalde işleri hızlandırır? (Key Data Point)
Doğru loglama kurgusu olan yapılarda, olası veri ihlallerinde kök neden analizi ve etkilenen kayıtların tespiti çok daha hızlı yapılabilir. Çünkü olayın zaman çizelgesi, hangi hesapların ne yaptığı ve hangi kayıtların etkilendiği netleşir; panik yerine “kanıt” çalışırsınız.
Mini Check (retention + güvenlik)
- • Retention politikası tanımlı ve uygulanıyor mu?
- • Loglarda PII masking var mı?
- • Log erişimi RBAC ile sınırlı mı?
- • Log bütünlüğü (immutability) düşünülmüş mü?
- • Logların yedekleri de güvenli mi?
Ne yapmalıyım?
- • Log retention’ı belirleyin ve otomatik rotate kurun.
- • Masking kuralını uygulayın (özellikle hata logları).
- • Log erişimini minimuma indirin (need-to-know).
- • Log bütünlüğü için immutability opsiyonlarını değerlendirin.
- • Sunucu güvenliği yaklaşımıyla birlikte ele alın.
6. Otel ve B2B İçin Panel + Sunucu Log Mimari Örnekleri
Bu bölüm, teoriyi mimariye bağlar. Amaç; panelde üretilen audit log’un sunucuda güvenli şekilde toplanması, saklanması ve sorgulanmasıdır. “Uygulama logu” ve “altyapı logu” birlikte tasarlanmalıdır; aksi halde kör nokta kalır.
Panel katmanı: uygulama audit trail
- •Her kullanıcı aksiyonu audit event olarak yazılır (actor, action, object, timestamp, ip, userAgent, correlationId).
- •Export işlemleri ayrı event’dir ve mutlaka loglanır (izinle).
- •Yetki değişiklikleri audit’e zorunlu girer.
Sunucu katmanı: altyapı log akışı
- •Web server / reverse proxy logları
- •WAF/CDN logları
- •Uygulama runtime logları
- •DB erişim ve admin logları (mümkünse)
- •Merkezi log toplama ve arama (sorgu + olay korelasyonu)
Panel ve sunucu log akış diyagramı (Competitor gap kapanışı)
TR’de yaygın yaklaşım “hata logu topladık” seviyesinde kalır. Oysa KVKK teknik tedbir perspektifinde erişim/değişiklik logları ile sunucu loglarını aynı correlation ID üzerinden ilişkilendirmek fark yaratır: “kullanıcı X panelde export yaptı → IP şundan geldi → şu endpoint’e gitti” gibi.
Mini Check (mimari)
- • Panel audit event formatı standart mı?
- • Correlation ID ile panel–sunucu logları bağlanıyor mu?
- • Export ve yetki değişikliği zorunlu audit mi?
- • Log toplama merkezi ve erişimi kısıtlı mı?
- • Log akış diyagramı dokümante mi?
Ne yapmalıyım?
- • Audit event şemasını belirleyin (actor-action-object).
- • Correlation ID’yi zorunlu hale getirin.
- • Panel–sunucu–WAF loglarını aynı zaman çizelgesinde korele edin.
- • Log akışını diyagramlayın ve ekiplerle paylaşın.
- • KVKK veri güvenliği raporlama yaklaşımıyla bağlayın.
7. Uygulanabilir “Erişim & Loglama” Checklist’i ve Sprint Planı
Bu rehberin çıktısı, bir “yapılacaklar listesi” olmalı. Çünkü RBAC ve loglama; tasarlanıp bırakılınca değil, uygulandıkça değer üretir. Hedef: 1 günde riskleri görmek, 14 günde kritik açıkları kapatmak, 30 günde sürdürülebilir izleme rutini kurmak.
1 günlük hızlı tarama
- •Kritik ekranlar (misafir/rezervasyon/sözleşme/teklif) çıkarılır
- •Rollerin ekran+aksiyon matrisi kontrol edilir
- •Export ve yetki değişikliği audit kapsamı doğrulanır
- •Log masking ve retention durumuna bakılır
14 günlük sprint (özet)
- •Gün 1–3: Rol matrisi + export kısıtları
- •Gün 4–7: Audit event şeması + panel logları
- •Gün 8–10: Sunucu log akışı + correlation ID
- •Gün 11–14: Retention + masking + erişim kısıtları + kapanış raporu
Mini Check (uygulama)
- • Rol–yetki matrisi güncel mi?
- • Export kısıtları var mı ve loglanıyor mu?
- • Audit event şeması standart mı?
- • Log masking ve retention aktif mi?
- • Log erişimi ve bütünlüğü korunuyor mu?
Ne yapmalıyım? (en hızlı 5 hamle)
- • Export’ları kilitleyin (izin + audit).
- • Yetki değişikliklerini mutlaka loglayın.
- • Correlation ID ile panel–sunucu bağlantısını kurun.
- • Masking + retention’ı otomatikleştirin.
- • Sunucu güvenliği ile birlikte ele alın.
8. Erişim & Loglama KVKK Teknik Tedbir Checklist Şablonu (v1.0)
Erişim & Loglama KVKK Teknik Tedbir Checklist Şablonunu İndir — Yazılım / Access Control (v1.0)
Bu asset, panel ve sunucu katmanında RBAC ve loglama kurgusunu tek checklist’e indirger. “Kim ne yaptı?” sorusuna yanıt verecek audit kapsamını standardize eder ve log güvenliği/retention adımlarını sprint planına bağlar. Otel ve B2B kurumlarda denetime hazırlık ve ihlal analiz hızını artırır.
Kim Kullanır?
IT/yazılım ekibi + operasyon yöneticileri + ajans teknik liderleri (otel ve B2B).
Nasıl Kullanılır?
- Rol–yetki matrisini doldurun ve export izinlerini netleştirin.
- Audit kapsamını seçin: view/update/delete/export + login + yetki değişimi.
- Log güvenliği: masking + retention + erişim kısıtı + bütünlük adımlarını sprint’e bağlayın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Rol seti tanımlı (admin/editör/operatör/viewer)
- ▢ ✅ Ekran + aksiyon bazlı izinler var (view/edit/delete/export)
- ▢ ✅ Export izinleri default kapalı
- ▢ ✅ Yetki değişiklikleri audit’e yazılıyor
- ▢ ✅ Login success/failure loglanıyor
- ▢ ✅ Kritik ekranlarda view loglanıyor
- ▢ ✅ Değişiklik loglarında diff var (eski→yeni)
- ▢ ✅ Hata loglarında PII masking var
- ▢ ✅ Log retention/rotate aktif
- ▢ ✅ Log erişimi RBAC ile sınırlı + audit altında
- ▢ ✅ Log bütünlüğü (immutability yaklaşımı) düşünülmüş
- ▢ ✅ Sunucu güvenliği ile uyumlu (WAF/CDN logları dahil)
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
9. Sonuç: Denetime hazır olmak “log var” demek değil; kanıt üreten mimari kurmaktır
KVKK teknik tedbirlerde erişim kontrolü ve loglama; güvenlik, izlenebilirlik ve operasyon hızını aynı anda çözen bir mimari karar setidir. RBAC ile erişimi sınırlayıp sorumluluğu netleştirir; audit trail ile “kim ne yaptı?” sorusuna kanıt üretirsiniz; sunucu tarafında log güvenliği/retention ve korelasyon ile ihlal anında kök neden ve etkilenen kayıt tespitini dramatik şekilde hızlandırırsınız.
Bir Sonraki Adım
Panel–sunucu katmanında RBAC+audit yapınızı kurup, ihlalde “kim ne yaptı?” sorusuna hızlı yanıt verecek mimariyi birlikte tasarlayalım.
Sık Sorulan Sorular
KVKK için erişim kontrolü (RBAC) nasıl kurgulanmalı?▾
Hangi aksiyonlar loglanmalı?▾
Logları ne kadar süre saklamalıyım?▾
Otel ve B2B için panel ve sunucu log mimarisi nasıl olmalı?▾
Loglarda hangi veriler tutulmamalı?▾
Export neden en kritik risk noktasıdır?▾
İlgili İçerikler