CRM Yetki Matrisi: Kim Hangi Müşteri Verisini Görebilir?

Rol, kapsam ve işlemi üç ayrı sütunda düşünün

Rol kişinin işini anlatır; kapsam erişebildiği kayıt grubunu, işlem ise o kayıtlarla ne yapabileceğini belirler. Bir temsilci kendi müşterisini okuyabilir ama dışa aktaramayabilir. Bölge yöneticisi ekibinin kayıtlarını görebilir fakat başka bölgenin fiyat anlaşmalarına erişmeyebilir. Bu ayrımlar tek bir açık-kapalı anahtarına sığmaz.

Microsoft Dataverse güvenlik yaklaşımı da kayıtlarla ilgili ayrıcalıklar ve erişim kapsamları arasında ayrım yapar. [1] Bu örneği kendi yazılımınıza uyarlarken platform davranışını aynen kopyalamak yerine işletmenin veri sahipliği modelini yazın. Bir kullanıcının birden fazla rol taşıması durumunda birleşik yetkinin ne olacağı özellikle incelenmelidir.

Hassas alanları kayıttan ayrı değerlendirin

Müşteri kartı görülebilirken özel indirim oranı veya iç değerlendirme notu gizli kalabilir. Alan düzeyindeki erişimi yalnızca ekranda saklamayla çözmeyin. API yanıtı, arama sonucu, bildirim, rapor ve dışa aktarma aynı sınıra uymalıdır. Aksi halde gizlenen alan başka bir kanaldan açığa çıkabilir.

OWASP, yetkilendirme kararlarının her istekte doğrulanmasını ve varsayılan reddetme yaklaşımını önerir. [2] Tasarımda bu ilkeleri hangi katmanın uyguladığı açık olsun. Kullanıcı arayüzünün gönderdiği müşteri veya ekip kimliği tek başına güvenilir erişim kanıtı sayılmamalıdır.

Örnek: temsilci değişen müşteri portföyü

Varsayımsal müşterinin sorumlusu A temsilcisinden B temsilcisine geçiyor. Eski temsilcinin müşteriyi görmeye devam edip etmeyeceği bir iş kararıdır; otomatik varsayılmamalıdır. Açık görevler, teklifler ve eski notlar da devir planına dahil edilmelidir. Sadece müşteri kartındaki sahip alanını değiştirmek bütün ilişkileri çözmeyebilir.

Tablo önerilen bir başlangıçtır; her işletmeye aynı şekilde uygulanmamalıdır. Örneğin ortak hesap yönetimi varsa bir müşterinin birden fazla sorumlusu olabilir ve kayıt sahipliği tek kullanıcıdan daha geniş modellenmelidir.

Dışa aktarma erişimini ayrıca sınayın

Bir kullanıcının ekranda elli kayıt görmesi ile tüm müşteri listesini dosya olarak indirebilmesi aynı risk değildir. Dışa aktarma yetkisi, alan kapsamı ve dosyanın erişilebilirliği ayrı kontrol edilmelidir. Geçici indirme bağlantılarının ne kadar süre geçerli olduğu ve dosyanın kimlerle paylaşılabileceği belirlenmelidir.

Testte kullanıcıya görünmeyen bir müşterinin kimliğini doğrudan isteğe koyun. Arama, rapor ve toplu işlem uç noktalarını da deneyin. Sadece tekil müşteri sayfasında çalışan yetki kontrolü yeterli kabul edilmemelidir.

Yönetici hesabını sınırsız çözüm olarak kullanmayın

Sistem yöneticisi ile ticari yönetici aynı role sahip olmak zorunda değildir. Teknik destek için geçici erişim veriliyorsa gerekçe, süre ve yapılan işlemler kaydedilebilir. Kalıcı geniş yetkiler yerine ihtiyaçla sınırlı erişim tasarlamak daha denetlenebilir bir yaklaşımdır.

Personel ayrılışında oturumlar, bağlı cihazlar ve otomatik entegrasyon erişimleri gözden geçirilmelidir. Bir hesabı pasif yapmak arka plandaki bütün erişim yollarının sona erdiğini otomatik olarak kanıtlamaz. Kullanılan kimlik altyapısının gerçek davranışı test edilmelidir.

Teslim paketi bir yetki tablosundan fazlası olsun

Rol matrisi, örnek kullanıcılar ve olumlu-olumsuz testler birlikte teslim edilsin. Her rol için yapılabilen işlemler kadar reddedilmesi gereken işlemler de tanımlansın. Yetki değişikliklerinin kim tarafından yapıldığı ve hangi kullanıcıları etkilediği izlenebilsin.

Yeni rol eklendiğinde mevcut testler yeniden çalıştırılmalıdır. Bir role erişim vermek başka bir rolün sınırlarını istemeden genişletmemelidir. Kabul toplantısında gerçek müşteri bilgileri yerine sentetik kayıtlar kullanın; erişim tasarımını test etmek için canlı veriyi gereksiz yere çoğaltmayın.

Sık sorulan sorular

### Kullanıcıya menüyü göstermemek yeterli mi? Hayır. İstek doğrudan API’ye veya dosya bağlantısına yapılabilir. Yetki, sunucu tarafında ve ilgili veri erişim yollarında doğrulanmalıdır.

Küçük ekipte de yetki matrisi gerekir mi?

Matris daha sade olabilir, fakat erişim sınırlarının yazılı olması yine faydalıdır. Ekip büyüdüğünde veya dış destek eklendiğinde varsayımların hataya dönüşmesini önler.