Onay akışı

QueryProxy’de her şey tek bir nesnenin etrafında döner: sorgu talebi. Bu kılavuz kimin ne yapabildiğini ve bir talebin her adımda başına gelenleri anlatır.

Roller

Admin globaldir; DBA, Developer ve Auditor takım bazındadır. Bir kullanıcı birden çok takımda farklı rollerle yer alabilir. Bağlantılar, talepler, maskeleme kuralları ve denetim günlükleri takım sınırını asla aşmaz.

Denetim günlüğü Auditor ve Admin’e ayrılmıştır; DBA’in erişimi yoktur.

Kullanıcıları askıya alma ve silme

Bir Admin, Users ekranında bir kullanıcıyı askıya alabilir. Askıdaki kullanıcı oturum açamaz, açık oturumlar sona erer ve Slack ile Teams kimlikleri çalışmaz olur; bekleyen talepleri yerinde kalır ve normal kurallarla karara bağlanır. Resume erişimi geri verir. Bir kullanıcıyı silmek aynı etkiyle bir soft delete’tir ve ayrıca onun pending taleplerini iptal eder (system aktörüyle request.cancelled olarak denetlenir); onaylanmış ve kuyruğa alınmış taleplere dokunulmaz. Talep geçmişi korunur: foreign key’ler hard delete’i reddeder ve silinmiş bir kullanıcının e-posta adresi rezerve kalır. Kimse kendi hesabını askıya alamaz ya da silemez.

Bağlantılar ve tanımlamalar

DBA’ler hedef veritabanlarını Connections altında kaydeder. Kimlik bilgileri (host, port, veritabanı, kullanıcı adı, parola) AES-256 ile şifreli saklanır. Parola kaydedildikten sonra bir daha gösterilmez — düzenleme formu onu boş bırakır, boş bırakmak da kayıtlı parolayı korur. Kimlik bilgileri günlüklere veya hata mesajlarına da düşmez.

Bir geliştirici, bir bağlantıyı ancak DBA kendisine tanımladıktan sonra görür (Connections → Grants). Tanımlanmamış bağlantılar Query Studio’da görünmez.

Süreli tanımlamalar ve erişim talepleri

Bir tanımlama, biri elle kaldırana kadar değil, belirli bir süre için de geçerli olabilir. DBA bir bağlantıyı tanımlarken (Connections → Grants) şunları ayarlar:

• erişim düzeyi: write (varsayılan) ya da read. read tanımlaması, SQL guard’ın yazma ya da DDL saydığı bir talebi açamaz; Query Studio 403 döner.
• süre: kalıcı (varsayılan) ya da bir zaman aralığı. Erişim süre dolduğu anda biter.
• isteğe bağlı bir gerekçe.

Panel her geliştiricinin düzeyini ve kalan süreyi gösterir; DBA tanımlamayı değiştirebilir ya da geri alabilir. Mevcut tanımlamalar tam erişimle kalıcı kalır. connections:expire-grants adlı zamanlanmış görev her dakika çalışır, süresi dolan satırları siler ve denetim günlüğüne grant.expired yazar; bu yüzden kayıt, erişimin gerçekte bittiği andan biraz sonra yazılabilir. Tanımlama bittiğinde zaten pending ya da approved olan talepler iptal edilmez; tanımlama yalnızca talep gönderme hakkı verir, her talebin kendi onayı yine gerekir.

Erişim isteme. Geliştirici panoda kendi takımının bir bağlantısına erişim isteyebilir: düzeyi, bir süreyi (1 saat, 4 saat, 1 gün, 7 gün ya da en fazla 30 günlük özel bir süre) seçer ve zorunlu olan gerekçeyi yazar. Talep, DBA’in Approvals sayfasındaki Access requests sekmesinde görünür; DBA onaylar ya da gerekçe yazarak reddeder. Tanımlama onaylandığı anda başlar. Süreli tanımlaması olan geliştirici düzeyini ve kalan süreyi görür, süreyi uzatmak için talep açabilir.

Onayın erişimi yanlışlıkla genişletmesini önleyen kurallar:

• Kimse kendi talebine karar vermez; talep açıkken DBA olan talep sahibi de.
• Talep, yürürlükteki tanımlamayla uyuşmalıdır. Yürürlükteki tanımlamadan farklı bir düzey için ya da o düzeyde kalıcı bir tanımlama varken herhangi bir düzey için açılan talep, hem açılırken hem onaylanırken reddedilir. Var olan bir tanımlamayı değiştirmek için DBA onu Connections sayfasında düzenler.
• Aynı düzeydeki bir onay süreli tanımlamayı yalnızca uzatır. Onu asla kısaltmaz ve kalıcı yapmaz.

DBA’ler uygulamada ve takımın Slack ya da Teams kanalında bilgilendirilir (serbest metin gerekçe olmadan); talep sahibine karar ve yürürlükteki tanımlama bildirilir. Denetim olayları grant.requested, grant.approved, grant.rejected ve grant.expired’dır. Elle geri alma yine connection.grant_revoked kaydeder; connection.grant_added artık erişim düzeyini, bitiş zamanını ve gerekçeyi taşır.

Talebin yaşam döngüsü

pending ──▶ approved ──▶ queued ──▶ running ──▶ completed
   │                                              │
   ├──▶ rejected  (gerekçe zorunlu)               └──▶ failed
   └──▶ cancelled (talep sahibi ya da admin)

• Gönderim. Geliştirici Query Studio’da SQL yazar. SQL korumaları gönderimden önce doğrular — kural ihlal eden talep kuyruğa hiç girmez.
• Bekleme. Talep, biri karar verene kadar süresiz bekler; otomatik zaman aşımı yoktur. Takım DBA’leri portalda ve yapılandırıldıysa Slack / Teams üzerinden bilgilendirilir. QUERYPROXY_PENDING_REMIND_AFTER saat sonra (varsayılan 4; 0 kapatır) takımın DBA’leri ve yöneticileri bir hatırlatma alır ve sohbet kartı yeni bir aksiyon token’ıyla yeniden yayınlanır. Talep sahibi gönderirken isteğe bağlı bir not ekleyebilir; DBA’ler onu talebiyle birlikte görür.
• Hassas filtre rozeti. Bir talep, takımın bir kolon kuralıyla maskelediği bir kolona göre filtrelediğinde (WHERE, JOIN, HAVING, GROUP BY, ORDER BY), onay ekranı ve talep detayı kolon adlarını içeren bir rozet gösterir. Maskeli bir kolon, sorgu adayları sınadığında yine de çıkarım yoluyla bir değeri sızdırabilir; bu yüzden onaylamadan önce ona bakın. Yalnızca kolon adlarını gösterir. Kolon takma adlarını ya da türetilmiş tabloları çözmez, regex ve validator kurallarını yok sayar; yükseltmeden önce gönderilmiş talepler rozet taşımaz.
• Onay / Red. Takımın herhangi bir DBA’i karar verebilir — kendi talepleri hariç: kendine onay engellidir. Admin’ler bu engeli aşabilir; aşım denetim günlüğünde işaretlenir. Red için yazılı gerekçe zorunludur. Aşım için her kanalda yazılı bir gerekçe (en fazla 1000 karakter) gerekir; o da denetim günlüğüne kaydedilir. Karar sohbetten geliyorsa aynı kurallara ek olarak iki koşul daha aranır: kontrolün taşıdığı tek kullanımlık aksiyon token’ı (o tek talebe bağlı, 24 saat ömürlü) geçerli olmalı ve çözülen onaylayan entegrasyonun takımına üye olmalıdır. REST API aynı kuralları izler; tek fark aşımı hiç kabul etmemesidir: web formuna bir bağlantıyla 403 döner.
• Çalıştırma. Onaylanan talepler kuyruğa girer ve işçi tarafından alınır. Okumalar veritabanı cursor’ı üzerinden sonuç dosyasına akar; her satıra yazılmadan önce maskeleme uygulanır. Yazmalar etkilenen satır sayısını raporlar; çok ifadeli talepler atomik çalışır ve herhangi bir ifade başarısız olursa tamamı geri alınır. Okumalar hedef veritabanında salt okunur bir oturumda, bir ifade ve bir kilit zaman aşımıyla çalışır (bkz. Yapılandırma). Bir bağlantıda aynı anda en fazla QUERYPROXY_CONNECTION_SLOTS talep (varsayılan 2) çalışır; diğerleri bir yuva boşalana kadar queued kalır.
• Durdurma. Talep sahibi, takımın DBA’leri ve yöneticiler, veritabanı oturumu bilinen running bir talepte Stop query’ye basabilir (SQLite’ta değil). Veritabanı ifadeyi iptal eder ve geri alabildiğini geri alır; zaten commit edilmiş değişiklikler kalır. Talep cancelled olur ve denetim günlüğü execution.cancelled kaydeder. SQL Server bunun için ek yetki ister; bkz. Yapılandırma.
• Sonuçlar. Talep sahibi (ve takımın DBA’leri) sonuçları sayfa sayfa görüntüleyebilir ya da CSV indirebilir. Denetçiler talep meta verisini, geçmişi ve onay izlerini görür — sonuç verisinin kendisini değil. Sonuç dosyaları yapılandırılan saklama süresi sonunda otomatik silinir.

Bildirimler

Talep sahipleri, talepleri karara bağlandığında ve çalıştırma bittiğinde; DBA’ler yeni gönderimlerde bilgilendirilir. Bildirimler portalın zil menüsünde görünür. Yeni gönderimler ve kararlar, sohbet kanalı yapılandırıldıysa orada da duyurulur; çalıştırma-bitti bildirimi yalnızca portalda talep sahibine gider, Slack’e ya da Teams’e gönderilmez.

E-posta. Her kullanıcı Profile sayfasında hangi olayların e-postayla da gelmesini istediğini seçer: inceleme bekleyen talep, kendi talebine verilen karar, biten, başarısız olan ya da durdurulan talep, bekleyen talep hatırlatması, bir DBA’i bekleyen erişim talebi ve erişim talebine verilen karar. Hepsi varsayılan olarak kapalıdır. E-posta sorgu sonucu, onaylayanın gerekçesi, karar notu ya da hata mesajı taşımaz; içindeki SQL’in değerleri gizlidir. E-postadaki bağlantılar talebi QueryProxy’de açar ve açık bir oturum ister; e-postadan hiçbir şey onaylanmaz. E-posta kuyruktan gönderilir, yani işçinin çalışması gerekir; e-posta hatası talebi hiçbir zaman engellemez. MAIL_MAILER=log iken hiçbir şey teslim edilmez ve Profile sayfası bunu söyler.

Denetim izi

Yukarıdaki her adım bir denetim kaydı yazar: gönderim, karar (kanal ve aşım işaretiyle), çalıştırma başlangıcı/bitişi (süre ve etkilenen satırlarla), sonuç indirmeleri; ayrıca girişler, tanımlamalar ve yapılandırma değişiklikleri. Denetim kayıtları değiştirilemez — model katmanı ve veritabanı trigger’ları güncelleme ve silmeyi reddeder, kayıtlar da php artisan audit:verify’ın denetlediği bir hash zinciri oluşturur. Denetçiler izi filtreleyebilir ve CSV olarak dışa aktarabilir. Denetim ekranı ve CSV, SQL’i literalleri redakte edilmiş (sql_redacted) gösterir, ham ifadeyi asla göstermez. Olaylar bir SIEM’e de aktarılabilir: bkz. Denetim zinciri ve SIEM aktarımı.

Kayıtlar istemci IP’sini QueryProxy’nin gördüğü hâliyle tutar. Bir ters vekil arkasında bu, vekili TRUSTED_PROXIES’e yazmadıkça vekilin kendi adresidir — bkz. Yapılandırma.