ABAC 구현은 ACL / RBAC보다 복잡합니다. 일부 프레임 워크는 후자를 처리하기 위해 약간의 인프라를 제공하기도합니다. 사람과 자산을 상대적으로 작고 고정 된 수의 역할 / 카테고리로 그룹화 할 수있는 경우 ACL / RBAC를 사용하는 것이 가장 좋습니다. 사용 권한이 개인마다 크게 다르면 ABAC가 더 우수하고 유연한 솔루션을 제공 할 수 있습니다.
ABAC 경로를 따라 가기로 선택한 경우 가장 먼저해야 할 일은 XACML 표준을 읽고 이해하는 데 시간을 투자하는 것입니다 . 이 문서에 제공된 예제는 XACML 호환 구문을 사용하며 처음에는 약간 씹기가 어렵습니다. 표준 호환 솔루션을 구현하고 싶지 않으므로 일반적인 아이디어 만 필요하다고 생각합니다.
개념
XACML은 주제 , 활동 , 자원 및 환경 이라는 4 가지 개념과 그 속성을 중심으로 진행됩니다 . 몇 개 더 있지만 이것들이 가장 중요합니다. 다른 모든 것은 그 위에 구축됩니다. 이러한 개념으로 문장을 작성하려면 다음과 같은 내용이 될 수 있습니다. 주제 는 특정 환경 에서 자원 에 대한 조치 를 수행 합니다 . 이것을 시나리오에 적용하면 다음과 같이 번역됩니다.
- Leslie가 가격 관리자 웹 페이지를 엽니 다.
- Leslie는 가격 관리자 웹 페이지를 사용하여 여행 가격을 만듭니다.
속성 수집
가장 먼저해야 할 일은 위에서 언급 한 개념의 관련 속성을 수집하는 것입니다. XACML이 방해받지 않고 시스템이 자연스럽게 제공하는 것에 의존하기 때문에 특정 속성을 할당하지 않는 것이 이상적입니다. 그리고 우리는 :
제목
시스템의 모든 행위자 (개인 또는 서비스). 우리의 주제는 레슬리입니다. Leslie를 고유하게 식별하려면 어떤 속성이 필요합니까? 아마 다음의 몇 가지 : first name, last name, e-mail, ssn, company id, position(s).
동작
주제에 의해 수행되는 모든 조치. 표준 CRUD 작업 또는보다 복잡한 작업 일 수 있습니다. 우리의 행동은 open/view과 create. 이러한 작업의 속성은 사용중인 웹 응용 프로그램 프레임 워크에 따라 다를 수 있습니다. 리소스에 접근 할 때 이에 대해 더 이야기하겠습니다.
자원
꽤 자명하다. 우리의 자원은이다 price manager page, travel prices하고 the newly created price. 정말로 원한다면 더있을 수 있습니다. 사용자가 수행 할 수없는 작업을 숨길 수 있습니다. 예 : 는 create price button/ 표시 사용자가 가격을 만들 수있는 권한이 있는지 여부에 따라 숨길 수있는 자원이 될 수 있습니다. 사용자가 가격 목록을 볼 수있는 유일한 방법은이 페이지를 통하는 것이기 때문에 스택을 더 낮추지 않고이 수준에서 권한 부여를 시행하는 것이 좋습니다.
리소스에 대한 액세스는 특히 데이터베이스에서 제공되는 리소스에 대해 구현하기가 가장 복잡합니다. 보다 세분화 된 옵션은 행 수준 보안입니다. 일부 데이터베이스는 특정 수준의 지원을 제공합니다. 일부 XACML 구현자는 SQL 수퍼 세트를 작성하는 데까지 이르렀습니다. 이것은 실제로 승인 요구에 달려 있지만 원하지 않는 한 가지는 테이블에서 모든 것을 가져온 다음 표시 할 내용을 결정하는 것입니다. 권한 세트별로 리소스를 그룹화하고이를 API로 추상화하고 API 엔드 포인트에서 권한을 부여 할 수 있습니다.
환경
제대로 정의 할 수 없습니다 (XACML에는 적절한 정의가 없습니다). 그러나 이것이 모든 일이 발생하는 "거품"이라고합시다. 여기에는 : web application, web server, operating system, browser, office. 당신은 같은 속성을 추출 할 수있다 : ip address, time of day, user locale, user agent, operating system version. 이 기능을 사용하면 응용 프로그램에서 지원하지 않는 환경 (예 : 이전 브라우저, 이전 운영 체제, 네트워크 외부 컴퓨터, 업무 시간 외 액세스)에서 사용자 액세스를 차단할 수도 있습니다.
승인 요청
필요한 모든 속성을 수집 한 후에는이를 인증 요청에 묶고 이러한 속성의 값을 기반으로 인증 결정을 내릴 수있는 엔티티로 전달합니다. XACML 언어에서는 이러한 속성을 수집하고 결정을 시행하는 장소를 정책 시행 지점 (PEP)이라고하고, 포인트 결정을 정책 결정 지점 (PDP) 이라고합니다 . 속성 값을 얻는 위치를 PIP ( 정책 정보 지점 )라고합니다. PEP, PDP 및 PIP는 외부 시스템 일 수있는 응용 프로그램의 일부일 수 있습니다. XACML 표준에서 서로 통신하는 방법에 대한 다이어그램을 찾을 수 있습니다.
결정 과정
의사 결정 프로세스는 규칙을 기반으로 합니다. 규칙을 정책 으로 그룹화하여 정책 세트 로 추가 그룹화 할 수 있습니다 . 이들 각각에는 목표가 있습니다. 대상은 규칙 중 하나가 권한 부여 요청에 적용되는지 여부를 결정하는 데 사용됩니다. 필터로 생각하십시오. 대상에는 속성 이름과 값을 사용하여 작성된 조건이 포함됩니다. 예를 들어, 애플리케이션 규칙은 다음과 같이 그룹화 될 수 있습니다.
웹 애플리케이션 (정책 세트)
|-target : application-name == "웹 응용 프로그램"
`-버전 1.0 (정책 세트)
|-대상 : application-version == "1.0"
`-가격 관리자보기 (정책)
|-대상 : 웹 페이지 이름 == "가격 관리자"&& action-name == "보기"
`-레슬리는 가격 관리자를 볼 수 있습니다 (규칙)
|-target : subject-name == "레슬리"
`-허가 : 허용
PDP는 위의 세트에있는 모든 것을 권한 부여 요청의 속성 값과 일치시킵니다. 규칙과 일치하지 않는 규칙은 PDP 구현에 따라 다릅니다. 플라즈마 디스플레이 패널이 결정을 (되면 allow, deny나 not-applicable) 그것이 부여하거나 자원에 대한 액세스를 거부하여 그 위에 작용하는 PEP에 회신한다. 응답과 함께 플라즈마 디스플레이 패널의 목록을 보낼 수 obligations와 advices단합해야 또는 집행 과정에서 수행해야합니다. 규칙이 저장되는 방식 (텍스트 파일 또는 데이터베이스)에 따라 관리자는 표준 텍스트 편집기 또는 사용자 정의 편집 응용 프로그램을 사용하여 원하는대로 규칙을 변경할 수 있습니다. 가격 관리자에게 해지 레슬리의 접근은 단순히 허가를 변경하기 위해 다시 시작 allow에deny, PEP가 작업을 수행 한 것을 인정합니다.
시행
이는 기술 스택에 따라 크게 달라집니다. 일부 웹 프레임 워크에는 자연스러운 적용 지점이 있습니다 (예 : ASP.NET MVC에는 속성 필터가 있음). 비즈니스 계층에서 이러한 시행 지점을 정의해야 할 수도 있습니다. 서비스 (마이크로 서비스) 엔드 포인트 또는 UI 레벨에서 시행을 적용하는 것이 더 쉽다는 것을 알았습니다.
다른 이익
이를 구현할 때의 부작용은 다른 목적으로 사용할 수있는 상당히 풍부한 감사 추적으로 이어진다는 것입니다.
( 보도 자료 이미지 )