Enterprise RBAC + SSO
SAML 2.0 SSO, SCIM 2.0 hazırlama (provisioning), özel roller, IP izin listesi, veri ikameti kilidi — düzenlemeye tabi alıcılar için organizasyon seviyesi kimlik akışı.
Moonborn'u değerlendiren tedarik (procurement) + güvenlik ekipleri için soru genellikle "kimlik yığınınıza nasıl entegre olursunuz?"
Üç kanonik cevap:
- SAML 2.0 SSO — kullanıcılar IdP (kimlik sağlayıcısı) üzerinden kimlik doğrulanır
- SCIM 2.0 hazırlama — katılan / değişen / ayrılan (joiner / mover / leaver) otomatik
- RBAC matrisi — yerleşik 7 rol + Enterprise özel rol
Bu kullanım senaryosu sana uyar mı?
- Enterprise BT — mevcut IdP (Okta, Azure AD, Google Workspace, OneLogin) yanına Moonborn ekleyecek
- Uyumluluk ekibi — kanıtlanabilir kullanıcı yaşam döngüsü kontrolleri
- Güvenlik ekibi — ağ-bağlı API erişimi (IP izin listesi)
- Veri ikameti — ABD veya AB kilitli kayıt
Ne gönderir
| Yetenek | Plan |
|---|---|
| Yerleşik roller (Owner, Admin, Editor, Viewer, API-only, Billing, Auditor) | Pro |
| SAML 2.0 SSO | Enterprise |
| SCIM 2.0 hazırlama (provisioning) | Enterprise |
| Özel roller | Enterprise |
| IP izin listesi (CIDR) | Enterprise |
| Veri ikameti kilidi (ABD / AB) | Enterprise (kayıtta ayarlanır) |
| Bölgeler arası okuma engelleme | Enterprise |
| Uzun saklama denetim kaydı (7 yıl) | Enterprise |
| 4 göz onayı (yıkıcı eylemler) | Enterprise |
Mimari — ağ geçidi-aracılı kimlik
Her istek bir Bearer token taşır:
- Oturum JWT'si — çerez-bağlı, SAML tarafından çıkarılmış (web uygulaması)
- API anahtarı —
sk_*öneki (programatik)
Token ağ geçidinde (kullanıcı, organizasyon, çalışma alanı) üçlüsüne çözülür. RBAC kullanım senaryosu etki alanına dokunmadan önce uygulanır — derinlemesine savunma (defense in depth).
SCIM için: IdP tarafı değişiklikler Moonborn'un /v1/auth/scim/v2/* uç noktalarına (RFC 7644) vurur. Kullanıcı yaşam döngüsü IdP'inde tek-kaynak kalır; Moonborn alıcıdır.
RBAC rol + izin matrisi (yerleşik)
| Rol | personas | chat | billing | config | webhooks | audit | members |
|---|---|---|---|---|---|---|---|
| Owner | YO | YO | YO | YO | YO | O | YO |
| Admin | YO | YO | YO | YO | YO | O | YO |
| Editor | YO | YO | — | O | O | — | — |
| Viewer | O | O | — | O | O | — | — |
| API-only | yetkili | yetkili | — | yetkili | yetkili | — | — |
| Billing | — | — | YO | — | — | — | — |
| Auditor | — | — | O | O | O | O | O |
O = okuma, Y = yazma, YO = ikisi. yetkili = API anahtarı yetkisine (scope) bağlı.
Özel roller (Enterprise) — matrisi farklı kesmen mümkündür. Örnek: "Brand QA Auditor" = read:personas, read:audit, write:moderation.
Denetim kaydı
Her üyelik değişikliği, rol değişikliği, yapılandırma düzenlemesi, persona mutasyonu değiştirilemez, karma-zincirli denetim kaydına iner:
event_n.hash = sha256(event_n.payload || event_{n-1}.hash)Kurcalamaya karşı duyarlı (tamper-evident): zincirdeki herhangi bir değişiklik onu kırar; yeniden hash'leyerek doğrulanabilir.
| Plan | Saklama süresi |
|---|---|
| Free | 30 gün |
| Pro | 90 gün |
| Team | 1 yıl |
| Enterprise | 7 yıl |
GET /v1/audit/events — kategori, eyleyen (actor), hedef, zaman aralığıyla sayfalanır. POST /v1/audit/export (Team ve üzeri) — imzalı arşiv (kendi sisteminde tutmak için). Detay: Denetim kaydı dışa aktarımı.
Veri ikameti
Organizasyon kaydında ABD veya AB seçilir → tüm kalıcı veri (persona, sohbet transkripti, denetim kaydı, vektörler) o bölgede kalır. Bölgeler arası okumalar veritabanı sınırında engellenir — politika kontrolü değil, fiziksel izolasyondur.
SAML SSO kurulum özeti
1. IdP'de Moonborn SAML uygulaması oluştur (Okta / Azure / Google)
2. Moonborn üstveri XML'ini içe aktar
3. Öznitelik eşlemesi: e-posta, ad, soyad, rol
4. SP-başlatmalı + IdP-başlatmalı akışı test et
5. Parola ile giriş kilidi (parola yedeği devre dışı)Detay: SSO SAML kurulumu.
SCIM hazırlama
1. SCIM uç nokta URL'ini Moonborn'dan al
2. SCIM Bearer token oluştur
3. IdP tarafı SCIM bağlayıcısını yapılandır (Okta / Azure / Google)
4. Grup → Moonborn rol eşlemesi
5. Test: kullanıcı oluştur / güncelle / devre dışı bırakDetay: SCIM hazırlama.
Plan gereksinimi
Enterprise.