Çok kiracılı SaaS izinleri: organizasyonlar, ekipler ve roller netleşiyor

Hedef basit: bir dakikada açıklanabilecek, öngörülebilir erişim kuralları. Örneğin: "Org verinin sahibidir. Ekipler insanları gruplar. Roller eylemleri tanımlar. Kaynaklar bir orga, bazen bir ekibe aittir. Paylaşım birkaç varsayılan iz üzerinde gider." Bunu açıkça söyleyemiyorsanız, inşa etmek zor, test etmek zor ve değiştirmek korkutucu olur.

Tutulması gereken söz: daha az rol, daha net sahiplik, daha güvenli varsayılanlar. İşe gerçek işlerle bağlantılı küçük bir rol setiyle başlayın, her kaynak için sahipliği belirgin yapın ve varsayılan erişimi en az düzeye getirin. Sonra paylaşımı kazara değil amaçlı yapmaya izin verin.

Düz dille harita: orglar, ekipler, kullanıcılar ve kaynaklar

Uygulamanız birden fazla müşteriye hizmet veriyorsa kuralları yazmadan önce zihinsel haritayı doğru kurun. Çok-kiracılı SaaS izinlerindeki karışıklığın çoğu, aynı kelimenin ürünün farklı yerlerinde farklı anlamlara kaymasından gelir.

Kiracı sınırı için tek bir anlam seçin ve ona sadık kalın. Birçok ürün "organizasyon"u tenant olarak kullanır: tüm veri bir org içinde yaşar ve paylaşım açıkça oluşturulmadıkça hiçbir şey bu çizgiyi geçmez.

Büyüdükçe net kalan basit bir sözlük:

• Organizasyon (tenant): müşteri hesabı ve sert veri sınırı.
• Kullanıcı (kimlik): tek bir oturuma sahip kişi.
• Üyelik: bir kullanıcının bir orga ait olduğunu söyleyen bağlantı ve rol(ler)i.
• Ekip (isteğe bağlı): günlük işler için org içinde bir gruplaşma.
• Kaynak: korumanız gereken her şey (projeler, faturalar, destek talepleri, API anahtarları).

"Bir kişi, birçok org" normaldir. Bir danışman üç müşteri organisyonuna ait olabilir ve her birinde farklı bir role sahip olabilir. Bu yüzden "kullanıcı" ve "üyelik" ayrı olmalı. Kontroller genellikle kullanıcı değil üyeliğe bağlıdır.

Ekipler, "Destek" veya "Finans" gibi gerçek gruplaşmaları yansıtıyorsa faydalıdır. Ekipler, ikinci bir izin sistemi haline geldiğinde gürültü yaratır. Kullanışlı bir test, ekibi bir özellik kuralı belirtmeden bir cümleyle açıklayıp açıklayamadığınızdır.

Örnek: Maria tek oturum açar, sonra Org A ile Org B arasında geçiş yapar. Org A'da Finans'tadır ve faturaları görüntüleyebilir. Org B'de Görüntüleyici'dir ve sadece projeleri okuyabilir. Aynı kullanıcı, farklı üyelikler, tutarlı kaynak türleri, net sınırlar.

Roller, izinler ve kapsam: jargon olmadan

Çok-kiracılı SaaS izinleri, üç şeyi ayırdığınızda anlaşılır kalır:

• Roller: sorumluluğu tanımlayan etiket.
• İzinler: birinin ne yapabildiği.
• Kapsam: nerede yapabildiği.

RBAC düz İngilizceyle

RBAC (role-based access control) demek: bir kullanıcıya bir rol verirsiniz ve o rol izin verilen eylemleri verir. Rol isimleri statüyü değil sorumluluğu anlatmalı. "Fatura Yöneticisi" nettir. "Power User" genellikle tartışma çıkarır.

İzinleri fiiller gibi düşünün ve ürün genelinde tutarlı tutun:

• Görüntüle (okuma)
• Oluştur
• Düzenle
• Sil
• Yönet (davet etme, ayarlar, dışa aktarma ve diğer özel eylemler)

Sonra aynı fiilin farklı yerlerde kullanılabilmesi için kapsam ekleyin. Böylece 20 tane hafifçe farklı rol oluşturmazsınız.

Yaygın ve okunabilir kapsamlar:

• Org-genel
• Sadece ekip
• Kendi öğeleri
• Atanmış

Rol eklemek yerine sahiplik kullanmak

Kendinizi "Proje Düzenleyici" ve "Proje Düzenleyici (Kendi)" gibi roller yaratırken yakalarsanız genellikle sorun rol değil kapsamdır.

Örnek: Bir CRM'de "Satış Temsilcisi"ne fırsatları oluşturma ve düzenleme yetkisi verin, ama kapsamı "kendi öğeleri" ile sınırlayın. "Satış Müdürü" benzer fiillere sahip olsun ama "ekip içi" veya "org-genel" kapsamda. Böylece daha az rol, daha net kurallar ve biri ekip değiştirdiğinde daha az sürpriz olur.

Sağlam bir varsayılan: roller fiilleri verir, sahiplik (veya atama) bu fiillerin nerede çalışacağını sınırlar.

Yüzlerce orga ölçeklenen basit bir kural seti

Modeliniz bir müşteri için çalışıp onda onorgda bozuluyorsa muhtemelen "kim görebilir" ile "ne yapabilir" ve "kimin" karıştırılmıştır. Bunları ayrı tutun ki sistem öngörülebilir kalsın.

Ölçeklenen bir kural seti:

• Her kayıt (proje, fatura, talep, API anahtarı) tam olarak bir ana organizasyona ait olur.
• Bir kullanıcı yalnızca üye olduğu orgların verilerini görebilir. Üye değilse, UI ve API o orgun var olmadığını varsaymalıdır.
• Roller eylemleri kontrol eder (oluştur, düzenle, sil, dışa aktar), ancak yalnızca kullanıcının zaten görebildiği orglarda.
• Sahiplik bir eşitleyicidir. İzin verilen kapsam içinde ekstra haklar verebilir (taslağını düzenleme, kendi API anahtarını yönetme) ama diğer verilere erişimi genişletmez.
• Yönetici (admin) erişimi dar, açık bir istisna olmalıdır. "Admin"in ne yapabildiğini tanımlayın ve admin düzeyindeki rolleri az tutun.

Örnek: Sam Org A ve Org B'ye üyedir. Org A'da Üye ve kendi raporlarını oluşturup düzenleyebilir ama faturalamayı değiştiremez. Org B'de Fatura Yöneticisi'dir ve ödeme yöntemlerini güncelleyip faturaları indirebilir, ama üyeliği o alanı içermiyorsa özel projeleri göremez.

Bu büyümeyi iyi anlamda sıkıcı yapar. Yeni bir org eklemek sadece üyelikler ve roller eklemektir. Temel kurallar aynı kalır.

Adım adım: izin modelinizi tek sayfada tasarlayın

Bir meslektaşın iki dakikada okuyabileceği tek bir sayfa yazın. İzinleri koda bakmadan açıklayabiliyorsanız iyi bir noktadasınız.

1) Kurallardan önce girdileri yazın

Parçaları kasıtlı olarak küçük tutun:

• Sahibini, yöneticiyi, üyeyi, görüntüleyiciyi açıklayabileceğiniz dört kullanıcı tipi seçin.
• İnsanların günlük temas ettiği 3–6 kaynağı listeleyin (projeler, müşteriler, raporlar, faturalama).
• Her kaynak için 2–4 eylem listeleyin (görüntüle, oluştur, düzenle, sil, davet et, dışa aktar).
• Yeni bir üye varsayılan olarak ne alır (genelde görüntüleyici veya üye, admin değil) karar verin.
• "Ekip" neyi değiştirir karar verin. Bunu görünürlük, atama ve raporlama ile sınırlayın, sürpriz yetkilerle değil.

2) Kuralları basit bir tabloda koyun

Rol patlamasını önlemek için kapsamı kullanın. Birçok ürünün sadece üç kapsamı yeter: kendi, ekip, org.

Akıl sağlığı kontrolü: bu sayfayı teknik olmayan bir meslektaşa gösterin ve sorun, "Destek üyesi Satış raporunu düzenleyebilir mi?" Eğer tereddüt ediyorlarsa kapsam veya ekip tanımınız net değil demektir.

Kaynak sahipliği ve paylaşım kuralları: aklı başında kalması

İzinleri anlaşılır tutmak için her kaynağın sahibinin kim olduğunu kararlaştırın, sonra paylaşım seçeneklerini sınırlı tutun.

Varsayılan sahiplik modeli

Çoğu kaynağı org-ait yapın. Müşteriler genelde şirket bazında düşünür: faturalar, projeler, kişiler, talepler ve otomasyonlar organizasyona aittir, bireye değil.

Ekipler hâlâ faydalı olabilir, ama bir ekibi yönlendirme ve görünürlük varsayılanları için bir iş akışı etiketi olarak ele alın, gizli güvenlik mantığı olarak değil. Bir ekip etiketi filtreleri, panoları, bildirimleri veya kuyrukları yönlendirebilir; erişim ise roller ve kapsamdan gelmelidir.

Kullanıcı-ait kaynaklar istisna olmalı: taslaklar, özel notlar, kaydedilmiş görünümler, API belirteçleri veya kişisel ayarlar gibi gerçekten kişisel öğeler. Bir kullanıcı ayrıldığında ne olacağına karar verin: sil, devret veya gizli tut.

Okunması kolay küçük bir paylaşım kural seti:

• Varsayılan org-ait: öğeleri tek bir organization ID altında saklayın.
• İş akışı için ekip-etiketi: yönlendirme için bir ekibe etiketleyin, zorunlu erişim kontrolü için değil.
• Kişi-ait öğeler kişisel: açıkça paylaşılmadıkça özel olsun.
• Paylaşım seviyeleri yalnızca: Özel (sahip), Ekip, Org. Erken aşamada özel öğe bazlı ACL'lerden kaçının.
• "Atandı" ile "erişebilir"i ayırın: atama sorumluluktur, izin değil.

Basit kalan paylaşım

Birisi "Erişim ihtiyacım var" dediğinde hangi seviyede olduğunu sorun: kişisel öğesi mi, ekip işi mi, yoksa tüm org mu? Üçten biri değilse genellikle kapsamlarınızın net olmadığının işaretidir, yeni bir paylaşım modu değil.

Örnek: bir destek talebi org-ait olabilir (yöneticilerin tüm talepleri raporlaması için), Support ekibine etiketlenebilir (doğru kuyruğa gelmesi için) ve Jordan'a atanabilir (sorumluluk için). Atama diğer izinli rollerin görüntülemesini engellememelidir.

Davetler, üyelik değişiklikleri ve orglar arasında geçiş

İzinler genellikle "insan olayları" sırasında bozulur: birini davet etmek, ekipler arasında taşımak veya erişimi kaldırmak. Bu akışlar modelinizin öngörülebilir kalıp kalmayacağını belirler.

Davetler

Davet bir üyelik oluşturma isteği olarak ele alınsın, tek başına erişim olarak değil. Davet kabul edilirse hangi org, ekip (isteğe bağlı) ve rol verileceği açıkça belirtilmeli.

Kuralları sıkı tutun:

• Sadece belirli roller davet edebilir (örneğin, Sahip ve Yönetici). Eğer ekip liderlerini destekliyorsanız, onları yalnızca kendi ekiplerine davet etmekle sınırlayın.
• Davet eden sadece kendi seviyesinde veya altında roller verebilir.
• Süresi dolmuş davetler hiçbir şey yapmaz.
• E-posta zaten bir hesaba aitse kabul edildiğinde üyelik ona eklenir. Değilse kabul hesap oluşturur ve sonra ekler.

Geçici erişim de burada yer alır. "Geçici kullanıcı" rolü icat etmek yerine bir rol verişine bir bitiş tarihi ekleyin. Süre dolunca erişim otomatik düşer ve denetim izi temiz kalır.

Ayrılma ve üyeliklerin kaybolmadan yönetimi

Birisi bir orgu terk ettiğinde kaynaklarıyla ne yapılacağına tahmin yürüterek karar vermeyin. Kuralınız "kaynaklar orga aittir" ise ona bağlı kalın. Kişi geçmiş için yaratıcı olarak kalabilir ama org sahibi olmaya devam eder.

Kullanıcıya ait kaynaklarınız varsa hassas olanlar (projeler, belgeler, API anahtarları) için kaldırmadan önce devretmeyi zorunlu kılın.

Güvenli org değiştirme

Bir oturum birden fazla orga ait olabilir, ama uygulamada her zaman tek bir "aktif org" olmalı. Bunu UI'da belirgin yapın ve her eylemi ona göre kapsamlayın.

Devre dışı bırakma genelde silmeden daha iyidir. Şimdi erişimi kaldırır ve geçmiş işlemleri denetlenebilir kılar.

Kaçınılması gereken yaygın hatalar ve tuzaklar

Çoğu izin modeli kurallardan daha hızlı büyüdüğü için başarısız olur. Temelleri (tenant sınırı, sahiplik, kapsam) koruyun ve diğer her şeyi detay olarak ele alın.

Rol patlaması klasik tuzaktır. Bir uç durum ortaya çıkar ve yeni bir rol yaratırsınız yerine daha net bir izin veya kapsam oluşturmalısınız. Birkaç ay sonra kimse "Manager Plus"ın ne anlama geldiğini bilmez. Özel durum sık gerekiyorsa onu birinci sınıf izin yapın. Nadirse geçici, süresi dolan bir yetkiyle halledin.

İzin kayması sessiz ama daha kötüdür. Birisi "sadece bir istisna" ekler ve model güncellenmeden unutulur. Bir yıl sonra yazılı kurallar ile gerçek sistem uyuşmaz. Önce modeli güncelleyin, sonra uygulayın.

Ekipleri sahte güvenlik sınırları olarak kullanmak sürekli karışıklık yaratır. Eğer kaynaklar org içinde ekipler arasında paylaşılabiliyorsa bunu açıkça söyleyin. Paylaşım mümkün değilse bunu isimlendirmede değil kodda zorlayın.

Erken yakalanacak kırmızı bayraklar:

• Varsayılan olarak tüm müşteri orglarını görebilen "süper admin"
• Sunucu tarafı kontrolleri yerine sadece UI gizleme (gizli butonlar)
• Üyelik kurallarını atlayan API anahtarları veya servis hesapları
• İş unvanlarıyla tanımlanmış roller, eylemlerle değil
• Bir cümlede açıklanamayan istisnalar

Destek bir müşteriye yardımcı olması gerektiğinde, "onlara bir dakika global admin verin" tenant sızıntısına davetiyedir. Bunun yerine belirli org, zaman penceresi ve eylemlerle açık, loglanan erişim tercih edin.

Yayınlamadan önce hızlı kontroller

Her istekte önce aktif organizasyonu çözün (alt alan, header, oturum veya rota üzerinden) ve eşleşmeyenleri reddedin.

Org bağlamından sonra kontrolleri tutarlı bir sırayla yapın: önce üyelik (bu orgda mı üye?), sonra rol (burada ne yapmasına izin var?), sonra sahiplik veya paylaşım (bu kayda erişimi var mı?). Sahiplik kontrollerini üyelikten önce yaparsanız var olan şeyler hakkında bilgi sızdırabilirsiniz.

Basit bir dizi uçtan uca testi gerçek hesaplarla çalıştırın, sadece birim testlerle yetinmeyin:

• Yeni üye görüntüleme, oluşturma ve dışa aktarma denemesi
• Ekip lideri sadece kendi takımını yönetmeye çalışıyor, tüm org değil
• Org yöneticisi rolleri değiştirdikten sonra hassas bir eylem deniyor (silme, dışa aktarma)
• Kaldırılan kullanıcı eski bir sekmeyi açık tutup tekrar deniyor
• Davet edilmiş (kabul etmemiş) kullanıcı eski daveti kullanıp erişim deniyor

Güçleri değiştiren veya veriyi taşıyan işlemler için temel denetim olayları ekleyin: rol değişiklikleri, üyelik kaldırmaları, dışa aktarmalar, silmeler, ayar güncellemeleri. İlk gün mükemmel olması gerekmez ama "kim ne yaptı, ne zaman?" sorusuna yanıt verebilmeli.

Varsayılanları gözden geçirin. Yeni orglar ve yeni üyeler başarılı olmaları için gereken en az erişimle başlamalı. Destek ve satış için kısa bir dahili izin SSS'si de yardımcı olur; örnekler: "Ekip lideri diğer ekipleri görebilir mi?" ve "Kaldırıldıktan sonra erişime ne olur?"

Örnek: tek bir orgdan yüzlerce orga yeniden tasarlamadan geçiş

Küçük, gerçek bir kurulumla başlayın: bir müşteri şirketi (bir org) ve iki ekip, Satış ve Operasyon. Herkes bir kez oturum açar, sonra ait olduğu orgu seçer. Satış müşteri kayıtlarına ve tekliflere ihtiyaç duyar. Operasyon faturalamaya ve iç ayarlara ihtiyaç duyar.

Aşama 1: bir org, iki ekip

Ekipleri gruplaşma ve iş akışı olarak tutun, ana izin anahtarı yapmayın. Varsayılanları ve yönlendirmeyi etkileyebilirler ama tek kapı olmamalılar.

Aşama 2: sabit roller, öngörülebilir kapsamlar

Küçük bir rol seti seçin ve özellikler geldikçe sabit tutun: Yönetici, Üye, Görüntüleyici. Rol "Bu orgda ne yapabilirsin?" sorusuna cevap verir. Kapsam "Nerede yapabilirsin?" sorusuna.

Aşama 3: sahiplik düzenleme kararlarını kolaylaştırır

Bir sahiplik kuralı ekleyin: her kaynağın bir orgu ve bir sahibi (çoğunlukla oluşturucu) olsun. Düzenleme, eğer Yöneticiyseniz veya sahibiyseniz ve rolünüz "kendi düzenle"yi içeriyorsa izinlidir. Görüntüleme, rolünüz o kaynak türü için "görüntüle"yi içeriyorsa izinlidir.

Örnek: bir Satış Üyesi bir teklif oluşturur. Başka bir Satış Üyesi teklifi görebilir ama paylaşılmadıkça veya yeniden atanmadıkça düzenleyemez. Bir Operasyon Görüntüleyicisi yalnızca kurallarınız Ops'un Satış kaynaklarını görmesine izin veriyorsa görebilir.

Aşama 4: 200 org, aynı kurallar

200 müşteri orgu devreye aldığınızda aynı rolleri ve sahiplik kurallarını yeniden kullanırsınız. Üyelikleri değiştirirsiniz, modeli değil. Destek talepleri "X'e erişim verebilir misiniz?" artık bir kontrol listesine dönüşür: orgu ve kaynağı doğrula, kullanıcının o orgdaki rolünü kontrol et, sahiplik ve paylaşımı kontrol et, sonra rolü değiştir veya kaynağı paylaş. Tek seferlik istisnalardan kaçının ve denetim notu bırakın.

Sonraki adımlar: uygulayın, test edin ve güvenle yineleyin

Tek sayfa modelinizi sözleşme gibi ele alın. Her API çağrısında ve her UI ekranında uygulayabileceğiniz kuralları hayata geçirin; aksi halde izinler "duruma bağlı"ya kayar.

Küçük başlayın: birkaç rol, net kapsamlar ve basit sahiplik. Yeni bir istek geldiğinde ("Editor-Yönetici rolü ekleyebilir miyiz?"), önce sahipliği veya kapsamı sıkılaştırın. Yeni roller nadir olmalı.

Eklediğiniz her yeni kaynak için temelleri tutarlı yapın:

• org_id saklasın (ve ekip uygunsa team_id)
• Görünürlük kuralı olsun (özel, ekip, org)
• Hassas eylemler için denetim olayları kaydetsin (davetler, rol değişiklikleri, dışa aktarmalar)
• Her sorguda kapsamla filtrelensin (sadece UI'da değil)
• Oluşturulduktan hemen sonra kimlerin görebileceğine dair öngörülebilir varsayılanları olsun

Kenar durumları cilalamadan önce gerçek akışları test edin: davetler, org değiştirme, admin sayfaları ve biri ortadayken erişimi kaybettiğinde ne olduğuna bakın.

Eğer sohbet tabanlı bir uygulama oluşturucuyla çalışıyorsanız, izin modelini önce düz dilde yazmak ve ürün spesifikasyonunun yanında tutmak işe yarar. On Koder.ai (koder.ai), Planning Mode artı anlık görüntüler ve geri alma, bu senaryoları denemek ve kuralların web, backend ve mobilde aynı davrandığından emin olmak için pratik bir yoldur.