Grup ve rol (Gerçek bir fark var mı?)

Biri bana söyleyebilir mi, grup ve rol arasındaki gerçek fark nedir? Bunu bir süredir anlamaya çalışıyorum ve daha fazla bilgi okudukça, bunun sadece insanların kafasını karıştırmak için ortaya çıktığı ve gerçek bir fark olmadığı hissine kapılıyorum. Her ikisi de diğerinin işini yapabilir. Kullanıcıları ve erişim haklarını yönetmek için her zaman bir grup kullandım.

Son zamanlarda, bir grup kullanıcının olduğu bir yönetim yazılımıyla karşılaştım. Her kullanıcı bir modül atayabilir (tüm sistem modül adı verilen birkaç parçaya bölünmüştür, örn. Yönetim modülü, Anket modülü, Siparişler modülü, Müşteri modülü). Üstelik, her modülde, her kullanıcı için izin verilebilecek veya reddedilebilecek bir işlevler listesi vardır. Diyelim ki, John Smith adlı bir kullanıcı Siparişler modülüne erişebilir ve herhangi bir siparişi düzenleyebilir, ancak herhangi birini silme hakkı vermemiş.

Aynı yetkinliğe sahip daha fazla kullanıcı olsaydı, bunu yönetmek için bir grup kullanırdım. Bu tür kullanıcıları aynı grupta toplayıp modüllere erişim haklarını ve bunların işlevlerini gruba atardım. Aynı gruptaki tüm kullanıcılar aynı erişim haklarına sahip olacaktır.

Neden ona rol değil de grup diyorsunuz? Bilmiyorum, sadece öyle hissediyorum. Bana öyle geliyor ki, gerçekten önemli değil:] Ama yine de gerçek farkı bilmek istiyorum.

Bunun grup yerine rol olarak adlandırılması gerektiğine dair herhangi bir öneriniz var mı?

Google Senin Arkadaşın :)

Her neyse, rol ve grup arasındaki ayrım, bilgisayar güvenliği kavramlarından kaynaklanıyor (basitçe kaynak yönetiminin aksine). Prof. Ravi Sandhu, roller ve gruplar arasındaki anlamsal farkın ufuk açıcı bir kapsamını sağlar.

http://profsandhu.com/workshop/role-group.pdf

Grup, gruba (ve kullanıcılara geçişli olarak) atanmış belirli bir izin kümesine sahip kullanıcılar topluluğudur. Rol, bir izinler koleksiyonudur ve bir kullanıcı, bu rol altında hareket ettiğinde bu izinleri etkin bir şekilde devralır.

Tipik olarak, grup üyeliğiniz oturum açma süreniz boyunca kalır. Diğer yandan bir rol, belirli koşullara göre etkinleştirilebilir. Mevcut göreviniz 'tıbbi personel' ise, belirli bir hastanın tıbbi kayıtlarından bazılarını görebilirsiniz. Bununla birlikte, rolünüz aynı zamanda 'hekim' ise, sadece 'tıbbi personel' rolüne sahip bir kişinin görebileceğinin ötesinde ek tıbbi bilgileri görebilirsiniz.

Roller günün saatine, erişim yerine göre etkinleştirilebilir. Roller ayrıca özniteliklerle geliştirilebilir / ilişkilendirilebilir. 'Hekim' olarak ameliyat ediyor olabilirsiniz, ancak benimle bir 'birincil hekim' niteliğiniz veya ilişkiniz yoksa ('hasta' rolü olan bir kullanıcı), o zaman tıbbi geçmişimin tamamını göremezsiniz.

Tüm bunları gruplarla yapabilirsiniz, ancak yine gruplar rol veya aktiviteye değil kimliğe odaklanma eğilimindedir. Ve az önce açıklanan türden güvenlik unsurları, kendilerini öncekinden çok sonraya daha iyi uyma eğilimindedir.

Çoğu durumda, bir şeyleri birlikte sınıflandırmak için (ve daha fazlası değil), gruplar ve roller aynı şekilde çalışır. Bununla birlikte, gruplar kimliğe dayalıdır, oysa roller, etkinliği sınırlandırmak içindir. Ne yazık ki, işletim sistemleri, rolleri gruplar olarak ele alarak farkı bulanıklaştırma eğilimindedir.

İşletim sistemi düzeyinde uygulanan (tipik olarak gruplarla eşanlamlı olan) `` roller '' yerine uygulama veya sisteme özgü anlambilim ( Oracle rollerinde olduğu gibi) taşıyan uygulama veya sistem düzeyindeki rollerle çok daha net bir ayrım görürsünüz .

Rollerde ve rol tabanlı erişim kontrol modellerinde sınırlamalar olabilir (tabii ki herhangi bir şeyde olduğu gibi):

http://www.lhotka.net/weblog/CommentView,guid,9efcafc7-68a2-4f8f-bc64-66174453adfd.aspx

Yaklaşık on yıl önce, rol tabanlı erişim denetiminden çok daha iyi ayrıntı düzeyi sağlayan öznitelik tabanlı ve ilişkiye dayalı erişim denetimi üzerine bazı araştırmalar gördüm. Ne yazık ki, bu alemde yıllardır pek etkinlik görmedim.

Roller ve gruplar arasındaki en önemli fark, rollerin tipik olarak zorunlu bir erişim denetimi (MAC) mekanizması uygulamasıdır. Kendinizi (veya başkalarını) rollere atayamazsınız. Bir rol yöneticisi veya rol mühendisi bunu yapar.

Bu, yüzeysel olarak, bir kullanıcının kendisini bir gruba atayabileceği / atayabileceği (tabii ki sudo aracılığıyla) UNIX gruplarına benzer. Gruplar bir güvenlik mühendisliği sürecine göre atandığında, ayrım biraz bulanıklaşır.

Bir diğer önemli özellik, gerçek RBAC modellerinin karşılıklı olarak dışlayıcı roller kavramını sağlayabilmesidir. Bunun aksine, kimliğe dayalı gruplar eklemelidir - bir müdürün kimliği, grupların toplamıdır (veya birleşimidir).

Gerçek RBAC tabanlı bir güvenlik modelinin bir başka özelliği, belirli bir rol için oluşturulan öğelere, bu rol altında hareket etmeyen biri tarafından tipik olarak geçişli olarak erişilememesidir.

Öte yandan, isteğe bağlı erişim denetimi (DAC) modeli altında (Unix'teki varsayılan model), bu tür garantiyi yalnızca gruplarla alamazsınız. BTW, bu grupların veya Unix'in bir sınırlaması değil, kimliğe dayalı (ve geçişli olarak, kimliğe dayalı gruplarla) DAC modellerinin bir sınırlamasıdır.

Umarım yardımcı olur.

=======================

Simon'ın iyi yanıtını gördükten sonra biraz daha eklemek. Roller, izinleri yönetmenize yardımcı olur. Gruplar, nesneleri ve konuları yönetmenize yardımcı olur. Dahası, roller 'bağlamlar' olarak düşünülebilir. 'X' rolü, Y öznesinin Z nesnesine nasıl eriştiğini (veya erişmediğini) yöneten bir güvenlik bağlamını tanımlayabilir.

Bir diğer önemli ayrım (veya ideal), bir uygulama, sistem veya işletim sisteminde gerekli ve / veya açık olan rolleri, bağlamları düzenleyen bir rol mühendisinin, bir kişinin olmasıdır. Bir rol mühendisi tipik olarak aynı zamanda bir rol yöneticisidir (veya sistem yöneticisi). Dahası, bir rol mühendisinin gerçek rolü (amaçlanan değildir) yönetim değil, güvenlik mühendisliği alanındadır.

Bu, RBAC tarafından resmileştirilmiş yeni bir gruptur (nadiren kullanılsa bile), tipik olarak grup yetenekli sistemlerde bulunmayan bir gruptur.

Bir grup, kullanıcıları organize etmenin bir aracıdır, oysa bir rol genellikle hakları organize etmenin bir yoludur.

Bu, çeşitli şekillerde faydalı olabilir. Örneğin, bir rol içinde gruplandırılmış bir dizi izin, bir grup gruba veya gruplarından bağımsız olarak bir kullanıcı kümesine atanabilir.

Örneğin, bir CMS'nin Gönderiyi oku, Gönderi oluştur, Gönderiyi düzenle gibi bazı izinleri olabilir. Bir Düzenleyici rolü Okuma ve Düzenleme yapabilir, ancak oluşturamaz (nedenini bilmiyorum!). Bir gönderi Oluşturma ve Okuma vb. Olabilir. Bir grup yönetici editör rolüne sahip olabilirken, BT'deki bir kullanıcı, yöneticiler grubunda olmayan bir kullanıcı da editör rolüne sahip olabilir. grup yapmaz.

Dolayısıyla, basit bir sistemde gruplar ve roller genellikle birbirine yakın olsa da, bu her zaman böyle değildir.

Roller ve Gruplar arasında anlamsal fark olmasına rağmen (yukarıda diğer cevaplarla açıklandığı gibi), teknik olarak Roller ve Gruplar aynı görünmektedir. Hiçbir şey İzinleri doğrudan Kullanıcılara ve Gruplara atamanızı engellemez (bu, bir ince ayar erişim kontrolü olarak düşünülebilir). Benzer şekilde, Kullanıcıya bir Rol atandığında, kullanıcı bir Grubun Üyesi olduğunda aynı anlamda bir rol Üyesi olarak kabul edilebilir.

Böylece Roller ve Gruplar arasında gerçek bir fark kalmayabiliriz. Kullanıcıları VE / VEYA İzinleri gruplamak için her ikisi de düşünülebilir. Dolayısıyla, fark yalnızca anlamsaldır: - Eğer izinleri gruplamak için anlamsal olarak kullanılıyorsa, o zaman bir Rol'dür; - Kullanıcıları gruplamak için anlamsal olarak kullanılıyorsa, o zaman bir Gruptur. Teknik olarak hiçbir fark yok.

Bir "grup", bir kullanıcı koleksiyonudur. "Rol", bir izinler koleksiyonudur. Bu , grup alfa, grup beta'yı içerdiğinde , alfa'nın tüm kullanıcıları beta sürümünden ve betanın tüm izinleri alfa'dan aldığı anlamına gelir . Tersine, betanın rol alfa rolünü içerdiğini ve aynı sonuçların geçerli olacağını söyleyebilirsiniz .

Bir somut bir örneği daha net şeyler yapar. "Müşteri desteği" ve "kıdemli müşteri desteği" ni düşünün. Bu koleksiyonları gruplar olarak düşünürseniz, müşteri destek kullanıcılarının kıdemli müşteri destek kullanıcılarını "içerdiği" açıktır. Ancak, onlara roller olarak bakarsanız, o zaman üst düzey müşteri desteği izinlerinin müşteri destek izinlerini "içerdiği" açıktır.

Teorik olarak, tek bir koleksiyon türüne sahip olabilirsiniz. Ancak, "koleksiyon alfa, koleksiyon beta içerir" deseniz belirsiz olur . Bu durumda, alfa'daki kullanıcıların beta sürümünde (bir rol gibi) veya beta sürümündeki kullanıcıların alfa'da (bir grup gibi) olup olmadığını anlayamazsınız. "İçerir" gibi terminolojiyi ve ağaç görünümleri gibi görsel öğeleri belirsiz hale getirmek için, çoğu rbac sistemi, söz konusu koleksiyonun bir "grup" mu yoksa bir "rol" mü olduğunu en azından tartışma amacıyla belirtmenizi gerektirir.

Bazı benzetmeler yardımcı olabilir. Grup alfa, grup beta'nın bir alt kümesi olduğunda , küme teorisi açısından çerçevelendiğinde, izinler alfa, izinlerin bir üst kümesidir. Şecere ile karşılaştırıldığında , gruplar bir torun ağacı gibiyse, o zaman roller bir atalar ağacı gibidir.

NOT - aşağıdaki saçmalıklar, yalnızca bir kuruluş içinde güvenliği empoze etmeye - yani bilgiye erişimi sınırlamaya çalışıyorsa anlamlıdır ...

Gruplar deneyseldir - "ne" sorusuna cevap verirler. Var olan erişim gerçekliğini yansıtmaları açısından "var" dır. BT çalışanları grupları sever - çok gerçek ve tanımlamaları kolaydır. Sonunda, tüm erişim kontrolü nihayetinde (hepimiz ortaokulda öğrendiğimiz gibi) "Hangi gruba dahilsiniz?" Sorusunu yanıtlamaya geçer.

Ancak roller daha normatiftir - “ne olması gerektiğine” rehberlik ederler. İyi yöneticiler ve İK "rolleri" sever - cevap vermezler - "Neden?" Sorusunu sorarlar . Ne yazık ki, roller de belirsiz olabilir ve bu "belirsizlik" (BT) insanları delirtebilir.

Eğer yukarıdaki tıbbi örnek kullanmak için rol "birinci basamak hekimi" nin daha fazla haklara (fazla gruba yani erişime) sahip rolü bir "x-ışını teknisyeni" halkı (yöneticiler ve İK) karar, bunun nedeni neden olduğunu olması gerekiyordu. Bu anlamda onlar bir örgütün "kolektif bilgeliğidir".

Diyelim ki bir doktora, hastaların mali kayıtlarına erişim (erişimi olan bir gruba üyelik) verildi. Bu dışarıdan normal bir doktorun "rol" ve gerektiği tartışılabilir. Bu nedenle, hiç kimse (ne kadar nitelikli olursa olsun) tüm gruplara tam erişim hakkına sahip olmamalıdır - bu, suistimalleri iktidara davet eder. Bu yüzden "rol mühendisliği" çok önemlidir - onsuz, sadece grup erişimi çok şeker gibi dağıtılır. İnsanlar, çok fazla gücün tehlikeleri konusunda tartışmadan grup erişimi toplayacak (ve bazen kalabalık olacak).

Sonuç olarak, iyi tanımlanmış rollerin bilgeliği, kaçak grup erişiminin tehlikelerini hafifletmeye yardımcı olur. Bir organizasyondaki herkes belirli bir gruba erişim için tartışabilir. Ancak bu erişim sağlandıktan sonra nadiren vazgeçilir. Rol mühendisliği (iyi tanımlanmış grup açıklamaları ve yetkilendirilmiş grup erişim yöneticileri gibi en iyi uygulamaların yanı sıra) bir organizasyon içindeki çıkar çatışmalarını sınırlayabilir, karar verme sürecini merkezden uzaklaştırabilir ve güvenlik yönetiminin daha rasyonel olmasına yardımcı olabilir.

Önceki cevapların hepsi harika. Belirtildiği gibi, Grup ve Rol kavramı teknikten çok kavramsaldır. Grupların kullanıcıları kapsamak için (bir kullanıcı birden fazla grupta olabilir: yani Joe, Yöneticiler grubunda ve BT grubunda [kendisi BT'de bir yöneticidir]) ve geniş ayrıcalıklar atamak için kullanıldığını kabul ettik. (yani, mag kart sistemimiz, BT grubundaki tüm kullanıcıların sunucu odasına erişmesine izin verir). Roller artık belirli kullanıcılara ayrıcalıklar eklemek için kullanılıyordu (yani, BT grubundaki kişiler sunuculara RDP uygulayabilir ancak kullanıcıları atayamaz veya izinleri değiştiremez, BT grubundaki Yönetici rolüne sahip kişiler kullanıcıları atayabilir ve izinleri değiştirebilir). Roller diğer rollerden de oluşturulabilir (Joe, kullanıcıları / ayrıcalıkları eklemek için Yönetici rolüne ve ayrıca sunucudaki DBMS'de veritabanı değişiklikleri yapmak için DBA rolüne sahiptir). Roller, bir kullanıcı için çok özel olabilen bireysel kullanıcı Rolleri (örn. JoesRole) oluşturabileceğimiz için çok özel olabilir. Özetlemek gerekirse, kullanıcıları yönetmek ve ayrıcalıkları yönetmek için genel Rolleri ve Rolleri atamak için Grupları kullanıyoruz. Bu da kümülatiftir. Kullanıcının bulunduğu Grup, çok genel ayrıcalıklar verecek (yani BT grubu kullanıcıları sunucularda oturum açmalarına izin veren SunucuRDP rolüne sahiptir) ve böylece kullanıcıya atanan Rollere (veya mevcut Rollerin bir listesine) sahip olabilir. Ardından, kullanıcının ait olduğu tüm Roller, son söz hakkına sahip olan son Rol ile tanımlandıkları sıraya göre eklenecektir (Roller, ayrıcalıklara İzin Verebilir, Reddetebilir veya uygulayamaz, böylece her Rol uygulandığında, bir ayrıcalık için önceki ayarları geçersiz kılar ya da değiştirmeyin). Tüm Grup seviyesindeki Roller ve Kullanıcı seviyesindeki Roller uygulandıktan sonra,

Kullanıcılar, herhangi bir sistemde oynadıkları sorumluluğa göre Rollere atanır. Örneğin, Satış Yöneticisi rolündeki kullanıcılar, bir ürün için ek indirim sağlamak gibi belirli eylemleri gerçekleştirebilir.

Gruplar, güvenliğin kolay yönetimi için bir sistemdeki kullanıcıları veya rolleri 'gruplamak' için kullanılır. Örneğin, "Liderlik Grubu" adlı bir grup, üyelerini Yöneticiler, Yöneticiler ve Mimarlar rollerinden ve bu rollerin dışında olan bireysel kullanıcılardan alabilir. Artık bu gruba belirli ayrıcalıklar atayabilmelisiniz.

Grupların ve Rollerin Amacı uygulamalarda değişiklik gösterir, ancak esas olarak anladığım kadarıyla Gruplar (kullanıcı grubu) statikken Roller (izinler kümesi) ilkelerle dinamiktir, örneğin (9'dan 6'ya kadar) a grup veya kullanıcı bu role sahip olabilir, ancak bu değil.

Gruba bir rol atayabilirsiniz. Kullanıcıyı gruba atayabilir ve herhangi bir rol kullanıcısında tek bir kullanıcıya rol atayabilirsiniz. Anlam. Jean Doe, SharePoint'ten raporlarımızı yazdırmaya izin veren ReportWritter rolüyle SalesDeptartment Grubunda olabilir, ancak SalesDepartment grubunda diğerleri ReportWritter rolüne sahip olmayabilir. - Diğer bir deyişle, roller, atanmış gruplarla özel ayrıcalıklardır. Umarım bu herhangi bir sahneyi yapar.

Alkış !!!