Amazon Elasticsearch Service의 세분화된 액세스 제어 - Amazon Elasticsearch Service

문서의 영문과 번역 사이에 충돌이 있는 경우에는 영문 버전을 따릅니다. 번역 버전은 기계 번역을 사용하여 제공합니다.

Amazon Elasticsearch Service의 세분화된 액세스 제어

세분화된 액세스 제어를 사용하면 추가적인 방법으로 Amazon Elasticsearch Service에서 데이터에 대한 액세스를 제어할 수 있습니다. 예를 들어, 요청하는 사용자에 따라 하나의 인덱스에서만 검색 결과를 반환하도록 할 수 있습니다. 또는 문서의 특정 필드를 숨기거나 특정 문서를 모두 제외할 수 있습니다. 세분화된 액세스 제어는 다음과 같은 기능을 제공합니다.

  • 역할 기반 액세스 제어

  • 인덱스, 문서 및 필드 수준의 보안

  • Kibana 멀티테넌시

  • Elasticsearch 및 Kibana에 대한 HTTP 기본 인증

더 큰 그림: 정교한 액세스 제어 및 Amazon ES 보안

Amazon Elasticsearch Service 보안은 크게 3가지 계층으로 구성됩니다.

네트워크

첫 번째 보안 계층은 네트워크로, Amazon ES 도메인에 요청이 도달하는지 여부를 결정합니다. 도메인을 생성할 때 퍼블릭 액세스를 선택하는 경우 인터넷에 연결된 클라이언트의 요청이 도메인 엔드포인트에 도달할 수 있습니다. VPC 액세스를 선택하는 경우 요청이 엔드포인트에 도달하려면 클라이언트를 VPC에 연결해야 합니다(연결된 보안 그룹에서 이를 허용해야 함). 자세한 정보는 Amazon Elasticsearch Service 도메인에 대한 VPC 지원 단원을 참조하십시오.

도메인 액세스 정책

두 번째 보안 계층은 도메인 액세스 정책입니다. 도메인 엔드포인트에 요청이 도달하면 리소스 기반 액세스 정책에서 지정된 URI에 대한 요청 액세스를 허용하거나 거부합니다. 액세스 정책은 요청이 Elasticsearch 자체에 도달하기 전에 도메인 “경계”에서 요청을 승인하거나 거부합니다.

세분화된 액세스 제어

마지막 세 번째 보안 계층은 세분화된 액세스 제어입니다. 리소스 기반 액세스 정책에서 도메인 엔드포인트에 요청이 도달하도록 허용한 이후 세분화된 액세스 제어에서 사용자 자격 증명을 평가하고 사용자를 인증하거나 요청을 거부합니다. 세분화된 액세스 제어에서 사용자를 인증하는 경우 해당 사용자에게 매핑된 모든 역할을 가져오고 전체 권한 세트를 사용하여 요청을 처리하는 방법을 결정합니다.

참고

리소스 기반 액세스 정책에 IAM 사용자 또는 역할이 포함된 경우 클라이언트에서 AWS 서명 버전 4를 사용하여 서명된 요청을 보내야 합니다. 따라서 액세스 정책이 세분화된 액세스 제어와 충돌할 수 있으며, 내부 사용자 데이터베이스와 HTTP 기본 인증을 사용하는 경우 특히 그렇습니다. 사용자 이름 및 암호와 IAM 자격 증명을 함께 사용하여 요청에 서명할 수는 없습니다. 일반적으로 세분화된 액세스 제어를 활성화하는 경우 서명된 요청이 필요 없는 도메인 액세스 정책을 사용하는 것이 좋습니다.

첫 번째 다이어그램은 세분화된 액세스 제어가 활성화된 VPC 액세스 도메인, IAM 기반 액세스 정책, IAM 마스터 사용자를 포함한 일반적인 구성을 보여 줍니다.


        VPC 도메인을 사용하는 경우 세분화된 액세스 제어 권한 부여 흐름

이 두 번째 다이어그램은 세분화된 액세스 제어가 활성화된 퍼블릭 액세스 도메인, IAM 보안 주체를 사용하지 않는 액세스 정책, 내부 사용자 데이터베이스의 마스터 사용자를 포함한 또 다른 일반적인 구성을 보여 줍니다.


        퍼블릭 액세스 도메인을 사용하는 경우 세분화된 액세스 제어 권한 부여 흐름

Example

고려 사항 GET 요청 movies/_search?q=thor. 사용자가 movies 지수가 있습니까? 그렇다면 사용자가 인덱스 내의 모든 문서를 볼 수 있는 권한을 갖습니까? 응답에서 일부 필드를 생략하거나 익명화해야 합니까? 마스터 사용자의 경우 응답은 다음과 같을 수 있습니다.

{ "hits": { "total": 7, "max_score": 8.772789, "hits": [{ "_index": "movies", "_type": "_doc", "_id": "tt0800369", "_score": 8.772789, "_source": { "directors": [ "Kenneth Branagh", "Joss Whedon" ], "release_date": "2011-04-21T00:00:00Z", "genres": [ "Action", "Adventure", "Fantasy" ], "plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.", "title": "Thor", "actors": [ "Chris Hemsworth", "Anthony Hopkins", "Natalie Portman" ], "year": 2011 } }, ... ] } }

보다 제한된 권한을 가진 사용자가 동일한 요청을 실행하는 경우 응답은 다음과 같을 수 있습니다.

{ "hits": { "total": 2, "max_score": 8.772789, "hits": [{ "_index": "movies", "_type": "_doc", "_id": "tt0800369", "_score": 8.772789, "_source": { "year": 2011, "release_date": "3812a72c6dd23eef3c750c2d99e205cbd260389461e19d610406847397ecb357", "plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.", "title": "Thor" } }, ... ] } }

응답의 결과 수와 각 결과의 필드 수가 더 적습니다. 또한 release_date 필드는 익명화됩니다. 권한이 없는 사용자가 동일한 요청을 하는 경우 클러스터에서 오류가 반환됩니다.

{ "error": { "root_cause": [{ "type": "security_exception", "reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]" }], "type": "security_exception", "reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]" }, "status": 403 }

사용자가 유효하지 않은 자격 증명을 제공하는 경우 클러스터에서 Unauthorized 예외가 반환됩니다.

핵심 개념

역할은 세분화된 액세스 제어를 사용하는 핵심 방법입니다. 이 경우 역할은 IAM 역할과 구별됩니다. 역할에는 클러스터 전체, 인덱스별, 문서 수준, 필드 수준 등 다양한 권한 조합이 포함됩니다.

역할을 구성한 후에는 한 명 이상의 사용자에게 매핑합니다. 예를 들어, 세 가지 역할을 단일 사용자에게 매핑할 수 있습니다. Kibana에 대한 액세스를 제공하는 하나의 역할은 읽기 전용 액세스를 제공하는 index1, 그리고 index2. 또는 단일 역할에 이러한 권한을 모두 포함할 수 있습니다.

사용자는 Elasticsearch 클러스터에 요청을 수행하는 사람 또는 애플리케이션을 의미하며, 요청을 수행할 때 지정하는 자격 증명(IAM 액세스 키 또는 사용자 이름/암호)을 갖습니다. Amazon Elasticsearch Service에서 세분화된 액세스 제어를 사용하는 경우 도메인을 구성할 때 마스터 사용자의 자격 증명을 둘 중 하나로 선택할 수 있습니다. 마스터 사용자는 클러스터에 대한 모든 권한을 가지며 역할 및 역할 매핑을 관리합니다.

  • 마스터 사용자에 IAM을 선택할 경우 클러스터에 대한 모든 요청에 AWS 서명 버전 4를 사용하여 서명해야 합니다. 샘플 코드에 대한 내용은 Amazon Elasticsearch Service에 대한 HTTP 요청 서명를 참조하십시오.

    여러 클러스터에서 동일한 사용자를 사용하려는 경우, Amazon Cognito를 사용하여 Kibana에 액세스하려는 경우(외부 자격 증명 공급자의 유무에 관계없음) 또는 서명 버전 4를 사용한 서명을 지원하는 Elasticsearch 클라이언트가 있는 경우 IAM이 권장됩니다.

  • 내부 사용자 데이터베이스를 선택하는 경우 HTTP 기본 인증(및 IAM 자격 증명)을 사용하여 클러스터에 요청을 수행할 수 있습니다. 대부분의 클라이언트는 curl을 포함한 기본 인증을 지원합니다. 내부 사용자 데이터베이스는 Elasticsearch 인덱스에 저장되므로 다른 클러스터와 공유할 수 없습니다.

    여러 클러스터에서 사용자를 재사용할 필요가 없는 경우, Amazon Cognito가 아닌 HTTP 기본 인증을 사용하여 Kibana에 액세스하려는 경우 또는 기본 인증만 지원하는 클라이언트가 있는 경우 내부 사용자 데이터베이스가 권장됩니다. 내부 사용자 데이터베이스는 Amazon ES를 시작하는 가장 간단한 방법입니다.

세분화된 액세스 제어 활성화

세분화된 액세스 제어는 콘솔, AWS CLI 또는 구성 API를 사용하여 활성화할 수 있습니다. 콘솔을 사용하는 방법이 가장 간편합니다. 단계는 Amazon Elasticsearch Service 도메인 생성 및 관리를 참조하십시오. 세분화된 액세스 제어를 활성화하기 위한 요구 사항은 다음과 같습니다.

기존 도메인에서는 세분화된 액세스 제어를 활성화할 수 없으며 새 도메인에서만 활성화할 수 있습니다. 세분화된 액세스 제어를 활성화한 후에는 비활성화할 수 없습니다.

마스터 사용자로 Kibana에 액세스

세분화된 액세스 제어 기능에는 관리 작업을 간소화하는 Kibana 플러그인이 포함되어 있습니다. Kibana를 사용하여 사용자, 역할, 매핑, 작업 그룹 및 테넌트를 관리할 수 있습니다. 그러나 Kibana 로그인 페이지와 기본 인증 방법은 도메인을 구성한 방법에 따라 다릅니다.

권한 관리

핵심 개념에 설명된 대로 세분화된 액세스 제어 권한은 역할, 사용자 및 매핑을 사용하여 관리합니다. 이 단원에서는 이러한 리소스를 생성하고 적용하는 방법을 설명합니다. 이러한 작업을 수행하려면 마스터 사용자로 Kibana에 로그인하는 것이 좋습니다.


        Kibana의 Security(보안) 홈 페이지

역할 생성

Kibana 또는 REST API의 _opendistro/_security 작업을 사용하여 세분화된 액세스 제어를 위한 새 역할을 생성할 수 있습니다. 자세한 내용은 Open Distro for Elasticsearch 설명서를 참조하십시오.

세분화된 액세스 제어에는 여러 가지 미리 정의된 역할도 포함됩니다. Kibana 및 Logstash와 같은 클라이언트는 Elasticsearch에 다양한 요청을 수행하므로 최소한의 권한 세트를 사용하여 역할을 수동으로 생성하기가 어려울 수 있습니다. 예를 들어 kibana_user 역할에는 사용자가 인덱스 패턴, 시각화, 대시보드 및 테넌트를 사용하는 데 필요한 권한이 포함됩니다. 다른 인덱스에 대한 액세스를 허용하는 추가 역할과 함께 Kibana에 액세스하는 모든 사용자 또는 백엔드 역할에 이를 매핑하는 것이 좋습니다.

클러스터 수준 보안

클러스터 수준 권한에는 다음과 같은 광범위한 요청을 수행하는 기능이 포함됩니다. _mget, _msearch, 그리고 _bulk, 상태 모니터링, 스냅샷 촬영 등. 역할을 생성할 때 Cluster Permissions(클러스터 권한) 탭을 사용하여 이러한 권한을 관리합니다. 클러스터 수준 작업 그룹의 목록은 Open Distro for Elasticsearch 설명서를 참조하십시오.

인덱스 수준 보안

인덱스 수준 권한에는 새 인덱스를 생성하고, 인덱스를 검색하고, 문서를 읽고 쓰고, 문서를 삭제하고, 별칭을 관리하는 것 등이 포함됩니다. 역할을 생성할 때 Index Permissions(인덱스 권한) 탭을 사용하여 이러한 권한을 관리합니다. 인덱스 수준 작업 그룹의 목록은 Open Distro for Elasticsearch 설명서를 참조하십시오.

문서 수준 보안

문서 수준 보안을 사용하면 인덱스 내에서 사용자가 볼 수 있는 문서를 제한할 수 있습니다. 역할을 생성할 때 인덱스 패턴과 Elasticsearch 쿼리를 지정합니다. 해당 역할에 매핑하는 모든 사용자는 쿼리와 일치하는 문서만 볼 수 있습니다. 문서 수준 보안은 검색할 때 반환되는 결과 수에 영향을 미칩니다.

자세한 내용은 Open Distro for Elasticsearch 설명서를 참조하십시오.

필드 수준 보안

필드 수준 보안을 사용하면 사용자가 볼 수 있는 문서 필드를 제어할 수 있습니다. 역할을 생성할 때 포함하거나 제외할 필드 목록을 추가합니다. 필드를 포함하면 해당 역할에 매핑되는 모든 사용자가 해당 필드만 볼 수 있습니다. 필드를 제외하면 제외된 필드 이외의 모든 필드를 볼 수 있습니다. 필드 수준 보안은 검색할 때 결과에 포함되는 필드 수에 영향을 미칩니다.

자세한 내용은 Open Distro for Elasticsearch 설명서를 참조하십시오.

필드 마스킹

필드 마스킹은 필드 수준 보안의 대안으로, 필드를 제거하는 대신 필드의 데이터를 익명화합니다. 역할을 생성할 때 마스킹할 필드 목록을 추가합니다. 필드 마스킹은 검색할 때 필드의 내용을 볼 수 있는지 여부에 영향을 미칩니다.

사용자 생성

내부 사용자 데이터베이스를 활성화한 경우 Kibana 또는 REST API의 _opendistro/_security 작업을 사용하여 사용자를 생성할 수 있습니다. 자세한 내용은 Open Distro for Elasticsearch 설명서를 참조하십시오.

마스터 사용자에 IAM을 선택한 경우 이 Kibana 부분은 무시하고 IAM 사용자 및 IAM 역할을 대신 생성합니다. 자세한 정보는 IAM 사용 설명서를 참조하십시오.

사용자에 역할 매핑

역할 매핑은 세분화된 액세스 제어의 가장 중요한 부분입니다. 세분화된 액세스 제어에는 시작하는 데 도움이 되는 몇 가지 미리 정의된 역할이 있지만, 사용자에게 역할을 매핑하지 않으면 클러스터에 대한 모든 요청이 권한 오류로 끝납니다.

백엔드 역할을 사용하면 또 다른 방법으로 역할을 사용자에게 매핑할 수 있습니다. 동일한 역할을 서로 다른 수십여 사용자에게 매핑하는 대신 역할을 단일 백엔드 역할에 매핑한 다음 모든 사용자가 해당 백엔드 역할을 갖도록 합니다. 백엔드 역할은 IAM 역할 또는 내부 사용자 데이터베이스에서 사용자를 생성할 때 지정하는 임의의 문자열일 수 있습니다.

  • Users(사용자) 섹션에서 사용자, IAM 사용자 ARN 및 Amazon Cognito 사용자 문자열을 지정합니다. Cognito 사용자 문자열은 Cognito/user-pool-id/username 형식을 사용합니다.

  • Backend roles(백엔드 역할) 섹션에서 백엔드 역할 및 IAM 역할 ARN을 지정합니다.


          역할 매핑 페이지

Kibana 또는 REST API의 _opendistro/_security 작업을 사용하여 사용자에게 역할을 매핑할 수 있습니다. 자세한 내용은 Open Distro for Elasticsearch 설명서를 참조하십시오.

작업 그룹 생성

작업 그룹은 여러 리소스에서 재사용할 수 있는 권한 세트입니다. 대부분의 사용 사례에서 기본 작업 그룹으로 충분하지만 Kibana 또는 REST API의 _opendistro/_security 작업을 사용하여 새 작업 그룹을 생성할 수 있습니다. 기본 작업 그룹에 대한 자세한 내용은 Open Distro for Elasticsearch 설명서를 참조하십시오.

Kibana 멀티테넌시

테넌트는 인덱스 패턴, 시각화, 대시보드 및 기타 Kibana 객체를 저장하는 공간입니다. Kibana 멀티테넌시를 사용하면 작업을 다른 Kibana 사용자와 안전하게 공유하거나 프라이빗 상태로 유지할 수 있습니다. 테넌트에 액세스할 수 있는 역할과 해당 역할에 읽기 또는 쓰기 액세스 권한이 있는지 여부를 제어할 수 있습니다. 자세한 내용은 Open Distro for Elasticsearch 설명서를 참조하십시오.

현재 테넌트를 보거나 테넌트를 변경하려면

  1. Kibana로 이동하여 로그인합니다.

  2. Tenants(테넌트)를 선택합니다.

  3. 시각화 또는 대시보드를 생성하기 전에 테넌트를 확인합니다. 다른 모든 Kibana 사용자와 작업을 공유하려면 Global(글로벌)을 선택합니다. 일부 Kibana 사용자와 작업을 공유하려면 다른 공유 테넌트를 선택합니다. 그렇지 않으면 Private(프라이빗)을 선택합니다.

권장 구성

Amazon은 세분화된 액세스 제어가 다른 보안 기능과 상호 작용하는 방식을 고려하여 대부분의 사용 사례에서 원활하게 작동하는 세분화된 액세스 제어 구성 몇 가지를 권장합니다.

설명 마스터 사용자 Kibana에 대한 Amazon Cognito 인증 도메인 액세스 정책
Elasticsearch API 호출에 IAM 자격 증명 또는 기본 인증을 사용하고, Kibana에 액세스하는 데 기본 인증을 사용합니다. Kibana 또는 REST API를 사용하여 세분화된 액세스 제어 역할을 관리합니다. 사용자 이름 및 암호 Disabled
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }
Elasticsearch API 호출에 IAM 자격 증명을 사용하고, Kibana에 액세스하는 데 Amazon Cognito를 사용합니다. Kibana 또는 REST API를 사용하여 세분화된 액세스 제어 역할을 관리합니다. IAM 사용자 또는 역할 Enabled
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }
Elasticsearch API 호출에 IAM 자격 증명을 사용하고, Kibana에 대한 대부분의 액세스를 차단합니다. REST API를 사용하여 세분화된 액세스 제어 역할을 관리합니다. IAM 사용자 또는 역할 Disabled
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" }, { "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/_plugin/kibana*" } ] }

자습서 IAM 마스터 사용자 및 Amazon Cognito

이 자습서에서는 Kibana에 Amazon Cognito 인증을 사용하는 IAM 마스터 사용자라는 일반적인 사용 사례를 다룹니다. 이러한 단계는 Amazon Cognito 사용자 풀을 인증에 사용하지만, 동일한 기본 프로세스가 모든 Cognito 인증 공급자에 대해 작동하므로 다양한 사용자(예: SAML)에게 다양한 IAM 역할을 할당할 수 있습니다.

참고

이 자습서에서는 마스터 사용자용 하나와 보다 제한된 사용자용 하나의 두 기존 IAM 역할이 있다고 가정합니다. 두 역할이 없는 경우 역할을 생성하십시오.

세분화된 액세스 제어를 시작하려면

  1. 다음 설정을 사용하여 도메인을 생성합니다.

    • Elasticsearch 7.7

    • 퍼블릭 액세스

    • 마스터 사용자로 IAM 역할(이 자습서의 나머지 부분에서는 IAMMasterUserRole로 지칭)을 사용하여 세분화된 액세스 제어 활성화

    • Kibana에 대한 Amazon Cognito 인증 활성화

    • 다음과 같은 액세스 정책:

      { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "*" ] }, "Action": [ "es:ESHttp*" ], "Resource": "arn:aws:es:region:account:domain/domain-name/*" } ] }
    • 도메인에 대한 모든 트래픽에 HTTPS 필요

    • 노드 간 암호화

    • 유휴 데이터 암호화

  2. IAM 콘솔로 이동하여 Roles(역할)를 선택합니다.

  3. IAMMasterUserRole을 선택한 다음 Trust relationships(신뢰 관계) 탭을 선택합니다.

  4. Edit trust relationship(신뢰 관계 편집)을 선택하고 Amazon Cognito 자격 증명 풀이 역할을 수임할 수 있는지 확인합니다. 다음과 같은 문이 표시되어야 합니다.

    { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Federated": "cognito-identity.amazonaws.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "cognito-identity.amazonaws.com:aud": "identity-pool-id" }, "ForAnyValue:StringLike": { "cognito-identity.amazonaws.com:amr": "authenticated" } } }] }
  5. [Update Trust Policy(신뢰 정책 업데이트)]를 선택합니다.

  6. 두 번째 IAM 역할(이 자습서의 나머지 부분에서 IAMLimitedUserRole로 지칭)에 동일한 신뢰 정책을 추가합니다.

  7. Amazon Cognito 콘솔로 이동하여, Manage User Pools(사용자 풀 관리)를 선택합니다.

  8. 사용자 풀을 선택한 다음 사용자 및 그룹을 선택합니다.

  9. 사용자 생성을 선택하고 master-user의 사용자 이름과 암호를 지정한 다음 사용자 생성을 선택합니다.

  10. limited-user라는 다른 사용자를 생성합니다.

  11. 그룹 탭을 선택한 다음 그룹 생성을 선택합니다.

  12. 그룹의 이름을 master-user-group으로 지정하고 IAM 역할 드롭다운 목록에서 IAMMasterUserRole을 선택한 다음 그룹 생성을 선택합니다.

  13. IAMLimitedUserRole을 사용하는 다른 그룹 limited-user-group을 생성합니다.

  14. master-user-group을 선택하고 사용자 추가를 선택한 다음 master-user를 추가합니다.

  15. limited-user-group을 선택하고 사용자 추가를 선택한 다음 limited-user를 추가합니다.

  16. 앱 클라이언트 설정을 선택하고 도메인의 앱 클라이언트 ID를 기록해 둡니다.

  17. 연동 자격 증명을 선택하고 자격 증명 풀을 선택한 다음 자격 증명 풀 편집을 선택합니다.

  18. 인증 공급자를 확장하고 도메인의 사용자 풀 ID와 앱 클라이언트 ID를 찾은 다음 기본 역할 사용토큰으로부터 역할 선택으로 변경합니다.

  19. 역할 해결에서 거부를 선택합니다. 이 설정을 사용하면 사용자가 인증 후 IAM 역할을 할당받기 위해 그룹에 속해야 합니다.

  20. 변경 사항 저장을 선택합니다.

  21. Kibana로 이동합니다.

  22. master-user로 로그인합니다.

  23. Try our sample data(샘플 데이터 사용해보기)를 선택합니다.

  24. 샘플 비행 데이터를 추가합니다.

  25. Security(보안), Roles(역할), Add a new role(새 역할 추가)을 선택합니다.

  26. 역할의 이름을 new-role로 지정하고 Index Permissions(인덱스 권한)를 선택합니다.

  27. Add index permissions(인덱스 권한 추가)를 선택한 다음 인덱스 패턴에 kibana_sample_data_fli*를 지정합니다.

  28. Add Action(작업 추가), read(읽기)를 선택합니다.

  29. Document Level Security Query(문서 수준 보안 쿼리)에 다음 쿼리를 지정합니다.

    { "match": { "FlightDelay": true } }

    그런 다음 Test DLS query syntax(DLS 쿼리 구문 테스트)를 선택합니다.

  30. Include or exclude fields(필드 포함 또는 제외)에서 Exclude fields(필드 제외)를 선택한 다음 Add Field(필드 추가)를 선택합니다. FlightNum를 지정합니다.

  31. Anonymize fields(필드 익명화)에서 Add Field(필드 추가)를 선택합니다. Dest를 지정합니다.

  32. Save Role Definition(역할 정의 저장)을 선택합니다.

  33. Back(뒤로), Role Mappings(역할 매핑), Add a new role(새 역할 매핑 추가)을 선택합니다.

  34. Role(역할)에서 new-role을 선택합니다. 선택 백엔드 역할 추가, 그리고 ARN을 IAMLimitedUserRole. 그런 다음 선택 제출.

  35. Add a new role mapping(새 역할 매핑 추가)를 다시 선택합니다.

  36. Role(역할)에서 kibana_user를 선택합니다. 선택 백엔드 역할 추가, 그리고 ARN을 IAMLimitedUserRole. 그런 다음 선택 제출.

  37. 새 프라이빗 브라우저 창에서 Kibana로 이동하고 limited-user를 사용하여 로그인한 다음 Explore on my own(직접 탐색)을 선택합니다.

  38. Dev Tools(개발 도구)를 선택한 다음 기본 검색을 실행합니다.

    GET _search { "query": { "match_all": {} } }

    권한 오류에 주의하십시오. limited-user 클러스터 전체 검색을 실행할 권한이 없습니다.

  39. 또 다른 검색을 실행합니다.

    GET kibana_sample_data_flights/_search { "query": { "match_all": {} } }

    일치하는 모든 문서에 true 값을 갖는 FlightDelay 필드와 익명화된 Dest 필드가 있으며 FlightNum 필드는 없는 것을 확인할 수 있습니다.

  40. master-user로 로그인한 원래 브라우저 창에서 Dev Tools(개발 도구)를 선택한 다음 동일한 검색을 수행합니다. 권한, 결과 수, 일치하는 문서 및 포함된 필드의 차이를 확인합니다.

자습서 내부 사용자 데이터베이스 및 HTTP 기본 인증

이 자습서에서는 내부 사용자 데이터베이스의 마스터 사용자와 Kibana에 대한 HTTP 기본 인증이라는 또 다른 일반적인 사용 사례를 다룹니다.

세분화된 액세스 제어를 시작하려면

  1. 다음 설정을 사용하여 도메인을 생성합니다.

    • Elasticsearch 7.7

    • 퍼블릭 액세스

    • 내부 사용자 데이터베이스의 마스터 사용자(이 자습서의 나머지 부분에서 TheMasterUser로 지칭)와 세분화된 액세스 제어

    • Kibana에 대한 Amazon Cognito 인증 비활성화

    • 다음과 같은 액세스 정책:

      { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "*" ] }, "Action": [ "es:ESHttp*" ], "Resource": "arn:aws:es:region:account:domain/domain-name/*" } ] }
    • 도메인에 대한 모든 트래픽에 HTTPS 필요

    • 노드 간 암호화

    • 유휴 데이터 암호화

  2. Kibana로 이동합니다.

  3. TheMasterUser를 사용하여 로그인합니다.

  4. Try our sample data(샘플 데이터 사용해보기)를 선택합니다.

  5. 샘플 비행 데이터를 추가합니다.

  6. Security(보안), Internal User Database(내부 사용자 데이터베이스), Add a new internal user(새 내부 사용자 추가)를 선택합니다.

  7. 사용자 이름 지정 new-user암호를 지정하고 사용자에게 백엔드 역할을 new-backend-role. 그런 다음 선택 제출.

  8. Back(뒤로), Roles(역할), Add a new role(새 역할 추가)을 선택합니다.

  9. 역할의 이름을 new-role로 지정하고 Index Permissions(인덱스 권한)를 선택합니다.

  10. Add index permissions(인덱스 권한 추가)를 선택한 다음 인덱스 패턴에 kibana_sample_data_fli*를 지정합니다.

  11. Add Action Group(작업 그룹 추가), read(읽기)를 선택합니다.

  12. Document Level Security Query(문서 수준 보안 쿼리)에 다음 쿼리를 지정합니다.

    { "match": { "FlightDelay": true } }

    그런 다음 Test DLS query syntax(DLS 쿼리 구문 테스트)를 선택합니다.

  13. Include or exclude fields(필드 포함 또는 제외)에서 Exclude fields(필드 제외)를 선택한 다음 Add Field(필드 추가)를 선택합니다. FlightNum를 지정합니다.

  14. Anonymize fields(필드 익명화)에서 Add Field(필드 추가)를 선택합니다. Dest를 지정합니다.

  15. Save Role Definition(역할 정의 저장)을 선택합니다.

  16. Back(뒤로), Role Mappings(역할 매핑), Add a new role(새 역할 매핑 추가)을 선택합니다.

  17. Role(역할)에서 new-role을 선택합니다. 선택 백엔드 역할 추가을(를) 지정합니다. new-backend-role. 그런 다음 선택 제출.

  18. Add a new role mapping(새 역할 매핑 추가)를 다시 선택합니다.

  19. 대상 역할, 선택 kibana_user. 선택 사용자 추가new-user. 그런 다음 선택 제출.

    new-userkibana_user 역할을 갖는데, new-backend-role 백엔드 역할이 있는 모든 사용자는 new-role 역할을 갖습니다.

  20. 새 프라이빗 브라우저 창에서 Kibana로 이동하고 new-user를 사용하여 로그인한 다음 Explore on my own(직접 탐색)을 선택합니다.

  21. Dev Tools(개발 도구)를 선택한 다음 기본 검색을 실행합니다.

    GET _search { "query": { "match_all": {} } }

    권한 오류에 주의하십시오. new-user 클러스터 전체 검색을 실행할 권한이 없습니다.

  22. 또 다른 검색을 실행합니다.

    GET kibana_sample_data_flights/_search { "query": { "match_all": {} } }

    일치하는 모든 문서에 true 값을 갖는 FlightDelay 필드와 익명화된 Dest 필드가 있으며 FlightNum 필드는 없는 것을 확인할 수 있습니다.

  23. TheMasterUser로 로그인한 원래 브라우저 창에서 Dev Tools(개발 도구)를 선택한 다음 동일한 검색을 수행합니다. 권한, 결과 수, 일치하는 문서 및 포함된 필드의 차이를 확인합니다.

Limitations

세분화된 액세스 제어에는 몇 가지 중요한 제한 사항이 있습니다.

  • 역할을 호스트 이름 또는 IP 주소에 매핑하는 hosts 측면의 역할 매핑은 도메인이 VPC 내에 있는 경우 작동하지 않습니다. 사용자 및 백엔드 역할에는 여전히 역할을 매핑할 수 있습니다.

  • 내부 사용자 데이터베이스의 사용자는 자신의 암호를 변경할 수 없습니다. 마스터 사용자(또는 동등한 권한을 가진 사용자)가 이들을 대신해 암호를 변경해야 합니다.

  • 마스터 사용자에 IAM을 선택하고 Amazon Cognito 인증을 활성화하지 않으면 Kibana에 작동하지 않는 로그인 페이지가 표시됩니다.

  • 마스터 사용자에 IAM을 선택하는 경우에도 내부 사용자 데이터베이스에 사용자를 생성할 수 있습니다. 그러나 이 구성에서는 HTTP 기본 인증이 활성화되지 않으므로 이러한 사용자 자격 증명으로 서명된 모든 요청이 거부됩니다.

  • SQL을 사용하여 액세스 권한이 없는 인덱스를 쿼리하는 경우 “no permissions(권한 없음)” 오류가 발생합니다. 인덱스가 없으면 “no such index(해당 인덱스 없음)” 오류가 발생합니다. 오류 메시지의 이러한 차이는 이름을 추측할 경우 인덱스의 존재를 확인할 수 있음을 의미합니다.

    문제를 최소화하려면 인덱스 이름에 민감한 정보를 포함하지 마십시오. SQL에 대한 모든 액세스를 거부하려면 도메인 액세스 정책에 다음 요소를 추가합니다.

    { "Effect": "Deny", "Principal": { "AWS": [ "*" ] }, "Action": [ "es:*" ], "Resource": "arn:aws:es:us-east-1:123456789012:domain/my-domain/_opendistro/_sql" }

마스터 사용자 수정

마스터 사용자의 세부 정보를 잊어버린 경우 콘솔, AWS CLI 또는 구성 API를 사용하여 다시 구성할 수 있습니다.

마스터 사용자를 수정하려면(콘솔)

  1. https://aws.amazon.com으로 이동하여 Sign In to the Console(콘솔에 로그인)을 선택합니다.

  2. Analytics에서 Elasticsearch 서비스를 선택합니다.

  3. 도메인을 선택합니다.

  4. Actions(작업), Modify master user(마스터 사용자 수정)를 선택합니다.

  5. Set IAM role as master user(IAM 역할을 마스터 사용자로 설정) 또는 Create new master user(새 마스터 사용자 생성)를 선택합니다.

    • 이전에 IAM 마스터 사용자를 사용한 경우 세분화된 액세스 제어가 all_access 역할을 지정한 새 IAM ARN에 다시 매핑합니다.

    • 이전에 내부 사용자 데이터베이스를 사용한 경우 세분화된 액세스 제어가 새 마스터 사용자를 생성합니다. 새 마스터 사용자를 사용하여 이전 마스터 사용자를 삭제할 수 있습니다.

  6. 제출을 선택합니다.

추가 마스터 사용자

도메인을 생성할 때 마스터 사용자를 지정하지만 원하는 경우 이 마스터 사용자를 사용하여 추가 마스터 사용자를 생성할 수 있습니다. 여기에는 두 가지 옵션이 있습니다. Kibana 또는 REST API.

  • Kibana를 사용하는 경우 Security(보안), Role Mappings(역할 매핑)를 선택한 다음 새 마스터 사용자를 all_accesssecurity_manager 역할에 매핑합니다.

    
            역할 매핑 페이지
  • REST API를 사용하려면 다음 요청을 보냅니다.

    PUT _opendistro/_security/api/rolesmapping/all_access { "backend_roles": [ "arn:aws:iam::123456789012:role/fourth-master-user" ], "hosts": [], "users": [ "master-user", "second-master-user", "arn:aws:iam::123456789012:user/third-master-user" ] }
    PUT _opendistro/_security/api/rolesmapping/security_manager { "backend_roles": [ "arn:aws:iam::123456789012:role/fourth-master-user" ], "hosts": [], "users": [ "master-user", "second-master-user", "arn:aws:iam::123456789012:user/third-master-user" ] }

    이러한 요청은 현재 역할 매핑을 대체하므로 PUT 요청에 현재 역할을 모두 포함할 수 있도록 GET 요청을 먼저 수행합니다. REST API는 Kibana에 액세스할 수 없고 IAM 역할을 Amazon Cognito에서 all_access 역할로 매핑하려는 경우에 특히 유용합니다.

수동 스냅샷

세분화된 액세스 제어를 사용하면 수동 스냅샷을 생성하는 데 따른 복잡성이 가중됩니다. 다른 모든 용도로 HTTP 기본 인증을 사용하는 경우에도 스냅샷 리포지토리를 등록하려면 수동 스냅샷 필수 조건에 정의된 대로 TheSnapshotRole을 수임할 iam:PassRole 권한이 있는 IAM 역할에 manage_snapshots 역할을 매핑해야 합니다.

그런 다음 수동 스냅샷 리포지토리 등록에 설명된 대로 해당 IAM 역할을 사용하여 서명된 요청을 도메인으로 보냅니다.

Integrations

Amazon ES와 함께 다른 AWS 서비스를 사용하는 경우 해당 서비스를 위한 IAM 역할에 적절한 권한을 제공해야 합니다. 예를 들어, Kinesis Data Firehose 전달 스트림은 종종 IAM 역할을 사용합니다. firehose_delivery_role. 키바나 정교한 액세스 제어를 위한 역할 생성, 그리고 IAM 역할을 매핑합니다.. 이 경우 새 역할에는 다음 권한이 필요합니다.

{ "cluster_permissions": [ "cluster_composite_ops", "cluster_monitor" ], "index_permissions": [{ "index_patterns": [ "firehose-index*" ], "allowed_actions": [ "create_index", "manage", "crud" ] }] }

권한은 각 서비스가 수행하는 작업에 따라 다릅니다. 데이터를 인덱싱하는 AWS IoT 규칙 또는 AWS Lambda 함수에는 Kinesis Data Firehose와 비슷한 권한이 필요할 수 있지만 검색만 수행하는 Lambda 함수는 보다 제한된 권한을 사용할 수 있습니다.

REST API 차이점

세분화된 액세스 제어 REST API는 Elasticsearch 버전에 따라 약간 차이가 있습니다. PUT 요청을 수행하기 전에 GET 요청을 수행하여 예상 요청 본문을 확인합니다. 예를 들어, _opendistro/_security/api/user에 대한 GET 요청은 모든 사용자를 반환하며, 이를 수정하여 유효한 PUT 요청을 생성하는 데 사용할 수 있습니다.

Elasticsearch 6.x에서 사용자를 생성하는 요청은 다음과 같습니다.

PUT _opendistro/_security/api/user/new-user { "password": "some-password", "roles": ["new-backend-role"] }

Elasticsearch 7.x에서 요청은 다음과 같습니다.

PUT _opendistro/_security/api/user/new-user { "password": "some-password", "backend_roles": ["new-backend-role"] }

Elasticsearch 6.x에서 테넌트는 역할의 속성입니다.

GET _opendistro/_security/api/roles/all_access { "all_access": { "cluster": ["UNLIMITED"], "tenants": { "admin_tenant": "RW" }, "indices": { "*": { "*": ["UNLIMITED"] } }, "readonly": "true" } }

Elasticsearch 7.x에서는 테넌트가 자체 URI를 가진 객체입니다.

GET _opendistro/_security/api/tenants { "global_tenant": { "reserved": true, "hidden": false, "description": "Global tenant", "static": false } }

7.x REST API 관련 문서는 Open Distro for Elasticsearch 설명서를 참조하십시오.

작은 정보

내부 사용자 데이터베이스를 사용하는 경우 curl을 사용하여 요청을 수행하고 도메인을 테스트할 수 있습니다. 다음 샘플 명령을 시도해 보십시오.

curl -XGET -u master-user:master-user-password 'domain-endpoint/_search' curl -XGET -u master-user:master-user-password 'domain-endpoint/_opendistro/_security/api/user'