Çalışan verisi ve yetki modeli: kim neyi görebilmeli?

Bir intranette en hassas soru, kimin neyi görebileceğidir. Fazla açık bir yapı gizlilik ihlali üretir; fazla kapalı bir yapı ise sistemi kullanılamaz hâle getirir ve insanlar bilgiyi başka kanallardan paylaşmaya başlar.

Denge, veri türüne göre farklı kurallar tanımlamakla kurulur.

Rol tabanlı temel

Çoğu şirket için dört seviyelik bir rol yapısı yeterlidir:

Çalışan. Kendi bilgilerini görür, herkese açık içeriği okur, talep oluşturur. Editör. İçerik üretir ve yayımlar; kişi ve organizasyon ayarlarına dokunamaz. Yönetici. Kullanıcı, departman ve ayarları yönetir; İK süreçlerini görür. Sahip. Her şeyi yapar, faturalama ve devir yetkisi vardır.

Bu yapının kritik ayrıntısı, editör rolünün sınırıdır: içerik tablolarında yönetici kadar yetkilidir, ama insan verisine ve hassas süreçlere erişemez. İç iletişim ekibinin bordro görmesi gerekmez.

Veri türüne göre görünürlük

Herkese açık. Ad, unvan, departman, kurumsal e-posta, dahili numara, yönetici bilgisi, fotoğraf. Bu bilgiler rehberin işlevi için gereklidir.

Sınırlı. Kişisel telefon, doğum tarihi, acil durum kişisi. Genellikle yalnızca İK ve doğrudan yönetici görmeli; çalışan kendi tercihine göre bir kısmını açabilmeli.

Gizli. Ücret, bordro, performans notları, disiplin kayıtları, sağlık bilgileri. Yalnızca İK ve zorunlu hâllerde ilgili yönetici.

Anonim. Etik ihbarlar, anonim anket cevapları. Kimlik hiç kaydedilmemeli.

Son kategori tasarım açısından farklıdır: gizlilik bir yetki kuralıyla değil, verinin hiç toplanmamasıyla sağlanır. Anonim bir bildirimde kimliği kaydedip sonra gizlemek, gizlilik değil güven riskidir.

En az yetki ilkesi

Temel kural şudur: her kişi işini yapmak için gereken en az yetkiye sahip olmalıdır.

Pratikte bunun tersi olur: yeni bir rol tanımlanırken "her ihtimale karşı" geniş yetki verilir ve daraltılması unutulur. Zamanla herkes her şeyi görebilir hâle gelir.

Bunu önlemenin yolu, yetki tanımlarının düzenli gözden geçirilmesidir. Yılda iki kez yapılacak bir denetim yeterlidir: kim hangi yetkiye sahip, hâlâ gerekli mi?

Özellikle rol değiştiren çalışanlarda birikme olur: yeni rolün yetkileri eklenir, eskininkiler kaldırılmaz. Bu, kurumsal sistemlerdeki en yaygın yetki sorunudur.

Yönetici erişimi

Yöneticinin kendi ekibinin bilgilerine erişmesi doğaldır ama sınırı çizilmelidir. "Kendi ekibi" tanımı da netleşmelidir: doğrudan raporlar mı, alt kademeler dahil mi?

Ücret bilgisi özel bir durumdur. Bazı şirketler yöneticiye ekibinin ücretini gösterir (bütçe yönetimi için gerekli), bazıları göstermez. Karar şirkete aittir ama yazılı olmalıdır ve teknik olarak da uygulanmalıdır.

Kısıtlar nerede uygulanmalı?

En kritik teknik ilke budur: yetki kısıtları arayüzde değil, veri katmanında uygulanmalıdır.

Bir alanı ekranda gizlemek, verinin gönderilmesini engellemez. Tarayıcının ağ trafiğine bakan biri, gizlenmiş alanı görebilir. Aynı şekilde bir düğmeyi gizlemek, o işlemin çağrılamayacağı anlamına gelmez.

Doğru tasarımda arayüz, veri katmanındaki kuralın aynasıdır: gizlenen şey zaten gönderilmiyordur. Bu ilkeyi çok kiracılı mimari ve veri izolasyonu yazısında ayrıntılandırdık.

Kendi kendine yetki artırma engellenmelidir

Kullanıcının kendi rolünü, unvanını ya da yöneticisini değiştirebilmesi ciddi bir açıktır. Bu tür kısıtların veritabanı seviyesinde zorlanması gerekir: kullanıcı kendi rolünü yükseltemez, kendi yöneticisini değiştiremez, sahibin rolü düşürülemez.

Bunlar arayüzde de gizlenmeli ama asıl kısıt veri katmanında olmalıdır.

Denetim kaydı

Yetki modelinin üçüncü ayağı, kimin neye eriştiğinin kaydıdır. Özellikle hassas verilere erişim ve yetki değişiklikleri kayıt altında olmalıdır.

Bu kaydın iki işlevi vardır: bir olay incelemesinde ne olduğunu göstermek ve caydırıcılık sağlamak. Erişimin kayıt altında olduğunu bilmek, gereksiz merak kaynaklı erişimleri belirgin biçimde azaltır.

KVKK açısından da erişim kayıtlarının tutulması, veri güvenliği yükümlülüğünün bir parçasıdır; çerçevesini KVKK uyumlu intranet yazısında ele aldık.

Geçici yetkiler

Bazı yetkiler kalıcı olmamalıdır: bir denetim döneminde verilen erişim, bir proje süresince açılan görünürlük, izne çıkan bir yöneticinin yerine bakan kişiye verilen onay yetkisi.

Bu yetkiler verilirken bitiş tarihi de tanımlanmalıdır. Süreli yetki desteklenmiyorsa, en azından bir hatırlatma bırakılmalı ve süre sonunda kaldırılmalıdır.

Uygulamada geçici yetkilerin kalıcılaşması, yetki şişmesinin en büyük kaynağıdır.

Yetki isteme süreci

Yetki taleplerinin nasıl yapılacağı tanımsızsa, insanlar tanıdıkları kişiden şifahen ister ve kayıt kalmaz.

Basit bir talep akışı bunu düzeltir: kim istiyor, hangi yetki, hangi gerekçe, kim onayladı. Bu kaydın olması, hem denetim hem de sonraki gözden geçirmeler için gereklidir.

Gerekçe alanının zorunlu olması, gereksiz taleplerin bir kısmını daha talep aşamasında eler.

Rol değişikliğinde tetikleyici

Yetki temizliğinin en doğal anı, çalışanın rolü değiştiğidir. Bu an bir tetikleyici olarak tanımlanmazsa, eski yetkiler birikir.

Otomatik bir kural — departman ya da unvan değiştiğinde İK'ya ve BT'ye yetki gözden geçirme görevi atanması — bu birikmeyi yapısal olarak engeller.

Şeffaflık güven kurar

Yetki modelinin çalışanlara anlatılması, gizlilik kaygısını azaltır. Kimin neyi görebildiği yazılı ve açıksa, çalışan bilgilerinin nasıl korunduğunu bilir.

Tersine, belirsiz bir yetki modeli her zaman en kötü varsayımı üretir: "herhalde herkes her şeyi görüyor". Bu varsayım, sisteme veri girmekten kaçınmaya yol açar.