# Onay akışı

> Roller, bağlantı tanımlamaları ve bir sorgu talebinin gönderimden onaya, maskelenmiş ve denetlenmiş sonuca uzanan yaşam döngüsü.

- Dokümantasyon: Kılavuzlar
- Güncelleme: 2026-10-10
- Kaynak: https://queryproxy.com/tr/docs/onay-akisi/
- Dil: tr-TR
- Yazar: Muhammet Şafak

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

| Rol | Yetkileri |
| :-- | :-- |
| **Admin** | Sistem genelinde her şey: takımlar, kullanıcılar, tüm ayarlar. Kullanıcı bazında verilir (`is_admin`). |
| **DBA** | Bağlantıları ve maskeleme kurallarını yönetir, erişim tanımlar, talepleri onaylar/reddeder; takımın her bağlantısına sorgu da gönderebilir. |
| **Developer** | Tanımlanmış bağlantılar üzerinden sorgu gönderir, kendi (maskelenmiş) sonuçlarını görür. |
| **Auditor** | Denetim günlüğüne (ve CSV dışa aktarımına) ve takımın Talepler listesi ile talep detayına (SQL, durum, talep sahibi, onaylayan, onay izi, DDL işareti) salt-okunur erişim; sonuç satırlarını görüntüleyemez ve indiremez; bağlantılara, onaylara, maskelemeye ve ChatOps ayarlarına erişimi yoktur. |

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'nin erişimi yoktur.

## 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; diğer alanlar formda dolu
gelir. 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.

## 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ı](/tr/docs/sql-korumalari/) 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](/tr/docs/slack-entegrasyonu/) / [Teams](/tr/docs/teams-entegrasyonu/)
  üzerinden bilgilendirilir.
- **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. 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.
- **Ç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](/tr/docs/veri-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.
- **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.

## 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ı güncelleme ve silmeyi reddeder.
Denetçiler izi filtreleyebilir ve CSV olarak dışa aktarabilir.

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](/tr/docs/yapilandirma/).