KVKK Teknik ve İdari Tedbirler Listesi: BT İçin Uygulama Rehberi

KVKK teknik ve idari tedbirler, 6698 sayılı Kişisel Verilerin Korunması Kanunu'nun 12. maddesinde tarif edilen veri güvenliği yükümlülüğünün pratikteki karşılığıdır. Madde, veri sorumlusundan üç şeyi sağlamak için “uygun güvenlik düzeyini temin etmeye yönelik gerekli her türlü teknik ve idari tedbiri” almasını ister: kişisel verilerin hukuka aykırı işlenmesini önlemek, verilere hukuka aykırı erişilmesini önlemek ve verilerin muhafazasını sağlamak. İdari tedbir kuralı, sorumluyu ve sözleşmeyi belirler; teknik tedbir o kuralı sistemde uygular.

Kimin almak zorunda olduğu sorusunun cevabı kısa: kişisel veri işleyen her veri sorumlusu. Çalışan sayınız, cironuz veya VERBİS kaydından muaf olmanız bu yükümlülüğü kaldırmaz; muafiyet kayıt ve envanter yükümlülüğüyle ilgilidir, güvenlikle değil. Verilerinizi sizin adınıza işleyen bir yazılım firması, bulut sağlayıcı veya muhasebe bürosu varsa Kanun sizi tedbirlerin alınmasında onunla müştereken sorumlu tutar.

Kanun tedbirleri tek tek saymaz ve bu bilinçli bir tercihtir: yaklaşım risk bazlıdır. Kurum'un Kişisel Veri Güvenliği Rehberi (Teknik ve İdari Tedbirler) beklenen başlıkları tek tek sayar. İlk baskısı Ocak 2018 tarihli; Kurum sonraki rehber güncellemelerinde metni yeniledi, bu yüzden kvkk.gov.tr'deki Rehberler sayfasından güncel sürümü indirip onunla çalışın. Özel nitelikli veriler (sağlık, biyometrik, ceza mahkûmiyeti, din, sendika üyeliği gibi) için Kurul'un 31.01.2018 tarihli ve 2018/10 sayılı kararı daha somuttur: kriptografik saklama, anahtarların ayrı ortamda tutulması, verilerdeki tüm işlemlerin güvenli loglanması, düzenli güvenlik testi ve uzaktan erişimde en az iki kademeli kimlik doğrulama.

Bu yazıyı hukuk metni gibi değil, iş listesi gibi okuyun. Danışmanın hazırladığı politika seti teslim edildikten sonra BT ekiplerinden gelen ilk soru neredeyse hep aynı: “Politikamız hazır. Sunucuda, veritabanında, Microsoft 365'te neyi açıp kapatacağız, incelemede neyi göstereceğiz?” Bölümleri bu soruya göre kurdum. Her birinde önce yapılacak ayar geliyor, sonra saklanacak kanıt; sahada sık bozulan yerleri de kısa notlar olarak ekledim.

• Kanun6698 sayılı KVKK, 12. maddeNe istendiğini söyler: uygun güvenlik düzeyi, veri işleyenle müşterek sorumluluk, kendi kurumunda denetim yapma veya yaptırma, öğrenilen veriyi açıklamama ve ihlal hâlinde bildirim.
• RehberKişisel Veri Güvenliği RehberiHangi başlıkların beklendiğini gösterir: yetki matrisi, erişim logları, kullanıcı hesap yönetimi, şifreleme, sızma testi, yedekleme, politika, eğitim, sözleşmeler ve iç denetim.
• KararKurul'un 2018/10 sayılı kararıÖzel nitelikli veri işliyorsanız bazı tedbirleri tercih olmaktan çıkarır: şifreli saklama, ayrı anahtar ortamı, güvenli loglama, periyodik yetki kontrolü, uzaktan erişimde iki kademeli doğrulama.
• SizKendi risk değerlendirmenizHangi sistemde hangi tedbiri hangi derinlikte uyguladığınızı ve neden yeterli gördüğünüzü yazar. Bir inceleme açıldığında savunduğunuz metin budur.

12. maddenin beş fıkrası, BT diliyle

1. 12/1Hukuka aykırı işlemeyi ve erişimi önlemek, verinin muhafazasını sağlamak için uygun güvenlik düzeyi.
2. 12/2Veri adına başkası işliyorsa, tedbirlerin alınmasında veri işleyenle birlikte müşterek sorumluluk.
3. 12/3Kanun hükümlerinin uygulanmasını sağlamak için kendi kurumunda denetim yapmak veya yaptırmak.
4. 12/4Veri sorumlusu ve veri işleyenin öğrendikleri veriyi açıklamaması; görevden ayrıldıktan sonra da.
5. 12/5Veriler hukuka aykırı yollarla başkalarınca elde edilirse ilgiliye ve Kurul'a en kısa sürede bildirim.

İdari tedbir “kim, neyi, hangi kurala göre yapar” sorusunun yazılı cevabıdır; teknik tedbir aynı kuralı insanların iyi niyetine bırakmadan sistemde zorlar. “Muhasebe personeli yalnız fatura verisine erişir” bir politika cümlesidir. ERP'de muhasebe rolünün yalnız ilgili ekran ve tablolara yetkiyle tanımlanması o cümlenin teknik karşılığıdır. Biri eksikse diğeri havada kalır.

İncelemelerde en sık gördüğümüz kopukluk tam burada. Erişim politikası “yetkiler üç ayda bir gözden geçirilir” diyor, son gözden geçirmenin tutanağı yok. İmha politikası “altı ayda bir periyodik imha” diyor, veritabanında yedi yıllık başvuru kayıtları duruyor. Bu durumda politika bir taahhüt metnine dönüşür ve aleyhinize okunabilir.

Sorumluluk dağılımını baştan netleştirmek işin yarısıdır. Aşağıdaki RACI tablosu (R: yapan, A: hesap veren, C: danışılan, I: bilgilendirilen) orta ölçekli bir şirketteki tipik dağılımı gösteriyor. Sizin yapınız farklı olabilir; tek kural, her satırda tek bir “A” bulunması.

Yazının geri kalanını okumadan önce mevcut durumunuzu işaretlemenizi öneririm; hangi bölüme ağırlık vereceğinizi böyle daha net görürsünüz. Araç 9 alanda 35 maddeyi “Var / Kısmen / Yok / Bize uygulanmaz” diye işaretletir ve her maddeyi ağırlığıyla puanlar. Var tam puan, Kısmen yarım puan, Yok sıfır puan alır; “uygulanmaz” işaretli maddeler hesaptan düşer.

Profil seçimi ağırlıkları değiştirir. Özel nitelikli veri işliyorsanız yetki, log, şifreleme ve uzaktan erişim maddelerinin ağırlığı 1,5 katına çıkar, çünkü 2018/10 kararı bu maddeleri doğrudan sayar. 50 çalışanın altındaki ölçekte alarm, sürekli tarama gibi birkaç maddenin ağırlığı bir kademe düşer; bulut ve SaaS ağırlıklı altyapıda ağ segmentasyonunun bir kısmını sağlayıcı üstlendiği için o maddenin ağırlığı azalır. Her eksik için ilk somut adımı ve denetimde göstereceğiniz kanıtı yazıyor, sonunda kopyalanabilir bir eylem planı üretiyor.

Koruyacağınız şeyin nerede durduğunu bilmeden yetki, log ya da şifreleme kuralı yazamazsınız. Hukuk ekibinin hazırladığı kişisel veri işleme envanteri veri kategorilerini, işleme amaçlarını, saklama sürelerini ve aktarımları sayar; VERBİS'e kayıtlıysanız oradaki beyanla da uyumludur. BT açısından eksik olan sütun neredeyse her zaman aynıdır: “bu veri fiziksel olarak nerede?” Hangi sunucu, hangi veritabanı, hangi tablo, hangi SaaS uygulaması, hangi yedek.

Bizim yöntemimiz iki listeyi birbirine bağlamak. Önce sistem envanteri çıkarılır: sunucular, veritabanları, dosya paylaşımları, Microsoft 365 veya Google Workspace, CRM, muhasebe/ERP, web sitesi formları, çağrı merkezi kayıtları ve yedek hedefleri. Sonra her veri kategorisi en az bir sisteme eşlenir. Sisteme eşlenemeyen kategori, envanterde olup bulunamayan veridir; ya gerçekten yoktur ya da birileri onu bir yerde tutuyordur. Hiçbir kategoriye eşlenmeyen sistem ise envantere hiç girmemiş veridir.

Veritabanı tarafında işe yarayan bir kestirme var: kolon adlarından aday kişisel veri alanlarını çıkarmak. Aşağıdaki sorgu PostgreSQL için yazıldı. SQL Server'da INFORMATION_SCHEMA.COLUMNS, MySQL ve MariaDB'de information_schema.columns üzerinde aynı arama LIKE koşullarıyla yapılır. Kolon adına tek başına güvenmeyin: incelediğim şemalarda aciklama ya da not alanına TCKN yazılan tablolar hiç az değildi. Sonucu her tablodan birkaç örnek kayda bakarak doğrulayın.

-- PostgreSQL: adı kişisel veri çağrıştıran kolonları listele
SELECT table_schema, table_name, column_name, data_type
FROM   information_schema.columns
WHERE  table_schema NOT IN ('pg_catalog', 'information_schema')
  AND  column_name ~* '(tckn|tc_no|kimlik|iban|telefon|gsm|eposta|email|adres|dogum|saglik|maas|plaka)'
ORDER  BY table_schema, table_name, column_name;

Örnek eşleme tablosu: kategoriler ve konumlar temsilidir; kendi sistem adlarınızla doldurun.

Envanteri güncel tutan dört tetikleyici

• 1.Yeni sistem veya SaaSSatın alma onayı, envanter güncellemesi tamamlanmadan verilmez.
• 2.Yeni form veya alanWeb formuna eklenen her alan için amaç ve saklama süresi sorulur.
• 3.Yeni tedarikçiVeri işleyen sözleşmesi ve erişim yöntemi envantere işlenir.
• 4.Yurt dışı aktarımVerinin gittiği ülke ve aktarım dayanağı hukukla birlikte kaydedilir.

Yetki matrisi; satırlarında roller, sütunlarında veri kategorileri bulunan ve her hücresinde o rolün o veriyle ne yapabildiğini yazan tablodur. Rehber'in teknik tedbirleri arasında doğrudan geçer ve incelemelerde istenen ilk belgelerden biridir. Değeri tablonun kendisinden değil, sistemdeki yetkilerle birebir örtüşmesinden gelir: matris “Satış: finans verisi yok” diyorsa ERP'de satış rolü cari bakiye ekranını açamamalıdır.

Hazırlarken üç ilkeye bağlı kalıyoruz. En az yetki: her rol görevini yapmaya yetecek en dar erişimi alır, “ileride lazım olur” yetkisi verilmez. Rol üzerinden atama: yetki kişiye değil role verilir, kişi role üye yapılır; Active Directory veya Entra ID grupları uygulama rolleriyle eşlenir. İşe giriş ve çıkışta tek bir grup üyeliğini değiştirmeniz yeter. Görevler ayrılığı: aynı kişi ödeme talimatını hem oluşturup hem onaylayamaz; aynı şekilde logları üreten sistem yöneticisi o logları silememelidir.

Okuma, yazma ve silmenin yanında iki yetkiyi ayrıca yazın: dışa aktarma (Excel/CSV indirme, toplu e-posta listesi çıkarma) ve toplu görüntüleme (tek kayıt yerine binlerce kaydı listeleme). Veri sızıntılarının önemli bir kısmı yetkisiz erişimden değil, yetkili kullanıcıya tanınmış geniş dışa aktarma imkânından doğar. Raporlama ihtiyacı için ham tablo yerine maskelenmiş bir görünüm (view) açmak bu riski ciddi biçimde daraltır.

Veritabanı katmanında uygulama hesabıyla insan hesabını ayırın. Uygulama tek bir servis hesabıyla bağlanır ve kullanıcı yetkisini uygulama içindeki rol kontrolü sağlar. Geliştirici veya raporcu ise kendi adına açılmış, salt okunur ve mümkünse maskelenmiş görünümlerle sınırlı bir hesapla bağlanır. Herkesin sa ya da root parolasını bildiği bir ortamda veritabanı logu tutmanın da anlamı kalmaz; loglar kimin ne yaptığını değil, “sa”nın ne yaptığını gösterir.

-- Raporlama rolü ham tabloya değil, maskelenmiş görünüme erişir
CREATE ROLE rapor_okuyucu NOLOGIN;

CREATE VIEW raporlama.musteri_maskeli AS
SELECT id,
       left(ad, 1) || '***'                        AS ad,
       left(tckn, 3) || '******' || right(tckn, 2) AS tckn,
       il,
       kayit_tarihi
FROM   public.musteri;

REVOKE ALL    ON public.musteri            FROM rapor_okuyucu;
GRANT  USAGE  ON SCHEMA raporlama          TO   rapor_okuyucu;
GRANT  SELECT ON raporlama.musteri_maskeli TO   rapor_okuyucu;

-- Yetki kişiye değil role verilir; kişi role üye yapılır
CREATE ROLE ayse_k LOGIN IN ROLE rapor_okuyucu;

Hesap yaşam döngüsü: dört an

1. 1İşe girişİK kaydı açıldığında rol grubu atanır. Kişiye özel istisna yetkisi talep formuyla, gerekçeli ve süreli verilir.
2. 2Görev değişikliğiEski rolün yetkileri yeni rol eklenmeden önce kaldırılır. 2018/10 kararı özel nitelikli veride bunu “derhal” ister.
3. 3İşten ayrılışSon iş gününde hesap devre dışı kalır: e-posta, VPN, SaaS, ERP, ortak parolalar ve fiziksel kart dahil. Liste İK'dan BT'ye otomatik bilet olarak gelir.
4. 4Periyodik gözden geçirmeBirim yöneticisi ekibinin yetki listesini onaylar. Örnek periyot: özel nitelikli ve finans verisinde 3 ay, diğerlerinde 6 ay.

Aşağıdaki üretici, kendi rol ve veri kategorilerinizle bir başlangıç matrisi kurmanızı sağlar. Hazır gelen şablon, sahada sık karşılaştığımız aşırı yetkili hâli bilerek içerir; uyarıları okuyup hücreleri düzelttikçe liste kısalır. Çıktıyı CSV veya Markdown olarak alıp gözden geçirme tutanağına ekleyebilirsiniz. Tüm işlem tarayıcınızda yapılır, hiçbir veri gönderilmez.

Çalınmış kimlik bilgisi, sahada en sık gördüğümüz ilk erişim yöntemi. Oltalama e-postasıyla toplanan veya başka bir siteden sızmış bir parola, MFA olmayan bir VPN'de ya da e-posta hesabında doğrudan çalışır. Çok faktörlü doğrulama bu senaryoyu büyük ölçüde keser, çünkü parolayı ele geçiren saldırganın ikinci faktöre de sahip olması gerekir. Kurul'un 2018/10 kararı, özel nitelikli verilere uzaktan erişimde en az iki kademeli kimlik doğrulamayı açıkça ister; diğer veriler için de beklentinin yönü aynıdır.

Her şeye aynı gün MFA açmak çoğu şirkette mümkün olmuyor, bu yüzden sırayı riske göre kuruyoruz. Önce dışarıdan erişilen kapılar: VPN, uzak masaüstü ağ geçidi, e-posta ve ofis paketi. Sonra yönetim panelleri: alan adı ve DNS paneli, hosting ve bulut konsolu, güvenlik duvarı arayüzü, yedekleme yazılımı. En son iç uygulamalar: ERP, CRM, İK yazılımı. Microsoft 365 tarafında güvenlik varsayılanları ile koşullu erişim arasındaki farkı ve hangi paketin neyi içerdiğini Microsoft 365 paket karşılaştırması yazımızda ayrıntılı anlattık.

1. 1. dalgaDışarıdan erişilen kapılarVPN, uzak masaüstü ağ geçidi, e-posta, ofis paketi, web tabanlı ERP girişi
2. 2. dalgaYönetim panelleriAlan adı ve DNS, hosting ve bulut konsolu, güvenlik duvarı, yedekleme, kimlik sağlayıcı yöneticileri
3. 3. dalgaİç uygulamalarERP, CRM, İK ve bordro, dosya paylaşımı, veritabanı yönetim araçları

Faktörün türü de fark yaratır. SMS ile gelen tek kullanımlık kod hiç yoktan iyidir, ama SIM kartın kopyalanması ya da kodun sahte giriş sayfasına girdirilmesi gibi yollarla aşılabilir; yönetici hesapları için tek başına yeterli saymıyoruz. Doğrulayıcı uygulama çoğu kullanıcı için makul dengedir; push onayı kullanılıyorsa “MFA yorgunluğu” saldırılarına karşı numara eşleştirme açık olmalıdır. FIDO2 güvenlik anahtarları ve passkey'ler oltalamaya dayanıklıdır; alan adı, bulut konsolu ve global yönetici hesaplarında öneriyoruz.

Parola politikasında uzunluk karmaşıklıktan daha değerlidir. NIST'in dijital kimlik kılavuzu (SP 800-63B) da karmaşıklık kuralları ve periyodik zorunlu değişiklik yerine uzunluğu ve sızmış parola kontrolünü öne çıkarır. Bizim önerimiz en az 12, mümkünse 15 karakterlik parola cümleleri, sızıntı tespit edildiğinde değişiklik, kurumsal parola yöneticisi ve ortak hesapların kaldırılması. Hizmet hesaplarının (yedek yazılımı, entegrasyon kullanıcısı, uygulamanın veritabanı hesabı) parolaları koda ya da depoya giren .env dosyasına yazılmamalı; bir sır kasasında tutulmalı ve bilen kişi ayrıldığında döndürülmelidir.

KVKK açısından log kaydının amacı, bir kişisel veriye kimin, ne zaman, hangi sistemden ve hangi işlemle eriştiğini sonradan gösterebilmektir. İhlal şüphesinde etkilenen kişi sayısını ve veri kategorisini belirlemenin, yani Kurul'a ve ilgililere doğru bildirim yapmanın başka yolu yoktur. Rehber erişim loglarını ve log kayıtlarını ayrı tedbirler olarak sayar; 2018/10 kararı özel nitelikli verilerdeki tüm işlemlerin güvenli biçimde loglanmasını ister.

Hangi katmanda log tutacağınız, verinin nerede durduğuna bağlıdır. Uygulama logu “ayse.k kullanıcısı 1043 numaralı müşteri kartını görüntüledi” bilgisini taşır ve en anlamlı olanıdır. Veritabanı denetim logu (PostgreSQL'de pgAudit, SQL Server'da SQL Server Audit, MariaDB'de audit eklentisi) uygulamayı atlayıp doğrudan atılan sorguları yakalar. İşletim sistemi, VPN, güvenlik duvarı ve kimlik sağlayıcı logları erişimin bağlamını verir: hangi IP'den, hangi cihazdan, MFA ile mi.

Logun kanıt değeri, değiştirilemez olmasına bağlıdır. Logları üretildikleri sunucuda bırakmak, o sunucuyu ele geçiren kişiye izlerini silme imkânı verir. Asgari düzen şu: loglar anlık olarak ayrı bir merkezi log sunucusuna veya SIEM'e gönderilir, orada yalnız ekleme yapılabilen ya da nesne kilidi (WORM, object lock) açık bir depolamada tutulur, log sunucusunun yöneticisi üretim sistemlerinin yöneticisinden ayrılır. Saat senkronizasyonu (NTP) da şart; saatleri birbirini tutmayan iki logla olay zinciri kuramazsınız.

Süre sorusunun dürüst cevabı: KVKK ve Rehber log kayıtları için sabit bir saklama süresi vermez. Süreyi logun amacına ve diğer mevzuata göre kendi saklama ve imha politikanızda gerekçesiyle belirlersiniz. Toplu kullanım sağlayıcı veya yer sağlayıcı sayılıyorsanız 5651 sayılı Kanun ve ilgili yönetmeliklerin trafik bilgisi için öngördüğü süreler ayrıca uygulanır; bu, KVKK erişim logundan farklı bir yükümlülüktür ve ikisini karıştırmamak gerekir. Sahada sık kurduğumuz denge, ayrıntılı uygulama ve veritabanı erişim loglarını bir ila iki yıl, özet güvenlik olaylarını daha uzun tutmak. Bu bir öneridir, mevzuat hükmü değildir.

Son kural sık unutulur: log, kişisel veri deposuna dönüşmemeli. Loga TCKN, kart numarası, parola, sağlık bilgisi veya tam istek gövdesi yazılırsa log sunucusu en hassas veritabanınız hâline gelir. Sızma testlerinde “hassas veri loglanıyor” bulgusunu düzenli görüyoruz: hata ayıklama için açılmış ayrıntılı log seviyesi canlıya taşınmış, uygulama her isteği müşteri bilgileriyle birlikte dosyaya yazıyordur. Ben aynı sorunu veritabanı tarafında daha sessiz bir hâliyle görüyorum: PostgreSQL'de bir performans incelemesi için log_statement = 'all' açılıp unutulursa, her INSERT içindeki TCKN ve telefonla birlikte sunucu loguna düşer. Çözüm, maskelemeyi log kütüphanesi seviyesinde yapmak (aşağıdaki örnek) ve veritabanında ayrıntılı sorgu logunu yalnız sınırlı süreli açmak.

// Önce: hata ayıklama seviyesinde canlıya taşınmış log satırı
{"ts":"2026-10-14T09:12:44+03:00","user":"ayse.k","action":"musteri.goruntule",
 "body":{"ad":"Mehmet Demir","tckn":"12345678901","iban":"TR120006400000112345678901"}}

// Sonra: kimlik ve işlem kalır, içerik maskelenir
{"ts":"2026-10-14T09:12:44+03:00","user":"ayse.k","action":"musteri.goruntule",
 "record_id":1043,"fields":["ad","tckn","iban"],"tckn":"123******01","ip":"10.20.4.17"}

Şifreleme üç yerde düşünülür: aktarımda, depolamada ve belirli alanlar için kullanım sırasında. Aktarımda şifreleme artık tartışma konusu değil. Web sitesi, API, e-posta sunucusu ve iç servisler arası bağlantılar TLS ile korunmalı, eski TLS 1.0 ve 1.1 kapatılmalı. Sertifika türlerini ve hangisinin ne zaman yeterli olduğunu SSL sertifikası türleri yazımızda anlattık; kurumsal sertifika tedarikini lisans satış hizmetimiz üzerinden yapıyoruz.

Depolamada şifreleme katmanlıdır ve her katman farklı bir tehdide karşı korur. Disk şifreleme (BitLocker, LUKS) çalınan dizüstü bilgisayara veya hurdaya çıkan diske karşı korur, ama çalışan sunucuda oturum açmış birine karşı bir şey yapmaz. Veritabanı seviyesinde şeffaf şifreleme (TDE) veri ve yedek dosyalarının kopyalanmasına karşı korur; uygulama üzerinden sorgu atan kullanıcı veriyi yine açık görür. Alan bazlı şifreleme (PostgreSQL'de pgcrypto, SQL Server'da Always Encrypted) TCKN ve sağlık bilgisi gibi tekil alanları veritabanı yöneticisinden bile saklar; bedeli arama, sıralama ve raporlamanın zorlaşmasıdır.

Anahtar yönetimi, şifrelemenin kendisinden daha çok hata üretir. Şifreleme anahtarı şifreli verinin yanında, aynı sunucudaki bir yapılandırma dosyasında duruyorsa sağlanan koruma çoğunlukla kâğıt üzerindedir. 2018/10 kararı özel nitelikli veride kriptografik anahtarların güvenli ve farklı ortamlarda tutulmasını ister: bulut sağlayıcının anahtar yönetim servisi (KMS), donanım güvenlik modülü (HSM) ya da en azından ayrı yetkiyle erişilen bir sır kasası. Anahtar döndürme ve anahtarın kaybolması senaryosu da yazılı olmalı; anahtarı kaybolmuş şifreli yedek, hiç alınmamış yedekle aynıdır.

Maskeleme, takma adlandırma ve anonimleştirme farklı işler görür. Maskeleme veriyi görüntüleyen kişiden gizler (çağrı merkezi ekranında TCKN'nin yalnız ilk ve son haneleri); veri arka planda tamdır. Takma adlandırma kimliği bir anahtarla değiştirir, anahtar varsa geri dönülebilir ve veri hâlâ kişisel veridir. Anonimleştirme ise kişiyle bağı geri dönüşü olmayacak biçimde koparır; doğru yapılmışsa sonuç artık kişisel veri değildir. Benim ekibimde en katı uyguladığımız kural şu: üretim verisi test veya geliştirme ortamına ham olarak kopyalanmaz; kopyalanacaksa önce maskelenir ya da sentetik veriyle değiştirilir. Aynı kural, çalışanların yapay zekâ araçlarına yapıştırdığı metinler için de geçerli; bunu ChatGPT ve şirket verisi yazımızda ayrıca ele alıyoruz.

Özel nitelikli veride aktarım kuralları (Kurul 2018/10)

• E-posta ile aktarım2018/10: şifreli olarak, kurumsal e-posta adresiyle veya KEP hesabıyla.
• Taşınabilir bellek, CD, DVDKriptografik yöntemle şifreli; anahtar farklı bir ortamda.
• Sunucular arası aktarımVPN kurularak veya sFTP ile.

Ağ tarafındaki amaç, bir noktadaki ihlalin kişisel verinin durduğu sunucuya kadar kolayca yayılmasını önlemektir. Düz bir ofis ağında misafir Wi-Fi'ye bağlanan telefon, muhasebe bilgisayarı ve veritabanı sunucusu aynı yayın alanındaysa tek bir zararlı yazılım hepsine ulaşır. Segmentasyon bu yolu böler: misafir ağı yalnız internete çıkar, ofis kullanıcıları sunuculara yalnız gerekli portlardan erişir, veritabanı yalnız uygulama sunucusundan gelen bağlantıyı kabul eder, internete açık servisler ayrı bir bölgede (DMZ) durur.

Güvenlik duvarı kurallarını “varsayılan olarak reddet, gerekeni aç” mantığıyla yazın ve her kurala bir sahip ile gerekçe ekleyin. Kural setini yılda en az bir kez gözden geçirmek, “geçici” diye açılıp yıllardır duran kuralları temizler. Dışarıdan erişilen servislerin listesini tutun ve düzenli tarayın: internete doğrudan açık uzak masaüstü (RDP), veritabanı portları (1433, 3306, 5432) ve yönetim panelleri, fidye yazılımı vakalarında en sık karşılaştığımız başlangıç noktalarıdır.

Yama yönetimi “otomatik güncellemeler açık” cümlesiyle bitmez; neyin ne kadar sürede güncellendiğini ölçmek gerekir. Kendinize hedef süreler koyun ve tutup tutmadığınızı aylık raporlayın. Aşağıdaki süreler bizim önerdiğimiz örnek başlangıç değerleri; sektörünüz veya müşteri sözleşmeleriniz daha sıkı süre şart koşabilir. Desteği bitmiş işletim sistemleri ve yazılımlar ayrı bir risk kaydıyla takip edilmeli, yamalanamayan sistem ağda izole edilmelidir.

Örnek / tahmini değerler: ekibimizin başlangıç önerisidir, mevzuat hükmü değildir.

Zararlı yazılım korumasında klasik antivirüsün yerini uç nokta algılama ve yanıt (EDR) çözümleri alıyor: imzaya değil davranışa bakar, şüpheli süreci durdurur ve olay kaydı üretir. Ölçeğinize uyan ürünler ve lisanslama seçenekleri için lisans satış ekibimizle görüşebilirsiniz. Sunucularınızı kendiniz yönetiyorsanız yeni bir Linux sunucunun ilk saatlerinde yapılacakları Linux sunucu güvenliği yazımızda adım adım anlattık. Altyapıyı yönetilen hizmet olarak almak isterseniz bulut sunucu ve dedicated sunucu seçeneklerimize, aralarındaki farka da hosting, VPS, bulut ve dedicated karşılaştırmamızda bakabilirsiniz.

12. maddedeki üçüncü amaç verinin muhafazasıdır; yani güvenlik yükümlülüğü verinin gizli kalmasıyla sınırlı değildir, kaybolmaması da bu yükümlülüğün parçasıdır. Fidye yazılımı veriyi şifrelediğinde ve geri dönülebilir bir yedek yoksa, bu bir erişilebilirlik ihlalidir ve bildirim değerlendirmesi gerektirebilir. Yedeklemeyi bu yüzden bir BT konforu olarak değil, kişisel veri tedbiri olarak belgeleyin.

Temel kural hâlâ 3-2-1: verinin en az üç kopyası, iki farklı ortamda, biri farklı bir konumda. Fidye yazılımı yaygınlaştıktan sonra buna iki madde eklendi: kopyalardan biri çevrimdışı veya değiştirilemez (immutable) olmalı ve geri dönüşler düzenli test edilip hatasız tamamlanmalı (3-2-1-1-0). Yedek sunucusunun etki alanına üye olması ve aynı yönetici parolasıyla erişilmesi, saldırganın yedekleri de silmesine yol açan klasik hatadır.

Geri dönüş testi yapılmamış yedek bir varsayımdır. Örnek takvim: her ay rastgele seçilen bir dosya veya tablo geri yüklenir, her çeyrekte tam bir sunucu ya da veritabanı ayrı ortamda ayağa kaldırılıp süresi ölçülür, yılda bir kez iş sürekliliği tatbikatı yapılır. Her testin tarihi, kapsamı, süresi ve sonucu kayda geçer. İncelemede gösterilecek kanıt bu kayıttır, yedekleme yazılımının “başarılı” bildirimi değil.

İmha tarafında Kişisel Verilerin Silinmesi, Yok Edilmesi veya Anonim Hale Getirilmesi Hakkında Yönetmelik iki rejim tanımlar. Saklama ve imha politikası hazırlamakla yükümlü olanlar (VERBİS'e kayıt yükümlülüğü bulunan veri sorumluları) verileri, silme yükümlülüğünün doğduğu tarihten sonraki ilk periyodik imhada siler; periyodik imha aralığı altı ayı geçemez. Politika yükümlülüğü olmayanlar için süre, yükümlülüğün doğmasından itibaren üç aydır. Her iki durumda da imha işlemleri kayıt altına alınır ve bu kayıtlar, diğer yasal yükümlülükler saklı kalmak üzere en az üç yıl saklanır.

-- Örnek periyodik imha işi: süresi dolan başvuruları anonimleştir
WITH hedef AS (
  SELECT id
  FROM   basvuru
  WHERE  durum = 'kapandi'
    AND  kapanis_tarihi < now() - interval '2 years'  -- politikadaki süre
    AND  anonim = false
)
UPDATE basvuru b
SET    ad = NULL, telefon = NULL, eposta = NULL, tckn = NULL, anonim = true
FROM   hedef
WHERE  b.id = hedef.id
RETURNING b.id;
-- Dönen kimlikler imha_kaydi tablosuna yöntem, tarih ve sorumluyla yazılır.

Yedekle imha arasında doğal bir gerilim var: canlı sistemden sildiğiniz kayıt, aylar önce alınmış yedekte durmaya devam eder. Yedekleri tek tek açıp kayıt silmek çoğu zaman pratik değildir. Uygulamada işe yarayan yol, yedek saklama süresini imha politikasıyla uyumlu tutmak ve yedekten geri dönüş yapıldığında silinmiş kayıtları yeniden silen bir prosedür yazmaktır; bu yaklaşımı politikada da açıkça belirtin. Veritabanı tasarlarken her tabloya saklama süresinin hesaplanabileceği bir tarih alanı koymak, imhayı otomatikleştirmenin en ucuz yoludur.

Verilerinizi sizin adınıza işleyen her firma (bulut sağlayıcı, CRM veya bordro yazılımı, bakım yapan yazılım şirketi, dış kaynak çağrı merkezi) KVKK'da veri işleyen sayılır ve 12. madde sizi tedbirlerin alınmasında onunla müştereken sorumlu tutar. Pratik sonucu açık: tedarikçinin zafiyeti sizin ihlalinizdir. Sözleşme ve teknik erişim düzeni bu sorumluluğu yönetmenin iki aracıdır.

Yurt dışında barındırılan bir SaaS kullanmak tek başına aykırılık değildir, ama yurt dışı aktarım rejimine uymanız gerekir. 12 Mart 2024'te Resmî Gazete'de yayımlanan ve 1 Haziran 2024'te yürürlüğe giren 7499 sayılı Kanun'la 9. madde yeniden düzenlendi. Aktarım artık yeterlilik kararına, Kurul'un ilan ettiği standart sözleşme, bağlayıcı şirket kuralları veya taahhütname gibi uygun güvencelere ya da sınırlı arızi hâllere dayanabiliyor. Standart sözleşme kullanılıyorsa imzadan itibaren beş iş günü içinde Kurum'a bildirilmesi gerekir. Hangi aracın size uyduğuna hukuk danışmanınızla karar verin; BT'nin görevi verinin hangi ülkede ve hangi alt işleyende durduğunu doğru raporlamaktır.

Yerel veri merkezi aktarım rejimini sadeleştirdiği için tercih sebebi olabilir, ama tek başına güvenlik garantisi değildir. Yerelde barındırılan, yaması yapılmamış ve yedeği olmayan bir sunucu, yurt dışında iyi yönetilen bir hizmetten daha risklidir. Karar verirken konumla birlikte erişim, log, şifreleme ve yedek sorularını da sorun.

Yazılımınızı dışarıdan geliştiriyorsanız güvenlik şartlarını sözleşmeye ve kabul kriterlerine yazın: OWASP ASVS gibi bir doğrulama standardı, teslim öncesi güvenlik testi, bağımlılık taraması, test ortamında gerçek veri kullanılmaması, kaynak kodun ve sırların teslimi. Web yazılım geliştirme ve API geliştirme projelerimizde bu maddeleri teklif aşamasında kapsama alıyoruz. Sağlık ve ödeme gibi özel nitelikli ya da finansal veri işleyen sistemlerde (sağlık randevu sistemleri, fintech ve ödeme sistemleri) bu şartlar pazarlık konusu olmamalı.

Sızma testi Rehber'deki teknik tedbirler arasında yer alır; 2018/10 kararı da özel nitelikli veri işlenen ortamlarda düzenli güvenlik testi yapılmasını ve sonuçlarının kayda alınmasını ister. Testin ne olduğu, nasıl kapsamlandığı ve hangi sıklıkla yapılacağı konusunu sızma testi rehberimizde ayrıntılı anlattık; bütçe tarafını sızma testi fiyatları yazısında ele alıyoruz. Burada tek bir soruya odaklanalım: test raporu kanıt dosyasında neyi kanıtlar?

Rapor tek başına bir zayıflık listesidir. Kanıt değeri taşıyan zincir üç parçadan oluşur: bulguları içeren rapor, her bulgunun kim tarafından ne zaman düzeltildiğini gösteren düzeltme kaydı ve düzeltmelerin doğrulandığı yeniden test sonucu (kapanış belgesi). İnceleyen taraf “kritik bulgu tespit edildi” cümlesinden çok, “kritik bulgu dokuz günde kapatıldı ve doğrulandı” kaydıyla ilgilenir. Yıllık sızma testi ile aradaki dönemi dolduran periyodik zafiyet taraması da birbirinin alternatifi değil, tamamlayıcısıdır. Güvenlik ve sızma testi çalışmalarımızda yeniden testi ve kapanış belgesini bu yüzden kapsamın parçası sayıyoruz.

Kurul incelemesi çoğunlukla bir ihlal bildirimi veya şikâyetle başlar ve sorulan soru özünde aynıdır: uygun tedbirleri almış mıydınız? Bu soruya ancak olaydan önce oluşmuş, tarihli kayıtlarla cevap verebilirsiniz; olaydan sonra yazılan politika bu soruyu cevaplamaz. Aşağıdaki kanıt dosyası, teknik tedbirler için hazır tutmanızı önerdiğimiz asgari setin bir örneği. Uyum skoru aracının eylem planındaki “kanıt” satırları da bu listeyle eşleşir.

ISO 27001 sıkça sorulan bir başlık. Sertifika KVKK uyumunu kendiliğinden sağlamaz ve Kanun'da bir muafiyet karşılığı yoktur. Ama bilgi güvenliği yönetim sistemi kurmuş bir şirketin risk değerlendirmesi, erişim kontrolü, log, tedarikçi ve olay yönetimi kayıtları, kanıt dosyasının büyük kısmını zaten üretir. Sertifikayı hedeflemeyen işletmeler için de ISO 27001 Ek A kontrolleri iyi bir kontrol listesidir.

Aşağıdaki maddeler, güvenlik değerlendirmelerinde ve sızma testlerinde tekrar tekrar karşımıza çıkan durumlar. Hiçbiri pahalı bir ürün gerektirmiyor. Çoğu, birkaç hafta boyunca birinin işi sahiplenmesiyle kapanıyor.

1. 1Politika var, sistemde karşılığı yokPolitika “yetkiler üç ayda bir gözden geçirilir” diyor, son tutanak iki yıl önce. Belgeye yazdığınız her periyodu takvime ve bilet sistemine bağlayın; uygulayamayacağınız periyodu yazmayın.
2. 2Paylaşılan yönetici hesabıadmin, muhasebe1, sa gibi birden fazla kişinin kullandığı hesaplar logları anlamsızlaştırır. Kişiye özel hesap açın; kalan ortak hesabı kimin aldığı loglanan bir sır kasasıyla kullanın.
3. 3Loglar aynı sunucuda ve silinebilirSaldırganın ilk işlerinden biri izlerini silmektir. Logları anlık olarak ayrı ve yalnız ekleme yapılabilen bir hedefe gönderin.
4. 4Test ortamında gerçek müşteri verisiCanlıdan alınmış tam yedek, zayıf parolalı ve internete açık bir test sunucusunda açılıyor. Test verisini maskeleyin veya sentetik veri üretin; test ortamını envantere ekleyin.
5. 5Ayrılan personelin hesabı açıkE-posta kapatılıyor ama VPN, CRM veya muhasebe programındaki hesap aylarca açık kalıyor. Çıkış listesini İK kaydına bağlayın ve SaaS uygulamalarını da kapsayın.
6. 6Hiç geri dönülmemiş yedekYedek yazılımı her gece “başarılı” diyor, ilk geri dönüş denemesi ihlal günü yapılıyor. Geri dönüş testini takvime koyun ve sonucunu kaydedin.
7. 7Şablon veri işleyen sözleşmesiİnternetten indirilmiş, tedbirleri “gerekli önlemler alınır” cümlesine indiren sözleşme hiçbir şeyi güvenceye almaz. Somut tedbir ekini, ihlal bildirim süresini ve alt işleyen listesini isteyin.

Uyum skorunuzdaki eksikleri bir plana bağlamak veya mevcut tedbirlerinizi sızma testiyle doğrulatmak isterseniz teklif formundan kapsamınızı paylaşın; dönüşümüzü güvenlik ekibimiz yapar.