DEVOCEAN을 통해 정책엔진인 OPA에 대해 소개한 적이있다. (https://devocean.sk.com/blog/techBoardDetail.do?ID=163522)

이를 적용하기 위해 다양한 스터디를 진행하고 있다. 때마침 OPA Slack(https://slack.openpolicyagent.org/)에 ‘OPA를 사용해 Attribute Based Access Control (ABAC)구현하는 방법’ (https://dev.to/permit_io/how-to-implement-attribute-based-access-control-abac-using-open-policy-agent-opa-3ek4)이라는 글이 소개되어 이를 번역하고자 한다.

인증을 구성하는 것은 복잡하고 노력이 많이 필요한 일이 될수 있다. 인증을 구성하는 다양한 모델들과 방법이 존재하지만, 최종적 목표는 우리가 적합한 사용자에게 적합한 권한을 부여하는 것이다. 이러한 이유로 우리는 몇가지 인증모델(ABAC, RBAC)을 살펴보고 OPA를 통해 어떻게 구현할 것인가를 설명할 것이다.

왜 ABAC과 RBAC인가?

ABAC과 RBAC은 가장 기본적이고 일반적으로 사용되는 두가지 권한부여 모듈이고 대부분의 복잡하거나 특화된 시스템의 기준선을 제공한다.

RBAC?

역할 기반 접근제어는 미리 정의된 역할을 기반으로 접근 제어를 결정하는 권한 부여 모델이다. 권한은 역할(예: Admin, User...)에 할당되고 역할은 관리자가 사용자에게 할당한다. 이 구조를 통해 누가 어디에 접근했는지 쉽게 인지할 수 있다.

사용자(어떤 사용자가), 자원(어떤 자원에), 작업(어떤 일을 수행할지)- 세가지의 조합을 ‘정책’이라 한다.

ABAC?

속성 기반 접근제어는 역할이 아닌 속성 이라는 특징의 집합을 기반으로 접근을 결정한다. 속성에는 사용자 역할, 보안 허가, 액세스 시간, 현재 시간, 데이터 위치, 현재 조직의 위협 수준, 리소스 생성 날짜 또는 소유권, 데이터 민감도 등에 대한 값들이 포함된다.

ABAC에서는 사용자뿐만 아니라 접근하려는 자원이나 전체시스템 및 이 상황와 관련된 기타 모든 것에 대한 속성을 확인하는 것에 유의하자.

사용자(어떤 사용자가), 자원(어떤 자원에), 작업(어떤 일을 수행할지), 상황(이 동작이 수행되기 위해 필요한 환경) - 네가지의 조합을 기반으로 ABAC ‘정책’이 만들어진다.

RBAC/ABAC 비교

조직의 요구사항에 따라 RBAC와 ABAC 중 선택하게 된다.

RBAC는 권한 부여를 결정하기 위한 다소 간단한 솔루션을 제공한다. RBAC에서 확장된 ABAC는 무단접근를 방지를 위한보다 심층적인 접근 방식을 제공한다. 더 많은 처리 능력과 시간이 필요하지만, ABAC는 훨씬 더 많은 수의 변수를 포함하는 더 복잡하고 상세한 인증이 가능하다.

많은 경우에 RBAC 및 ABAC는 함께 계층적으로 사용할 수 있다(RBAC에 의한 광범위한 접근제어와 ABAC에 의한 보다 복잡한 접근제어). 즉, 조직의 요구 사항에 맞는 적절한(너무 단순하지도 복잡하지도 않는) 인증 방법을 선택하는 것이 중요하다.

이 글의 목적상 ABAC을 선택했다고 가정한다.

ABAC으로 정책을 위한 과제

ABAC를 사용하여 정책을 설정하기로 결정했다면, 다음과 같은 문제를 만나게 될 것이다.

각 개별 서비스에 대한 정책 집합은 서비스 내부에 수동으로 설정되어야 한다. 정책, 사용자 및 서비스의 양이 증가함에 따라 각 관련 서비스에서 변경은 매우 지루하고 시간 소모적 작업이 된다. 그뿐만 아니라 정책이 시시각각 변하기 때문에 최소한의 유동성을 가져야 한다. 또 다른 문제는 인증 계층의 코드가 애플리케이션 자체의 코드와 혼합되어 있을 때 발생할 수 있다. 이로 인해 서로 다른 마이크로서비스 간에 복제되는 코드를 업그레이드하고, 기능을 추가하고, 모니터링하는 데 어려움을 겪는 상황이 발생한다. 횔용하는 마이크로 서비스가 개발됨에 따라 서로 더 멀리 확산되고, 각 변경사항은 많은 코드 영역의 리팩토링을 요구한다.

그래서 어떻게 해결할 것인가?

인증을 위한 별도의 마이크로서비스를 만들어 코드에서 정책을 분리하였다. 별도의 인증 서비스를 통해 중앙에서 인증관리를 제어할수 있으므로서, 접근 여부를 결정해야하는 모든 시스템에 서비스로 했다. 이것을 위해 OPA(Open Policy Agent) 를 사용했다.

OPA가 우리에게 제공하는 것

• OPA는 각 개별 서비스의 모든 정책을 하나의 서버로 통합한다.

• 서비스에서 정책을 결정하고 서비스들이 실행하도록 한다.: 서비스들은 OPA에 묻고 OPA는 결정을 결과물로 서비스에 돌려준다, 서비스는 OPA의 응답에 의거하여 동작한다.

• 이를 통해 쉽게 검토, 편집 및 롤백할 수 있는 Policy as Code가 된다.

중앙화된 인증 솔루션이 있지만 시행 자체는 여전히 분산 되어 있다. - 우리는 거의 실시간으로 결정하고 실행하도록 하는 OPA 에이전트를 갖고있다. OPA 에이전트는 분산되어 있고 서비스의 크기에 따라 증가한다.

OPA에서 ABAC을 구현하는 방법

속성 기반 액세스 제어를 사용하면 요청과 관련된 사용자, 개체 및 작업의 속성을 사용하여 정책 결정을 내린다. 이를 위해서는 세 가지 유형의 정보가 필요하다.

• 사용자를 위한 속성

• 객체의 속성

• 어떤 속성 조합이 승인되었는지 지시하는 로직

예를 들어 사용자에 대해 다음 속성을 사용한다고 가정해 보자.

• Squid:

  • 10년전 입사

  • Cashier

• Pat:

  • 6개월전 입사

  • Cashier

우리는 객체에 대해서도 속성을 부여했다.

• 버거:

  • 메뉴로 판매

  • $3

• 쉐이크:

  • 메뉴로 판매

  • $1

ABAC 정책을 글로 적어보면 다음과 같다.

• Cashier는 최대 $1까지 주문을 처리할 수 있다.

• 1년이상 경력을 갖은 Casher는 최대 $10까지의 주문을 처리할 수 있다.

OPA는 ABAC 정책을 아래와 같이 지원

package abac

# 사용자 속성
user_attributes := {
    "Squid": {"tenure": 10, "title": "cashier"},
    "Pat": {"tenure": 0.5, "title": "cashier"}
}

# 메뉴 속성
menu_attributes := {
    "Burger": {"items": "Menu", "price": 3},
    "Shake": {"items": "Menu", "price": 1}
}

default allow = false

# 모든 Casher는 최대 $1까지 주문을 처리할 수 있다.
allow {
    # 사용자의 속성을 가져오고
    user := user_attributes[input.user]
    # 사용자가 cashier인지 체크
    user.title == "cashier"
    # 팔려는 물건이 메뉴에 있는지 확인하고
    menu_attributes[input.ticker].items == "Menu"
    # $1이하를 처리하려는 것인지 체크
    input.amount <= 1

}

# 1년 이상의 경력을 갖은 Cashier는 최대 $10의 주문을 처리할 수 있다.
allow {
    # 사용자의 속성을 가져오고
    user := user_attributes[input.user]
    # 사용자가 cashier인지 체크
    user.title == "cashier"

    # 팔려는 물건이 메뉴에 있는지 확인하고
    menu_attributes[input.ticker].items == "Menu"
    # 경력이 1년 이상인지 확인하고
    user.tenure > 1
    # $10 이하를 처리하려는 것인지 체크
    input.amount <= 10
}

이제 아래와 같은 입력으로 확인해보자.

{
  "user": "Squid",
  "menu": "Burger",
  "action": "sell",
  "amount": 2
}

위의 입력으로 허용룰을 확인하면 다음과 같은 응답을 받는다: True

축하한다! 성공적으로 OPA를 사용하여 구현된 ABAC을 갖게됐다.

요약하자면

배운내용을 빠르게 정리해 보겠다.

• RBAC 는 사전 정의된 역할을 기반으로 동작하는 반면 ABAC은 속성이라는 특성 집합을 기반으로 접근을 결정한다.

• RBAC이 대부분의 조직에 적합한 권한 시스템으로 간단한 솔루션을 제공하지만, ABAC은 훨씬 더 많은 변수를 고려할 수 있고 더 복잡하고 자세한 권한 부여 방식이다.

• 요구 사항에 맞는 인증 모델을 선택하는 것이 중요하다 .

• RBAC를 사용하여 정책을 설정할 때의 주요 문제는 각 개별 서비스에 대한 정책 집합을 수동으로 설정하고 인증 계층 코드를 애플리케이션 자체의 코드와 혼합해야 한다는 것이다. 이 두가지를 OPA를 사용하여 해결할 수 있다.

• OPA는 모든 정책을 하나의 서버로 통합하고 서비스에서 정책 결정 및 시행의 역할을 수행 하고 Policy as Code로 관리할 수 있도록 함으로써 이러한 문제를 해결한다 .

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

역자추가

본 페이지를 통해 ABAC을 만드는 방법에 대한 글을 번역해 보았다. 동일한 저자가 작성한 RBAC 을 구현하는 방법에 대한 글(https://www.permit.io/blog/implement-rbac-using-opa)도 있으며 대부분의 배경지식등은 동일하다. 구현 예시 부분만 간단하게 정리하면 다음과 같다.

역할예시

권한예시

RBAC을 통한 결정 예시

OPA로 정책구현

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"
}

아주 단순한 예제이지만 OPA를 통해 RBAC과 ABAC을 구현하는 차이점을 구체적으로 살펴볼 수 있는 자료이고 OPA를 처음 접하는 사용자의 막막함을 덜어줄 수 있을 것으로 기대되는 글이다.

https://heavenly-part-d73.notion.site/OPA-ABAC-db571dce08904da0b328e1413cff52f5