View a markdown version of this page

자습서: 내부 사용자 데이터베이스와 HTTP 기본 인증을 사용하여 도메인 구성 - Amazon OpenSearch Service

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

자습서: 내부 사용자 데이터베이스와 HTTP 기본 인증을 사용하여 도메인 구성

이 자습서에서는 내부 사용자 데이터베이스의 마스터 사용자와 OpenSearch 대시보드에 대한 HTTP 기본 인증이라는 또 다른 일반적인 세분화된 액세스 제어 사용 사례를 다룹니다. 그러면 마스터 사용자는 OpenSearch Dashboards에 로그인하여 내부 사용자를 생상하고 이 사용자를 역할에 매핑하고 세분화된 액세스 제어를 사용하여 사용자의 권한을 제한할 수 있습니다.

참고

IAM 보안 주체를 지정하는 리소스 기반 액세스 정책과 함께 HTTP 기본 인증을 사용하는 경우 HTTP 기본 인증을 통해 인증된 서명되지 않은 요청은 세분화된 액세스 제어 내부 사용자 데이터베이스에서만 처리됩니다. 서명된 요청(SigV4 사용)은 도메인 액세스 정책과 세분화된 액세스 제어를 기준으로 평가됩니다. 액세스 정책이와 같은 보안 주체를 지정하는 경우 해당 계정의 SigV4-signed 요청"AWS": "arn:aws:iam::111122223333:root"만 액세스 정책에서 허용되며 HTTP Basic Auth 요청은 액세스 정책을 우회하고 세분화된 액세스 제어 역할로 완전히 제어됩니다.

이 튜토리얼에서는 다음 단계를 완료합니다.

1단계: 도메인 생성

https://console.aws.amazon.com/aos/home/ Amazon OpenSearch Service 콘솔로 이동하여 다음 설정을 사용하여 도메인을 생성합니다.

  • OpenSearch 1.0 이상 또는 Elasticsearch 7.9 이상

  • 공개 액세스(Public access)

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

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

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

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

  • 노드 간 암호화

  • 저장 데이터의 암호화

2다녜: OpenSearch Dashboards에서 내부 사용자 구성하기

이제 도메인이 생겼으므로 OpenSearch Dashboards에 로그인하여 내부 사용자를 생성할 수 있습니다.

  1. OpenSearch Service 콘솔로 돌아가서 생성한 도메인의 OpenSearch 대시보드 URL로 이동합니다. URL은 domain-endpoint/_dashboards/ 형식입니다.

  2. TheMasterUser(으)로 로그인합니다.

  3. Add sample data(샘플 데이터 추가)를 선택하고 샘플 비행 데이터를 추가합니다.

  4. 왼쪽 탐색 창에서 보안, 내부 사용자, 내부 사용자 생성을 선택합니다.

  5. 사용자의 이름을 new-user로 지정하고 암호를 지정합니다. 그런 다음 생성(Create)을 선택합니다.

3단계: OpenSearch Dashboards에서 역할 매핑

이제 사용자가 구성되었으므로 사용자를 역할에 매핑할 수 있습니다.

  1. OpenSearch Dashboards의 보안 섹션에서 역할, 역할 생성을 선택하세요.

  2. 역할 이름을 new-role로 지정합니다.

  3. 인덱스 권한의 경우 인덱스 패턴에 opensearch_dashboards_sample_data_fli*(을)를 지정합니다(Elasticsearch 도메인의 kibana_sample_data_fli*인 경우 ).

  4. 작업 그룹에 대해 읽기(read)를 선택합니다.

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

    { "match": { "FlightDelay": true } }
  6. 필드 수준 보안의 경우 제외(Exclude)를 선택하고 FlightNum을 지정합니다.

  7. 익명화(Anonymization)Dest를 지정합니다.

  8. 생성(Create)을 선택합니다.

  9. 매핑된 사용자(Mapped users), 매핑 관리(Manage mapping)를 차례로 선택합니다. 그런 다음 new-user사용자(Users)에 추가하고 맵(Map)을 선택합니다.

4단계: 권한 테스트

역할이 올바르게 매핑되면 제한된 사용자로 로그인하고 권한을 테스트할 수 있습니다.

  1. 새로운 프라이빗 브라우저 창에서 도메인의 OpenSearch 대시보드 URL로 이동하고 new-user 보안 인증을 사용하여 로그인한 다음 Explore on my own(직접 탐색)을 선택합니다.

  2. 개발 도구(Dev Tools)로 이동하여 기본 검색을 실행합니다.

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

    권한 오류를 확인합니다. new-user에는 클러스터 전체 검색을 실행할 권한이 없습니다.

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

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

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

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