Çoğu kişi yetki yönetimini bir güven meselesi sanır. "Ekipteki herkese güveniyorum, ayrı ayrı rol tanımlamaya ne gerek var" der ve tek bir admin hesabının şifresini üç kişiye verir. Oysa yetkilendirmenin asıl sebebi güvensizlik değil; izlenebilirlik ve hata sınırlama. Kimin ne yaptığını bilemediğin bir sistemde en küçük karışıklık bile saatlerce süren bir tartışmaya dönüşür ve kimse kötü niyetli olmasa da para kaybolur.
Asıl sorun şu: e-pin işinde admin panelinde yapılan tek bir tıklama gerçek paraya dokunur. Fiyat değiştirmek, stok yüklemek, cüzdana bakiye eklemek, siparişi manuel "teslim edildi" işaretlemek... Bunların hepsi geri alınması zor işlemler. Tek hesapla çalışan bir işletmede bu işlemlerin hiçbiri kimseye bağlanamaz. Bu yazıda büyüyen satıcıların kurduğu rol mimarisini, hangi iznin kime asla verilmemesi gerektiğini ve kullandığın e-pin scripti tarafında neye bakacağını anlatıyorum.
Tek admin hesabı seni tam olarak nerede yakıyor?
Üç noktada. Birincisi olay anı: bir müşterinin cüzdanına yanlış bakiye yüklendiğinde, paylaşılan hesapla çalışıyorsan bunu kimin yaptığını bulamazsın ve düzeltmek yerine kimin suçlu olduğunu tartışırsın. İkincisi ayrılık anı: ekipten biri işten çıktığında şifreyi değiştirmek zorundasın, bu da geri kalan herkesin işini kesintiye uğratır ve genelde erteleyip unutulur. Üçüncüsü güvenlik olayı: tek hesabın oturumu ele geçirildiğinde saldırganın elinde tüm panel olur, sadece bir bölüm değil.
Bir de görünmeyen maliyet var: eğitim. Destek personelini tüm panele bakabilecek şekilde bıraktığında yeni kişi nereye dokunacağını bilemez, yanlış menüye girer, ödü patlar ve iş yavaşlar. Dar yetki aslında personeli koruyan bir şeydir; ona "senin alanın burası" der ve hızını artırır. İyi bir dijital ürün satış yazılımı bu yüzden rol bazlı menü gizleme yapar, sadece tıklamayı engellemekle kalmaz.
Hangi rolleri kurmalısın ve sınırları nerede çizilir?
Pratikte beş rol çoğu işletmeye yeter. Sahip: her şeye erişir, yetki dağıtır, ödeme sağlayıcı ayarlarına dokunur; tek kişi olmalı, mümkünse ikincisi acil durum için kilitli dursun. Operasyon yöneticisi: ürün, fiyat, stok, tedarikçi ve kampanya yönetir; ödeme ayarına ve yetki dağıtımına dokunamaz. Destek personeli: siparişleri görür, kodu yeniden gönderir, talep açar ve kapatır; fiyat değiştiremez, cüzdana para yükleyemez. Muhasebe: rapor ve mutabakat görür, hiçbir şeyi değiştiremez. Teknik: entegrasyon ve log erişimi vardır, müşteri verisinde toplu işlem yapamaz.
Sınırın çizildiği yer tek bir soruyla bulunur: bu işlem yanlış yapıldığında para mı kaybediyoruz, itibar mı, yoksa sadece zaman mı? Para kaybettiren işlemler dar tutulur ve çift onaya bağlanır. Zaman kaybettiren işlemler cömertçe dağıtılır. Bu ayrımı yapmayan işletmeler ya herkesi kilitler ve operasyon tıkanır, ya herkesi açar ve sürpriz yaşar.
| Yetki | Sahip | Operasyon | Destek | Muhasebe |
|---|---|---|---|---|
| Ödeme sağlayıcı ayarları | Var | Yok | Yok | Yok |
| Kullanıcı yetkisi dağıtma | Var | Yok | Yok | Yok |
| Cüzdana manuel bakiye | Var | Onaylı | Yok | Yok |
| Fiyat ve kâr marjı | Var | Var | Yok | Yok |
| Stok yükleme / silme | Var | Var | Yok | Yok |
| Sipariş görüntüleme | Var | Var | Var | Var |
| Kodu yeniden gönderme | Var | Var | Var | Yok |
| Manuel teslim işaretleme | Var | Var | Onaylı | Yok |
| Rapor ve mutabakat | Var | Var | Kısmi | Var |
| Veri dışa aktarma | Var | Kısmi | Yok | Var |
Asla devretmemen gereken üç izin hangisi?
Birincisi yetki dağıtma izni. Bunu verdiğin kişi, kendisine istediği her yetkiyi verebilir; yani aslında ona tüm paneli vermiş olursun. Bu izin sahiplik demektir, adı farklı olsa bile. İkincisi ödeme ve tahsilat ayarları. Sağlayıcı anahtarlarının, hesap numaralarının ve komisyon eşiklerinin olduğu ekran doğrudan nakit akışına dokunur; burada yapılan sessiz bir değişiklik haftalar sonra fark edilir.
Üçüncüsü log silme ve geçmişi düzenleme. Bu izin hiç kimsede olmamalı, sahipte bile. Çünkü kayıtların değiştirilebildiği bir sistemde kayıtların hiçbir anlamı kalmaz; ne bankaya karşı, ne tedarikçiye karşı, ne kendi ekibine karşı. Bir e-pin satış scripti değerlendirirken bak: işlem geçmişi gerçekten yalnızca eklenebilir mi, yoksa panelden "temizle" düğmesiyle uçuyor mu? Bu tek soru, altyapının ciddiyetini ölçer.
Epin sitelerinde yönetim kaynaklı kayıpların dağılımı
- Yanlış fiyat / marj girişi 44%
- Hatalı manuel bakiye ve teslim 26%
- Yetkisiz veri dışa aktarma 18%
- Ayrılan personelin açık erişimi 12%
Log tutmak yetmez: kaydın "kullanılabilir" olması ne demek?
Pek çok panel log tutar ama o log işe yaramaz. Kullanılabilir bir yönetim kaydında beş alan olmalı: kim, ne zaman, hangi kayıtta, neyi neye çevirdi ve hangi IP'den. Özellikle dördüncüsü kritik: "fiyat güncellendi" yazan bir satır hiçbir soruyu cevaplamaz, "fiyat 250'den 25'e çevrildi" yazan satır ise hatayı bir bakışta gösterir. Eski ve yeni değeri saklamayan log, log değil gürültüdür.
İkinci şart aranabilirlik. Kayıtları kullanıcıya, tarihe ve işlem tipine göre filtreleyemiyorsan, olay anında binlerce satırı gözle tarayamazsın. Üçüncü şart bildirim: kritik işlemler gerçekleştiğinde sahibe anlık haber gitmeli. Fiyat marjının belirli bir yüzdenin altına inmesi, tek seferde büyük bakiye yüklemesi, gece saatlerinde toplu dışa aktarma... Bunlar sabah raporunda değil, olduğu anda bilinmesi gereken şeyler.
Panel yolunu tahmin edilemez yapmak ve tüm yönetici hesaplarında iki adımlı doğrulamayı zorunlu kılmak, yetki mimarisinin temel şartıdır; rol tanımları ancak giriş kapısı sağlamsa anlam kazanır.
Büyürken yetki mimarisi nasıl bozulur, nasıl korunur?
Bozulma her zaman aynı şekilde olur: acil bir iş çıkar, birine geçici olarak geniş yetki verilir ve o yetki hiç geri alınmaz. Altı ay sonra bakarsın ki destek ekibinin yarısı fiyat değiştirebiliyor. Bunun adı yetki kaymasıdır ve tek çözümü takvime bağlı gözden geçirmedir. Üç ayda bir kullanıcı listesini aç, her satır için tek soruyu sor: bu kişi bu yetkiyi son doksan günde kullandı mı? Cevap hayırsa kaldır.
İkinci koruma önlemi, yetkiyi kişiye değil role bağlamak. Yeni bir destek personeli geldiğinde "şuna benzeyen yetkiler" verme; hazır role ata. Böylece rol değiştiğinde herkes birlikte değişir ve kimse tekil bir istisna olarak kalmaz. Üçüncüsü ise ayrılma prosedürü: hesap silinmez, devre dışı bırakılır. Çünkü geçmiş logların o kullanıcıya bağlı kalması gerekir; hesabı silersen tarihin bir kısmını da silersin. Özellikler listesinde bu "askıya al" davranışının olup olmaması, aslında yazılımın ne kadar ciddi düşünüldüğünü gösterir.
| Kurulum kontrolü | Neden önemli | Tamam ölçütü |
|---|---|---|
| Rol bazlı menü gizleme | Personel yanlış ekrana hiç girmez | Yetkisiz menü görünmüyor |
| İki adımlı doğrulama | Şifre sızıntısı tek başına yetmez | Tüm yönetici hesaplarında zorunlu |
| Eski/yeni değer logu | Hatanın boyutu anında görülür | Her değişiklikte iki değer kayıtlı |
| Kritik işlem bildirimi | Kayıp aynı gün fark edilir | Bakiye ve fiyat eşiklerinde anlık uyarı |
| Çift onay akışı | Tek kişilik hata zinciri kırılır | Yüksek tutarlı işlemlerde ikinci onay |
| Oturum süresi sınırı | Açık kalan panel riski azalır | Belirli süre sonra otomatik çıkış |
| IP kısıtı seçeneği | Ofis dışı erişim kontrol edilir | Rol bazlı IP beyaz listesi mümkün |
| Hesap askıya alma | Geçmiş loglar korunur | Silme yerine devre dışı bırakma var |
Yetki mimarisini büyümeden önce kur
Rol bazlı erişim, eski/yeni değer logu, çift onay ve askıya alma davranışı hazır gelen bir altyapıda ekibini büyütmek çok daha az risk taşır.
Kaç yönetici hesabı açmalıyım?
Kişi sayısı kadar. Paylaşılan hesap en kısa vadede kolay görünse de olay anında kimin ne yaptığını bulmayı imkânsız kılar. Her personelin kendi hesabı olsun, yetkiler role bağlansın ve şifre paylaşımı kesinlikle yasaklansın.
Destek personeline cüzdan yetkisi verilir mi?
Doğrudan verilmemesi en doğrusu. Destek, kod yeniden gönderme ve talep yönetimi gibi geri alınabilir işlemleri yapabilir; bakiye yükleme gibi doğrudan paraya dokunan işlemler ya yönetici onayına ya da düşük bir tutar sınırına bağlanmalıdır.
Yönetim panelinin adresini gizlemek gerçekten işe yarar mı?
Tek başına güvenlik sağlamaz ama otomatik tarama ve kaba kuvvet denemelerinin büyük kısmını keser. Tahmin edilemez bir yol, iki adımlı doğrulama ve deneme sınırı birlikte kullanıldığında giriş kapısı ciddi biçimde sağlamlaşır.
Ekipten ayrılan kişinin hesabını silmeli miyim?
Silme, askıya al. Hesabı silersen o kullanıcıya bağlı geçmiş yönetim kayıtları anlamsızlaşır ve ileride bir mutabakat tartışmasında elin boş kalır. Erişimi kes, oturumları düşür, yetkileri sıfırla ama kaydı koru.
Yetki mimarisi, epin işinde büyümenin sessiz altyapısıdır: doğru kurulduğunda ekibini rahatça genişletirsin, kurulmadığında her yeni kişi yeni bir risk olur. Rol matrisini, işlem geçmişini ve çift onay akışını gerçek bir panelde görmek istersen canlı demo üzerinden yönetici kullanıcıları ve log ekranını incele; fiyat tarafında da ekip büyüklüğüne uygun kurulumu seçmek böylece tahmine değil ihtiyaca dayanır.