QueryProxy

QueryProxy ve just-in-time erişim ile PAM araçları

StrongDM gibi just-in-time erişim araçları erişimi sınırlı bir süre için verir, günlüğe alır ve kaydeder. QueryProxy farklı bir noktada durur ve her SQL ifadesini çalışmadan önce inceler.

Güncelleme:

Bir bakışta

KonuQueryProxyJust-in-time erişim ve PAM araçları
Cevapladığı soru"Bu ifade çalışabilir mi?""Bu kişi şimdi erişebilir mi ve ne zamana kadar?"
Denetim birimiTek bir SQL ifadesiBir kaynağa, belirli bir süre için verilen erişim yetkisi
Süre sınırlarıModeli bu değil; bağlantıyı bir DBA verir ve her ifade onaylanırStrongDM'de erişim tam zamanında verilir ve kendiliğinden sona erer
OnayBir DBA her ifadeyi onaylarStrongDM erişim iş akışlarında onaylayıcılar bir kaynağa erişim talebini kabul eder ya da reddeder
Verilen pencerenin içindeHer ifade parse edilir, sınırlandırılır ve onaylanırStrongDM erişimi ve etkinliği günlüğe alır ve kaydeder; politikaları ayrıca bir eylem için onay iş akışı şart koşabilir, Enterprise planda
Sonuç işlemeKişisel veri sonuç yazılırken maskelenirAraca bağlı
KapsamBeş veritabanı motoruna karşı SQLStrongDM için veritabanları, sunucular, Kubernetes kümeleri, bulutlar ve web uygulamaları

Just-in-time erişim ile QueryProxy farklı soruları cevaplar ve fark, her birinin denetlediği birimdir.

Bir just-in-time (JIT) erişim aracı bir erişim yetkisini denetler: bu kişi bu kaynağa bu kadar süreyle ulaşabilir. Kategorideki bir ürün olan StrongDM bunu en az ayrıcalıklı erişimi tam zamanında vermek ve kendiliğinden sona erdirmek olarak anlatır (strongdm.com). QueryProxy bir ifadeyi denetler: bu belirli UPDATE çalışabilir mi ve sonuç maskelenmeli mi.

Bir yetki size neyi söylemez?

Bir yetki oturumun kenarında biter. StrongDM’in sayfası, denetimler için erişimi ve etkinliği günlüğe aldığını ve kaydettiğini söyler. Bir kayıt, bir kişinin ne çalıştırdığını sonradan söyler; tek başına kimseyi sorguyu önceden okumaya zorlamaz. Bazı araçlar, bir sonraki bölümün göstereceği gibi eylem başına onay ekler.

QueryProxy sırayı tersine çevirir. İfade SQL korumalarına karşı parse edilir, bir DBA onay akışında tam SQL’i okur ve ancak ondan sonra bir işçi onu çalıştırır. Bunun kaydı bir denetim girdisidir, bir oturum kaydı değil: kaydedilecek etkileşimli bir oturum yoktur.

Onay modelleri nasıl ayrışıyor?

StrongDM’in erişim iş akışlarında kullanıcılar kaynaklara erişim talep eder, önceden seçilmiş onaylayıcılar kabul eder ya da reddeder; sayfa özelliğin Enterprise planın parçası olduğunu söyler. İfade düzeyindeki kurallar, belirli veritabanı komutlarına izin verebilen ya da onları yasaklayabilen ve Postgres ile Microsoft SQL Server için satırları sınırlayabilen politikalarında vardır, yine Enterprise planda. Politikalar sayfası ayrıca bir kullanım örneği olarak, bir eyleme yalnızca bir onay iş akışı onaylarsa izin vermeyi sıralar. Hoop’un eylem erişim talepleri, belirlenmiş bir onaylayıcı Slack’te, Teams’te ya da web uygulamasında karar verene kadar her komutu PENDING durumuyla bekletir. Yani çalıştırmadan önce onay bu araçların bazılarında vardır; fark, bunun her ifade için varsayılan olup olmadığıdır.

Bunlar iki satıcının özellikleridir, kategorinin tamamı değil. Bu sayfa her PAM ürünü adına konuştuğunu iddia etmez ve terimi tanımlamaz, çünkü bunun için birincil bir tanım okunmamıştır. Denetçileriniz PAM için belirli bir tanım kullanıyorsa, ürününüzün ne yaptığını ona göre kontrol edin.

Birbirlerine nasıl uyarlar?

Birçok ekibin ikisine de ihtiyacı var. Bir JIT aracı ya da atlama sunucusu ağ yolunu denetler. Teleport bunu kısa ömürlü sertifikalarla yapar. QueryProxy ise veritabanı kimlik bilgisinin yaşadığı ve her ifadenin denetlendiği yerdir. Böylece geçerli bir yetkisi olan biri bile onay ve maskelenmiş bir sonuç olmadan customers tablosunu okuyamaz. Fikir veritabanı erişim denetimi nedir yazısında ortaya konuyor, denemek için hızlı başlangıç var.

QueryProxy’nin kendi sınırları burada da geçerli. Korumaları statiktir ve elinden gelenin en iyisini yapar; veritabanı tarafında salt okunur çalıştırma v0.3.0 için planlanmıştır; bkz. üretim güvenliği.

Yukarıdaki StrongDM ve Hoop ifadeleri herkese açık dokümantasyonlarından 2026-10-13 tarihinde okundu. Aracınızın ne yaptığı için kendi satıcınızın dokümantasyonunu okuyun.

Bunun yerine Just-in-time erişim ve PAM araçları seçmeniz gereken durumlar

  • Sunucular, Kubernetes, bulut konsolları ve web uygulamaları genelinde yönetilen ayrıcalıklı erişime ihtiyacınız varsa. QueryProxy'nin SQL dışında sunacağı bir şey yoktur.
  • Kontrol hedefiniz otomatik sona eren süreli erişimse. QueryProxy süreli erişim vermez; ifadeleri inceler.
  • Onayların biletlere ya da bir yöneticiye bağlandığı, tüm envanteri kapsayan bir kimlik sağlayıcı entegrasyonu istiyorsanız. QueryProxy onaylayıcıları portalın içindeki DBA'lerdir.

Sık sorulanlar

Just-in-time erişim üretim veritabanları için yeterli mi?
Tek başına değil. Birinin ne zaman bağlanabileceğini daraltır, ki bu değerlidir. Yalnızca bir yetki, o pencere içinde ne çalıştırdıklarına karar vermez; dolayısıyla ifadeyi okuyan bir şey yoksa geçerli bir yetkinin içinde WHERE'siz tek bir DELETE yine mümkündür. Bazı araçlar StrongDM politikaları ve Hoop'un eylem erişim talepleri gibi eylem düzeyinde denetimler ekler.
PAM ile sorgu onayı arasındaki fark nedir?
Bir PAM ürünü olan StrongDM, kaynaklara erişimi denetlemeyi ve denetimler için günlüğe alıp kaydetmeyi anlatır. Sorgu onayı her ifadenin çalışmasından önce ikinci bir kişiyi araya koyar. Birincisi kim ve ne zaman sorusunu, ikincisi ne sorusunu cevaplar; yine de bazı erişim araçları eylem başına onay da sunar.
QueryProxy bir PAM aracı mı?
Hayır. PostgreSQL, MySQL, MariaDB, SQL Server ve SQLite'a karşı SQL ile ilgilenir; sunuculara, kümelere ya da konsollara süreli erişim vermez.
JIT erişimi ve QueryProxy'yi birlikte kullanabilir miyim?
Evet. Erişim aracını kimin ağa ve ne kadar süreyle ulaşacağına karar vermek için kullanın; QueryProxy veritabanı kimlik bilgisinin tek sahibi olsun, böylece günlük okuma ve yazmalar incelenmiş bir ifadeden geçsin.

Gezinmek için ok tuşları, açmak için Enter.