RBAC ve ABAC: Bilmeniz Gereken Erişim Kontrol Modelleri

Giriş#

Erişim kontrolü, herhangi bir sistemde güvenliğin kritik bir yönüdür. Yalnızca yetkilendirilmiş kullanıcıların kaynaklara erişmesini ve eylemleri gerçekleştirmesini sağlar. Rol tabanlı erişim kontrolü (RBAC) ve öznitelik tabanlı erişim kontrolü (ABAC), modern sistemlerde kullanılan en popüler erişim kontrol modellerinden ikisidir. Her iki model de yaygın olarak benimsenmiştir ve erişim kontrol politikalarını etkili bir şekilde zorlamak için kullanılabilir. Peki, bunlar nelerdir ve nasıl farklılık gösterirler?

Rol tabanlı erişim kontrolü (RBAC)#

Rol tabanlı erişim kontrolü (RBAC) ilk olarak 1990'ların başında tanıtıldı. Modelin formalizasyonu, David Ferraiolo ve Rick Kuhn'a 1992'de yayınlanan bir makaleyle atfedilir. O zamandan beri, RBAC sektörde en yaygın kullanılan erişim kontrol modellerinden biri haline gelmiştir.

RBAC'te erişim kontrol politikaları, izinlerin koleksiyonları olan rollere dayalıdır. Kullanıcılara roller (örn. yönetici, düzenleyici, görüntüleyici) atanır ve erişim hakları, belirli kaynaklar (örn. dosyalar, veritabanları, uygulamalar) için izinlerle (örn. oluşturma, düzenleme, silme) belirlenir. Kullanıcıları rollerine göre gruplayarak ve izinleri rollere atayarak erişim kontrol politikalarının yönetimini basitleştirir. Kullanıcıları rollere eklemek veya çıkarmak kolaydır ve değişiklikler erişim kontrol politikalarına otomatik olarak yansır.

RBAC'ın Temel Bileşenleri#

• Kaynak: Bir kullanıcının erişebileceği bir varlıktır. Kaynaklar dosyalardan, veritabanlarından, API'lardan veya korunması gereken diğer sistem varlıklarından herhangi biri olabilir.
• İzin: Kullanıcının bir kaynak üzerinde gerçekleştirebileceği belirli bir eylemdir. Örneğin, oluşturma, düzenleme, silme, görüntüleme. İzin tanımı sisteme bağlı olarak değişebilir. Çoğu durumda, izinler kaynak düzeyinde minimum ayrıntılılıkla tanımlanır.
• Rol: Kullanıcının gerçekleştirebileceği bir dizi eylemi tanımlayan bir izinler topluluğudur. Örneğin, bir yönetici rolü kaynakları oluşturma, düzenleme ve silme iznine sahip olabilirken, bir izleyici rolü kaynakları görüntüleme iznine sahip olabilir.
• Kullanıcı: Bir veya daha fazla role atanabilen bir varlıktır. Kullanıcılar, atandıkları rollerle ilişkili izinlere dayalı olarak kaynaklara erişim elde ederler.

RBAC Varyantları#

Daha karmaşık erişim kontrol gereksinimlerini karşılamak için temel modeli genişleten birkaç RBAC varyantı vardır:

• RBAC0: Kullanıcıların rollere, rollerin ise izinlere atandığı temel model.
• RBAC1: Rol hiyerarşileri kavramını ekler. Roller, diğer rollerden izinler devralabilir. Hiyerarşik RBAC olarak da bilinir.
• RBAC2: Rollere kısıtlamalar ekler. Kısıtlamalar, bir kullanıcının rol atanabilmesi için karşılanması gereken ek koşulları tanımlamak için kullanılabilir. Kısıtlama tabanlı RBAC olarak da bilinir.
• RBAC3: RBAC1 ve RBAC2'nin özelliklerini birleştirir. Hem rol hiyerarşilerini hem de kısıtlamaları destekler.

Bu varyantlar hakkında daha fazla bilgi için RBAC modelleri ve evrimi bölümüne bakınız.

RBAC'ın Artıları#

• Basitlik: RBAC anlaması ve uygulaması kolaydır. İzinleri rollere ve rolleri kullanıcılara atamak basittir.
• Verimlilik: Kullanıcıları rollerine göre gruplayarak erişim kontrol politikalarının yönetimini basitleştirir. Erişim kontrol politikalarını değiştirmeden kullanıcılara roller eklemek veya çıkarmak kolaydır. İyi tanımlanmış izin yapıları olan büyük organizasyonlarda RBAC çok verimli olabilir.
• Şeffaflık: RBAC, roller, izinler ve kullanıcılar arasında açık bir eşleme sağlar. Erişim kontrol politikalarını denetlemek ve gözden geçirmek kolaydır.

RBAC'ın Eksileri#

• Sertlik: RBAC, karmaşık erişim kontrol politikalarını tanımlama konusunda katı olabilir. Erişim kontrol politikalarının daha dinamik ve bağlama duyarlı olması gereken sistemler için uygun olmayabilir.
• Ayrıntılılık: RBAC, ince ayrıntılı erişim kontrolü için gereken ayrıntıya sahip olmayabilir. Erişim kontrol politikaları iyi tanımlanmış rollere bağlıdır ve daha ayrıntılı düzeyde izinleri tanımlamak için ekstra çaba gerekebilir.
• Rol patlaması: Karmaşık izin yapıları olan büyük organizasyonlarda, rol sayısı üstel olarak artabilir ve rol patlamasına yol açabilir. Çok sayıda rolü yönetmek zorlu olabilir.

Öznitelik Tabanlı Erişim Kontrolü (ABAC)#

2000'lerin sonlarında sistemler daha karmaşık ve dinamik hale geldikçe, giderek daha fazla organizasyon öznitelik tabanlı erişim kontrolü (ABAC) modelini RBAC'ye alternatif olarak benimsemeye başladı. ABAC'nin formalizasyonunda önemli bir dönüm noktası, 2014 yılında yayınlanan NIST Özel Yayını 800-162 olmuştur.

ABAC, RBAC'ye kıyasla daha esnek bir erişim kontrol modelidir. Kullanıcının, kaynağın, eylemin ve ortamın özniteliklerine dayalı erişim kontrol politikalarını tanımlayan bir yetkilendirme modelidir. Organizasyonların farklı bağlamlara ve koşullara uyum sağlayabilecek ince ayrıntılı erişim kontrol politikalarını tanımlamalarına olanak tanır.

ABAC'ın Temel Bileşenleri#

• Özne: Bir kaynağa erişim talep eden bir varlıktır. Bu bir kullanıcı, bir cihaz, bir uygulama veya kaynaklara erişmesi gereken herhangi bir varlık olabilir.
• Kaynak: RBAC'deki gibi, bir öznenin erişebileceği bir varlıktır. Kaynaklar dosyalar, veritabanları, API'lar veya herhangi bir sistem varlığı olabilir.
• Eylem: Bir öznenin bir kaynak üzerinde gerçekleştirebileceği belirli bir işlemdir. Oluşturma, okuma, güncelleme, silme veya kontrol edilmesi gereken herhangi bir işlem olabilir.
• Ortam: Erişim isteğinin yapıldığı bağlamdır. Günün saati, konum, ağ, cihaz gibi öznitelikleri içerebilir.
• Öznitelik: Bir öznenin, kaynağın, eylemin veya ortamın bir özelliğidir. Kullanıcı rolleri, departman, konum, IP adresi, cihaz türü vb. her şey olabilir.
• Politika: Erişimin verilip verilmeyeceği koşulları tanımlayan bir kuraldır. Politikalar özniteliklere dayalı olarak tanımlanır.

ABAC'ın Artıları#

• Esneklik: ABAC, birden çok özniteliğe dayalı karmaşık erişim kontrol politikalarını barındırabilir. Organizasyonların farklı bağlamlara ve koşullara uyum sağlayabilecek ince ayrıntılı politikalar tanımlamalarına olanak tanır.
• Dinamik: ABAC politikaları dinamik ve bağlama duyarlı olabilir. Erişim kontrol kararları, konum, günün saati, cihaz türü gibi gerçek zamanlı özniteliklere dayanarak verilebilir.
• Ayrıntılılık: ABAC, birden çok özniteliğe dayalı olarak organizasyonların ince ayrıntılı politikalar tanımlamasına izin vererek ince ayrıntılı erişim kontrolü sağlar. Rolleri ve izinleri tanımlamaktan ziyade, öznitelik bazlı politikalar daha ayrıntılı olabilir.

ABAC'ın Eksileri#

• Karmaşıklık: ABAC, RBAC'ye kıyasla uygulamak ve yönetmek daha karmaşık olabilir. Öznitelikleri ve politikaları tanımlamak daha fazla çaba ve uzmanlık gerektirebilir. RBAC'de rol ve izinler iyi yapılandırılmışken, öznitelikler daha dinamik olabilir ve bu yüzden politikalar da öyle olabilir. Karmaşık bir sistemde çok sayıda öznitelik ve politikayı yönetmek zorlu olabilir. Politikaları değerlendirmek için genellikle merkezi bir politika değerlendirme motoru gereklidir.
• Performans: Öznitelik değerlendirmesi, özellikle gerçek zamanlı ortamlarda performansı etkileyebilir. Birden çok özniteliğe ve gerçek zamanlı koşullara dayalı politikalar, erişim kontrol kararlarında gecikme yaratabilir.

Karşılaştırma Tablosu#

Karşılaştırma tablosundan anlaşılacağı üzere, RBAC en iyi tanımlanmış izin yapıları ve erişim kontrol politikalarının nispeten statik olduğu sistemler için en uygunudur. Öte yandan, ABAC erişim kontrol politikalarının dinamik, bağlama duyarlı ve ince ayrıntılı olması gereken sistemler için daha uygundur.

Örnekler#

Senaryo: Farklı personel üyeleri için hasta kayıtlarına erişimi yönetmesi gereken bir hastane sistemi.

• Personel: Doktorlar, Hemşireler, Yöneticiler
• Kaynaklar: Hasta kayıtları
• İzinler: Okuma, Yazma, Silme

Durum 1#

Erişim kontrol politikaları nispeten basittir:

1. Doktorlar hasta kayıtlarını okuyabilir ve yazabilir.
2. Hemşireler hasta kayıtlarını okuyabilir.
3. Yöneticiler hasta kayıtlarını okuyabilir, yazabilir ve silebilir.

RBAC modeli#

Bu durumda, RBAC basit ve etkilidir. Doktorlar, hemşireler ve yöneticiler için roller tanımlayıp her role uygun izinler atayabiliriz.

Erişim kontrol değerlendirmesi basittir:

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')

ABAC modeli#

Bu durumda, ABAC fazla gelebilir, ancak departman, rol gibi özniteliklere dayalı ince ayrıntılı politikalar tanımlamak için yine de kullanılabilir.

Öznitelikler:

• user.role: doktor, hemşire, admin
• resource.name: hasta-kayıt
• action: okuma, yazma, silme

Politikalar:

• Politika 1: user.role ve resource.name'e dayalı okuyarak erişim izni ver
  • subject: Rolü doktor, hemşire, admin olan kullanıcı
  • resource: Adı hasta-kayıt olan kaynak
  • action: okuma
  • effect: izin ver
  • rationale: "Tüm rollere hasta kayıtlarına okuma izni ver"
• Politika 2: Doktorlar ve yöneticiler için düzenleme erişimi ver
  • subject: Rolü doktor, admin olan kullanıcı
  • resource: Adı hasta-kayıt olan kaynak
  • action: yazma
  • effect: izin ver
  • rationale: "Doktorlar ve yöneticiler için hasta kayıtlarına yazma izni ver"
• Politika 3: Yöneticiler için silme erişimi ver
  • subject: Rolü admin olan kullanıcı
  • resource: Adı hasta-kayıt olan kaynak
  • action: silme
  • effect: izin ver
  • rationale: "Yöneticiler için hasta kayıtlarını silme izni ver"

Her okuma / yazma / silme isteği için, politika motoru özniteliklere göre tüm ilgili politikaları değerlendirir ve bir erişim kontrol kararı verir.

Karşılaştırma#

Bu durumda, erişim kontrol politikaları basit ve iyi yapılandırılmıştır. Bir kullanıcının bir kaynağa erişip erişmediğini belirlemek için yalnızca tek seviyeli izin kontrolü gerektirir. Hastane sisteminin çok sayıda departman, rol ve izin içeren daha karmaşık bir yapıya sahip olduğunu hayal edin:

• Bir RBAC modelinde, hasta kayıtları kaynağının erişim kontrol değerlendirme süreci, kullanıcı okuma, yazma veya silme iznine sahip olup olmadığına bakılmaksızın basit ve doğrudan kalacaktır;
• Öte yandan, ABAC ek departman-id ve doktor-id gibi ek öznitelikler içermelidir. Peki, hasta kayıtlarına erişmesi gereken bir IoT cihazı olursa ne olacak? Politika değerlendirmesine yeni bir öznitelik olan cihaz-id tanıtılması gerekecektir. Bir stajyer doktora geçici olarak okuma izni vermek nasıl olacak?

Sonuç olarak, RBAC daha iyi bir uyum sağlar. İyi tanımlanmış izin yapılarına sahip sistemler ve erişim kontrol politikalarının statik olduğu sistemler için RBAC basit ve etkilidir.

Durum 2#

Aynı hastane sistemi, şimdi yeni bir rol olan hasta ve yeni bir öznitelik hasta-id tanıtalım.

Erişim kontrol politikaları şunlardır:

1. Doktorlar hasta kayıtlarını okuyabilir ve yazabilir.
2. Hemşireler hasta kayıtlarını okuyabilir.
3. Yöneticiler hasta kayıtlarını okuyabilir, yazabilir ve silebilir.
4. Hastalar kendi kayıtlarını okuyabilir.

RBAC modeli#

Bu durumda, eski okuma iznine ek olarak yeni bir izin kendi-okuma eklememiz gerekecek. Doktorlar, hemşireler, yöneticiler ve hastalar için roller tanımlayıp her role uygun izinler atayabiliriz.

Artık okuma hasta kaydı eylemi için erişim kontrol değerlendirmesi biraz daha karmaşıktır:

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')
• GET /patient-records/:patient-id: user.permission.includes('read-own') && user.id === patient-id || user.permission.includes('read')

ABAC modeli#

Şimdi yeni gereksinimleri karşılamak için ABAC modelindeki öznitelikleri ve politikaları güncelleyelim.

Öznitelikler:

• user.role: doktor, hemşire, admin, hasta
• user.id: hasta-id
• resource.name: hasta-kayıt
• resource.patient-id: hasta-id
• action: okuma, yazma, silme

Politikalar:

• Politika 1: Tüm hasta kayıtlarına okuma izni ver
  • subject: Rolü doktor, hemşire, admin olan kullanıcı
  • resource: Adı hasta-kayıt olan kaynak
  • action: okuma
  • effect: izin ver
  • rationale: "Tüm personel ve hastanın kendisi için hasta kayıtlarına okuma izni ver"
• Politika 2: Doktorlar ve yöneticiler için tüm hasta kayıtlarına yazma izni ver
  • subject: Rolü doktor, admin olan kullanıcı
  • resource: Adı hasta-kayıt olan kaynak
  • action: yazma
  • effect: izin ver
  • rationale: "Doktorlar ve yöneticiler için hasta kayıtlarına yazma izni ver"
• Politika 3: Yöneticiler için tüm hasta kayıtlarına silme izni ver
  • subject: Rolü admin olan kullanıcı
  • resource: Adı hasta-kayıt olan kaynak
  • action: silme
  • effect: izin ver
  • rationale: "Yöneticiler için hasta kayıtlarını silme izni ver"
• Politika 4: Kendi hasta kayıtlarına okuma izni ver
  • subject: Rolü hasta olan kullanıcı
  • resource: Adı hasta-kayıt olan kaynak
  • action: okuma
  • condition: user.id === resource.patient-id
  • effect: izin ver
  • rationale: "Kendi hasta kayıtlarına okuma izni ver"

Karşılaştırma#

Bu durumda, erişim kontrol politikaları daha karmaşık ve bağlama duyarlıdır. Hasta kayıtları kaynağının erişim kontrol değerlendirme süreci, bir kullanıcının bir kaynağa erişip erişmediğini belirlemek için birden fazla izin seviyesinde kontrol gerektirecektir.

• Bir RBAC modelinde, hasta kayıtları kaynağının erişim kontrol değerlendirme süreci, bir kullanıcının bir kaynağa erişip erişmediğini belirlemek için birden fazla izin seviyesi kontrolü gerektirecektir. Örneğin, hastanın kendi kayıtlarına erişimi olup olmadığını belirlemek için sistemin kullanıcının kendi-okuma iznine sahip olup olmadığını ve kullanıcı kimliğinin hasta kimliğiyle eşleşip eşleşmediğini kontrol etmesi gerekir.
• Bir ABAC modelinde, erişim kontrol değerlendirme süreci daha basit olabilir. Politikalar, kullanıcının, kaynağın ve eylemin özniteliklerine dayalı olarak tanımlanabilir. Örneğin, bir hastanın kendi kayıtlarına erişimi olup olmadığını belirlemek için politika motoru, kullanıcı kimliği ve hasta kimliğine dayalı olarak politikayı değerlendirebilir.

Bu durumda, ABAC daha iyi bir uyum sağlayabilir. ABAC, erişim kontrol politikalarının dinamik, bağlama duyarlı ve ince ayrıntılı olması gerektiği sistemler için daha uygundur.

Sonuç#

RBAC ve ABAC arasında seçim yapmak, sistemin spesifik gereksinimlerine bağlıdır. RBAC, iyi tanımlanmış izin yapılarına sahip sistemler ve erişim kontrol politikalarının statik olduğu sistemler için en uygunudur. ABAC, erişim kontrol politikalarının dinamik, bağlama duyarlı ve ince ayrıntılı olması gerektiği sistemler için daha uygundur. Pratikte, organizasyonlar istenen erişim kontrol seviyesini elde etmek için her iki modelin bir kombinasyonunu kullanmayı tercih edebilir.