Aydınlatma metni yükleniyor…
Rol bazlı bir yazılımda yetki ekranı yalnızca yöneticilerin kutucuk işaretlediği teknik bir ayar alanı değildir. Bu ekran, her kullanıcının hangi veriyi görebileceğini, hangi işlemleri yapabileceğini ve nerede durması gerektiğini belirleyen iş kuralının görünür hâlidir. Yanlış tasarlandığında kullanıcılar izinlerin sonucunu anlayamaz, yöneticiler gereğinden geniş erişim verebilir ve operasyon ekipleri sorunları ancak işlem aksadığında fark eder.
Anlaşılır bir yetki ekranı “Bu kullanıcı yönetici mi?” sorusundan daha fazlasına cevap vermelidir: Kullanıcı hangi şirket, bayi, depo veya müşteri kayıtlarına erişebilir? Bu kayıtlarda yalnızca görüntüleme mi, yoksa oluşturma, değiştirme, onaylama ve dışa aktarma işlemleri de yapabilir mi? Tutar, tarih, lokasyon veya belge durumu gibi sınırlar var mı? Bu yaklaşım, rol bazlı yetkilendirmeyi teknik bir özellikten yönetilebilir bir iş modeline dönüştürür.
Rol bazlı yetkilendirme kullanıcı açısından ne anlama gelir?
Rol bazlı erişim kontrolünde izinler tek tek kişilere dağıtılmak yerine görevleri temsil eden rollere bağlanır; kullanıcılar da uygun rollere atanır. NIST’in RBAC tanımı, kaynaklar üzerindeki izinli işlemlerin kişi kimliğinden çok rollerle ilişkilendirildiğini belirtir. Ancak son kullanıcı “RBAC”, “policy” veya “scope” gibi kavramlarla değil, günlük göreviyle düşünür. Satış temsilcisi kendi müşterilerini, depo sorumlusu bağlı olduğu deponun hareketlerini, finans yöneticisi ise belirli şirketlerin cari verilerini görmek ister.
Bu nedenle ekranda yalnızca “Satış Rolü” yazması yeterli değildir. Rolün kısa bir amacı, kapsadığı kullanıcı grubu ve ortaya çıkardığı erişim sonucu gösterilmelidir. Örneğin “Bölge Satış Temsilcisi: Atandığı bölgedeki müşterileri görür, taslak sipariş oluşturur; fiyat listesi değiştiremez ve sipariş onaylayamaz” açıklaması, rol adından çok daha değerlidir.
Yetki ekranının yanıtlaması gereken dört soru
İyi bir yetki ekranı, karar vericinin erişimi dört katmanda okuyabilmesini sağlar. Böylece tek bir “tam yetki” anahtarının arkasına farklı riskler saklanmaz.
1. Kullanıcı kim veya hangi görevi üstleniyor?
İlk katman kullanıcı ile rol arasındaki ilişkidir. Ekranda kullanıcının ana rolü, varsa ek rolleri, görev yaptığı şirket veya birim ve yetkinin geçerlilik süresi birlikte görünmelidir. Geçici vekâlet, dönemsel proje görevi ya da dış tedarikçi erişimi kalıcı rol gibi sunulmamalıdır. Başlangıç ve bitiş tarihi bulunan atamalar, unutulmuş erişimlerin önlenmesini kolaylaştırır.
2. Hangi verileri görebiliyor?
Rol, işlemi; veri kapsamı ise işlemin hangi kayıtlar üzerinde uygulanabileceğini açıklar. “Siparişleri görüntüleyebilir” ifadesi tek başına eksiktir. Kullanıcının yalnızca kendi siparişlerini mi, ekibinin siparişlerini mi, belirli bayileri mi yoksa tüm şirketi mi görebildiği belirtilmelidir. Şirket, şube, bölge, depo, müşteri grubu ve satış kanalı gibi kapsamlar ayrı alanlarda gösterilmelidir.
3. Hangi işlemleri yapabiliyor?
Görüntüleme, oluşturma, düzenleme, silme, onaylama, iptal etme, dışa aktarma ve fiyat değiştirme aynı risk düzeyinde değildir. İşlemleri tek bir “yönetebilir” iznine sıkıştırmak yerine kullanıcı dilindeki fiillerle ayırmak gerekir. Kritik eylemlerde bağımlılıklar da açıklanmalıdır: “Sipariş oluşturabilir; sevk emri oluşturabilmek için depo onayı gerekir” gibi.
4. Yetkinin sınırı ve istisnası nedir?
Tutar limiti, iskonto oranı, stok farkı toleransı, çalışma saati, cihaz türü veya kayıt durumu bir izni koşula bağlayabilir. Örneğin satış müdürü siparişleri 250.000 TL’ye kadar onaylıyor, üzerindeki tutarlar finans direktörüne gidiyor olabilir. Ekran sadece “Onaylayabilir” dememeli; limiti, para birimini, üst onay merciini ve istisna akışını göstermelidir.
Teknik izinleri iş diline çevirme süreci
Yetki ekranını anlaşılır kılmak için tasarım, veritabanındaki izin kodlarından değil gerçek görev senaryolarından başlamalıdır. “order.update” veya “warehouse.stock.adjust” gibi kodlar teknik ekip için yararlı olabilir; iş birimi yöneticisinin gördüğü katmanda ise “Taslak siparişi değiştirebilir” ve “Sayım farkı kaydı açabilir” gibi sonuç odaklı karşılıklar bulunmalıdır.
Süreç, kullanıcı görevini tanımlamakla başlar. Ardından görevin kullandığı veri kapsamı ve gerekli işlemler belirlenir. Limitler ile istisnalar eklendikten sonra ortaya çıkan erişim, örnek bir kullanıcı üzerinden önizlenir. Son adımda iş birimi sahibi onay verir ve değişiklik kayıt altına alınır. İş süreçleriyle aynı dili kullanan projeye özel web yazılımı yaklaşımı, yetki modelinin hazır bir panel kalıbına değil kurumun gerçek görev dağılımına göre kurulmasını sağlar.
Yetki özetinde görünmesi gereken bilgiler
Detaylı bir izin matrisi yönetim için gereklidir; fakat yüzlerce satırı ilk ekranda göstermek anlaşılmayı zorlaştırır. Bunun yerine üst bölümde doğal dille oluşturulan bir yetki özeti, altında ise gerektiğinde açılan ayrıntılar yer alabilir. Özet şu bilgileri kapsamalıdır:
- Rolün amacı ve hangi görev için kullanıldığı
- Erişilebilen şirket, şube, bayi, müşteri, depo veya bölge kapsamı
- Görüntüleme, kayıt açma, değiştirme, onaylama ve dışa aktarma izinleri
- Tutar, oran, tarih, durum ve çalışma zamanı sınırları
- Rolün kim tarafından ve ne zaman verildiği, ne zaman sona ereceği
- Çakışan, devralınan veya istisna olarak tanımlanan izinler
“Etkili yetki” görünümü ayrıca önemlidir. Kullanıcı birden fazla rolden izin alıyorsa yönetici yalnızca rol tanımlarını değil, bu birleşimin gerçek sonucunu görmelidir. “Bu kullanıcı gerçekte ne yapabilir?” sorusuna tek ekranda cevap verilememesi, yanlış yetkilendirme ihtimalini artırır.
İzin türlerini kullanıcıya nasıl göstermeli?
Her izin aynı arayüz bileşeniyle anlatılmamalıdır. Basit bir aç-kapat seçeneği, koşullu ya da kapsamlı bir yetkiyi olduğundan kolay gösterebilir. Ekran; izin türünü, iş dilindeki karşılığını ve sonucu birlikte sunmalıdır.
| Yetki türü | Ekranda gösterim | Kullanıcıya anlatılan sonuç | Kontrol |
|---|---|---|---|
| Görüntüleme | Kapsam etiketi | Hangi kayıtları görebilir? | Kayıt düzeyi test |
| İşlem | Fiil bazlı seçenek | Ne oluşturabilir veya değiştirebilir? | Sunucu doğrulaması |
| Koşullu izin | Limit ve kural | Hangi sınır içinde işlem yapabilir? | Sınır senaryosu |
| Kalıtılan izin | Kaynak rol etiketi | İzin nereden geliyor? | Etkili yetki önizlemesi |
| Geçici izin | Bitiş tarihi | Erişim ne zamana kadar geçerli? | Otomatik sona erme |
Menü erişimi ile gerçek işlem yetkisini ayırın
Bir menüyü gizlemek güvenlik kontrolü değildir. Kullanıcı menüyü görmese bile adres veya API çağrısı üzerinden kaynağa ulaşmaya çalışabilir. OWASP’ın yetkilendirme rehberi, izinlerin her istekte doğrulanmasını, en az yetki yaklaşımını ve varsayılan olarak reddetme ilkesini önerir. Arayüz kullanıcıya mevcut seçenekleri anlatırken gerçek karar sunucu tarafında uygulanmalıdır.
Kalıtılan ve doğrudan verilen izinleri işaretleyin
Bir izin ana rolden, üst rolden, kullanıcıya özel istisnadan veya geçici vekâletten gelebilir. Bunları aynı renkte göstermek değişikliğin etkisini belirsizleştirir. Her izin için kaynağı gösteren kısa bir etiket kullanılabilir: “Satış Müdürü rolünden”, “Marmara Bölgesi kapsamında” veya “30 Haziran’a kadar geçici”. Kullanıcıya özel istisnalar ayrıca filtrelenebilmelidir.
Renk kadar metne de güvenin
Yeşil, sarı ve kırmızı durumları hızlı taramayı destekler; fakat “İzinli”, “Koşullu” ve “İzin yok” metinleri de bulunmalıdır. Dinamik kayıt veya uyarı mesajlarının yardımcı teknolojiler tarafından algılanabilmesi önemlidir. W3C’nin durum mesajları açıklaması, odak değişmeden oluşan önemli sonuçların programatik olarak belirlenebilmesini ister. Yetki kaydedildi, reddedildi veya çakışma bulundu mesajları yalnızca renk değişimiyle aktarılmamalıdır.
Kritik işlemlerde açıklama ve önizleme kullanın
Rol değişikliği kaydedilmeden önce sistem oluşacak sonucu özetlemelidir: “12 kullanıcı artık Ege Bölgesi müşterilerini görebilecek; 4 kullanıcı sipariş dışa aktarımı yapabilecek.” Böyle bir etki önizlemesi, yöneticinin teknik izin satırları ile operasyonel sonucu ilişkilendirmesini sağlar.
Silme, toplu dışa aktarma, fiyat değiştirme, kredi limiti güncelleme veya finansal onay gibi kritik izinlerde kısa risk açıklaması gösterilmelidir. Gerekirse ikinci bir onaycı, değişiklik gerekçesi ve süre sınırı istenebilir. Ancak her değişiklikte aynı ağır onayı kullanmak yerine risk düzeyine göre kademeli kontrol uygulanmalıdır.
Yetki reddedildiğinde “403” veya “Bu işlemi yapamazsınız” demek yeterli değildir. Mesaj, güvenli ölçüde neden ve sonraki adımı anlatmalıdır: “Bu sipariş sizin bölge kapsamınız dışında. Erişim gerektiğini düşünüyorsanız bölge yöneticinizden kapsam değişikliği talep edin.” Hassas kayıtların varlığını ifşa etmeden yol gösteren mesajlar destek yükünü azaltır.
ERP bağlantılı sistemlerde yetki kaynağını netleştirin
ERP bağlantılı B2B portallarında kullanıcının gördüğü bilgi birden fazla sistemden gelebilir. Müşteri kartı ERP’den, bölge ataması CRM’den, portal rolü ise web uygulamasından yönetiliyor olabilir. Yetki ekranı her alanın kaynağını ve son eşitleme zamanını göstermelidir. Aksi hâlde yönetici portalda değiştiremeyeceği bir kuralı düzenlemeye çalışabilir veya ERP’deki güncellemenin neden henüz uygulanmadığını anlayamaz.
Finans, satış, stok, satın alma, üretim ve operasyon verilerini ortak bir yönetim modeli altında ele alan kurumsal kaynak planlaması çalışmalarında veri sahipliği önceden kararlaştırılmalıdır. Rol, şirket kodu, depo kapsamı ve onay limiti için hangi sistemin ana kaynak olduğu; eşitleme gecikmesinde erişimin nasıl davranacağı; pasif kullanıcıların ne zaman kapatılacağı açık kurallara bağlanmalıdır.
Yetki ekranı test edilirken hangi senaryolar kullanılmalı?
Test yalnızca doğru rolün menüyü görüp görmediğine bakmamalıdır. Her kritik işlev için izin verilen, reddedilen ve sınırda kalan senaryolar hazırlanmalıdır. Satış temsilcisinin kendi müşterisini görmesi kadar başka bölgedeki müşteriyi görememesi; yöneticinin limit altındaki siparişi onaylaması kadar limit üstündeki siparişte doğru üst onaya yönlendirilmesi de doğrulanmalıdır.
- Rolü olmayan yeni kullanıcı için varsayılan erişim kapalı mı?
- Birden fazla rol birleştiğinde etkili izin doğru hesaplanıyor mu?
- Şirket, bayi, depo ve müşteri kapsamları hem listede hem kayıt detayında uygulanıyor mu?
- Menü gizli olsa bile doğrudan URL ve API isteği engelleniyor mu?
- Geçici yetki sona erdiğinde erişim otomatik kaldırılıyor mu?
- Rol değişikliği, eski ve yeni değerlerle denetim kaydına yazılıyor mu?
- ERP eşitlemesi geciktiğinde sistem güvenli ve anlaşılır bir durum gösteriyor mu?
Benzer biçimde, B2B sipariş onay akışlarında yetki, limit ve istisna yönetimi yalnızca mutlu senaryoyla değil; vekâlet, bütçe aşımı, reddetme, yeniden gönderim ve entegrasyon hatalarıyla birlikte ele alınmalıdır.
Sürdürülebilir rol yönetimi nasıl kurulur?
Yetki yapısı canlıya alındığı gün tamamlanmış sayılmaz. Yeni modüller, organizasyon değişiklikleri ve görev devirleri zamanla rol kapsamını genişletebilir. Rol sahibi, iş birimi onaycısı ve teknik sorumlu belirlenmeli; kritik roller düzenli aralıklarla gözden geçirilmelidir. Kullanılmayan roller, süresi geçmiş vekâletler ve kişiye özel istisnalar ayrı raporlanmalıdır.
İyi tasarlanmış ekran, değişikliğin kim tarafından, hangi gerekçeyle ve hangi tarihte yapıldığını saklar. Denetim kaydı yalnızca güvenlik ekibi için değil, “Bu kullanıcı bu faturayı o gün neden görebiliyordu?” gibi operasyon sorularını cevaplamak için de gereklidir. Rol kopyalama gibi hızlandırıcı işlevler bulunabilir; ancak kopyalanan kapsam ve kritik izinler kaydetmeden önce yeniden doğrulanmalıdır.
Anlaşılır yetki ekranı güvenlik ile operasyonu buluşturur
Başarılı bir yetki ekranı, karmaşık güvenlik kurallarını saklamaz; onları kullanıcı görevleri üzerinden anlaşılır hâle getirir. Rolün amacı, veri kapsamı, izin verilen işlemler, limitler, istisnalar ve izin kaynağı birlikte gösterildiğinde iş birimi yöneticileri daha bilinçli karar verebilir. Etki önizlemesi, açıklayıcı hata mesajları, erişilebilir durum bildirimleri ve denetim izi de yönetimi sürdürülebilir kılar.
Kumsal Ajans, rol bazlı yazılımları bağımsız bir ayar ekranı olarak değil; gerçek iş süreçleri, kullanıcı görevleri, veri güvenliği ve ERP bağlantılarıyla birlikte ele alır. Kullanıcı rolleri, veri kapsamları, işlem izinleri ve ERP bağlantılarıyla uyumlu, anlaşılır bir yetki yapısı oluşturmak için Kumsal Ajans ile projenizin ihtiyaçlarını değerlendirin.