Kimlik, SSO ve Yetkilendirme

Knowentra'da kimlik yönetimi yalnızca kullanıcının oturum açmasını sağlamaz. Kullanıcının hangi organizasyona ait olduğunu, hangi departman ve Space'lerde çalışabildiğini, hangi bilgi kaynaklarını arayabildiğini ve agent'ların hangi araçları onun adına çalıştırabildiğini belirleyen güven zincirinin başlangıcıdır.

Bu rehber dört ayrı sorumluluğu birlikte ele alır:

• Kimlik doğrulama: Kullanıcı kim?
• Provisioning: Hesap ne zaman oluşturulur, güncellenir ve kapatılır?
• Yetkilendirme: Kim, hangi kaynak üzerinde hangi işlemi yapabilir?
• Delegasyon: Bir agent veya workflow kullanıcı adına hangi etkiyi oluşturabilir?

Kimlik ve yetki zinciri

Kurumsal IdP
    ↓ kimlik doğrulama + MFA
Knowentra kullanıcı hesabı
    ↓ organizasyon üyeliği
Departman üyeliği
    ↓
Space üyeliği
    ├── Bilgi kaynakları
    ├── Agent sürümü
    ├── Workflow
    └── Araç / MCP → işlem izni → credential kapsamı

Her adım bir öncekinin bağlamını daraltır. Bir kullanıcının başarıyla oturum açması, organizasyon verisine erişebileceği anlamına gelmez. Bir Space'e üye olması da o Space'teki her yazma etkili aracı kullanabileceği anlamına gelmez.

Üç rol alanını birbirinden ayırın

Knowentra'da aynı “admin” sözcüğü farklı güven sınırlarında kullanılabilir:

Platform yöneticisi, normal iş kullanımı için günlük bir organizasyon yöneticisi hesabı olarak kullanılmamalıdır. En yüksek ayrıcalıklı rolü az sayıda, kişiye özel ve güçlü MFA ile korunan hesapla sınırlandırın.

Organizasyon → Departman → Space modeli

Organizasyon

Kurumsal tenant ve temel yönetişim sınırıdır. Kullanıcının organizasyon kimliği istemciden gelen bir alanla belirlenmemeli; sunucudaki üyelik kaydından türetilmelidir.

Organizasyon seviyesinde tipik olarak şunlar yönetilir:

• Kullanıcı ve yönetici üyelikleri
• İzin verilen kimlik sağlayıcıları
• Temel model ve veri güvenliği politikaları
• Departman oluşturma yetkisi
• Kurumsal araç/connector kataloğu

Departman

İş birimi ve veri sahipliği sınırıdır. Departman yöneticisi kendi departmanındaki üyeleri, bilgi tabanlarını ve izin verilen yetenekleri yönetebilir. Organizasyon yöneticisi alt departmanlarda yönetim yetkisini devralabilir.

Bir kullanıcı Space'e eklenmeden önce ilgili departmanın üyesi olmalıdır. Kullanıcı departmandan çıkarıldığında alt Space üyelikleri ve türetilmiş workflow erişimleri de kaldırılmalıdır.

Space

Günlük çalışma ve en dar bağlam sınırıdır. Chat, bilgi, agent ve workflow birlikte bu bağlamda çalışır. Bir Space özel veya organizasyon içinde keşfedilebilir olabilir; keşfedilebilirlik üyelik veya içerik erişimi değildir.

Space yöneticisi, bağlı olduğu departmanın izin verdiği katalogdan seçim yapar. Üst seviyede izin verilmeyen bir model, araç veya MCP'yi Space seviyesinde etkinleştiremez.

SSO yöntemini seçmek

OIDC / OAuth tabanlı SSO

Modern kurumsal kurulumlar için genellikle tercih edilen yöntemdir. Knowentra, sürüme bağlı olarak genel OpenID Connect discovery endpoint'i ve belirli OAuth sağlayıcılarıyla çalışabilir.

OIDC yapılandırmasında en az şu değerleri belirleyin:

OIDC güvenlik kontrolleri

• Authorization Code flow kullanın; mümkünse PKCE etkinleştirin.
• state, nonce, issuer, audience ve imza doğrulamasını zorunlu tutun.
• Redirect URI'yi wildcard olmadan tam adresle kaydedin.
• Client secret'ı repository veya istemci koduna koymayın.
• JWKS anahtar yenileme ve IdP kesintisi davranışını test edin.
• Yalnız kurumsal tenant/issuer'ı kabul edin.
• Hesap oluşturmayı varsayılan açık bırakmak yerine kontrollü provisioning kullanın.
• IdP logout ile Knowentra oturum iptalinin aynı şey olup olmadığını test edin.

LDAP

LDAP, özellikle kapalı ağ ve mevcut dizin altyapısında kullanılabilir. LDAP oturum açmayı sağlayabilir; hesap yaşam döngüsü ve gerçek zamanlı devre dışı bırakma için ayrıca bir süreç gerekebilir.

Üretimde:

• LDAPS veya StartTLS kullanın.
• Sertifika doğrulamayı kapatmayın; kurum CA zincirini sağlayın.
• Bind hesabını salt-okunur ve dar arama kapsamıyla sınırlandırın.
• Search base'i yalnız ilgili kullanıcı OU'larına daraltın.
• Kullanıcı girdisini LDAP filtresine ham biçimde eklemeyin.
• E-posta, kullanıcı adı ve grup attribute mapping'ini örnek hesaplarla test edin.
• Bind parolasını merkezi secret yönetiminde tutun ve döndürün.
• Dizin kesildiğinde mevcut oturum ve yeni oturum davranışını belirleyin.

SCIM

SCIM, oturum açma protokolü değil kullanıcı yaşam döngüsü protokolüdür. SSO ile birlikte kullanıldığında hesaplar kullanıcı ilk kez giriş yapmadan önce oluşturulabilir ve ayrılan çalışanların erişimi merkezi olarak kapatılabilir.

SCIM entegrasyonu şu olayları idempotent biçimde ele almalıdır:

• Kullanıcı oluşturma
• Ad, e-posta veya profil güncelleme
• Kullanıcıyı pasifleştirme
• Grup üyeliği ekleme ve kaldırma
• Aynı isteğin tekrar gönderilmesi
• Bilinmeyen veya daha önce silinmiş kaynağa güncelleme

SCIM bearer token'ını yüksek ayrıcalıklı bir secret olarak yönetin. Kaynak IP kısıtı, TLS, rotasyon ve audit uygulayın. Pasifleştirme sonrasında mevcut Knowentra oturumlarını da iptal edin; yalnız yeni girişleri engellemek yeterli değildir.

Trusted header / kimlik proxy'si

Bir reverse proxy, access gateway veya kurumsal kimlik katmanı doğrulanmış kullanıcı bilgisini header ile aktarabilir. Bu modelde Knowentra header'a değil, header'ı üreten ve ağ seviyesinde tek güvenilir kaynak olan proxy'ye güvenir.

• Knowentra'ya doğrudan erişimi tamamen kapatın.
• Dış istemciden gelen kimlik header'larını proxy'de silip yeniden üretin.
• Proxy ile Knowentra arasında mTLS veya izole ağ kullanın.
• E-posta, ad, grup ve rol header isimlerini sabitleyin.
• Boş, çoğul veya beklenmeyen header davranışını test edin.
• Proxy bypass edilirse isteğin anonim veya yönetici kabul edilmediğini doğrulayın.

SAML kullanan kurumlar

Kurulu Knowentra sürümünüz doğrudan SAML özelliği sunmuyorsa SAML'i destekleyen kurumsal IdP veya kimlik proxy'si, Knowentra'ya OIDC ya da doğrulanmış header üzerinden kimlik aktarabilir. Bu köprünün oturum kapatma, claim mapping ve MFA bağlamını kaybetmediğini doğrulayın; desteklenmeyen bir protokolü doğrudan varmış gibi yapılandırmayın.

Provisioning stratejisi

Kritik kurulumlarda önerilen desen, SSO + SCIM veya kontrollü davettir. JIT kullanılacaksa:

• Yalnız onaylı tenant ve domain'i kabul edin.
• İlk rolü en düşük yetki olan kullanıcı olarak atayın.
• İlk girişte otomatik organizasyon yöneticisi vermeyin.
• Grup claim'ini doğrudan ayrıcalıklı role çevirmeden önce allowlist uygulayın.
• Yeni hesap oluşumunu ve mapping hatalarını alarm/audit kapsamına alın.

Claim ve grup eşleme

Kimlik sağlayıcı grubu ile Knowentra rolünü birebir aynı kavram kabul etmeyin. Önce açık bir mapping tablosu oluşturun:

Mapping yaparken:

• Grup adından çok değişmeyen grup kimliğini tercih edin.
• İç içe grup davranışını açıkça belirleyin.
• Birden fazla mapping çakıştığında sonucu tanımlayın.
• Claim boyutu sınırını ve çok üyeli kullanıcıları test edin.
• IdP grubundan çıkışın Knowentra üyeliğini ne zaman kaldırdığını ölçün.
• Yerel manuel değişiklik ile IdP yönetiminin hangisinin kaynak-of-truth olduğunu belirleyin.

Yetkilendirme nasıl değerlendirilir?

Bir istek için karar yalnız route seviyesinde verilmemelidir. Kaynak ve işlem birlikte kontrol edilir:

Kimlik doğrulandı mı?
  → Hesap aktif mi?
  → Organizasyon üyeliği aktif mi?
  → Departman/Space üyeliği var mı?
  → İstenen kaynak bu kapsama mı ait?
  → Rol bu işleme izin veriyor mu?
  → Agent sürümü bu bilgi/aracı içeriyor mu?
  → Araç işlemi ve credential kapsamı izinli mi?
  → Ek onay gerekiyor mu?

İstemcinin gönderdiği org_id, department_id, space_id, role veya user_id tek başına güvenilir değildir. Sunucu üst kaynaktan bağlamı türetmeli ve her ilişkide üyeliği doğrulamalıdır.

Okuma ve yönetim yetkisini ayırın

Bir kullanıcının bir Space'i görebilmesi şu yetkileri otomatik vermez:

• Üye eklemek veya rol değiştirmek
• Bilgi kaynağı bağlamak
• Agent yayınlamak
• Credential görmek veya değiştirmek
• Yazma etkili workflow çalıştırmak
• Audit kayıtlarını dışa aktarmak

Roller yalnız ekran görünürlüğünü değil sunucu endpoint'lerini ve arka plan işlerini de korumalıdır.

Agent adına yetki

Agent ayrı bir sınırsız kullanıcı değildir. Gerçek kullanıcı bağlamında ve yayınlanan agent sürümünün izinleriyle çalışır:

Etkili izin =
  kullanıcı izni
  ∩ Space'in izin verdiği kaynaklar
  ∩ agent sürümüne atanmış araçlar
  ∩ araç işleminin kapsamı
  ∩ credential'ın dış sistem yetkisi

Bu kesişimlerden biri izin vermiyorsa çağrı reddedilir. Modelin araç çağırmayı önermesi yetki kanıtı değildir.

Yazma etkili araçlarda kullanıcı yetkisine ek olarak şu kontrolleri değerlendirin:

• İnsan onayı
• İşlem başına maksimum etki
• Idempotency anahtarı
• Zaman ve ağ kısıtı
• Hedef kayıt/hesap kapsamı
• Ayrı audit olayı

Workflow ve servis kimlikleri

Uzun süren workflow, kullanıcı oturumu sona erdikten sonra devam edebilir. Bu nedenle üç kimliği kaydedin:

• Başlatan: Workflow'u tetikleyen kullanıcı veya olay
• Çalıştıran servis: Adımları teknik olarak yürüten servis kimliği
• Onaylayan: Riskli adımın devamına karar veren kişi

Servisler arası çağrılarda tarayıcı cookie'si veya ortak statik admin anahtarı kullanmayın. Kısa ömürlü, belirli audience'a sahip imzalı token veya ayrı servis credential'ı kullanın. Token en az issuer, subject, audience, expiry, kapsam ve correlation kimliği taşımalıdır.

Bir kullanıcının üyeliği workflow beklerken kaldırılırsa resume anında yetki yeniden değerlendirilmelidir. Eski snapshot'taki izin, kalıcı yetki değildir.

Oturum güvenliği

• Cookie'leri Secure, HttpOnly ve uygun SameSite değeriyle koruyun.
• Oturum kimliğini URL veya log içine koymayın.
• Yönetici ve normal kullanıcı için uygun idle ve absolute timeout belirleyin.
• Parola/MFA değişimi, işten ayrılma ve riskli olayda oturumları iptal edin.
• Logout'un yalnız tarayıcı cookie'sini değil sunucu oturumunu da sonlandırdığını doğrulayın.
• Back-channel logout kullanılıyorsa IdP olayını ilgili oturumlara bağlayın.
• Session store çoklu instance'larda tutarlı olmalıdır.
• CSRF korumasını state-changing işlemlerde test edin.

Break-glass erişimi

Kimlik sağlayıcı kesintisinde kullanılacak acil hesap:

• Günlük kullanım hesabı olmamalı.
• Kişiye özel veya çift kontrolle erişilen biçimde saklanmalı.
• Uzun ve benzersiz credential + mümkünse bağımsız MFA kullanmalı.
• Normal ağlardan kısıtlanmalı.
• Her kullanımda kritik alarm üretmeli.
• Üç aylık veya kurum politikasına uygun aralıkla test edilmeli.
• Kullanımdan sonra credential'ı döndürülmeli ve olay incelemesi yapılmalı.

Break-glass hesabı, tenant veya veri filtrelerini atlayan görünmez bir arka kapı olmamalıdır.

Joiner, mover, leaver

İşe giriş

1. Kimlik sağlayıcı hesabı ve MFA hazır olur.
2. SCIM veya davetle en düşük organizasyon üyeliği verilir.
3. Departman üyeliği veri sahibi onayıyla atanır.
4. Space ve ayrıcalıklı roller ihtiyaç temelinde eklenir.
5. İlk erişim ve policy kabulü audit edilir.

Rol/departman değişikliği

1. Yeni yetkiler onaylanır.
2. Eski departman ve Space üyelikleri aynı değişiklik kapsamında kaldırılır.
3. Agent, workflow workspace ve connector erişimleri yeniden hesaplanır.
4. Bekleyen onay ve sahiplikler yeni kişiye devredilir.
5. Yetki farkı raporu incelenir.

İşten ayrılma

1. IdP hesabı kapatılır ve SCIM active=false gönderir.
2. Tüm Knowentra oturumları ve API anahtarları iptal edilir.
3. Organizasyon, departman ve Space üyelikleri pasifleştirilir.
4. Connector credential sahipliği ve workflow onayları devredilir.
5. Kişisel token, servis credential'ı ve paylaşılmış linkler aranır.
6. Audit kaydı saklama politikasına göre korunur.

Yetki test matrisi

Üretim öncesinde en az aşağıdaki negatif testleri otomatikleştirin:

Audit edilmesi gereken olaylar

• SSO/LDAP giriş başarısı ve başarısızlığı
• Yeni hesap, pasifleştirme ve yeniden etkinleştirme
• Organizasyon, departman ve Space üyelik değişikliği
• Rol yükseltme ve düşürme
• Grup/claim mapping değişikliği
• Break-glass ve platform admin kullanımı
• API anahtarı ve servis credential oluşturma/iptal
• Agent veya workflow yayınlama
• Araç ve credential atama
• İnsan onayı ve dış sistem etkisi

Audit olayında aktör, hedef kullanıcı/kaynak, önceki ve yeni değer, zaman, kaynak IP/istemci, correlation kimliği ve karar sonucu bulunmalıdır. Token, parola ve cookie kaydedilmemelidir.

Devreye alma sırası

1. Staging'de IdP uygulama kaydını ve callback'i kurun.
2. İki normal kullanıcı, bir yönetici ve bir pasif kullanıcıyla test edin.
3. Claim/group mapping'i en düşük yetkiyle doğrulayın.
4. SCIM veya üyelik senkronizasyonunu küçük bir pilot grupla açın.
5. Organizasyon → departman → Space negatif testlerini tamamlayın.
6. Oturum iptali, logout ve IdP kesintisini test edin.
7. Break-glass erişimini ve alarmını doğrulayın.
8. Üretim kaydını ayrı secret ve yalnız üretim callback'iyle oluşturun.
9. Pilot kullanıcıları taşıyın; audit ve mapping hatalarını izleyin.
10. Yerel/parola girişini yalnız onaylı acil erişim kapsamına daraltın.

Üretim kontrol listesi

• Kurumsal issuer/tenant allowlist'i tanımlı.
• Redirect URI'ler tam ve yalnız HTTPS.
• Subject tabanlı kullanıcı eşleme kullanılıyor.
• JIT veya SCIM'in kaynak-of-truth davranışı belgeli.
• Yeni hesap varsayılan en düşük yetkiyle oluşuyor.
• Grup → rol mapping'i sahibiyle birlikte kayıtlı.
• Platform ve organizasyon admin rolleri ayrılmış.
• Departmandan çıkış alt Space/workflow erişimini kaldırıyor.
• Agent/araç izni kullanıcı izninin önüne geçmiyor.
• Pasifleştirme mevcut oturum ve token'ları iptal ediyor.
• Break-glass hesabı test ve alarm kapsamında.
• Çapraz organizasyon ve IDOR negatif testleri geçiyor.
• Kimlik ve yetki değişiklikleri audit ediliyor.
• Kimlik sağlayıcı kesintisi runbook'u hazır.

Sonraki adımlar

• Hiyerarşik kapsam için Organizasyon, Departman ve Space
• Üretim kabulü için Üretim Kurulumu Kontrol Listesi
• Agent sınırları için Agent Oluşturma ve Yayınlama
• Araç yetkisi için Araç Bağlama ve MCP
• Sistem sınırları için Platform Mimarisi