속성 기반 접근 제어 (Attribute-based access control, ABAC)

속성 기반 접근 제어 (ABAC)란 무엇인가?

ABAC는 액세스 제어 (Access control) 결정에 속성을 사용하는 접근 제어 모델입니다. 이러한 속성은 다음과 같은 다양한 요인을 포함할 수 있습니다:

• 사용자 속성: 예를 들어, 역할, 부서, 위치 등
• 리소스 속성: 예를 들어, 민감도 수준, 소유자, 유형 등
• 환경 속성: 예를 들어, 접근 시간, 위치, 장치 등

이러한 속성을 평가하고 일련의 규칙을 통해 실행함으로써, ABAC는 주체(예: 사용자, 서비스)가 리소스에 대한 접근 권한을 부여받아야 하는지를 결정할 수 있습니다. 이 접근 방식은 상황에 따라 세분화된 접근 제어와 동적 정책 시행을 가능하게 합니다.

ABAC는 어떻게 작동하나요?

ABAC는 정책 기반 접근 제어 방식을 사용합니다. 일반적인 ABAC 정책은 다음으로 구성됩니다:

• 주체: 접근을 요청하는 엔터티 (예: 사용자, 서비스, 장치).
• 작업: 리소스에 수행되는 작업 (예: 읽기, 쓰기, 삭제).
• 리소스: 접근되는 엔터티 (예: 파일, 데이터베이스, API).
• 환경: 접근이 요청되는 맥락 (예: 시간, 위치, 장치).
• 속성: 접근 결정을 내리기 위해 평가되는 주체, 리소스, 환경의 속성.
• 정책: 접근이 허용되거나 거부되는 조건을 정의하는 일련의 규칙.

ABAC 정책은 전통적인 접근 제어 모델인 역할 기반 액세스 제어 (Role-based access control, RBAC) 보다 복잡합니다. 반면에 ABAC는 접근 제어 결정에서 더 많은 유연성과 세분화를 제공합니다.

ABAC 정책 예제

예를 들어, 시스템에 여러 개의 ABAC 정책이 있을 수 있습니다:

1. 정책 1: 접근 허용:

   • (주체) 주체 역할이 manager.
   • (속성) 리소스 민감도 수준이 high.
   • (환경) 위치가 internal.
   • (작업) 모든 작업.
   • (환경) 시간이 9 AM ~ 5 PM (업무 시간) 사이.

2. 정책 2: 접근 거부:

   • (주체) 주체 역할이 manager가 아님.
   • (속성) 리소스 민감도 수준이 high.
   • (환경) 모든 위치.
   • (작업) 모든 작업.
   • (환경) 모든 시간.

3. 정책 3: 접근 허용:

   • (주체) 주체 역할이 employee 또는 manager.
   • (속성) 리소스 민감도 수준이 low.
   • (환경) 모든 위치.
   • (작업) read 작업.
   • (환경) 모든 시간.

정책 평가 엔진은 이러한 정책을 순서대로 확인하고, 조건에 맞는 첫 번째 정책이 접근 결정을 내리게 됩니다. 다른 정책이 일치하지 않으면 기본 거부 정책이 적용됩니다.

ABAC가 어떻게 작동하는지 이해하기 위해 몇 가지 시나리오를 살펴보겠습니다:

시나리오 1. 사용자가 사무실 외부(환경)에서 높은 민감도 수준의 문서(리소스)에 접근(‘읽기’ 작업 수행)하려고 합니다. 사용자는 시스템에 manager 역할로 저장되어 있습니다.

결정: 사용자가 사무실 외부에 있으므로(위치가 internal이 아님) 접근이 거부됩니다.

시나리오 2. 사용자가 사무실 내 네트워크(위치=internal)에서 업무 시간 중(환경)에 높은 민감도 수준의 문서(리소스)에 접근(‘읽기’ 작업 수행)하려고 합니다. 사용자는 manager 역할을 가지고 있습니다.

결정: 정책 1의 모든 조건이 충족되므로 접근이 허용됩니다.

시나리오 3. 시나리오 2의 모든 조건은 동일하지만, 사용자의 역할이 manager 대신 employee 입니다.

결정: 사용자의 역할이 정책 1의 조건을 충족하지 않으므로 접근이 거부됩니다.

시나리오 4. 사용자가 낮은 민감도 수준의 문서(리소스)에 접근(‘읽기’ 작업 수행)하려고 합니다. 사용자는 employee 역할을 가지고 있습니다.

결정: 정책 3의 모든 조건이 충족되므로 접근이 허용됩니다.

시나리오 5. 사용자가 낮은 민감도 수준의 문서(리소스)를 삭제(‘삭제’ 작업 수행)하려고 합니다. 사용자는 employee 역할을 가지고 있습니다.

결정: 낮은 민감도 수준의 문서에 대한 delete 작업을 허용하는 정책이 없으므로 접근이 거부됩니다.

모든 정책에서 모든 속성이 필요한 것은 아닙니다. 이러한 유연성은 보다 동적이고 상황에 맞는 접근 제어 메커니즘을 허용합니다.

확장 가능 접근 제어 마크업 언어 (XACML)

XACML은 접근 제어 정책을 표현하기 위한 XML 기반 표준입니다. 특정 접근 제어 모델을 정의하지는 않지만, XACML은 종종 ABAC 정책을 구현하는 데 사용됩니다. 이전 예시에서 ABAC 정책을 표현하기 위해 XACML이 어떻게 사용될 수 있는지 비규범적인 예를 살펴보겠습니다:

<PolicySet PolicySetId="ABAC_Policies" PolicyCombiningAlgId="urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-overrides">
  <Description>ABAC Policies</Description>
  <Policy PolicyId="Policy1" RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-overrides">
    <Description>Employees can read data</Description>
    <Target>
      <AnyOf>
        <AllOf>
          <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
            <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
            <AttributeDesignator
              AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
              Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"
              DataType="http://www.w3.org/2001/XMLSchema#string"
              MustBePresent="true"
            />
          </Match>
        </AllOf>
      </AnyOf>
    </Target>
    <Rule RuleId="Rule1" Effect="Permit">
      <Target>
        <AnyOf>
          <AllOf>
            <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
              <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">employee</AttributeValue>
              <AttributeDesignator
                AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
                Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
                DataType="http://www.w3.org/2001/XMLSchema#string"
                MustBePresent="true"
              />
            </Match>
          </AllOf>
        </AnyOf>
      </Target>
    </Rule>
    <Rule RuleId="Rule2" Effect="Deny">
      <Target>
        <AnyOf>
          <AllOf>
            <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
              <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">user</AttributeValue>
              <AttributeDesignator
                AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
                Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
                DataType="http://www.w3.org/2001/XMLSchema#string"
                MustBePresent="true"
              />
            </Match>
          </AllOf>
        </AnyOf>
      </Target>
    </Rule>
  </Policy>
  <!-- ...other policies... -->
</PolicySet>

XACML에 대한 자세한 내용은 eXtensible Access Control Markup Language (XACML) 을 참조하십시오.

구현 고려 사항

ABAC는 강력한 접근 제어 관리 방법을 제공하지만 구현 시 몇 가지 고려해야 할 사항이 있습니다:

• 시스템 복잡성: ABAC 정책은 속성과 규칙의 수가 증가함에 따라 복잡해질 수 있습니다. 적절한 정책 관리와 테스트는 더 간단한 접근 제어 모델보다 시간이 더 많이 소요됩니다.
• 성능: 복잡한 ABAC 정책을 평가하는 것은 시스템 성능에 영향을 미칠 수 있습니다. 캐싱 및 최적화 기술은 이 문제를 완화하는 데 도움이 될 수 있습니다.
• 정책 충돌: 충돌하는 정책은 예측할 수 없는 접근 결정으로 이어질 수 있습니다. 정기적인 정책 검토와 충돌 해결은 정책 관리 과정의 일부가 되어야 합니다.

ABAC vs. RBAC

ABAC와 역할 기반 액세스 제어 (Role-based access control, RBAC) 를 비교하면 두 모델 간의 차이를 이해하는 데 도움이 됩니다:

	RBAC	ABAC
접근 제어 정책	역할 기반	속성 기반
세분화	대략적	세밀한
유연성	제한적	매우 유연한
복잡성	간단함	더 복잡함
성능 영향	최소	상당할 수 있음
접근 관리	역할 관리	정책 관리
가장 적합한 용도	잘 정의된 권한 구조	동적이며 상황에 알맞은 접근 제어

참고

• 액세스 제어 (Access control)
• 역할 기반 액세스 제어 (Role-based access control, RBAC)
• 권한 부여 (Authorization)