CIAM 102: Yetkilendirme ve Rol Tabanlı Erişim Kontrolü

Arka Plan#

Önceki makalede, kimlik doğrulama (AuthN) ve yetkilendirme (AuthZ) kavramlarını tanıttık, baş ağrısı yaratan bazı terimlerle birlikte: Kimlik, Organizasyon, Tenant, vb.

Organizasyon ve Tenant, Kimlikleri gruplamak için harikadır, ancak bunlar kesin bir demokrasiye yol açar: herkes bu sistemde her şeyi yapabilir. Ütopya hala bir gizemken, erişimin yönetimine bir bakış atalım: Yetkilendirme (AuthZ).

Neden yetkilendirmeye ihtiyacımız var?#

Notion harika bir örnektir. Sahip olduğunuz her sayfayı, yalnızca size özel tutabilir, arkadaşlarınızla paylaşabilir veya halka açabilirsiniz.

Veya, bir çevrimiçi kitapçı için, herkesin tüm kitapları görüntülemesini, ancak müşterilerin sadece kendi siparişlerini görüntülemesini ve satıcıların sadece kendi mağazalarındaki kitapları yönetmesini istersiniz.

AuthZ ve AuthN, karmaşık bir iş modelinin temel bileşenleridir. Çoğu zaman el ele giderler; AuthZ bir kullanıcının erişimini doğrular, AuthN ise kimlikleri doğrular. Her ikisi de güvenli bir sistem için gereklidir.

Temel yetkilendirme modeli#

İşte en yaygın AuthZ modellerinden biri: Eğer KİMLİK EYLEM gerçekleştirirse KAYNAK üzerinde, o zaman KABUL veya RED.

Notion örneğinde, model şu şekildedir: KİŞİ GÖRÜNTÜ gerçekleştirir SAYFASI üzerinde.

Eğer sayfa özel ise:

• Kendi SAYFANIZ üzerinde GÖRÜNTÜ gerçekleştirirken KABUL alırsınız.
• Diğer herkesin, sizin SAYFANIZ üzerinde GÖRÜNTÜ gerçekleştirirken RED alması gerekir.

Bazılarına göre, sektör Rol Tabanlı Erişim Kontrolü (RBAC), Özellik Tabanlı Erişim Kontrolü (ABAC) gibi çeşitli yetkilendirme teknolojileri geliştirdi. Bugün, NIST RBAC modeli Seviye 1: Düz RBAC üzerinde duracağız.

Rol Tabanlı Erişim Kontrolü#

Kitapçı örneğini genişletelim. Diyelim ki birçok müşterimiz var ama yalnızca bir satıcımız var:

• Müşteriler kitapları görüntüleyebilir ve sipariş verebilir, ayrıca kendi siparişlerini görüntüleyebilirler.
• Satıcı kitapları görüntüleyebilir, oluşturabilir ve silebilir, müşteri siparişlerini yönetebilir.

Kaynaklarını tanımla#

Logto'da, bir kaynak (yani API Kaynağı) genellikle bir varlık kümesini veya öğeleri temsil eder, çünkü geçerli bir URL kullanmak gereklidir. Bu yüzden iki kaynak tanımlıyoruz:

• Kitaplar: https://api.bookstore.io/books
• Siparişler: https://api.bookstore.io/orders

URL biçimini zorlama avantajlarından biri, URL'nin sistemin diğer bileşenleriyle entegrasyon sırasında okunabilirliği ve tanınabilirliği artırmasıdır.

Yetkileri tanımlar#

Kaynak kavramını tanıttığımızdan beri, Logto'da, yetkilerin bir kaynağa ait olması gerektiğini, tersine, kaynakların yetkileri olabileceğini belirttik.

Şimdi, kaynaklara bazı yetkiler ekleyelim:

• Kitaplar: okuma, oluşturma, silme
• Siparişler: okuma, kendine:okuma, kendine:oluşturma, silme

Bir yetkinin adı konusunda hiçbir gereklilik olmamakla birlikte, aşağıdaki sözleşmeyi benimseriz:

Uygulamada#

Teorinin yanı sıra, modelin beklendiği gibi çalışması için ağır teknik çalışmaları tamamlamamız gerekiyor:

• İstemci ve yetki sunucusu geliştirmesi
• RBAC için veritabanı tasarımı
• Farklı hizmetler arası doğrulama
• Güvenlik ve açık standart uyumluluğu
• Rol, yetki, kaynak yönetimi ve atama

Ping examples:

• Alice satılık yeni bir kitap eklemek ister:
  • Kullanıcı Alice, Kitaplar kaynağında (https://api.bookstore.io/books) oluşturma işlemini gerçekleştirir.
  • Alice'nin satıcı rolüne göre Kitapların oluşturma yetkisine sahip olduğuna göre sonuç ✅ KABUL'dır.
• Alice tüm siparişleri görüntülemek ve satışın beklentilerini karşılayıp karşılamadığını görmek ister:
  • Kullanıcı Alice, Siparişler kaynağında (https://api.bookstore.io/orders) okuma işlemini gerçekleştirir.
  • Alice'nin satıcı rolüne göre Siparişlerin okuma yetkisine sahip olduğuna göre sonuç ✅ KABUL'dır.
• Bob kitap listesine göz atmak ve satın almak istediği herhangi bir kitap olup olmadığını görmek ister.
  • Kullanıcı Bob, Kitaplar kaynağında (https://api.bookstore.io/books) okuma işlemini gerçekleştirir.
  • Bob'un müşteri rolüne göre Kitapların okuma yetkisine sahip olduğuna göre sonuç ✅ KABUL'dır.
• Bob, Carol’un siparişini görüntülemek ister.
  • Bu başkasının siparişi olduğu için, Siparişlerin kendine:okuma yetkisi burada işe yaramaz.
  • Kullanıcı Bob, Siparişler kaynağında (https://api.bookstore.io/order) okuma işlemini gerçekleştirir.
  • Bob'un Siparişlerin okuma yetkisi olmadığına göre sonuç ❌ RED'dir.

Diğer RBAC seviyeleri#

NIST RBAC modelinde dört seviye vardır:

• Düz RBAC
• Hiyerarşik RBAC
• Kısıtlı RBAC
• Simetrik RBAC

İlgileniyorsanız detaylar için makaleye bakınız.

Logto şu anda 1. Seviye uygulamasına sahip ve topluluk geri bildirimine dayalı olarak daha yüksek seviyelere ilerleyecektir. Daha yüksek bir seviyenin ihtiyaçlarınıza uygun olduğunu bize bildirmekten çekinmeyin!

Uygulamada#

Teorinin yanı sıra, modelin beklendiği gibi çalışması için ağır teknik çalışmaları tamamlamamız gerekiyor:

• İstemci ve yetkilendirme sunucusu geliştirme
• RBAC için veritabanı tasarımı
• Farklı hizmetler arası doğrulama
• Güvenlik ve açık standart uyumluluğu
• Rol, izin, kaynak yönetimi ve atama

Endişelenmeyin. Bunu göz önünde bulundurduk ve tüm bunları kapsayacak şekilde kutudan çıkar desteği ekledik. RBAC'nin Logto'da nasıl kullanılacağını öğrenmek için 🔐 RBAC tarifini kontrol edin.

Kapanış notları#

RBAC, çoğu durum için güçlü bir erişim yönetimi modelidir, ancak gümüş bir kurşun yoktur. Hala bazı sorularımız var:

• Yüksek RBAC seviyelerine ihtiyacım var mı?
• RBAC diğer yetkilendirme modelleriyle nasıl karşılaştırılır?
• Farklı Organizasyonlar arasında yetkilendirme modeli nasıl tanımlanır?