KVKK Teknik Tedbirleri: Yetki, Erişim Logu ve Maskeleme Uygulaması

İhlal sonrası gelen ilk soru “politikanız var mı” değildir; “bu kayda kim, ne zaman erişti” sorusudur. Yanıt çoğu kurumda yoktur, çünkü oturum açma logu tutulmuş ama veri düzeyinde log hiç açılmamıştır. KVKK’nın veri güvenliği yükümlülüğü kâğıtta tek maddedir; sistemde ise yetki matrisi, veritabanı denetim kaydı, test ortamındaki kopyalar ve maskeleme kuralları demektir. Bu rehber sistem yöneticileri ve bilgi güvenliği sorumluları için, tedbirin nasıl uygulandığını ve nasıl kanıtlandığını anlatır. Hukuki tavsiye değildir; hukuki sebep ve saklama süresi kararları hukuk ve uyum ekibiyle verilir.

KVKK’da teknik tedbirlerin yeri

6698 sayılı Kişisel Verilerin Korunması Kanunu’nun 12. maddesi, veri sorumlusundan kişisel verilerin hukuka aykırı işlenmesini ve erişilmesini önlemek, verilerin muhafazasını sağlamak için “uygun güvenlik düzeyini temin etmeye yönelik gerekli her türlü teknik ve idari tedbiri” almasını ister. Kanun teknoloji adı vermez. Somut çerçeveyi Kişisel Verileri Koruma Kurumu’nun Kişisel Veri Güvenliği Rehberi (Teknik ve İdari Tedbirler) ve Kurul kararları çizer.

Rehberdeki teknik tedbirler şunlardır: yetki matrisi ve yetki kontrolü, erişim logları, kullanıcı hesap yönetimi, ağ ve uygulama güvenliği, şifreleme, sızma testi, saldırı tespit ve önleme, log kayıtlarının izlenmesi, veri maskeleme, veri kaybı önleme, yedekleme ve anahtar yönetimi. Özel nitelikli kişisel veriler için Kurul’un 31.01.2018 tarihli ve 2018/10 sayılı kararı çıtayı yükseltir: bu verilere erişimin loglanması, uzaktan erişimde en az iki aşamalı kimlik doğrulama, aktarımda şifreleme gibi.

Kurumsal siber güvenlik tarafında işin özü şu: belge yetmez, tedbirin ilgili sistemde çalıştığını tarihli kayıtla göstermeniz gerekir. Her tedbirin bir uygulama noktası ve bir kanıtı olmalı. Kanıtı olmayan tedbir yoktur.

Kişisel veri envanterinin teknik karşılığı

Hukuk ekibinin envanteri “müşteri iletişim bilgileri, CRM’de, 10 yıl” gibi satırlardan oluşur. Sistem yöneticisi bu satırla hiçbir şey yapamaz. Satırın karşılığı bilinmeli: hangi sunucu, hangi veritabanı, hangi tablo ve sütun, hangi dosya paylaşımı, hangi SaaS uygulaması?

Her envanter satırı için şu alanları tutan bir “teknik veri haritası” çıkarın:

• Depolama konumu: sunucu adı, veritabanı/şema/tablo veya paylaşım yolu, bulut kiracısı.
• Veri alanları: TCKN, IBAN, sağlık bilgisi gibi hassas sütunlar ayrıca işaretlenir.
• Erişim kanalları: uygulama arayüzü, doğrudan veritabanı bağlantısı, raporlama aracı, API, dışa aktarım.
• Kopyalar: yedekler, test ve geliştirme ortamları, raporlama veri ambarı, kullanıcıların indirdiği Excel dosyaları.
• Sistem sahibi ve veri sahibi: erişim taleplerini kim onaylar, gözden geçirmeyi kim yapar.

Sahada en sık kaçan alan kopyalardır. Üretim veritabanında yetkiler sıkıdır; aynı verinin gece aktarılan raporlama kopyası ise “Domain Users” seviyesinde açık kalmıştır. Bunu görmeden envanter tamamlanmış sayılmaz. Dosya sunucularındaki yapılandırılmamış veri için dosya sunucularında hassas veri keşfi yöntemleri haritanın eksik kısmını kapatır.

Yetkilendirme matrisi ve erişim gözden geçirme

Yetki matrisi, roller ile kişisel veri kümeleri arasındaki izinleri gösteren tablodur. Uygulanabilir olması için zincir net olmalı: rol dizin grubuna, grup da uygulama veya veritabanı rolüne bağlanır. Kişiye doğrudan verilmiş izin hem gözden geçirmeyi hem işten çıkış sürecini bozar. Matris dışı izin, sahipsiz izindir.

Rol	Veri kümesi	İzin	Teknik karşılık
Çağrı merkezi	Müşteri iletişim	Okuma, maskeli	AD grubu → CRM rolü, TCKN maskeli
Muhasebe	Cari hesap, IBAN	Okuma/yazma	AD grubu → ERP rolü
İK uzmanı	Personel özlük	Okuma/yazma	Ayrı paylaşım, yalnız İK grubu
Raporlama	Satış raporları	Okuma	Takma adlı görünüm, ham tablo yok
Veritabanı yöneticisi	Tüm tablolar	Yönetim	Ayrı yönetici hesabı, oturum loglu

Erişim gözden geçirmesi, matrisi gerçek durumla karşılaştırmaktır. İlk adım, grup üyeliklerini iç içe gruplarla birlikte dışa aktarmaktır; yalnız doğrudan üyeleri çekerseniz iç içe gruptan gelen erişimler görünmez:

Get-ADGroupMember -Identity "CRM_Musteri_Okuma" -Recursive |
  Get-ADUser -Properties Enabled, LastLogonDate, Department |
  Select-Object SamAccountName, Name, Department, Enabled, LastLogonDate |
  Export-Csv -Path .\CRM_Musteri_Okuma_gozden_gecirme.csv -NoTypeInformation -Encoding UTF8

Listeyi veri sahibine gönderin, her kullanıcı için “devam / kaldır” kararı alın ve kaldırma tarihlerini kaydedin. Gözden geçirmenin kanıtı budur. Uygulamanın kendi kullanıcı tablosundaki yerel hesapları da aynı döngüye alın; dizin dışındaki hesaplar en sık unutulan erişimlerdir. Denetimde bunun nasıl belgeleneceği için uyum tarafındaki erişim gözden geçirme kanıtı rehberine bakın.

Erişim loglarının tutulması

Erişim logu tek soruya cevap vermeli: kim, hangi kişisel veriye, ne zaman, hangi kanaldan erişti? Oturum açma logu bunu söylemez. Veri düzeyinde log gerekir. Kaynağa göre seçenekler:

• Uygulama logu: En anlamlı kayıt, uygulamanın ürettiği “müşteri kartı görüntülendi / dışa aktarıldı” olayıdır. Yeni geliştirmelerde bu olay kullanıcı, kayıt kimliği ve işlem türüyle loglanmalı.
• Veritabanı denetimi: Uygulama log üretmiyorsa ya da doğrudan veritabanı erişimi varsa veritabanının denetim özelliği devreye alınır.
• Dosya sistemi denetimi: Windows dosya sunucusunda nesne erişim denetimi açılır, hassas klasörlere SACL tanımlanır; erişimler Security loguna 4663 olay kimliğiyle düşer.

Microsoft SQL Server’da hassas bir tablodaki okuma ve değiştirme işlemlerini dosyaya yazan örnek yapılandırma:

USE master;
CREATE SERVER AUDIT KisiselVeriDenetim
  TO FILE (FILEPATH = 'E:\SQLAudit\', MAXSIZE = 256 MB);
ALTER SERVER AUDIT KisiselVeriDenetim WITH (STATE = ON);

USE CRM;
CREATE DATABASE AUDIT SPECIFICATION MusteriTablosuErisim
  FOR SERVER AUDIT KisiselVeriDenetim
  ADD (SELECT, UPDATE, DELETE ON OBJECT::dbo.Musteri BY public)
  WITH (STATE = ON);

Windows dosya sunucusunda önce denetim alt kategorisi açılır, sonra klasöre denetim girdisi (SACL) eklenir. SACL’siz açılan alt kategori log üretmez:

auditpol /set /subcategory:"File System" /success:enable /failure:enable

Etki alanındaki sunucularda bu ayarı Grup İlkesi’nin Gelişmiş Denetim İlkesi Yapılandırması (Advanced Audit Policy Configuration) üzerinden dağıtın. auditpol ile yapılan yerel değişiklik, bir sonraki ilke uygulamasında GPO değeriyle ezilebilir. Sahada “denetim açıktı, sonra kayboldu” şikâyetinin tipik nedeni budur.

Loglama tasarımında üç hata sürekli tekrar eder. Birincisi: uygulama veritabanına tek servis hesabıyla bağlanır, veritabanı denetimi de yalnız servis hesabını gösterir. Son kullanıcıyı ayırt etmek için uygulama logu şarttır. İkincisi: loglar, veriye erişen yöneticinin silebileceği yerde durur. Loglar merkezi sisteme akmalı, sistem yöneticisi bu kayıtları değiştirememelidir. Üçüncüsü: hacim hesabı yapılmaz. Yüksek trafikli bir tabloda her SELECT’i loglamak diski günler içinde doldurur; kapsamı hassas tablolar ve toplu dışa aktarımla sınırlayın. Dolu disk, kayıp logdur. Saklama süresi, bütünlük ve erişim kontrolü için merkezi log saklama mimarisi yazısına bakın.

Maskeleme, takma ad ve anonimleştirme

Bu üç teknik sürekli karıştırılır; hukuki sonuçları farklıdır. Anonim veri, başka verilerle eşleştirilse bile kişiyle ilişkilendirilemez ve KVKK kapsamından çıkar. Takma ad (pseudonymization) ve maskeleme veriyi kişisel veri olmaktan çıkarmaz. Yalnızca erişenin göreceğini sınırlar.

Teknik	Ne yapar	Geri döndürülebilir mi	Tipik kullanım
Dinamik maskeleme	Sorgu sonucunda değeri gizler	Evet, kaynak veri değişmez	Çağrı merkezi ekranı
Statik maskeleme	Kopya veride değeri kalıcı değiştirir	Hayır (kopya için)	Test ortamı
Takma ad	Kimliği anahtarlı bir değerle değiştirir	Anahtarla evet	Raporlama, analiz
Anonimleştirme	Kişiyle bağı kalıcı koparır	Hayır	İstatistik, dış paylaşım

SQL Server’da dinamik veri maskeleme (Dynamic Data Masking) örneği:

ALTER TABLE dbo.Musteri
  ALTER COLUMN TCKN ADD MASKED WITH (FUNCTION = 'partial(0,"*******",4)');
ALTER TABLE dbo.Musteri
  ALTER COLUMN Eposta ADD MASKED WITH (FUNCTION = 'email()');

GRANT UNMASK TO [CRM_Yetkili_Rol];

Takma adda yaygın yöntem, kimlik alanının gizli bir anahtarla HMAC’ini almaktır. Anahtarsız düz hash (yalnızca SHA-256 gibi) TCKN gibi değer uzayı sınırlı alanlarda tüm olasılıklar hesaplanarak geri çözülebilir. Hash, şifreleme değildir. Anahtar, veriyi kullanan ekipten ayrı tutulur. Anonimleştirmede ise ad ve kimlik numarasını silmek yetmez; doğum tarihi, posta kodu ve cinsiyetin birleşimi kişiyi yeniden belirlenebilir kılabilir. Kurum’un anonim hale getirme rehberindeki genelleştirme, gürültü ekleme ve k-anonimlik yöntemleri bu riski hedefler.

Test ortamlarında gerçek veri kullanımı

Üretim yedeğini test sunucusuna geri yüklemek on dakikalık iştir. Sonuç, envanterde görünmeyen ve zayıf korunan bir kişisel veri kopyasıdır. Test ortamında geliştirici erişimi geniştir, loglama zayıftır, dış yazılım firmaları bağlanır. Saldırgan da önce oraya bakar.

Uygulanabilir karar sırası:

1. Sentetik veri yeterli mi? Fonksiyonel testlerin çoğu için evet. Üretilen veri, alan formatlarına (TCKN algoritması, IBAN yapısı) uymalıdır.
2. Gerçek veri dağılımı gerekiyorsa üretimden alınan kopya, test ortamına taşınmadan önce statik maskeleme işleminden geçirilir. Maskeleme betiği üretim tarafında veya ayrı bir ara ortamda çalışır; ham veri test ağına hiç ulaşmaz.
3. Maskelenmemiş veri zorunluysa (örneğin üretimdeki bir hatanın birebir yeniden üretimi), bu bir istisnadır: süre sınırlı, onaylı, erişimi üretimle aynı kurallara tabi ve iş bitince silinip silindiği kayıt altına alınan bir ortam olarak yönetilir.

Maskeleme referans bütünlüğünü korumalı: aynı müşteri numarası tüm tablolarda aynı maskeli değere dönüşmezse uygulama testleri patlar. Bu yüzden deterministik (aynı girdiye aynı çıktı) ama anahtarı test ekibinde olmayan dönüşümler seçilir.

Teknik tedbir kontrol listesi

Bir sistemi kişisel veri açısından gözden geçirirken aşağıdaki adımları kullanın. Her maddenin karşısına “nasıl gösterilir” sorusunun cevabını yazın. O cevap kanıttır.

• Sistem, teknik veri haritasında konum, alan ve kopyalarıyla kayıtlı; sistem sahibi tanımlı.
• Kişisel veriye erişim yalnızca gruplar üzerinden veriliyor; doğrudan kişiye atanmış izin yok.
• Son erişim gözden geçirmesinin tarihi, onaylayan kişi ve kaldırılan erişimler kayıtlı.
• Hassas tablolara ve klasörlere erişim kullanıcı düzeyinde loglanıyor; loglar merkezi sisteme akıyor ve sistem yöneticileri tarafından silinemiyor.
• Toplu dışa aktarım ve yüksek hacimli sorgular için uyarı kuralı var.
• Ekranlarda gereksiz alanlar maskeli; maskeyi kaldırma yetkisi gerekçeli ve sınırlı.
• Test ve geliştirme ortamlarında ham kişisel veri yok veya istisna kaydıyla yönetiliyor.
• Uç noktalarda ve sunucularda disk şifreleme etkin; aktarımda TLS zorunlu (ayrıntılar için şifreleme kontrolleri rehberi).
• Saklama süresi dolan veriler için periyodik imha işi tanımlı ve çalıştığına dair çıktı saklanıyor.
• Veri kaybı önleme kuralları kişisel veri desenlerini (TCKN, IBAN) tanıyor ve en azından izleme modunda çalışıyor.

Hangi kontrolün önce ele alınacağı, sistemdeki veri türüne ve maruziyete bağlıdır. Hassas veri desenlerini e-posta, bulut paylaşımı ve uç noktalarda izlemek için veri kaybı önleme (DLP) çalışması; sistemler arası önceliklendirme için siber güvenlik risk değerlendirmesi mantıklı başlangıç noktalarıdır. Kurum rehberlerinin güncel sürümleri kvkk.gov.tr üzerinde; SQL Server maskeleme davranışının ayrıntıları Microsoft’un Dynamic Data Masking belgesinde.

Sık sorulan sorular

Takma adlı veri KVKK kapsamından çıkar mı?

Hayır. Takma ad veriyi doğrudan tanımlayıcı olmaktan çıkarır, ama anahtar veya eşleme tablosuyla kişiye geri bağlanabildiği için kişisel veri olarak kalır. Kapsamdan yalnızca kişiyle bağı geri döndürülemez biçimde koparılmış, yani anonim hale getirilmiş veri çıkar.

Oturum açma logları KVKK erişim logu olarak yeterli mi?

Genellikle hayır. Oturum açma logu kullanıcının sisteme girdiğini gösterir, hangi kişinin verisine eriştiğini göstermez. Kullanıcıyı erişilen kayıt veya tabloyla ilişkilendiren uygulama ya da veritabanı düzeyinde log gerekir.

Test ortamında üretim verisinin maskeli kopyası kullanılabilir mi?

Maskeleme kalıcı ve geri döndürülemezse ve dolaylı tanımlayıcılar da ele alındıysa risk ciddi biçimde düşer. Maskeleme, ham verinin test ağına ulaşmadığı bir noktada çalışmalı; anahtar veya eşleme bilgisi test ekibinde olmamalıdır.

Bu teknik tedbirler hukuki uyum için yeterli mi?

Hayır, veri güvenliği yükümlülüğünün yalnızca bir parçasıdır. Aydınlatma, hukuki sebep, saklama süreleri, ilgili kişi başvuruları ve veri işleyen sözleşmeleri hukuk ve uyum ekipleriyle birlikte değerlendirilir; bu yazı hukuki tavsiye niteliği taşımaz.