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.
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.
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.
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.
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.
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ışı.
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ı.
/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.
Veriyi ve APP_KEY’i ayrı ayrı yedekleyin. Bkz. Yedekleme ve geri yükleme.
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.
QueryProxy’nin kimlere ve nelere karşı savunduğu: Tehdit modeli.
Docker’sız kurulum: Manuel kurulum.
Sohbet callback’leri: Slack entegrasyonu ve Teams entegrasyonu.