Ü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.

SQL sorgu onay akışı nedir?

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ı. 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ı anlatır. WHERE kuralı WHERE’siz UPDATE ve DELETE nasıl engellenir yazısında açıklanır.

Roller ve tam yaşam döngüsü için onay akışı dokümantasyonuna, parse edicinin neyi reddettiği için SQL korumaları referansına bakın. Korumalar motora göre farklılaşır; bkz. PostgreSQL, MySQL ve MariaDB ve SQL Server. 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, KVKK açısından hangi kanıta karşılık geldiği için KVKK ve veritabanı erişim 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.