Farklı ürünler arasında roller, gruplar ve izinleri merkezileştiren bir web uygulamasını nasıl tasarlayıp inşa edebileceğinizi; denetimler, SSO ve güvenli yayılım süreçleriyle birlikte öğrenin.
“Birden fazla ürün arasında izinleri yönetmemiz gerekiyor” dendiğinde genellikle üç durumdan biri kastedilir:
Her durumda temel sorun aynıdır: erişim kararları çok fazla yerde alınıyor ve “Admin”, “Manager” veya “Read-only” gibi rollerin tanımları çelişiyor.
Ekipler genellikle sorunun varlığını net olarak söylemeden önce aksaklığı hissederler.
Tutarsız roller ve politikalar. Bir üründeki “Editor” kayıtları silebilirken diğerinde silemez. Kullanıcılar neye ihtiyaçları olacağını bilmedikleri için gereksiz erişim isterler.
Manuel provisyon/iptal. Erişim değişiklikleri rastgele Slack mesajları, hesap tabloları veya bilet kuyruğu üzerinden yapılır. Offboarding özellikle risklidir: bir araçta erişim gider ama diğerinde kalır.
Sahiplik belirsizliği. Kim erişimi onaylayabilir, kim gözden geçirmeli veya bir izin hatası olayına kim hesap vermeli bilinmez.
İyi bir izin yönetimi web uygulaması sadece bir kontrol paneli değildir—ortak bir anlayış yaratır.
Merkezi yönetim ve tutarlı tanımlar. Roller anlaşılır, yeniden kullanılabilir ve ürünler arasında (veya farklar açıkça belirtilerek) net şekilde eşlenir.
Koruyucu sınırlar içinde self‑servis. Kullanıcılar doğru kişiyi aramadan erişim isteyebilir; hassas izinler yine de onay ister.
Onay akışları ve hesap verebilirlik. Her değişikliğin sahibi olmalı: kim istedi, kim onayladı, neden.
Varsayılan olarak denetlenebilirlik. “Kim neye, ne zaman erişti?” sorusunu beş sistemin loglarını birleştirmeden yanıtlayabilmelisiniz.
Hız ve güvenlikle ilişkili çıktıları izleyin:
Erişim değişikliklerini hem daha hızlı hem de daha öngörülebilir hale getirebilirseniz doğru yoldasınız demektir.
Rol tasarlamaya veya teknoloji seçmeye başlamadan önce, izin uygulamanızın birinci günde hangi alanları kapsaması gerektiğini ve açıkça neyi kapsamayacağını netleştirin. Dar bir kapsam, yarıda her şeyi yeniden inşa etmenizi engeller.
Kısa bir listeyle (genellikle 1–3 ürün) başlayın ve her birinin bugün erişimi nasıl ifade ettiğini yazın:
is_admin gibi flag’ler mi kullanılıyor?Eğer iki ürün temelde farklı modeller kullanıyorsa, bunu erken not edin—zorla tek bir şekle sokmak yerine çeviri katmanına ihtiyaç duyabilirsiniz.
İzin sisteminiz sadece “son kullanıcıları” yönetmemeli. En az şunları tanımlayın:
Sözleşmeli çalışanlar, paylaşılan posta kutuları ve birden fazla organizasyona ait kullanıcılar gibi uç durumları da yakalayın.
İş ve kullanıcılar için önemli eylemleri listeleyin. Yaygın kategoriler:
Bunları nesneye bağlı fiiller olarak yazın (ör. “workspace ayarlarını düzenle”), belirsiz etiketler kullanmayın.
Kimliklerin ve özniteliklerin nereden geldiğini netleştirin:
Her kaynak için izin uygulamanızın neyi sahiplenip neyi aynaladığına ve çakışma olduğunda nasıl çözüleceğine karar verin.
İlk büyük karar: yetkilendirme “nerede” yaşasın? Bu seçim entegrasyon çabasını, admin deneyimini ve izinleri güvenle geliştirme şeklini belirler.
Merkezi modelde, tüm ürünler için erişimi değerlendiren özel bir authorization service vardır. Ürünler bu servise çağrı yapar (veya merkezi verilen kararları doğrular) ve sonra eylemi izin verir.
Tutarlılığı, çapraz‑ürün rollerini ve tek bir yerde denetim yapmayı kolaylaştırır. Başlıca maliyet entegrasyondur: her ürün paylaşılan servisin kullanılabilirliğine, gecikmesine ve karar formatına bağımlı olur.
Federated modelde, her ürün kendi izinlerini uygular ve değerlendirir. Yönetici uygulamanız esasen atama iş akışlarını yönetir ve sonucu her ürüne senkronize eder.
Bu, ürün özerkliğini maksimize eder ve ortak runtime bağımlılıklarını azaltır. Dezavantajı sürüklenme (drift): isimler, anlamlar ve uç durumlar farklılaşarak çapraz‑ürün yönetimini ve raporlamayı zorlaştırır.
Pratik bir orta yol: izin yöneticisini kontrol düzlemi (tek bir admin konsolu) olarak kullanmak, ürünleri ise uygulama noktaları olarak bırakmaktır.
Ortak bir izin katalogu oluşturun (ör. “Billing Admin”, “Read Reports”) ve aynı zamanda ürün‑özgü izinlere yer verin. Ürünler güncellemeleri (roller, atamalar, grup eşlemeleri) çeker veya alır ve yerelde uygular.
Ürün büyümesi bekliyorsanız, hibrit genellikle en iyi başlangıçtır: tek bir yönetici konsolu deneyimi sunar ama her ürünü aynı runtime karar motoruna zorlamaz.
Bir izin sisteminin başarısı veritabanı/modeline bağlıdır. İnsanların kolay anlayacağı basit bir RBAC ile başlayın. RBAC çok kaba gelmeye başladığında ABAC ekleyin.
En azından şu kavramları açıkça modelleyin:
project.read, project.write, billing.manage).Pratik bir desen: rol atamaları bir principal (kullanıcı veya grup) ile bir rolu bir kapsamta (ürün geneli, kaynak seviyesi veya ikisi) bağlar.
Her ürün için roller tanımlayın, böylece her ürünün sözcükçesi net kalır (örn. Ürün A’daki “Analyst” zorunlu olarak Ürün B’deki “Analyst” ile aynı olmak zorunda değildir).
Sonra rol şablonları ekleyin: tenantlar, ortamlar veya müşteriler arasında tekrar kullanılabilecek standart roller. Üzerine de birden fazla ürünü kapsayan paketler (bundles) oluşturun (örn. “Support Agent bundle” = Ürün A + Ürün B + Ürün C rolleri). Paketler yöneticilik işini azaltır fakat her şeyi tek bir mega‑role çekmez.
Varsayılan deneyimi güvenli yapın:
billing.manage, user.invite, audit.export gibi yüksek riskli izinleri ayrı tutun; bunları tek bir “admin”in arkasına saklamayın.RBAC ile temiz ifade edilemeyen politika kuralları gerektiğinde ABAC ekleyin: “kullanıcı yalnızca kendi bölgesindeki ticket’ları görebilir” veya “sadece staging’e deploy edebilir” gibi. ABAC’ı kısıtlar için (bölge, ortam, veri sınıflandırması) kullanın; insanlar rollerle düşünmeye devam etsin.
Daha derin rol isimlendirme ve kapsam konvansiyonları için dahili dokümanlarınıza veya referans sayfanıza başvurun: /docs/authorization-model.
İzin uygulamanız insanları, ürünleri ve politikaları birbirine bağlar—bu yüzden her isteğin kim tarafından yapıldığını, hangi ürünün sorduğunu ve hangi izinlerin uygulanacağını belirleyecek net bir plan gerekir.
Her ürünü (ve ortamı) kendi kimliğiyle bir istemci olarak ele alın:
Hangi yöntemi seçerseniz seçin, her authorization/audit etkinliğinde ürün kimliğini loglayın ki “hangi sistem bunu istedi?” sorusuna cevap verebilesiniz.
İki giriş noktasını destekleyin:
Oturumlar için kısa ömürlü erişim tokenleri + sunucu tarafı session veya refresh token döndürme kullanın. Logout ve oturum iptalini (özellikle adminler için) öngörülebilir kılın.
İki yaygın desen:
Pratik bir hybrid: JWT kimlik + tenant + roller içerir; ürünler detaylı izinler için bir endpoint’e çağrı yapar.
Arka plan işlerinde kullanıcı tokenlerini yeniden kullanmayın. Servis hesapları için açık kapsamlar verin, client‑credential tokenleri oluşturun ve bunları insan eylemlerinden ayrı tutun ki denetim günlükleri karışmasın.
İzin uygulaması ancak her ürün aynı soruyu sorup tutarlı cevap alabildiğinde işe yarar. Amaç, her ürünün bir kez entegre edip portföy büyüdükçe yeniden kullanabileceği küçük ve stabil API setini tanımlamaktır.
Her ürünün ihtiyaç duyduğu temel operasyonlara odaklanın:
Bu endpoint’lere ürün‑özel mantık eklemekten kaçının. Standart bir sözlük kullanın: subject (kullanıcı/servis), action, resource, scope (tenant/org/project) ve context (ileride kullanılabilecek öznitelikler).
Çoğu ekip kombinasyon kullanır:
POST /authz/check çağrısı yapar veya yerel SDK kullanır.Pratik kural: merkezi kontrolü yüksek riskli eylemler için tek kaynak olarak tutun; replikasyon UX amaçlı (menüler, feature flag’ler, “erişiminiz var” rozetleri) için kullanılabilir, küçük staleness kabul edilebilir.
İzinler değiştiğinde, her ürünün poll yapmasını beklemeyin.
role.granted, role.revoked, membership.changed, policy.updated gibi olaylar yayınlayın. Ürünler abone olup yerel cache/read model’lerini günceller.
Olayları şu şekilde tasarlayın:
Erişim kontrolleri hızlı olmalı; ancak zayıf invalidasyon güvenlik açıklarına yol açar.
Yaygın desen:
JWT içindeki rollerle gidiyorsanız token ömrünü kısa tutun ve iptalin hızlı yayılması için sunucu tarafı iptal mekanizmaları (veya “token version” claim’i) kullanın.
İzinler ürünler yeni özellik ekledikçe evrilir. Buna hazırlıklı olun:
/v1/authz/check) ve olay şemalarını versiyonlayın.Uyumluluğa küçük bir yatırım, izin sisteminin yeni özelliklerin önünde bir darboğaz olmasını engeller.
Teknik olarak doğru bir izin sistemi, yöneticiler “Kimin neye, neden erişimi var?” sorusunu güvenle yanıtlayamazsa başarısız olur. UX, belirsizliği azaltmalı, yanlışlıkla aşırı yetki verilmesini önlemeli ve sık yapılan işleri hızlı hale getirmelidir.
Günlük operasyonların %80’ini kapsayan küçük bir sayfa setiyle başlayın:
Her rolün yanında düz‑dil açıklama verin: “Bu rol ne yapar” ve somut örnekler (“$10k’ye kadar faturayı onaylayabilir”)—bu, “invoice:write” gibi belirsiz etiketlerden daha iyidir. Gerekirse daha derin dokümanlara bağlayın: /help/roles.
Toplu araçlar zaman kazandırır ama hataları büyütür; bu yüzden güvenli tasarlayın:
“Dry run”, rate limitler ve bir import ters giderse geri alma talimatları gibi korumaları ekleyin.
Birçok kuruluş hafif bir süreç ister:
İstek → Onay → Provisyon → Bildirim
İstekler iş bağlamını yakalamalı (“Q4 kapanışı için gerekli”) ve süre bilgisi içermeli. Onaylar rol‑ve‑ürün bazlı olmalı (doğru onaylayıcı doğru işi denetlemeli). Provisyoning denetim girdisi oluşturmalı ve hem isteyeni hem onaylayıcıyı bilgilendirmeli.
Tutarlı adlandırma kullanın, UI’da kısaltmalardan kaçının ve satır içi uyarılar ekleyin (“Bu, müşteri PII’sine erişim verir”). Klavye navigasyonu, yeterli kontrast ve temiz boş durumlar sağlayın (“Henüz rol atanmamış—erişim vermek için bir rol ekleyin”).
Denetim, “erişim doğru görünüyor” ile “kanıt gösterebiliyoruz” arasındaki farktır. Uygulamanız izinleri yönetiyorsa, her değişiklik izlenebilir olmalı—özellikle rol atamaları, politika düzenlemeleri ve yönetici eylemleri.
En azından kim neyi, ne zaman, nereden ve neden değiştirdiğini kaydedin:
Denetim olaylarını append‑only olarak yönetin. Uygulama koduyla güncelleme veya silmeye izin vermeyin; düzeltme gerekiyorsa telafi edici bir olay yazın.
Saklama politikasını risk ve düzenlemeye göre belirleyin: çoğu ekip “hot” aranan logları 30–90 gün, arşivleri 1–7 yıl tutar. İhracı kolaylaştırın: zamanlı teslim (ör. günlük) ve SIEM’e akış seçenekleri sunun. En azından newline‑delimited JSON desteği ve tutarlı ID’ler sağlayın.
Basit dedektörler oluşturun ve şu durumları işaretleyin:
Bunları “Yönetici etkinliği” görünümünde öne çıkarın ve istenirse uyarılar gönderin.
Pratik ve dışa aktarılabilir raporlar sağlayın:
Onay iş akışları eklerseniz, denetim olaylarını istek ID’siyle ilişkilendirin ki uyumluluk incelemeleri hızlı olsun.
Bir izin yönetimi uygulaması kendisi yüksek değerli bir hedeftir: tek bir kötü karar tüm ürünlerde geniş erişim verebilir. Yönetici yüzeyi ve yetkilendirme kontrollerini "tier‑0" sistemleri gibi ele alın.
En az ayrıcalık ile başlayın ve yükselmeyi zorlaştırın:
Yaygın hata modu: bir “role editor” admin rolünü düzenleyip sonra kendine atayabilir.
Admin API’leri son‑kullanıcı API’leri kadar erişilebilir olmamalı:
Yaygın hata modu: üretime bir kolaylık endpoint’i (örn. “tümünü destek için ata”) guardrails olmadan gönderildi.
HttpOnly, Secure, SameSite, kısa oturum süreleri ve CSRF koruması.Yaygın hata modu: politika yazma yetkisi veren servis kimlik bilgilerinin sızması.
Yetkilendirme hataları genellikle “reddetmeyi unutan” senaryolardır:
Bir izin sistemi lansmanda "tamam" olmaz—güveni güvenli bir yayılma ile kazanırsınız. Amaç, erişim kararlarının doğru olduğunu kanıtlamak, destek ekiplerinin hızlı çözüm üretebilmesini sağlamak ve değişiklikleri geri almayı kolay kılmaktır.
Rolü ve aktif kullanıcıları net bir ürünle başlayın. Mevcut roller/grupları yeni sistemdeki kanonik rollere eşleyin, sonra ürünü bugün uyguladığı şekilde çevirecek bir adapter inşa edin (API scope’ları, feature flag’ler, DB flag’leri vb.).
Pilot sırasında tam döngüyü doğrulayın:
Başarı metriklerini önceden tanımlayın: erişimle ilgili destek taleplerinde azalma, kritik aşırı ayrıcalık olaylarının olmaması ve iptal süresinin dakikalar içinde ölçülebilir olması.
Legacy izinleri karmaşıktır. Mevcut grupları, ad‑hoc istisnaları ve ürün‑spesifik rolleri yeni modele çeviren bir adım planlayın. Her göç edilen atamayı açıklayabilmek için eşleme tablosu tutun.
Staging’de dry run yapın, sonra dalga dalga (organizasyon, bölge veya müşteri kademesi) göç edin. Zor müşteriler için göç yapın ama “shadow mode” açık kalarak eski ve yeni kararları karşılaştırın.
Feature flag ile “yazma yolu”nu enforcement’dan ayırın. Tipik aşamalar:
Bir sorun çıkarsa enforcement’ı kapatıp denetim görünürlüğünü koruyabilirsiniz.
Sık olaylar için runbook’lar hazırlayın: kullanıcı ürünlere erişemiyor, kullanıcı fazla erişime sahip, yönetici hata yaptı, acil iptal. Kim nöbette, log’larda nerelere bakılmalı, etkin izinler nasıl doğrulanır ve hızla yayılan “break‑glass” iptali nasıl yapılır gibi adımlar olsun.
Pilot stabil olunca aynı playbook’u ürün‑ürün uygulayın. Her yeni entegrasyon entegrasyon işi gibi hissetmeli—izin modelinizin yeniden icadı değil.
Mükemmel bir izin yönetimi uygulaması için egzotik teknolojiye gerek yok. Doğruluk, öngörülebilirlik ve işletilebilirliğe öncelik verin—sonra optimize edin.
Yaygın bir temel:
Yetki karar mantığını tek bir servis/kütüphanede tutun ki ürünler davranışta ayrışmasın.
Eğer pilotu hızlıca ayağa kaldırmak istiyorsanız, Koder.ai gibi platformlar chat‑odaklı iş akışıyla web uygulamasını hızla prototiplemenize yardımcı olabilir. Bu, React tabanlı admin UI, Go + PostgreSQL backend ve denetim/log/onsay workflow’larının iskeletini hızla oluşturabilir—yetkilendirme mantığını dikkatle gözden geçirmeniz gerekir.
İzin sistemleri hızla kuyruğa koyulması gereken işler üretir:
İşleri idempotent ve retry‑edilebilir yapın; destek için tenant bazlı iş durumu saklayın.
En azından şunları instrument edin:
deny‑by‑error (örn. DB timeouts) spike’larına ve permission check için p95/p99 gecikmesine alarm kurun.
Yayılmadan önce permission‑check endpointi gerçekçi patternlerle load test edin:
Throughput, p95 gecikme ve Redis hit oranını izleyin; cache soğukken performansın kademeli olarak düşmesini sağlayın.
Çekirdek model çalışınca, birkaç “kurumsal” özellik sistemi ölçeklemek ve işletmeyi kolaylaştırmak için fark yaratır—bu ürünlerin uygulama şeklini değiştirmez.
SSO genellikle SAML 2.0 (eski kurumsal IdP’ler) veya OpenID Connect (OIDC) ile gelir. Karar: IdP’den neyi güvenilir şekilde kabul edeceksiniz?
Pratik bir desen: IdP’den kimlik ve yüksek‑seviyede grup üyeliğini kabul edin; sonra bu grupları tenant bazlı rol şablonlarına eşleyin (örn. IdP grubu Acme-App-Admins tenant acme için Workspace Admin rolüne eşlensin). Bu eşlemeyi tenant yöneticilerinin düzenleyebilmesini sağlayın; sert kodlamayın.
IdP gruplarını doğrudan izin olarak kullanmaktan kaçının. Gruplar organizasyonel nedenlerle değişir; uygulamanızın rolleri sabit kalmalı.
SCIM müşterilerin hesap yaşam döngüsünü otomatikleştirir: kullanıcı oluşturma, devre dışı bırakma ve grup senkronizasyonu. Bu manuel davetleri azaltır ve ayrılma durumlarında güvenlik açıklarını kapatır.
Uygulama ipuçları:
Çok‑tenant erişim kontrolü her yerde tenant izolasyonu sağlamalı: tokenlerde kimlikler, veritabanı satır seviyesinde filtreler, cache anahtarları ve denetim logları.
Temiz yönetici sınırları tanımlayın: tenant yöneticileri yalnızca kendi tenant’ları içinde kullanıcı ve rol yönetebilir; platform yöneticileri ise varsayılan olarak ürün erişimi vermeden troubleshoot edebilsin.
Daha derin uygulama rehberleri ve paketleme seçenekleri için referansınız: /blog. Özelliklerin hangi plana ait olduğunu kararlaştırırken /pricing ile hizalayın.
Başlangıç için entegre edeceğiniz 1–3 ürünü listeleyerek ve her bir ürün için şunları belgeleyerek başlayın:
Modeler çok farklıysa, hemen tek bir modele zorlamak yerine bir çeviri katmanı planlayın.
Kararı, politika değerlendirmelerinin nerede yapılmasını istediğinize göre verin:
Birden çok ürün ve sık değişim bekliyorsanız, genellikle hibrit varsayılan olarak en güvenli yoldur.
Başlangıç için pratik bir temel RBAC modeliyle başlayın ve şu varlıkları açıkça modelleyin:
billing.manage)Daha sonra şu şekilde saklayın: — böylece “kim nerede neye sahip” sorusunu rahatça yanıtlayabilirsiniz.
RBAC'i insanın anladığı arayüz olarak tutun ve sadece RBAC'in ifade edemeyeceği kısıtlamalar için ABAC ekleyin.
ABAC şunlar için uygundur:
Özellikleri sınırlı tutun (ör. region, environment, data classification) ve belgelerini iyi tutun; roller hâlâ erişim atamanın ana yolu olmalı.
Tek bir mega-rol yerine katmanlı yaklaşımlar kullanın:
Bu, yöneticilerin iş yükünü azaltır ama ürünler arasındaki önemli farkları gizlemez.
İki ortak desen vardır:
Pratik bir hibrit: JWT kimlik + tenant + roller içerir; yüksek riskli veya ince taneli işlemler için ürünler yetki kontrol endpoint’ine (introspection) çağrı yapar. Token sürelerini kısa tutun ve acil iptaller için bir strateji belirleyin.
Her ürünün uygulaması gereken küçük, kararlı bir çekirdek tutun:
POST /authz/check (hot path)Kelimeleri standartlaştırın: , , , (tenant/org/workspace) ve opsiyonel . Çekirdek endpoint’lerde ürün‑özel mantıklardan kaçının.
Ürünlerin sürekli poll yapmasını önlemek için olay tabanlı senaryo kullanın. Yayınlanacak tipik olaylar:
role.granted / role.revokedmembership.changedpolicy.updatedOlaylar , mümkünse ve ya (a) yerel durumu güncelleyecek kadar açıklayıcı ya da (b) uzlaşma için kullanılabilecek bir “fetch current state” endpoint’i ile birlikte olmalıdır.
Yanlış yetki vermeyi azaltacak ekranlar ve korumalar ekleyin:
Roller için düz‑konuşma açıklamalar ve hassas erişimler (PII, faturalama) için uyarılar ekleyin.
Her hassas değişikliği append‑only olay olarak kaydedin; denetim kaydı “kim, neyi, ne zaman, nereden ve neden” sorularını yanıtlayabilmeli.
En azından şunları yakalayın:
Arşivleme, SIEM'e aktarma (newline-delimited JSON) ve stabil ID'lerle de-dup destekleyin.