Ana içeriğe geç

Bölüm 23: Explicit Proxy ve IDE/Tool Trafiği

Explicit Proxy'ye Genel Bakış

Explicit Proxy (forward proxy), istemcinin bilinçli olarak Arceris'i proxy olarak yapılandırarak trafiğini yönlendirdiği çalışma modudur. Transparent proxy'den farkı, istemcinin proxy kullanımından haberdar olması ve kendi yapılandırmasında bunu açıkça belirtmesidir.

Bu yaklaşım özellikle coding agent'ları (Claude Code, Codex, Cursor), IDE eklentileri (VS Code, JetBrains), CLI istemcileri (curl, httpie), AI SDK'ları ve kurumsal uygulamalar için uygundur. Bu araçlarda proxy ayarı yapmak, ağ altyapısında yönlendirme yapmaktan daha kolay ve daha kontrollüdür.

Explicit proxy üzerinde istek tarafı denetimlerinin tamamı çalışır: Model ACL, prompt injection kontrolü, PII ve DLP taraması, path filter ve dosya (MIME/dosya metadata) kontrolleri. TLS kesme açıkken yanıt tarafı denetimleri (yanıt PII taraması, injection taraması) de devreye girer. IDE/CLI trafiği, oturum tehdidi korelasyonuna kendi ad alanında katılır ve diğer tüm giriş noktalarıyla aynı denetim izi altyapısını kullanır.

Ne Zaman Kullanılmalı?

  • IDE ve editör eklentileri: GitHub Copilot, Continue.dev, Cline gibi araçlar proxy ayarını destekler. Arceris explicit proxy olarak yapılandırılarak bu araçların AI trafiği denetlenebilir.
  • CLI istemcileri: curl, httpie veya özel API istemcileri, --proxy veya HTTPS_PROXY ortam değişkeniyle Arceris'e yönlendirilebilir.
  • AI SDK'ları: OpenAI SDK, Anthropic SDK gibi yazılım geliştirme kitleri çoğu zaman proxy yapılandırmasını destekler.
  • Kurumsal uygulamalar: AI entegrasyonu olan dahili uygulamalar, Arceris'i forward proxy olarak kullanabilir.
  • Geliştirici iş istasyonları: Ağ seviyesinde transparent proxy kurulumunun pratik olmadığı durumlarda, geliştirici makinede explicit proxy yapılandırması daha uygundur.

Yapılandırma

Explicit proxy'nin ayar yüzeyi ikidir: çalışma zamanı ayarları panelde, dinleyici ve başlangıç değerleri kurulum sırasında sunucu tarafında belirlenir.

Settings → Çalışma Zamanı → Proxy Sıkılaştırma (Açık Relay Koruması): Explicit proxy'nin (:3128) güvenlik duruşunu belirleyen iki anahtar buradadır (ayrıntılı açıklama Bölüm 6'da):

  • Explicit Proxy: TLS Kesme (MITM): Açıkken :3128, kesme kapsamı listesindeki ve kayıtlı sağlayıcı hostlarına giden CONNECT'leri keser. Prompt kontrolleri (PII, DLP, injection, path filter, model ACL) ancak TLS kesme açıkken ve hostun kesme kapsamında olmasıyla okunabilir; iki koşul birlikte gereklidir. MITM CA sertifikası gerektirir (kurulum sırasında üretilir). Değişiklik yeniden başlatma gerektirmez; bir sonraki CONNECT isteğinden itibaren geçerlidir.
  • Explicit Proxy: Kimlik Doğrulama Zorunlu: Açıkken (varsayılan) :3128, geçerli proxy token'ı veya captive IP oturumu olmayan her isteği upstream'e bağlantı kurmadan 407 ile reddeder. arceris-dev ile enroll olmuş araçlar token taşıdığı için etkilenmez. Kapatmak, kutuyu kimlik denetimi olmayan açık bir CONNECT relay'ine dönüştürür; yalnızca proxy portuna AI trafiği yönlendirilen ve ağ seviyesinde korunan ortamlarda düşünülmalıdır.

Dinleyici ve başlangıç değerleri: Explicit proxy dinleyicisi kurulum sırasında açılır veya kapatılır (varsayılan: kapalı); etkinleştirildiğinde Arceris, belirtilen port üzerinde forward proxy dinleyicisini başlatır. Varsayılan port: 3128; kurumun güvenlik duvarı kurallarında bu porta izin verilmesi gerekir. TLS kesmenin açılış değeri de kurulumda belirlenir; kurulumdan sonraki açma/kapama işlemi paneldeki "Explicit Proxy: TLS Kesme (MITM)" anahtarıyla, yeniden başlatma olmadan yapılır.

Kesme kapsamı listesi: MITM'in hangi hedef alan adlarına uygulanacağını belirten liste. Varsayılan kapsam: api.openai.com, api.anthropic.com, generativelanguage.googleapis.com, copilot-proxy.githubusercontent.com. Kayıtlı sağlayıcı hostları bu listeden bağımsız olarak kesme kapsamındadır; listeye eklenmesi gerekenler, katalogda olmayan ve içeriğinin denetlenmesi istenen hostlardır. Kapsam dışındaki hostlar incelemesiz (blind) tünel olarak iletilir.

Bu başlangıç değerleri sunucu tarafında tanımlanır; değişiklik için destek ekibiyle çalışın. Proxy zinciri arkasındaki kurulumlarda iletilen başlık güvenliği de destek ekibi tarafından yapılandırılır (bkz. "İstemci IP'si, İletilen Başlıklar ve IP Hedefli Kurallar").

Kimlik Doğrulama (Proxy Token)

Explicit proxy, Proxy-Authorization header'ı ile kimlik doğrulaması yapar. Her kullanıcıya özel bir proxy token oluşturulur ve bu token istemci tarafında proxy kimlik bilgisi olarak kullanılır. Token taşıyamayan istemciler için captive IP oturumu geri dönüşü de vardır; bu oturumlar yalnızca bağlantının kaynak adresiyle eşleştirilir (Bölüm 9).

Proxy Token Nasıl Oluşturulur:

  1. Kullanıcı https://<ARCERIS_HOST>:8443/user/login adresinden giriş yapar.
  2. Profile sayfasında "Proxy Token" bölümünde "Generate" butonuna tıklar.
  3. Parolasını girerek onaylar.
  4. Sistem bir proxy token üretir ve ekranda gösterir. Bu token yalnızca bir kez gösterilir; güvenli bir yere kaydedilmelidir.
  5. Admin, User Management sayfasından da kullanıcının proxy token'ını yönetebilir (generate, regenerate, revoke).

Proxy Token Nasıl Kullanılır:

İstemci tarafında iki kimlik doğrulama yöntemi desteklenir:

  • Bearer token:

    Proxy-Authorization: Bearer <proxy_token>
    
    En basit kullanım. HTTP_proxy veya HTTPS_PROXY ortam değişkeniyle birlikte kullanılabilir.

  • Basic auth:

    Proxy-Authorization: Basic base64(<username>:<proxy_token>)
    
    Bazı istemciler (ör. curl, IDE'ler) Basic proxy auth'u daha iyi destekler. Kullanıcı adı herhangi bir değer olabilir; önemli olan parola alanının proxy token olmasıdır.

Örnek Kullanımlar:

# curl ile
curl --proxy https://localhost:3128 \
     --proxy-header "Proxy-Authorization: Bearer abc123token" \
     https://api.openai.com/v1/chat/completions

# Ortam değişkeniyle
export HTTPS_PROXY=https://localhost:3128
export HTTPS_PROXY_AUTH="Bearer abc123token"

arceris-dev ile enroll olmuş cihazlarda geliştirici araçları token'ı kendiliğinden taşır; kullanıcıdan ayrıca bir şey yapması beklenmez (Bölüm 13, Bölüm 24).

Proxy Token Yönetimi:

  • Generate: Yeni bir token oluşturur. Önceki token varsa geçersiz kalır.
  • Regenerate: Mevcut token'ı geçersiz kılarak yenisini oluşturur.
  • Revoke: Token'ı kalıcı olarak iptal eder. İstemci yeni token alana kadar proxy'yi kullanamaz.

Token güvenliği için: - Token'lar yalnızca bir kez gösterilir; kaybolursa regenerate yapılmalıdır. - Token'lar kod reposuna, log dosyalarına veya paylaşılan alanlara yazılmamalıdır. - Kullanıcı ayrıldığında veya şüpheli durumda token hemen revoke edilmelidir.

Sunulmuş ama reddedilmiş bir token (süresi dolmuş, iptal edilmiş, askıya alınmış) captive IP oturumuyla kurtarılmaz; istek anonim sayılır ve "Kimlik Doğrulama Zorunlu" açıkken 407 alır. Bu reddedilme, İstek Olayları ve Denetim Kayıtları'nda nedeniyle birlikte kayda geçer; token'ın kendisi hiçbir kayda yazılmaz (Bölüm 25).

İstemci IP'si, İletilen Başlıklar ve IP Hedefli Kurallar

Explicit proxyde istemci IP'si iki yerde önem taşır: iletilen başlıkların yorumlanmasında ve IP hedefli kuralların uygulanmasında.

İletilen başlıklar: Explicit proxy, X-Forwarded-For başlığına yalnızca sunucu tarafında güvenilir kabul edilen kaynaklardan itibar eder; varsayılan olarak yalnızca doğrudan bağlanan (socket) istemci kabul edilir. Proxy zinciri arkasındaki kurulumlarda hangi kaynaklara itibar edileceği destek ekibi tarafından yapılandırılır. İtibar edilen tek başlık X-Forwarded-For'dur ve sağdan sola okunur: güvenilir olmayan en sağdaki adres istemci kabul edilir. X-Real-IP yok sayılır. Yönetim/API arayüzünün başlık yorumu ayrı yapılandırılır; explicit proxy üzerinde etkisi yoktur. Arceris bir yük dengeleyicinin veya üst proxy'nin arkasındaysa ve o aracı güvenilir kabul edilmiyorsa her istemci aracının adresinde görünür; aracı güvenilir kabul edildiğinde gerçek istemci X-Forwarded-For'dan sağdan sola çözülür. İstemci adresini başlığa hiç bağımlı olmadan korumanın yolu, bağlantıyı adres düzeyinde taşıyan L4 pass-through kullanmaktır. Güvenilen listelerde köprü ağ geçidi adresi (ör. 172.17.0.1) varsa açılışta bir WARN ile adı geçer; bu tür adresler hairpin ve IPv6 trafiğini de iletebilir.

IP hedefli kurallar: TLS-bump edilen tünellerde istekler artık gerçek istemci IP'sini taşır. Daha önce bump'lı trafik hiç IP taşmadığı için IP hedefli kurallar (Model Access, path filter, …) coding agent trafiğine hiç uygulanmıyordu; artık uygulanır. Etkilenen IP hedefli kurallar açılışta tek bir WARN ile listelenir. IP koşullu atamaların nasıl yazıldığı Bölüm 11'de, bump'lı trafiğin denetim satırlarında istemci IP'si görünür (Bölüm 25).

İstek Akışı

  1. İstemci, Arceris explicit proxy'sine (ör. localhost:3128) bir istek gönderir.
  2. Arceris, Proxy-Authorization header'ından kullanıcıyı doğrular; token yoksa veya geçersizse captive IP oturumuna, o da yoksa "Kimlik Doğrulama Zorunlu" açıkken 407'ye düşer.
  3. HTTP istekleri: İstek doğrudan hedefe iletilir; PII taraması, DLP, prompt injection kontrolü, model ACL denetimi ve dosya (MIME/dosya metadata) kontrolleri uygulanır.
  4. HTTPS istekleri (CONNECT):
  5. TLS kesme açıkken ve hedef kesme kapsamı listesinde veya kayıtlı sağlayıcı hostlarından biriyse: TLS bump yapılır, içerik denetlenir ve güvenlik politikaları uygulanır.
  6. Katalog dışı bir AI hostuysa: asla otomatik bump edilmez; yalnızca tespit edilir ve Shadow AI akışında görünür.
  7. Diğer hedefler: incelemesiz (blind) tünel olarak iletilir; Arceris kimin nereye bağlandığını görür, içeriği göremez.
  8. Eşleşme bulunursa istek engellenir veya maskelenir; bulunmazsa hedefe iletilir.

MITM ve TLS Bump Mekanizması

HTTPS trafiğinde içerik denetimi yapabilmek için Arceris, TLS bağlantısını kesip (bump) tekrar şifreler. Bu işlem için Arceris CA sertifikası kullanılır.

  • "Explicit Proxy: TLS Kesme (MITM)" anahtarı açıkken ve hedef kesme kapsamındaysa TLS bump yapılır; anahtar panelden değiştirildiğinde bir sonraki CONNECT'te geçerli olur, yeniden başlatma gerekmez.
  • İstemci cihazda Arceris CA sertifikasının güvenilir kök sertifikalar arasına eklenmiş olması gerekir (Transparent Proxy'deki CA güven dağıtımı ile aynı; Bölüm 22).
  • TLS kesme kapalıyken HTTPS trafiği incelemesiz tünel olarak iletilir. Bu durumda Arceris trafiği görür (kim, nereye bağlanıyor) ancak içeriği göremez; prompt kontrolleri çalışmaz.

Uzun Turlar ve Akış Davranışı

AI taşıyan yollarda Arceris, bütün bir isteğin veya yanıtın süresini sınırlayan bir üst sınır uygulamaz. Bir model turu dakikalar sürebilir; sınır, istemcinin bağlantıyı kesmesidir. MITM akışı istemci bağlantısını izler ve istemci koptuğunda upstream bağlantısını iptal eder — coding agent'ın uzun turu gateway tarafından yarıda kesilmez, istemci gitmişse upstream de boş yere açık kalmaz.

Yanıt Tarafı Denetimi

Yanıt taraması açıkken modelin cevabı istemciye ulaşmadan denetlenir ve bu, tüm kanallar arasında explicit proxy üzerinde de çalışır (Bölüm 6, Yanıt Taraması). Path filter açıkken dahi yanıt PII taraması çalışır: tarama, path filter'ın çıktısı üzerinden yapılır (Bölüm 17) ve bir path filter reddinin metnindeki PII dahi maskelenmiş olarak döner — coding agent'lar yanıttaki PII'yi maskelenmiş alır.

Yanıt tarafının explicit proxy davranışı:

  • Denetim kaydı fiilen yapılanı yazar: maskelendi, reddedildi veya "log" eylemiyle yalnızca not edildi.
  • "Block" eylemi akışsız (stream edilmemiş) bir yanıtı da reddeder.
  • Maskelenecek bir şey yoksa (kullanıcıya atanmış PII kuralı yoksa veya eylem "log" ise) akışlı yanıt canlı akmaya devam eder; "mask"/"block" altında akışlı yanıt model bitince tek seferde gelir.
  • İnceleme sınırını aşan yanıt kısaltılmadan bütün teslim edilir.

Dosya Kontrolleri

Coding agent'ların explicit proxy üzerinden gönderdiği dosyalar, yüklemelerle aynı dosya kontrollerinden geçer: MIME ve dosya metadata kuralları, koklanan ve beyan edilen tür birlikte değerlendirilen tek dosya kararıyla uygulanır — aynı dosya başka bir giriş noktasından gelseydi de aynı karar çıkardı (Bölüm 18). Claude Code'un kendi okuma aracıyla okuduğu dosyanın adı, aracın okuma çağrısındaki yoldan alınır; yerel diskte okunan dosyalar için MIME/metadata kuralları arceris-dev hook'u üzerinden ayrıca uygulanır (Bölüm 24). DLP dosya kuralları da bu trafikte geçerlidir (Bölüm 20).

Katalog Dışı AI Hostları ve Shadow AI Görünürlüğü

Bir terminal aracı, katalogda olmayan bir AI sağlayıcısına (ör. api.z.ai) bağlanırsa bu host asla otomatik bump edilmez: otomatik bump, Model ACL'nin örtük reddi ile karşılaşır ve canlıdaki aracı düşürürdü. Bunun yerine host yalnızca tespit modunda tanınır ve Shadow AI akışında görünür: CONNECT incelemesiz tünellenir ama "bu bir AI hostu ve yönetilmiyor" kaydı düşer.

Shadow AI akışında bu satırlar "Geliştirici aracı" kaynağıyla listelenir ve Araç sütunu, isteğin taşıdığı X-Arceris-Tool bilgisinden beslenir (hangi araç, hangi hostu kullanıyor). Her satırdaki "Provider olarak tanımla" işlemi, sağlayıcı ekleme formunu bu hostla ön-dolu açar; host tanımlandığında yakalama ve tüm prompt kontrolleri devreye girer (Bölüm 8). Remediation önerisi, hostun kesme kapsamına eklenmesidir — explicit proxy bu hostu ancak o zaman inceleyebilir.

Oturum Tehditi Korelasyonu

IDE/CLI trafiği, explicit proxy üzerinden çok turlu oturum tehdidi korelasyonuna kendi ide: ad alanında katılır. Bir coding agent oturumunda biriken tehdit sinyalleri (injection denemeleri, ACL ihlalleri), tarayıcı oturumlarıyla aynı korelasyon ve eşik mekanizmasından geçer; oturum kaynakları arasında "IDE / CLI (açık proxy)" ayrımı görünür. Ayrıntılar Bölüm 21'de.

Denetim İzi ve Sayım

  • Tek iz: Explicit proxyde bir blok tek iz bırakır: host+yol ve orijinal payload'ı taşıyan tek bir denetim satırı. İstemcinin aynı isteği tekrar denemesi ayrı satır açmaz; tekrarlar deduplanır (Bölüm 25).
  • Kimlik kaynağı: Her explicit reddi, kimliğin nereden geldiğini (oturum, IP oturumu, cihaz aktarımı, kimlik bilgisi, anonim) taşır; İstek Olayları satırında da aynı kimlik bilgisi görünür.
  • İstemci IP'si: Bump'lı trafiğin denetim satırları istemci IP'sini kaydeder.
  • Blok bildirimi: Gövdesinde boş bir events listesi taşıyan istekler ham gövde taramasından düşmez; blok bildirimi eşleşen her değer için kategoriyi ayrı ayrı tekrar etmez.
  • Prob trafiği sayılmaz: Claude Desktop başlangıcında gönderdiği count_tokens probları taranır ama sayılmaz: her prob için ayrı istek kaydı ve denetim satırı açılmaz, ardından gelen gerçek tur iki kez sayılmaz. Model ACL, injection, DLP ve PII korumaları problarda da çalışır; bloklanan bir prob her yerde kayda geçer.

IDE ve CLI Yapılandırma Örnekleri

VS Code / Cursor (GitHub Copilot):

settings.json dosyasına eklenir:

{
  "http.proxy": "https://localhost:3128",
  "http.proxyStrictSSL": false,
  "http.proxyAuthorization": "Bearer <proxy_token>"
}

JetBrains IDE (PyCharm, IntelliJ):

Settings → Appearance & Behavior → System Settings → HTTP Proxy: - Proxy type: HTTP - Host: <ARCERIS_HOST> - Port: 3128 - Proxy authentication: Basic - Username: herhangi bir değer - Password: <proxy_token>

curl:

curl --proxy https://<ARCERIS_HOST>:3128 \
     --proxy-header "Proxy-Authorization: Bearer <proxy_token>" \
     https://api.openai.com/v1/chat/completions \
     -H "Authorization: Bearer <real_api_key>" \
     -d '{"model":"gpt-4o","messages":[{"role":"user","content":"Hello"}]}'

Python OpenAI SDK:

import openai

client = openai.OpenAI(
    api_key="<real_api_key>",
    http_client=httpx.Client(
        proxy="https://<ARCERIS_HOST>:3128",
        headers={"Proxy-Authorization": "Bearer <proxy_token>"}
    )
)

arceris-dev ile enroll olmuş makinelerde HTTPS_PROXY ve token yapılandırması helper tarafından yönetilir; elle yapılandırma yalnızca enroll olmayan istemciler için gerekir (Bölüm 24).

Transparent ve Explicit Proxy Karşılaştırması

Özellik Transparent Proxy Explicit Proxy
İstemci yapılandırması Gerekmez Gerekir (proxy ayarı)
Ağ yönlendirme Gerekir (DNS/PBR) Gerekmez
Kimlik doğrulama Captive portal / proxy token Proxy token (zorunlu, varsayılan açık)
Kullanım senaryosu Tarayıcı, son kullanıcı IDE, CLI, SDK, coding agent'ları
MITM Her zaman aktif Anahtar + kesme kapsamı (bump listesi / kayıtlı sağlayıcı hostları)
CA güven dağıtımı Gerekli MITM açıksa gerekli
Port 443 (varsayılan) 3128 (varsayılan)

En sağlıklı yaklaşım, kullanım türlerine göre bu modelleri birlikte kullanmaktır: tarayıcı trafiği için transparent proxy, geliştirici araçları için explicit proxy.

Güvenlik Değerlendirmesi

  • "Kimlik Doğrulama Zorunlu" varsayılan olarak açıktır; anonim istekler upstream'e bağlantı kurulmadan reddedilir. Anahtarı kapatmak kutuyu açık bir CONNECT relay'ine dönüştürdüğü için, kapatma yalnızca ağ seviyesinde korunan ortamlarda değerlendirilmelidir.
  • Proxy token'lar uzun ömürlüdür ancak istediğiniz zaman revoke edilebilir; reddedilen token'ların kendisi kayıtlara asla yazılmaz.
  • TLS kesme kapalıyken bile Arceris bağlantı metadata'sını (kim, nereye, ne zaman) kaydeder; katalog dışı AI hostları da en azından tespit edilip Shadow AI akışına düşer.
  • Kesme kapsamı listesi, yalnızca denetlenmesi gereken alan adlarını içerecek şekilde dar tutulmalıdır.
  • İletilen başlık güvenliği yalnızca gerçekten önünde duran üst proxy'leri kapsayacak şekilde yapılandırılmalıdır; herkese açık aralıklar istemci IP'sinin sahtelenmesine kapı açar.
  • IP hedefli kuralların bump'lı coding agent trafiğine artık uygulandığını unutmayın; IP koşullu atamaların kapsamını gözden geçirirken Bölüm 11 rehberdir.