API güvenliği neden yalnızca giriş ekranı değildir?
Kimlik doğrulama kimin işlem yaptığını, yetkilendirme ise o kişinin ne yapabileceğini belirler. Kullanıcının başarılı şekilde giriş yapmış olması, erişebildiği her uç noktadaki her kaydı okuyabileceği veya değiştirebileceği anlamına gelmez. OWASP, izinlerin her istekte değerlendirilmesini önerir.
Örneğin bir satın alma uygulamasında talep açabilen bir çalışanın aynı talebi onaylamasına izin verilmeyebilir. Bu ayrımı yalnızca arayüzde düğmeyi saklayarak kurmak yeterli değildir; API’nin iş kararı da aynı sınırı uygulamalıdır. İlk tasarım görüşmesinde ‘yönetici’ ve ‘kullanıcı’ rollerini saymak yerine gerçek işlemleri çıkarmak daha açıklayıcıdır.
Kayıt düzeyinde erişimi açıkça tanımlayın
Bir uç noktanın kullanıcıya açık olması, istekte belirtilen nesnenin de ona açık olduğu anlamına gelmez. Nesne düzeyinde yetkilendirme, kullanıcının belirli kayıtta belirli işlemi yapma hakkını kontrol eder. Tahmin edilmesi zor bir kimlik kullanmak bu kontrolün yerine geçmez.
Çok şubeli bir ürün için örnek bir karar matrisi oluşturun: şube çalışanı kendi şubesindeki talebi görebilir; bölge sorumlusu tanımlı şubeler arasında inceleme yapabilir; entegrasyon hesabı ise yalnızca kendisine açılan işlem türlerini kullanabilir. Bu matris, yetki kapsamını ve veri sahipliğini konuşmak için kullanılabilir; her işletmede aynı olmak zorunda değildir.
Alanlar ve iş akışları için ayrı sınırlar koyun
Kaydı görüntüleyebilmek, içindeki her alanı değiştirebilmek değildir. Bir örnek talep formunda açıklama düzenlenebilirken onaylayan kişi, şube veya işlem durumu sunucu tarafından yönetilebilir. İstemciden gelen alanları doğrudan kayıt nesnesine aktarmak yerine hangi alanların hangi işlemde kabul edildiğini tanımlayın.
Benzer şekilde, iş akışındaki sıralama sunucuda doğrulanmalıdır. Taslak bir talebin gerekli onayları almadan tamamlandı durumuna geçmemesi gerekir. Bu örnek üzerinde ekipçe durum geçişlerini çizmek; ekran, entegrasyon ve yönetim panelinin aynı iş kuralını nasıl paylaşacağını görünür kılar.
Entegrasyon hesabını sınırsız yöneticiye dönüştürmeyin
Sistemler arası bağlantılar için de amaç, izin ve sorumluluk tanımlayın. Örneğin yalnızca sipariş durumunu bildiren bir bağlantının müşteri listesini dışa aktarması gerekmeyebilir. Her entegrasyonun sahibi, kullandığı veri, izin kapsamı ve devreden çıkarma adımı kayıt altında olmalıdır.
HTTPS, gizli anahtar yönetimi ve uygun kimlik doğrulama yöntemleri temel tasarım parçalarıdır. Bir API anahtarı kullanılıyor olması, hassas bir kaynağın bütün erişim gereksinimlerini tek başına karşılamaz. Bağlantı yenilendiğinde eski kimlik bilgisinin nasıl iptal edileceğini de devreye alma planına ekleyin.
Kaynak kullanımını işlevin maliyetine göre sınırlayın
Küçük bir kayıt sorgusu ile geniş kapsamlı bir rapor aynı kaynak maliyetine sahip olmayabilir. Liste boyutu, dosya yükleme sınırı, zaman aşımı ve istek sıklığı gibi kontrolleri uç noktanın gerçek işine göre tasarlayın. Sınır aşıldığında istemcinin anlayabileceği tutarlı bir yanıt üretin.
Örnek bir rapor akışında; kullanıcının veri kapsamını kontrol etmek, sorgu dönemini sınırlamak ve uzun işi ayrı bir görev olarak izlemek birlikte değerlendirilebilir. İyi soru yalnızca ‘kaç istek kabul edelim?’ değildir. Tek bir isteğin ne kadar iş üretebildiği ve bunun ürün deneyimine etkisi de değerlendirilmelidir.
Gözlemlenebilirlik kurarken hassas veriyi çoğaltmayın
İşlem kayıtları, erişim kararlarının ve hataların incelenmesini desteklemelidir. Ancak erişim belirteçleri, parolalar veya gereksiz kişisel veriler günlük dosyalarına taşınmamalıdır. Hangi olayın hangi ayrıntıyla kaydedileceği ve bu kayıtlara kimin erişebileceği ayrıca belirlenmelidir.
Operasyon açısından bir istek kimliği, işlem türü, sonuç ve uygun bağlam; bir olayın izini sürmek için yararlı olabilir. Ekip, örnek bir reddedilen istek üzerinden ‘bunu teşhis edebilir miyiz?’ sorusunu test edebilir. Daha çok veri toplamak yerine gerekli sinyali güvenli ve anlaşılır biçimde toplamak hedeflenmelidir.
Yayına çıkmadan önce reddedilen senaryoları da test edin
Kontrollü test ortamında aynı işlevi farklı kullanıcı rolleri, farklı şubeler ve farklı kayıt sahipleriyle sınayın. Yetkili kullanıcının beklenen işlemi yapabilmesi kadar, kapsamı dışındaki kaydı görememesi de bir kabul ölçütüdür. Alan değiştirme, işlem sırası ve erişimi kaldırılmış hesap senaryolarını bu matrise ekleyin.
Sürdürülebilir kontrol için her API’nin sahibi, sürümü, tüketicisi ve veri kapsamı bilinir olmalıdır. Yeni bir alan veya entegrasyon eklendiğinde mevcut yetki kararlarını tekrar değerlendirin. Güvenliği yalnızca yayın öncesi tek bir kontrol olarak ele almak yerine, yazılımın değişim sürecine bağlamak uzun vadede daha yönetilebilir bir yaklaşım sağlar.
