İstifadəçinin sistemə daxil olması ona bütün məlumatı görmək hüququ vermir. Giriş şəxsiyyəti təsdiqləyir; səlahiyyət isə konkret əməliyyata icazə verilib-verilmədiyini müəyyən edir. CRM-də bu fərq müştəri siyahısı, maliyyə qeydləri, hesabat və ixrac kimi gündəlik funksiyalarda görünür. Yalnız düyməni gizlətməklə həll olunan məsələ deyil.
OWASP səlahiyyət bələdçisi minimum zəruri icazə, ilkin qadağa və hər sorğuda yoxlama yanaşmasını tövsiyə edir. Biznes tərəfinin vəzifəsi isə hansı rola hansı məlumatın nə üçün lazım olduğunu aydın izah etməkdir.
Rolu və istifadəçini ayırın
«Aysel bütün sifarişləri görür» şəxsi istisnadır; «filial rəhbəri öz filialının sifarişlərini görür» isə qaydadır. Rollara əsaslanan model işçinin dəyişməsini daha anlaşılan edir. Bir əməkdaşın eyni zamanda bir neçə məsuliyyəti ola bilər, amma onların birləşməsi gözlənilmədən geniş giriş yaratmamalıdır.
Vəzifə adı ilə proqram rolu tam eyni olmaya bilər. Məsələn, müvəqqəti əvəz edən əməkdaşa müəyyən müddət üçün əlavə icazə lazım gələ bilər. Bu əlavə hüququn kim tərəfindən və nə vaxta qədər verildiyi saxlanmalıdır. İstisnaların da qaydası olmalıdır.
Əməliyyat matrisini hazırlayın
Müştəri kartını görmək, yaratmaq, dəyişmək, silmək və ixrac etmək ayrı əməliyyatlardır. Bir rola baxış icazəsi verilməsi avtomatik olaraq silmə və ya kütləvi yükləmə icazəsi demək deyil. Hər məlumat qrupu üçün əsas əməliyyatları bir cədvəldə göstərmək ilkin müzakirəni sadələşdirir.
- Satış əməkdaşı hansı müştəriləri görə bilər?
- Müştərinin məsul şəxsi kim tərəfindən dəyişdirilir?
- Məbləğ və ödəniş qeydlərini kim redaktə edə bilər?
- Kim bütün müştəri bazasını ixrac edə bilər?
- Silinmiş qeyd kim tərəfindən bərpa edilir?
Məlumatın öz sərhədi var
İki istifadəçi eyni «sifarişə bax» funksiyasına sahib ola bilər, amma fərqli sifarişləri görməlidir. İcazə yalnız funksiyaya deyil, konkret qeydə də aiddir. Filial, komanda, müştərinin məsul şəxsi və ya layihə üzvlüyü belə sərhədlər yarada bilər.
İzahlı nümunə: bir şirkətin Bakı və Gəncə filialları var. Satış əməkdaşı öz işlərini, filial rəhbəri filialdakı işləri, ümumi rəhbər isə razılaşdırılmış yekunları görür. Bu, real müştəriyə aid model deyil. Həmin qaydanın axtarış, hesabat, bildiriş və ixracda da eyni işləməsi tələb olunur.
İxrac və sənədlər ayrıca düşünülməlidir
Ekranda görünən məlumat az olsa da, ixrac faylı bütün bazanı aça bilər. Ona görə kütləvi yükləmənin məqsədi, sahələri və məsul rolu ayrıca razılaşdırılmalıdır. Hesabatın cəmi də həssas ola bilər: istifadəçinin görə bilmədiyi məlumatın yekunu ona dolayı məlumat verə bilər.
Faylın ünvanını bilən hər kəs onu yükləyə bilirsə, kartdakı icazə sənədi qorumur. Müqavilə və şəxsi sənədlərə çıxış qaydası da tətbiqin məlumat modelinin hissəsidir. Bunun necə qurulacağı texniki tapşırıqda əvvəlcədən göstərilməlidir.
Tarixçə və təsdiq axını
Mühüm dəyişiklik üçün kim, nə vaxt və hansı əməliyyatı etdiyini görmək faydalıdır. Tarixçə bütün gizli məlumatı daimi saxlamaq məqsədi daşımamalıdır; saxlanan qeydin məqsədi və müddəti razılaşdırılmalıdır. Şifrələr və giriş tokenləri adi dəyişiklik tarixçəsinə yazılmamalıdır.
Bəzi işlərdə dəyişiklik etmək və onu təsdiqləmək fərqli məsuliyyətdir. Məsələn, sifariş məbləğinin yenilənməsi ayrıca təsdiq tələb edə bilər. Bu qayda lazım olmayan hər əməliyyata əlavə olunarsa, gündəlik iş ağırlaşacaq. Təsdiq real risk və biznes ehtiyacı ilə əlaqəli olmalıdır.
İcazələri necə sınaqdan keçirmək olar?
- Hər rol üçün nümunə istifadəçi yaradın.
- İcazəli və qadağan edilmiş qeyd nümunələri seçin.
- Birbaşa səhifə ünvanı ilə girişi yoxlayın.
- Axtarış, hesabat və ixrac nəticələrini müqayisə edin.
- Rol dəyişəndən sonra əvvəlki girişin vəziyyətini yoxlayın.
- Əməkdaş hesabı bağlananda sessiyanın davranışını nəzərdən keçirin.
İstisna nümunəsi: müvəqqəti əvəzləmə
Rəhbər məzuniyyətdə olduğu müddətdə əməkdaşın bəzi təsdiqləri etməli olduğunu düşünün. Bu, şərti iş halıdır. Ona rəhbərin hesabını vermək əvəzinə hansı əməliyyat və müddət üçün əlavə səlahiyyət lazım olduğu yazılmalıdır. Başqasının hesabından istifadə tarixçənin müəllifini qarışdırır.
Əvəzləmə bitəndə əlavə icazə geri alınmalıdır. Bunun yalnız yaddaşa bağlı qalmaması üçün son tarix, məsul şəxs və yoxlama addımı müəyyənləşdirilir. Rolun geri alınması ilə artıq yüklənmiş məlumatın cihazdan silinməsi eyni məsələ deyil; ixrac qaydası buna görə ayrıca düşünülür.
- Hansı təsdiq növlərinin müvəqqəti verildiyini yazın.
- Müddətin başlanğıc və sonunu müəyyən edin.
- Tarixçədə həqiqi istifadəçinin göründüyünü yoxlayın.
- Əvəzləmə bitəndən sonra giriş sınağı aparın.
Bu nümunə icazənin bir dəfə qurulub unudulan siyahı olmadığını göstərir. Komandanın iş şəraiti dəyişdikcə səlahiyyətlərin də əsaslandırılması davam etməlidir.
Tez verilən suallar
Administrator hər şeyi görə bilərmi?
Bu, razılaşdırılmış modeldən asılıdır. Texniki administratorla biznes məlumatına baxan rəhbərin ehtiyacları ayrı ola bilər.
Yeni funksiya əlavə olunanda köhnə rol kifayətdirmi?
Yeni əməliyyat ayrıca qiymətləndirilməlidir. Köhnə rolun adını avtomatik geniş icazə kimi qəbul etmək olmaz.
HR Proqramı kimi məxfi məlumat kontekstinə malik məhsulların təqdimatı rol məsələsini düşünmək üçün nümunədir; bu qeyd onun daxili mexanizmlərini açıqlamır. CRM tətbiqi zamanı matris yoxlanılmalı, sistem hazırlanması mərhələsində isə qaydalar server və interfeysdə birgə nəzərə alınmalıdır.
