Bir e-pin veya dijital ürün satış sisteminde en büyük tehdit çoğu zaman dışarıdan gelmez. Sistemin içinde, "güvenilir" sayılan bir personelin ya da bayinin elindeki fazla yetki, günün birinde şirkete dışarıdan gelecek herhangi bir saldırıdan daha pahalıya patlayabilir. Peki sizin e-pin scriptiniz kimin ne yapabileceğini gerçekten kontrol ediyor mu, yoksa herkes aynı kapıdan mı giriyor?
E-Pin Sisteminizde "Yetkisiz" Bir Admin Var mı?
Çoğu küçük ve orta ölçekli e-pin işletmesinde admin paneli tek bir kalıptan çıkar: ya tam yetki verilir ya da hiç erişim verilmez. Bu ikili yaklaşım, aradaki gri alanı gözden kaçırır. Örneğin sipariş onaylayan bir müşteri temsilcisinin aynı zamanda cüzdan bakiyesi ekleme yetkisine sahip olması, teoride "sadece siparişe bakıyor" dediğiniz kişinin pratikte kendi hesabına ya da bir tanıdığına bedava bakiye tanımlayabilmesi demektir.
İç tehdit, kötü niyetli bir çalışan kadar dikkatsiz bir yetkilendirme hatasından da doğar. Bir e-pin scriptinde en sık görülen aşırı-yetkilendirme örnekleri şunlardır:
- Destek personeline tanınan manuel bakiye/cüzdan düzenleme yetkisi
- Herkesin görebildiği sipariş durumu değiştirme ve iptal etme yetkisi
- Stok girişi yapan kişinin aynı anda ürün fiyatını da değiştirebilmesi
- Tüm müşteri verilerine (e-posta, telefon, sipariş geçmişi) sınırsız erişim
- Ödeme sağlayıcı panelinde manuel "ödeme onaylandı" işaretleme yetkisi
Bu maddelerin her biri tek başına makul görünebilir, ama üst üste geldiğinde tek bir hesabın sistemin tamamını manipüle edebilmesine yol açar. Sorunun kaynağı kötü niyet değil, çoğunlukla "zaten güveniyoruz" mantığıyla hiç sınırlandırılmamış bir yetki yapısıdır.
Kim, Neye, Ne Zaman Erişebilir? Yetki Matrisi Nasıl Kurulur
Rol tabanlı erişim kontrolü (RBAC), her kullanıcıya işini yapması için gereken en az yetkiyi verme ilkesine dayanır. Amaç güvensizlik değil, sorumluluğun net çizilmesidir. Sağlıklı bir e-pin scripti için tipik rol ayrımı şöyle kurulabilir:
- Süper Admin — sistem ayarları, ödeme entegrasyonları, kullanıcı/rol yönetimi
- Muhasebe — cüzdan hareketleri, fatura, ciro raporları (ürün/stok değiştiremez)
- Stok/Tedarik Sorumlusu — ürün, fiyat, tedarikçi API bağlantıları
- Destek/Müşteri Temsilcisi — sipariş görüntüleme, talep yanıtlama, sınırlı iade yetkisi
- Bayi Yöneticisi — kendi alt bayi ağını yönetir, sistem geneline erişemez
Kritik nokta, her rolün yalnızca ihtiyaç duyduğu ekranı ve işlemi görmesidir. Destek temsilcisinin API anahtarlarını görmesine, stok sorumlusunun kullanıcı silmesine gerek yoktur. Bu ayrım hem hata payını azaltır hem de bir hesap ele geçirildiğinde saldırganın erişebileceği alanı daralttığı için hasarı sınırlar.
Tek Şifre, Tüm Sistem: Süper Admin Tuzağı Neden Tehlikeli
Birçok işletme sahibi işe yeni başladığında tek bir admin hesabı açar ve zamanla bu hesabın şifresini tüm ekiple paylaşır. "Zaman kazandırıyor" gibi görünen bu alışkanlık aslında iki büyük risk taşır: birincisi, bir sorun çıktığında kimin ne yaptığını ayırt edemezsiniz; ikincisi, o tek şifre bir şekilde sızarsa (bir çalışanın kişisel cihazından, bir ekran görüntüsünden, hatta iş bırakan bir kişinin hafızasından) sisteminizin tamamı anında açık hale gelir.
Doğru yaklaşım, her ekip üyesine kendi adına açılmış, kendi rolüne bağlı, mümkünse iki faktörlü doğrulamayla korunan bireysel bir hesap tanımlamaktır. Bu sadece güvenlik değil, aynı zamanda hesap verebilirlik meselesidir.
| Yetkilendirme Konusu | Manuel / Elle | Pinova ile |
|---|---|---|
| Rol tanımlama | Kod içine elle yazılır, her değişiklik için geliştirici gerekir | Panelden rol oluşturma/düzenleme, kod bilgisi gerekmez |
| Personel hesabı | Tek ortak admin şifresi ekip içinde paylaşılır | Her personele ayrı kullanıcı adı + şifre, bireysel takip |
| Manuel bakiye yetkisi | Herkeste ya var ya yok, kademeli sınır tanımlanamaz | Role özel yetki + işlem limiti panelden belirlenir |
| İşlem kaydı | Kim ne yaptı net değil, log tutulmuyor | Her işlem kullanıcı adı ve zaman damgasıyla loglanır |
| Erişim iptali | Personel ayrılınca kod/veritabanı üzerinden elle iptal | Panelden tek tıkla hesap pasif hale getirilir |
Personel İşten Ayrılınca Ne Olur? Erişim İptalinin Unutulan Adımı
Rol yönetiminin en çok ihmal edilen kısmı işe alım değil, işten çıkıştır (offboarding). Bir personel ayrıldığında hesabının pasif hale getirilmesi genelde akla gelir, ama sistemin başka köşelerinde unutulan erişimler kalabilir: paylaşılan bir API anahtarı, ödeme sağlayıcı panelindeki ayrı bir giriş, ya da tarayıcıda açık kalmış bir oturum.
Sağlıklı bir offboarding sürecinde şu adımların hepsinin tamamlanması gerekir:
- Kullanıcı hesabını panelden anında pasif/silinmiş hale getirmek
- O kişinin bildiği veya eriştiği API anahtarlarını yenilemek
- Paylaşılan ödeme paneli ve tedarikçi paneli şifrelerini değiştirmek
- Sistemde açık kalmış aktif oturumları zorla sonlandırmak
Bu adımlardan biri atlandığında, aylar sonra fark edilen bir "hayalet erişim" gerçek bir güvenlik açığına dönüşebilir. Rol sistemi ne kadar iyi kurulmuş olursa olsun, çıkış sürecinde disiplin yoksa yetki matrisinin tamamı kağıt üzerinde kalır.
Her Tıklama İz Bırakıyor mu? İşlem Loglarının Gerçek Değeri
Yetkilendirme kadar önemli olan ikinci katman, o yetkinin nasıl kullanıldığının kaydedilmesidir. Loglama sadece bir "kötü niyeti yakalama" aracı değildir; günlük operasyonda da işe yarar. Bir müşteri "kodum bana ulaşmadı" dediğinde, sipariş üzerinde kimin ne zaman hangi işlemi yaptığını gösteren bir kayıt, hem müşteriyle hem ödeme sağlayıcıyla (chargeback itirazlarında) elinizi güçlendirir.
Etkili bir log sistemi en azından şu bilgileri tutmalıdır: işlemi yapan kullanıcı, işlemin türü, etkilenen kayıt, zaman damgası ve mümkünse IP adresi. Bu kayıtların değiştirilemez (immutable) olması, yani admin dahil kimsenin kendi izini silememesi de kritik bir detaydır.
Manuel bakiye ekleme, iade ve fiyat değiştirme gibi kritik işlemler için tüm admin ve muhasebe rollerinde iki faktörlü doğrulamayı (2FA) zorunlu kılın; ardından haftada bir işlem loglarını hızlıca gözden geçirmeyi ekip rutinine ekleyin. Bu iki alışkanlık, kod değişikliği gerektirmeden çoğu iç tehdit senaryosunu erken fark etmenizi sağlar.
Bayi ve Müşteri Panelleri Ayrı mı Olmalı? Sınır Nerede Çiziliyor
Çok seviyeli bayi sistemi çalıştıran e-pin platformlarında iç tehdit riski personelle sınırlı kalmaz; bayi ağının kendisi de bir risk alanıdır. Bir üst seviye bayinin, alt bayilerinin bakiyesini veya sipariş geçmişini gereğinden fazla görebilmesi, hatta bazı sistemlerde yanlışlıkla admin paneline yakın yetkilerle donatılması sık karşılaşılan bir hatadır.
Doğru kurgu, hiyerarşinin her seviyesinde görüş alanını kendi altındaki katmanla sınırlamaktır: ana bayi kendi alt bayilerini yönetir ama sistem geneline, diğer ana bayilerin verilerine veya admin ayarlarına erişemez. Bu sınır hem bayiler arası haksız rekabeti hem de bir bayi hesabının ele geçirilmesi durumunda oluşacak hasarı önler. Müşteri panelinin ise bayi ve admin panelinden tamamen ayrı bir yetki katmanında, sadece kendi siparişini ve cüzdanını görecek şekilde izole edilmesi gerekir.
Peki Bu Riskleri Sıfıra İndirmenin Yolu Ne?
Pinova, süper admin'den bayiye, muhasebeden destek personeline kadar her seviye için ayrı rol ve yetki tanımlamayı panel üzerinden sunar; her işlem otomatik loglanır ve erişimler tek tıkla iptal edilebilir. Kod yazmadan, iç tehditlere kapalı bir e-pin altyapısı kurmak için:
E-pin scriptinde rol yönetimi neden bu kadar önemli?
Çünkü e-pin sistemlerinde bakiye, kod ve ödeme gibi doğrudan parasal değeri olan işlemler yapılır. Yetkiler ayrılmadığında tek bir hesabın hatası ya da kötüye kullanımı, tüm işletmeyi doğrudan finansal kayba uğratabilir.
Küçük bir ekip için rol ayrımı gerekli mi, tek admin yeterli olmaz mı?
Ekip ne kadar küçük olursa olsun, birden fazla kişi panele giriyorsa rol ayrımı önerilir. İki kişilik bir ekipte bile "kim ne yaptı" sorusuna cevap verebilmek, ileride çıkabilecek bir anlaşmazlığı çözmenin tek yoludur.
Pinova'da kaç farklı yetki seviyesi tanımlanabilir?
Pinova süper admin, muhasebe, stok/ürün, destek ve çok seviyeli bayi rollerini panelden esnek şekilde tanımlamanıza izin verir; ihtiyaca göre yeni özel roller de oluşturabilirsiniz.
Mevcut bir e-pin sistemine sonradan rol/yetki sistemi eklenebilir mi?
Teknik olarak mümkündür ama genellikle ciddi bir kod revizyonu gerektirir. Bu yüzden çoğu işletme, hazır ve test edilmiş bir yetkilendirme altyapısına sahip bir sistem olan Pinova gibi çözümlere geçmeyi tercih eder.