Elasticsearch의 인증과 권한 부여 이해하기

By
Gabriel Moskovicz

4년 넘게 Elastic에서 근무하면서, 3년 반 동안 지원 및 컨설팅을 담당했고, 나머지 반 년 동안에는 영업 업무를 처리했지만, 어느 부서에 있든, 사용자들이 묻곤 했던 가장 흔한 질문은 Elasticsearch 보안에 대한 것입니다. Elasticsearch는 어느 유형의 인증을 지원하나요? 어떻게 그 인증을 설정하나요? 사용자들이 봐서는 안되는 데이터를 보지 않도록 어떻게 확실하게 작업할 수 있나요? 이 블로그에서 그러한 질문에 답변하고, 보안을 구성하는 동안 발생하는 몇 가지 일반적인 문제 해결을 위한 지침을 제공해드리려고 합니다.

먼저, 보안이 어떻게 제공되어왔는지 간단히 살펴보겠습니다. Elasticsearch를 한동안 사용해오고 계시다면, 전에는 X-Pack에 포함된 Shield라는 플러그인에서 보안이 제공되었다는 것을 아실 것입니다. 요즘에는 보안 기능이 (X-Pack의 나머지 구성 요소와 함께) Elastic Stack으로 옮겨갔으며, 가장 일반적으로 사용되는 기능들과 더불어 무료로 기본 배포를 통해 제공됩니다. 보안에는 암호화된 통신(TLS/SSL), 인증(기본, LDAP, SSO 등), 권한 부여(RBAC, ABAC 등), IP 필터링, 감사 로깅과 그 밖에 여러 가지가 포함됩니다. 이 블로그는 두 가지 “인증”에 중점을 두게 됩니다.

Elasticsearch의 인증

간단히 말해, 사용자나 API가 Elasticsearch에 접근하고자 하는 경우, 인증을 받아야 합니다.

Elasticsearch는 기본적으로 다음과 같은 다양한 보안 방법을 지원합니다.

이 중 하나에 해당되지 않는 경우, 자체 통합을 생성할 수도 있습니다. 그러나, 우리는 통상적으로 기존 통합 중 하나를 사용하실 것을 권장합니다. 유효성 검사가 완료되고 계속해서 개발을 진행하여 적절한 지원을 제공해드리기 때문입니다.

Elasticsearch 내에서 보안의 가장 기본적인 구성 요소는 영역이며, 바로 이 영역이 사용자를 확인하고 인증하는 것입니다. 위의 목록에 있는 각 인증 방법은 영역으로 간주됩니다. 그리고 기능을 수행하기 위해, Elasticsearch는 영역 체인과 함께 작동합니다. 영역 체인은 기본 설정의 오름차순으로 우선 순위가 지정된 구성된 영역의 목록입니다(1부터 N 영역까지). 사용자가 Elasticsearch에 접근하려고 할 때, 인증이 성공할 때까지 또는 더 이상 시도할 영역이 없을 때까지 요청은 연속하여 이 목록을 훑게 됩니다.

근본적으로, 이 프로세스는 목록에서 구성된 첫 번째 영역을 시도하고, 그것이 실패하면, 영역 항목 중 하나로 성공하거나 전체 목록을 통해 남김 없이 실행해보거나 할 때까지 계속해서 그 다음 영역을 시도하게 됩니다. Elasticsearch에 접근하기 위한 이 첫 번째 단계를 인증이라고 합니다.

사용자가 인증되면, Elasticsearch는 그 다음으로 사용자에게 하나 또는 그 이상의 역할을 할당하려는 시도를 하게 됩니다. 역할은 사용자 속성 몇 가지를 기반으로 인증 중에 정적으로 또는 동적으로 사용자에게 할당될 수 있습니다. 사용자를 인증한 영역 유형에 따라, 역할을 할당하는 데 사용되는 사용자 속성은 사용자가 외부 시스템에서 보유하고 있는 그룹 구성원 자격일 수도 있고, Elasticsearch 사용자 이름의 접미사일 수도 있습니다. 아울러, Elasticsearch는 또한 다음 계정으로 실행 기능을 특징으로 합니다. 이것은 사용자가 재인증을 요구하지 않고 다른 사용자들 대신 요청을 제출할 수 있게 해줍니다.

인증 단계가 완료되면, 다음 단계는 권한 부여입니다. 다음 차트에서 전체 워크플로우를 확인하실 수 있습니다.

Elasticsearch의 영역 체인

Elasticsearch의 권한 부여

인증이 성공적으로 끝나면, 사용자는 두 번째 보안 검사점인 권한 부여로 이동하게 됩니다. 권한 부여는 사용자가 요청을 실행하도록 허용될 것인지 여부를 결정하는 프로세스이며, 미리 정의된 그리고/또는 사용자 정의된 역할에 대한 사용자 매핑을 통해 이루어집니다. Elasticsearch와 함께 기본으로 제공되는 역할들이 있지만 사용 사례를 위해 특정한 역할을 생성할 수도 있습니다.

역할은 다음으로 이루어집니다.

  • 접근할 수 있는 사용자 목록
  • 클러스터 권한
  • 글로벌 권한
  • 인덱스 권한
  • 애플리케이션 권한

이 두 번째 단계에서, Elasticsearch는 다음 중 하나를 이용하게 됩니다.

  • role_mapping API는 API 기반의 중앙화된 방식으로 각 역할의 매핑을 관리할 수 있기 때문에 선호되는 방법입니다. 이것은 Elastic Cloud의 Elasticsearch Service에서 역할 매핑을 구성할 수 있는 유일한 방법입니다.
  • 구성 폴더 내의 각 노드에 존재하는 role_mapping 파일(role_mapping.yml)

role_mapping API는 역할을 관리할 수 있는 적절한 권한을 가진 사용자가 호출합니다. Elastic 사용자가 갖는 superuser 역할이 그 한 예입니다. 그러나 이를 위한 특정한 역할을 생성할 수도 있습니다.

영역과 역할은 정의가 완전히 다릅니다. 영역과 영역 체인은 인증을 받기 위해 우리가 사용하는 것이고, 인증 단계 후에 우리는 역할을 이용해 사용자를 매핑하게 됩니다. 사용자가 영역 체인으로부터 단일한 영역을 사용해 인증받는 경우에만, 두 번째 단계에서 사용자가 1개부터 다수의 역할까지 매핑될 수 있습니다. 이것은 또한 역할 기반 액세스 제어라고도 알려져 있습니다.

인증 및 권한 부여 사안에 대한 문제 해결 단계

인증 및 권한 부여가 어떻게 작동하는지에 대한 기본 사항을 다 살펴보았으므로, 이제 문제가 생기는 경우 적용할 수 있는 문제 해결 단계를 몇 가지 살펴보겠습니다.

401 권한 없음

영역 중 하나를 사용해 인증될 수 없는 경우, 401 권한 없음 상태 코드가 나타나게 됩니다. 구성된 영역 목록에 대해 자격 증명을 시도하기 위한 사장 쉬운 방법은 검사를 허용하는 플래그가 있는 cURL입니다(예를 들어, -v). 다음과 같은 메시지를 받을 수도 있습니다. 

curl https://xxxxxx:9200 -u test:test -v 
> User-Agent: curl/7.54.0 
> Accept: */* 
> 
< HTTP/1.1 401 Unauthorized 
< Content-Type: application/json; charset=UTF-8 
< Date: Tue, 10 Sep 2019 15:59:33 GMT 
< Www-Authenticate: Bearer realm="security" 
< Www-Authenticate: ApiKey 
< Www-Authenticate: Basic realm="security" charset="UTF-8" 
< Content-Length: 455 
< Connection: keep-alive 
< 
* Connection #0 to host 06618318cff64c829af1cd5a2beb91a5.us-east-1.aws.found.io left intact 
{"error":{"root_cause":[{"type":"security_exception","reason":"unable to authenticate user [test] for REST request [/]","header":{"WWW-Authenticate":["Bearer realm=\"security\"","ApiKey","Basic realm=\"security\" charset=\"UTF-8\""]}}],"type":"security_exception","reason":"unable to authenticate user [test] for REST request [/]","header":{"WWW-Authenticate":["Bearer realm=\"security\"","ApiKey","Basic realm=\"security\" charset=\"UTF-8\""]}},"status":401}%

이 오류 메시지는 문제의 근본 원인을 파악하는 데 도움이 될 수 있습니다. 예를 들어, Elasticsearch 및 ID 공급자와 상호작용을 하기 위해 Kibana 또는 사용자 정의 웹 애플리케이션이 필요한 SAML과 같은 특정한 영역들이 있습니다.

오류 로깅 활성화

영역, 영역 체인, 역할 및 역할 매핑을 설정한 후, 그래도 계속 문제가 있는 경우, 일부 추가 로깅을 손쉽게 구성하여 우리가 앞서 다룬 인증 및 권한 부여 프로세스에 대한 추가 정보를 얻을 수 있습니다.

클러스터 설정 API 내에서 로깅 구성을 사용하여, 모든 영역에 대해 로깅 수준을 정의할 수 있습니다.

LDAP 영역의 예를 살펴봅시다. 사용자 인증 또는 권한 부여가 실패하는 경우, 다음 로깅 수준을 설정하여 그에 대한 추가 정보를 얻을 수 있습니다. 

PUT /_cluster/settings 
{ 
  "transient": { 
     "logger.org.elasticsearch.xpack.security.authc.ldap":"DEBUG", 
     "logger.org.elasticsearch.xpack.security.authz":"DEBUG" 
   } 
}

이것은 기본값에서 DEBUG로 LDAP 패키지에 대한 로깅 수준을 증가시키게 됩니다. 또한 그로부터 서버에 대해 이루어진 모든 LDAP 호출과 그로부터의 응답 같은 훨씬 더 많은 정보를 얻기 위해 TRACE 로깅도 활성화할 수 있습니다. 저희의 GitHub 리포지토리를 사용해 특정한 각 REALM에서 활성화하기 위한 패키지 이름을 찾을 수 있습니다. 예를 들어, 다음은 LDAP 영역에 대한 코드입니다. 코드의 첫 줄을 사용해, 다음과 같이 로깅 수준에 대해 사용될 패키지를 볼 수 있습니다. 

package org.elasticsearch.xpack.security.authc.ldap;

이것이 활성화되면, 다음 예와 같이 수많은 로그 줄을 보게 됩니다. 

[2019-09-12T08:41:20,628][DEBUG][o.e.x.s.a.l.LdapRealm   ] [xxxxxxx] user not found in cache, proceeding with normal authentication
[2019-09-12T08:41:21,180][TRACE][o.e.x.s.a.l.s.LdapUtils ] LDAP Search SearchRequest(baseDN='dc=xxx,dc=xxxx,dc=domain,dc=com', scope=SUB, deref=NEVER, sizeLimit=0, timeLimit=5, filter='(cn=vchatzig)', attrs={1.1}) => SearchResult(resultCode=0 (success), messageID=2, entriesReturned=1, referencesReturned=0) ([SearchResultEntry(dn='cn=xxxxxxx,ou=xxxxx,dc=intc,dc=xxxx,dc=domain,dc=com', messageID=2, attributes={}, controls={})])

여기에서 우리는 캐시로부터 사용자를 확인하려고 하는, 그리고 그 다음에는 우리가 제공한 특정한 구성을 사용해 서버에게 LDAP Search 요청을 하는 LDAP 영역을 볼 수 있습니다. 이것은 여러분이 얻게 되는 수많은 로그 줄의 한 예일뿐입니다.

참고: 로깅 활성화는 진단에는 유용하지만 성능에 대해서는 그리 유용하지 않습니다. 일단 모든 것이 작동하는지 확인한 후에는, 다음을 이용해 로깅 수준 설정을 다시 기본값으로 돌려놓으실 것을 권장합니다. 

PUT /_cluster/settings 
{ 
  "transient": { 
     "logger.org.elasticsearch.xpack.security.authc.ldap": null, 
     "logger.org.elasticsearch.xpack.security.authz": null 
   } 
}

이러한 패키지 중 일부는 버전에 따라 달라질 수 있다는 점에 유의하세요. 따라서 특정한 해당 릴리즈에 대한 GitHub 클래스 링크와 더불어 사용 중이신 특정한 Elasticsearch 버전에 대한 설명서 링크를 다시 확인해보실 것을 권장합니다.

일반적인 SAML 문제

SAML 영역에는 Elasticsearch와 함께 서비스 제공자 역할을 하는 (Okta 또는 Auth0 같은) ID 공급자와 웹 애플리케이션(기본값은 Kibana)이 필요합니다. 우리가 흔히 보게 되는 몇 가지 문제는 다음과 같습니다.

  • ID 공급자(IdP) 구성에서 잘못된 검증 소비자 서비스 URL 설정. ID 공급자에서 통상적으로 구성해야 하는 엔드포인트는 https://kibana.xxxx.com/api/security/v1/saml입니다.
  • ID 공급자의 메타데이터는 인터넷을 통해서는 접근할 수 없습니다. 온-프레미스나 Elastic Cloud의 Elasticsearch idp.metadata.path 구성의 값은 Elasticsearch/Kibana가 실행 중인 네트워크를 통해 접근해야 합니다. 그렇지 않은 경우, 거기에 접근할 수 있는 호스트로부터 메타데이터를 다운로드해야 하거나, IdP 관리자에게 메타데이터를 요청하고 Elasticsearch의 로컬 파일로 그것을 추가하고 참조해야 합니다. 나타나는 오류는 다음과 비슷할 것입니다. 
    Caused by: net.shibboleth.utilities.java.support.resolver.ResolverException: net.shibboleth.utilities.java.support.resolver.ResolverException: Non-ok status code 404 returned from remote metadata source https://xxxx.xxxx/xxx/yyyyyyyy/sso/saml/metadata
  • 여러분은 인증을 받을 수 있지만 사용자는 Kibana를 열 수 없습니다. 이를 위해 우리는 최소한 그 역할 중 하나가 Kibana에 액세스하는지 확인하기 위해 통상적으로 사용자를 위한 역할 매핑을 다시 확인할 것을 권장합니다.

ID 공급자 구성은 Elasticsearch/Kibana 구성만큼 중요하며, 우리는 언제나 예상되는 설정과 구성된 설정 간에 오타와 잘못된 매칭이 있는지 찾아보아야 합니다. 특정한 ID 공급자(IdP)가 각각 자체 설정을 갖더라도, 필요한 각 특정 설정에 대한 설명서를 보다 세심하게 살펴보실 것을 권장합니다.

SAML에 대한 보다 일반적인 사안과 문제 해결 단계를 보려면, 각 릴리즈와 함께 유지 관리되는 저희 문제 해결 설명서를 확인하시기 바랍니다.

결론

Elasticsearch의 인증은 일단 우리가 그 이면의 모든 개념을 이해하면 아주 쉽게 설정할 수 있는 것입니다. 또한, 어떤 것들이 잘 작동하고 있고, 어떤 것들이 제대로 작동하지 않는지 그리고 그 이유가 무엇인지에 대해 이해하는 것은 때로는 어려울 수 있지만 이 포스팅에서 우리는 좀더 세심하게 살펴보기 위해 수많은 옵션을 다루었습니다. Elasticsearch에서 보안 시작하기에 대한 저희 설명서를 이용하시거나 저희 설명서에서 보안에 대한 문제 해결 가이드를 이용하실 수 있습니다. 저희 Elastic Security 수석 제품 관리자가 시작하기 환경에 대해 상세하게 설명하는 것을 확인해 보세요.

또한 저희 구독 페이지를 다시 확인하시고 각 수준에 포함되는 기능에 대해 더 자세히 알아보실 것을 권장합니다. 끝으로, 특정한 질문이 있으시면, 지원 담당자에게 연락하시거나 저희 토론 포럼을 이용하실 수 있습니다.

즐거운 보안 작업 되세요!