Parolayı paylaşmadan geliştiricilere üretim PostgreSQL veritabanına erişimi nasıl veririm?

Veritabanını QueryProxy'ye bir kez kaydedin; kimlik bilgisi orada AES-256 ile şifrelenmiş olarak saklanır. Geliştiricilere parolayı değil bağlantıyı verin. SQL gönderirler, bir DBA onaylar ve bir işçi (worker) bunu saklanan kimlik bilgisiyle çalıştırır. Geliştiriciler parolayı hiç görmez.

PostgreSQL'de kişisel verileri korumak için GRANT SELECT yeterli mi?

Hayır. GRANT SELECT, rolün yetki verilen her kolonu, e-posta adresleri ve telefon numaraları dahil, okumasına izin verir ve bunları istemciye maskesiz döndürür. Satır düzeyi güvenlik satırları gizleyebilir ama izin verdiği satırlardaki bir kolonu maskeleyemez. Maskeleme ayrı bir katmandır ve QueryProxy bunu sonuç yazılırken uygular.

QueryProxy COPY ... TO PROGRAM'ı engelliyor mu?

Evet. SQL guard, PostgreSQL COPY'yi, COPY ... TO PROGRAM dahil, gönderim anında reddeder; talep hiçbir DBA'e ulaşmaz. Aynısı pg_read_file(), pg_read_binary_file(), pg_ls_dir(), lo_import() ve lo_export() için de geçerlidir.

QueryProxy PostgreSQL'deki DO bloklarını nasıl ele alıyor?

DO bloğu yazma olarak sınıflandırılır ve her zaman tüm gövdesini gören bir DBA'e gider. Gövde, engellenen fonksiyonlar ve korunan ayarlar için taranır; dinamik SQL (EXECUTE) kullanan bir gövde, çalıştıracağı ifade önceden okunamadığı için reddedilir.

QueryProxy, PostgreSQL rollerinin ve satır düzeyi güvenliğin yerini alıyor mu?

Hayır. Onların önüne bir katman ekler. QueryProxy bağlantısına yalnızca işin gerektirdiği yetkilere sahip bir veritabanı kullanıcısı verin; okuma bağlantıları için ideali yalnızca SELECT'tir, çünkü veritabanı tarafındaki salt okunur transaction ve statement timeout henüz mevcut değil.

PostgreSQL erişim denetimi ve sorgu onayı

PostgreSQL, kimin hangi nesneleri okuyabileceğine ya da değiştirebileceğine karar verir. Gece 3’te biri tarafından yazılan bu özel ifadenin çalışıp çalışmaması gerektiğine karar vermez. QueryProxy bu kararı ekler: geliştiriciler SQL gönderir, ifade kuyruğa girmeden önce parse edilip denetlenir, bir DBA onaylar ve sonuç saklanmadan önce maskelenir. PostgreSQL parolası QueryProxy’nin kasasında kalır ve hiçbir geliştiriciye verilmez.

GRANT ve satır düzeyi güvenlik neyi kapsar?

GRANT, bir role nesneler üzerinde yetki verir: tablolar, kolonlar, şemalar, fonksiyonlar. Bir rolün neye erişebileceğini sınırlamak için doğru araçtır ve her üretim kurulumu onu kullanmalıdır.

Satır düzeyi güvenlik daha da ileri gider. PostgreSQL 18.6 dokümantasyonu, satır güvenliği politikalarının “normal sorgularla hangi satırların döndürülebileceğini ya da veri değiştirme komutlarıyla hangi satırların eklenebileceğini, güncellenebileceğini veya silinebileceğini” kısıtladığını söyler. Aynı sayfa, superuser’ların ve BYPASSRLS özniteliğine sahip rollerin onu her zaman atladığını, tablo sahiplerinin de normalde atladığını belirtir. (2026-10-13 tarihinde okundu.)

İkisinin de yapmadığı şey ifadeye bakmaktır. Bir tabloyu UPDATE edebilen rol, WHERE cümlesiz bir UPDATE çalıştırabilir. users tablosunu SELECT edebilen rol, içindeki her e-posta adresini maskesiz olarak bir dizüstü bilgisayara alır. İkisinde de ikinci bir kişi yoktur. Bu boşluklar veritabanı erişim denetiminin ne olduğu yazısının savıdır: roller kimin işlem yapabileceğini söyler, ifadeyi inceleyemez. WHERE’siz UPDATE ve DELETE nasıl engellenir yazısı bu boşluğu ayrıntılı ele alır.

QueryProxy PostgreSQL’de neyi engeller?

Her gönderim onay kuyruğuna ulaşmadan önce parse edilir ve bir guard’ı çiğneyen talep, gönderim anında açık bir mesajla reddedilir. SQL korumaları referansı kuralları dialect’e göre listeler. PostgreSQL’de en önemli olanlar:

WHERE’siz ya da her zaman doğru olan bir WHERE ile (WHERE 1 = 1) yazılmış UPDATE ve DELETE reddedilir. LIMIT’siz bir SELECT’e LIMIT 1000 eklenir, 10000’in üzerindeki limit ise düşürülür.
COPY, COPY ... TO PROGRAM dahil, engellenir.
Dosya fonksiyonları engellenir: pg_read_file(), pg_read_binary_file(), pg_ls_dir(), lo_import() ve lo_export().
dblink* ile pg_terminate_backend, pg_cancel_backend, pg_reload_conf, pg_rotate_logfile, pg_promote ve pg_switch_wal yönetim fonksiyonları engellenir.
Kendilerine string olarak verilen SQL’i çalıştıran query_to_xml, xpath_table, ts_stat ve crosstab* gibi fonksiyonlar, guard içerideki ifadeyi okuyamadığı için engellenir.
CREATE EXTENSION ada göre değerlendirilir. Güvenilmeyen prosedürel diller (plpythonu, plperlu ve pl...u kuralına uyan her ad) reddedilir; pgcrypto, uuid-ossp ya da postgis normal şekilde kurulur.
session_preload_libraries, dynamic_library_path ya da session_replication_role gibi korunan bir ayarın SET ile değiştirilmesi her kapsamda reddedilir.

DELETE FROM customers;                      -- rejected at submission
DELETE FROM customers WHERE id = 42;        -- allowed, still needs a DBA
SELECT pg_read_file('/etc/passwd');         -- rejected at submission

Tablo adları örnektir; kararlar belgelenmiş kurallara göre verilir.

DO blokları nasıl ele alınır?

Bir DO bloğu, bir CREATE FUNCTION ya da bir CREATE PROCEDURE başka bir dilde yazılmış bir gövde taşır. QueryProxy bu gövdeyi PostgreSQL’in kendi sözcük kurallarıyla okur, engellenen fonksiyon ve korunan ayar kurallarını ona uygular ve yalnızca plpgsql ile sql dillerini kabul eder.

DO bloğu yazma olarak sınıflandırılır ve her zaman insan onayından geçer; onay veren kişi gövdenin tamamını görür. Dinamik SQL (EXECUTE) kullanan bir gövde, çalıştıracağı ifade çalışma anında kurulduğu için doğrudan reddedilir. Bir plpgsql bloğunun yapabileceği geri kalan her şeye parser değil, onay karar verir.

Bir PostgreSQL veritabanı nasıl bağlanır?

Bir DBA, veritabanını Connections altında pgsql sürücüsüyle kaydeder. Varsayılan port 5432’dir (DbDriver.php, v0.2.5). Varsayılan Docker imajı pdo_pgsql ile gelir, dolayısıyla imajı değiştirmek gerekmez; gerisini yapılandırma rehberi anlatır. Kimlik bilgileri AES-256 ile şifrelenerek saklanır. Geliştirici bağlantıyı yalnızca bir DBA yetki verdikten sonra görür.

Salt okunur çalışan ekipler için, yalnızca SELECT yetkisi olan bir veritabanı kullanıcısıyla ayrı bir bağlantı kaydedin ve mümkünse onu bir replikaya yöneltin. Üretim güvenliği rehberi bunu önerir.

Sonuca ne olur?

Satırlar, cursor’dan sonuç dosyasına akarken maskelenir; böylece maskesiz bir kopya diskte hiç bulunmaz. Maskeleme kuralları bir kolon adıyla (*email* gibi) ya da bir değerin içeriğiyle eşleşir; hiçbir kuralın eşleşmediği değer olduğu gibi döner. Dinamik veri maskeleme fikri anlatır, veri maskeleme dokümantasyonu ise kural türlerini ve stratejileri listeler.

Maskeleme hataları da kapsar. Failing row contains (...) gibi bir PostgreSQL hatası, kısıtı bozan satırı yankılayabilir; bu yüzden bağlantıda herhangi bir maskeleme kuralı varsa, saklanan hata mesajında satırın tamamı maskelenir. Gönderimden indirmeye kadar her adım değiştirilemez bir denetim günlüğüne yazılır.

PostgreSQL’de sınırlar neler?

Yasak listesi eksiktir. Bugün bilinen tehlikeli sözdizimini adlandırır; adlandırmadığı bir yazım geçer. SQL korumaları referansı bunu kendisi söyler: bir ifadeyi yetkilendiren şey guard değil, DBA onayıdır.
Veritabanı tarafında henüz salt okunur transaction ve statement timeout yok. İkisi de v0.3.0 için planlananlar arasında listelenir. O zamana kadar okuma bağlantıları için yalnızca SELECT yetkisi olan bir veritabanı kullanıcısı kullanın.
TLS henüz yapılandırılamıyor. Bağlantı bugün sslmode=prefer kullanır ve bir TLS ayarı v0.3.0 için planlanmıştır. Aktarım katmanını kendiniz kontrol edin.
Maskeleme kural tabanlıdır. Hiçbir kuralın eşleşmediği değer olduğu gibi döner; bu yüzden QueryProxy tüm kişisel verileri maskelediğini iddia etmez.
DO gövdesi taraması yalnızca düz metni okur. plpgsql ile yazılmış bir DO bloğu hâlâ keyfi sunucu tarafı koddur ve gövdesinde açıkça yazılmış WHERE’siz bir DELETE geçer, çünkü bloklara onayda karar verilir.

PostgreSQL için guard’ın kararları canlı bir sunucuya karşı da denetlenir (live-pgsql test grubu). Referans, MySQL, MariaDB ve SQL Server’ın canlı sunuculara karşı çalıştırılmadığını belirtir.

QueryProxy’ye ne zaman ihtiyacınız yok?

Veritabanının sahibi tek kişiyse ve bağlanan yalnızca kendisiyse, onaylayacak ikinci bir kişi yoktur; GRANT artı salt okunur bir rol yeterlidir. Gerçek veri tutmayan bir geliştirme veritabanı için de aynısı geçerlidir. Sorununuz yalnızca uygulamaların parolaları yapılandırma dosyalarında tutması ise, bir secrets manager ya da IAM veritabanı kimlik doğrulaması bunu bir onay kuyruğu olmadan çözer. QueryProxy, insanların önemli verilere anlık erişmesi gerektiğinde ve ikinci bir çift göz ile neyin çalıştığının kaydını istediğinizde yerini hak eder.

Bir talebin nasıl ilerlediği için onay akışına bakın ya da QueryProxy’yi bir atlama sunucusuyla karşılaştırın. MySQL ve MariaDB ekipleri MySQL ve MariaDB erişim denetimi sayfasından başlamalı.

Sık sorulanlar

Parolayı paylaşmadan geliştiricilere üretim PostgreSQL veritabanına erişimi nasıl veririm?: Veritabanını QueryProxy'ye bir kez kaydedin; kimlik bilgisi orada AES-256 ile şifrelenmiş olarak saklanır. Geliştiricilere parolayı değil bağlantıyı verin. SQL gönderirler, bir DBA onaylar ve bir işçi (worker) bunu saklanan kimlik bilgisiyle çalıştırır. Geliştiriciler parolayı hiç görmez.
PostgreSQL'de kişisel verileri korumak için GRANT SELECT yeterli mi?: Hayır. GRANT SELECT, rolün yetki verilen her kolonu, e-posta adresleri ve telefon numaraları dahil, okumasına izin verir ve bunları istemciye maskesiz döndürür. Satır düzeyi güvenlik satırları gizleyebilir ama izin verdiği satırlardaki bir kolonu maskeleyemez. Maskeleme ayrı bir katmandır ve QueryProxy bunu sonuç yazılırken uygular.
QueryProxy COPY ... TO PROGRAM'ı engelliyor mu?: Evet. SQL guard, PostgreSQL COPY'yi, COPY ... TO PROGRAM dahil, gönderim anında reddeder; talep hiçbir DBA'e ulaşmaz. Aynısı pg_read_file(), pg_read_binary_file(), pg_ls_dir(), lo_import() ve lo_export() için de geçerlidir.
QueryProxy PostgreSQL'deki DO bloklarını nasıl ele alıyor?: DO bloğu yazma olarak sınıflandırılır ve her zaman tüm gövdesini gören bir DBA'e gider. Gövde, engellenen fonksiyonlar ve korunan ayarlar için taranır; dinamik SQL (EXECUTE) kullanan bir gövde, çalıştıracağı ifade önceden okunamadığı için reddedilir.
QueryProxy, PostgreSQL rollerinin ve satır düzeyi güvenliğin yerini alıyor mu?: Hayır. Onların önüne bir katman ekler. QueryProxy bağlantısına yalnızca işin gerektirdiği yetkilere sahip bir veritabanı kullanıcısı verin; okuma bağlantıları için ideali yalnızca SELECT'tir, çünkü veritabanı tarafındaki salt okunur transaction ve statement timeout henüz mevcut değil.