Şirketinizdeki Dijital Anahtarlar: Rol Bazlı Yetkilendirme ve Personel Yönetimi

RBAC kararı kullanıcının rolüne göre verir: "muhasebeci cari ekranını görür." ABAC ise istek anında departman, lokasyon, saat, cihaz gibi öznitelikleri değerlendirir: "muhasebe çalışanı, mesai saatinde, şirket ağından girerse görür." ABAC daha esnektir ama kurulumu ve denetimi zordur. Çoğu kurumsal yazılımda doğru kurgu, RBAC omurgası üzerine şube veya çalışma saati gibi birkaç öznitelik kuralı eklemektir.

Her istisnai ihtiyaç için yeni rol açıldığında rol sayısının kontrolsüz büyümesidir; 30 kişilik bir şirkette 40 rol oluştuğunda model yönetilemez hale gelir. Önlemek için az sayıda geniş iş rolü tanımlanır, istisnalar kişiye özel ve mümkünse süreli ek yetkilerle karşılanır. Rol sayısının kullanıcı sayısına yaklaşması, modelin gözden geçirilmesi gerektiğinin en net sinyalidir.

Suistimale açık bir işlemin başlangıcı ile onayının aynı kişide toplanmasını engelleyen kuraldır. Örneğin satın alma talebini açan kullanıcı aynı talebi onaylayamaz; kasa sayımını yapan kişi kasa kaydını düzeltemez. Kısıtlı (constrained) RBAC bu kuralları sistemde teknik olarak zorunlu kılar; kritik işlemler tek kişinin inisiyatifinden çıkar, iç denetim ve suistimal riski azalır.

Evet. Hem satın alma hem depo sorumluluğu taşıyan bir kişi iki role birden atanabilir; yetkiler birleşir. Dikkat edilmesi gereken tek nokta görev ayrılığı kurallarıdır: birleşen roller, aynı işlemi hem başlatma hem onaylama yetkisini tek kişide toplamamalıdır. İyi kurgulanmış bir sistem, çakışan rol atamalarında yöneticiyi uyarır.

İşlem ve alan düzeyine kadar inebilir: bir kullanıcı ekranı yalnızca görüntüler ama düzenleyemez, kayıt ekler ama silemez. Alan bazlı gizlemeyle aynı stok kartına bakan iki kişiden biri yalnızca miktarı, diğeri maliyet ve marjı görür. Ölçü her zaman aynıdır: işin gerektirdiği kadar yetki, fazlası değil.

Evet. Denetim izi; kimin, ne zaman, hangi kaydı eklediğini, değiştirdiğini veya sildiğini eski ve yeni değerleriyle birlikte saklar. Silinen bir irsaliye ya da değiştirilen bir fiyat geriye dönük sorgulanır; sorumluluk tartışması yerine kayıt konuşur. Olağan dışı hareketler için yöneticiye otomatik uyarı da tanımlanabilir.

Kullanıcı hesabı pasifleştirilir veya rolü kaldırılır; erişim anında ve tamamen kapanır, açık oturumlar sonlandırılır. Şifre değişimini veya e-posta hesabının kapanmasını beklemeye gerek kalmaz, sistemde unutulmuş açık kapı riski oluşmaz. Geçmiş işlem kayıtları ise silinmez; ayrılan personelin yaptığı işlemler ihtiyaç halinde denetim izinden geriye dönük sorgulanabilir olarak kalır.

Evet. Bir proje, denetim dönemi veya izin vekaleti için başlangıç-bitiş tarihli yetki tanımlanır; süre dolunca erişim kendiliğinden kapanır. Dış danışman ve geçici personel için bu yöntem, unutulup açık kalan hesap riskini ortadan kaldırır. Rol patlamasını önlemenin de en pratik yolu, istisnaları süreli yetkiyle çözmektir.

Evet. Aynı rol, veri kapsamı kurallarıyla daraltılır: İzmir şube müdürü yalnızca kendi şubesinin stok ve satışını görür, genel müdür tüm lokasyonların konsolide raporuna ulaşır (bkz. B2B veri analitiği ve lokasyon motoru projemiz). Vardiya amiri de benzer şekilde yalnızca kendi vardiyasının iş emirlerini yönetir. Yeni şube açıldığında mevcut rol şablonları kopyalanarak dakikalar içinde devreye alınır; yetki düzeni büyümeyle birlikte bozulmadan ölçeklenir.

Evet ve birbirini tamamlarlar: 2FA kapıdan kimin girdiğini doğrular, RBAC içeride nereye girebileceğini belirler. Finansal ekranlara erişen roller gibi hassas hesaplar için uygulama tabanlı veya SMS doğrulama zorunlu tutulabilir. Böylece şifre ele geçse bile hem giriş engellenir hem de olası zarar rolün sınırlarıyla daraltılmış olur.

Evet. Yetki kuralları sunucu tarafında tanımlandığı için web ve mobil uygulamada aynı model geçerlidir; kullanıcı hangi cihazdan girerse girsin yalnızca rolünün izin verdiği alanı görür. Mobil tarafta bu kurgu anlık bildirimlerle birleştirilebilir: şüpheli giriş denemesi veya yüksek tutarlı işlem, yöneticinin telefonuna anında düşer.

Evet, hem de doğrudan. KVKK, kişisel veriye yalnızca işi gereği ihtiyaç duyanın erişmesini ve bu erişimin belgelenmesini bekler; RBAC ile erişim sınırlanır, denetim iziyle kayıt altına alınır. Olası bir ihlal incelemesinde "kim neye erişebiliyordu" sorusuna yetki matrisiyle, "kim neye erişti" sorusuna loglarla yanıt verirsiniz. Bu iki belge, veri sorumlusunun elini ciddi biçimde güçlendirir.

İdeali çeyrekte bir, asgarisi yılda birdir; personel sirkülasyonu yüksek işletmelerde aralık kısalmalıdır. Gözden geçirmede üç soru sorulur: Kullanılmayan rol veya yetki var mı? Görev değişikliğinden kalan fazla erişim var mı? Rol sayısı kullanıcı sayısına yaklaşıyor mu? Ayrıca her terfi ve departman değişikliği, planlı takvimi beklemeden mini bir gözden geçirme tetiklemelidir.

Çoğu hazır paket sınırlı sayıda kalıp rol sunar; alan bazlı gizleme, görev ayrılığı veya şube kapsamı gibi ihtiyaçlarda esneklik biter. Özel yazılımda rol modeli organizasyon şemanıza birebir tasarlanır ve şirketle birlikte evrilir. Özel yazılıma geçerken sözleşmeye kaynak kod teslimini mutlaka yazdırın; kaynak kodlar verilmezse ne yapılacağını ayrı bir rehberde anlattık. Paket programdan çıkarken Edge Bilişim olarak eski sistemdeki kullanıcı hesaplarını olduğu gibi taşımıyoruz: aktarım sırasında hesaplar rol eşleşmesi yapılarak yeniden kuruluyor, karşılığı olmayan ve yıllardır kullanılmayan hesaplar aktarım dışı bırakılıyor; veri tarafının nasıl taşındığını ERP/CRM veri göçü rehberinde ayrıntılandırdık.

SaaS üründe yetki modeli, sağlayıcının sunduğu seçeneklerle sınırlıdır; rol özelleştirme, alan bazlı gizleme ve log dışa aktarımı üründen ürüne ciddi fark gösterir. Sözleşme öncesi bu üç başlığı mutlaka test edin. Kiracı (tenant) izolasyonu, veri konumu ve erişim güvenliği tarafını bulut tabanlı ERP sistemleri güvenli mi rehberinde ayrıntılı ele aldık.

Beş kişilik ekipte bile maaş, maliyet ve cari verisini operasyon ekranlarından ayırmak değerlidir; ancak model basit tutulmalıdır: iki-üç rol çoğu zaman yeterlidir ve rol patlamasına gerek yoktur. Tek kişilik işletmelerde ise öncelik yetkilendirme değil, işi hızlandıran otomasyondur; bu tarafı solopreneur otomasyon yazılımları rehberinde işledik. Ekip büyüdükçe rolleri bölmek, baştan karmaşık kurmaktan her zaman kolaydır.

Modern mimarili çoğu sisteme yetki katmanı sonradan eklenebilir; eski sistemlerde kapsam analizi gerekir. Süreyi ve bütçeyi belirleyen dört etken vardır: ekran ve modül sayısı, alan bazlı gizleme ihtiyacı, onay akışları ve denetim izi derinliği. Basit bir rol-ekran modeli birkaç haftalık iş iken, görev ayrılığı ve kapsamlı loglama içeren tam kurgu birkaç aya yayılabilir; maliyet de bu kapsamla doğru orantılı olarak değişir. Tek bir sabit rakam veren tekliflere temkinli yaklaşın. Mevcut sisteme sonradan yetki katmanı eklerken Edge Bilişim işi tek seferde canlıya almıyor; önce salt okunur mod açılıyor, kural ihlalleri iki hafta boyunca engellenmeden yalnızca raporlanıyor, listede yanlış pozitif kalmadığında kısıtlar zorunlu hale getiriliyor. Bu aşamaların sözleşmede nasıl bölündüğünü milestone bazlı ilerleme rehberinde açıkladık.