Bu rehberi bitirdiğinizde, "neden bu danışman bu hastayı göremiyor?" ya da "bu kişi nasıl tüm kayıtları silebilmiş?" sorularıyla saatler kaybetmenizi önleyecek bir zihin haritasına sahip olacaksınız. Zoho CRM'de bir kullanıcının bir kayda erişimi tek bir kutucuğa değil, üst üste binen birkaç katmanın ortak sonucuna bağlıdır. Aşağıda bu katmanları tek tek açıyor, butik medikal klinik ve çok şubeli KOBİ ölçeğindeki ekiplerin gerçek günlük akışlarıyla örnekliyor; en sonda da yıllar içinde en sık düzeltmek zorunda kaldığımız hataları baştan önleyecek bir kurulum sırası bırakıyoruz. Amaç teorik bir güvenlik dersi değil, ekibiniz büyüdükçe geri toplaması zor olmayan sürdürülebilir bir erişim modeli kurmak.
Erişim neden tek bir ayara bakmaz
Güvenlik tarafında en pahalı hata, erişimi tek bir düğme zannetmektir. Gerçekte bir kullanıcının bir kaydı görüp göremediği, dört ayrı katmanın kesişiminden çıkar. Bu katmanları zihninizde net tuttuğunuzda, ileride çıkacak "kim neyi göremiyor" sorunlarını dakikalar içinde çözersiniz.
Önce bir ayrımı oturtalım: Zoho CRM'de veri iki tür modülde yaşar. Birden çok ekibin ortak kullandığı kurum modülleri (örneğin Kişiler / Contacts) ve yalnızca tek bir ekibe ait ekip modülleri (örneğin satış öncesi demo takip modülü). Erişim mantığı bu ikisinde aynı çalışmaz; ayrımı baştan bilmek karışıklığı önler.
Çalışma Alanı
Kullanıcı önce ilgili teamspace'e eklenmiş olmalı. Hiçbir modüle bu kapıdan geçmeden erişilmez.
Profil
Hangi eylemleri yapabileceğini (görüntüle, oluştur, düzenle, sil, içe/dışa aktar) profil belirler.
Hiyerarşi
Rol veya raporlama hiyerarşisi, hangi kayıtları görebileceğini belirler.
Paylaşım
Manuel paylaşım, paylaşım kuralları, gruplar ve bölgeler erişimi noktasal genişletir.
Kurum modüllerinde varsayılan davranış özeldir (private): bir kayıt yalnızca sahibine ve hiyerarşide ondan üstte olanlara görünür. İhtiyaç olursa bir modülün varsayılanını "herkese salt-okunur", "herkese okuma/yazma" ya da "herkese okuma/yazma/silme" yapabilirsiniz. Tüm ekibin ürün kataloğunu görmesi gibi gerçekten ortak bir veride bu mantıklıdır; hasta ya da anlaşma gibi kritik veride değildir.
Ekip modüllerinde mantık değişir: erişim, kullanıcının o spesifik ekip modülü için eşlendiği ekip modülü profiline bağlıdır. Aynı kişi farklı ekip modüllerinde farklı yetki seviyelerine sahip olabilir. Dikkat çekici bir nokta: doğru CRM profil iznine sahip bir kullanıcı, üyesi olmadığı bir ekip modülünün yapılandırmasını yine de düzenleyebilir; bu, yöneticinin her ekibe üye olmadan yönetebilmesi içindir.
Üç kavram: kullanıcı, rol, profil
Sağlıklı bir güvenlik kurulumunun yarısı, üç kavramı birbirine karıştırmamaktan geçer: kişinin kim olduğu (kullanıcı), organizasyonda nerede durduğu (rol) ve ne yapmaya yetkili olduğu (profil). Bu üçü ayrı eksenlerdir; biri diğerinin yerine geçmez.
| Kavram | Neyi belirler | Klinik örneğiyle |
|---|---|---|
| Kullanıcı (User) | CRM'e e-posta + parolayla giren, kayıt yöneten kişi | Resepsiyondaki hasta danışmanı |
| Rol (Role) | Hiyerarşideki konum; hangi kayıtların görüleceğini belirler | Klinik Müdürü → Danışman |
| Profil (Profile) | İzin paketi; hangi eylem ve özelliklerin yapılabileceğini belirler | Yönetici / Standart |
Kaç kullanıcı ekleyebileceğiniz satın aldığınız sürüme ve lisans sayısına bağlıdır. Her kullanıcıya konumuna göre bir rol atanır; varsayılanda CEO ve Müdür (Manager) rolleri hazır gelir. Kendi yapınıza göre "Klinik Müdürü", "Hasta Danışmanı", "Muhasebe" gibi roller ekleyip aralarında bir hiyerarşi kurarsınız.
İzin tarafında iki varsayılan profil türü vardır:
- Yönetici (Administrator): Tüm sistemi ve veriyi görür. Hesapta en az bir yönetici bulunması zorunludur. Tipik olarak klinik sahibi ya da operasyon müdürüdür.
- Standart Kullanıcı (Standard): Yalnızca tanımlı profil ve rolün izin verdiği ölçüde erişir. Danışmanlar, pazarlama ve destek ekibi buraya girer.
Roller ve yeni profiller ancak hesaba ilk kullanıcı eklendikten sonra oluşturulabilir. Ayrıca rol oluşturmak için hesapta birden fazla kullanıcı bulunması gerekir. İlk kullanıcıya yalnızca sistemin hazır rol (CEO/Müdür) ve profilleri (Yönetici/Standart) atanabilir. Ekip kullanıcıları eklediyseniz sınırlı yetkili bir Ekip Kullanıcı Profili (Team User Profile) de görürsünüz.
Profil izinleri: kim ne yapabilir
Profili rollere göre değil, "bu kişiler gün içinde gerçekte ne yapıyor?" sorusuna göre tasarlayın. Aynı roldeki iki kişinin bile iş tanımı farklı olabilir; izin paketi işin kendisini yansıtmalıdır.
Sıfırdan yazmayın, klonlayın
Hazır gelen Yönetici ve Standart profillerinde yalnızca kurum modülü izinleri değiştirilebilir; başka özelleştirme yapamazsınız. Bu yüzden pratikte en hızlı ve en az hatalı yol, ihtiyacınıza en yakın profili klonlayıp üzerinde ince ayar yapmaktır.
Yeni profil oluşturun
Menü yolu: Kurulum > Güvenlik Kontrolü > Profiller. "Yeni Profil"e tıklayın; bir ad verin, klonlanacak profili seçin ve gerekirse açıklama girin. Bu özelliğe yalnızca "Profilleri Yönet" izni olan kullanıcılar erişebilir.
İzinleri ayarlayın
Profil oluşturulduktan sonra izinleri açıp kapatırsınız. Değişiklik o an yürürlüğe girer; "kaydet" beklemeniz gerekmez.
Kullanıcıları doğrulayın
Profilin yanındaki menüden "Kullanıcıları Gör" ile o profile eşlenmiş kişileri kontrol edin. Yetki devrederken bu liste sizi sürprizlerden korur.
İzinler dört başlıkta toplanır
| Kategori | Kapsadığı yetkiler |
|---|---|
| Modül İzinleri | Görüntüle / Oluştur / Düzenle / Sil; ek olarak İçe-Dışa Aktar, E-posta Gönder, Toplu Güncelle, Toplu Sil, Sahip Değiştir gibi araçlar |
| Kurulum İzinleri | Kullanıcı yönetimi ve modül özelleştirme (yalnızca yöneticiler), e-posta/şablonlar, otomasyon (İş Akışları, Blueprint, Cadence, Onay süreçleri), veri yönetimi, Zia |
| Eklenti İzinleri | Zoho ürünleri (Desk, Projects, Phone Bridge), Google ve Microsoft servisleri, sosyal medya, CRM API erişimi |
| Geliştirici İzinleri | Zoho CRM API'leri ve özel fonksiyon/entegrasyon genişletme yönetimi |
"Kullanıcı Yönetimi" ve "Modül Özelleştirme" gibi yönetici düzeyi izinleri başka profillere açarken çok dikkatli olun; bunlar sessizce çok geniş bir yetki devreder. Ayrıca bir profili silebilmek için önce ona bağlı tüm kullanıcıları başka bir profile taşımanız gerekir; bağlı kullanıcı varken profil silinmez.
Roller ve görünürlük hiyerarşisi
Roller kurum genelindeki görünürlüğü kurar. Kuralın özü sade: hiyerarşide üstte olan, altındakilerin kayıtlarına ulaşabilir; alttaki yalnızca kendi kayıtlarını görür. Klinik müdürü tüm danışmanların portföyünü görürken, danışman yalnızca kendi hastalarını görür.
Roller hakkında işleyişi belirleyen kurallar
- CEO rolü kurumdaki tüm veriye erişir. Yönetici profili ise atandığı rolden bağımsız olarak her veriyi görür; rol bu profilin önünde durmaz.
- Üst rol, astının kaydını görebilmek için yine de o modülde Okuma/Düzenleme iznine sahip olmalıdır. Rol tek başına yetmez; profil ve hiyerarşi birlikte değerlendirilir.
- Varsayılanda aynı roldeki kişiler birbirinin verisini göremez: eşit konumdaki iki müdür birbirinin kayıtlarını görmez. Bunu açmak için "Akranlarla Veri Paylaş (Share Data with Peers)" seçeneği kullanılır.
- Varsayılanda üst yönetici, astının özel paylaşım kuralıyla aldığı veriyi göremez; bunu paylaşım kuralında "Üstler İzinli (Superiors Allowed)" ile açabilirsiniz.
- Bir kayda not/ek eklemek ya da e-posta göndermek için o kayıtta en az okuma veya okuma/yazma erişiminiz olmalıdır.
Rol oluşturma, düzenleme, silme
Menü yolu: Kurulum > Güvenlik Kontrolü > Roller ve Paylaşım. Yeni rol eklerken bir "Bağlı Olduğu (Reports To)" üst rol seçersiniz; seçmezseniz rol doğrudan CEO altına yerleşir. Rol adını sonradan değiştirseniz bile tüm veri paylaşım kuralları otomatik güncellenir, elle yeniden hesaplama gerekmez. Bir rolü silmek isterseniz önce o roldeki kullanıcıları ve alt rolleri başka bir role devretmek zorundasınız; "Devret ve Sil (Transfer & Delete)" ile hiyerarşi yeniden kurulur.
Rol hiyerarşisi mi, raporlama hiyerarşisi mi?
Organizasyonunuz bu iki modelden birini kullanır ve seçim Kurulum > Genel > Şirket Ayarları > Hiyerarşi Tercihi altından yapılır. Raporlama hiyerarşisinde her kullanıcının tek bir raporlama yöneticisi vardır ve o kişi kullanıcının verisine erişir. Raporlama yöneticisi olmayan ("non-reporting") kişiler için verinin yalnızca CEO/Yönetici tarafından mı, yoksa hiyerarşide üstteki herhangi biri tarafından mı görüleceğini siz belirlersiniz.
Raporlama hiyerarşisinin asıl gücü, diğer süreçlerle iç içe çalışmasıdır: onay süreçlerinde "raporlama yöneticisini onaylayıcı yap" (1., 2., 3. seviyeye kadar tanımlanabilir), iş akışlarında "kayıt sahibinin yöneticisine uyarı gönder", Blueprint geçişlerinde geçiş sahibini yöneticiye bağlama gibi seçenekler açılır. Hiyerarşi etkinken kullanıcı alanlarında otomatik bir "Bağlı Olduğu (Reporting To)" alanı belirir; bunu rapor, filtre ve e-posta şablonu birleştirme alanlarında kullanabilirsiniz.
Raporlama hiyerarşisinde kullanıcılar verilerini akranlarıyla paylaşamaz. Bir kullanıcıyı silerken astları varsa, onları eşit ya da üst roldeki birine devredebilir veya yöneticisiz bırakabilirsiniz. Çok CEO'lu yapıda her CEO tüm organizasyonun tahminlerini görüp düzenleyebilir.
Bölge yönetimine ne zaman geçilir
Bölge yönetimi (Territory), müşteri hesaplarını sahiplik yerine özelliklerine göre gruplayıp paylaşmanın yoludur. Coğrafya, sektör, ürün hattı, hesap büyüklüğü ya da beklenen ciro gibi kriterlerle bölgeler tanımlarsınız. Rol hiyerarşisinin tek başına yetmediği, çok ekipli ve matris satış yapılarında devreye girer. Bu özelliği bir Yönetici profili etkinleştirir.
Rol mü, bölge mi? Net fark
| Boyut | Rol Hiyerarşisi | Bölge Hiyerarşisi |
|---|---|---|
| Kullanıcı ataması | Tek rol | Birden çok bölge |
| Tahmin (forecast) hedefi | Tek hedef | Bölge başına ayrı hedef |
| Gruplama mantığı | Kayıt sahipliğine göre | Hesabın özelliğine göre |
| Erişim | Sahip + üst roller + paylaşım kuralı | Yukarıdakiler + aynı/üst bölgedeki kullanıcılar |
Somut bir senaryo: İstanbul, İzmir ve Antalya'da şubeleri olan bir estetik klinik zinciri düşünün. Her şubenin danışmanı kural olarak yalnızca kendi şehrinin hastalarını görsün; ancak yurt dışından gelen yüksek bütçeli bir hastayı iki şehirden kıdemli danışmanla ortaklaşa yürütmek isteyebilirsiniz. Bunu yalnızca rol ve paylaşım kurallarıyla çözmek hızla karmaşıklaşır. Bölgelerle hem temiz hem esnek olur; üstelik her şubeye ayrı bir satış hedefi koyabilirsiniz.
Çalışma mantığı ve sayısal sınırlar
- Kayıtlar oluşturulurken veya değiştirilirken tanımlı kriterlere göre bölgelere otomatik atanır. Bir kayıt önce üst bölge kriterini sağlamadan alt bölgeye atanamaz.
- Bir hesap ve bir kişi en fazla on bölgeye, bir fırsat (Deals) ise yalnızca bir bölgeye ait olabilir.
- Kişiler bölgeyi bağlı oldukları hesaptan miras alır; on bölgeden yalnızca biri hesap üzerinden otomatik atanabilir.
- Manuel eklenen bölge yalnızca manuel kaldırılır; otomatik atanan bölge ise manuel kaldırılamaz.
- Devreye almak için iki başlangıç yolu vardır: sıfırdan hiyerarşi kurmak ya da mevcut rol hiyerarşisini bölgelere kopyalamak. Menü: Kurulum > Güvenlik Kontrolü > Bölge Yönetimi.
Bölge yönetimi yalnızca Lead, Kişi, Hesap ve Fırsat modüllerini kapsar. Bölgeyi kapatırsanız bu modüllerden bölge bilgisi kalkar ve bölge bazlı tahminler kalıcı olarak silinir; rol bazlı tahmin çalışmaya devam eder. Her klinik veya KOBİ'nin bölgeye ihtiyacı yoktur; sık ekip değiştiren karmaşık bir satış yapınız yoksa rol + paylaşım kuralları çoğu zaman yeterlidir.
Varsayılan özel + paylaşım kuralları
Hiyerarşi "kim üstte kimi görür" sorusunu çözer; ama aynı seviyedeki ekiplerin veya farklı departmanların seçili veriyi görmesi gerektiğinde devreye veri paylaşım kuralları girer. Önemli bir kural: bu kurallar erişimi yalnızca genişletir, kurum genelindeki varsayılan izni asla daraltamaz.
Dört erişim seviyesi
| Seviye | Ne anlama gelir |
|---|---|
| Özel (Private) | Yalnızca kayıt sahibi ve üstü görür — varsayılan budur |
| Herkese Salt-Okunur | Herkes görür; kimse değiştiremez veya silemez |
| Herkese Okuma/Yazma | Herkes görür ve düzenler; silemez |
| Herkese Okuma/Yazma/Silme | Herkes tam erişime sahiptir |
Bir modülün varsayılanı "Herkese Okuma/Yazma" ya da "Okuma/Yazma/Silme" yapıldığında, bu ayar rol hiyerarşisini ve paylaşım kurallarını geçersiz kılar (override eder). Yani genel ayar açıksa kurduğunuz paylaşım kuralları anlamını yitirir. Bu yüzden kritik modülleri "Özel" bırakıp erişimi kurallarla nokta atışı genişletmek temel prensibimizdir.
Paylaşım kuralı oluşturma
Modülü ve paylaşım türünü seçin
Menü: Kurulum > Güvenlik Kontrolü > Roller ve Paylaşım > Veri Paylaşım Ayarları > Paylaşım Kuralları. Modülü seçin; ardından "Kayıt Sahibine Göre" (rol/rol+astlar/grup) veya "Kritere Göre" (örneğin tedavi tipi = "rinoplasti") ile kaynağı tanımlayın. Bu özelliğe yalnızca "Veri Paylaşımını Yönet" izni olanlar erişir.
Hedefi ve izin seviyesini belirleyin
Paylaşımın gideceği rol, rol+astlar, grup veya tüm kullanıcıları seçin; izni Salt-Okunur / Okuma-Yazma / Okuma-Yazma-Silme olarak ayarlayın.
Gerekirse üstleri dahil edin
"Üstler İzinli (Superiors Allowed)" işaretlenirse, hedef rol/grubun üstündekiler de erişir.
Bir kural çalışırken (yürütme tamamlanana kadar) düzenlenemez. 4 milyondan fazla kaydı olan ve kayıtların %60'ından fazlası kritere uyan modüllerde mevcut kayıtların paylaşımı için Zoho desteğinden yardım gerekebilir; yeni/güncellenen eşleşen kayıtlar yine otomatik paylaşılır. Ek, Not ve Rakipler gibi alt kayıtlar erişimi bağlı oldukları ana kayıttan miras alır. Tahminler (Forecasts) her zaman özeldir; hiçbir paylaşım kuralıyla açılamaz.
Tek kayıt paylaşımı ve gruplar
Bazen bir kural kurmaya değmeyecek, tek seferlik bir paylaşım gerekir: "Şu hastayı bir kez de operatör doktorla görüşelim." İşte burada manuel kayıt paylaşımı ve gruplar devreye girer.
Tek kaydı elle paylaşmak
Bir kaydın detay sayfasında "Daha Fazla > Paylaş" ile özel veya genel paylaşım yaparsınız. Üç erişim seviyesi vardır: Salt-Okunur, Okuma/Yazma (sahip değiştiremez, silemez) ve Tam Erişim (görüntüle, düzenle, sil, sahip değiştir). Kullanıcının bunu yapabilmesi için profilinde Paylaş (Share) izni açık olmalıdır.
- Kayıtlar liste görünümünden toplu değil, yalnızca tek tek paylaşılır.
- Özel paylaşımda doğrudan en fazla 10 kullanıcı, 5 rol ve 5 grupla; dolaylı paylaşımda en fazla 12 kullanıcı, 5 rol ve 5 grupla paylaşabilirsiniz.
- İlgili modüle erişimi olmayan bir kullanıcıyla kayıt paylaşamazsınız; o kişi kaydı yine göremez.
- Size paylaşılmış bir kaydı, siz başkasıyla yeniden paylaşamazsınız.
- Çakışma olursa en yüksek geçerli izin uygulanır; ayrıca profil izinleri kayıt düzeyi paylaşımların önüne geçer.
- Görev, arama, toplantı gibi Etkinlikler ile bağlantı (junction) kayıtları ayrı paylaşılamaz; ana kayıtla birlikte paylaşılır.
Gruplar: paylaşımı ölçeklendirmek
Grup, ortak bir kayıt kümesini yönetmek için bir araya getirilmiş kullanıcı topluluğudur; ekip satışı, ekip desteği veya etkinlik yönetimi için uygundur. Bir gruba doğrudan kayıt atanamaz; ama veri paylaşım kuralı kurarak grupla kayıt paylaşırsınız. Üyeler yine yalnızca profillerinin izin verdiği ölçüde işlem yapabilir — modüle erişimi olmayan biri grup üzerinden de o veriye ulaşamaz. Grup yönetimine "Kullanıcı Yönetimi" izni olanlar erişir ve oluşturabileceğiniz grup sayısı sürüme göre değişir.
| Grup üyesi türü | Kimi kapsar |
|---|---|
| Kullanıcılar | Yalnızca tek tek seçilen kişiler |
| Roller | O role bağlı tüm kullanıcılar |
| Roller ve Astlar | Rol + tüm alt rollerdeki kullanıcılar |
| Alt Gruplar | Başka bir grubun tüm üyeleri |
Kayıtlar her zaman bir kullanıcıya aittir, gruba ait olamaz. Grup veya rolü sildiğinizde paylaşım kuralları otomatik yeniden hesaplanır; elle müdahale gerekmez. "Kullanıcıları Gör" seçeneği, kişi gruba ister doğrudan ister bir rol/bölge üzerinden dolaylı eklensin tüm üyeleri tek listede gösterir.
Girişi kontrol etmek: SSO, IP, politika
Buraya kadarki katmanlar "giriş yaptıktan sonra ne görülür" sorusunu çözdü. Bu bölümdeki kontroller ise daha öncesini, yani kimin ve nasıl giriş yapabileceğini yönetir. Çoğu Zoho Directory tarafından sağlanır.
Tekil Oturum (SSO)
Çalışanların seçtiğiniz kimlik sağlayıcı (IdP) üzerinden tek kimlikle giriş yapmasını sağlar; parola yorgunluğunu azaltır.
Güvenlik Politikaları
Parolanın periyodik değişmesi gibi kuralları tanımlar; kimlik doğrulamanın nasıl yapılacağını standartlaştırır.
Giriş Geçmişi
Kullanıcıların tüm giriş kayıtlarını IP adresi ve cihaz bilgisiyle birlikte gösterir.
IP Kısıtlama
CRM girişini yalnızca belirlediğiniz IP adreslerine açar; ofis dışından yetkisiz erişimi engeller.
Active Directory Senkron
Mevcut LDAP sunucunuzdan Zoho Directory'ye güvenli, tek yönlü dizin senkronizasyonu yapar.
Güvenilir Alan Adı
Client Script ve Query'lerden istek gönderilebilecek alan adlarını beyaz listeye alır.
Hasta verisi taşıyan bir CRM'de en azından parola politikasını ve giriş geçmişi takibini açın. Ofisiniz sabit IP'liyse IP kısıtlama, dışarıdan yetkisiz girişe karşı düşük maliyetli ama etkili bir kalkandır. Bu üçü, ek lisans gerektirmeden uygulayabileceğiniz ilk hattır.
KVKK, denetim ve izlenebilirlik
Erişimi düzenlemek işin yarısıdır; yapılanları sonradan kanıtlayabilmek diğer yarısı. Özellikle sağlık verisiyle çalışan ekipler için izlenebilirlik bir konfor değil, yasal bir zorunluluktur.
KVKK / GDPR & HIPAA
Hassas müşteri verisinin gizliliğini korumak için ilgili uyum ayarlarını etkinleştirip yapılandırabilirsiniz. Türkiye'de hasta verisi işleyen bir klinik için KVKK uyumu; rıza durumu ve saklama süresi gibi alanların veri modelinde yer alması, erişimin rolle sınırlanması demektir.
Denetim Günlüğü (Audit Log)
Kullanıcıların CRM'de yaptığı işlemleri kronolojik sırayla kaydeder. "Kim, neyi, ne zaman değiştirdi?" sorusuna kanıtla cevap verir; denetimlerde ve olay incelemelerinde paha biçilmezdir.
Veri Şifreleme
Ham veri, yetkisiz birinin eline geçse bile okunamayacak biçimde şifrelenir. Şifreli alanlara yalnızca yetkili kullanıcılar erişebilir.
Destek Erişimi
Zoho destek ekibinin, uzak oturum açmadan sorun gidermek için hesabınıza güvenli ve süreli erişimine izin verir. Erişim yalnızca Zoho destekle sınırlıdır.
Bunlara ek olarak, devre dışı bırakılan Zoho Mail eklentisi kullanıcılarının gönderdiği e-postaları yedekleyebilir ve ilgili yapılandırma değişikliklerini yönetebilirsiniz. Uyum ve izleme katmanını kurulumun en başında zorlamak şart değildir; ancak veri hacminiz büyümeden, yani geriye dönük "kim değiştirdi" sorusu cevapsız kalmadan önce devreye almanızı öneririz.
KVKK kapsamında bir veri ihlali yaşandığında, ihlalin kapsamını ve kimin neye eriştiğini gösterebilmek zorundasınız. Denetim günlüğü ve giriş geçmişi açık değilse bu kanıtı geriye dönük üretemezsiniz. Kesin uyum yükümlülükleri için hukuk danışmanınızla birlikte değerlendirme yapılması önerilir.
Eksenium'un güvenlik kurulum sırası
Medikal klinikler ve butik KOBİ'ler için yıllardır Zoho CRM kurarken güvenlik tarafında en sık karşımıza çıkan dersleri damıttık. Aşağıdaki yaklaşım, çoğu ekibin "sonradan düzeltmek zorunda kaldığı" hataları baştan keser.
- "Özel" ile başlayın, ihtiyaç doğdukça açın. Kritik modülleri varsayılan özel bırakıp erişimi paylaşım kurallarıyla noktasal genişletmek, sonradan geniş erişimi geri toplamaktan kat kat kolaydır.
- Hiyerarşi tercihini en başta verin. Rol mü, raporlama mı kararını kullanıcı eklemeden ve rol kurmadan önce netleştirin; bu seçimi sonradan değiştirmek tüm org'da kimin neyi gördüğünü altüst eder.
- Profili klonlayın, sıfırdan yazmayın. En yakın hazır profilden türetmek hem daha hızlı hem hata payı düşük bir yöntemdir.
- Yönetici sayısını minimumda tutun. Yönetici profili rolden bağımsız her veriye erişir; bu yetkiyi yalnızca gerçekten gerekenlere verin.
- Bölgeyi gereksiz yere açmayın. Çok şubeli ve sık ekip değişen bir yapınız yoksa rol + paylaşım kuralları genellikle yeterlidir; bölge ek karmaşıklık getirir.
- Denetim günlüğü ve giriş geçmişini ilk günden açın. Bunlar geriye dönük çalışmaz; açmadığınız bir dönemin kaydını sonradan üretemezsiniz.
Bu rehberdeki her başlık, sizin sürecinize göre özelleştirilmesi gereken bir karardır; tek doğru bir şablon yoktur. Eksenium olarak güvenlik katmanlarını sizin ekip yapınıza göre tasarlayıp canlıya almadan önce yazılı bir yol haritasıyla netleştiriyoruz.
