API Güvenliğinde İlk Adım: Envanter, Kimlik Doğrulama ve Oran Sınırları

Uygulama programlama arayüzleri, web uygulamalarından mobil istemcilere, iş ortaklığı bağlantılarından servisler arası iletişime kadar pek çok akışın temelini oluşturur. Aynı işlevin farklı kanallardan kullanılabilmesi önemli bir esneklik sağlar; ancak belgelenmemiş uç noktalar, uzun ömürlü erişim anahtarları ve tutarsız yetkilendirme kuralları saldırı yüzeyini hızla büyütür. Dışarıya açık olmayan bir API de güvenli kabul edilemez. İç ağdaki bir hesabın ele geçirilmesi veya yanlış yapılandırılmış bir iş yükü, bu arayüzleri kötüye kullanabilir.

Sağlam bir programın başlangıç noktası ürün seçimi değil, görünürlüktür. Hangi API'lerin çalıştığı, hangi veriyi işlediği, kimin sorumlu olduğu ve hangi kimlik modelini kullandığı bilinmeden etkili politika yazılamaz. Envanter, kimlik doğrulama, yetkilendirme, girdi doğrulama, kaynak tüketim sınırları ve olay kaydı aynı yaşam döngüsünde ele alınmalıdır. Koruma önlemleri tasarım aşamasında başlamalı, çalışma zamanındaki gözlemle doğrulanmalı ve kullanılmayan sürümler kapatılmalıdır.

API envanteri güvenliğin temelidir

Envanter yalnızca bir URL listesi değildir. Her kayıt için ortam, temel adres, sürüm, protokol, veri sınıfı, kimlik doğrulama yöntemi, sorumlu ekip, kullanım amacı, dışa açıklık, bağımlı sistemler ve planlanan kullanım sonu tutulmalıdır. OpenAPI gibi makine tarafından okunabilir bir tanım; yolları, işlemleri, parametreleri, yanıtları ve güvenlik şemalarını ortak biçimde ifade eder. Bu tanımın kaynak koduyla birlikte sürümlenmesi, belgelerle gerçek davranış arasındaki farkın otomatik olarak bulunmasını kolaylaştırır.

Envanteri yalnızca tasarım kayıtlarından üretmek yeterli değildir. Ağ geçidi günlükleri, servis kataloğu, alan adı kayıtları, yük dengeleyici ayarları ve çalışma zamanı telemetrisi de karşılaştırılmalıdır. Böylece unutulmuş deneme uç noktaları, eski sürümler ve doğrudan arka uca giden yollar görülebilir. OWASP API Security Top 10 listesinde uygunsuz envanter yönetiminin ayrı bir risk olarak yer alması, keşif ve kullanım sonlandırma adımlarının önemini gösterir.

Envanter kaydı dağıtım sürecinin koşulu olmalıdır. Yeni bir uç nokta tanımı eklenmeden üretime geçmemeli; kullanım sonu gelen sürüm için trafik, bağımlılık ve hata oranı gözlenerek kapatma planı uygulanmalıdır. Envanterde sahibi bulunmayan veya ne amaçla kullanıldığı açıklanamayan bir arayüz, öncelikli inceleme gerektirir.

Kimlik doğrulama ve yetkilendirme ayrılmalıdır

Kimlik doğrulama, isteği gönderen hesabın ya da iş yükünün kim olduğunu belirler. Yetkilendirme ise bu kimliğin belirli bir nesne ve işlem üzerinde ne yapabileceğine karar verir. Geçerli bir erişim belirteci, istenen kayda erişim hakkı bulunduğunu tek başına kanıtlamaz. Her nesne sorgusunda sahiplik, rol, kapsam ve bağlam sunucu tarafında yeniden denetlenmelidir. Kullanıcının gönderdiği nesne kimliğine güvenerek kayıt döndürmek, nesne düzeyinde yetkilendirme hatasına yol açar.

Erişim belirteçleri kısa ömürlü olmalı; hedef kitle, kapsam, veren makam ve geçerlilik süresi doğrulanmalıdır. Belirteçler URL içinde, uygulama günlüklerinde veya hata mesajlarında görünmemelidir. Sistemler arası erişimde paylaşılan sabit anahtarlar yerine döndürülebilen iş yükü kimlikleri tercih edilmelidir. OAuth 2.0 kullanılan akışlarda güncel güvenlik uygulamaları izlenmeli; yönlendirme adresleri tam eşleşmeyle sınanmalı, yetkilendirme kodu akışında PKCE kullanılmalı ve belirteçlerin başka bir hedefte yeniden oynatılması engellenmelidir.

Yetki politikası uç nokta adından türetilmemelidir. Aynı yol üzerindeki okuma, oluşturma, güncelleme ve silme işlemleri farklı kararlar gerektirebilir. Yönetim işlevleri ile olağan işlevler açıkça ayrılmalı; alan düzeyinde hassas veriler için yanıt filtreleme uygulanmalıdır. Politika testleri yalnızca izin verilen örnekleri değil, reddedilmesi gereken nesne ve işlev kombinasyonlarını da kapsamalıdır.

Şema ve girdi doğrulama birlikte çalışmalıdır

API tanımı, gelen isteğin biçimini sınamak için yürütülebilir bir sözleşmeye dönüştürülebilir. Tür, uzunluk, aralık, zorunlu alan ve beklenen içerik biçimi sunucu tarafında doğrulanmalıdır. Tanımda bulunmayan alanları sessizce kabul etmek, istenmeyen özelliklerin güncellenmesine veya daha sonra davranış değişikliğine neden olabilir. Yanıtlar da tanımlı şemaya göre kontrol edilerek fazla veri açığa çıkması önlenmelidir.

Şema doğrulama iş kuralının yerini tutmaz. Geçerli biçimdeki bir tarih, işlemin izin verilen dönemde olduğunu; geçerli bir sayı ise hesabın bu tutarı işleme hakkı bulunduğunu göstermez. Bu nedenle biçim denetimi, nesne ve işlev yetkilendirmesi ile iş akışı kontrolleri aynı işlem bağlamında uygulanmalıdır. Hata yanıtları gerekli ayrıntıyı günlükte tutmalı, ancak dışarıya sorgu, dosya yolu veya yığın izi sızdırmamalıdır.

Oran sınırları bağlama göre belirlenmelidir

Tek bir saniyelik istek sayısı sınırı bütün riskleri karşılamaz. Uç noktaların işlem maliyeti, veri hassasiyeti ve kötüye kullanım biçimi farklıdır. Basit bir okuma isteği ile büyük rapor üreten, dosya işleyen veya dış sisteme bildirim gönderen işlem aynı bütçeyi kullanmamalıdır. Sınırlar kimlik, erişim belirteci, IP aralığı, uç nokta, işlev ve zaman penceresi gibi birden fazla boyuta göre uygulanmalıdır.

OWASP, sınırsız kaynak tüketimini işlemci, bellek, depolama, ağ ve ücretli dış servis kullanımı açısından önemli bir API riski olarak tanımlar. Bu nedenle istek sayısının yanında eşzamanlı bağlantı, gövde boyutu, sorgu karmaşıklığı, döndürülen kayıt sayısı ve işlem süresi de sınırlandırılmalıdır. Büyük veri kümelerinde sayfalama zorunlu olmalı; arama ve grafik sorgularında derinlik veya maliyet bütçesi kullanılmalıdır.

Sınır aşıldığında tutarlı bir durum kodu ve yeniden deneme bilgisi döndürülmeli, istemciler üstel bekleme ve rastgele gecikme kullanmalıdır. Olağan yoğunluk, kötüye kullanım ve kapasite sorunu aynı görünmediği için eşikler sabit bırakılmamalıdır. Trafik taban çizgisi, kritik iş akışları ve operasyon kapasitesi birlikte gözden geçirilmelidir. Acil durumda uygulanacak daha sıkı sınırlar önceden tanımlanmalı ve geri dönüş planı bulunmalıdır.

Ağ geçidi tek başına yeterli değildir

Merkezi bir ağ geçidi TLS sonlandırma, belirteç kontrolü, şema doğrulama ve temel oran sınırları için yararlıdır. Yine de bütün yetki kararlarını bu katmana taşımak doğru değildir. Ağ geçidi, kaydın gerçek sahibini veya işlemin iş bağlamını her zaman bilemez. Nesne ve alan düzeyindeki kararlar veriye en yakın serviste uygulanmalı; merkezi politika ile yerel denetim birbirini tamamlamalıdır.

Doğrudan servis adreslerinin ağ geçidini atlaması engellenmelidir. Servisler arası iletişimde karşılıklı kimlik doğrulama, şifreli taşıma ve en az ayrıcalık ilkesi kullanılmalıdır. NIST SP 800-228, API yaşam döngüsünü tasarım öncesi ve çalışma zamanı korumalarıyla birlikte ele alır. Bu yaklaşım, yalnızca internet sınırında kontrol kurmak yerine geliştirme, test, dağıtım ve işletim aşamalarının tamamına doğrulama eklenmesini destekler.

Günlükler karar verecek kadar bağlam taşımalıdır

Bir olay kaydı; zaman, istek kimliği, uç nokta sürümü, işlem, kimlik türü, yetki kararı, sonuç kodu, gecikme ve uygulanan sınır hakkında bilgi vermelidir. Erişim belirteçleri, parolalar, kişisel veriler ve tam istek gövdeleri günlükte tutulmamalıdır. Dağıtık iz kimliği, ağ geçidi ile arka uç servislerindeki olayları ilişkilendirerek başarısız işlemin nerede oluştuğunu gösterir.

İzleme yalnızca hata oranına bakmamalıdır. Çok sayıda reddedilen nesne isteği, farklı kimliklerle aynı hassas işlemin denenmesi, eski sürüme ani trafik artışı veya sürekli sınırın hemen altında kalan otomatik istekler araştırılmalıdır. Uyarı eşiği, normal kullanım davranışıyla karşılaştırılmalı ve aynı olayın tekrar tekrar bildirilmesini önleyecek biçimde gruplanmalıdır.

Sık yapılan hatalar

İlk hata, envanteri yılda bir kez hazırlanan tablo olarak görmektir. API sürümleri ve dağıtımlar sürekli değiştiği için kayıt otomatik güncellenmezse kısa sürede güvenilmez hâle gelir. İkinci hata, geçerli belirteci bütün verilere erişim izni saymaktır. Kimlik doğrulama başarılı olsa bile nesne ve işlev yetkisi her istekte sınanmalıdır.

Diğer hatalar bütün uç noktalara aynı oran sınırını uygulamak, geliştirme uç noktalarını üretimde açık bırakmak, hata yanıtlarında iç ayrıntıları göstermek ve yalnız ağ geçidi günlüklerini saklamaktır. Güvenlik testi de tek seferlik sızma testiyle sınırlı kalmamalıdır. Şema değişiklikleri, yeni roller ve kullanım sonu gelen sürümler otomatik testleri yeniden çalıştırmalıdır.

Aşamalı uygulama planı

İlk aşamada çalışma zamanı trafiği ile tasarım kayıtları karşılaştırılarak güncel envanter çıkarılır. Dışa açık, hassas veri işleyen veya sahibi belirsiz uç noktalar önceliklendirilir. İkinci aşamada kimlik doğrulama yöntemleri ve belirteç ömürleri standartlaştırılır; nesne ve işlev yetki testleri geliştirme hattına eklenir.

Üçüncü aşamada şema doğrulama, gövde boyutu, zaman aşımı, sayfalama ve oran sınırları uç nokta riskine göre uygulanır. Dördüncü aşamada ağ geçidi, servis ve veri katmanı günlükleri ortak istek kimliğiyle ilişkilendirilir. Son aşamada kullanılmayan sürümler kapatılır; envanter bütünlüğü, reddedilen yetki kararları, sınır aşımı ve anormal trafik düzenli olarak gözden geçirilir.