Bölüm 9: Kimlik Doğrulama ve Kullanıcı Erişimi

Arceris'te her istek bir kimlik adına değerlendirilir: Model Access kuralları, maliyet limitleri, PII/DLP/Prompt Koruması bağları ve denetim kayıtları bu kimliğe göre karar verir. Bu bölüm, kimliğin hangi yöntemlerle doğrulandığını, kimlik yapılandırmasının hangi panelde yapıldığını ve bir isteğin kimliğinin nasıl çözümlendiğini anlatır.

Kimlik Yönetimi Sayfası

Admin paneldeki Kimlik Yönetimi sayfası, kimlik doğrulama yöntemlerini dört sekmede toplar:

Sekme	Ne işe yarar
LDAP / Active Directory	Kurumsal dizinle giriş ve rol eşleme (Bölüm 10)
Tek Oturum Açma (SSO)	Güvenlik duvarı kimlik ajanıyla (Fortinet FSSO, Palo Alto User-ID) otomatik giriş
Keycloak (OIDC)	Tarayıcı yönlendirmeli tek oturum açma (OpenID Connect)
Kerberos / SPNEGO	Domaine katılmış uç noktalar için sıfır dokunuşlu kayıt

LDAP/AD entegrasyonunun ayrıntıları Bölüm 10'dadır; bu bölüm kalan üç yöntemi ve kimlik modelinin tamamını ele alır. Kayıtlı cihazların kimlik taşıması (Kayıtlı Cihazla Otomatik Giriş) ve kullanıcı paneli oturumları aşağıdaki bölümlerde ayrıca anlatılır.

Yerel Kullanıcı Modeli

Arceris, doğrudan ürün içinde yönetilen yerel kullanıcıları destekler. Bu model özellikle harici dizin entegrasyonu olmayan, küçük başlayan veya belirli özel yönetici hesaplarını ayrı tutmak isteyen kurumlar için kullanışlıdır.

Yerel kullanıcılar operasyonel açıdan basitlik sağlar; ancak kurumsal ölçekte kimlik merkeziyle uyum gereksinimi arttıkça LDAP veya benzeri yöntemlerle birlikte değerlendirilmelidir. Kullanıcı hesapları user, admin ve auditor rollerini alabilir; LDAP, OIDC ve Kerberos yoluyla açılan hesaplar da aynı yerel hesap modeline yazılır — ilk girişte hesap açma ve varsayılan rol, bu yöntemlerin kendi sekmelerinden ayarlanır.

Admin Girişi ve Kullanıcı Girişi

Admin girişi ile standart kullanıcı girişi aynı şey değildir. Yönetim yetkisi gerektiren yüzeyler, ayrı kontrol mantığıyla korunur ve rol doğrulaması bu ayrımın önemli parçasıdır.

• Admin girişi: https://<ARCERIS_HOST>:8443/login adresinden yapılır. İlk kurulumda tanımlanan admin API anahtarı ile erişilir.
• Standart kullanıcı girişi: https://<ARCERIS_HOST>:8443/user/login adresinden yapılır. Son kullanıcılar bu sayfa üzerinden kimlik doğrulaması yaparak Arceris'in kullanıcı yüzeyine erişir.

Admin düzlemi yalnız parolayla girilir: kimlik ajanı SSO ve OIDC oturumları admin API'sine hiçbir koşulda erişemez. Bu kural panelde bir anahtar olarak sunulmaz; sunucu tarafında zorunlu kılınır. Kullanıcı paneli oturumlarının yönetimi ve oturum iptali Bölüm 12'de ele alınır.

Break-Glass Erişim Mantığı

Break-glass modeli, olağan yönetici erişimi sağlanamadığında kullanılabilecek kontrollü bir istisna mekanizmasıdır. Bu yapı günlük kullanım için değil, acil durum ve geri kazanım senaryoları için düşünülmelidir.

Kurumsal açıdan bu mekanizmanın kullanımı sınırlı, kayıtlı ve prosedüre bağlı olmalıdır. Break-glass anahtarıyla yapılan işlemler denetim kayıtlarında actor break-glass olarak görünür (Bölüm 25).

Kimlik Ajanı ile Tek Oturum Açma (SSO)

Tek Oturum Açma (SSO) sekmesi, güvenlik duvarı tabanlı kimlik ajanlarını yapılandırır: Fortinet FSSO (FortiGate REST API üzerinden) veya Palo Alto Networks User-ID (PAN-OS XML API üzerinden). Aynı anda tek ajan etkin olabilir.

Bu yöntem OIDC/SAML değildir: kullanıcı Windows oturum açarken zaten doğrulanmıştır. Güvenlik duvarı, hangi IP adresinde hangi domain kullanıcısının oturum açtığını izlediği için bilir; Arceris ona "bu adreste kim var?" diye sorar ve tanıdığı adresi hiçbir şey sormadan içeri alır. Arceris, IP–kullanıcı tablosunu üreticinin belgelenmiş yönetim API'si üzerinden yalnızca okur; güvenlik duvarında değişiklik yapmaz.

Paneldeki temel ayarlar:

• Bağlantı: ajan seçimi ve erişim bilgileri (FortiGate URL, REST API token, VDOM; PAN-OS URL, XML API anahtarı, vsys).
• Otomatik giriş yap: ajan adresi tanıdığında Bağlantı Portalı'nda (captive portal) giriş sayfası hiç gösterilmez. Kapatılırsa kullanıcı "SSO ile Giriş Yap" düğmesine basmak zorunda kalır.
• Nerede geçerli: Bağlantı Portalı ve Kullanıcı Paneli Girişi yüzeyleri ayrı ayrı açılıp kapatılabilir.
• Domain önekini kaldır: ACME\jdoe ve [email protected] değerlerini Arceris/LDAP hesabı jdoe ile eşler.
• Bir Adresi Test Et: gerçek bir istemci makinenin adresiyle ajanın kimi gördüğünü sorgular — yapılandırma hatasını, ajanın tanımadığı bir cihazdan ayırmanın en hızlı yoludur.

Kullanıcı adı/parola ile giriş her zaman yedek yol olarak açık kalır. Palo Alto User-ID kullanıcı adını verir ama kullanıcının gruplarını vermez; grup bazlı hedefleme için LDAP ayarlarının yapılmış olması gerekir (Bölüm 10).

Keycloak (OIDC) ile Tek Oturum Açma

Keycloak (OIDC) sekmesi, OpenID Connect Authorization Code + PKCE akışıyla tarayıcı yönlendirmeli tek oturum açmayı yapılandırır: kullanıcı kimlik sağlayıcıya yönlendirilir, orada kimliğini doğrular (parola + MFA) ve geri döner; Arceris imzalı id_token değerini doğrulayıp oturumu açar.

Bağlantı tarafında Issuer URL (realm), Client ID ve Client Secret girilir (public client kullanılıyorsa secret boş bırakılır; PKCE her durumda uygulanır). Arceris, {issuer}/.well-known/openid-configuration adresini okur; verilen Arceris Genel URL Adresi'nden üretilen redirect URI'nin IdP client'ına kaydedilmesi gerekir. Scope listesine, grup claim değerini taşıyan scope eklenmelidir (Keycloak için çoğunlukla groups). Discovery Testi düğmesi bağlantıyı doğrular.

Claim Eşlemesi bölümünde kullanıcı adı, e-posta, grup/rol ve görünen ad alanları noktalı yollarla belirtilir (ör. Keycloak realm rolleri realm_access.roles). Grup claim içindeki değerler kullanıcının Arceris grupları olur; Access Management'taki grup hedefleri bu değerlerle eşleşir (Bölüm 11).

Kimler Giriş Yapabilir sorusu üç politikadan biriyle yanıtlanır:

• Açık: kimlik sağlayıcının doğruladığı herkes girer; kapı IdP'dir, kısıtlama client atamasıyla yapılır.
• İzinli gruplar: kullanıcının listelenen claim değerlerinden en az birine sahip olması gerekir.
• Access Management: LDAP girişiyle aynı kapı — kullanıcının bir Access Management ataması ya da içe aktarılmış bir grup hedefiyle eşleşen bir grup değeri olmalıdır.

Rol eşlemeleri bir grup/rol claim değerini Arceris rolüne bağlar; hiçbir eşleme tutmazsa Varsayılan Rol atanır. OIDC yalnızca Kullanıcı Paneli Girişi ve Bağlantı Portalı yüzeylerinde etkinleştirilebilir; admin paneli OIDC'yi asla kabul etmez. Kimlik sağlayıcıya ulaşılamazsa giriş sayfaları yerel, LDAP ve kimlik ajanı SSO ile çalışmaya devam eder — OIDC parola formunu asla engellemez.

Kerberos / SPNEGO Enrollment

Kerberos / SPNEGO sekmesi, domaine katılmış uç noktaların parola, tarayıcı ve onay ekranı olmadan sessizce kaydolmasını sağlar: uç nokta, kullanıcının Windows girişinde elinde tuttuğu Kerberos biletini SPNEGO üzerinden sunar; Arceris bileti çevrimdışı doğrular.

Panel, Windows üzerinde ktpass ile keytab üretip dosya devri yapılan iş akışının yerini alır: Realm, Servis Principal Adı (SPN), KDC Adresi ve SPN'in eşlendiği servis hesabının sAMAccountName ve parolası girilir. Keytab, KDC'nin yetkili salt değeriyle türetilir ve şifreli olarak saklanır; parola yalnızca keytab üretimi için bir kez kullanılır ve asla saklanmaz. İlk kayıtta otomatik hesap oluştur açıksa hesabı olmayan bir principal için Arceris hesabı açılır; kayıt yine de Model Access ile sınırlıdır.

Kerberos kaydı iki düzlemde çalışır: kullanıcı kaydı (helper, oturum açmış kullanıcının biletiyle sessiz kaydolur) ve makine kaydı (AD bilgisayar hesabıyla; kurulum token'ı alternatifi domain dışı makineler içindir). Kayıt sonrası görünürlük ve yönetim Bölüm 13'te, kurulum adımları Bölüm 24'te anlatılır; grup hedeflemesinin dizin tarafı Bölüm 10'dadır.

Kayıtlı Cihazla Otomatik Giriş

Kayıtlı bir cihazın (arceris-dev helper) Arceris'e açtığı relay bağlantısı, cihazın kullanıcısının kimliğini taşır. Kayıtlı Cihazla Otomatik Giriş ayarı (Settings → Runtime; Runtime ayarlarının tamamı Bölüm 6'da) bu kimliğin çerezsiz isteklerde ne zaman devreye girdiğini belirler ve v1.3.0'dan itibaren varsayılan olarak açıktır.

Ayar açıkken, bu bağlantıda oturum çerezi olmayan (veya çerezi eskiyen) bir istek — tipik olarak tarayıcıda oturum kalmamışken gelen Gemini/ChatGPT arka plan istekleri — anonim IP|tarayıcı kimliği yerine cihazın kullanıcısı olarak değerlendirilir. İstek, cihaz girişinin kendisiyle aynı kapılardan geçer: askıya alınmış kullanıcı, iptal edilmiş cihaz ve giriş kapısı (Access Management ataması zorunluluğu) kontrolleri. Bu tür bağlantılarda kimlik relay belirtecidir; kaynak IP asla kimlik olarak kullanılmaz ve IP oturumu fallback'ine başvurulmaz.

Bu değerlendirmenin sonuçları:

• Model Access kuralları kullanıcı kurallarıyla eşleşir; önceki sürümlerde herkese uygulanan * kurallarını gören istek artık kullanıcıya özel kurallara göre izin de alabilir, engel de.
• Maliyet limiti ön kontrolü çalışır; kullanıcıya atanmış PII, DLP, Kurumsal Veri Denetçisi (LLM Judge) ve Prompt Koruması bağları uygulanır.
• Denetim kayıtlarındaki Actor, maliyet kayıtları ve veri düzlemi etkinliği gerçek kullanıcıyı gösterir.

v1.3.0 davranış değişikliği — önceki sürümlerde bu istekler anonim değerlendiriliyor ve Model Access kuralları ["*"] rolüyle eşleşiyordu. Bu yüzden kurulumların Model Access kurallarını (Bölüm 11) yeni değerlendirme bakımından gözden geçirmesi gerekir. Eski davranış, ayarı Settings → Runtime altından kapatmakla geri getirilebilir; operatörün kapatma kararı hatırlanır.

Kullanıcının kimliği kaybolduğunda (cihaz iptal edildi, kayıt süresi doldu, sessiz kayıt bileti bekliyor ya da reddedildi) o kullanıcının tarayıcısı ve araçları Arceris'e kimliksiz ulaşır ve istekler * kurallarına göre karar verir. Bu durum Makineler sayfasındaki "Kullanıcı kimliği yok" rozeti ve filo alarmıyla izlenir (Bölüm 13). Cihaz girişinin kendisi de iptal edilmiş bir cihazı reddeder (denetim nedeni device_revoked); eskiden uzun ömürlü tünel üzerinden yeni bir oturum açılıyordu.

Bir İsteğin Kimliği Nasıl Çözümlenir?

Arceris bir isteği şu sırayla kimliğe bağlar: oturum çerezi (Bağlantı Portalı veya Kullanıcı Paneli oturumu) → kayıtlı cihazın relay kimliği → sunulan kimlik bilgisi (proxy belirteci, gateway anahtarı) → IP oturumu → anonim. Her denetim satırı isteğin kimlik kaynağını ve doğrulama yöntemini taşır; değer sözlüğü Bölüm 25'tedir. İstek Olayları'nda kimliksiz satırlar ANON rozetiyle gösterilir.

Reddedilen kimlik bilgileri anonim kalır ve denetlenir. v1.3.0 davranış değişikliği — explicit proxy'de sunulan ama reddedilen bir belirteç artık aynı IP'deki captive oturumuyla kurtarılmıyor: istek anonim değerlendirilir ve 407 yanıtı alır. Reddedilen her kimlik bir auth_login_fail satırı yazar (neden: süresi dolmuş / iptal edilmiş / askıda / belirteçte cihaz yok); aynı neden–kullanıcı–IP üçlüsü 10 dakikada bir kez kaydedilir ve belirtecin kendisi asla loglanmaz (Bölüm 25).

Kullanıcı Profil ve Oturum Yapısı

Kullanıcı oturumları, ürünün kimlik doğrulama modelinin temel taşıdır. Oturum bazlı yaklaşım sayesinde kullanıcı ve yönetici işlemleri geçici erişim bağlamı üzerinden yürütülür; bu da daha güvenli ve denetlenebilir bir kullanım modeli sağlar.

Operasyon ekipleri için burada önemli olan nokta, oturum davranışını erişim yetkisi, görünürlük ve kullanıcı deneyimi ile birlikte değerlendirmektir.

Oturumlar 24 saatte sunucu tarafında da sonlanır. v1.3.0 davranış değişikliği — captive parola, kimlik ajanı SSO ve OIDC yoluyla açılan oturumlar artık tarayıcı çereziyle aynı anda, 24. saatte sunucu tarafında kapanıyor; önceden sunucudaki oturum ağ geçidi yeniden başlatılana kadar yaşıyor ve IP oturumu üzerinden kimlik vermeye devam ediyordu. Etkilenen grup dar kapsamlıdır: tarayıcıdan bir kez girip sonra yalnızca çerezsiz istemciler (CLI/SDK) kullanan kullanıcı, aynı IP'deki son captive girişinden en geç 24 saat sonra tarayıcıdan yeniden girmelidir. SSO ve Kayıtlı Cihazla Otomatik Giriş, tarayıcı kullanıldıkça oturumu yenilediğinden kullanıcı fark etmez; arceris-dev ajanlı makineler belirteçle doğrulandığından etkilenmez.

Süre kararları duvar saatiyle verilir: dizüstü makine veya VM askıya alındığında duran dahili saat yüzünden süresi dolmuş bir oturum ya da çerez, uyandırmadan sonra geçerli sayılmaz. Kullanıcı paneli oturumlarının yönetimi ve oturum iptali Bölüm 12'dedir.

İstemci Adresi ve Güvenilen Proxy'ler

Kimlik çözümlemesinde istemci IP'si bir güvenlik girdisidir; Arceris iletilen bir başlığa ancak gönderenin gerçekten güvenilir bir aracı olduğundan eminse bakar.

• Şeffaf proxy (:443): X-Forwarded-For gibi iletilen başlıklar hiçbir koşulda kabul edilmez — bu başlıklar Arceris'in sonlandırdığı TLS'in içinde yazılırlar, yani istemci tarafından yazılırlar. Oturumlar (captive, SSO, cihaz) yuva (socket) adresiyle kaydedilir ve aranır. Bu yüzden :443 önüne yalnız L4 pass-through yük dengeleyici konulmalıdır; L7 proxy oturum kaydını bozar (Bölüm 23).
• Explicit proxy (:3128): iletilen başlık yalnızca zincirdeki üst (parent) proxy'den gelirse okunur. Güven listesi EXPLICIT_PROXY_TRUSTED_CIDRS yapılandırma değişkeniyle verilir; varsayılan boştur, yani yalnız doğrudan bağlanan eş (peer) adres geçerlidir. Yalnızca X-Forwarded-For okunur ve sağdan sola yürünür: güven listesinin kendisinde olmayan en sağdaki adres istemcidir.
• Admin/API dinleyicisi: panel önündeki ters proxy için TRUSTED_PROXY_CIDRS geçerlidir; bu liste proxy kimlik yollarıyla bilinçli olarak paylaşılmaz.

v1.3.0 davranış değişikliği — önceki sürümlerde herhangi bir istemcinin gönderdiği ilk X-Forwarded-For değeri kabul ediliyordu; bir istemci iş arkadaşının adresini iddia edip o adresin captive oturumunu devralabiliyordu.

Proxy Token Kullanımı

Belirli kullanım senaryolarında kullanıcı veya istemci tarafı proxy token mantığı devreye girebilir. Bu yapı, özellikle aracı yüzeyler veya kontrollü istemci akışları için pratik bir erişim modeli sunar.

Bu alan, doğrudan günlük kullanıcı işlemi gibi değil; entegrasyon ve kontrollü istemci kullanımı bağlamında ele alınmalıdır. Explicit proxy'de istemcinin sunduğu belirteç reddedilirse istek anonim değerlendirilir ve 407 döner; reddedilen kimlik denetim günlüğüne yazılır (bkz. Bir İsteğin Kimliği Nasıl Çözümlenir?).

Gateway anahtarlarının dışarı sızması. Google'ın Gemini SDK'ları Arceris gateway anahtarını varsayılan olarak x-goog-api-key başlığıyla gönderir. v1.3.0 davranış değişikliği — önceki sürümlerde bu başlıktaki anahtar Google'a değiştirilmeden iletiliyor; istek "API key not valid" hatasıyla başarısız oluyor ve gateway anahtarı ağ geçidinden dışarı çıkıyordu. Artık bu başlık tanınıyor ve içerdiği anahtar kullanıcının gerçek anahtarıyla değiştiriliyor — hem şeffaf hem explicit proxy'de. Gemini SDK'larıyla kullanılmış gateway anahtarlarının yenilenmesi (rotasyon) önerilir.