API Güvenliği: Kimlik Doğrulama, Yetkilendirme ve Veri Koruma

API'ler, yazılım sistemlerinin birbirleriyle ve dış istemcilerle veri alışverişi yaptığı programatik arayüzlerdir. Bu arayüzler genellikle kullanıcı adı ve parola gibi geleneksel oturum mekanizmalarının dışında çalıştığı için güvenlik gereksinimleri farklı bir çerçevede ele alınır. API güvenliği; isteği yapan tarafın kimliğinin doğrulanması, bu tarafın hangi kaynaklara ve işlemlere erişebileceğinin belirlenmesi, iletilen ve saklanan verinin korunması, hatalı veya kötü niyetli isteklerin tespit edilmesi ve güvenlik olaylarının izlenmesi gibi birbiriyle ilişkili unsurlardan oluşur. Kimlik doğrulama, yetkilendirme ve veri koruma başlıkları bu çerçevenin temel sütunlarıdır; ancak bu sütunlar tek başına yeterli olmaz. API'nin tasarımından devreden çıkarılmasına kadar geçen süreçte tutarlı bir güvenlik yaklaşımı uygulanması gerekir.

API güvenliğinin temel ilkeleri

API güvenliğinde ilk adım, korunacak varlıkların ve olası tehditlerin tanımlanmasıdır. Hangi uç noktaların hangi verileri işlediği, hangi istemcilerin bu uç noktalara eriştiği ve hangi işlemlerin geri döndürülemez sonuçlar doğurduğu belirlenmeden etkili bir koruma kurulamaz. Tehdit modellemesi, yetkisiz erişim, veri sızıntısı, hizmet dışı bırakma, istek sahteciliği ve kötüye kullanım gibi senaryoların sistem tasarımı aşamasında değerlendirilmesini sağlar. Bu değerlendirme, güvenlik kontrollerinin sonradan eklenen bir katman olarak değil, API'nin doğal parçası olarak ele alınmasına yardımcı olur.

En az yetki ilkesi, bir istemcinin veya kullanıcının yalnızca görevini yerine getirmek için gereken kaynaklara ve işlemlere erişebilmesini ifade eder. Varsayılan olarak reddet yaklaşımı ise açıkça izin verilmeyen her erişimin engellenmesini temel alır. Bu iki ilke, yetkilendirme kararlarının merkezinde yer alır. Derinlemesine savunma yaklaşımı, tek bir kontrolün yeterli görülmemesini ve kimlik doğrulama, yetkilendirme, ağ segmentasyonu, şifreleme, izleme ve hız sınırlama gibi birden fazla katmanın birlikte kullanılmasını ifade eder. Her isteğin kimliği doğrulanmış ve yetkisi denetlenmiş olsa bile kaynak tüketimi, veri bütünlüğü ve hata yönetimi açısından ayrıca değerlendirilmesi gerekir.

API yüzeyinin küçültülmesi, gereksiz uç noktaların, eski sürümlerin ve kullanılmayan parametrelerin kaldırılmasını kapsar. Saldırı yüzeyi genişledikçe korunması gereken bileşen sayısı artar ve yapılandırma hatalarının gözden kaçma olasılığı yükselir. Bu nedenle API envanterinin güncel tutulması, sürümlerin ve dağıtım ortamlarının kayıt altına alınması güvenlik yönetiminin ayrılmaz parçasıdır. Güvenli varsayılanlar da önemli bir ilkedir; hata ayıklama bilgilerinin üretim ortamında kapalı olması, ayrıntılı hata mesajlarının iç bilgileri açığa çıkarmaması ve izinlerin başlangıçta sınırlı tutulması bu yaklaşımın örnekleri arasında yer alır.

Kimlik doğrulama yöntemleri

Kimlik doğrulama, bir isteğin beyan edilen istemciye veya kullanıcıya ait olduğunun kanıtlanması sürecidir. API'lerde yaygın olarak API anahtarları, istemci sertifikaları, OAuth 2.0 erişim belirteçleri ve JWT gibi yapılar kullanılır. API anahtarları, istemcinin tanınmasını sağlayan basit bir mekanizmadır; ancak tek başına kullanıcı kimliğini veya ince taneli yetkileri temsil etmek için sınırlıdır. Anahtarların istemci tarafında açıkta kalması, günlüklere yazılması veya kod deposunda saklanması güvenlik riski oluşturur. Bu nedenle API anahtarlarının yalnızca istemci kimliğini gösteren bir unsur olarak değerlendirilmesi ve yetkilendirme kararlarında tek başına dayanak yapılmaması gerekir.

Karşılıklı TLS, sunucunun istemciyi X.509 sertifikasıyla doğruladığı makine-makine senaryolarında kullanılan bir yöntemdir. Bu yaklaşımda hem sunucu hem de istemci birbirine sertifika sunar ve güven zinciri doğrulanır. Sertifika yönetimi, yenileme süreçleri ve iptal kontrolleri düzenli olarak yürütülmediğinde kimlik doğrulama güvenilirliği azalır. Sertifikaların özel anahtarlarının korunması, donanım güvenlik modülleri veya güvenli anahtar depoları aracılığıyla yapılabilir. Karşılıklı TLS, özellikle kurum içi servisler arasındaki iletişimde ve yüksek güven gerektiren entegrasyonlarda ek bir kimlik doğrulama katmanı sağlar.

OAuth 2.0, kaynak sahibinin yetkisini istemciye devretmesine olanak tanıyan bir yetkilendirme çerçevesidir. API güvenliği açısından OAuth, erişim belirteçlerinin nasıl alınacağını, kapsamların nasıl sınırlandırılacağını ve istemcilerin yetkilendirme sunucusuyla nasıl etkileşime gireceğini tanımlar. OAuth 2.0 tek başına kimlik doğrulama protokolü değildir; kimlik doğrulama gereksinimi olduğunda OpenID Connect gibi ek katmanlar kullanılır. Bu ayrım, yetkilendirme ile kimlik doğrulama arasındaki sınırların doğru kurulması açısından önemlidir.

OAuth 2.0 ve OpenID Connect'in rolü

OAuth 2.0 modelinde kaynak sahibi, istemci, yetkilendirme sunucusu ve kaynak sunucusu olmak üzere dört temel rol bulunur. İstemci, kaynak sahibinin adına sınırlı bir yetkiyle kaynak sunucusuna erişmek ister. Yetkilendirme sunucusu, istemcinin kimliğini ve izin kapsamını değerlendirerek erişim belirteci üretir. Kaynak sunucusu ise gelen belirtecin geçerliliğini ve kapsamını kontrol ederek isteği yanıtlar. Yetkilendirme kodu akışı, kullanıcı etkileşimi gerektiren senaryolarda yaygın olarak kullanılır ve PKCE uzantısı ile birlikte yetkilendirme kodu ele geçirme risklerine karşı ek koruma sağlar. İstemci kimlik bilgileri akışı ise kullanıcı etkileşimi olmayan makine-makine entegrasyonlarında kullanılabilir.

Örtük akış, erişim belirtecinin tarayıcı üzerinden taşınmasına dayandığı için güvenlik sınırlamaları barındırır ve günümüz uygulamalarında kullanımı azalmıştır. Belirteçlerin URL parçalarında görünmesi, tarayıcı geçmişi ve günlükler aracılığıyla açığa çıkma olasılığını artırır. Bu nedenle OAuth dağıtımlarında akış seçimi, istemci türü ve tehdit modeliyle birlikte değerlendirilir. Kapsamların dar tutulması, istemcinin yalnızca ihtiyaç duyduğu işlemleri gerçekleştirmesini sağlar. Yetkilendirme sunucusunun yönlendirme adreslerini doğrulaması, istemci kimlik bilgilerini güvenli biçimde saklaması ve belirteçleri kısa ömürlü üretmesi OAuth güvenliğinin temel unsurlarıdır.

OpenID Connect, OAuth 2.0 üzerine kimlik doğrulama katmanı ekleyen bir protokoldür. Kimlik belirteci aracılığıyla kullanıcıya ilişkin temel talepler taşınır ve bu belirteç genellikle JWT biçimindedir. OpenID Connect kullanıldığında kimlik belirtecinin imzası, düzenleyicisi, hedef kitlesi ve geçerlilik süresi doğrulanır. Kimlik doğrulama sonucunun yalnızca istemci tarafından değil, güvenilen sunucu tarafından da denetlenmesi gerekir. Bu yaklaşım, oturum yönetimi ile API yetkilendirmesinin birbirine karıştırılmasını önlemeye yardımcı olur.

JWT doğrulama ve token yönetimi

JWT, taraflar arasında taşınan talepleri imzalı veya şifreli biçimde temsil eden bir veri formatıdır. Bir JWT üç bölümden oluşur: başlık, yük ve imza. Bu bölümler Base64URL kodlamasıyla birleştirilir. Başlık bölümü, kullanılan imzalama algoritması ve belirteç türü hakkında bilgi içerir. Yük bölümü, konu, düzenleyici, hedef kitle, son kullanma zamanı ve yetki kapsamı gibi talepleri taşır. İmza bölümü ise belirtecin bütünlüğünün doğrulanmasını sağlar. JWT'nin tek başına kimlik doğrulama protokolü olmadığı, genellikle OAuth 2.0 veya OpenID Connect gibi çerçeveler içinde belirteç formatı olarak kullanıldığı dikkate alınmalıdır.

JWT doğrulamasında yalnızca belirtecin biçimine bakmak yeterli değildir. İmza, güvenilen anahtar veya ortak anahtar seti kullanılarak doğrulanır. Düzenleyici, hedef kitle, son kullanma zamanı ve geçerlilik başlangıcı gibi talepler uygulama tarafından kontrol edilir. İmzalama algoritmasının başlık bölümünden bağımsız olarak sunucu tarafından beklenen değerle karşılaştırılması gerekir; aksi durumda algoritma karışıklığı olarak bilinen saldırı sınıfı ortaya çıkabilir. None algoritması kabul edilmemeli ve zayıf algoritmalarla imzalanmış belirteçler reddedilmelidir. Bu kontroller, belirtecin kötü niyetli olarak değiştirilmesini veya başka bir bağlamda yeniden kullanılmasını engellemeye yardımcı olur.

JWT yükü şifrelenmemiş olabilir; bu nedenle parola, kredi kartı numarası veya kişisel veri gibi hassas bilgiler belirteç yüküne yerleştirilmemelidir. Belirteçlerin kısa ömürlü olması, ele geçirilme durumunda etki alanını sınırlar. Yenileme belirteçleri ayrı bir güvenlik katmanı olarak ele alınır; bu belirteçlerin saklanması, döndürülmesi ve iptal edilmesi için açık kurallar tanımlanır. Erişim belirtecinin iptal edilmesi gerektiğinde, yalnızca imza doğrulamasına güvenmek yeterli olmayabilir; merkezi iptal listesi veya kısa ömürlü belirteç yaklaşımı birlikte değerlendirilir. İmzalama anahtarlarının düzenli olarak döndürülmesi ve eski anahtarların güvenli biçimde devre dışı bırakılması da token yönetiminin parçasıdır.

Yetkilendirme modelleri

Yetkilendirme, doğrulanmış bir öznenin hangi kaynaklara erişebileceğini ve hangi işlemleri gerçekleştirebileceğini belirler. Rol tabanlı erişim kontrolü, kullanıcıları rollere ve rolleri izinlere bağlayarak yönetimi kolaylaştırır. Öznitelik tabanlı erişim kontrolü ise kullanıcı, kaynak, işlem ve ortam özniteliklerini birlikte değerlendirerek daha ayrıntılı kararlar üretir. Politika tabanlı yaklaşımlar, yetkilendirme kurallarının merkezi bir noktada tanımlanmasını ve farklı servisler tarafından tutarlı biçimde uygulanmasını sağlar. Hangi model kullanılırsa kullanılsın, yetkilendirme kararlarının istemci tarafına bırakılmaması ve sunucu tarafında her istek için yeniden değerlendirilmesi gerekir.

API yetkilendirmesinde kapsamlar, bir istemcinin erişebileceği işlem kümelerini sınırlar. OAuth kapsamları, erişim belirtecinin hangi kaynaklara yönelik kullanılabileceğini gösterir. Kapsamların geniş tutulması, belirteç ele geçirildiğinde daha fazla işlemin yapılabilmesine yol açar. Bu nedenle kapsamların işlevsel gereksinimlere göre daraltılması ve belirteç kullanımının kaynak sunucusunda doğrulanması gerekir. Yetkilendirme kararları yalnızca rol adına veya kapsam adına dayanmamalı; erişilmek istenen nesnenin sahipliği, durumu ve işlem bağlamı da dikkate alınmalıdır.

Nesne düzeyinde yetkilendirme, API güvenliğinde sık karşılaşılan sorunlardan biridir. Bir kullanıcının yalnızca kendi kaynağına erişmesi gerekiyorsa, istekte bulunan kimliğin ilgili kaynağın sahibi olup olmadığı her istekte kontrol edilir. Yalnızca kimlik doğrulama yapılması ve kaynak kimliğinin istemciden alınması, başka kullanıcıların kaynaklarına erişim riskini doğurabilir. Benzer biçimde toplu atama olarak bilinen durumda, istemcinin göndermediği veya yetkisi olmayan alanların güncellenmesi engellenir. İzin verilen alanların açık listesiyle sınırlandırılması ve yanıtlarda yalnızca gerekli verilerin döndürülmesi bu riskleri azaltır.

Taşıma ve depolama güvenliği

API trafiğinin TLS ile korunması, verinin iletim sırasında dinlenmesini ve değiştirilmesini zorlaştırır. Sunucu sertifikasının geçerli olması, sertifika zincirinin doğrulanması ve eski TLS sürümlerinin kullanılmaması taşıma güvenliğinin temel unsurlarıdır. HSTS, istemcilerin belirli bir alan adına yalnızca güvenli bağlantı üzerinden erişmesini teşvik eder. Karşılıklı TLS gerektiren ortamlarda istemci sertifikalarının yaşam döngüsü yönetilir ve iptal kontrolleri yapılır. Taşıma güvenliği tek başına yetkilendirme yerine geçmez; ancak iletişimin gizliliği ve bütünlüğü için temel oluşturur.

Beklemedeki verinin şifrelenmesi, veritabanı, yedekleme ve dosya depolama katmanlarında hassas bilgilerin korunmasına yardımcı olur. Şifreleme anahtarlarının uygulama kodundan ayrı tutulması, anahtar yönetim sistemleri veya donanım güvenlik modülleri aracılığıyla korunması gerekir. Anahtar döndürme, erişim denetimi ve kullanım günlükleri anahtar yönetiminin parçalarıdır. Sırların kaynak kod içine gömülmesi, yapılandırma dosyalarında düz metin olarak saklanması veya sürüm kontrol sistemlerine eklenmesi önlenir. Ortam değişkenleri, gizli bilgi depoları ve erişim politikaları birlikte kullanılarak sırların yalnızca yetkili bileşenler tarafından okunması sağlanır.

Günlükler ve hata mesajları da veri koruma kapsamında değerlendirilir. Kimlik doğrulama belirteçleri, parolalar, oturum çerezleri ve kişisel veriler günlüklere yazılmamalı; zorunlu olduğunda maskelenmelidir. Ayrıntılı hata mesajları, veritabanı yapısı veya iç dosya yolları gibi bilgileri dışarıya sızdırmamalıdır. İstemciye dönen hata yanıtları genel ve tutarlı olurken, ayrıntılı bilgiler yalnızca yetkili izleme sistemlerinde tutulur. Bu ayrım, hem hata ayıklama hem de bilgi sızıntısını önleme açısından işlevseldir.

Girdi doğrulama ve güvenlik açıklarının önlenmesi

Girdi doğrulama, API'ye gelen verilerin beklenen biçim, tür, uzunluk ve aralıkta olmasını sağlar. Şema tabanlı doğrulama, istek gövdesi, sorgu parametreleri ve başlık alanları için açık kurallar tanımlar. Tip karışıklığı, beklenmeyen alanlar ve sınır dışı değerler reddedilir. Veritabanı sorgularında parametreli ifadeler kullanılması, komut enjeksiyonu ve sorgu enjeksiyonu risklerini azaltır. Dosya yükleme kabul eden uç noktalarda dosya türü, boyutu ve içeriği doğrulanır; yüklenen dosyalar çalıştırılabilir dizinlerde saklanmaz. Girdi doğrulama, yalnızca istemci tarafında değil, sunucu tarafında ve her katmanda uygulanır.

Hız sınırlama ve kota yönetimi, brute force denemelerini, kaynak tüketimini ve otomatik kötüye kullanımı sınırlar. İstek sayısı, yanıt boyutu ve eşzamanlı bağlantı sayısı gibi ölçütler istemci veya kimlik bazında izlenir. Yanıt boyutunun sınırlandırılması, aşırı veri döndürülmesini ve gereksiz kaynak kullanımını engellemeye yardımcı olur. Hata yanıtlarının gecikmeli veya genel tutulması, saldırganların sistem davranışını çıkarsamasını zorlaştırabilir. Ancak bu önlemlerin meşru istemcileri gereksiz yere engellemeyecek biçimde yapılandırılması gerekir.

Yaygın API güvenlik açıkları

• Nesne düzeyinde yetkilendirme hataları: Bir istemcinin kimliği doğrulanmış olsa bile başka bir kullanıcıya ait kaynağa erişebilmesi durumudur. Her kaynak erişiminde sahiplik ve yetki kontrolü yapılması gerekir.
• Bozuk kimlik doğrulama: Zayıf belirteç yönetimi, parola denemelerinin sınırlandırılmaması veya oturum bilgilerinin güvenli olmayan biçimde saklanması bu başlık altında değerlendirilir.
• Aşırı veri açığa çıkarma: API yanıtlarının istemcinin ihtiyaç duyduğundan fazla alan döndürmesi, hassas bilgilerin gereksiz yere paylaşılmasına yol açabilir. Yanıtlar alan bazında filtrelenir.
• Toplu atama: İstemcinin yetkisi olmayan alanları güncellemesine izin verilmesi, veri bütünlüğünü ve yetkilendirme sınırlarını zedeler. İzin verilen alanlar açıkça tanımlanır.
• Enjeksiyon ve istek sahteciliği: Girdilerin doğrulanmaması veya sunucu tarafı isteklerinin hedef adreslerinin denetlenmemesi, komut enjeksiyonu ve sunucu tarafı istek sahteciliği gibi riskleri artırır.
• Hız sınırlamasının yokluğu: Sınırsız istek kabul edilmesi, kimlik bilgisi denemelerini ve hizmet dışı bırakma girişimlerini kolaylaştırabilir. İstemci ve kimlik bazlı sınırlar uygulanır.
• API envanteri ve sürüm yönetimi eksikliği: Kullanılmayan veya unutulmuş uç noktalar güncel güvenlik kontrollerinden yoksun kalabilir. Envanterin güncel tutulması ve eski sürümlerin kontrollü biçimde kaldırılması gerekir.

İzleme, günlükleme ve olay müdahalesi

API güvenliğinde izleme, yalnızca hataları değil, beklenmeyen erişim kalıplarını ve anormal istek hacimlerini de kapsar. Kimlik doğrulama başarısızlıkları, yetkilendirme redleri, hız sınırı aşımları ve olağan dışı yanıt süreleri izlenen göstergeler arasında yer alır. İsteklerin correlation ID gibi bir tanımlayıcıyla ilişkilendirilmesi, dağıtık sistemlerde olayların izlenmesini kolaylaştırır. Günlüklerde kişisel veri ve sır bulunmaması, kayıtların bütünlüğünün korunması ve saklama sürelerinin tanımlanması gerekir.

Olay müdahale planı, şüpheli bir etkinliğin tespit edilmesi durumunda izlenecek adımları belirler. Etkilenen belirteçlerin iptal edilmesi, anahtarların döndürülmesi, erişim kurallarının geçici olarak sıkılaştırılması ve kök nedenin belirlenmesi bu adımlar arasında yer alabilir. Olay sonrası inceleme, kontrol eksikliklerinin ve yapılandırma hatalarının giderilmesine katkı sağlar. İzleme sistemlerinin yalnızca teknik göstergelere değil, iş süreçlerine etki edebilecek erişim değişikliklerine de duyarlı olması beklenir.

API yaşam döngüsünde güvenlik

API güvenliği tasarım aşamasında başlar. Uç noktaların amaçları, erişim gereksinimleri ve veri sınıflandırması açıkça tanımlanır. Kimlik doğrulama ve yetkilendirme gereksinimleri, işlevsel gereksinimlerden ayrı bir güvenlik başlığı olarak ele alınır. Tasarımda varsayılan reddet yaklaşımı benimsenir ve istemcilere yalnızca gerekli kapsamlar verilir. Tehdit modellemesi, geliştirme sürecinin erken aşamalarında yapılarak maliyetli değişikliklerin önüne geçilmesine yardımcı olur.

Geliştirme sürecinde kod incelemesi, statik analiz ve bağımlılık denetimi güvenlik kontrollerinin parçasıdır. Kullanılan kütüphanelerin ve çerçevelerin güvenlik güncellemeleri izlenir; bilinen açıkları bulunan bileşenlerin kullanımı sınırlandırılır. Otomatik testler, yetkilendirme kurallarının ve girdi doğrulamalarının beklenen biçimde çalıştığını doğrular. Sırların test ortamlarında da açıkta bırakılmaması, üretim ve test yapılandırmalarının birbirinden ayrılması gerekir. Dağıtım öncesinde güvenlik yapılandırmalarının gözden geçirilmesi, hata ayıklama modlarının kapatılması ve gereksiz uç noktaların devre dışı bırakılması kontrol edilir.

Dağıtım sonrasında API envanteri, sürüm bilgileri ve erişim politikaları güncel tutulur. Kullanımdan kaldırılan sürümler için geçiş süreçleri tanımlanır; eski sürümlerin güvenlik yamalarını almadığı durumlarda erişimlerinin kapatılması gerekir. Düzenli güvenlik değerlendirmeleri, yetki matrislerinin gözden geçirilmesi ve belirteç ömürlerinin kontrol edilmesi sürdürülebilir bir güvenlik yaklaşımının parçalarıdır. API güvenliği tek seferlik bir yapılandırma değil; tasarım, geliştirme, dağıtım, izleme ve kullanımdan kaldırma aşamalarını kapsayan sürekli bir disiplindir.