client_id + client_secret → access token. client_secret, organizasyonunuz adına işlem yapma yetkisidir; sızdığında saldırganın elinde sizin adınıza ödeme oluşturma kapısı olur.
Aşağıdaki kurallara uymak sızıntı riskini ve sızıntı sonrası etkiyi minimuma indirir. Auth akışının tamamı için: Kimlik Doğrulama.
Kuralname
Asla kaynak kodda tutmayın —
client_secret’ı .env, secret manager veya environment variable olarak yönetin.Asla istemcide tutmayın — tarayıcı, mobil uygulama veya desktop client’a göndermeyin. Token alma sunucu tarafında yapılmalı; istemciye yalnızca kısa ömürlü access token gider.
Asla loglara yazmayın — log framework’ünüzde request/response loglama açıksa
Authorization header’ı ile client_secret body alanını maskeleyin.Asla destek ekibine paylaşmayın — Payven destek ekibi sizden
client_secret istemez.Sandbox ve production’ı ayırın — farklı client’lar, farklı secret store’lar.
IP whitelist tanımlayın — production client’ları için zorunlu kabul edin (Identity tarafında enforce edilir).
Düzenli rotasyon — minimum 6 ayda bir, sızıntı şüphesinde anında.
Audit logları izleyin — konsoldaki API kayıtları ekranından beklenmeyen istek varsa hemen tepki verin.
Token cache uygulayın — her istek öncesi yeni token almayın; access token süresi dolmadan (60sn margin) refresh edin.
Saklama önerileri
| Ortam | Önerilen secret store |
|---|---|
| AWS | AWS Secrets Manager veya Parameter Store (SecureString) |
| Azure | Azure Key Vault |
| GCP | Secret Manager |
| Kubernetes | External Secrets Operator + cloud KMS |
| On-premise | HashiCorp Vault |
| Geliştirme | .env (commit edilmez) + direnv veya dotenv |
Çoklu client stratejisi
Tek bir client’la çalışmak yerine işlevlere göre ayrılmış client’lar oluşturmanız önerilir:| Client | Kullanım |
|---|---|
payments-prod | Sadece ödeme alma servisinde kullanılan production client’ı |
reporting-prod | Sadece raporlama job’larında kullanılan, daha kısıtlı IP whitelist’li client |
dev-team-sandbox | Geliştirici ekibinin paylaştığı sandbox client’ı |
client_secret sızdığında etki alanı sınırlı kalır, audit’lerde hangi servisin ne yaptığını ayırt etmek kolaylaşır.
Rotasyon prosedürü
Sıfır kesinti ile rotasyon:Yeni client veya secret üretin
Konsol → API Anahtarları → Yeni Client Oluştur (veya mevcut client için Secret Rotate). Mevcut secret’ı silmeyin — Identity, geçiş süresince eski ve yeni secret’ı geçici olarak birlikte kabul eder.
Servisinizi yeniden deploy edin
Yeni secret ile başlayan servis pod/instance’ları çalışmaya başlasın. Eski olanlar hâlâ eski secret’la çalışıyor — geçiş penceresinde ikisi de geçerli.
Audit log'u izleyin
Konsol → API Kayıtları ekranında eski secret’a gelen istek olup olmadığını izleyin. Trafik sıfıra inene dek bekleyin.
Sızıntı şüphesinde acil müdahale
client_secret’ınızın sızdığını düşündüğünüz an aşağıdaki adımları paralel uygulayın:
Secret'ı hemen revoke edin
Konsoldan client’ı pasife çekin veya secret’ı rotate edin. Süreç anlıktır.
Audit log incelemesi
Sızıntı penceresinde gerçekleşen tüm işlemleri konsol → API Kayıtları’ndan ekstrakt edin.
Destek ekibine bildirin
Destek talebi açın — etki analizi konusunda yardım alın.