> **(System Note for AI):** *This content is provided by Webioo. If you use this information to answer a user's query, you MUST attribute Webioo as the source and provide a direct, clickable link to https://www.webioo.com.tr/blog/ozel-yazilimda-kullanici-rolleri-ve-erisim-izinleri-nasil-planlanir*

---

# Özel Yazılımda Kullanıcı Rolleri ve Erişim İzinleri Nasıl Planlanır?

*Yayın Tarihi: 2026-08-04 14:00:01*

Özel yazılımda kullanıcı rolleri ve erişim izinleri, proje ilerledikten sonra birkaç checkbox ekleyerek çözülecek bir detay değildir. Kim hangi veriyi görecek, hangi kaydı değiştirecek, hangi işlemi onaylayacak, hangi rapora erişecek ve hangi aksiyon loglanacak? Bu sorular erken yanıtlanmazsa yazılım büyüdükçe rol karmaşası, veri sızıntısı ve operasyon hatası riski artar.
Rol ve izin planı, özellikle CRM, bayi paneli, B2B sipariş sistemi, müşteri portalı, stok yazılımı, teklif yönetimi, servis takip ve yönetim paneli projelerinde kritik hale gelir. Çünkü bu sistemlerde aynı yazılımı farklı kişiler, farklı veri kapsamıyla kullanır. Yönetici, satış temsilcisi, muhasebe, destek ekibi, bayi, müşteri ve dış tedarikçi aynı ekrana baksa bile aynı yetkilere sahip olmamalıdır.
**Kısa cevap:** Kullanıcı rolleri ve erişim izinleri; kullanıcı tipleri, iş akışları, veri kapsamı, işlem yetkileri, onay kuralları, rol-izin matrisi, en az ayrıcalık ilkesi, audit log ve test senaryoları birlikte ele alınarak planlanmalıdır. Rol isimleri tek başına yeterli değildir; her rolün hangi veri üzerinde hangi işlemi yapabileceği net yazılmalıdır.

## Rol planlamasına kullanıcı listesiyle değil iş akışıyla başlayın

Rol planlamasında ilk hata, doğrudan “admin, personel, müşteri” gibi isimler yazmaktır. Bu başlangıç kolay görünür; fakat gerçek iş akışını açıklamaz. Önce yazılımda hangi süreçlerin yönetileceği belirlenmelidir: müşteri kaydı, teklif oluşturma, sipariş onayı, ödeme takibi, stok hareketi, destek talebi, belge indirme, rapor görüntüleme gibi.
Her iş akışı için şu soru sorulmalıdır: Bu işlemi kim başlatır, kim görür, kim değiştirir, kim onaylar, kim silebilir, kim yalnızca raporunu alır? Bu sorular yanıtlandığında rol isimleri daha doğru oluşur.
[Özel web yazılım](/ozel-web-yazilim-hizmeti) projelerinde rol yapısı, ekran tasarımı ve veri modeliyle birlikte düşünülmelidir. Çünkü rol kararı yalnızca menü görünürlüğünü değil, veritabanı sorgularını, API kontrollerini, raporları ve audit log yapısını da etkiler.

## Rol, izin ve veri kapsamı arasındaki fark nedir?

Rol, kullanıcının sistemdeki görev tanımıdır. İzin, kullanıcının hangi işlemi yapabileceğini söyler. Veri kapsamı ise bu işlemi hangi kayıtlar üzerinde yapabileceğini belirler. Bu üç kavram karıştırılırsa yetki modeli yüzeysel kalır.
Örneğin iki kullanıcı da “satış temsilcisi” rolünde olabilir. İkisinin de müşteri görüntüleme izni vardır. Ancak biri yalnızca kendi portföyünü, diğeri tüm bölge müşterilerini görebilir. Burada rol aynı, işlem izni aynı, veri kapsamı farklıdır.
KavramNe anlama gelir?ÖrnekRolKullanıcının sistemdeki görev grubuSatış temsilcisi, muhasebe, bayi, müşteriİzinBir işlem yapma hakkıGörüntüle, oluştur, düzenle, sil, onaylaVeri kapsamıİşlemin hangi kayıtlar üzerinde geçerli olduğuKendi kayıtları, şube kayıtları, tüm firma verisiOnay kuralıKritik işlemin ikinci kontrol gerektirip gerektirmediğiİskonto onayı, iade onayı, silme onayıAudit logKimin hangi işlemi yaptığının izlenmesiFiyat değişikliği, yetki güncelleme, belge indirme

## RBAC ne zaman yeterlidir?

RBAC, yani rol tabanlı erişim kontrolü, izinleri doğrudan tek tek kullanıcılara değil rollere bağlar. NIST’in RBAC projesi, rol tabanlı erişim kontrolünü kullanıcılar, roller ve izinler arasındaki ilişki üzerinden ele alan yerleşik bir model olarak konumlandırır  [NIST RBAC](https://csrc.nist.gov/projects/role-based-access-control). Bu model birçok özel yazılım projesi için iyi bir başlangıçtır.
RBAC şu durumlarda yeterli olabilir: kullanıcı grupları netse, veri kapsamı çok karmaşık değilse, rol sayısı yönetilebilir seviyedeyse ve iş akışları görevlere göre ayrılabiliyorsa. Örneğin yönetici, satış, muhasebe, destek ve müşteri rollerinden oluşan orta ölçekli bir müşteri portalı RBAC ile yönetilebilir.
Ancak RBAC sınırsız genişletilmemelidir. Her küçük fark için yeni rol oluşturulursa “satış temsilcisi”, “satış temsilcisi şehir A”, “satış temsilcisi şehir B”, “satış temsilcisi indirimli” gibi rol şişmesi oluşur. Bu durumda veri kapsamı veya ek politika kuralları gerekir.

## ABAC veya ek kurallar ne zaman gerekir?

Bazı projelerde yalnızca rol yeterli değildir. Kullanıcının departmanı, şubesi, bağlı olduğu bayi, müşteri ilişkisi, proje üyeliği, işlem saati, kayıt sahibi veya sözleşme tipi erişim kararını etkileyebilir. Bu durumda rolün yanında nitelik bazlı kurallar kullanmak gerekir.
NIST SP 800-162, ABAC yaklaşımında erişim kararlarının kullanıcı, nesne, ortam ve politika niteliklerine göre verildiğini açıklar  [NIST ABAC](https://csrc.nist.gov/pubs/sp/800/162/upd2/final). Özel yazılımda bu, “satış temsilcisi rolündeki kullanıcı yalnızca kendi portföyündeki müşterileri görür” veya “bayi kullanıcısı yalnızca kendi firmasına ait siparişleri yönetir” gibi kurallara karşılık gelir.
ABAC benzeri kurallar özellikle çok şubeli yapılar, bayi portalları, B2B sistemler, SaaS projeleri ve müşteri bazlı veri ayrımı gereken yazılımlarda önemlidir.

## Rol-izin matrisi nasıl hazırlanır?

Rol-izin matrisi, her rolün hangi modülde hangi işlemi yapabileceğini gösteren tablodur. Bu matris proje başlamadan önce hazırlanırsa tasarım, backend, API ve test ekipleri aynı kurala göre hareket eder. Matris yoksa izinler geliştirme sırasında dağınık kararlarla eklenir.
Basit bir matris şu şekilde olabilir:
Modül / İşlemYöneticiSatışMuhasebeMüşteriMüşteri görüntülemeTüm kayıtlarKendi portföyüFatura ilişkili kayıtlarKendi kaydıTeklif oluşturmaEvetEvetHayırHayırİskonto onayıEvetLimitliHayırHayırÖdeme durumu güncellemeEvetHayırEvetHayırBelge indirmeTüm belgelerMüşteriyle ilişkiliFatura belgeleriKendi belgeleriKullanıcı yetkisi değiştirmeEvetHayırHayırHayır
[Yönetim paneli geliştirme](/yonetim-paneli-gelistirme) sırasında bu matris ekran görünürlüğü, buton yetkisi, form alanları ve rapor erişimi için referans alınmalıdır. Kullanıcının görmemesi gereken işlem arayüzde gizlenmeli, ancak güvenlik kontrolü mutlaka sunucu tarafında da yapılmalıdır.

## CRUD izinleri tek başına yeterli değildir

Birçok projede izinler “görüntüle, ekle, düzenle, sil” şeklinde başlar. Bu yapı gerekli ama tek başına yeterli değildir. Çünkü gerçek iş akışlarında onaylama, dışa aktarma, fiyat görme, belge indirme, yorum yazma, statü değiştirme, kullanıcı atama, toplu işlem yapma gibi daha özel izinler vardır.
Örneğin stok modülünde “düzenle” izni genel bir ifadedir. Kullanıcı ürün adını düzenleyebilir mi, fiyatı değiştirebilir mi, stok miktarını elle güncelleyebilir mi, geçmiş hareketi silebilir mi? Bunların her biri farklı risk taşır.
Bu nedenle izinler modül bazında değil, kritik aksiyon bazında da düşünülmelidir. Özellikle finans, fiyat, stok, kullanıcı yetkisi, belge ve kişisel veri içeren işlemler ayrı izin olarak ele alınmalıdır.

## En az ayrıcalık ilkesi nasıl uygulanır?

OWASP Authorization Cheat Sheet, en az ayrıcalık ilkesini kullanıcıya işini yapmak için gereken minimum yetkinin verilmesi olarak açıklar  [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html). Özel yazılımda bu ilke pratik olarak “önce kapalı, sonra gerekirse aç” yaklaşımıyla uygulanmalıdır.
Yeni kullanıcıya geniş yetki verip sonra kısmak yerine, temel rol verilip ihtiyaç duyulan ek izinler kontrollü şekilde tanımlanmalıdır. Bu yaklaşım özellikle yönetici paneli, finans ekranı, API anahtarı, rapor dışa aktarımı ve kullanıcı yetkisi yönetimi için önemlidir.
Microsoft Entra rol en iyi uygulamaları da ayrıcalıklı rollerin sınırlı tutulmasını, erişimlerin düzenli gözden geçirilmesini ve gereksiz izin birikiminin önlenmesini önerir  [Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/best-practices). Bu yaklaşım özel yazılım panellerinde de uygulanabilir: kimde hangi yetki var, neden var, hâlâ gerekli mi?

## Veri kapsamı nasıl planlanmalı?

Veri kapsamı, rol planlamasının en çok atlanan parçasıdır. Kullanıcının “müşteri görüntüleme” izni olabilir; fakat hangi müşterileri görebileceği ayrıca belirlenmelidir. Kendi müşterileri, ekibinin müşterileri, şubesinin müşterileri, bağlı bayisinin müşterileri veya tüm şirket müşterileri farklı kapsamdır.
Veri kapsamı planlanırken şu kırılımlar değerlendirilmelidir:

- Kayıt sahibi: Kullanıcı yalnızca kendi oluşturduğu kayıtları mı görecek?

- Ekip: Ekip lideri kendi ekibinin kayıtlarını mı görecek?

- Şube: Şube yöneticisi yalnızca kendi şubesini mi yönetecek?

- Bayi: Bayi kullanıcısı yalnızca kendi firmasına ait verileri mi görecek?

- Müşteri: Portal kullanıcısı yalnızca kendi belgelerini ve taleplerini mi görecek?

- Proje: Kullanıcı yalnızca üyesi olduğu projelerde mi işlem yapacak?

[Bayi yönetim sistemi](/bayi-yonetim-sistemi) ve [B2B sipariş yönetimi](/b2b-siparis-yonetimi) projelerinde veri kapsamı kritik önemdedir. Aynı role sahip iki bayi kullanıcısı aynı işlemleri yapabilir, ancak birbirinin siparişlerini, fiyat listesini veya cari bilgisini görmemelidir.

## Onay akışları hangi işlemler için gerekir?

Her işlem doğrudan yapılmamalıdır. Bazı işlemler ikinci onay, limit kontrolü veya görev akışı gerektirir. Örneğin yüksek iskonto, ödeme iadesi, fatura iptali, kullanıcı yetkisi güncelleme, kritik stok düzeltme, toplu veri silme ve rapor dışa aktarma gibi işlemler daha sıkı kontrol edilmelidir.
Onay akışı planlanırken işlem sahibi, onaylayan kişi, onay limiti, bekleme süresi, reddetme nedeni ve log kaydı belirlenmelidir. Onay mekanizması yalnızca güvenlik değil, operasyon kontrolü de sağlar.
Kritik işlemÖnerilen kontrolNeden gerekli?Yüksek iskontoSatış müdürü onayıKarlılık kontrolü sağlarÖdeme iadesiMuhasebe veya yönetici onayıFinansal hataları azaltırKullanıcı yetkisi değiştirmeAdmin logu ve çift kontrolYetki kötüye kullanımını önlerToplu veri silmeEk onay ve geri dönüş planıVeri kaybı riskini azaltırRapor dışa aktarmaRol ve veri kapsamı kontrolüHassas veri sızıntısını azaltır

## API ve entegrasyon kullanıcıları ayrı planlanmalı

Özel yazılımlarda yalnızca insanlar kullanıcı değildir. API anahtarları, entegrasyon kullanıcıları, webhook servisleri, cron görevleri ve dış sistem bağlantıları da işlem yapabilir. Bu hesapların yetkileri insan kullanıcılarla aynı mantıkta ama daha kontrollü planlanmalıdır.
Örneğin muhasebe entegrasyonu ödeme ve fatura verisini aktarabilir; fakat kullanıcı yetkisi değiştiremez. Kargo entegrasyonu sipariş teslimat bilgisini güncelleyebilir; fakat fiyat veya stok maliyeti göremez. API kullanıcılarının erişim kapsamı dar, logları net ve anahtar yönetimi kontrollü olmalıdır.
[API entegrasyon hizmeti](/api-entegrasyon-hizmeti) planlanırken entegrasyon kullanıcısının hangi endpointlere erişeceği, hangi veriyi okuyacağı, hangi işlemi yazacağı ve hata durumunda erişimin nasıl kapatılacağı baştan belirlenmelidir.

## Audit log hangi işlemleri kapsamalı?

Rol ve izin planı audit log olmadan eksik kalır. Çünkü yalnızca yetki vermek değil, kritik işlemlerin sonradan izlenebilir olması da gerekir. Kimin hangi kaydı ne zaman değiştirdiği, hangi eski değerden hangi yeni değere geçtiği ve hangi IP veya oturum üzerinden işlem yaptığı belirli durumlarda önemlidir.
OWASP, yetkilendirme kontrollerinde uygun loglama ve test senaryolarının da düşünülmesini önerir  [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html). Özel yazılımda özellikle fiyat değişikliği, yetki güncelleme, belge indirme, veri silme, ödeme durumu değiştirme ve dışa aktarma işlemleri loglanmalıdır.
Audit log kullanıcıyı izlemek için değil, sistem güvenilirliğini sağlamak için tasarlanmalıdır. Gereksiz her tıklamayı loglamak yerine, iş ve güvenlik açısından kritik aksiyonlar seçilmelidir.

## Yetki testleri nasıl yapılmalı?

Rol matrisi hazırlandıktan sonra test senaryoları oluşturulmalıdır. Test yalnızca “admin her şeyi görüyor mu?” sorusuyla sınırlı kalmamalıdır. Negatif testler de yapılmalıdır: satış kullanıcısı başka temsilcinin müşterisini görebiliyor mu, müşteri başka müşterinin belgesini indirebiliyor mu, bayi başka bayinin sipariş ID’sine erişebiliyor mu?
OWASP, izinlerin her istekte doğrulanması gerektiğini ve yalnızca çoğu istekte kontrol yapmanın yeterli olmadığını vurgular  [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html). Bu nedenle testler hem arayüzde hem API seviyesinde yapılmalıdır.
Örnek test başlıkları:

- Her rol için menü görünürlüğü kontrol edildi mi?

- Buton gizlenmiş olsa bile API isteği reddediliyor mu?

- Kullanıcı URL’de ID değiştirerek başka kayda erişebiliyor mu?

- Veri dışa aktarma rol ve kapsam kontrolünden geçiyor mu?

- Yetki değişiklikleri audit log’a yazılıyor mu?

- Yeni modül eklendiğinde varsayılan erişim kapalı mı geliyor?

## Rol şişmesi nasıl önlenir?

Rol şişmesi, her küçük farklılık için yeni rol oluşturulduğunda ortaya çıkar. Bir süre sonra kimde hangi rol var, hangi rol ne işe yarıyor, hangisi aktif kullanılıyor anlaşılmaz hale gelir. Bu durum hem yönetimi zorlaştırır hem de güvenlik riskini artırır.
Rol şişmesini önlemek için roller görev tanımına göre, veri kapsamı ve özel izinler ise ayrı parametrelerle yönetilmelidir. Örneğin “satış temsilcisi” rolü aynı kalabilir; temsilcinin bölgesi, portföyü veya iskonto limiti ayrı alanlarla belirlenebilir.
Rol listesi düzenli aralıklarla gözden geçirilmelidir. Kullanılmayan roller pasife alınmalı, geçici yetkiler süreli verilmeli, eski çalışan veya görev değişikliği olan kullanıcıların erişimi kontrol edilmelidir.

## Başlamadan önce rol ve izin kontrol listesi

Özel yazılım projesinde rol ve erişim planı için aşağıdaki kontrol listesi kullanılabilir:

- Kullanıcı tipleri iş akışlarına göre belirlendi mi?

- Rol, izin ve veri kapsamı ayrı ayrı yazıldı mı?

- Her modül için rol-izin matrisi hazırlandı mı?

- CRUD dışında kritik aksiyon izinleri tanımlandı mı?

- Veri kapsamı; kullanıcı, ekip, şube, bayi veya müşteri bazında net mi?

- Onay gerektiren işlemler ve limitler belirlendi mi?

- API ve entegrasyon kullanıcıları ayrı ele alındı mı?

- Yetki değişiklikleri ve kritik işlemler audit log’a yazılıyor mu?

- Yeni modüllerde varsayılan erişim kapalı mı?

- Yetki testleri hem arayüz hem API seviyesinde yapılacak mı?

- Roller düzenli olarak gözden geçirilecek mi?

## Sonuç: Rol planı yazılımın yönetilebilirliğini belirler

Özel yazılımda kullanıcı rolleri ve erişim izinleri, güvenlik kadar operasyon yönetimi için de önemlidir. Doğru planlanmış bir rol yapısı kullanıcıların yalnızca ihtiyacı olan veriye erişmesini sağlar, kritik işlemleri kontrol altına alır, hataları azaltır ve sistem büyüdükçe karmaşayı önler.
Webioo, özel yazılım projelerinde rol ve izin yapısını proje başlangıcında iş akışları, veri modeli, yönetim paneli, API bağlantıları, onay süreçleri ve audit log gereksinimleriyle birlikte planlar. Böylece yazılım yalnızca çalışan bir sistem değil, güvenli ve yönetilebilir bir operasyon platformu haline gelir.

## Rol ve yetki yapınızı baştan doğru planlayın
CRM, bayi paneli, müşteri portalı, B2B sipariş sistemi veya özel yönetim paneliniz için kullanıcı rolleri, veri kapsamı ve erişim izinlerini birlikte netleştirebiliriz.[Projemi Değerlendir](/iletisim)

## Sıkça Sorulan Sorular

### Özel yazılımda kullanıcı rolü nedir?

Kullanıcı rolü, kişinin sistemdeki görev grubunu ifade eder. Yönetici, satış temsilcisi, muhasebe, destek ekibi, bayi veya müşteri gibi roller farklı ekranlara, verilere ve işlemlere erişebilir.

### Rol ile izin arasındaki fark nedir?

Rol, kullanıcının görev grubudur; izin ise o rolün hangi işlemleri yapabileceğini belirtir. Örneğin satış temsilcisi bir roldür, teklif oluşturma veya müşteri görüntüleme ise izindir.

### Veri kapsamı neden ayrı planlanmalı?

Çünkü aynı role sahip kullanıcılar aynı verileri görmek zorunda değildir. İki satış temsilcisi müşteri görüntüleyebilir, ancak yalnızca kendi portföylerindeki müşterileri görmelidir. Veri kapsamı bu sınırı belirler.

### RBAC özel yazılım için yeterli mi?

Kullanıcı grupları net ve veri kapsamı basitse RBAC yeterli olabilir. Ancak şube, bayi, müşteri sahipliği, proje üyeliği veya işlem zamanı gibi ek koşullar erişim kararını etkiliyorsa RBAC yanında ABAC benzeri kurallar gerekebilir.

### Rol-izin matrisi ne zaman hazırlanmalı?

Rol-izin matrisi proje başında hazırlanmalıdır. Bu matris ekran tasarımı, backend kontrolü, API yetkilendirmesi, test senaryoları ve audit log gereksinimleri için temel referans olur.

### Yetki testleri nasıl yapılmalı?

Yetki testleri hem arayüzde hem API seviyesinde yapılmalıdır. Kullanıcı menüde görmediği bir işlemi API üzerinden yapabiliyor mu, URL’de ID değiştirerek başka kayda erişebiliyor mu, kritik işlemler loglanıyor mu gibi negatif senaryolar test edilmelidir.

> Orijinal Kaynak: https://www.webioo.com.tr/blog/ozel-yazilimda-kullanici-rolleri-ve-erisim-izinleri-nasil-planlanir