더 큰 그림: 세분화된 액세스 제어 및 서비스 보안 OpenSearch 주요 개념 마스터 사용자 정보 세분화된 액세스 제어 활성화 마스터 사용자로 대시보드에 액세스 OpenSearch 권한 관리 권장 구성 제한 사항 마스터 사용자 수정 추가 마스터 사용자 수동 스냅샷 수 통합 REST API 차이점

Amazon 서비스의 세밀한 액세스 제어 OpenSearch

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

세분화된 액세스 제어는 다음과 같은 이점을 제공합니다.

역할 기반 액세스 제어
인덱스, 문서 및 필드 수준의 보안
OpenSearch 대시보드 멀티테넌시
및 대시보드를 위한 HTTP 기본 인증 OpenSearch OpenSearch

주제

더 큰 그림: 세분화된 액세스 제어 및 서비스 보안 OpenSearch
주요 개념
마스터 사용자 정보
세분화된 액세스 제어 활성화
마스터 사용자로 대시보드에 액세스 OpenSearch
권한 관리
권장 구성
제한 사항
마스터 사용자 수정
추가 마스터 사용자
수동 스냅샷 수
통합
REST API 차이점
자습서: IAM 마스터 사용자 및 Amazon Cognito 인증을 사용하여 도메인 구성
자습서: 내부 사용자 데이터베이스와 HTTP 기본 인증을 사용하여 도메인 구성

더 큰 그림: 세분화된 액세스 제어 및 서비스 보안 OpenSearch

Amazon OpenSearch 서비스 보안에는 세 가지 기본 계층이 있습니다.

네트워크: 첫 번째 보안 계층은 요청이 OpenSearch 서비스 도메인에 도달하는지 여부를 결정하는 네트워크입니다. 도메인을 생성할 때 퍼블릭 액세스(Public access)를 선택하는 경우 인터넷에 연결된 클라이언트의 요청이 도메인 엔드포인트에 도달할 수 있습니다. VPC 액세스(VPC access)를 선택하는 경우 요청이 엔드포인트에 도달하려면 클라이언트를 VPC에 연결해야 합니다(연결된 보안 그룹에서 이를 허용해야 함). 자세한 내용은 VPC 내에서 아마존 OpenSearch 서비스 도메인 시작 섹션을 참조하세요.

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

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

참고

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

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

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

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

예

movies/_search?q=thor에 대한 GET 요청을 예로 들어 보겠습니다. 사용자가 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 역할과 구별됩니다. 역할에는 클러스터 전체, 인덱스별, 문서 수준, 필드 수준 등 다양한 권한 조합이 포함됩니다.
매핑 — 역할을 구성한 후 한 명 이상의 사용자에게 매핑합니다. 예를 들어, Dashboards에 대한 액세스 권한을 제공하는 역할, index1에 대한 읽기 전용 액세스 권한을 제공하는 역할, index2에 대한 쓰기 액세스 권한을 제공하는 역할이라는 3가지 역할을 단일 사용자에게 매핑할 수 있습니다. 또는 이러한 모든 권한을 단일 역할에 포함할 수 있습니다.
사용자 - OpenSearch 클러스터에 요청을 보내는 사람 또는 애플리케이션. 사용자에게는 요청할 때 지정하는 보안 인증 정보(IAM 액세스 키 또는 사용자 이름과 암호)가 있습니다.

마스터 사용자 정보

OpenSearch 서비스의 마스터 사용자는 사용자 이름과 암호 조합이거나 기본 OpenSearch 클러스터에 대한 전체 권한을 가진 IAM 보안 주체입니다. 대시보드 내에서 내부 사용자, 역할 및 역할 매핑을 생성할 수 있는 권한과 함께 OpenSearch 클러스터에 대한 모든 액세스 권한을 가진 사용자는 마스터 사용자로 간주됩니다. OpenSearch

OpenSearch 서비스 콘솔이나 CLI를 통해 생성된 마스터 사용자는 사전 정의된 두 역할에 자동으로 매핑됩니다.

all_access— 모든 클러스터 전체 작업에 대한 전체 액세스 권한, 모든 클러스터 인덱스에 대한 쓰기 권한 및 모든 테넌트에 대한 쓰기 권한을 제공합니다.
security_manager— 보안 플러그인에 대한 액세스와 사용자 및 권한 관리를 제공합니다.

이 두 역할을 통해 사용자는 OpenSearch 대시보드의 보안 탭에 액세스하여 사용자와 권한을 관리할 수 있습니다. 다른 내부 사용자를 만들고 이 사용자를 all_access 역할에만 매핑하는 경우 사용자는 보안 탭에 액세스할 수 없습니다. 마스터 사용자를 all_access 및 security_manager 역할 모두에 명시적으로 매핑하여 추가 마스터 사용자를 생성할 수 있습니다. 지침은 추가 마스터 사용자 섹션을 참조하십시오.

도메인의 마스터 사용자를 생성할 때 기존 IAM 보안 주체를 지정하거나 내부 사용자 데이터베이스 내에 마스터 사용자를 생성할 수 있습니다. 어느 것을 사용할지 결정할 때는 다음 사항을 고려하십시오.

IAM 보안 주체 - 마스터 사용자의 IAM 보안 주체를 선택하는 경우 클러스터에 대한 모든 요청은 AWS 서명 버전 4를 사용하여 서명되어야 합니다.

OpenSearch 서비스에서는 IAM 보안 주체의 권한을 전혀 고려하지 않습니다. IAM 사용자 또는 역할은 인증 용도로만 사용됩니다. 해당 사용자 또는 역할에 대한 정책은 마스터 사용자의 권한 부여와 관련이 없습니다. 권한 부여는 OpenSearch 보안 플러그인의 다양한 권한을 통해 처리됩니다.

예를 들어, IAM 보안 주체에게 0개의 IAM 권한을 할당하고 해당 사용자 또는 역할을 인증할 수 있는 한 해당 컴퓨터 또는 사용자는 Service의 마스터 사용자 권한을 가집니다. OpenSearch

여러 클러스터에서 동일한 사용자를 사용하거나, Amazon Cognito를 사용하여 대시보드에 액세스하려는 경우 또는 서명 버전 4 서명을 지원하는 클라이언트가 OpenSearch 있는 경우 IAM을 사용하는 것이 좋습니다.
내부 사용자 데이터베이스 — 사용자 이름과 암호 조합으로 내부 사용자 데이터베이스에 마스터를 생성하면 HTTP 기본 인증 (IAM 자격 증명 포함) 을 사용하여 클러스터에 요청을 보낼 수 있습니다. 대부분의 클라이언트는 curl을 비롯한 기본 인증을 지원하며, 이 인증은 --aws-sigv4 옵션과 함께 AWS 서명 버전 4도 지원합니다. 내부 사용자 데이터베이스는 OpenSearch 인덱스에 저장되므로 다른 클러스터와 공유할 수 없습니다.

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

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

콘솔 또는 구성 API를 사용하여 세밀한 액세스 제어를 가능하게 하세요. AWS CLI단계는 아마존 OpenSearch 서비스 도메인 생성 및 관리를 참조하세요.

Elasticsearch 6.7 이상에서는 세분화된 액세스 제어가 필요합니다 OpenSearch . 또한 도메인으로 향하는 모든 트래픽에 대해 HTTPS가 필요하고, 저장된 데이터의 암호화 및 암호화가 필요합니다. node-to-node 세분화된 액세스 제어의 고급 기능을 구성하는 방법에 따라 요청을 추가로 처리하려면 개별 데이터 노드의 컴퓨팅 및 메모리 리소스가 필요할 수 있습니다. 세분화된 액세스 제어를 활성화한 후에는 비활성화할 수 없습니다.

기존 도메인에서의 세분화된 액세스 제어 사용 설정

Elasticsearch 6.7 OpenSearch 이상을 실행하는 기존 도메인에 대해 세밀한 액세스 제어를 활성화할 수 있습니다.

기존 도메인(콘솔)에서 세분화된 액세스 제어 사용 설정

도메인을 선택하고 작업(Actions), 보안 구성 편집(Edit security configuration)을 선택합니다.
세분화된 액세스 제어 사용 설정(Enable fine-grained access control)을 선택합니다.
마스터 사용자를 생성하는 방법을 선택합니다.
- 사용자 관리에 IAM을 사용하려면 IAM ARN을 마스터 사용자로 설정(Set IAM ARN as master user)을 선택하고 IAM 역할의 ARN을 지정합니다.
- 내부 사용자 데이터베이스를 사용하려면 [기본 사용자 생성]을 선택하고 사용자 이름과 암호를 지정합니다.
(선택 사항) Open/IP 기반 액세스 정책에 대한 마이그레이션 기간 사용 설정(Enable migration period for open/IP-based access policy)을 선택합니다. 이 설정을 사용하면 기존 사용자가 중단 없이 도메인에 계속 액세스할 수 있는 30일의 전환 기간을 사용할 수 있으며, 기존의 개방형 및 IP 기반 액세스 정책이 도메인에서 계속 사용됩니다. 이 마이그레이션 기간 동안 관리자는 도메인에 대해 필요한 역할을 생성하고 사용자에게 매핑하는 것이 좋습니다. 개방형 또는 IP 기반 액세스 정책 대신 자격 증명 기반 정책을 사용하는 경우 이 설정을 사용 중지할 수 있습니다.

또한 마이그레이션 기간 동안 세분화된 액세스 제어 기능을 사용할 수 있도록 클라이언트를 업데이트해야 합니다. 예를 들어 IAM 역할을 세분화된 액세스 제어와 매핑하는 경우 서명 버전 4로 요청에 서명하기 시작하도록 클라이언트를 업데이트해야 합니다. AWS 세분화된 액세스 제어를 사용하여 HTTP 기본 인증을 구성하는 경우 요청에서 적절한 기본 인증 자격 증명을 제공하도록 클라이언트를 업데이트해야 합니다.

마이그레이션 기간 동안 도메인의 OpenSearch 대시보드 엔드포인트에 액세스하는 사용자는 로그인 페이지가 아닌 디스커버 페이지로 바로 이동합니다. 관리자 및 마스터 사용자는 로그인을 선택하여 관리자 자격 증명으로 로그인하고 역할 매핑을 구성할 수 있습니다.

중요
OpenSearch 서비스는 30일이 지나면 마이그레이션 기간을 자동으로 비활성화합니다. 필요한 역할을 만들고 사용자에게 매핑하는 즉시 종료하는 것이 좋습니다. 마이그레이션 기간이 끝난 후에는 다시 사용 설정할 수 없습니다.
변경 사항 저장를 선택합니다.

변경 사항은 클러스터 상태가 빨간색으로 바뀐 동안 블루/그린 배포를 트리거하지만, 모든 클러스터 작업은 영향을 받지 않습니다.

기존 도메인(CLI) 에 대한 세분화된 액세스 제어 사용 설정

AnonymousAuthEnabled를 true로 설정하여 세분화된 액세스 제어를 통해 마이그레이션 기간을 사용 설정합니다.


aws opensearch update-domain-config --domain-name test-domain --region us-east-1 \
      --advanced-security-options '{ "Enabled": true, "InternalUserDatabaseEnabled":true, "MasterUserOptions": {"MasterUserName":"master-username","MasterUserPassword":"master-password"},"AnonymousAuthEnabled": true}'

default_role 정보

세분화된 액세스 제어에는 역할 매핑이 필요합니다. 도메인에서 ID 기반 액세스 정책을 사용하는 경우 OpenSearch 서비스는 기존 사용자를 적절하게 마이그레이션할 수 있도록 사용자를 default_role이라는 새 역할에 자동으로 매핑합니다. 이 임시 매핑을 사용하면 사용자가 고유한 역할 매핑을 생성할 때까지 IAM 서명이 된 GET 및 PUT 요청을 성공적으로 보낼 수 있습니다.

이 역할은 서비스 도메인에 보안 취약성이나 결함을 추가하지 않습니다. OpenSearch 자신의 역할을 설정하고 적절히 매핑하는 즉시 기본 역할을 삭제하는 것이 좋습니다.

마이그레이션 시나리오

다음 표에서는 기존 도메인에 대한 세분화된 액세스 제어를 사용 설정하기 전후의 각 인증 방법에 대한 동작과 관리자가 사용자를 역할에 올바르게 매핑하기 위해 수행해야 하는 단계에 대해 설명합니다.

인증 방법	세분화된 액세스 제어 사용 설정 전	세분화된 액세스 제어 사용 설정 후	관리자 작업
보안 인증 기반 정책	IAM 정책을 충족하는 모든 I사용자가 도메인에 액세스할 수 있습니다.	마이그레이션 기간을 사용 설정할 필요는 없습니다. OpenSearch 서비스는 IAM 정책을 충족하는 모든 사용자를 default_role에 자동으로 매핑하여 사용자가 도메인에 계속 액세스할 수 있도록 합니다.	도메인에서 사용자 지정 역할 매핑을 생성합니다. default_role을 삭제합니다.
IP 기반 정책	허용된 IP 주소 또는 CIDR 블록의 모든 사용자가 도메인에 액세스할 수 있습니다.	30일의 마이그레이션 기간 동안 허용된 IP 주소 또는 CIDR 블록의 모든 사용자가 도메인에 계속 액세스할 수 있습니다.	도메인에서 사용자 지정 역할 매핑을 생성합니다. 역할 매핑 구성에 따라 기본 인증 자격 증명 또는 IAM 자격 증명을 제공하도록 클라이언트를 업데이트합니다. 마이그레이션 기간을 사용 중지합니다. 허용된 IP 주소 또는 CIDR 블록의 사용자가 기본 인증 또는 IAM 자격 증명 없이 요청을 보내면 도메인에 대한 액세스 권한을 잃게 됩니다.
개방형 액세스 정책	인터넷을 통해 모든 사용자가 도메인에 액세스할 수 있습니다.	30일의 마이그레이션 기간 동안 인터넷을 통해 모든 사용자가 도메인에 계속 액세스할 수 있습니다.	도메인에서 역할 매핑을 생성합니다. 역할 매핑 구성에 따라 기본 인증 자격 증명 또는 IAM 자격 증명을 제공하도록 클라이언트를 업데이트합니다. 마이그레이션 기간을 사용 중지합니다. 기본 인증 또는 IAM 자격 증명 없이 요청을 보내는 사용자는 도메인에 대한 액세스 권한을 잃게 됩니다.

인증 방법

세분화된 액세스 제어 사용 설정 전

세분화된 액세스 제어 사용 설정 후

관리자 작업

보안 인증 기반 정책

IAM 정책을 충족하는 모든 I사용자가 도메인에 액세스할 수 있습니다.

마이그레이션 기간을 사용 설정할 필요는 없습니다.

OpenSearch 서비스는 IAM 정책을 충족하는 모든 사용자를 default_role에 자동으로 매핑하여 사용자가 도메인에 계속 액세스할 수 있도록 합니다.

도메인에서 사용자 지정 역할 매핑을 생성합니다.
default_role을 삭제합니다.

IP 기반 정책

허용된 IP 주소 또는 CIDR 블록의 모든 사용자가 도메인에 액세스할 수 있습니다.

30일의 마이그레이션 기간 동안 허용된 IP 주소 또는 CIDR 블록의 모든 사용자가 도메인에 계속 액세스할 수 있습니다.

도메인에서 사용자 지정 역할 매핑을 생성합니다.
역할 매핑 구성에 따라 기본 인증 자격 증명 또는 IAM 자격 증명을 제공하도록 클라이언트를 업데이트합니다.
마이그레이션 기간을 사용 중지합니다. 허용된 IP 주소 또는 CIDR 블록의 사용자가 기본 인증 또는 IAM 자격 증명 없이 요청을 보내면 도메인에 대한 액세스 권한을 잃게 됩니다.

개방형 액세스 정책

인터넷을 통해 모든 사용자가 도메인에 액세스할 수 있습니다.

30일의 마이그레이션 기간 동안 인터넷을 통해 모든 사용자가 도메인에 계속 액세스할 수 있습니다.

도메인에서 역할 매핑을 생성합니다.
역할 매핑 구성에 따라 기본 인증 자격 증명 또는 IAM 자격 증명을 제공하도록 클라이언트를 업데이트합니다.
마이그레이션 기간을 사용 중지합니다. 기본 인증 또는 IAM 자격 증명 없이 요청을 보내는 사용자는 도메인에 대한 액세스 권한을 잃게 됩니다.

마스터 사용자로 대시보드에 액세스 OpenSearch

세분화된 액세스 제어에는 관리 작업을 간소화하는 OpenSearch 대시보드 플러그인이 있습니다. Dashboards를 사용하여 사용자, 역할, 매핑, 작업 그룹 및 테넌트를 관리할 수 있습니다. 하지만 OpenSearch 대시보드 로그인 페이지와 기본 인증 방법은 사용자를 관리하고 도메인을 구성하는 방법에 따라 달라집니다.

사용자 관리를 위해 IAM을 사용하려면 OpenSearch Dashboards에 대한 Amazon Cognito 인증 구성을 클릭하여 Dashboards에 액세스합니다. 그렇지 않으면 Dashboards에서 작동하지 않는 로그인 페이지가 표시됩니다. 제한 사항 섹션을 참조하세요.

Amazon Cognito 인증과 함께 자격 증명 풀의 수임된 역할 중 하나가 마스터 사용자에 지정한 IAM 역할과 일치해야 합니다. 이 구성에 대한 자세한 내용은 (선택 사항) 세분화된 액세스 구성 및 자습서: IAM 마스터 사용자 및 Amazon Cognito 인증을 사용하여 도메인 구성 섹션을 참조하세요.
내부 사용자 데이터베이스를 사용하도록 선택한 경우 마스터 사용자 이름과 암호를 사용하여 대시보드에 로그인할 수 있습니다. HTTPS를 통해 Dashboards에 액세스해야 합니다. Dashboards에 대한 Amazon Cognito 및 SAML 인증은 모두 이 로그인 화면을 대체합니다.

이 구성에 대한 자세한 내용은 자습서: 내부 사용자 데이터베이스와 HTTP 기본 인증을 사용하여 도메인 구성 섹션을 참조하세요.
SAML 인증을 사용하도록 선택한 경우 외부 자격 증명 공급자의 자격 증명을 사용하여 로그인할 수 있습니다. 자세한 내용은 대시보드의 SAML 인증 OpenSearch 섹션을 참조하세요.

권한 관리

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

참고

사용자에게 부여하기로 선택하는 권한은 사용 사례에 따라 크게 다릅니다. 모든 시나리오를 이 설명서에서 실행 가능할 만큼 다룰 수는 없습니다. 사용자에게 부여할 권한을 결정할 때는 다음 섹션에 언급된 OpenSearch 클러스터 및 인덱스 권한을 참조하고 항상 최소 권한 원칙을 준수해야 합니다.

역할 생성

OpenSearch 대시보드 또는 REST API의 _plugins/_security 작업을 사용하여 세분화된 액세스 제어를 위한 새 역할을 만들 수 있습니다. 자세한 정보는 역할 생성 섹션을 참조하세요.

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

Amazon OpenSearch 서비스는 다음과 같은 OpenSearch 역할을 제공하지 않습니다.

observability_full_access
observability_read_access
reports_read_access
reports_full_access

Amazon OpenSearch Service는 OpenSearch 다음과 함께 사용할 수 없는 여러 역할을 제공합니다.

ultrawarm_manager
ml_full_access
cold_manager
notifications_full_access
notifications_read_access

클러스터 수준 보안

클러스터 수준 권한에는 _mget, _msearch 및 _bulk와 같은 다양한 요청을 실행하고, 상태를 모니터링하고, 스냅샷을 생성하는 것 등이 포함됩니다. 역할을 생성할 때 클러스터 권한(Cluster Permissions) 섹션을 사용하여 이러한 권한을 관리합니다. 클러스터 수준 권한의 전체 목록은 클러스터 권한 섹션을 참조하세요.

개별 권한보다는 기본 작업 그룹을 조합하여 원하는 보안 태세를 유지할 수 있는 경우가 많습니다. 클러스터 수준 작업 그룹의 목록은 클러스터 수준 섹션을 참조하세요.

인덱스 수준 보안

인덱스 수준 권한에는 새 인덱스를 생성하고, 인덱스를 검색하고, 문서를 읽고 쓰고, 문서를 삭제하고, 별칭을 관리하는 것 등이 포함됩니다. 역할을 생성할 때 인덱스 권한(Index Permissions) 섹션을 사용하여 이러한 권한을 관리합니다. 인덱스 수준 권한의 전체 목록은 인덱스 권한 부여 섹션을 참조하세요.

개별 권한보다는 기본 작업 그룹을 조합하여 원하는 보안 태세를 유지할 수 있는 경우가 많습니다. 인덱스 수준 작업 그룹의 목록은 인덱스 수준 섹션을 참조하세요.

문서 수준 보안

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

자세한 내용은 문서 수준 보안 섹션을 참조하세요.

필드 수준 보안

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

자세한 내용은 필드 수준 보안 섹션을 참조하세요.

필드 마스킹

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

작은 정보

표준 마스킹을 필드에 적용하는 경우 OpenSearch Service는 안전한 임의 해시를 사용하므로 집계 결과가 부정확해질 수 있습니다. 마스킹 처리된 필드에서 집계를 수행하려면 패턴 기반 마스킹을 대신 사용합니다.

사용자 생성

내부 사용자 데이터베이스를 활성화한 경우 OpenSearch 대시보드 또는 REST API의 _plugins/_security 작업을 사용하여 사용자를 만들 수 있습니다. 자세한 내용은 사용자 생성 섹션을 참조하세요.

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

사용자에 역할 매핑

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

백엔드 역할은 역할 매핑 프로세스를 단순화하는 데 도움이 될 수 있습니다. 동일한 역할을 100명의 개별 사용자에게 매핑하는 대신 100명의 사용자 모두가 공유하는 단일 백엔드 역할에 역할을 매핑할 수 있습니다. 백엔드 역할은 IAM 역할 또는 임의 문자열일 수 있습니다.

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

OpenSearch 대시보드 또는 REST API의 _plugins/_security 작업을 사용하여 사용자에게 역할을 매핑할 수 있습니다. 자세한 내용은 사용자를 역할에 매핑 섹션을 참조하세요.

작업 그룹 생성

작업 그룹은 여러 리소스에서 재사용할 수 있는 권한 세트입니다. OpenSearch 대시보드를 사용하거나 REST API의 _plugins/_security 작업을 사용하여 새 작업 그룹을 만들 수 있지만 대부분의 사용 사례에서는 기본 작업 그룹으로도 충분합니다. 기본 작업 그룹에 대한 자세한 내용은 기본 작업 그룹 섹션을 참조하세요.

OpenSearch 대시보드 멀티테넌시

테넌트는 인덱스 패턴, 시각화, 대시보드 및 기타 Dashboards 객체를 저장하는 공간입니다. Dashboards 멀티-테넌시를 사용하면 작업을 다른 Dashboards 사용자와 안전하게 공유하거나 프라이빗 상태로 유지하고 테넌트를 역동적으로 구성할 수 있습니다. 테넌트에 액세스할 수 있는 역할과 해당 역할에 읽기 또는 쓰기 액세스 권한이 있는지를 제어할 수 있습니다. 글로벌 테넌트가 기본값입니다. 자세히 알아보려면 대시보드 멀티테넌시를 참조하십시오OpenSearch .

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

OpenSearch 대시보드로 이동하여 로그인합니다.
오른쪽 상단에서 사용자 아이콘을 선택하고 테넌트 전환(Switch tenants)을 선택합니다.
시각화 또는 대시보드를 생성하기 전에 테넌트를 확인합니다. 다른 모든 Dashboards 사용자와 작업을 공유하려면 글로벌(Global)을 선택합니다. 일부 Dashboards 사용자와 하위 작업을 공유하려면 다른 공유 테넌트를 선택합니다. 그렇지 않으면 프라이빗(Private)을 선택합니다.

참고

OpenSearch 대시보드는 각 테넌트에 대해 별도의 인덱스를 유지 관리하고 이라는 인덱스 템플릿을 생성합니다. tenant_template 테넌트 tenant_template 인덱스 매핑이 잘못 구성된 경우 OpenSearch 대시보드가 오작동할 수 있으므로 인덱스를 삭제하거나 수정하지 마십시오.

권장 구성

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

설명	마스터 사용자	도메인 액세스 정책
OpenSearch API 호출에는 IAM 자격 증명을 사용하고 대시보드에 액세스하려면 SAML 인증을 사용하십시오. Dashboards 또는 REST API를 사용하여 세분화된 액세스 제어 역할을 관리합니다.	IAM 역할 또는 사용자	`{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "" }, "Action": "es:ESHttp", "Resource": "domain-arn/*" } ] }`
API 호출에는 IAM 자격 증명 또는 기본 인증을 사용하십시오. OpenSearch Dashboards 또는 REST API를 사용하여 세분화된 액세스 제어 역할을 관리합니다. 이 구성은 유연성이 뛰어나며, 특히 기본 인증만 지원하는 OpenSearch 클라이언트가 있는 경우 더욱 그렇습니다. 기존 자격 증명 공급자가 있는 경우 SAML 인증을 사용하여 Dashboards에 액세스합니다. 그렇지 않으면 내부 사용자 데이터베이스에서 Dashboards 사용자를 관리합니다.	사용자 이름 및 암호	`{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "" }, "Action": "es:ESHttp", "Resource": "domain-arn/*" } ] }`
OpenSearch API 호출에는 IAM 자격 증명을 사용하고 대시보드에 액세스하려면 Amazon Cognito를 사용하십시오. Dashboards 또는 REST API를 사용하여 세분화된 액세스 제어 역할을 관리합니다.	IAM 역할 또는 사용자	`{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "" }, "Action": "es:ESHttp", "Resource": "domain-arn/*" } ] }`
IAM 자격 증명을 사용하여 OpenSearch API를 호출하고 대시보드에 대한 대부분의 액세스를 차단하십시오. REST API를 사용하여 세분화된 액세스 제어 역할을 관리합니다.	IAM 역할 또는 사용자	`{ "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/_dashboards" } ] }`

제한 사항

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

역할을 호스트 이름 또는 IP 주소에 매핑하는 hosts 측면의 역할 매핑은 도메인이 VPC 내에 있는 경우 작동하지 않습니다. 사용자 및 백엔드 역할에는 여전히 역할을 매핑할 수 있습니다.
마스터 사용자에 IAM을 선택하고 Amazon Cognito 또는 SAML 인증을 활성화하지 않으면 Dashboards에 작동하지 않는 로그인 페이지가 표시됩니다.
마스터 사용자에 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/_plugins/_sql"
}
```
도메인 버전이 2.3 이상이고 세분화된 액세스 제어를 활성화한 경우 max_clause_count(을)를 1로 설정하면 도메인에 문제가 발생할 수 있습니다. 이 계정을 더 높은 숫자로 설정하는 것이 좋습니다.
세분화된 액세스 제어가 설정되지 않은 도메인에서 세분화된 액세스 제어를 활성화하려는 경우 직접 쿼리용으로 생성된 데이터 소스에 대해 세분화된 액세스 제어 역할을 직접 설정해야 합니다. 세분화된 액세스 역할을 설정하는 방법에 대한 자세한 내용은 Amazon S3와 Amazon OpenSearch Service 데이터 소스 통합 생성을 참조하십시오.

마스터 사용자 수정

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

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

https://console.aws.amazon.com/aos/home/ 에서 아마존 OpenSearch 서비스 콘솔로 이동합니다.
도메인을 선택하고 Actions(작업), Edit security configuration(보안 구성 편집)을 선택합니다.
IAM ARN을 마스터 사용자로 설정(Set IAM ARN as master user) 또는 마스터 사용자 생성(Create master user)을 선택합니다.
- 이전에 IAM 마스터 사용자를 사용한 경우 세분화된 액세스 제어가 all_access 역할을 지정한 새 IAM ARN에 다시 매핑합니다.
- 이전에 내부 사용자 데이터베이스를 사용한 경우 세분화된 액세스 제어가 새 마스터 사용자를 생성합니다. 새 마스터 사용자를 사용하여 이전 마스터 사용자를 삭제할 수 있습니다.
- 내부 사용자 데이터베이스에서 IAM 마스터 사용자로 전환하면 내부 사용자 데이터베이스에서 사용자가 삭제되지 않습니다. 대신 HTTP 기본 인증을 비활성화합니다. 내부 사용자 데이터베이스에서 사용자를 수동으로 삭제하거나 HTTP 기본 인증을 다시 활성화해야 할 경우를 대비하여 보관합니다.
변경 사항 저장를 선택합니다.

추가 마스터 사용자

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

Dashboards를 사용하는 경우 보안(Security), 역할(Roles)을 선택한 다음 새 마스터 사용자를 all_access 및 security_manager 역할에 매핑합니다.

REST API를 사용하려면 다음 요청을 보냅니다.


PUT _plugins/_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 _plugins/_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 역할을 사용하여 서명된 요청을 도메인으로 보냅니다.

통합

서비스와 함께 다른 AWS 서비스를 사용하는 경우 적절한 권한을 가진 OpenSearch 해당 서비스에 대한 IAM 역할을 제공해야 합니다. 예를 들어 Firehose 전송 스트림은 라는 IAM 역할을 사용하는 경우가 많습니다. firehose_delivery_role Dashboards에서 세분화된 액세스 제어를 위한 역할을 생성하고 이 역할에 IAM 역할을 매핑합니다. 이 경우 새 역할에는 다음 권한이 필요합니다.


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

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

REST API 차이점

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

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


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

OpenSearch 또는 Elasticsearch 7.x에서 요청은 다음과 같습니다 (Elasticsearch를 사용하는 경우 요청으로 변경). _plugins _opendistro


PUT _plugins/_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에서는 이러한 OpenSearch 객체가 고유한 URI를 가진 객체입니다 (Elasticsearch를 사용하는 경우 로 변경). _plugins _opendistro


GET _plugins/_security/api/tenants

{
  "global_tenant": {
    "reserved": true,
    "hidden": false,
    "description": "Global tenant",
    "static": false
  }
}

OpenSearch REST API에 대한 설명서는 보안 플러그인 API 참조를 참조하십시오.

작은 정보

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


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

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

교차 서비스 혼동된 대리자 예방

자습서: Cognito 인증을 사용한 세분화된 액세스 제어