역할 및 권한 기반 액세스 제어

액세스 제어 (권한 부여)와 관련하여 역할과 권한의 본질적인 상충 관계를 이해하려고합니다.

시스템에서 Permission 은 세분화 된 액세스 단위 ( " 리소스 X 편집 ", " 대시 보드 페이지 액세스 "등)가됩니다. 역할 1+ 권한의 집합이 될 것입니다. 사용자 1+ 역할을 할 수 있습니다. 이러한 모든 관계 (사용자, 역할, 권한)는 모두 데이터베이스에 저장되며 필요에 따라 즉시 변경할 수 있습니다.

내 관심사 :

(1) 액세스 제어를위한 역할을 확인하는 데있어 "나쁜"것은 무엇입니까? 대신 권한을 확인하면 어떤 이점이 있습니까? 즉, 아래 두 스 니펫의 차이점은 무엇입니까?

if(SecurityUtils.hasRole(user)) {
    // Grant them access to a feature
}

// vs.
if(SecurityUtils.hasPermission(user)) {
    // Grant them access to a feature
}

과:

(2)이 시나리오에서 역할은 어떤 유용한 가치를 제공합니까? 사용자에게 1 개 이상의 권한을 직접 할당 할 수 없습니까? 역할이 제공하는 구체적인 추상 가치는 무엇입니까 ?

— 스미 브
소스

몇 가지 요점 : (1) 단일 사용자가 여러 역할을 가질 수 있습니다. (2) 예를 들어 ACL (Access Control Lists)을 살펴볼 수 있습니다. "대시 보드 페이지 액세스"를 대시 보드 페이지의 하위 집합 (여러 개가있는 경우)에만 부여 할 수 있습니다.

— Matthieu M.

답변:

(1) 액세스 제어를위한 역할을 확인하는 데있어 "나쁜"것은 무엇입니까? 대신 권한을 확인하면 어떤 이점이 있습니까?

확인하는 순간, 호출 코드는 "사용자 X에게 작업 Y를 수행 할 권한이 있습니까?" 만 알면됩니다. .
호출 코드는 역할과 권한 간의 관계를 신경 쓰지 않으며 인식하지 않아야합니다.

권한 부여 계층은 일반적으로 사용자의 역할에이 권한이 있는지 확인하여 사용자에게이 권한이 있는지 확인합니다. 이를 통해 호출 코드를 업데이트하지 않고 인증 로직을 변경할 수 있습니다.

호출 사이트에서 역할을 직접 확인하는 경우 암시 적으로 역할 ⇄ 권한 관계를 형성하고 권한 부여 논리를 호출 코드에 주입하여 우려의 분리를 위반합니다.

나중에 역할에 foo권한이 없어야한다고 결정한 baz경우 사용자가 a인지 확인하는 모든 코드를 변경해야합니다 foo.

(2)이 시나리오에서 역할은 어떤 유용한 가치를 제공합니까? 사용자에게 1 개 이상의 권한을 직접 할당 할 수 없습니까? 역할이 제공하는 구체적인 추상 가치는 무엇입니까?

역할은 개념적으로 명명 된 권한 모음을 나타냅니다.

사용자가 특정 설정을 편집 할 수있는 새로운 기능을 추가한다고 가정 해 봅시다. 이 기능은 관리자 만 사용할 수 있습니다.

사용자 당 권한을 저장하는 경우 데이터베이스에서 관리자가 알고있는 모든 사용자를 찾아야합니다 (사용자의 역할 정보를 저장하지 않는 경우 관리자 인 사용자를 어떻게 알 수 있습니까?) . 권한 목록에 대한 권한입니다.

역할을 사용하는 경우 역할에 권한을 추가하기 만하면됩니다.이 작업 Administrator은 수행하기 쉽고 공간 효율적이며 실수가 적습니다.

— 로템
소스

어? 인증 계층은 사용자가 주장 그 사람인지 확인한다; 사용자가 어떤 기능 / 데이터를 액세스 할 수 있는지 확인하는 계층

— SJuan76

모든 프로그래머는 반드시 읽어야합니다. 우수한.

— Kosta Kontos

간단하고 간결하며 요점은 책의 전체 장을 어딘가에서 능가합니다. 감사.

— Dan Nissenbaum

명확성에 대한 주석 (그리고 내가 실수하면 정정하십시오) : authorization layer단순히 기능 의 정의 를 갖는 것 이상의 의미 가 있습니다. 즉, user->hasPermission(SOME_PERMISSION)내부적으로 사용자의 역할을 먼저 확인한 다음 주어진 역할을 포함 / 제외하는 역할이 있는지 확인하십시오 허가. 예를 들어, the calling code특정 페이지가 사용자에게 표시하고 부를 것이다 있는지 점검 할 수있다 user->hasPermission(VIEW_GIVEN_PAGE), 그리고는 authorization layer의 이루어져 정의 의 hasPermission위로서 역할을 확인 기능.

— Dan Nissenbaum

@DanNissenbaum 예, 제대로 된 것 같습니다. 사용자 역할에이 권한이 있는지 확인하는 것만 큼 간단 할 수 있습니다. 그 이상일 수도 있습니다. 예를 들어, 사용자를 일시적으로 일시 중지 할 수있는 옵션이 hasPermission있을 수 있습니다 usersRole.HasPermission(VIEW_GIVEN_PAGE) && !user.Suspended. 요점은 모든 것이 한 장소에서 이루어지고 소비 (호출) 코드가 아니라는 것입니다.

— Rotem

첫 번째 질문에 대한 응답으로 사용자에게 특정 권한이 아닌 역할이 있는지 확인하는 데 가장 큰 문제는 여러 역할이 권한을 보유 할 수 있다는 것입니다. 이에 대한 예로, 개발자는 회사 인트라넷에서 개발자 포털을 볼 수있는 액세스 권한을 가질 수 있습니다. 이는 아마도 관리자가 보유한 권한 일 수도 있습니다. 사용자가 개발자 포털에 액세스하려고하면 다음과 유사한 검사가 나타납니다.

if(SecurityUtils.hasRole(developer)) {
    // Grant them access to a feature
} else if(SecurityUtils.hasRole(manager)) {
    // Grant them access to a feature
} else if...

( switch귀하가 선택한 언어로 된 진술이 더 좋지만 여전히 깔끔하지는 않습니다)

더 일반적이거나 널리 사용되는 권한 일수록 누군가 특정 시스템에 액세스 할 수 있는지 확인하기 위해 더 많은 사용자 역할을 확인해야합니다. 또한 역할에 대한 권한을 수정할 때마다이를 반영하도록 검사를 수정해야하는 문제가 발생합니다. 큰 시스템에서 이것은 매우 다루기 힘들어 질 것입니다.

예를 들어, 사용자에게 개발자 포털에 액세스 할 수있는 권한이 있는지 확인하면 어떤 역할을 수행하든 관계없이 액세스 권한이 부여됩니다.

두 번째 질문에 대답하려면 역할이있는 이유는 권한의 "패키지"를 쉽게 수정하고 배포하는 역할을하기 때문입니다. 수백 개의 역할과 수천 개의 권한을 가진 시스템이있는 경우 새 사용자 (예 : 새 HR 관리자)를 추가하려면 다른 HR 관리자가 보유한 모든 단일 권한을 부여해야합니다. 이 작업은 지루할뿐만 아니라 수동으로 수행하면 실수하기 쉽습니다. 이것을 단순히 "HR 관리자"역할을 사용자 프로필에 추가하는 것과 비교하면 해당 역할을 가진 다른 모든 사용자와 동일한 액세스 권한이 부여됩니다.

기존 사용자를 복제 할 수 있다고 주장 할 수 있지만 (시스템에서이를 지원하는 경우) 해당 시점에 대해 사용자에게 올바른 권한을 부여하지만 향후 모든 사용자에 대한 권한을 추가하거나 제거하려고 시도하는 것은 어려운. 이에 대한 시나리오의 예는 과거 HR 직원이 급여를 담당했지만 나중에 회사가 급여를 처리하기 위해 직원을 채용 할만큼 충분히 커지는 경우입니다. 즉, HR은 더 이상 급여 시스템에 액세스 할 필요가 없으므로 권한을 제거 할 수 있습니다. HR 구성원이 10 명인 경우 수동으로 진행하여 사용자 오류가 발생할 수있는 올바른 권한을 제거해야합니다. 이것의 다른 문제는 단순히 확장되지 않는다는 것입니다. 주어진 역할에서 점점 더 많은 사용자를 확보할수록 역할 수정이 훨씬 어려워집니다. 권한을 제거하기 위해 문제의 중요한 역할 만 수정하면되는 역할을 사용하는 역할과 비교하십시오. 권한을 제거하면 해당 역할을 보유한 모든 사용자가이를 반영합니다.

— 매트 챔피언
소스

좋은 예, 감사합니다!

— 솔직한