Çoğu satıcı tedarikçi entegrasyonunu şöyle sanır: panele bir API anahtarı yapıştırırsın, test siparişi geçer, iş biter. Gerçekte o anahtar senin kasanın kapısıdır ve kapıyı kilitleyen şey anahtarın kendisi değil, onu nasıl taşıdığın, nerede sakladığın ve hangi imzayla doğruladığındır. Bayi bakiyesi boşalan işletmelerin büyük kısmında kimse siteyi hacklemiş değildir; sadece anahtar yanlış yerde durmuştur.
İşin can sıkıcı tarafı şu: tedarikçiler dokümantasyonlarında genelde en kolay yöntemi örnek verir, çünkü destek yükünü azaltmak isterler. Sen de o en kolay yöntemi üretimde bırakırsın. Bu yazıda bir e-pin satış scripti ile tedarikçi arasındaki kimlik doğrulama katmanını tek tek açıyorum: hangi yöntem ne işe yarar, hangisi hangi riski kapatır ve Pinova gibi lisanslı bir e-pin satış yazılımında bu katmanı nasıl kurman gerekir.
Neden API anahtarı tek başına yeterli değil?
API anahtarı bir parola gibidir: kim elinde tutuyorsa o sensin. Anahtarı bir kez sızdırdığında saldırganın yapacağı şey siteni kırmak değil, doğrudan tedarikçiye senin adına sipariş geçmektir. Kodlar ona gider, fatura sana kalır. Bu yüzden anahtarı veritabanında düz metin tutmak, git deposuna göndermek veya panelde ekranda açık göstermek üretim ortamında kabul edilemez. Doğru e-pin scripti kurgusunda anahtar şifreli kolonda durur, çözüldüğü tek yer sunucu tarafındaki istek anıdır ve arayüzde yalnızca son dört karakteri maskeli görünür.
İkinci nokta: anahtarın nereye gittiği. Tedarikçi anahtarı sorgu parametresinde kabul ediyor olsa bile sen onu Authorization başlığında göndermelisin. Sorgu parametreleri sunucu erişim kayıtlarına, ara vekil sunucu loglarına ve hata izleme servislerine olduğu gibi yazılır. Başlıklar yazılmaz. Bu tek tercih, kazara sızma yüzeyini ciddi biçimde daraltır.
HMAC imza gerçekten ne kazandırıyor?
HMAC, isteğin gövdesini ve zaman damgasını gizli bir anahtarla özetleyip imza olarak eklemektir. Kazancı şudur: anahtar hattan hiç geçmez, sadece imza geçer. Saldırgan trafiği yakalasa bile elinde yalnızca o isteğe özel, kısa ömürlü bir imza olur; başka bir sipariş üretemez. Üstelik imzaya zaman damgası ve tekil istek kimliği koyduğunda tekrar saldırısı da kapanır: aynı imza ikinci kez geldiğinde tedarikçi reddeder.
İmza kurarken en sık yapılan hata gövdeyi yeniden üretmektir. İmzayı, ağa gönderdiğin baytların birebir aynısı üzerinden hesaplamalısın. JSON'u imzaladıktan sonra kütüphane boşlukları değiştirirse imza geçersiz olur ve sen bir hafta boyunca tedarikçiyle "bizde çalışıyor" yazışması yaparsın. Pratik çözüm: gövdeyi bir kez string olarak üret, o string'i hem imzala hem gönder.
| Yöntem | Anahtar hattan geçer mi | Kapattığı risk | Kurulum zorluğu | Uygun olduğu durum |
|---|---|---|---|---|
| API anahtarı (başlıkta) | Evet | Yetkisiz temel erişim | Düşük | Küçük hacim, tek tedarikçi |
| HMAC imza | Hayır | Trafik dinleme, istek değiştirme, tekrar | Orta | Yüksek hacim, otomatik teslimat |
| OAuth2 istemci kimlik bilgisi | Kısa süreli token | Kalıcı sır sızması | Orta | Kurumsal tedarikçi, çoklu yetki alanı |
| mTLS (karşılıklı sertifika) | Hayır | Sunucu taklidi, sahte uç nokta | Yüksek | Banka/ödeme benzeri yüksek limitli hat |
| IP kısıtlama | - | Farklı sunucudan kullanım | Düşük | Her zaman, ek katman olarak |
OAuth2 ve token ömrü seni nasıl kurtarır?
OAuth2 istemci kimlik bilgisi akışında elinde kalıcı bir anahtar yerine kimlik çifti bulunur; onunla kısa ömürlü erişim token'ı alırsın. Token sızsa bile ömrü genelde bir saattir. Buradaki asıl mühendislik işi token'ı doğru önbelleklemektir. Her sipariş için yeni token isteyen bir dijital ürün satış scripti hem yavaşlar hem hız sınırına takılır. Token'ı merkezi bir yerde tut, bitiş zamanından altmış saniye önce yenile ve yenilemeyi kilitle ki eşzamanlı on sipariş aynı anda on token talebi göndermesin.
Token yenilemesi başarısız olduğunda ne olacağını da baştan kararlaştır. Doğru davranış siparişi iptal etmek değil, beklemeye almaktır. Müşteriye "kod üretiliyor" durumu göster, kuyruğa al, token dönünce teslim et. Panelinde bu durumu gösteren bir ekran yoksa her geçici kimlik hatası sana iade talebi olarak geri döner.
Tedarikçi entegrasyonlarında karşılaşılan doğrulama yöntemlerinin dağılımı
- API anahtarı 45%
- HMAC imza 25%
- OAuth2 token 20%
- mTLS ve diğer 10%
IP kısıtlama neden hâlâ en ucuz sigortan?
Tedarikçi panelinde IP kısıtlama alanı varsa ve sen orayı boş bıraktıysan, aslında dünyanın herhangi bir yerinden gelen isteği kabul etmeyi seçmiş olursun. Anahtar sızdığı gün bu tek alan zararı sıfıra indirir. Kurarken dikkat edilecek yer paylaşımlı barındırmadır: giden trafiğin IP'si her zaman sitenin A kaydı değildir. Önce kendi sunucundan bir yankı servisine istek atıp gerçek çıkış IP'sini öğren, öyle ekle. Bir de yedek IP tanımla; sunucu değiştirdiğin gece satışın durmasın.
IP kısıtlamayı kendi tarafında da uygula: tedarikçiden gelen bildirim uç noktalarını yalnızca tedarikçinin adres bloğuna aç. Aksi halde sipariş durumunu "teslim edildi" yapan bir bildirim adresi, internetteki herkesin tetikleyebildiği bir kapıya dönüşür. Bu, e-pin satış yazılımı kurulumlarında en sık gözden kaçan taraftır: dışa çıkan istekleri koruyup içe gelen bildirimleri açık bırakmak.
Anahtar döndürme ve sızma anı planı nasıl olmalı?
Anahtar döndürmeyi bir kriz eylemi değil, takvim işi olarak gör. Doksan günde bir yenile; yenilemeyi kesintisiz yapabilmek için yazılımın aynı tedarikçi için iki anahtarı birlikte taşıyabilmesi gerekir: yeni anahtar eklenir, istekler ona kayar, eski anahtar bir gün sonra silinir. Tek alanlı kurulumlarda döndürme her zaman kısa bir kesinti demektir, o yüzden hiç yapılmaz.
Sızma şüphesinde sıra şudur: tedarikçi panelinden anahtarı iptal et, kendi tarafında otomatik sipariş akışını durdur, son yirmi dört saatin sipariş kayıtlarını çıkar, tedarikçinin hareket dökümüyle karşılaştır, aradaki farkı yazılı olarak bildir. Bu dört adımı yazmadıysan panik anında hiçbirini sırayla yapamazsın.
Her tedarikçi isteğine kendi ürettiğin tekil bir istek kimliği ekle ve kaydet. Kesinti sonrası "bu sipariş gerçekten gitti mi" sorusunu tahminle değil kayıtla yanıtlarsın; çift çekilen bakiyelerin çoğu bu tek alanla geri alınır.
| Kontrol | Beklenen durum | Kim doğrular | Sıklık |
|---|---|---|---|
| Anahtar şifreli saklama | Veritabanında düz metin yok | Geliştirici | Kurulumda |
| Başlıkla gönderim | URL'de sır yok | Geliştirici | Kurulumda |
| IP kısıtlama | Canlı + yedek IP tanımlı | İşletme sahibi | Sunucu değişiminde |
| Token önbelleği | Tek kilit, erken yenileme | Geliştirici | Ayda bir |
| Anahtar döndürme | Kesintisiz çift anahtar | İşletme sahibi | 90 günde bir |
| Bildirim uç noktası kilidi | Sadece tedarikçi IP'si | Geliştirici | Kurulumda |
| Mutabakat raporu | Sipariş sayısı = bakiye hareketi | İşletme sahibi | Günlük |
Bunu sıfırdan yazmak mı, hazır altyapı mı?
Yukarıdaki katmanları kendin kurabilirsin; ama şunu unutma: her yeni tedarikçi kendi doğrulama biçimiyle gelir. Üç tedarikçiden sonra elinde üç ayrı özel kod parçası olur ve biri bozulduğunda hangisinin bozulduğunu anlamak saatler alır. Pinova'nın yaklaşımı bu işi tekilleştirmektir: tek bir tedarikçi soyutlaması, anahtarların şifreli deposu, istek kimliği üretimi, kuyruk ve yeniden deneme mantığı ortakta durur; tedarikçiye özgü olan yalnızca ince bir uyarlama katmanı olur. Özellikler bölümünde bu katmanın hangi başlıklardan oluştuğunu görebilir, fiyat tarafını kendi sipariş hacminle karşılaştırabilirsin.
Tedarikçi hattını sağlam kuran bir altyapıyla başla
Kimlik doğrulama, kuyruk ve mutabakat katmanı hazır gelen bir e-pin satış yazılımıyla ilk günden üretime uygun çalış.
API anahtarımı panelde açık göstermek sorun mu?
Evet. Panele erişen her personel ve her oturum çalınması anahtarı ele geçirebilir. Anahtar bir kez kaydedildikten sonra yalnızca maskeli gösterilmeli, düzenleme sadece üzerine yazma biçiminde olmalı.
HMAC imza kurmak zorunlu mu?
Tedarikçi destekliyorsa evet, özellikle otomatik teslimat yapıyorsan. Desteklemiyorsa en azından IP kısıtlama, başlıkla gönderim ve tekil istek kimliği üçlüsünü mutlaka uygula.
Token sürekli geçersiz oluyor, sebebi ne olabilir?
En sık iki sebep: sunucu saatinin kaymış olması ve token'ın eşzamanlı isteklerde kilitsiz yenilenmesi. Saati eşitle, yenilemeyi tek kilide bağla ve bitiş zamanından bir dakika önce yenile.
Tek tedarikçiyle çalışıyorum, bu kadar katman gerekli mi?
Katmanların çoğu tek seferlik kurulum işidir ve maliyeti neredeyse sıfırdır. Tek tedarikçiyle çalışmak riski azaltmaz, aksine o hat durduğunda satışın tamamen durması demektir.
Kimlik doğrulama görünmez bir katmandır; iyi kurulduğunda kimse fark etmez, kötü kurulduğunda tek gecede aylık kârını siler. Kendi kurulumunu bu yazıdaki kontrol listesiyle karşılaştır, eksik satırları not al ve ardından canlı demo üzerinden bu katmanların hazır gelen bir altyapıda nasıl göründüğüne bak; farkı en net orada görürsün.