API güvenliği, sistemlerinizin birbirine ve dış servislere açtığı bağlantı noktalarının yalnız yetkili taraflarca, yalnız gereken kadar ve izlenebilir biçimde kullanılmasını sağlamaktır. API'yi daha önce iki yazılımın birbirine soru sorup cevap aldığı kapı olarak tanımlamıştık. Web siteniz ödeme sağlayıcısına, ERP'niz pazaryerine, CRM'iniz form servisine bu kapılardan bağlanır.
Entegrasyon sayısı arttıkça bu kapıların anahtarları da çoğalır. Birçok firmada bu anahtarlar bir geliştiricinin bilgisayarında, eski bir e-postada ya da paylaşılan bir dosyada durur. Kapı kurulurken gösterilen özen, yıllar içinde anahtarın nerede durduğu konusunda gösterilmez. Aşağıdaki liste bu boşluğu kapatmak için.
Anahtar yönetimi
API anahtarı, bir sistemin kendini karşı tarafa tanıttığı gizli bilgidir; bir tür şifre gibi düşünebilirsiniz. Kaybolursa, başkasının eline geçerse o kişi sizin adınıza işlem yapabilir.
- Kod içine yazılmamalı. Anahtar, uygulamanın kodunda değil, ayrı ve erişimi kısıtlı bir ayar dosyasında ya da gizli bilgi kasasında durmalı. Kod bir depoya gönderildiğinde anahtar da gitmemeli.
- Paylaşım kanalı güvenli olmalı. Anahtar e-postayla, mesajlaşma uygulamasıyla ya da ekran görüntüsüyle iletilmemeli.
- Ortam bazında ayrı anahtar. Test ortamı ile canlı ortam aynı anahtarı kullanmamalı.
- Düzenli yenileme. Anahtarlar belirli aralıklarla ve özellikle ekipten biri ayrıldığında değiştirilmeli.
- Envanter. Hangi anahtarın hangi servise ait olduğu, kimin oluşturduğu ve nerede kullanıldığı bir listede tutulmalı.
Yetki sınırı: en az yetki ilkesi
Bir entegrasyon yalnız işini yapacak kadar yetkiye sahip olmalı. Kargo takip bilgisini okuyan bir bağlantının sipariş silme yetkisi olmamalı; ERP'den stok okuyan bir servis ERP'ye yazamamalı.
Pratikte bu şu anlama gelir:
| Soru | İyi uygulama |
|---|---|
| Bu bağlantı yalnız okuyor mu? | Evet ise salt okuma yetkisi verilir |
| Hangi verilere erişmesi gerekiyor? | Yalnız o tablolara ya da kaynaklara izin verilir |
| Hangi adreslerden bağlanacak? | Mümkünse IP kısıtlaması uygulanır |
| Ne kadar süre geçerli olmalı? | Geçici işler için süreli anahtar kullanılır |
Ortak bir "yönetici" anahtarını tüm entegrasyonlarda kullanmak en yaygın ve en riskli alışkanlıktır. Bir bağlantı sızdığında zarar o bağlantının yetkisiyle sınırlı kalmalı.
İstek limiti ve kötüye kullanım
İstek limiti, İngilizcede rate limit, bir tarafın belirli bir sürede yapabileceği istek sayısına sınır koymaktır. Kendi API'nizi dışarıya açıyorsanız bu sınır hem kötü niyetli denemeleri hem de hatalı yazılmış bir entegrasyonun sisteminizi kilitlemesini engeller.
Dış servisleri kullanırken de karşı tarafın limitlerini bilmek gerekir. Limit aşıldığında servis istekleri geri çevirir; entegrasyonunuz bunu anlayıp beklemeli ve sonra yeniden denemelidir. Aksi hâlde limit aşımı art arda yeni denemelere, o da daha uzun bir engellemeye yol açar. Periyodik sorgulamayla anlık bildirim arasındaki seçimin bu yükü nasıl etkilediğini webhook nedir yazımızda anlattık.
Kayıt tutma ve izlenebilirlik
Bir sorun çıktığında ilk soru "ne oldu, ne zaman, kim yaptı?" olur. Bunun cevabı ancak düzgün tutulmuş kayıtlarla verilebilir.
- Her istek için zaman, kaynak, yapılan işlem ve sonuç kaydedilmeli.
- Kayıtlara parola, anahtar, kart bilgisi gibi gizli veriler yazılmamalı. Kişisel veriler gerekmedikçe maskelenmeli.
- Kayıtlar belirli bir süre saklanmalı, sonra silinmeli; bu süre KVKK ve iş ihtiyacına göre belirlenir.
- Olağandışı durumlar, örneğin bir anahtarla gece yarısı yüzlerce başarısız deneme, uyarı üretmeli.
Kayıtların nasıl alarma dönüştürüleceğini entegrasyon hata izleme yazımızda ele alıyoruz.
Bağlantının kendisi
- Tüm API trafiği şifreli bağlantı (HTTPS) üzerinden gitmeli.
- Dışarıdan gelen veriler, örneğin webhook mesajları, işlenmeden önce doğrulanmalı.
- Kullanılmayan eski entegrasyonlar kapatılmalı, anahtarları iptal edilmeli.
- Yazılım kütüphaneleri güncel tutulmalı; eski sürümlerde bilinen açıklar olabilir.
Kısa kontrol listesi
- Tüm API anahtarlarının listesi var, sahibi ve kullanım yeri belli
- Hiçbir anahtar kod deposunda ya da e-postada durmuyor
- Test ve canlı ortam anahtarları ayrı
- Her bağlantı yalnız gereken yetkiye sahip
- Mümkün olan yerlerde IP kısıtlaması var
- İstek limitleri tanımlı ve limit aşımında bekleme davranışı var
- İstek kayıtları tutuluyor, gizli veri içermiyor
- Olağandışı hareketler için uyarı kurulu
- Ekipten ayrılan kişi sonrası anahtar yenileme adımı prosedürde
Globya'da nasıl yapıyoruz
Kurduğumuz her bağlantıda anahtarları kod dışında, erişimi kısıtlı ayar dosyalarında tutuyor ve her entegrasyona yalnız ihtiyaç duyduğu yetkiyi veriyoruz. Mevcut entegrasyonlarınızı devralırken önce bir envanter çıkarıp yukarıdaki listeye göre gözden geçiriyoruz. Kişisel veri taşıyan bağlantılarda KVKK uyumu gereklilikleri eksik kalmaz, ek ücret alınmaz. Sunucu ve güncelleme tarafı barındırma ve bakım hizmetimiz ile aynı ekipte takip edilir.
Sık sorulan sorular
Bir API anahtarının sızdığından şüpheleniyoruz, ilk ne yapmalıyız?
Hemen o anahtarı iptal edip yenisini oluşturun, kullanıldığı yerleri güncelleyin ve kayıtlarda şüpheli işlem olup olmadığına bakın. Kişisel veri etkilendiyse KVKK kapsamındaki bildirim yükümlülüğünü de değerlendirin.
Küçük bir firmayız, bu kadar önlem gerekli mi?
Listenin çoğu bir kez kurulduktan sonra ek iş getirmez. Anahtarı doğru yerde tutmak ve yetkiyi sınırlamak, firmanın büyüklüğünden bağımsız olarak en temel önlemdir.
Mevcut entegrasyonlarımızın güvenliğini kontrol edebilir misiniz?
Evet. 0850 432 55 13 numarasından ya da iletişim sayfasından ulaşabilirsiniz. İnceleme kapsamı ve fiyatı keşif görüşmesinden sonra yazılı teklifle netleşir.
Globya asistanı 7/24 çevrimiçi; sorunuzu hemen yanıtlar, gerekirse ekibe iletir.