İç araçlar için RBAC vs ABAC: ölçeklenen izinleri seçmek

İç araçlarda izinlerin neden karıştığı\n\nİç araçlar bir işletmenin en hassas parçalarına yakındır: müşteri kayıtları, iadeler, faturalar, bordro notları, anlaşma değerleri ve özel iç yorumlar. Herkes her şeyi görmemeli, düzenleyebilenlerin sayısı daha da az olmalı.\n\nİzinler genellikle basit başlar: “Destek biletleri görüntüleyebilir”, “Finans iadeleri onaylayabilir”, “Yöneticiler ekip performansını görebilir.” Sonra organizasyon büyür, süreçler değişir ve araç istisnalarla dolu bir yamaya dönüşür.\n\nBu “sonra patlama” paterni yaygındır:\n\n- Rol yayılımı: önce Support, sonra Support - Senior, sonra Support - EU, sonra Support - EU - Night Shift eklersiniz; sonunda kim hangi rolün ne içerdiğini bile hatırlamaz.\n- İstisna artışı: birkaç kişinin “sadece bir ekstra izne” ihtiyacı olur, tek seferlik geçişler yığılır.\n- Gizli maruz kalma: bir ekran yeniden kullanıldığında erişim tekrar kontrol edilmezse biri maaş notlarını, müşteri PII'sini veya gelir raporlarını görebilir.\n- Kırık iş akışları: bir kullanıcı kaydı görebilir ama bir sonraki adımı atamaz (ya da daha kötüsü, bağlamı görmeden adımı atabilir).\n- Ağır denetimler: “Kim $1.000 üzeri iadeyi onaylayabilir?” sorusuna elle kazma yapmadan cevap vermek zordur.\n\nRBAC mı yoksa ABAC mı seçeceğinize erken karar vermenin amacı sadece ekranları kilitlemek değil. Amaç, yeni ekipler, bölgeler ve politikalar geldiğinde kuralların anlaşılabilir kalmasını sağlamaktır.\n\nDayanıklı bir izin modeli dört niteliğe sahiptir: açıklaması kolay, gözden geçirilmesi kolay, kötüye kullanımı zor ve değiştirmesi hızlı.\n\n## RBAC basitçe (roller ve ne açtıkları)\n\nRBAC (rol tabanlı erişim kontrolü) “iş unvanı” yaklaşımıdır. Bir kullanıcı bir veya daha fazla rol alır (Support Agent, Admin). Her rol, o rolün neleri görebileceği ve yapabileceği konusunda sabit bir setle gelir. İki kişi aynı rolü paylaşıyorsa aynı erişimi alır.\n\nRBAC, ekipler günlük olarak çoğunlukla aynı şekilde çalışıyorsa ve ana sorular özellik düzeyindeyse iyi çalışır: “Bu ekranı kullanabilir mi?” veya “Bu işlemi yapabilir mi?”\n\nDestek konsolu için örnek roller:\n\n- Support Agent: biletleri görüntüle, müşterilere yanıt ver, iç not ekle\n- Support Lead: bir ajanın yapabildiği her şey artı biletleri yeniden atama ve ekip metriklerini görme\n- Admin: kullanıcıları yönet, sistem ayarlarını değiştir, izin kurallarını düzenle\n\nTemel fikir rolleri sorumluluklara eşlemektir, belirli kişilere değil. Sorumluluklar sabit olduğunda roller de sabit kalır ve model açıklaması kolay olur.\n\nRBAC iyi uyar när:\n\n- Organizasyon şeması açıksa (ekipler, liderler, adminler)\n- Çoğu erişim kararı “bu özelliği kullanabilir mi?” şeklindeyse\n- İşe alımın öngörülebilir olması gerekiyorsa (rol X atandığında iş biter)\n- Denetimler önemliyse (bir rolün neler yapabildiğini listelemek kolaydır)\n\nRBAC'ın zorlukları gerçeklik karmaşaysa başlar. İç araçlar istisnaları toplar: bir destek temsilcisi iade yapabiliyor, bir finans kullanıcısı yalnızca tek bir bölgeyi görmeli, bir yüklenici biletleri görebilir ama müşteri PII'sini göremez. Her istisnayı yeni bir rol oluşturarak çözerseniz rol patlaması yaşarsınız.\n\nRBAC'ın tek başına başarısız olduğuna dair pratik bir işaret: her hafta “özel roller” eklemeye başlarsınız.\n\n## ABAC basitçe (özniteliklere dayalı kurallar)\n\nABAC (öznitelik tabanlı erişim kontrolü) erişimi sadece iş unvanlarına göre değil, kurallar aracılığıyla belirler. “Finans rolü ne yapabilir?” yerine ABAC şöyle sorar: “Bu kişi kim, bu kayıt ne, şu anda ne oluyor; izin verilmeli mi?”\n\nÖznitelikler zaten takip ettiğiniz gerçeklerdir. Bir kural şunları diyebilir:\n\n- “Destek ajanları bölgelerindeki biletleri görüntüleyebilir.”\n- “Yöneticiler iş saatlerinde 5.000$ altındaki masrafları onaylayabilir.”\n\nÇoğu ABAC sistemi birkaç öznitelik kategorisine dayanır:\n\n- Kullanıcı öznitelikleri: departman, bölge, yönetici statüsü\n- Veri öznitelikleri: kayıt sahibi, bilet önceliği, fatura durumu\n- Bağlam öznitelikleri: günün saati, cihaz türü, ağ konumu\n- Eylem öznitelikleri: görüntüleme vs düzenleme vs dışa aktarma\n\nSomut örnek: bir destek ajanı yalnızca (a) bilet önceliği kritik değilse, (b) bilet kendisine atanmışsa ve (c) müşteri bölgesi kendi bölgesiyle eşleşiyorsa bileti düzenleyebilir. Bu, Support - EU - Noncritical ve Support - US - Noncritical gibi ayrı roller yaratmaktan kaçınmanızı sağlar.\n\nTakas, ABAC kuralları biriktikçe mantığını anlamanın zorlaşabilmesidir. Birkaç ay sonra insanlar “Faturaları kim dışa aktarabilir?” gibi temel sorulara uzun bir koşul zinciri okumadan cevap veremez hale gelebilir.\n\nİyi bir ABAC alışkanlığı: kuralları az, tutarlı ve sade dille adlandırılmış tutmaktır.\n\n## Kayıt düzeyi erişim: en çok hatanın olduğu yer\n\nBirçok ekip izinleri “bu ekranı açabilir misin?” olarak ele alır. Bu sadece ilk katmandır. Kayıt düzeyi erişim farklı bir soruyu yanıtlar: ekranı açabilseniz bile hangi satırları görmeye veya değiştirmeye izinlisiniz?\n\nBir destek temsilcisi ve bir finans analisti ikisi de Müşteriler sayfasına erişebilir. Sadece ekran düzeyinde durursanız herkese her şeyi gösterme riski alırsınız. Kayıt düzeyi kurallar, o sayfa içinde hangi verilerin yüklendiğini daraltır.\n\nYaygın kayıt düzeyi kuralları şunlardır:\n\n- Sadece sizin müşterileriniz (assigned_owner_id = current_user.id)\n- Sadece kendi bölgeniz (customer.region IN current_user.allowed_regions)\n- Sadece kendi maliyet merkeziniz (invoice.cost_center_id IN current_user.cost_centers)\n- Takımınızın biletleri (ticket.team_id = current_user.team_id)\n- Sadece sizin oluşturduklarınız (created_by = current_user.id)\n\nKayıt düzeyi erişimin veri çekilirken ve değiştirilirken — yalnızca UI'de değil — zorunlu kılınması gerekir. Pratikte bu sorgu katmanı, API uç noktaları ve iş mantısı anlamına gelir.\n\nTipik bir hata modu “kilitli sayfa, açık API”dır. Bir buton admin olmayanlar için gizlenmiş olabilir, ancak uç nokta hala tüm kayıtları döndürebilir. Uygulamaya erişimi olan herkes bazen isteği yeniden kullanarak veya filtreyi değiştirerek o çağrıyı tetikleyebilir.\n\nModelinizi birkaç soruyla sağlamlaştırın:\n\n- Bir kullanıcı uç noktayı doğrudan çağırabilirse, sadece izinli kayıtları mı alıyor?\n- Liste, detay, dışa aktarma ve sayma uç noktaları aynı kuralları uyguluyor mu?\n- Oluşturma, güncelleme ve silme ayrı ayrı kontrol ediliyor mu (sadece okuma değil)?\n- Adminler kasıtlı olarak mı yoksa kazara mı kuralları atlıyor?\n\nEkran izinleri kim bir odaya girebileceğini belirler. Kayıt düzeyi erişim ise içeride hangi çekmeceleri açabileceğini belirler.\n\n## Gerçek örnekler: destek, finans ve yöneticiler\n\nAmaç “mükemmel güvenlik” değildir. Amaç bugün insanların anlayabileceği, sonrasında bozmadan değiştirebileceğiniz izinlerdir.\n\n### Destek ekibi\n\nDestek genellikle kayıt düzeyi kurallara ihtiyaç duyar, çünkü “tüm biletler” nadiren doğrudur.\n\nBasit bir model: ajanlar kendilerine atanmış ve kuyruklarındaki biletleri açıp güncelleyebilir. Takım liderleri biletleri yeniden atayabilir ve yükseltmelerde müdahale edebilir. Yöneticiler genellikle panoları görmesi gerekir ancak her bileti düzenleme yetkisine sahip olmamalıdır.\n\nToplu işlemler ve dışa aktarmalar ortak bükülmedir. Birçok ekip toplu-kapatmaya izin verir, toplu yeniden atamayı kısıtlar ve dışa aktarmaları liderlere ve yöneticilere günlük kaydı tutarak sınırlar.\n\n### Finans ekibi\n\nFinans erişimi çoğunlukla onay adımları ve temiz bir denet izine ilişkindir.\n\nYaygın bir kurulum: bir AP çalışanı faturaları oluşturup taslak olarak kaydedebilir, ancak onaylayamaz veya ödeme yapamaz. Bir controller onaylayıp ödemeyi serbest bırakabilir. Denetçiler yalnızca ekler dahil okunabilir olmalı, tedarikçi bilgilerini değiştirememelidir.\n\nGerçekçi bir kural: “AP çalışanları oluşturdukları taslakları düzenleyebilir; gönderildikten sonra yalnızca controller'lar değiştirebilir.” Bu durum kayıt düzeyi erişimidir (durum + sahip) ve genellikle daha fazla rol oluşturmaktan ziyade ABAC ile daha iyi uyar.\n\n### Yöneticiler\n\nÇoğu yönetici geniş görünürlüğe ama sınırlı düzenleme gücüne ihtiyaç duyar.\n\nPratik bir desen: yöneticiler çoğu operasyonel veriyi görebilir, ancak sadece ekiplerine ait veya doğrudan raporlarına bağlı kayıtları (izin talepleri, hedefler, performans notları) düzenleyebilir. team_id, manager_id ve istihdam durumu gibi öznitelikler, her departman için ayrı bir rol oluşturmaktan daha açıktır.\n\nBu gruplar arasında genelde ihtiyaç duyulanlar:\n\n- Destek: atama/kuyruk bazlı görünürlük, dikkatli dışa aktarmalar, kontrollü yeniden atama\n- Finans: durum tabanlı kurallar (taslak vs gönderilmiş vs onaylanmış), sıkı onaylar, denetim-dostu salt okuma erişimi\n- Yöneticiler: geniş görüntüleme, dar düzenleme (ekip-sahipli veya doğrudan rapor kayıtları)\n\n## Karar matrisi: roller vs öznitelikler vs kayıt düzeyi kuralları\n\n“Hangisi daha iyi?” diye tartışmak yerine, erişim probleminizin hangi parçalarının hangi modele uyduğunu sorun. Çoğu ekip hibritle sonuçlanır: geniş erişim için roller, istisnalar için öznitelikler ve “sadece benim verilerim” için kayıt düzeyi filtreleri.\n\n| Değerlendirdiğiniz konu | Roller (RBAC) | Öznitelikler (ABAC) | Kayıt düzeyi filtreleri |\n|---|---:|---|---|\n| Ekip büyüklüğü | Küçük ve orta ekipler, net iş fonksiyonları için en iyi. | Ekipler büyüdükçe ve iş tanımları bulanıklaştıkça değerli olur. | Sahiplik önemli olduğunda, ekip boyutundan bağımsız olarak gerekli. |\n| İstisna sıklığı | “Destek içindeki herkes hariç...” denildiğinde dağılıp bozulur. | “bölge = EU ve kıdem = taşeron ise...” gibi durumları roller çoğaltmadan halleder. | “sadece bana atanmış biletler” ve “maliyet merkezime ait faturalar”ı yönetir. |\n| Denet ihtiyaçları | Açıklaması kolay: “Finans rolü faturaları dışa aktarabilir.” | Kurallar açıkça dokümante edilirse denet için uygun olabilir. | Erişimin belirli verilere sınırlandığını kanıtladığı için denetler için sıkça gereklidir. |\n| Yeniden yapılanma riski | Roller org şemasını çok yakından yansıtıyorsa daha yüksek risk. | department_id, employment_type gibi stabil öznitelikler kullanılırsa daha düşük risk. | Sahiplik alanları doğru kalırsa reorg'larda orta düzey risk: kurallar ayakta kalır. |\n\nİzin mantığını aylık fatura gibi düşünün. Her ekstra rol, kural ve istisna test, açıklama ve hata ayıklama maliyeti getirir. Bugün gerçek senaryoları karşılayan en küçük miktarı harcayın.\n\nPratik bir varsayılan:\n\n- Genel hatlar için RBAC ile başlayın (Support, Finance, Manager).\n- Tekrarlayan koşullar için ABAC ekleyin (bölge, kıdem, müşteri seviyesi).\n- Kullanıcıların “sadece kendi öğelerini” görmesi gerektiğinde kayıt düzeyi kurallar ekleyin.\n\n## Adım adım: ekranları oluşturmadan önce izinleri tasarlayın\n\nEğer izinleri UI yapıldıktan sonra belirlerseniz genellikle çok fazla rol veya bir sürü özel durumla bitersiniz. Basit bir plan sürekli yeniden yapımın önüne geçer.\n\n### 1) Eylemlerle başlayın, ekranlarla değil\n\nHer iş akışında insanların gerçekten ne yaptığını yazın:\n\n- Görüntüle (read)\n- Oluştur (create)\n- Düzenle (edit)\n- Onayla (approve)\n- Dışa aktar (export)\n- Sil (delete)\n\nBir iadeler akışında, Approve ile Edit aynı eylem değildir. Bu tek ayrım sıkça sert bir kurala mı yoksa sadece bir role mi ihtiyaç olduğunu belirler.\n\n### 2) İnsanların tanıdığı roller tanımlayın\n\nToplantı gerektirmeden herkesin tanıyacağı rolleri seçin: Support Agent, Support Lead, Finance Analyst, Finance Manager, Auditor, Admin. “Support Agent - VIP notları düzenleyebilir” gibi rollerden kaçının; bunlar hızla çoğalır.\n\n### 3) Gerçek istisnaları yaratan öznitelikleri listeleyin\n\nABAC'ı yalnızca karşılığını verdiğinde ekleyin. Tipik öznitelikler bölge, ekip, müşteri seviyesi, sahiplik ve tutardır.\n\nBir istisna ayda birden daha az oluyorsa, kalıcı bir izin kuralı yerine manuel onay adımını düşünün.\n\n### 4) Kayıt düzeyi kurallarını bir cümlelik politikalara dönüştürün\n\nKayıt düzeyi erişim çoğu iç aracın bozulduğu yerdir. Bir teknik olmayan yöneticiye gösterebileceğiniz kurallar yazın:\n\n“Destek Ajanları kendi bölgelerindeki biletleri görüntüleyebilir.”\n\n“Finans Analistleri onaylanana kadar oluşturdukları faturaları düzenleyebilir.”\n\n“Yöneticiler yalnızca ekipleri için 500$ üzeri iadeleri onaylayabilir.”\n\nBir kuralı bir cümlede ifade edemiyorsanız, süreç muhtemelen net değildir.\n\n### 5) İnşa etmeden önce beş gerçek kişiyle test edin\n\nGerçek senaryolarla yürütün:\n\n- VIP müşteriye bakan bir destek ajanı\n- Bir faturayı düzelten finans analisti\n- Büyük bir iadeyi onaylayan yönetici\n- Bakım yapan bir admin\n- Tarihçeyi görmesi gereken ama hiçbir şeyi değiştirmemesi gereken bir denetçi\n\nBuradaki karışıklıkları düzeltin; izinler labirente dönüşmeden önce.\n\n## Yaygın tuzaklar (ve nasıl kaçınılır)\n\nÇoğu izin hatası RBAC veya ABAC seçiminden ziyade küçük istisnaların birikmesiyle olur; sonunda kim neyi neden yapabildiğini açıklayamaz hale gelir.\n\nRol patlaması genellikle “Support Lead bir ekstra butona ihtiyaç duyuyor” ile başlar ve sonra bir izin farkıyla 25 role dönüşür. Rolleri geniş (iş-şekilli) tutun ve tekrar eden kenar durumlar için az sayıda kural bazlı istisna kullanın.\n\nOkunmaz öznitelik mantığı ABAC'in aynı sorunudur. “department == X AND region != Y” gibi koşullar her yerde dağınık haldeyse denetimler tahmin yürütmeye döner. Adlandırılmış politikalar kullanın (en azından ortak bir dökümanda tutulan tutarlı etiketler) böylece bir formülü çözmek yerine “RefundApproval politikası” diyebilirsiniz.\n\nDışa aktarmalar, raporlar ve toplu işlemler sızıntıların olduğu yerlerdir. Ekipler bir kayıt görünümünü kilitler sonra dışa aktarımın aynı kontrolleri atladığını unutur. Her ekran dışı yolu da birincil eylem olarak ele alın ve kendi izin kontrolüne sahip olsun.\n\nİzlenecek tuzaklar:\n\n- Her istisna için yeni bir rol oluşturmak\n- Okunması zor veya adlandırılmamış öznitelik kuralları\n- Dışa aktarmaların, zamanlı raporların ve toplu işlemlerin kontrolleri atlaması\n- Farklı araçların aynı erişim sorusuna farklı cevaplar vermesi\n- Kayıt düzeyi kurallarının bir yerde uygulanıp başka yerde uygulanmaması\n\nEn güvenli çözüm roller, öznitelikler ve kayıt düzeyi kuralları için tek bir gerçek kaynağın olması ve bunun backend mantığında tutarlı şekilde uygulanmasıdır.\n\n## Gönderim öncesi hızlı kontrol listesi\n\nModeliniz açıklaması güçse, birinin “O müşteriyi görmem gerek” veya “Neden bunu dışa aktarabiliyorlar?” demesi durumunda hata ayıklamak daha zor olacaktır.\n\nÇoğu sürprizi yakalayan beş kontrol:\n\n- Gerçek bir kullanıcı erişimini bir cümleyle anlatabiliyor mu (örnek: “Ben Support, bölge = EU, bölgemdeki biletleri görüntüleyebilirim ama dışa aktarım yapamam”)? Eğer hayırsa kurallar muhtemelen çok dağınık.\n- “Kim dışa aktarabilir?” ve “Kim onaylayabilir?” sorularına açık cevaplarınız var mı? Dışa aktarma ve onayı yüksek riskli eylemler olarak ele alın.\n- Kayıt düzeyi kuralları verinin çekildiği her yerde (API uç noktaları, raporlar, arka plan işleri) uygulanıyor mu, sadece butonları gizlemekle yetinmiyor musunuz?\n- Hassas eylemler için varsayılan güvenli mi (deny by default)? Yeni roller, öznitelikler ve ekranlar güçlü izinleri kazara miras almamalı.\n- “Bu belirli kaydı kim hangi nedenle görebiliyor?” sorusuna bir dakika altında, tek bir gerçek kaynaktan (rol, öznitelikler, kayıt sahipliği/durumu) cevap verebiliyor musunuz?\n\nÖrnek: Finans tüm faturaları görebilir, ama sadece Approver'lar onaylayabilir ve sadece Manager'lar tam tedarikçi listesini dışa aktarabilir. Destek biletleri görüntülenebilir ama sadece bilet sahibinin takımı iç notları görebilir.\n\n## İzinleri her şeyi bozmadan değiştirmek\n\nİzinler sıkıcı nedenlerle değişir: yeni bir yönetici gelir, finans AP ve AR olarak ayrılır veya şirket başka bir ekip satın alır. Değişikliklerin küçük, geri alınabilir ve gözden geçirilmesi kolay olmasını planlayın.\n\nErişimi tek bir büyük “süper rol”e bağlamaktan kaçının. Yeni erişimi ya yeni bir rol, yeni bir öznitelik veya dar bir kayıt kuralı olarak ekleyin, sonra gerçek görevlerle test edin.\n\n### Yeniden tasarım yapmadan erişim ekleme\n\nYeni bir departman ortaya çıktığında (veya bir birleşme yeni ekipler eklediğinde), temel rolleri sabit tutup etraflarına katmanlar ekleyin.\n\n- Temel rolleri az tutun (Support, Finance, Manager), sonra küçük eklentiler ekleyin (Refunds, Export, Approvals).\n- Yeni grupların yeni roller gerektirmemesi için organizasyon değişiklikleri için öznitelikleri tercih edin (team, region, cost center).\n- Sahiplik ve atama için kayıt düzeyi kuralları kullanın (ticket.assignee_id, invoice.cost_center).\n- Hassas eylemler için onay adımı ekleyin (ödeme, zarar yazımı).\n- Dışa aktarmayı neredeyse her yerde ayrı bir izin olarak ele alın.\n\nGeçici erişim için kalıcı rol değişikliği gerekmemeli. Tatil devriye veya olay müdahalesi için zaman sınırlı izinler kullanın: “Finance Approver 48 saat için”, bitiş tarihi ve bir sebep ile.\n\n### Denet ritmi ve soruşturma için hazır günlükler\n\nBasit bir gözden geçirme düzeni kullanın: para ve dışa aktarmalar gibi yüksek riskli izinler için aylık, geri kalanı için üç aylık ve herhangi bir yeniden yapılanma veya birleşme sonrası inceleme.\n\nKim ne yaptı, hangi kayda dokundu ve neden izin verildiğini cevaplayacak kadar günlük tutun:\n\n- Kim görüntüledi, düzenledi, onayladı veya dışa aktardı\n- Ne zaman oldu (ve yakalama yapıyorsanız nereden)\n- Hangi kayıt dokunuldu (ID'ler, tür, düzenlemeler için önce/sonra)\n- Neden izin verildi (rol, öznitelikler, kayıt kuralı, geçici izin)\n- Erişimi kim verdi (ve ne zaman süresi dolacak)\n\n## Sürdürülebilir bir modeli uygulamak için sonraki adımlar\n\nKüçük, sıkıcı bir izin modeliyle başlayın. Altı ay sonraki değişimi atlatacak olan budur.\n\nİyi bir varsayılan basit RBAC'tir: gerçek iş fonksiyonlarına uyan birkaç rol (Support Agent, Support Lead, Finance, Manager, Admin). Bu roller büyük kapıları kontrol etsin: hangi ekranların var olduğu, hangi eylemlerin kullanılabileceği ve hangi iş akışlarının başlatılabileceği.\n\nABAC'ı yalnızca aynı gerçek istisnaları tekrar görüyorsanız ekleyin. ABAC koşulların önemli olduğu (tutar limitleri, bölge kısıtları, sahiplik, durum) durumlarda parıldar, ancak dikkatli test ve açık sahiplik ister.\n\nKuralları önce sade cümleler olarak yazın. Bir kuralı bir cümlede ifade edemiyorsanız, onu sürdürmek zor olacaktır.\n\nEğer bunu gerçek bir iç araçta hızlıca denemek istiyorsanız, AppMaster gibi bir no-code platformu rolleri, owner/team/status gibi veri alanlarını ve backend tarafından zorlanan iş akışlarını erkenden modellemenize yardımcı olabilir.