AuthN vs AuthZ: API güvenliği production ortamlarında neden sessizce çöker

API güvenliği konuşmalarının çoğu benzer bir noktada biter. Kimlik doğrulama çözülmüştür, token’lar alınır, imzalar doğrulanır ve sistem “güvende” kabul edilir.

Production ortamlarında sorunlar ise genellikle tam bu rahatlama anından sonra başlar.

Authentication (AuthN) ile authorization (AuthZ) arasındaki fark teoride herkesin bildiği bir ayrımdır. Pratikte ise bu iki kavram çoğu mimaride ya iç içe geçirilir ya da aralarındaki sınır bilinçli olarak belirsiz bırakılır. Bunun sonucu, sistemlerin açıkça kırılmaması ama zamanla sessiz riskler üretmesidir.

Bu yazı, AuthN ve AuthZ’yi yeniden tanımlamak için değil, neden doğru tasarlandığı düşünülen API güvenlik mimarilerinin production’da fark edilmeden problemli hale geldiğini anlatmak için yazıldı.

Sorun genellikle authentication’da değil

Authentication çoğu sistemde sorunsuz çözülür. Token alınır, imzası doğrulanır, süresi kontrol edilir. Identity provider doğru çalışıyordur ve bu katman ekipler için genellikle “tamamlandı” kabul edilir.

Authorization ise çoğu zaman daha flu bir alandır. Token geçerliyse erişimin de geçerli olduğu varsayılır. Bu varsayım kısa vadede işleri hızlandırır, uzun vadede ise en pahalı güvenlik problemlerinin zeminini hazırlar.

Production sistemlerinde sıkça görülen ortak nokta şudur: Yetkilendirme kararı ya hiç alınmaz ya da alınması gereken yerden çok daha önce alınır.

Token geçerli, peki yetki?

Basit bir örnekle düşünelim:

GET /claims/12345
Authorization: Bearer eyJhbGciOi...

Token geçerli, süresi dolmamış ve güvenilir bir identity provider tarafından üretilmiş. Log’lara bakıldığında her şey olması gerektiği gibi görünüyor.

Ama kritik soru genellikle sorulmaz: Bu kullanıcı bu claim’e erişmeli mi?

Çoğu sistem için bu soru, mimari olarak sorulabilecek bir yerde değildir. Token doğrulandıktan sonra istek “doğru” kabul edilir ve yoluna devam eder. Bu yaklaşım, sistem çalıştığı sürece sorun yaratmaz gibi görünür.

Sorun, sistem büyüdükçe ve kullanım senaryoları çeşitlendikçe ortaya çıkar.

Gateway her şeyi çözmez

API gateway’ler authentication için güçlü ve doğru araçlardır. Token doğrulama, rate limit, client kontrolü gibi teknik konular gateway seviyesinde merkezi olarak çözülür.

Ancak authorization’ı da aynı katmanda çözmeye çalıştığınızda fark edilmesi zor bir yan etki oluşur: İş bağlamı kaybolur. Gateway, domain datasını bilmez. Hangi kaydın kime ait olduğunu, hangi işlemin hangi iş kuralına bağlı olduğunu anlayamaz.

Bu noktada authorization kararları kaçınılmaz olarak statikleşir. Role’lar genişler, scope’lar şişer ve bir süre sonra “çalışıyor” gibi görünen ama sınırları belirsiz bir yetki modeli ortaya çıkar.

Bu aşamada ekipler genellikle şu cümleyi kurar: “Nasıl olsa gateway kontrol ediyor.”

Production’da bu cümle pahalıdır.

Role’lar neden yeterli olmaz

Role-based authorization başlangıçta pratiktir ve hızlı ilerlemenizi sağlar. Ancak sistem büyüdükçe bazı sorular kaçınılmaz hale gelir.

Aynı role sahip iki kullanıcı gerçekten aynı verilere mi erişmeli? Bu kullanıcı sadece kendi kaydını mı görmeli, yoksa aynı role sahip herkesin verisini mi? Bölge, müşteri, ürün veya zaman gibi bağlamlar yetkilendirme kararına nerede dâhil edilmeli?

Role’lar bu sorulara cevap vermez. Production sistemlerinde yetkilendirme, kaçınılmaz olarak context-aware hale gelmek zorundadır.

Sessiz riskler ve yanlış sınırlar

Bu mimari problemler genellikle alarm üretmez. Log’larda hata yoktur, servisler ayaktadır, SLA’ler yeşildir. Sistem çalışıyordur.

Ancak bir süre sonra audit sırasında ya da beklenmedik bir güvenlik incelemesinde şu tarz cümleler duyulur: “Teknik olarak doğru, ama mantıksal olarak yanlış.”

En zor açıklanan güvenlik problemleri bunlardır. Çünkü sistem bozuk değildir, sadece sınırları yanlış çizilmiştir.

Gateway nerede bitmeli, servis nerede başlamalı?

Sağlıklı mimarilerde gateway ile servis arasındaki sorumluluk sınırı nettir. Gateway, isteğin sisteme girip giremeyeceğine karar verir. Kimlik doğrulama, trafik kontrolü ve teknik politika enforcement burada çözülür.

Servis tarafı ise iş bağlamını bilir. Verinin sahibini, işlemin anlamını ve erişimin gerçekten doğru olup olmadığını değerlendirebilecek tek yerdir. Nihai authorization kararı burada alınmalıdır.

Bu iki soruyu aynı katmanda çözmeye çalışmak kısa vadede işleri kolaylaştırır, uzun vadede ise mimari borç üretir.

Sonuç: Güvenlik hataları gürültüyle gelmez

En tehlikeli güvenlik açıkları exception fırlatmaz, sistemi durdurmaz, dashboard’ları kırmızıya boyamaz.

Bir gün sadece şu soru sorulur: “Bu kullanıcı bu veriye neden erişebiliyordu?”

AuthN ve AuthZ arasındaki farkı doğru yerde konumlandırmak bir güvenlik detayı değil, temel bir mimari karardır.

Sıkça sorulan sorular

Authentication ile authorization arasındaki fark nedir?

Authentication (AuthN) kimlik doğrulamadır — “Sen kimsin?” sorusuna cevap verir. Authorization (AuthZ) ise yetkilendirmedir — “Ne yapmaya yetkilisin?” sorusuna cevap verir. AuthN genellikle login, token veya sertifika ile yapılır. AuthZ ise RBAC, ABAC veya policy engine’ler aracılığıyla uygulanır. İkisi birbirinden bağımsız katmanlardır ve API güvenliğinde her ikisi de zorunludur.

API güvenliğinde JWT mi yoksa OAuth 2.0 mı kullanılmalı?

JWT ve OAuth 2.0 farklı katmanlarda çalışır. OAuth 2.0 bir yetkilendirme framework’üdür ve token alma sürecini tanımlar. JWT ise bir token formatıdır. Genellikle birlikte kullanılırlar: OAuth 2.0 flow’u ile alınan access token JWT formatında olabilir. Machine-to-machine iletişimde client credentials flow ile JWT, kullanıcı bazlı erişimde ise authorization code flow ile opaque veya JWT token tercih edilir.

Zero trust API güvenliği nasıl uygulanır?

Zero trust API güvenliği şu prensiplerle uygulanır: Her istek bağımsız olarak doğrulanır (session’a güvenilmez), mTLS ile servisler arası kimlik doğrulama yapılır, en az yetki prensibi (least privilege) ile scope’lar minimumda tutulur, token ömürleri kısa tutulur ve sürekli yenilenir, API gateway’de rate limiting ve anomaly detection uygulanır ve tüm erişimler audit log’a kaydedilir.

API authentication bypass saldırıları nasıl önlenir?

Authentication bypass önleme stratejileri: token validation’ı her endpoint’te zorunlu kılma (middleware/interceptor pattern), JWT signature doğrulamasında algorithm confusion saldırısını önleme (kabul edilen algoritmaları bir allowlist ile sınırlama), token expiration kontrolü, audience (aud) ve issuer (iss) claim doğrulaması ve broken object level authorization (BOLA) kontrolü ile kaynak bazlı yetkilendirme yapılmalıdır.