Mikroservis Mimarisinde Kimlik Doğrulama (Authentication) ve Yetkilendirme (Authorization)
(microservices.io)Bu seri, mikroservis mimarisinde kimlik doğrulama (Authentication) ve yetkilendirmenin (Authorization) nasıl uygulanacağını ele alıyor.
Bu yazı, genel bir bakışla birlikte tek uygulama (monolitik) yapısından farklarını açıklıyor.
Örnek uygulama: RealGuard.io
RealGuard.io, güvenlik cihazlarının kontrolünü ve alarmları yöneten ticari bir güvenlik sistemi platformudur.
Kullanıcılar satıcı firma, müşteri firma ve izleme hizmeti sağlayıcısı tarafında yer alır ve her biri farklı erişim yetkilerine sahiptir.
Monolitik mimaride kimlik doğrulama ve yetkilendirme
Monolitik yapı, tek bir uygulama ve veritabanından oluşur; kimlik doğrulama ise oturum token'ı ile uygulanır.
Yetkilendirme şu yapıyla gerçekleştirilir:
isAllowed(user, operation, resource)
Örnek:
isAllowed(user, "disarm", SecuritySystem(ID))
4 yetkilendirme modeli
- RBAC: Rol tabanlı erişim kontrolü – yetki, kullanıcıya atanan role göre belirlenir
- ReBAC: İlişki tabanlı erişim kontrolü – erişim, kullanıcı ile kaynak arasındaki ilişkiye göre belirlenir
- ABAC: Öznitelik tabanlı erişim kontrolü – karar, kullanıcı, kaynak ve ortam özniteliklerine göre verilir
- Karma model: Yukarıdaki 3 yaklaşım birleştirilerek daha karmaşık politikalar uygulanabilir
Yetkilendirme örnekleri ve rollere göre izinler
| Operation | Required Role |
|---|---|
| getAlarmSystem() | SecuritySystemViewer |
| armSystem() | SecuritySystemArmer |
| disarmSystem() | SecuritySystemDisarmer |
| cancelSystem() | SecuritySystemAlarmCanceller |
Belirli bir role ek olarak, çalışma saati kısıtları (ABAC) veya bildirim listesinde yer alma gibi ek koşullar da uygulanabilir.
Yetkilendirme denetiminin yapıldığı yerler
- Ağ altyapısı: service mesh, ingress controller vb. katmanlarda basit yetki kontrolleri yapılabilir
- REST API handler'ları: istek düzeyinde coarse-grained yetkilendirme uygulanabilir
- Domain mantığı: karmaşık koşullara dayalı yetkilendirme burada işlenir
- DB erişim katmanı: SQL içinde yetkilendirme filtrelemesi yapılabilir (yüksek hacimli işlemlerde etkilidir)
UI'da yetkilendirme
UI yetkilendirmeyi zorunlu kılamaz, ancak kullanıcı yetkilerine göre butonları/özellikleri göstermek veya devre dışı bırakmak suretiyle UX'i optimize edebilir.
Mikroservis mimarisinde kimlik doğrulama
BFF (Backend For Frontend), giriş ve oturum yönetiminden sorumludur.
Her mikroservis bağımsız çalıştığı için kullanıcı bilgisine doğrudan oturum üzerinden erişemez; bu nedenle JWT gibi token'larla kullanıcı bilgisinin iletilmesi gerekir.
Mikroservis mimarisinde yetkilendirme
İstekler BFF → SecurityService sırasıyla iletilir ve yetkilendirme denetimi şu üç noktada yapılabilir:
- BFF: oturum bilgisine dayalı olarak yol ve metoda göre istek düzeyinde yetkilendirme yapılabilir
- Inter-service Network: service mesh, JWT tabanlı yetkilendirmenin bir kısmını üstlenebilir
- Her servisin içi: domain mantığında ve DB erişim katmanında yetkilendirme uygulanır
Dağıtık yetkilendirmenin zorlukları
Her servis, ihtiyaç duyduğu bilgileri kendi veritabanında tutmadığı için, yetkilendirme amacıyla başka servislerin API'lerini çağırmak gerekebilir.
Bunu JWT ile çözmeye çalışan yaklaşımlar da vardır, ancak token boyutu ve doğrulama maliyeti sorun yaratır.
Özet
- Kimlik doğrulama kullanıcı kimliğini doğrular, yetkilendirme ise izinleri belirler
isAllowed(user, operation, resource)deseni yetkilendirmenin temelidir- RBAC, ReBAC ve ABAC olmak üzere üç yetkilendirme modeli birleştirilerek uygulanabilir
- Monolitik yapıda tek veritabanına erişim sayesinde yetkilendirme daha kolaydır
- Mikroservislerde ise yetkilendirme için gereken veriler dağınık olduğundan uygulama daha karmaşıktır
Henüz yorum yok.