Panelde Tek Başına Yetkili Olman Güvenlik Değil, Açık Kapı: E-pin Satış Scriptinde Admin İşlemlerini İkinci Onaya Bağlayan Mekanizmanın İçyüzü

Çoğu e-pin satıcısı güvenliği "dışarıdan gelen saldırı" olarak düşünür. Güçlü şifre, iki adımlı doğrulama, güvenlik duvarı, gizli admin yolu. Bunların hepsi gerekli. Ama işletmelerin gerçekten büyük para kaybettiği olayların çoğu dışarıdan değil, içeriden ve yetkili bir oturumdan geçerek olur. Bakiye elle yükseltilir, indirim oranı bir gecelik değiştirilir, stok fiyatı sıfıra çekilir, sipariş "teslim edildi" işaretlenir, kullanıcı hesabı silinir. Sistem hiçbirinde hata vermez, çünkü hepsi yetkili işlemdir.

Buradaki sorun kötü niyet varsayımı değil. Sorun şu: tek bir tıklamayla geri alınamaz sonuç üretebilen bir panel, yalnızca o tıklayan kişi kadar güvenlidir. O kişi sen olsan bile yorgun, aceleci veya oturumu ele geçirilmiş olabilirsin. Olgun bir e-pin satış scripti bu yüzden yetkiyi tek adımda değil, kritik işlemlerde iki adımda kullandırır: işlem talep edilir, kuyruğa girer, ikinci bir yetkili onaylar, sonra uygulanır. Bu yazı o mekanizmanın nasıl tasarlanacağını, hangi işlemlerin kapsama girmesi gerektiğini ve küçük ekiplerde nasıl uygulanabilir hale getirileceğini anlatıyor.

Rol yetkisi neden yeterli bir cevap değil?

Rol tabanlı yetkilendirme "kim yapabilir" sorusunu cevaplar; "bu kez yapılmalı mı" sorusunu cevaplamaz. Destek personeline bakiye düzeltme yetkisi verirsin, çünkü iadeler için gerekli. Bu yetki verildiği anda, o personel 50 TL yerine 50.000 TL yazma imkânına da kavuşur. Rolü daraltırsan işi yapamaz, genişletirsen risk açarsın. Çıkış yolu yetkiyi daraltmak değil, yetkinin eşik üstünde ikinci imza istemesi. Yani destek 500 TL'ye kadar tek başına düzeltme yapar, üstünde talep oluşturur ve yönetici onaylar. Aynı mantık indirimde, stok fiyatında, toplu teslimde ve para çıkışında geçerlidir. Bu yapı hem işi akıtır hem tavanı kapatır. Teknik karşılığı da sade: kritik işlemler doğrudan tabloya yazmaz, bekleyen işlem kaydı üretir; uygulama yalnızca onay sonrası çalışan tek bir noktadan geçer. Böyle kurulmuş bir dijital ürün satış scripti hem denetlenebilir hem de tek noktadan değiştirilebilir olur.

Hangi işlemler mutlaka ikinci imza istemeli?

Kapsamı geniş tutmak akıllıca görünür ama pratikte ekibi kilitler ve onaylar rutin tıklamaya dönüşür. Doğru ölçüt şu üç sorudur: işlem geri alınabilir mi, doğrudan para veya kod hareketi yaratıyor mu, tek seferde çok kaydı etkiliyor mu? Üçünden en az birine "evet" diyorsan kapsama girer. Aşağıdaki tablo, sahada en çok soruna yol açan işlemleri, önerilen eşiği ve onay sonrası uygulanma biçimini veriyor.

Tek kişilik işletmede ikili onay nasıl olur?

Haklı bir itiraz: ekip sen ve bir kişiyseniz, ikinci imzayı kim atacak? Cevap, onayı kişi sayısına değil kanal ve zamana bağlamaktır. İkinci faktör bir insan olmak zorunda değil; ayrı bir kanaldan gelen doğrulama da olabilir. Kritik işlem talep edilir, kayıtlı Telegram veya e-posta kanalına özet ve tek kullanımlık onay bağlantısı gider, sen o kanaldan onaylarsın. Bu, oturumu ele geçirilmiş bir saldırganın tek başına işlemi tamamlamasını engeller, çünkü ikinci kanal onun elinde değildir. Buna bir de zaman gecikmesi eklenebilir: yüksek riskli işlemler onaylandıktan sonra bile 15 dakika bekleyip uygulanır ve bu sürede iptal edilebilir. Bu iki basit ekleme, tek kişilik bir e-pin yazılımı kurulumunu bile içeriden gelen tek tıklama riskine karşı ciddi biçimde sağlamlaştırır.

Denetim izi olmadan onay mekanizması neden çöker?

Onay akışının değeri, sonradan okunabilmesinden gelir. "Bu 12.000 TL bakiyeyi kim istedi, kim onayladı, hangi gerekçeyle?" sorusunun cevabı tek bir satırda durmuyorsa, mekanizma tören olur. Denetim izinin üç özelliği olmalı: eksiksiz olmalı, yani talep, onay, red ve uygulama ayrı ayrı kaydedilmeli; bağlamlı olmalı, yani eski ve yeni değer birlikte tutulmalı; ve silinemez olmalı, yani panel üzerinden hiçbir yetki bu kayıtları değiştirememeli. Silinebilir bir log, saldırganın ilk temizlediği yerdir. Pratik çözüm, denetim kayıtlarını yalnızca ekleme yapılabilen bir tabloda tutmak ve gün sonunda ayrı bir yere kopyalamaktır. Böylece bir anlaşmazlıkta elinde yorum değil kanıt olur.

Bu akışı kurarken nelere dikkat edeceksin?

Onay mekanizmasının en büyük düşmanı bürokrasi hissidir. Ekip onayı engel olarak görürse etrafından dolaşmanın yolunu bulur: eşiğin altında bölerek işlem yapar, birbirine körü körüne onay verir, ya da paneli hiç kullanmayıp doğrudan veritabanına girer. Bunu önlemenin yolu akışı hızlı, görünür ve anlamlı tutmaktır. Aşağıdaki liste kurulum sırasında kontrol etmen gereken maddeleri veriyor.

Hazır bir sistemde bu nasıl geliyor?

Onay kuyruğunu sonradan eklemek, panelin kritik işlem yapan her ekranına dokunmak anlamına gelir; bu da en çok atlanan ve en çok hata üreten iş kalemidir. Pinova bu yapıyı baştan kurulu veriyor: eşik tanımlı kritik işlem listesi, bekleyen işlem kuyruğu, kendi talebini onaylama engeli, kayıtlı kanal bildirimi, gecikmeli uygulama ve yalnızca eklenebilen denetim izi. Pinova e-pin satmaz; e-pin satan işletmelerin panelini disipline eden lisanslı e-pin satış yazılımı olarak çalışır. Hangi işlemlerin kapsama geldiğini özellikler bölümünde, sürüm farklarını fiyat sayfasında inceleyebilirsin.

Bir panelde tek başına her şeyi yapabiliyor olmak güç değil, açık risktir; disiplin, o gücü kritik anlarda ikinci bir kapıdan geçirmekle başlar. Bekleyen işlem kuyruğunun, fark ekranının ve denetim izinin gerçek bir panelde nasıl işlediğini görmek istersen canlı demo üzerinden örnek bir bakiye talebi oluşturup onay akışını baştan sona deneyebilir, ardından lisans adımına geçebilirsin.