Site Yönetiminde Yetki Matrisi: Kim, Neyi Görebilmeli?

Site yönetiminde yetkilendirme, bir kullanıcıya yalnızca “yönetici” veya “personel” etiketi vermek değildir. Doğru model; kişinin hangi siteye, hangi modüle, hangi kayıt kümesine ve hangi işlem düzeyinde erişeceğini ayrı ayrı tanımlar. Böylece finans sorumlusu tahsilat işini yürütebilirken ziyaretçi kayıtlarını gereksiz yere görmez; teknik görevli kendisine atanan iş emrini güncelleyebilirken bütün sakin ve banka kayıtlarını tarayamaz.

Pratik başlangıç kuralı şudur: rol + site kapsamı + veri/modül + işlem + süre + onay. Bu altı alanın biri eksikse yetki ya gereğinden geniş kalır ya da çalışan işini yapamaz. Yetki matrisi, bu kararları kişi hafızasından çıkarıp yönetilebilir ve denetlenebilir bir tabloya dönüştürür.

Kısa cevap: Site yönetiminde yetki matrisi nasıl hazırlanır?

1. Site yönetimindeki görevleri ve her görevin gerçekten kullandığı kayıtları çıkarın.
2. Kişi adları yerine yönetici, finans, operasyon, teknik ekip, güvenlik ve denetçi gibi rol şablonları oluşturun.
3. Her rol için erişilebilecek site, blok veya atanmış iş kapsamını belirleyin.
4. Her modülde görüntüleme, oluşturma, düzenleme, silme, dışa aktarma ve onay işlemlerini ayrı değerlendirin.
5. Kişisel ve finansal alanlarda maskeleme, kayıt kapsamı ve süre sınırı gerekip gerekmediğini yazın.
6. Yetki talep eden, onaylayan, uygulayan ve periyodik kontrol eden sorumluları ayırın.
7. Rolü gerçek senaryolarla; hem izin verilmesi hem reddedilmesi gereken işlemler üzerinden test edin.
8. İşe giriş, görev değişikliği, geçici vekâlet ve işten ayrılışta yetki yaşam döngüsünü çalıştırın.
9. Yetki değişikliklerini ve kritik işlemleri denetlenebilir kayıtlarla izleyin.

Bu tablo evrensel bir hukuki yetki listesi değildir. Yönetim planı, kurul kararları, sözleşmeler, veri işleme amaçları ve kurumun görev dağılımı somut yapı için ayrıca değerlendirilmelidir.

Kimlik doğrulama, rol, yetki ve işlem kaydı aynı şey değildir

Yetki tasarımındaki ilk hata, birbirinden farklı kontrolleri tek kavram gibi kullanmaktır.

Kavram	Yanıtladığı soru	Site yönetimi örneği
Kimlik doğrulama	Giriş yapan kişi gerçekten bu kullanıcı mı?	Finans sorumlusunun kendi hesabıyla oturum açması
Rol	Kişinin iş fonksiyonu nedir?	Finans, teknik ekip veya güvenlik
Kapsam	Bu rol hangi site veya kayıtlarla sınırlı?	Yalnızca A Sitesi ya da yalnızca atanmış iş emirleri
Yetki	Kayıt üzerinde ne yapabilir?	Görüntüle, düzenle, dışa aktar veya onayla
İşlem kaydı	Kim, ne zaman, hangi kapsamda ne yaptı?	Bir tahsilat düzeltmesinin kullanıcı ve zaman izi

Kullanıcının sisteme girebilmesi bütün verilere erişmesi gerektiği anlamına gelmez. Benzer biçimde işlem kaydı tutmak, yanlış verilmiş bir yetkiyi önceden engellemez; gerçekleşen kritik işlemi sonradan incelemeyi mümkün kılan ayrı bir kontroldür.

Yetki matrisinin altı boyutu

1. Rol: Kişi değil iş fonksiyonu

Yetkiyi “Ahmet’in erişimleri” şeklinde kurmak yerine “Finans sorumlusu” rolünde toplayın. Çalışan değiştiğinde yeni kişiye aynı doğrulanmış rol atanabilir; kişiye özel istisnalar görünür kalır. Rol adı, organizasyon kartvizitinden çok sistemde yürütülen işi tarif etmelidir.

2. Site kapsamı: Hangi yapı?

Profesyonel yönetim şirketlerinde aynı kullanıcı birden çok siteyle çalışabilir. Rol tek başına yeterli değildir; yetki hangi site, tesis, blok veya portföy için geçerli olduğu bilgisiyle birlikte atanmalıdır. A Sitesi finans sorumlusunun B Sitesi sakin, banka veya ziyaretçi kayıtlarını görmemesi ayrı bir kapsam kontrolüdür.

3. Modül ve veri türü: Neye erişim?

Finans, sakin kayıtları, talepler, iş emirleri, personel, ziyaretçi, duyurular, raporlar, kullanıcı yönetimi ve işlem kayıtlarını ayrı kaynaklar olarak ele alın. “Panele erişebilir” gibi geniş bir ifade, hangi verinin açıldığını anlatmaz.

4. İşlem düzeyi: Ne yapabilir?

Görüntüleme ile değiştirme aynı yetki değildir. Oluşturma, düzenleme, silme, içe/dışa aktarma, toplu işlem ve onay seçeneklerini ayrı sütunlara bölün. Özellikle finansal kayıtlar, kullanıcı/rol değişiklikleri ve toplu dışa aktarımlar için ikinci onay veya daha dar rol gerekebilir.

5. Kayıt ve alan kapsamı: Ne kadarını görebilir?

Teknik görevlinin bütün sakin listesini görmesi yerine yalnızca atanan iş emrindeki gerekli iletişim bilgisini görmesi yeterli olabilir. Denetçi toplam raporu incelerken tam telefon, IBAN veya ziyaretçi ayrıntısına ihtiyaç duymayabilir. Kayıt bazlı sınır ve alan maskeleme, modül erişiminin içindeki ikinci katmandır.

6. Süre ve koşul: Ne zamana kadar?

İzinli personelin yerine bir hafta görev alan kullanıcıya kalıcı rol vermeyin. Başlangıç/bitiş zamanı, gerekçe, onaylayan ve otomatik gözden geçirme tarihi ekleyin. Acil durumda açılan geniş yetki, olay kapandığında ayrıca geri alınmalıdır.

Örnek görev–erişim matrisi

Aşağıdaki tablo bir başlangıç örneğidir; otomatik uygulanacak standart değildir. “Sınırlı” hücresi, yalnızca görevin gerektirdiği kayıt veya alanın açılması gerektiğini ifade eder.

Rol	Önerilen kapsam	Finans	Sakin verisi	Talep / iş emri	Ziyaretçi
Site yöneticisi	Atanmış site	Özet görüntüleme; tanımlı onaylar	Görev için gerekli kayıtlar	Atama, düzenleme ve onay	Özet ve gerekli onay
Finans sorumlusu	Atanmış site	Tahakkuk, tahsilat, cari ve rapor işlemleri	Finans işlemi için gerekli alanlar	Gerekli finans özeti	Erişim yok
Operasyon sorumlusu	Atanmış site	Gerekli bütçe/özet görünümü	Talep için gerekli alanlar	Atama, düzenleme ve kapanış	Operasyon için gerekli görünüm
Teknik görevli	Atanmış iş emri ve alan	Erişim yok	İş için gerekli sınırlı iletişim	Atanmış işi görüntüleme ve güncelleme	Erişim yok
Güvenlik / danışma	Atanmış site ve vardiya	Erişim yok	Giriş kontrolü için sınırlı alanlar	İlgili bildirim görünümü	Oluşturma ve durum güncelleme
Denetçi	Onaylı site ve dönem	Salt okunur rapor	Gerektiğinde maskeli	Salt okunur	Gerektiğinde salt okunur

Yönetim kayıtlarının hangi kaynak, sorumlu ve kontrol zamanı ile tutulacağını önce apartman ve site yöneticisi kayıt rehberiyle çıkarın. Yetki matrisi bu kayıt envanterinin üzerine kurulmalıdır; sistemde bulunmayan veya amacı açıklanmayan bir veri için erişim kararı sağlıklı verilemez.

Site yönetiminde rol bazlı yetkilendirme adımları

Adım 1: Süreç ve veri envanterini çıkarın

Tahakkuk oluşturma, tahsilat işleme, banka hareketi inceleme, sakin talebi yanıtlama, iş emri kapatma, ziyaretçi kaydı oluşturma, duyuru gönderme ve rapor dışa aktarma gibi gerçek işleri listeleyin. Her iş için kullanılan veriyi, işin sahibini ve sonucu yazın.

Adım 2: Varsayılan erişimi kapalı kabul edin

Rolde açıkça tanımlanmayan bir modül veya işlem erişime açılmamalıdır. Yeni kullanıcı oluşturulduğunda önce site kapsamı ve rol atanmalı; “sonra daraltırız” yaklaşımıyla geçici tam yetki verilmemelidir.

Adım 3: Rol şablonunu kişiden bağımsız kurun

Her rol için amaç, sorumlu birim, modüller, işlem düzeyleri, veri alanları ve istisna onayı yazın. Aynı kişide birden fazla görev varsa rolleri birleştirmeden ayrı atayın; böylece hangi yetkinin hangi görevden geldiği görülebilir.

Adım 4: Site ve kayıt sınırını ekleyin

Rol şablonu “finans” olabilir; atama “A Sitesi finans” olmalıdır. Teknik ekip için sınır daha da daraltılarak atanmış iş emri, ekipman veya vardiya düzeyine indirilebilir. Çoklu site kullanımında başka siteye ait arama, doğrudan URL, dışa aktarma ve rapor sonuçları ayrıca test edilmelidir.

Adım 5: Kritik işlemlerde görev ayrımı yapın

Bir kişinin hem kendi rolünü genişletmesi hem de bu yetkiyle mali kaydı oluşturup onaylaması kontrolü zayıflatır. Yetki talebi, onayı ve teknik ataması mümkünse farklı sorumlular tarafından yürütülmelidir. Küçük yapılarda kişi sayısı sınırlıysa en azından ikinci kontrol, zaman ayrımı ve işlem kaydı kullanılmalıdır.

Adım 6: Olumlu ve olumsuz test senaryoları çalıştırın

“Finans kullanıcısı tahsilatı görebiliyor mu?” olumlu bir testtir. “Finans kullanıcısı ziyaretçi listesini, başka siteyi veya kullanıcı rolü ekranını açamıyor mu?” olumsuz testtir. Yalnızca menünün görünmemesine güvenmeyin; doğrudan bağlantı, arama, rapor ve dışa aktarma yollarını da sınayın.

Adım 7: Onay kaydıyla canlıya alın

Rol adı, kapsam, izinler, talep eden, onaylayan, uygulayan, başlangıç tarihi ve ilk gözden geçirme zamanını kaydedin. Bir yazılıma geçiş sırasında örnek kullanıcılarla prova yapmak için 30 günlük site yönetim yazılımı geçiş planını kullanabilirsiniz.

KVKK açısından yetki matrisi neden önemlidir?

Kişisel Verileri Koruma Kurumunun güncel Kişisel Veri Güvenliği Rehberi, veri sorumlularının değerlendirebileceği teknik tedbirler arasında yetki matrisi, yetki kontrolü, erişim logları, kullanıcı hesap yönetimi ve veri maskelemeyi ayrı başlıklar halinde sayar. Bu başlıklar tek başına uyum garantisi değildir; verinin niteliği ve işlendiği ortam dikkate alınarak somut tedbirler belirlenmelidir.

Kurulun site yönetimlerine ilişkin 22 Temmuz 2020 tarihli 2020/560 sayılı karar özeti, veri sorumlusu sıfatının belirlenmesinde her somut olayda kişisel veri işleme kararlarını alan, veri kayıt sistemini kuran, elinde bulunduran ve yöneten birimlerin tespit edilmesi gerektiğini belirtir. Bu nedenle “yazılımı kullanıyoruz, sorumluluk tamamen yazılım şirketindedir” veya “yönetici her durumda tek başına veri sorumlusudur” gibi genellemeler yapılmamalıdır.

TÜBİTAK-BİLGEM tarafından hazırlanmış resmî Güvenli Yazılım Geliştirme Kılavuzu da rol bazlı yetkilendirmeyi, kullanıcıların yetkilerinin raporlanabilmesini ve seçilmiş işlevlerde erişim testleri yapılmasını önerir. Yetki matrisi yalnızca yönetim prosedürü değil, uygulamanın fiilen uygulaması ve test etmesi gereken bir kontroldür.

Bu bölüm genel bilgilendirmedir; hukuki görüş değildir. Veri sorumlusu/veri işleyen rolleri, işleme şartı, saklama süresi, erişim kapsamı ve alınacak tedbirler kendi organizasyonunuz ve somut veri işleme faaliyetiniz için hukuk ve bilgi güvenliği uzmanlarıyla değerlendirilmelidir.

Yetki yaşam döngüsü nasıl yönetilir?

Olay	Yapılacak kontrol	Kanıt
İşe veya göreve başlama	Onaylı rol ve site kapsamı atama	Talep, onay ve başlangıç zamanı
Görev değişikliği	Eski rolü kaldırıp yeni rolü atama	Önce/sonra yetki raporu
Geçici vekâlet	Süreli ve gerekçeli ek yetki	Bitiş zamanı ve otomatik kontrol
İzin / askıya alma	İhtiyaca göre hesabı veya kritik yetkiyi durdurma	Başlangıç ve dönüş kaydı
İşten ayrılma	Hesabı kapatma, aktif oturum ve anahtarları sonlandırma	Kapanış kontrol listesi
Periyodik gözden geçirme	Kullanıcı–rol–site–izin karşılaştırması	Onaylı erişim raporu ve istisna listesi

Periyodik kontrol aralığını veri riski, çalışan değişimi ve işlem hacmine göre belirleyin. Yalnızca yılda bir kez kontrol etmek yerine görev değişikliği ve ayrılış olaylarını anlık tetikleyici olarak kullanın. Kullanılmayan hesapları, süresi dolmuş geçici rolleri ve uzun süredir çalışmayan istisna yetkilerini ayrıca inceleyin.

Yetki değişiklikleri ve kritik işlemler nasıl izlenmeli?

İşlem kaydında en az kullanıcı, zaman, site/kapsam, işlem türü, hedef kayıt ve istek/işlem kimliği bulunması incelemeyi kolaylaştırır. Yetki değişikliğinde eski ve yeni durum ile onay gerekçesi de korunmalıdır. Logların yalnızca üretilmesi değil, yetkili kişilerce aranabilir ve düzenli gözden geçirilebilir olması gerekir.

Şu olaylar öncelikli izleme listesine alınabilir:

• Yeni kullanıcı oluşturma ve hesabı yeniden etkinleştirme.
• Rol atama, rol kapsamını genişletme veya kaldırma.
• Başka siteye erişim veren kapsam değişikliği.
• Toplu veri dışa aktarma veya rapor indirme.
• Finansal kaydı oluşturma, düzeltme, silme veya onaylama.
• Sakin ve ziyaretçi kayıtlarında toplu değişiklik.
• İşlem kayıtlarına erişim ve log ayarı değişikliği.

Sık yapılan yetkilendirme hataları

1. Ortak kullanıcı hesabı: Kimin işlem yaptığı ayırt edilemez.
2. Herkese yönetici rolü: Kolay kurulum uğruna gereksiz veri ve işlem erişimi açılır.
3. Rol var, site kapsamı yok: Çoklu portföyde bir kullanıcının diğer siteleri görmesi mümkün hale gelir.
4. Menüyü gizlemeyi güvenlik sanmak: Doğrudan bağlantı, API, arama veya dışa aktarma yolu açık kalabilir.
5. Görüntüleme ile dışa aktarmayı birleştirmek: Ekranda sınırlı erişim alan kullanıcı toplu dosya indirebilir.
6. Yetki yöneticisine sınırsız iş verisi açmak: Kullanıcı/rol yönetimi için bütün finans ve sakin verisini görmek gerekmeyebilir.
7. Geçici yetkiyi kalıcı bırakmak: Vekâlet veya proje bittikten sonra erişim devam eder.
8. Görev değişiminde eski rolü tutmak: Kullanıcı zamanla birbiriyle ilgisiz yetkiler biriktirir.
9. Log var diye onayı kaldırmak: Kayıt, önleyici kontrolün yerine geçmez.
10. Sadece başarılı işlemleri test etmek: Reddedilmesi gereken erişimler denenmez.

Liyova ile rol ve site kapsamı nasıl ele alınır?

Liyova Yetki ve Rol Yönetimi; rol şablonları, yetki matrisi, site kapsamı ve işlem kaydı bağlantısını aynı erişim tasarımında ele alır. Bu kapsam, bir personele yalnızca görev yaptığı site ve işlemler için rol atamayı planlamaya yardımcı olur; somut izinlerin doğruluğu yine yönetimin görev ve risk analizine bağlıdır.

Liyova Personel, personel kartlarını rol bağlantısı ve operasyon görevleriyle ilişkilendirmek için tasarlanmıştır. Liyova İşlem Kayıtları ise kritik işlemleri kullanıcı, zaman, kapsam ve istek bilgisiyle izleme bağlamı sunar. Rol ataması, personel görevi ve işlem izi birbirini tamamlar; biri diğerinin yerine geçmez.

Bir sistemi satın almadan önce hazır rol adlarına değil, kendi test kullanıcılarınıza bakın. Finans kullanıcısının yalnızca atanmış sitede çalıştığını, teknik görevlinin yalnızca kendi işini güncellediğini, güvenliğin finans verisine ulaşamadığını ve denetçinin kayıtları değiştiremediğini doğrulayın. Bu senaryoları daha geniş değerlendirmeye eklemek için site yönetim programı seçme rehberini kullanın.

Canlıya almadan önce kontrol listesi

• Her kullanıcı benzersiz bir hesapla mı çalışıyor?
• Rol adları kişi isimlerinden bağımsız mı?
• Her rolün iş amacı ve sahibi tanımlı mı?
• Site, blok, portföy veya atanmış kayıt kapsamı yazılı mı?
• Görüntüleme, düzenleme, silme, dışa aktarma ve onay ayrı mı?
• Kişisel ve finansal alanlarda maskeleme ihtiyacı değerlendirildi mi?
• Yetki talep eden, onaylayan ve uygulayan belli mi?
• Kullanıcı kendi rolünü genişletebiliyor mu; engellenmesi gereken yollar test edildi mi?
• Başka siteye doğrudan bağlantı, arama, rapor ve dışa aktarma denendi mi?
• Geçici yetkilerin başlangıç ve bitiş zamanı var mı?
• Görev değişikliği ve ayrılış kontrol listesi hazır mı?
• Yetki değişiklikleri kullanıcı, zaman, kapsam ve gerekçeyle izleniyor mu?
• İlk periyodik gözden geçirme tarihi atandı mı?
• Yönetim planı, kurul kararları ve veri sorumluluğu değerlendirmesiyle çelişen bir erişim var mı?

Kendi ekibiniz ve site yapınız için rol–kapsam–işlem senaryolarını birlikte test etmek isterseniz Liyova demo talebi oluşturun.

Sık sorulan sorular

Yetki matrisi nedir?

Rolleri; site, modül, kayıt ve işlem düzeyleriyle eşleştiren kontrol tablosudur. Kimin neyi görüntüleyebileceğini, değiştirebileceğini, dışa aktarabileceğini veya onaylayabileceğini görünür hale getirir.

Rol bazlı yetkilendirme ile kullanıcı bazlı yetki arasındaki fark nedir?

Rol bazlı modelde izinler iş fonksiyonlarında toplanır ve kullanıcıya rol atanır. Kullanıcı bazlı istisna gerekebilir; ancak çok sayıda kişisel istisna, görev değişikliklerini ve periyodik kontrolü zorlaştırır.

Site yöneticisi her şeyi görebilmeli mi?

Hayır, otomatik olarak değil. Yönetici rolünün kapsamı yönetim planı, kurul kararları, görevler, veri işleme ihtiyacı ve riskler temelinde belirlenmelidir. Sistem yönetme yetkisi, her kişisel veya finansal alanı sınırsız görme gereği doğurmaz.

Teknik personel sakin telefonlarını görebilir mi?

Görevin yürütülmesi için iletişim gerekiyorsa yalnızca ilgili iş emri ve gerekli alanlarla sınırlı erişim tasarlanabilir. Bütün sakin rehberinin açılması yerine görev bazlı ve süreli görünüm değerlendirilmelidir.

Denetçi hangi yetkilere sahip olmalı?

Denetçinin görevi ve onaylı inceleme kapsamına göre salt okunur rapor ve işlem kaydı erişimi verilebilir. Kayıt değiştirme, silme veya yetki atama genellikle denetim işlevinden ayrı tutulmalıdır; kesin kapsam somut yetki ve sorumluluklara göre belirlenir.

Yetkiler ne sıklıkla gözden geçirilmeli?

Risk düzeyine göre periyodik bir takvim kurulmalı; işe giriş, görev değişikliği, geçici vekâlet ve ayrılışta takvim beklenmeden kontrol yapılmalıdır. Kritik veya geniş kapsamlı roller daha sık incelenebilir.

İşlem kaydı tutmak tek başına yeterli mi?

Hayır. İşlem kaydı izlenebilirlik sağlar; doğru rol, kapsam, onay ve erişim testlerinin yerine geçmez. Önleyici yetki kontrolleri ile sonradan incelemeye yarayan loglar birlikte tasarlanmalıdır.