Yükleniyor...
API güvenliği çoğu zaman token doğrulamada biter. Oysa production’da asıl risk, authorization kararlarının yanlış katmanda alınmasıyla başlar. Bu yazı, AuthN ve AuthZ ayrımının neden mimari bir karar olduğunu anlatıyor.
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ı.
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.
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.
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: iş 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-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 dahil edilmeli?
Role’lar bu sorulara cevap vermez. Production sistemlerinde yetkilendirme, kaçınılmaz olarak context-aware hale gelmek zorundadır.
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.
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.
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.
