ACL ve RBAC hakkında okurken bunu kolayca anlıyorum - bir varlığa erişim verilen kullanıcı adları veya roller var. Bunları nasıl uygulayabildiğimi de görebiliyorum.

yani bu görüntü benim için ACL ve RBAC'ın net bir görünümünü veriyor (olduğu gibi devam edebilir ve yukarıdaki tablo veritabanlarını tasarlayabilirim): ( Basın kitaplarının izniyle )

Mücadele ettiğim şey ABAC. Şimdiye kadar bulduğum çeşitli görüntüler elle dalgalı veya aşırı karmaşıktır veya Yetkili bir üçüncü taraf harici varlık kullanmanızı önerir. Ya da tuhaf nitelik örnekleri verin Nasıl kullanılacağından tam olarak emin değilim.

Başlangıç ​​Örneği

Öyleyse gerçek hayatta bir şeyle başlayayım. Diyelim ki 70-200 kişilik bir şirketim var. Ve benim korunacak varlığım çok çeşitli sayfaları olan bir web sitesidir. Belirli kişilerin belirli varlıklara erişmesine izin vermek istiyorum.

Örneğin, bir kişinin Leslieadlı bir web sayfasına erişmesini Price Managerve yalnızca Travelo sayfadaki fiyat grubunun fiyatlarını yönetmesine izin vermesini istiyorum , ancak Productaynı sayfadaki grup fiyatlarını yönetememesine izin veriyorum . ABAC kullanarak bunu nasıl uygulayabilirim?

Şimdiye kadar alay, tahminim Lesliebazı nitelikler atayabilirsiniz (ama hangileri ve bu nitelikler nelerdir?) Ve sonra bunları depolayan bir veritabanı tablosu var. Daha sonra bu niteliklere bakan bir motor tasarlayabilirim (ancak LeslieRBAC'de yapıldığı gibi "Rol" olarak görünmüyor ) ve oradan sayfaya erişim izni verip vermemeye karar veriyorum. Bu motor nasıl görünecekti? Basit bir if / else bloğu mu? Başka bir şey?

Leslie daha sonra pozisyonunu değiştirirse ve birisinin erişimini değiştirmesi gerekiyorsa ne olur? Erişimin taşınması Productve kaldırılması gerekiyorsa nasıl görünecek Travel? Nasıl o kadar iptal erişimi gerekiyorsa kodlu olacak Price Managerartık ne erişebilir tamamen ve dolayısıyla sayfa Travelya Product?

Benim durumumdaki varlık, sadece yeniden ifade etmek için Price Manager, ve bir kullanıcı o sayfadaki Travelfiyatlandırma, Productfiyatlandırma vb. Gibi çeşitli fiyat gruplarına erişebilir .

Aradığım şey, ayrıntıları açıklığa kavuşturmaya ve tahmin etmeden nereye gidebileceğim ve uygulayabileceğim yere uygulamaya yönelik makul derecede eksiksiz bir yol haritası. yani kavramsal olarak tamamlanabilir ve / veya bir veritabanı yapısını, vb.

Bonus: ABAC, nispeten küçük bir izin ihtiyacı için uygun bir yol mudur? Örneğin 70-200 kişiyi yönetmek ve 150 - 450 varlığa erişim? Bunun yerine ACL / RBAC'a bağlı kalmak daha mı iyi olacak?

Bir ABAC uygulaması, ACL / RBAC'den daha karmaşıktır. Bazı çerçeveler, ikincisiyle başa çıkmak için size altyapı parçaları bile verir. İnsanlar ve varlıklar nispeten az sayıda ve sabit sayıda rol / kategori altında gruplandırılabiliyorsa, muhtemelen ACL / RBAC'a bağlı kalmak en iyisidir. İzinler kişiden kişiye çok farklıysa, ABAC daha iyi ve daha esnek bir çözüm sağlayabilir.

ABAC yolunda ilerlemeyi seçerseniz, yapmanız gereken ilk şey XACML standardını okumak ve anlamak için biraz zaman harcamaktır . Belgede sağlanan örneklerde XACML uyumlu sözdizimi kullanılmaktadır ve ilk başta çiğnemek biraz zordur. Standart uyumlu bir çözüm uygulamak istemediğiniz için tahmin ediyorum, bu yüzden sadece genel fikirlere ihtiyacınız var.

Kavramlar

XACML yaklaşık 4 kavram ve özelliklerini içerir: konular , eylemler , kaynaklar ve çevre . Birkaç tane daha var, ama bunlar en önemlileridir. Diğer her şey onların üzerine inşa edilmiştir. Eğer bu kavramlarla bir cümle kuracak olsaydım, şu konular boyunca bir şey olabilir: konular belirli bir ortamdaki kaynaklar üzerinde eylemler gerçekleştirir . Bunu senaryonuza uygulamak şöyle bir şeye dönüşecektir:

• Leslie fiyat yöneticisi web sayfasını açar.
• Leslie fiyat yöneticisi web sayfasını kullanarak bir seyahat fiyatı oluşturur.

Özellik koleksiyonu

Yapmamız gereken ilk şey, yukarıda belirtilen kavramların ilgili özelliklerini toplamaktır. İdeal olarak, XACML göze çarpmayacak ve sadece sistemin doğal olarak sağladığı şeye güvenmeye çalıştığı için belirli bir özellik atamamalısınız. Ve böylece:

konu

Sisteminizdeki herhangi bir aktör, kişi veya hizmet olsun. Bizim konumuz Leslie. Leslie'yi benzersiz bir şekilde tanımlamak için hangi özellikler gereklidir? Muhtemelen Aşağıdakilerden bazı: first name, last name, e-mail, ssn, company id, position(s).

Aksiyon

Denekler tarafından gerçekleştirilen herhangi bir işlem. Standart CRUD işlemleri veya daha karmaşık bir şey olabilir. Bizim eylemlerimiz open/viewve create. Bu eylemlerin özellikleri, kullandığınız web uygulama çerçevesine bağlı olarak farklı olabilir. Kaynağa geldiğimizde bunun hakkında daha fazla konuşacağız.

Kaynak

Kendini açıklayıcı. Kaynaklarımız price manager page, travel pricesve the newly created price. Gerçekten isterseniz daha fazlası olabilir. Kullanıcıların gerçekleştiremediği eylemleri gizlemek isteyebilirsiniz. Örneğin. create price button/ gösterilen kullanıcı fiyatları oluşturmak için izinlere sahip olup olmadığına bağlı gizli olabilir bir kaynak olabilir. Bir kullanıcının fiyat listesini görmesinin tek yolu bu sayfa üzerinden olabileceğinden, yetkilendirmeyi yığının aşağısına doğru ilerletmekten ziyade bu düzeyde uygulamak iyi bir fikir olabilir.

Kaynaklara erişim, özellikle bir veritabanından gelenler için, uygulanması en karmaşık olanıdır. Daha ince taneli seçenek, satır düzeyinde güvenliktir. Bazı veritabanlarının belirli bir derece desteği vardır. Bazı XACML uygulayıcıları, bir SQL üst kümesi oluşturmak kadar ileri gitti. Bu gerçekten yetkilendirme ihtiyaçlarınıza bağlıdır, ancak yapmak istemediğiniz tek şey her şeyi bir tablodan çekmek ve sonra ne göstereceğinize karar vermektir. Kaynakları izin kümelerine göre gruplandırabilir, bir API'nın arkasına soyutlayabilir ve API uç noktalarında yetkilendirmeyi uygulayabilirsiniz.

çevre

Düzgün tanımlayamıyorum (XACML'nin de uygun bir tanımı yok) ama diyelim ki tüm bunların gerçekleştiği "kabarcık". Bunlar: web application, web server, operating system, browser, office. Sen gibi özelliklerini ayıklamak olabilir: ip address, time of day, user locale, user agent, operating system version. Bunları, uygulamanız tarafından desteklenmeyen ortamlardan (ör. Eski tarayıcılar, eski işletim sistemleri, ağınızın dışındaki bilgisayarlar, çalışma saatleri dışındaki erişim) kullanıcı erişimini engellemek için bile kullanabilirsiniz.

Yetkilendirme talebi

Gerekli tüm öznitelikleri topladıktan sonra, bunları bir yetkilendirme isteğinde toplar ve bu özniteliklerin değerlerine göre yetkilendirme kararları verebilecek bir kuruluşa iletiriz. XACML lingua'da bu öznitelikleri topladığınız ve daha sonra alınan kararları uyguladığınız yere politika uygulama noktası (PEP) ve nokta verme kararlarına politika karar noktası (PDP) denir . Özellik değerlerinin alındığı konumlara politika bilgi noktası s (PIP) denir . PEP'ler, PDP'ler ve PIP'ler uygulamanızın bir parçası olabilir ve harici sistemler olabilir. XACML standardında birbirleriyle nasıl iletişim kurduklarını gösteren bir şema bulabilirsiniz.

Karar süreci

Karar alma süreci kurallara dayanmaktadır . Kurallar halinde gruplandırılabilir politikaları daha da içine toplanabilir politika grubuna . Bunların her birinin bir hedefi var . Hedef, yetkilendirme isteği için kurallardan herhangi birinin geçerli olup olmadığına karar vermek için kullanılır. Bir filtre olarak düşünün. Hedef, özellik adları ve değerleri kullanılarak oluşturulan koşulları içerir. Örneğin, uygulamanızın kuralları aşağıdaki gibi bir grupta toplanabilir:

Web uygulaması (ilke kümesi)
| - target: application-name == "Web uygulaması"
`- Sürüm 1.0 (politika kümesi)
    | - hedef: uygulama sürümü == "1.0"
    `- Fiyat yöneticisini görüntüle (politika)
        | - target: web-page-name == "fiyat yöneticisi" && action-name == "görünüm"
        `- Leslie fiyat yöneticisini görebilir (kural)
            | - hedef: konu-adı == "Leslie"
            `- izin: izin ver

PDP, yukarıdaki ayardaki her şeyi yetkilendirme isteğindeki özellik değerleriyle eşleştirecektir. Bununla eşleşen kurallar yoksa ne olur PDP'nizin uygulanmasına bağlıdır. PDP bir karar (sonra allow, denyya da not-applicable) o verilmesi veya kaynak erişimi yasaklamak ile buna göre hareket PEP geri gönderir. Tepki ile birlikte PDP listesini gönderebilir obligationsve advicesPEP şırası olduğunu veya icra sürecinde yerine getirmelidir. Kuralların nasıl saklandığına (metin dosyaları veya veritabanı) bağlı olarak, yönetici bunları uygun gördüğü şekilde değiştirmek için standart bir metin düzenleyici veya özel bir düzenleme uygulaması kullanabilir. Fiyatları yöneticiye iptal etme Leslie erişim basitçe izin değişen devam allowetmekdeny, PEP'in işini yapmasına izin verdi.

zorlama

Bu büyük ölçüde teknoloji yığınınıza bağlıdır. Bazı web çerçevelerinin doğal uygulama noktaları vardır (örn. ASP.NET MVC'nin özellik filtreleri vardır). İş katmanlarınızın bu tür uygulama noktalarını tanımlaması gerekebilir. Hizmet (mikro hizmetler) son noktalarında veya kullanıcı arabirimi düzeyinde uygulama yapmayı daha kolay buldum.

Diğer avantajlar

Bunu uygulamanın güzel bir yan etkisi, başka amaçlar için kullanılabilecek oldukça zengin bir denetim izi bulmanızdır.