OPA(Open Policy Agent)를 사용한 역할 기반 액세스 제어(RBAC)

건축 허가는 아마도 복잡한 일일 것이다.구축 권한 수여는 서로 다른 모델과 서로 다른 실현 방식이 있다.결국, 단지 한 가지 중요한 것이 있다. 우리는 적당한 사람이 적당한 자산을 사용할 권리가 있기를 바란다.
이를 위해, 우리는 두 가지 권한 수여 모델 (RBAC와 ABAC) 을 되돌아보고, 어떻게 개방된 정책 에이전트를 사용해서 그것을 실현할 수 있는지 설명하고자 합니다. 권한 수여를 위해 단독 마이크로 서비스를 만들고, 우리의 정책과 코드를 분리할 수 있도록 합니다.

그럼 왜 RBAC랑 ABAC인가요?

RBAC와 ABAC는 두 가지 가장 기본적이고 가장 자주 사용하는 권한 수여 모델로 대부분의 기타 복잡하고 특정한 권한 수여 모델에 기준을 제공한다.이들을 보다 잘 이해하는 것부터 시작하겠습니다.

RBAC란?

역할 기반 액세스 제어(RBAC)는 미리 정의된 역할에 따라 액세스 제어를 결정하는 권한 부여 모델입니다.권한은 관리자나 사용자와 같은 역할에 할당되고 역할은 관리자가 사용자에게 할당합니다.이런 구조는 누가 무엇을 방문할 권리가 있는지 쉽게 이해하게 한다.
누구의 조합(이들은 어떤 배역을 맡았습니까?)자원(어떤 자원상의 자원)에 대해 정책이라고 불리는 조작을 수행할 수 있다(어떤 조작을 허용할 수 있는지).

ABAC란?

ABAC(속성 기반 액세스 제어)는 속성이라는 피쳐 세트를 기반으로 액세스를 결정합니다.속성에는 사용자 역할, 보안 라이센스, 액세스 시간, 데이터 위치, 현재 조직 위협 수준, 리소스 작성 일자 또는 소유권, 데이터 민감도 등의 매개 변수가 포함됩니다.

RBAC VS ABAC

RBAC와 ABAC 사이의 선택은 조직의 요구에 달려 있다 -
RBAC는 대부분의 조직에 충분한 권한을 부여하기 위해 상당히 간단한 해결 방안을 제공했다.어떤 경우, 권한이 부여되지 않은 방문을 방지하기 위해서는 더욱 깊은 권한 수여 방법이 필요하다. 이것이 바로 ABAC의 용무이다.ABAC는 더 많은 처리 능력과 시간을 필요로 하지만, 더 복잡하고 상세한 권한 수여 방법을 제공하여 더 많은 변수를 분해할 수 있다.
많은 상황에서 RBAC와 ABAC는 차원 구조에서 함께 사용할 수 있고 RBAC 프로토콜은 광범위한 접근을 실시하며 ABAC는 더욱 복잡한 접근을 관리한다.그럼에도 불구하고 조직의 수요에 적합한 권한 수여 방법을 선택하는 것은 매우 중요하기 때문에 권한 수여 과정은 간단하지도 복잡하지도 않다.
이 문서에서는 RBAC를 사용하여 정책을 설정하기로 결정한 것으로 가정합니다.

RBAC를 사용한 정책 설정 문제

RBAC를 사용하여 정책을 설정하기로 결정한 후에는 다음 과제에 주의해야 합니다.
모든 서비스의 정책 집합은 서비스 자체 내부에서 수동으로 설정해야 한다.이것은 정책, 사용자, 서비스 수량이 증가함에 따라 모든 관련 서비스에서 그것들을 업데이트하는 것은 매우 지루하고 시간이 소모될 수 있는 고통일 수도 있다.뿐만 아니라 정책이 계속 바뀌고 있다는 사실을 감안하면 적어도 유동성은 있어야 한다.
또 다른 문제는 권한 수여층의 코드와 응용 프로그램 자체의 코드를 혼합하는 것이다.이로 인해 코드가 서로 다른 마이크로 서비스 사이에서 복제될 때 우리는 업그레이드, 기능 추가와 모니터링 코드를 추가하기 어렵다.매번 변경할 때마다 우리는 대량의 코드를 재구성해야 한다. 이러한 마이크로 서비스의 개발에 따라 이 코드들은 서로 간의 거리가 점점 멀어질 뿐이다.
그러나 우리는 어떻게 이런 도전을 해결합니까?

단독 권한 수여 마이크로 서비스를 만들어서 우리의 정책과 코드를 분리합니다.개별 권한 부여 서비스를 통해 액세스 관리를 집중적으로 제어하여 사용자가 자원에 접근할 수 있는지 확인해야 하는 모든 시스템에 서비스를 제공할 수 있다.이것은 Open Policy Agent(OPA)를 사용하여 완성할 수 있다.

OPA는 우리에게 무엇을 주었습니까?

OPA는 서버의 각 서비스에 대한 모든 정책을 통합합니다.

서비스에서 정책 결정과 집행의 역할을 맡는다. 서비스 조회OPA, OPA가 결정을 내리고 서비스에 출력을 보내고 서비스는 OPA의 회답에 따라 행동한다.

정책을 코드로 하여 보기, 편집, 스크롤을 쉽게 할 수 있습니다.

중앙 집중식 권한 부여 솔루션이 있지만 실행 자체는 분산되어 있습니다.
우리는 모든 마이크로 서비스 옆에 OPA 에이전트가 있어서 거의 0에 가까운 네트워크 지연으로 의사결정과 집행을 제공한다.OPA 에이전트는 분산형으로 서비스 규모 확대에 따라 성장할 수 있다.

OPA에서 RBAC는 어떻게 구현됩니까?

RBAC를 사용하려면 다음과 같은 두 가지 유형의 정보가 필요합니다.

사용자 역할

어떤 역할이 어떤 권한을 가지고 있는지

RBAC에 이러한 정보를 제공한 후 권한 수여 결정을 내리는 방법을 결정합니다.사용자가 역할에 할당되어 해당 역할이 허용하는 작업을 수행할 수 있는 권한이 부여됩니다.
예를 들어 다음과 같은 역할 할당을 살펴보겠습니다.
이용자
(이 작업을 수행하는 사람)
역할
(사용자가 할당한 역할은 무엇인가)Crab Admin Bob Cook Plankton Villain그리고 이 역할/권한 할당:
역할
수술하다
(얘네 뭐하는 거야)
리소스
(그들은 무슨 행동을 하고 있는가)Admin Write Secret formula Admin Read Secret formula Cook Read Secret formula Villain Want Secret formula이 예제에서 RBAC는 다음과 같은 권한 부여 결정을 내립니다.
이용자
수술하다
리소스
결정하다.
(이런 행동을 허락해야 하나? 왜?)Crab Write Secret formula Allow 왜냐하면Crab AdminBob Read Secret formula Allow 왜냐하면Bob CookVillain Read Secret formula Deny 왜냐하면Plankton VillainVillain Want Secret formula Allow 왜냐하면Plankton Villain
OPA를 사용하면 다음과 같은 코드 세그먼트를 작성하여 RBAC 정책 예제를 적용할 수 있습니다.

package rbac.authz

# Assigning user roles 

user_roles := {

    "crab": ["admin"],

    "bob": ["cook"],

    “plankton”:[“villain”]

}

# Role permission assignments
role_permissions := {
    "cook":    [{"action": "read",  "object": "secret_formula"}],
    "admin":   [{"action": "read",  "object": "secret_formula"},
                {"action": "write", "object": "secret_formula"}],
    "villain": [{"action": "want",  "object": "secret_formula"}]
}

# Logic that implements RBAC.
default allow = false
allow {
    # Lookup the list of roles for the user
    roles := user_roles[input.user]
    # For each role in that list
    r := roles[_]
    # Lookup the permissions list for role r
    permissions := role_permissions[r]
    # For each permission
    p := permissions[_]
    # Check if the permission granted to r matches the user's request
    p == {"action": input.action, "object": input.object}
}

다음 입력 쿼리 허용 규칙을 사용합니다.

{
  "user": "plankton",
  "action": "read",
  "object": "secret_formula"
}

네가 바라는 결과는 False이다.

⁠축하합니다!당신은 이미 OPA에서 ABAC를 성공적으로 실현하였습니다! 
⁠

결론:

이제 배운 내용을 빠르게 살펴보겠습니다.

RBAC는 미리 정의된 역할에 기반한 권한 수여 모델이고 ABAC는'속성'이라고 불리는 특징 그룹을 바탕으로 접근 권한을 확정한다.

RBAC는 대다수 조직에 적합한 권한 수여를 확정하기 위해 상당히 간단한 해결 방안을 제공했지만 ABAC는 더욱 복잡하고 상세한 권한 수여 방법으로 더 많은 변수를 고려했다.

조직이 필요로 하는 권한 수여 모델을 선택하는 것은 매우 중요하다. 이렇게 하면 간단하지도 복잡하지도 않다.

RBAC를 사용하여 정책을 설정하는 주요 도전은 각 단독 서비스에 수동으로 정책 집합을 설정하고 권한 수여층의 코드를 응용 프로그램 자체의 코드와 혼합하는 것이다.둘 다 OPA로 해결할 수 있습니다.

OPA는 한 서버에서 모든 정책을 통일시키고 서비스에서 정책 결정과 집행의 역할을 맡으며 코드 형식으로 정책을 관리할 수 있도록 함으로써 이러한 문제점을 해결했다.

OPA에서 RBAC를 성공적으로 구현하는 방법의 예를 보았습니다.

더 알고 싶으세요?저희Blog의 다른 강좌를 보시고, 더 많은 유용한 강좌를 알아보시거나, 저희의⁠ Slack channel는 권한을 질문하고 토론한다.