Düğmeye tek başına güvenilmiyorsa, üretim SQL’ini Slack ya da Teams’ten güvenle onaylayabilirsiniz. Bir tıklama yalnızca bir HTTP callback’idir; bu yüzden güvenlik, sunucunun harekete geçmeden önce neyi kontrol ettiğindedir: kim imzaladı, ne kadar eski, gerçek bir mesaja mı cevap veriyor ve hangi kişiyle eşleşiyor. Sohbet onayları çoğunlukla burada yanlış gider ve QueryProxy’nin emeği burada harcanır.
Neden sohbette onaylansın ki?
Çünkü kimsenin açmadığı bir kuyruk, tıkanan bir kuyruktur. Bir DBA zaten sohbette yaşar; bu yüzden istek, talep eden, bağlantı ve SQL önizlemesiyle birlikte bulunduğu yere gelir ve oracıkta karar verir. Onay akışı her iki yolda da aynıdır; sohbet yalnızca kararın nerede alındığını değiştirir.
Bir sohbet düğmesinde ne ters gidebilir?
- Sahtecilik. Callback URL’sini bulan herkes ona gönderim yapabilir.
- Tekrar oynatma. Ele geçirilmiş gerçek bir onayın daha sonra yeniden gönderilmesi.
- Yanlış kişi. Geçerli bir imza, çağıranın bir sırra sahip olduğunu söyler. Belirli bir kişinin tıkladığını söylemez.
- Bayat bir mesaj. Birinin eski bir karttan bir isteğe iki kez karar vermesi.
QueryProxy’de Slack onayı nasıl çalışır?
Yeni istekler bir kanalda Approve, Reject ve Open in QueryProxy düğmeleriyle duyurulur ve karardan sonra mesaj güncellenir, böylece düğmeler kaybolur. Kurulum Slack entegrasyonu rehberindedir. Her callback, herhangi bir şey olmadan önce doğrulanır:
- İmza.
X-Slack-Signaturebaşlığı, zaman damgasının ve ham gövdenin, uygulamanın signing secret’ı ile imzalanmış HMAC-SHA256 değeriyle eşleşmelidir. Slack bu şemayı,v0=öneki dahil, Slack’ten gelen isteklerin doğrulanması rehberinde anlatır. (2026-10-13’te okundu.) - Tekrar penceresi. Slack’in rehberi, zaman damgası yerel saatten beş dakikadan fazla farklı olan isteği reddetmenizi söyler; QueryProxy artı eksi beş dakika dışındaki istekleri reddeder. (2026-10-13’te okundu.)
- Tek kullanımlık token. Her düğme tek bir isteğe bağlı, 24 saat geçerli bir token taşır ve kaydedilen ilk kararda harcanır. Yetkilendirme tarafından geri çevrilen bir tıklama onu tüketmez.
- Kimlik. Slack kullanıcısı, isteğin takımında DBA rolü olan bir QueryProxy kullanıcısıyla eşlenmiş olmalıdır. Bir yönetici her gözden geçirenin Slack üye kimliğini doldurur; bir tıklamayı bir kişiye bağlayan şey budur.
- Kurallar. Kendi talebini onaylama yok, web’deki gibi.
Sahte ya da süresi dolmuş bir callback reddedilir ve hiçbir durumu değiştirmez.
Sır neden yalnızca yöneticiye ait?
Bir HMAC’in neyi söyleyip neyi söyleyemeyeceği yüzünden. Rehber bu konuda açık sözlüdür: çağıranın sırrı bildiğini kanıtlar, belirli bir kişinin onay verdiğini asla. Bir DBA sırrı seçebilseydi, bir meslektaşı adına kendi talebini onaylayan bir callback imzalayabilirdi ve kayıt meslektaşı yazardı. Bu yüzden sırrı yalnızca bir sistem yöneticisi belirleyebilir ya da döndürebilir ve döndürmek mevcut olanı ister.
Peki Microsoft Teams?
Teams farklı çalışır ve bunu açık söylemekte fayda var. QueryProxy her yeni istek için Review in QueryProxy bağlantılı bir kart gönderir ve kararları kanala geri duyurur. Teams’ten onay, otomasyonunuzun, örneğin bir Power Automate akışının ya da giden bir webhook’un, HMAC ile imzalı bir istekle çağırdığı bir aksiyon endpoint’i üzerinden gerçekleşir. Onaylayan, bir yöneticinin bir kullanıcıya bağladığı Azure AD nesne kimliğiyle belirlenir. Slack’tekine benzer tam etkileşimli kart düğmeleri bir Teams bot kaydı ister ve yol haritasındadır.
Bugün Teams’te tıkla-onayla akışı istiyorsanız, onu otomasyonunuzda kurarsınız. İstemiyorsanız web’den onaylayın.
Kayıt sohbet kararlarını tutuyor mu?
Evet: bir karar kanalıyla birlikte denetim günlüğüne yazılır; böylece bir gözden geçiren web onayını Slack onayından ayırt edebilir. Bunun kanıta nasıl eşlendiği için üretim sorguları için denetim kaydı neleri tutmalı yazısına ve SOC 2 sayfasına bakın.
Sınırlar neler?
Slack’ten yapılan bir ret yalnızca genel bir gerekçe kaydeder; önemli olduğunda
gerekçeyi web arayüzünde yazın. Karttaki SQL önizlemesi 400 karakterde kesilir
ve sohbet geçmişi ifadelerin düşmesini istediğiniz bir yer değilse
QUERYPROXY_CHAT_INCLUDE_SQL=false ile kapatabilirsiniz. Tek kullanımlık
token’lar getirilmeden önce gönderilmiş mesajlardaki düğmeler artık çalışmaz.
Sık sorulanlar
- Slack'ten bir SQL sorgusunu onaylayabilir misiniz?
- Evet. QueryProxy her yeni isteği, Approve, Reject ve Open in QueryProxy aksiyonlarıyla bir kanala gönderir. Bir tıklama doğrulanır, o takımda DBA rolü olan bir QueryProxy kullanıcısıyla eşlenir ve kendi talebini onaylama yasağı dahil web ile aynı kurallara tabidir.
- Teams'te onay düğmeleri var mı?
- Etkileşimli kart düğmeleri olarak henüz yok; bunlar bir Teams bot kaydı ister ve yol haritasında. Bugün QueryProxy, Review in QueryProxy bağlantısıyla bir kart gönderir ve bir Power Automate akışının ya da giden webhook'un çağırabileceği, HMAC ile imzalı bir aksiyon endpoint'i sunar.
- Sahte ya da tekrar oynatılmış bir onayı ne engeller?
- Her callback için geçerli bir HMAC imzası ve beş dakika içinde bir zaman damgası aranır. Her Approve ya da Reject tıklaması ayrıca tek kullanımlık, 24 saat geçerli ve tek bir isteğe bağlı bir token taşır; böylece ele geçirilmiş bir çağrı tekrar oynatılamaz ve sır tek başına bir karar üretemez.
- Sohbet onayı bir kendi kendine onay olabilir mi?
- Normal gözden geçirenler için hayır. Web ile aynı kural geçerlidir ve onaylayanın isteğin takımında DBA rolü olmalıdır. Bir sistem yöneticisi hem DBA rolü kuralını hem de kendi talebini onaylama engelini geçersiz kılabilir; bunu yapan bir onay denetim günlüğünde işaretlenir.
- Her onay sohbette mi yapılmalı?
- Hayır. Sohbet rutin değişiklikler için rahattır. Yazılı bir gerekçe isteyen bir talep için web arayüzünü kullanın, çünkü Slack'ten yapılan bir ret yalnızca genel bir gerekçe kaydeder.