# SQL sorgu onay akışı nedir?

> Sorgu onay akışının ne olduğu, bir talebin geçtiği durumlar, kimin neyi onayladığı ve böyle bir akış kurmadan önce tasarımla önlenmesi gereken hata biçimleri.

- Güncelleme: 2026-10-10
- Kaynak: https://queryproxy.com/tr/sql-sorgu-onay-akisi/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
Bir sorgu onay akışı, "çalıştır ve umut et" yerine "gönder ve biri baksın" der.
Geliştirici SQL yazar ama çalıştırmaz; ikinci bir kişi ifadeyi inceler; sistem
sorguyu geliştirici adına çalıştırır ve denetlenmiş bir sonuç döndürür.
Geliştirici kimlik bilgisini hiç eline almaz.

## Bir talebin geçtiği durumlar

**Gönderildi.** Geliştirici, yetkilendirildiği bir bağlantıya karşı bir ifade
yazar. Henüz hiçbir şey çalışmadı.

**Denetlendi.** Sistem, herhangi bir insan görmeden önce SQL'i parse eder. Bu
makine işidir: `WHERE`'siz `UPDATE` ve `DELETE`'i reddet, sınırsız bir `SELECT`'e
`LIMIT` ekle, yönetimsel ifadeleri engelle. Bunları otomatik yakalamak,
inceleyenlerin dikkatini sözdizimine değil niyete ayırmasını sağlar.

**Beklemede.** Talep, karar verebilecek kişilere görünür biçimde bekler. Kimsenin
bakmadığı bir yerde bekliyorsa akış çoktan başarısız olmuştur.

**Onaylandı ya da reddedildi.** Bir inceleyen karar verir ve her iki sonuç da
kimin ne zaman karar verdiğiyle birlikte kaydedilir.

**Çalıştırıldı.** Sistem bağlanır ve ifadeyi çalıştırır. Bekleme süresi
sınırsız olduğundan bu iş bir web isteğinde değil, bir işçide olmalıdır.

**Döndü.** Sonuçlar sınırlandırılmış, maskelenmiş ve bir saklama kuralına bağlı
olarak depolanmış biçimde döner — ardından denetim günlüğüne yazılır.

## Tasarımla önlenmesi gereken hata biçimleri

**Onay yorgunluğu.** Kırk talep gören bir inceleyen kırkını da okumadan onaylar.
Korumalar, açıkça yanlış olanı insan devreye girmeden reddederek yardımcı olur;
böylece bir kişiye ulaşan şey okunmaya değer olur.

**Kimsenin kullanmadığı akış.** Onay, hâlâ orada duran bastion sunucudan yavaşsa
insanlar bastion'ı kullanır. Ya onay yolu hızlı yol olur ya da alternatif kapanır.

**Kendine onay.** İnceleyenlerin kendi taleplerini onaylayabildiği bir akış, akış
kılığına girmiş bir günlükleme sistemidir. Bunu kodda zorlayın.

**Sınırsız sonuçlar.** Yüz milyon satır üzerinde onaylanmış bir `SELECT`,
onaylanmış bir kesintidir. Sınırlayın ve tamponlamak yerine akıtın.

**Tek denetim olarak onay.** Onay, bir ifadenin çalışıp çalışmayacağına karar
verir. Geri ne döneceği konusunda hiçbir şey yapmaz. Maskeleme olmadan onaylanmış
bir sorgu bile birinin dizüstü bilgisayarına maskesiz kişisel veri koyar.

## QueryProxy bunu nasıl uyguluyor

QueryProxy bu akışın ürünleşmiş hâlidir. Talepler korumalı bir düzenleyicide
gönderilir, incelemeden önce bir AST denetleyicisi tarafından parse edilir ve
DBA'lere hem web kuyruğunda hem de Approve ile Reject düğmeleri taşıyan bir Slack
kartı olarak gösterilir — böylece karar, inceleyenin zaten bulunduğu yerde
verilir. Teams'e kart bir duyuru olarak düşer; karar oradan, HMAC imzalı aksiyon
ucunu çağıran bir otomasyonla (ör. bir Power Automate akışı) verilir; bkz. [Slack ve Teams üzerinden SQL onayı](/tr/blog/slack-teams-uzerinden-sql-onayi/). Kendine onay kodda engellenir; bir sistem yöneticisi bunu geçersiz
kılabilir ve geçersiz kılma denetim günlüğünde işaretlenir. Onaylanan sorgular
imleç akışıyla bir kuyruk işçisinde çalışır, sonuçlar yazılırken kurallarınıza
göre maskelenir ve her adım, uygulamanın hiçbir kaydı düzenlemediği ya da
silmediği, yalnızca eklenen bir denetim günlüğüne düşer; bu kaydın neyi
içermesi gerektiğini [denetim kaydı yazısı](/tr/blog/uretim-sorgu-denetim-kaydi/)
anlatır. `WHERE` kuralı [WHERE'siz `UPDATE` ve `DELETE` nasıl
engellenir](/tr/blog/where-olmadan-update-delete-engelleme/) yazısında açıklanır.

Roller ve tam yaşam döngüsü için [onay akışı
dokümantasyonuna](/tr/docs/onay-akisi/), parse edicinin neyi reddettiği için
[SQL korumaları referansına](/tr/docs/sql-korumalari/) bakın. Korumalar motora
göre farklılaşır; bkz. [PostgreSQL](/tr/postgresql-erisim-denetimi/),
[MySQL ve MariaDB](/tr/mysql-mariadb-erisim-denetimi/) ve
[SQL Server](/tr/sql-server-erisim-denetimi/). Onay kaydının ve denetim
günlüğünün uyum kanıtıyla ilişkisi için
[SOC 2 ve veritabanı erişim denetimi](/tr/soc-2-veritabani-erisim-denetimi/),
KVKK açısından hangi kanıta karşılık geldiği için
[KVKK ve veritabanı erişim denetimi](/tr/kvkk-veritabani-erisim-denetimi/)
sayfalarını okuyun.

## Sık sorulanlar

### SQL sorgu onay akışı nedir?

Bir geliştiricinin SQL ifadesini doğrudan çalıştırmak yerine incelemeye gönderdiği, ikinci bir kişinin onayladığı ya da reddettiği ve onaylanan ifadenin sistem tarafından geliştirici adına çalıştırıldığı süreçtir. Geliştirici veritabanı kimlik bilgisini hiç eline almaz ve sorguyu kendisi çalıştırmaz.

### Üretim sorgularını kim onaylamalı?

Şemayı bilen ve talebi açan kişi olmayan biri — genellikle o veritabanının sahibi olan bir DBA ya da kıdemli bir mühendis. Politika yerine yazılımda zorlanmaya değer tek kural, kimsenin kendi talebini onaylayamamasıdır.

### Onay akışı ekipleri yavaşlatır mı?

Bir bekleme ekler ve bu beklemenin uzunluğu tasarımın asıl problemidir. Onaylar iki düğmeli bir sohbet mesajı olarak geldiğinde bekleme genellikle dakikalarla ölçülür. Ayrı bir aracı açıp kuyruk aramayı gerektirdiğindeyse insanlar sistemin etrafından dolaşır ki bu, sistemin hiç olmamasından kötüdür.

### Reddedilen sorgulara ne olur?

Reddedilen talep gerekçesiyle birlikte denetim izinde kalır; böylece kayıt yalnızca ne çalıştığını değil ne istendiğini de gösterir. Geliştirici emeğini kaybetmeden ifadeyi düzeltip yeniden gönderir.