Özel Yazılımda Yetkilendirme: 9 Kritik İlke | Reform Bilişim
Özel Yazılımda Kullanıcı Yetkilendirme
Bir satış temsilcisinin başka bir müşterinin tekliflerini görebildiğini veya depo personelinin muhasebe kayıtlarını değiştirebildiğini düşünün. Sorun çoğu zaman şifre güvenliğinden değil, yanlış planlanmış erişim kurallarından kaynaklanır. Özel yazılım geliştirirken kullanıcı yetkilendirme tasarımı, hem hassas bilgileri korumak hem de çalışanların görevlerini aksatmadan tamamlamasını sağlamak için gereklidir.
CRM, ERP, bayi portalı ve şirket içi yönetim panellerinde doğru yaklaşım, herkese aynı erişimi vermek ya da yalnızca ekranları gizlemek değildir. Yetkiler, iş süreçleri ve verinin kime ait olduğu birlikte değerlendirilmelidir.
Kullanıcı Yetkilendirme Nedir? Kısa Yanıt
Yetkilendirme, sisteme giriş yapan kişinin hangi veriyi görüntüleyebileceğini ve hangi işlemi gerçekleştirebileceğini belirleyen kurallar bütünüdür. Kimlik doğrulama ise kişinin gerçekten iddia ettiği kullanıcı olup olmadığını kontrol eder. Bir çalışanın doğru şifreyle giriş yapması, bütün müşteri kayıtlarına erişebileceği anlamına gelmez.
Bu nedenle güvenli tasarımın başlangıç sorusu şudur: Kim, hangi kaynağa, hangi koşulda, ne yapabilir? Cevaplar yazılım geliştirilmeden önce belgelendiğinde sonradan ortaya çıkabilecek yetki karmaşası azalır.
1. Önce Kullanıcı Rollerini ve İş Akışlarını Belirleyin
İlk aşamada departmanları değil, gerçek sorumlulukları inceleyin. Örneğin satış temsilcisi kendi müşterilerinin tekliflerini oluşturabilir; satış müdürü ekibinin tekliflerini onaylayabilir; muhasebe sorumlusu faturaları yönetebilir. Sistem yöneticisinin teknik ayarlara erişmesi, finansal işlemleri otomatik olarak onaylayabilmesi gerektiği anlamına gelmez.
Her kritik işlem için görüntüleme, oluşturma, güncelleme, silme, dışa aktarma ve onay verme izinlerini ayrı tanımlayın. Böylece bir rolün neye eriştiği tahmine değil, yazılı bir yetki matrisine dayanır.
2. Rol Bazlı Yetkilendirme (RBAC) ile Yönetimi Kolaylaştırın
RBAC modelinde izinler doğrudan kişilere tek tek verilmek yerine rollere atanır. Yeni başlayan çalışana uygun rol tanımlandığında gerekli erişimler tutarlı biçimde sağlanır. İşten ayrılan veya görev değiştiren çalışanların yetkileri de merkezi olarak güncellenebilir.
Bu yaklaşımın akademik temelleri, NIST tarafından yayımlanan rol bazlı erişim kontrolü araştırmasında açıklanır. Web sunucuları için geliştirilmiş 1999 tarihli akademik uygulama çalışması da bu yaklaşımın kurumsal kullanımını inceler. Ancak tek başına “yönetici” veya “personel” ayrımı her projeye yetmez; rol sayısı gereksiz büyütülmeden görev ayrılığı ve istisnalar planlanmalıdır.
3. Veri Sahipliğini ve Koşulları ABAC ile Değerlendirin
İki satış temsilcisi aynı role sahip olsa bile birbirlerinin müşterilerini görmemelidir. Bu durumda rolün yanında kayıt sahibi, şube, şirket, proje veya işlem durumu gibi özellikler kontrol edilmelidir. Öznitelik tabanlı erişim kontrolü (ABAC), kararları bu koşullara göre verebilir.
NIST SP 800-162 rehberi, ABAC kararlarında kullanıcı, kaynak, işlem ve çevresel özelliklerin nasıl değerlendirildiğini açıklar. Çok şubeli veya birden fazla müşteriye hizmet veren platformlarda RBAC ile ABAC birlikte kullanılabilir.
4. Asgari Yetki ve Varsayılan Ret İlkesini Uygulayın
Bir kullanıcının yalnızca görevini yapabilmesi için gereken izinleri bulunmalıdır. Açıkça tanımlanmayan işlemler otomatik olarak reddedilmelidir. Özellikle toplu veri indirme, kayıt silme, ödeme onayı ve yetki değiştirme gibi işlemler ayrıca korunmalıdır.
OWASP yetkilendirme rehberi, asgari ayrıcalık, varsayılan ret ve her istekte izin kontrolünü temel uygulamalar arasında sayar. Bu ilkeler sonradan eklenen modüllerin yanlışlıkla herkese açılmasını önlemeye yardımcı olur.
5. Kontrolü Yalnızca Arayüzde Değil, Sunucuda Yapın
Bir butonu gizlemek güvenlik önlemi değildir. Kullanıcı, tarayıcı araçları veya doğrudan API isteğiyle gizli işlemi çağırmayı deneyebilir. Bu nedenle her veri okuma ve değiştirme talebinde sunucu tarafında yetki kontrolü yapılmalıdır.
Örneğin /api/teklifler/125 adresine erişen kişinin yalnızca oturumunun açık olması yeterli değildir; ilgili teklifi görme hakkı da doğrulanmalıdır. Listeleme, dosya indirme, mobil uygulama ve entegrasyon uç noktaları aynı kurallara uymalıdır. Şirketler arasında veri karışmasını önlemek için kiracı veya firma kimliği de doğrulanmalıdır.
6. Kritik İşlemlerde Görev Ayrılığı Oluşturun
Tek kişinin hem ödeme talebi oluşturması hem de onu onaylaması gereksiz risk yaratabilir. Tutar veya işlem türüne göre ikinci onay mekanizması kurulabilir. Yönetici hesapları için çok faktörlü kimlik doğrulama, gerektiğinde süreli ayrıcalık ve işlem sonrası erişim kaldırma kuralları düşünülmelidir.
Acil durum erişimleri de sınırsız kalmamalıdır. Kimin, hangi gerekçeyle, ne kadar süreyle ek yetki kullandığı takip edilebilir olmalıdır.
7. Yetki Değişikliklerini Kayıt Altına Alın
Rol atamaları, başarısız erişim denemeleri, kritik onaylar ve veri dışa aktarma işlemleri uygun denetim kayıtlarıyla izlenmelidir. Kayıtlarda kullanıcı, zaman, işlem ve sonuç gibi bilgiler bulunabilir; parola, erişim anahtarı veya gereksiz kişisel veri tutulmamalıdır.
Yetki gözden geçirmeleri yalnızca kurulum sırasında yapılmamalıdır. Departman değişiklikleri, işten ayrılmalar ve yeni modüller erişim listesinin yeniden değerlendirilmesini gerektirir.
8. Olumsuz Senaryolarla Yetkilendirme Testleri Yapın
Testlerde sadece izin verilen işlemin çalıştığı değil, yasaklanan işlemin gerçekten engellendiği de doğrulanmalıdır. Personelin yönetici API’sini çağırması, başka firmanın kaydını açması, eski bağlantıyla dosya indirmesi ve yetkisi kaldırıldıktan sonra işlem yapması gibi senaryolar denenmelidir.
Bu kontroller, kullanıcı kabul testi (UAT) sırasında iş akışlarıyla birlikte değerlendirilebilir. Ancak güvenlik testleri yalnızca UAT ile sınırlı kalmamalı; otomatik testlerle her sürümde tekrarlanmalıdır.
9. Yetki Mimarisini Proje Kapsamına Dahil Edin
Rol sayısı, şube yapısı, onay akışları ve entegrasyonlar geliştirme süresini etkiler. Bu nedenle erişim kurallarını teklif sonrasında düşünmek yerine ihtiyaç analizi aşamasında netleştirmek daha sağlıklıdır. Web yazılım çözümleri kapsamında süreçlerin ve kullanıcı sorumluluklarının birlikte ele alınması önemlidir.
Bütçe planlarken de yalnızca ekran sayısını değil, yetki matrisini, test kapsamını ve bakım gereksinimlerini değerlendirin. Ayrıntılı karşılaştırma için özel web yazılım maliyetleri rehberini inceleyebilirsiniz.
Sıkça Sorulan Sorular
RBAC ile ABAC arasındaki fark nedir?
RBAC erişimi kullanıcının rolüne göre belirler. ABAC ise rolün yanı sıra kayıt sahibi, şirket, zaman veya işlem koşulu gibi özellikleri değerlendirir. Gereksinime göre iki yöntem birlikte kullanılabilir.
Her kullanıcı için ayrı yetki tanımlamak doğru mu?
Genellikle hayır. Kişiye özel çok sayıda istisna yönetimi zorlaştırır. Ortak izinler rollerle, gerçekten gerekli farklılıklar ise denetlenebilir ek kurallarla yönetilmelidir.
Yönetici hesabı bütün verilere erişmeli mi?
Hayır. Teknik yönetim, müşteri verilerini görüntüleme ve finansal onay farklı sorumluluklardır. Yüksek ayrıcalıklar yalnızca iş gereği verilmeli ve düzenli incelenmelidir.
Yetkilendirme sistemi sonradan değiştirilebilir mi?
Evet; ancak kodun farklı noktalarına dağılmış kurallar değişiklik maliyetini artırır. Merkezi politika kontrolü ve açık izin tanımları, yeni rol veya şube eklemeyi kolaylaştırır.
Özel yazılım projesi için ilk görüşme ücretli mi?
Hayır. Reform Bilişim Teknolojileri’nde ilk görüşme ücretsizdir. İş akışlarınızı, kullanıcı rollerinizi ve güvenlik ihtiyaçlarınızı paylaşarak başlangıç değerlendirmesi yapabilirsiniz. Ayrıntılı analiz ve geliştirme kapsamı ayrıca tekliflendirilir.
Güvenli ve Yönetilebilir Bir Yazılım İçin Doğru Başlangıç
İyi tasarlanmış bir erişim yapısı, çalışanların işini zorlaştırmadan bilgiyi doğru kişilerle buluşturur. Gereksiz yetkileri sınırlar, denetimi kolaylaştırır ve yazılım büyüdükçe ortaya çıkan karmaşayı azaltır. CRM, ERP, bayi portalı veya yönetim paneli projeniz için Reform Bilişim ile iletişime geçebilir, ücretsiz ilk görüşmede ihtiyaçlarınızı değerlendirebilirsiniz.
