# Üretim güvenliği > QueryProxy'yi erişilebilir bir ağda çalıştırmak için kontrol listesi; uygulama anahtarından HTTPS'e, salt okunur bağlantılardan varsayılan korumalara kadar. - Dokümantasyon: Kılavuzlar - Güncelleme: 2026-10-31 - Kaynak: https://queryproxy.com/tr/docs/uretim-guvenligi/ - Dil: tr-TR - Yazar: Muhammet Şafak --- QueryProxy, önündeki her veritabanının kimlik bilgilerini saklar; bu yüzden kurulumun kendisini de hassas bir sistem olarak ele alın. Bir ağa açmadan önce bu listeyi gözden geçirin. ## Önerilen üretim düzeni - Yalnızca okuyan ekipler ya da kullanıcılar için yalnızca `SELECT` yetkisi olan bir veritabanı kullanıcısıyla ayrı bir bağlantı tanımlayın. Yazma erişimini başka bir bağlantıda tutun; çünkü onaylanan yazmalar, gönderildikleri bağlantı üzerinden çalışır. Salt okunur oturumu olmayan SQL Server'da bağlantıya, yalnızca `SELECT` yetkisi olan ayrı bir **okuma kullanıcı adı ve parolası** verin. - Mümkünse bu salt okunur bağlantıyı bir replikaya yöneltin. - QueryProxy ile hedef veritabanı arasındaki ağ yolunu kısıtlayın. - Her ağ bağlantısında TLS'yi zorunlu kılın ve sunucu sertifikasını doğrulayın (PostgreSQL'de `verify-ca` ya da `verify-full`, MySQL ve MariaDB'de "Verify the server certificate", SQL Server'da `TrustServerCertificate` kapalı). v0.3.0'dan önce oluşturulan bağlantılar siz düzenleyene kadar zorunlu kılınmaz; `queryproxy:doctor` bunları listeler. SQL guard son savunma hattı değildir. Okumalar veritabanı tarafında salt okunur bir oturumda çalışır, ama son hat yine veritabanı kullanıcısının yetkileridir; savunmayı onlarla da kurun. ## Kontrol listesi - **`APP_KEY`'i açıkça ayarlayın** ve sabit tutun. Bağlantı kimlik bilgilerini ve sohbet secret'larını şifreler; değişirse saklanan tüm kimlik bilgileri okunamaz hale gelir. Şu komutla üretin: `docker run --rm queryproxy/queryproxy php artisan key:generate --show` ve `-e APP_KEY=...` olarak verin (aynı kurulumun tüm konteynerleri aynı anahtarı paylaşmalıdır). Anahtarı döndürürken eskisini `APP_PREVIOUS_KEYS` içine taşıyın; böylece mevcut şifreli veriler çözülmeye devam eder. Açık bir `APP_KEY` yoksa konteyner ilk açılışta bir anahtar üretir ve veri volume'üne yazar. - **HTTPS ile sunun**: TLS sonlandıran bir ters vekilin arkasında (konteyner `:7432` üzerinde düz HTTP sunar). Ardından `SESSION_SECURE_COOKIE=true` ayarlayın. - **Önünde bir vekil varsa `TRUSTED_PROXIES`'i vekilinizin IP'sine ya da CIDR'ına ayarlayın.** Varsayılan olarak hiçbir vekile güvenilmez; ayarlayana kadar uygulama bağlanan eşi istemci sayar: `X-Forwarded-Proto` yok sayılır (HTTPS algılanmaz, dolayısıyla HSTS başlığı gönderilmez) ve denetim kayıtlarına vekilin adresi yazılır. `*` değerini asla vermeyin: her istemcinin `X-Forwarded-For` başlığını taklit etmesine izin verir; bu hem denetim izindeki istemci IP'sini sahteler hem de IP bazlı oldukları için giriş ve 2FA denemelerini sınırsız kılar. Bkz. [Yapılandırma](/tr/docs/yapilandirma/#ters-vekil-arkasında). - **Sırları dosya olarak verin**, platformunuz sağlıyorsa: değerleri ortama yazmak yerine `APP_KEY_FILE`, `DB_PASSWORD_FILE` ve diğer `*_FILE` değişkenlerini ayarlayın. Bkz. [Yapılandırma](/tr/docs/yapilandirma/#dosyadan-sırlar). - **Demo verisini kapalı tutun** (`QUERYPROXY_SEED_DEMO=false`, varsayılan); erişilebilir her kurulumda. - **Ayrıcalıklı roller için 2FA zorunlu kılın**: `QUERYPROXY_REQUIRE_2FA=admins` (ya da `dba` / `all`). Kullanıcılar bir sonraki girişte kayda yönlendirilir. - **Tek oturum açma kullanıyorsanız MFA'yı kimlik sağlayıcıda zorunlu kılın.** SSO ile giren kullanıcılar `QUERYPROXY_REQUIRE_2FA` kapsamının dışındadır; QueryProxy sağlayıcının hangi ikinci faktörü kullandığını göremez. E-posta adreslerini doğrulamayan bir sağlayıcı bağlamayın (QueryProxy hesapları yalnızca sağlayıcı doğrulanmış bir adres bildirirse oluşturur ve bağlar: `email_verified`, Entra ID için `xms_edov`) ve parolanın yalnızca sistem yöneticilerinde, break-glass erişimi için kalması amacıyla `QUERYPROXY_LOCAL_LOGIN=admins_only` değerini düşünün. QueryProxy'den çıkmak kullanıcıyı sağlayıcıdan çıkarmaz. Bkz. [Tek oturum açma](/tr/docs/tek-oturum-acma/). - **API token'larını kimlik bilgisi gibi ele alın.** Her token'a yalnızca ihtiyaç duyduğu kapsamları verin; `approvals:write`'ı talepleri karara bağlaması gereken az sayıdaki token'a ayırın: sızdırılmış bir onaylayan token'ı başka kullanıcıların taleplerini onaylayabilir. `QUERYPROXY_API_TOKEN_MAX_DAYS` değerini (varsayılan `90`) kabul ettiğiniz en uzun ömre indirin ve rol değiştiren kişilerin token'larını iptal edin. Bir token, sahibinin kendi talebini onaylayamaz ve override yapamaz. Token oluşturma ve iptal denetlenir. Bkz. [REST API ve token'lar](/tr/docs/rest-api/). - **Kubernetes'te NetworkPolicy'yi açın** (`networkPolicy.enabled`) ve ingress denetleyicinizi `networkPolicy.ingressFrom` içinde listeleyin; böylece 7432 portuna yalnızca o ulaşır (ağ eklentiniz NetworkPolicy'yi uygulamalıdır). Gereken egress'i de `networkPolicy.egress.restrict=true` ile listeleyin. Chart'ın yönettiği Secret yerine kendi Secret'ınızı (`secrets.existingSecret`) kullanın. Bkz. [Kubernetes, Helm ve yüksek erişilebilirlik](/tr/docs/kubernetes-ve-helm/). - **Kalıcı olmayan erişim için süreli tanımlamayı tercih edin:** DBA bir bağlantıyı belirli bir süre için ve `read` düzeyinde tanımlayabilir. Bkz. [Onay akışı](/tr/docs/onay-akisi/#süreli-tanımlamalar-ve-erişim-talepleri). - **Denetim günlüğünün bir kopyasını veritabanının dışında tutun.** Bir SIEM hedefini (`QUERYPROXY_SIEM_SINKS`) açın; böylece veritabanına erişimi olan biri geçmişi fark edilmeden yeniden yazamaz. Bkz. [Denetim zinciri ve SIEM aktarımı](/tr/docs/denetim-kaydi-ve-siem/). - **`/metrics`'i** bir token ya da adres izin listesiyle koruyun, ya da kapalı bırakın (varsayılan). - **Her deploy'dan sonra doctor'ı çalıştırın**: `php artisan queryproxy:doctor --strict`. Bkz. [Sorun giderme](/tr/docs/sorun-giderme/). - **Veriyi ve `APP_KEY`'i ayrı ayrı yedekleyin.** Bkz. [Yedekleme ve geri yükleme](/tr/docs/yedekleme-ve-geri-yukleme/). - **Bağlantı hedeflerini kısıtlayın**: DBA'lerin rastgele host'lara ulaşmaması gerekiyorsa `QUERYPROXY_CONNECTION_HOST_DENYLIST` / `QUERYPROXY_SQLITE_ALLOWED_DIR` kullanın. ## Varsayılan olarak açık olanlar Bunlar için yapılandırma gerekmez: - Content-Security-Policy dahil güvenlik yanıt başlıkları ve Livewire ucunda istek sınırı (rate limit). - Diskte şifreli bağlantı kimlik bilgileri ve TOTP iki adımlı doğrulama (siz zorunlu kılana kadar isteğe bağlı). - Yorumları normalize eden SQL guard'ları ve çalıştırıcıda uygulanan satır tavanı. - Yeniden oynatmaya karşı korumalı, kimliğe bağlı sohbet callback'leri ve kendi talebini onaylamanın engellenmesi. - Kurcalamaya karşı belirgin (hash zinciri ve veritabanı trigger'ları) bir denetim günlüğü; SQL, Auditor'lara ve sohbette redakte edilmiş gösterilir; ayrıca giriş/webhook istek sınırı. - SSRF'e karşı korumalı giden webhook'lar. - Her zaman sona eren, özet (hash) olarak saklanan ve sahibi askıya alınır ya da silinirse çalışmaz olan API token'ları. - Yazılırken maskelenen, hata durumunda kapalı kalan sonuç depolaması. ## Sonraki adımlar - Tüm ortam değişkenleri: [Yapılandırma](/tr/docs/yapilandirma/). - QueryProxy'nin kimlere ve nelere karşı savunduğu: [Tehdit modeli](/tr/docs/tehdit-modeli/). - Docker'sız kurulum: [Manuel kurulum](/tr/docs/manuel-kurulum/). - Sohbet callback'leri: [Slack entegrasyonu](/tr/docs/slack-entegrasyonu/) ve [Teams entegrasyonu](/tr/docs/teams-entegrasyonu/).