그룹 대 역할 (실제 차이점이 있습니까?)

누구든지 말해 줄 수 있습니까? 그룹과 역할의 실제 차이점은 무엇입니까? 나는 이것을 한동안 알아 내려고 노력 해왔고 내가 더 많은 정보를 읽을수록 이것이 사람들을 혼란스럽게하고 실제적인 차이가 없다는 것을 더 많이 느끼게됩니다. 둘 다 상대방의 일을 할 수 있습니다. 저는 항상 그룹을 사용하여 사용자와 액세스 권한을 관리했습니다.

최근에 사용자가 많은 관리 소프트웨어를 접했습니다. 각 사용자는 모듈을 할당 할 수 있습니다 (전체 시스템은 관리 모듈, 설문 조사 모듈, 주문 모듈, 고객 모듈과 같은 모듈이라고하는 몇 가지 부분으로 나뉩니다). 또한 각 모듈에는 각 사용자에 대해 허용 또는 거부 할 수있는 기능 목록이 있습니다. 따라서 사용자 John Smith가 주문 모듈에 액세스하고 모든 주문을 편집 할 수 있지만 삭제할 수있는 권한을 부여하지 않았다고 가정 해 보겠습니다.

동일한 역량을 가진 사용자가 더 많으면 그룹을 사용하여 관리합니다. 이러한 사용자를 동일한 그룹으로 모아 모듈 및 해당 기능에 대한 액세스 권한을 그룹에 할당합니다. 동일한 그룹의 모든 사용자는 동일한 액세스 권한을 갖습니다.

역할이 아닌 그룹이라고 부르는 이유는 무엇입니까? 모르겠어요, 그냥 그렇게 느낍니다. 단순히 그것이 정말로 중요하지 않은 것 같습니다. :] 그러나 나는 여전히 진짜 차이점을 알고 싶습니다.

왜 이것이 그룹이나 그 반대의 역할이라고 부르는 것이 좋을까요?

Google은 당신의 친구입니다 :)

어쨌든 역할과 그룹의 구분은 컴퓨터 보안의 개념에서 비롯됩니다 (단순한 리소스 관리가 아님). Ravi Sandhu 교수는 역할과 그룹 간의 의미 론적 차이에 대한 중요한 범위를 제공합니다.

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

그룹은 그룹 (그리고 사용자에게 전 이적으로) 할당 된 주어진 권한 집합을 가진 사용자 모음입니다. 역할은 권한 모음이며 사용자는 해당 역할에 따라 작업 할 때 이러한 권한을 효과적으로 상속합니다.

일반적으로 그룹 멤버십은 로그인하는 동안 유지됩니다. 반면 특정 조건에 따라 역할을 활성화 할 수 있습니다. 귀하의 현재 역할이 '의료 직원'인 경우 해당 환자의 의료 기록 중 일부를 볼 수 있습니다. 그러나 자신의 역할이 '의사'인 경우 '의료진'역할 만하는 사람이 볼 수있는 것 이상의 추가 의료 정보를 볼 수 있습니다.

역할은 시간, 액세스 위치에 따라 활성화 될 수 있습니다. 역할은 속성과 강화 / 연결될 수도 있습니다. 당신은 '의사'로 운영 될 수 있지만, '주치의'속성이나 나와 ( '환자'역할을 가진 사용자)와의 관계가 없다면 나의 전체 병력을 볼 수 없습니다.

그룹으로 모든 것을 할 수 있지만 그룹은 역할이나 활동이 아닌 정체성에 초점을 맞추는 경향이 있습니다. 그리고 방금 설명한 보안 측면의 유형은 전자보다 나중 측면에 더 잘 부합하는 경향이 있습니다.

많은 경우, 사물을 함께 분류하는 데 사용하는 경우 (그 이상은 아님) 그룹과 역할이 동일하게 작동합니다. 그러나 그룹은 ID를 기반으로하는 반면 역할은 활동을 구분하기위한 것입니다. 불행히도 운영 체제는 역할을 그룹으로 취급하여 구분을 모호하게 만드는 경향이 있습니다.

OS 수준 (일반적으로 그룹과 동의어)에서 구현 된 '역할'과 달리 애플리케이션 또는 시스템 특정 의미 (예 : Oracle 역할 )를 전달하는 애플리케이션 또는 시스템 수준 역할과 훨씬 더 분명한 차이를 볼 수 있습니다 .

역할 및 역할 기반 액세스 제어 모델에 제한이있을 수 있습니다.

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

약 10 년 전에 역할 기반 액세스 제어보다 훨씬 더 세분화 된 속성 기반 및 관계 기반 액세스 제어에 대한 연구를 보았습니다. 불행히도 저는 그 영역에서 몇 년 동안 많은 활동을 보지 못했습니다.

역할과 그룹의 가장 중요한 차이점은 역할은 일반적으로 필수 액세스 제어 (MAC) 메커니즘을 구현한다는 것입니다. 자신 (또는 다른 사람)을 역할에 할당 할 수 없습니다. 역할 관리자 또는 역할 엔지니어가이를 수행합니다.

이것은 표면적으로 사용자가 자신을 그룹에 할당 할 수있는 UNIX 그룹과 유사합니다 (물론 sudo를 통해). 그러나 보안 엔지니어링 프로세스에 따라 그룹이 할당되면 구분이 약간 모호합니다.

또 다른 중요한 특징은 진정한 RBAC 모델이 상호 배타적 인 역할의 개념을 제공 할 수 있다는 것입니다. 반대로 신원 기반 그룹은 가산 적입니다. 주체의 신원은 그룹의 합 (또는 결합)입니다.

진정한 RBAC 기반 보안 모델의 또 다른 특징은 특정 역할에 대해 생성 된 요소는 일반적으로 해당 역할에 따라 행동하지 않는 사람이 전 이적으로 액세스 할 수 없다는 것입니다.

반면 DAC (임의 액세스 제어) 모델 (Unix의 기본 모델)에서는 그룹만으로는 이러한 유형의 보증을 얻을 수 없습니다. BTW, 이것은 그룹 또는 Unix의 제한이 아니라 신원을 기반으로 한 DAC 모델의 제한입니다 (그리고 전 이적으로 신원 기반 그룹으로).

도움이 되었기를 바랍니다.

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

Simon의 잘된 반응을 본 후 더 추가합니다. 역할은 권한을 관리하는 데 도움이됩니다. 그룹은 개체와 주제를 관리하는 데 도움이됩니다. 또한 역할을 '컨텍스트'라고 생각할 수 있습니다. 역할 'X'는 주체 Y가 객체 Z에 액세스하거나 액세스하지 않는 방법을 규정하는 보안 컨텍스트를 설명 할 수 있습니다.

또 다른 중요한 차이점 (또는 이상)은 애플리케이션, 시스템 또는 OS에서 필요하거나 분명한 역할, 컨텍스트를 엔지니어링하는 역할 엔지니어가 있다는 것입니다. 역할 엔지니어는 일반적으로 역할 관리자 (또는 sysadmin)이기도합니다 (그럴 필요는 없음). 또한 역할 엔지니어의 진정한 역할 (말장난이 아님)은 관리가 아닌 보안 엔지니어링 영역에 있습니다.

이것은 RBAC에 의해 공식화 된 새로운 그룹으로 (거의 사용되지 않더라도) 일반적으로 그룹 가능 시스템에 존재하지 않았습니다.

그룹은 사용자를 구성하는 수단이지만 역할은 일반적으로 권한을 구성하는 수단입니다.

이것은 여러 가지 방법으로 유용 할 수 있습니다. 예를 들어 역할로 그룹화 된 권한 집합은 그룹 집합 또는 그룹과 독립적으로 사용자 집합에 할당 될 수 있습니다.

예를 들어 CMS에는 게시물 읽기, 게시물 작성, 게시물 편집과 같은 일부 권한이있을 수 있습니다. 편집자 역할은 읽고 편집 할 수 있지만 만들 수는 없습니다 (이유를 모릅니다!). 게시물을 작성하고 읽을 수 있습니다. 관리자 그룹에는 편집자 역할이있을 수 있으며, 관리자 그룹에 속하지 않은 IT 사용자는 나머지는 편집자 역할도 가질 수 있습니다. 그룹은하지 않습니다.

따라서 단순한 시스템에서 그룹과 역할은 종종 밀접하게 정렬되지만 항상 그런 것은 아닙니다.

역할과 그룹 사이에는 의미 론적 차이가 있지만 (위의 다른 답변에서 설명했듯이) 기술적으로 역할과 그룹은 동일하게 보입니다. 사용자 및 그룹에 직접 권한을 할당하는 것을 방해하는 것은 없습니다 (미세 조정 액세스 제어로 간주 될 수 있음). 마찬가지로 사용자에게 역할이 할당되면 사용자가 그룹의 구성원이 될 때와 마찬가지로 역할 구성원으로 간주 될 수 있습니다.

따라서 역할과 그룹간에 실질적인 차이가 없습니다. 둘 다 사용자 및 / 또는 권한을 그룹화하는 데 고려할 수 있습니다. 따라서 차이점은 의미론적일뿐입니다. — 권한 그룹화에 의미 론적으로 사용되는 경우 역할이됩니다. — 사용자 그룹화에 의미 상 사용되는 경우 그룹이됩니다. 기술적으로 차이가 없습니다.

"그룹"은 사용자 모음입니다. "역할"은 권한 모음입니다. 즉 , alpha 그룹에 beta 그룹이 포함되면 alpha는 beta의 모든 사용자를 받고 beta는 alpha의 모든 권한을받습니다. 반대로 역할 베타에는 역할 알파가 포함 되며 동일한 결론이 적용된다고 말할 수 있습니다.

구체적인 예는 일을 더 명확합니다. "고객 지원"및 "상위 고객 지원"을 고려하십시오. 이러한 컬렉션을 그룹으로 생각하면 고객 지원 사용자가 수석 고객 지원 사용자를 "포함"한다는 것이 분명합니다. 그러나 이들을 역할로 보면 고위 고객 지원 권한에 고객 지원 권한이 "포함"된다는 것이 분명합니다.

이론적으로는 하나의 컬렉션 유형 만 가질 수 있습니다. 그러나 "컬렉션 알파에는 컬렉션 베타가 포함된다"라고 말하면 모호합니다 . 이 경우 알파의 사용자가 베타 상태인지 (예 : 역할) 베타 사용자가 알파 상태인지 (예 : 그룹) 알 수 없습니다. "포함"과 같은 용어와 트리 뷰와 같은 시각적 요소를 모호하지 않게 만들기 위해 대부분의 rbac 시스템에서는 적어도 논의를 위해 문제가되는 컬렉션이 "그룹"인지 "역할"인지 지정해야합니다.

몇 가지 비유 가 도움이 될 수 있습니다. 집합 이론의 관점에서 보면 그룹 알파가 그룹 베타의 하위 집합 인 경우 권한 알파는 권한 베타의 상위 집합입니다. 계보 와 비교 그룹이 후손의 나무와 같으면 역할은 조상의 나무와 같습니다.

참고-다음 사항은 조직 내에서 보안을 강화하려는 경우에만 의미가 있습니다. 즉, 정보에 대한 액세스를 제한하려는 경우 ...

그룹은 경험적이며 "무엇"에 대한 질문에 답합니다. 기존의 액세스 현실을 반영한다는 점에서 "is"입니다. IT 사람들은 그룹을 좋아합니다. 매우 문자적이고 정의하기 쉽습니다. 결국 모든 액세스 제어는 궁극적으로 (우리 모두가 중학교에서 배운 것처럼 ...) "당신은 어떤 그룹에 속합니까?"라는 질문에 답하는 것으로 넘어갑니다.

그러나 역할은 더 규범 적이며 "되어야 할 것"을 안내합니다. 좋은 관리자와 HR의 사랑 "역할"- 그들은 대답하지 않는다 - 그들은 질문 의 질문 "왜?" 안타깝게도 역할도 모호 할 수 있으며 "모호함"은 사람들을 미치게 만들 수 있습니다.

경우, 위의 의료 예제를 사용하려면 역할 "주치의"의이보다 더 많은 권리 (자세한 그룹 즉, 액세스)이 역할 에 "X 레이 기술자"의를 사람들 (관리자, HR)를 결정하기 때문에, 이것이 왜 그 일어날 필요가 있습니다. 그런 의미에서 그들은 조직의 "집단적 지혜"입니다.

의사에게 환자의 재무 기록에 대한 액세스 권한 (액세스 권한이있는 그룹의 구성원)이 부여되었다고 가정 해 보겠습니다. 이것은 일반적으로 의사의 "역할"밖에 있으며 토론 되어야 합니다. 따라서 아무리 자격이 있더라도 누구도 모든 그룹에 대한 완전한 접근 권한을 가져서는 안됩니다. 이것이 "역할 엔지니어링"이 매우 중요한 이유입니다. 이것이 없으면 그룹 액세스 권한이 너무 많은 사탕처럼 나눠집니다. 사람들은 너무 많은 권력의 위험에 대해 논의하지 않고 그룹 액세스를 수집 (때로는 무리) 할 것입니다.

결론적으로, 잘 정의 된 역할의 지혜는 폭주하는 그룹 액세스의 위험을 완화하는 데 도움이됩니다. 조직의 모든 사람이 특정 그룹에 대한 액세스를 주장 할 수 있습니다. 그러나 일단 액세스가 제공되면 거의 포기되지 않습니다. 역할 엔지니어링 (잘 정의 된 그룹 설명 및 권한 부여 된 그룹 액세스 관리자와 같은 모범 사례와 함께)은 조직 내 이해 상충을 제한하고 의사 결정을 분산시키고 보안 관리를보다 합리적으로 만들 수 있습니다.

이전 답변은 모두 훌륭합니다. 언급했듯이 그룹 대 역할의 개념은 기술적 인 것보다 더 개념적입니다. 그룹은 사용자를 포함하고 (사용자는 둘 이상의 그룹에 속할 수 있습니다. 즉, Joe는 관리자 그룹과 IT 그룹에 속합니다 [그는 IT의 관리자입니다]) 및 광범위한 권한을 할당하는 데 사용된다는 입장을 취했습니다. (즉, 우리의 자기 카드 시스템은 IT 그룹의 모든 사용자가 서버 룸에 액세스 할 수 있도록합니다). 이제 역할을 사용하여 특정 사용자에게 권한을 추가했습니다 (즉, IT 그룹의 사용자는 서버에 RDP를 할 수 있지만 사용자를 할당하거나 권한을 변경할 수 없으며, 관리자 역할을 가진 IT 그룹의 사람들은 사용자를 할당하고 권한을 변경할 수 있습니다). 역할은 다른 역할로도 구성 될 수 있습니다 (Joe는 사용자 / 권한을 추가하는 Admin 역할이 있고 서버의 DBMS에 데이터베이스 변경을 수행하는 DBA 역할도 있습니다). 역할은 사용자에게 매우 특정한 개별 사용자 역할 (예 : JoesRole)을 만들 수 있다는 점에서 매우 구체적 일 수 있습니다. 요약하자면 그룹을 사용하여 사용자를 관리하고 일반적인 역할과 역할을 할당하여 권한을 관리합니다. 이것은 또한 누적됩니다. 사용자가 속한 그룹에는 매우 일반적인 권한을 부여하는 역할 (또는 사용 가능한 역할 목록)이 할당되어있을 수 있습니다 (즉, IT 그룹 사용자는 서버에 로그온 할 수있는 ServerRDP 역할이 있음). 그런 다음 사용자가 속한 역할은 마지막 역할 (권한을 허용, 거부 또는 적용하지 않을 수 있음)이있는 마지막 역할로 정의 된 순서대로 추가되어 각 역할이 적용될 때 권한에 대한 이전 설정을 재정의합니다. 또는 변경하지 마십시오). 모든 그룹 수준 역할 및 사용자 수준 역할이 적용되면

사용자는 시스템에서 수행하는 책임에 따라 역할에 할당됩니다. 예를 들어 영업 관리자 역할의 사용자는 제품에 대한 추가 할인 제공과 같은 특정 작업을 수행 할 수 있습니다.

그룹은 보안을 쉽게 관리하기 위해 시스템에서 사용자 또는 역할을 '그룹화'하는 데 사용됩니다. 예를 들어 "리더십 그룹"이라는 그룹은 관리자, 디렉터 및 설계자 역할의 구성원과 이러한 역할에서 벗어난 개별 사용자를 가질 수 있습니다. 이제이 그룹에 특정 권한을 할당 할 수 있습니다.

그룹 및 역할의 목적은 응용 프로그램에 따라 다르지만 주로 다음과 같이 이해했습니다. 그룹 (사용자 집합)은 정적 인 반면 역할 (권한 집합)은 정책에 따라 동적입니다. 예를 들어 (9 ~ 6) a 그룹 또는 사용자는이 역할을 가질 수 있지만 그렇지 않을 수 있습니다.

그룹에 역할을 할당 할 수 있습니다. 사용자를 그룹에 할당하고 역할 사용자의 개별 사용자에게 역할을 할당 할 수 있습니다. 의미. Jean Doe는 SharePoint에서 보고서를 인쇄 할 수있는 ReportWritter 역할이없는 SalesDeptartment 그룹에있을 수 있지만 SalesDepartment 그룹에서는 다른 사용자가 ReportWritter 역할을 갖지 않을 수 있습니다. -즉, 역할은 할당 된 그룹에 대한 특별한 권한입니다. 이것이 어떤 장면을 만들기를 바랍니다.

건배!!!