인사이트리포트

들어가며

산업의 계속된 성장으로 매년 데이터 양이 급격히 늘어나고 있다. 이에 따라 ChatGPT 같은 대규모 언어 모델(Large Language Model, LLM)을 활용한 AI 기술들이 빠르게 개발되고 출시되고 있다. 우리는 이러한 기술들을 적극 구현하고 활용할 때, 접근 제어 처리와 같은 보안 설계 단계에서도 많은 노력을 기울여야 한다. 접근 제어 또는 인증 메커니즘이 제대로 구현되지 않을 경우, 권한이 없는 사용자가 무단으로 정보를 취득하는 등의 심각한 문제가 발생할 수 있기 때문이다.

시장의 요구를 충족시키기 위해 엘라스틱서치(Elasticsearch)에서는 AI 기술을 활용한 검색 기능을 강화하고 있다. 키워드 중심의 전통적인 검색(Traditional search)을 넘어 벡터DB로써 활용할 수 있는 벡터 검색(Vector search)인 K-최근접이웃 검색(K-nearest neighbor search, knn search)과 희소 벡터 표현(Elastic Learned Sparse EncodeR, ELSER)을 활용한 시맨틱 검색까지 확장하고 있다. 단순히, 이러한 기술에만 그치지 않고, 접근 제어 처리를 효과적으로 결합하기 위해 역할 기반 접근 제어(Role-based access control, RBAC) 기능과 속성 기반 접근 제어(Attribute-Based Access Control, ABAC) 컨셉을 구현하기 위한 유용한 기능들을 제공하고 있다.

접근 제어(Access Control)란?

접근 제어는 방대한 양의 정보를 보호하기 위한 메커니즘으로 컴퓨팅 패러다임의 변화와 함께 진화하였다.

접근 제어의 개념은 1970년대에 처음 제안되었으며, 이후 임의 접근 제어(Discretionary Access Control, DAC), 의무적 접근 제어(Mandatory Access Control, MAC) 등 여러 접근 제어 모델이 등장하였다. 이후, MAC과 DAC의 단점을 보완하기 위해 MAC의 강력한 보안성과 DAC의 유연성을 조합하여, 사용자의 역할을 그룹화하고 각 역할에 대한 권한을 부여하는 방식인 역할 기반 접근 제어(Role-Based Access Control, RBAC) 개념이 소개 되었다. 이후, 미국의 NIST (National Institute of Standards and Technology)에서 역할 기반 접근 제어(Role-Based Access Control, RBAC) 표준을 제안하는 등 다양한 연구가 이루어졌다.

이후의 복잡한 환경과 요구사항에 맞추기 위해, 속성 기반 접근 제어(Attribute-Based Access Control, ABAC)의 개념이 2005년 E Yuan의 “Attributed based access control (ABAC) for web services” 논문에서 처음 소개 되었다.

그럼, 오늘날 많이 사용하고 있는 RBAC과 ABAC 모델에 대해 간단하게 살펴보자.

RBAC

RBAC (Role-Based Access Control)은 사용자에게 특정 규칙(rule)을 갖는 역할(role)을 할당하여, 이 역할을 갖는 사용자는 특정한 액션을 수행할 수 있는 권한과 접근 가능한 리소스가 어떻게 결정되는지를 나타내는 모델이다.

예를 들어, 마케팅 그룹의 사용자 100명, 개발 그룹의 사용자 200명, 영업 그룹 200명으로 구성되어 있는 조직의 자원을 관리해야 한다면, 마케팅, 개발, 영업에서 접근 가능한 자원을 정의하여 역할을 만든다면, 3개의 역할로 500명을 관리 할 수 있다.

이러한 특징을 가지고 있기 때문에, 관리해야 하는 역할이 명확하고, 그 개수가 적을 경우, 매우 효율적으로 관리할 수 있다. 즉, 공동의 역할을 가지고 있는 다수의 사용자에게 그룹화하여 적용하는 케이스에서 사용한다면, 매우 좋은 모델이 될 것이다.

하지만, 특정 사용자마다 여러 가지 권한을 부여하는 등의 상호 배타적인 권한을 부여해야 하는 케이스가 많을 경우, 모델 특성상 구현의 복잡도가 높아지는 특징이 있다.

ABAC

ABAC (Attribute-Based Access Control)은 사용자의 속성(부서, 직책)이나 환경 속성(접근 시간, 접근 장소, 디바이스 종류) 자원 속성(생성일, 접근 보안 레벨) 등의 접근 제어의 필요한 속성들을 정의하고, 각 사용자(혹은 주체)마다 리소스의 접근 제어를 속성을 기반으로 정교한 접근 제어 처리를 하는 모델이다.

RBAC은 여러 사용자가 특정 집합에 속하는 규칙을 만들어야 할 때, 역할을 만들어 손쉽게 관리할 수 있는 반면에, ABAC은 사용자 별로 특정 집합에 속하게 만들기 어렵고, 사용자 마다, 여러 속성을 기준으로 접근 처리를 해야 할 때 사용하면 좋은 모델이다.

예를 들어, 특정 사용자(사용자 속성)에게 특정 정보(자원 속성)를 제각각 특정 시간(환경 속성) 동안에만 접근 처리를 허용하는 케이스라면, 속성을 기반하여 접근 수준을 손쉽게 결정할 수 있다.

이러한 특징을 가지고 있기 때문에, 사용자마다 개인화된 다양하고 복잡한 접근 처리를 해야 할 때 효과적이다.

하지만, 다양하고 복잡한 접근 처리를 하기 위하여, 초기 설정이 복잡하고 검증하는 작업의 많은 시간이 소요된다는 단점이 있다.

엘라스틱서치에서 접근제어를 처리하는 방법은?

엘라스틱서치에서 접근 제어를 반영하는 방법은 크게 세가지가 있으며, 각각의 방법에는 기술적으로 장점과 단점이 분명하다. 때문에, 주어진 리소스와 권한 처리 요구사항에 따라 적절한 방법을 활용해야 한다.

• Elastic의 RBAC(Role-Based Access Control)
• Document-Level ABAC(Attribute-Based Access Control)
• Elastic의 IP Filtering

Elastic의 RBAC(Role-Based Access Control)

Elastic은 기본적인 접근 처리를 위해 RBAC 기능을 제공하고 있다.

Elastic RBAC의 요소로 ‘User’, ‘Group’, ‘Permission’, ‘Role’, ‘Secured Resource’ 로 구성되어 있으며, 일반적으로 쓰이는 RBAC 요소와 크게 다른 점은 없다.

참고로, 여기서의 Group은 ‘LDAP’, ‘OpenID Connect’ 등의 엑세스 프로토콜을 활용하여 사용자를 Group으로 관리 한다는 점을 유의해야 한다.

Elastic RBAC 기능으로 처리할 수 있는 엑세스 단위는 ‘클러스터’, ‘인덱스’, ‘문서’, ‘필드’ 수준으로 나눌 수 있다. 클러스터와 인덱스는 사전 정의 된 privilege로 제어할 수 있으며, 문서 수준은 query로 제어할 수 있고, 필드 같은 경우는 field_security 속성의 grant(허가 필드), except(거부 필드)로 제어를 할 수 있다. 이 때 주의할 점은 except가 grant 보다 우선이 된다는 것이다. 예를 들어, grant는 모든 필드를, except에는 고객 필드를 명시하였을 경우, 고객 필드를 제외한 모든 필드에 접근이 허용이 된다.

Elastic RBAC에서 역할(Role) 에 대해 조금 더 알아보겠다.

Elastic에서 역할(Role)은 역할(Role)끼리 계층적으로 상속할 수 없지만, 한 명의 사용자에게 N개의 역할(Role)을 부여할 수 있다는 것이 주요 특징이다.

다중 역할(Role)을 부여 받았을 때, 처리하는 방법은 기본적으로 합집합으로 처리한다.

예를 들어, 모든 문서를 볼 수 있는 권한을 부여한 역할1, A의 문서만 볼 수 있는 권한을 부여한 역할2가 있고, 한 명의 사용자에게 역할1, 역할2를 동시에 부여한다면 합집합 처리가 되기 때문에, 이 사용자는 결론적으로 모든 문서를 볼 수 있는 권한을 획득 한다.

만약, 계층적인 권한 구조를 고려해야 하는 요구사항이 있다면, 이러한 합집합 메커니즘을 통해서, 복잡하지만 개념적으로는 계층적으로 상속 받는 것처럼 구현할 수 있다.

이러한 특징들을 고려하여, 요구사항에 따라 Elastic의 RBAC을 활용하여 접근 제어 구현을 고려해볼 수 있다.

Document-Level ABAC(Attribute-Based Access Control)

Elastic의 ABAC은 RBAC과 달리, Elastic에서 솔루션 형태로 제공하고 있진 않다.

하지만, 도큐먼트 수준에서 ABAC 컨셉을 구현하기 위한 유용한 기능들을 제공하고 있고, 활용 방법이나 아이디어에 따라, 다양한 방법으로 구현할 수 있다는 점이 특징이다.

인덱스 설계에 따라, 일반적인 bool query를 활용할 수 있고, terms_set query를 활용 하여 접근 처리를 할 수 있다.

벡터 값을 저장하고, K-최근접이웃 검색(knn search)를 활용하면서 terms_set query를 활용하여 ABAC을 적용한 예시를 간략하게 소개하겠다.

예를 들어, 아래처럼 마케팅 문서 인덱스의 mapping을 생성한다.

이후에, 아래처럼 도큐먼트 3개를 생성한다. 이때, ‘보안_속성’ 과 ‘보안_속성_최소_매치’ 값이 약간 상이한 것을 볼 수 있다.

‘보안_속성’과 ‘보안_속성_최소_매치’ 필드의 값들이 도큐먼트마다 다르기 때문에, 동적인 처리를 위해 terms_set query를 활용할 수 있다. 이때, 벡터 검색인 knn search도 함께 사용해보겠다.

아래 query를 해석해보면, query_vector의 값이 [-5, 9, -12] 가까운 도큐먼트를 검색하되, 마케팅사용자, 내부망, 문서보안_A등급, 문서보안_C등급에 해당하는 속성 중에, 각 도큐먼트 마다 보안_속성_최소_매치 값에 따라 매치 되는 결과 있으면 필터링해서 반환하라는 의미이다.

이 때, 반환되는 도큐먼트는 1번 도큐먼트인 ‘마케팅 커뮤니케이션과 편견’과 2번 도큐먼트인 ‘고객 구매 여정 기반의 디지털 마케팅 성과 분석 방안’이 될 것이다.

이러한 특징을 활용하여, 도큐먼트 수준에서의 ABAC을 고려한 접근 제어를 설계할 수 있다. 요구사항에 따라, 위에서 살펴본 ABAC과 Elastic의 RBAC을 조합하여 구현할 수도 있다.

Elastic의 IP Filtering

Elastic에서 제공하는 IP Filtering 기능을 사용하면, 상대적으로 약한 수준의 접근 제어를 구현할 수 있다. 이 기능을 단독으로 사용할 경우, IP만을 기준으로 제어하기 때문에 사용자마다 특별한 접근 제어를 적용하긴 어렵지만, Elastic 리소스에 대한 1차적인 접근 제어 역할을 수행한다는 점에서 활용할 수 있다.

Elastic에서 제공하는 IP Filtering 기능은 IP주소 또는 CIDR(Classless Inter-Domain Routing) 블록을 기준으로 사용자 또는 클라이언트의 접근 제어에 사용할 수 있다.

기본적인 제어 동작은 allow(허가하는 IP) 와 deny(거부하는 IP)로 제어할 수 있으며,

http 수준과 transport 수준을 나누어 제어할 수 있다.

이 때, allow > deny의 우선순위를 가지고 있다는 점을 유의해야 한다. 예를 들어 ‘172.16.0.0/16’을 allow하고, 전체 IP를 deny 할 경우, 172.16.0.0/16만을 허용한다.

마치며

지금까지 엘라스틱서치에서 접근 제어를 처리하는 방법에 대해서 살펴보았다.

대규모 언어 모델(Large Language Model, LLM)을 활용한 AI 기술들이 빠르게 발전함에 따라, 보안의 중요성도 함께 강조만큼 접근 제어를 반영한 설계도 매우 중요하다.

사실, 실세계에서 접근 제어를 처리하기 위해서 하나의 방법만을 가지고 해결하기 어려운 상황이 많다. 그렇기에, 다양한 방법을 조합하여 면밀히 검증해야 할 것이다.

아래 표는 엘라스틱서치에서 접근 제어 방법에 대한 요약이다.

에스코어는 국내 최초의 엘라스틱 MSP(Managed Service Provider)로서 엘라스틱社가 공인한 엔지니어로 구성된 국내 최대 규모의 전문가 조직으로 엘라스틱에 대한 기술 조언, 문제 해결, 기술 지원을 패키지한 케어팩(Carepack) 서비스와 컨설팅 서비스 등을 제공하고 있다.