Erişim denetim izi neden değiştirilemez olmalı?

Yetkiyi kim denetler?

Bir platformda kimlik bilgilerine erişebilen her yönetici, aynı zamanda bu erişimi kötüye kullanabilecek biridir. Bu bir güvensizlik ifadesi değil, her güvenlik tasarımının temel kabulüdür. Bir çalışanın merakla bir kullanıcının kimliğine bakması, bir eski çalışanın ayrılmadan önce kayıt dışa aktarması ya da ele geçirilmiş bir yönetici hesabı; bunların hepsi gerçek dünyada yaşanmış senaryolardır.

Erişim denetim izi, bu soruya verilen yanıttır: Yetkiyi kimse kendi başına denetleyemez, ama her kullanımı geride silinemez bir iz bırakırsa sonradan hesap sorulabilir. Takma adlı bir topluluk platformunda bu iz, kullanıcıya verilen gizlilik sözünün teknik teminatıdır.

Bu yüzden iz, bir güvensizlik beyanı olarak değil, ekibin kullanıcıya verdiği sözü tuttuğunu gösteren bir düzen olarak anlatılmalıdır. İz kurulduğunda, ekibe de kullanıcıya da aynı açıklıkla duyurulması, güvenin iki yönlü olduğunu hatırlatır. Kullanıcıya gizlilik sayfasında “kimliğinin her görüntülenişi gerekçesiyle kayıt altına alınır” demek, platformun kendi yöneticilerine de sınır koyduğunu açıkça gösterir.

İze neler yazılmalı?

Denetim izine yalnız kimlik açma işlemleri değil, hassas verilere dokunan her işlem yazılmalıdır: kimlik alanının gösterilmesi, oturum geçmişinin açılması, bir sohbet kaydının görüntülenmesi, teslim paketi üretilmesi, saklama süresi ayarının değiştirilmesi, bir rolün yetkilerinin değiştirilmesi ve verinin dışa aktarılması. Her kayıtta işlemi yapan yöneticinin kimliği ve rolü, hedef kullanıcı ya da kayıt, seçilen gerekçe, serbest not ve sunucu tarafında alınmış zaman damgası bulunur.

Gerekçe seçenekleri dar ve anlamlı tutulmalıdır. Kuytuna demosunda dört gerekçe vardır: yasal talep, suç şüphesi, kullanıcı başvurusu ve güvenlik incelemesi. “Diğer” seçeneği bilinçli olarak yoktur; çünkü her açık uçlu gerekçe, izin anlamını zayıflatır.

Değiştirilemezliğin teknik karşılığı

İzin değiştirilemez olması, uygulamada üç katmanla sağlanır. Birincisi, veritabanı düzeyinde iz tablosuna yalnız ekleme izni verilir; güncelleme ve silme yetkisi uygulama hesabından tamamen kaldırılır. İkincisi, her kayıt bir önceki kaydın SHA-256 özetini içerir ve kendi içeriğiyle birlikte yeni bir özet üretir; böylece zincirdeki herhangi bir halkanın değişmesi ya da silinmesi, sonraki tüm özetleri bozar. Üçüncüsü, zincirin belirli aralıklardaki özetleri ana sistemden bağımsız bir yere kopyalanır.

Bu üç katman birlikte, veritabanı yöneticisinin bile izi fark edilmeden değiştiremeyeceği bir yapı kurar. Panelde “zinciri doğrula” düğmesi, tüm kayıtların özetlerini yeniden hesaplayıp bir kopukluk olup olmadığını gösterir.

İz, yöneticiyi de korur

Denetim izi çoğu zaman yöneticilere yönelik bir gözetim aracı gibi algılanır, ama aslında en çok onları korur. Bir kullanıcı “bilgilerim izinsiz görüldü” diye başvurduğunda, iz hangi erişimin hangi gerekçeyle yapıldığını gösterir. Yetkisi içinde ve doğru gerekçeyle işlem yapan bir hukuk sorumlusunun bunu belgeleyebilmesi, kişisel bir güvencedir.

Aynı şekilde bir yetkili makam, belirli bir bilginin ne zaman ve hangi talep üzerine teslim edildiğini sorduğunda cevap tahminlere değil kayda dayanır. İz, işletmenin özen yükümlülüğünü yerine getirdiğini gösteren en somut belgedir.

İzin caydırıcı bir etkisi de vardır. Her erişimin kayda geçtiğini bilen bir yönetici, gerekçesiz bir merak anında durup düşünür. Bu, kimseyi suçlamadan, sistemin kendisinin iyi davranışı kolaylaştırması anlamına gelir. Ekibe izin varlığını ve nasıl çalıştığını açıkça anlatmak, bu etkinin ön koşuludur.

Düzenli aralıklarla izin bir örneklemini gözden geçirmek de önerilir. Örneğin her ay rastgele seçilen birkaç kimlik açma kaydının gerekçesi ve bağlı talep kaydı kontrol edilir. Bu kontrol, kötüye kullanımdan çok, gerekçe notlarının ne kadar özenli yazıldığını görmek için yararlıdır.

İzin kendisini kim görür?

Denetim izinin okunması da bir yetkidir ve bu yetki dar tutulmalıdır. Genellikle platform yöneticisi ve hukuk sorumlusu izi görebilir; moderatör, destek ve analitik rolleri göremez. İzin okunması da ayrı bir kayıt olarak tutulabilir. İzi dışa aktarmak gerektiğinde, dışa aktarılan dosyanın da özet değeri üretilmeli ve bu işlem iz içinde yer almalıdır.

İz, kullanıcının KVKK kapsamındaki başvurularında da işe yarar. Bir kullanıcı verilerinin kimlerle paylaşıldığını sorduğunda, iz bu soruya kesin bir cevap verilmesini sağlar.

Bu metin bir demo içindir; gerçek kurulumda hukukçu onayı gerekir. Briefikir, Kuytuna demosundaki zincirli denetim izini gerçek bir veritabanı üzerinde, yalnız ekleme izinli tablolar ve bağımsız özet kopyalarıyla kurabilir.

İzin saklama süresi de ayrıca belirlenmelidir. Denetim izi, ilişkili olduğu kayıtların saklama süresinden daha kısa tutulmamalıdır; aksi hâlde bir kaydın kim tarafından görüldüğü sorusu, kaydın kendisinden önce cevapsız kalabilir.

Sık yapılan hatalar

Denetim izi kuran ekiplerin en sık yaptığı hata, izi uygulama günlüğüyle aynı yere yazmaktır. Uygulama günlükleri döndürülür, sıkıştırılır ve belirli bir süre sonra silinir; denetim izi ise bu döngünün dışında kalmalıdır. İkinci hata, izi yalnız başarılı işlemler için tutmaktır. Oysa reddedilen bir kimlik açma denemesi ya da yetkisi olmayan bir rolün bir kayda erişmeye çalışması, en az başarılı işlemler kadar değerlidir.

Üçüncü hata, ize yazılan bilginin kendisinin hassas veri içermesidir. İz, hangi kullanıcının kimliğinin açıldığını iç kimlikle kaydetmeli, açılan e-posta adresini ya da gerçek adı ize kopyalamamalıdır. Aksi hâlde iz, kendisi korunması gereken yeni bir kişisel veri deposuna dönüşür.

Son olarak, yönetici hesaplarının paylaşılması izin anlamını tamamen ortadan kaldırır. Her yöneticinin kendi hesabı olmalı, hesaplar iki aşamalı doğrulamayla korunmalı ve işten ayrılan kişilerin erişimi aynı gün kapatılmalıdır. Paylaşılan bir hesapla yapılan bir erişimde iz “kim” sorusuna yanıt veremez.