기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
아마존 OpenSearch 서비스의 ID 및 액세스 관리
Amazon OpenSearch Service는 도메인에 대한 액세스를 제어할 수 있는 여러 가지 방법을 제공합니다. 이 주제에서는 다양한 정책 유형과 정책 유형 사이의 상호 작용 방식, 그리고 사용자 지정 정책을 생성하는 방법에 대해서 살펴보겠습니다.
중요
VPC지원팀에서는 OpenSearch 서비스 액세스 제어에 대한 몇 가지 추가 고려 사항을 소개합니다. 자세한 내용은 VPC 도메인 액세스 정책에 대하여 단원을 참조하십시오.
정책 유형
OpenSearch 서비스는 세 가지 유형의 액세스 정책을 지원합니다.
리소스 기반 정책
도메인을 생성할 때 도메인 액세스 정책이라고도 하는 리소스 기반 정책을 추가합니다. 이 정책은 보안 주체가 도메인의 하위 리소스에서 실행할 수 있는 작업을 지정합니다(클러스터 간 검색 제외). 하위 리소스에는 OpenSearch 색인 및 이 포함됩니다. APIs Principal 요소는 액세스가 허용된 계정, 사용자 또는 역할을 지정합니다. Resource 요소는 이러한 보안 주체가 액세스할 수 있는 하위 리소스를 지정합니다.
예를 들어 다음 리소스 기반 정책은 test-user에게 test-domain의 하위 리소스에 대한 모든 액세스 권한(es:*)을 부여합니다.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:*" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" } ] }
이 정책에는 다음과 같이 두 가지 중요한 고려 사항이 있습니다.
-
이 권한은 해당 도메인에만 적용됩니다. 다른 도메인에서 유사한 정책을 만들지 않는 한
test-user만test-domain에 액세스할 수 있습니다. -
Resource에서/*요소의 추적은 중요하며 리소스 기반 정책은 도메인 자체가 아닌 도메인의 하위 리소스에만 적용됨을 나타냅니다. 리소스 기반 정책에서es:*작업은es:ESHttp*와 동일합니다.예를 들어
test-user는 인덱스(GET https://search-test-domain.us-west-1.es.amazonaws.com/test-index)에 대해 요청할 수 있지만 도메인의 구성(POST https://es.us-west-1.amazonaws.com/2021-01-01/opensearch/domain/test-domain/config)을 업데이트하지는 못합니다. 두 엔드포인트의 차이점을 참고하세요. 구성에 액세스하려면 ID API 기반 정책이 필요합니다.
와일드카드를 추가하여 부분 인덱스 이름을 지정할 수 있습니다. 이 예시는 commerce(으)로 시작하는 모든 인덱스를 식별합니다.
arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce*
이 경우 이 와일드카드를 사용하여 지정하면 test-user이(가) commerce(으)로 이름이 시작되는 test-domain 내의 인덱스에 요청할 수 있음을 의미합니다.
test-user의 액세스 권한을 추가로 제한할 때는 다음과 같이 정책을 적용할 수 있습니다.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttpGet" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/_search" } ] }
이제 test-user은(는) 한 가지 작업, 즉 commerce-data 인덱스에 대한 비교 검색만 실행할 수 있습니다. 그 밖에 도메인에 속한 모든 인덱스에는 액세스할 수 없으며, es:ESHttpPut 또는 es:ESHttpPost 작업 사용 권한이 없기 때문에 test-user이(가) 문서를 추가하거나 수정하는 것은 제한됩니다.
다음으로 고급 사용자 역할을 구성할 수도 있습니다. 이 정책은 인덱스에 있는 모든 URIs 사용자에게 HTTP GET 및 PUT 메서드에 대한 power-user-role 액세스 권한을 부여합니다.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:role/power-user-role" ] }, "Action": [ "es:ESHttpGet", "es:ESHttpPut" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/*" } ] }
도메인이 세분화된 액세스 제어를 VPC 적용받거나 사용하는 경우 개방형 도메인 액세스 정책을 사용할 수 있습니다. 그렇지 않으면 도메인 액세스 정책에 보안 주체 또는 IP 주소별로 몇 가지 제한 사항이 포함되어야 합니다.
가능한 작업에 대한 자세한 내용은 정책 요소 참조 섹션을 참조하세요. 데이터를 훨씬 더 세밀하게 제어하려면 세분화된 액세스 제어와 함께 개방형 도메인 액세스 정책을 사용합니다.
보안 인증 기반 정책
각 OpenSearch 서비스 도메인의 일부인 리소스 기반 정책과 달리 () 서비스를 사용하여 ID 기반 정책을 사용자 또는 역할에 연결합니다. AWS Identity and Access Management IAM 자격 증명 기반 정책 역시 리소스 기반 정책과 마찬가지로 서비스에 대한 액세스 주체와 실행 가능한 작업, 그리고 해당되는 경우에 한해 작업을 실행할 수 있는 리소스까지 지정합니다.
반드시 그래야 하는 것은 아니지만 자격 증명 기반 정책은 더욱 포괄적으로 적용되는 경우가 많습니다. 이러한 정책은 사용자가 API 수행할 수 있는 구성 작업에만 적용되는 경우가 많습니다. 이러한 정책을 마련한 후에는 OpenSearch 서비스의 리소스 기반 정책 (또는 세분화된 액세스 제어) 을 사용하여 사용자에게 인덱스 및 인덱스에 대한 액세스를 제공할 수 있습니다. OpenSearch APIs
참고
AWS 관리형 AmazonOpenSearchServiceReadOnlyAccess 정책을 사용하는 사용자는 콘솔에서 클러스터 상태를 볼 수 없습니다. 사용자가 클러스터 상태 (및 기타 OpenSearch 데이터) 를 볼 수 있게 하려면 액세스 정책에 es:ESHttpGet 작업을 추가하고 사용자 계정이나 역할에 연결하세요.
ID 기반 정책은 사용자 또는 역할 (보안 주체) 에 연결되므로 보안 주체를 지정하지 JSON 않습니다. 다음 정책은 Describe 및 List로 시작하는 작업에 대한 액세스 권한을 부여합니다. 이러한 조합의 작업은 도메인 구성에 대한 읽기 전용 액세스 권한을 제공하지만, 도메인 자체에 저장된 데이터에 대한 액세스 권한은 제공하지 않습니다.
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "es:Describe*", "es:List*" ], "Effect": "Allow", "Resource": "*" } ] }
관리자는 OpenSearch 서비스 및 모든 도메인에 저장된 모든 데이터에 대한 전체 액세스 권한을 가질 수 있습니다.
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "es:*" ], "Effect": "Allow", "Resource": "*" } ] }
ID 기반 정책을 사용하면 태그를 사용하여 구성에 대한 액세스를 제어할 수 있습니다. API 예를 들어 다음 정책은 도메인에 team:devops 태그가 있는 경우 연결된 보안 주체가 도메인 구성을 보고 업데이트할 수 있도록 허용합니다.
{ "Version": "2012-10-17", "Statement": [{ "Action": [ "es:UpdateDomainConfig", "es:DescribeDomain", "es:DescribeDomainConfig" ], "Effect": "Allow", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/team": [ "devops" ] } } }] }
태그를 사용하여 에 대한 액세스를 제어할 수도 있습니다. OpenSearch API 에 대한 태그 기반 정책은 OpenSearch API HTTP 메서드에만 적용됩니다. 예를 들어 다음 정책은 도메인에 태그가 있는 OpenSearch API 경우 연결된 보안 주체가 해당 도메인에 PUT 요청을 GET 보내고 요청할 수 있도록 합니다. environment:production
{ "Version": "2012-10-17", "Statement": [{ "Action": [ "es:ESHttpGet", "es:ESHttpPut" ], "Effect": "Allow", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/environment": [ "production" ] } } }] }
를 보다 세밀하게 제어하려면 세분화된 액세스 OpenSearch API 제어를 사용하는 것이 좋습니다.
참고
태그 기반 정책에 하나 이상을 OpenSearch APIs 추가한 후에는 단일 태그 작업 (예: 태그 추가, 제거 또는 수정) 을 수행해야 변경 내용이 도메인에 적용됩니다. 태그 기반 정책에 OpenSearch API 작업을 포함하려면 서비스 소프트웨어 R20211203 이상을 사용 중이어야 합니다.
OpenSearch 서비스는 해당 구성의 RequestTag TagKeys 글로벌 조건 키를 API 지원하지만 는 지원하지 않습니다. OpenSearch API 이러한 조건은 요청에 태그가 포함된 API 호출에만 적용됩니다 (예:CreateDomain,AddTags,)RemoveTags. 다음 정책을 사용하면 연결된 보안 주체가 도메인을 생성할 수 있지만 요청에 team:it 태그를 포함하는 경우에만 해당합니다.
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "es:CreateDomain", "es:AddTags" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/team": [ "it" ] } } } }
액세스 제어를 위한 태그 사용 및 리소스 기반 정책과 ID 기반 정책 간의 차이점에 대한 자세한 내용은 사용 설명서를 참조하십시오. IAM
IP 기반 정책
IP 기반 정책은 도메인에 대한 액세스를 하나 이상의 IP 주소 또는 블록으로 제한합니다. CIDR 기술적으로 보았을 때 IP 기반 정책은 별개의 정책이 아닙니다. 오히려 익명의 보안 주체를 지정한 후 특별한 Condition 요소를 추가하는 리소스 기반 정책이라고도 할 수 있습니다.
IP 기반 정책의 가장 큰 매력은 OpenSearch 서비스 도메인에 서명되지 않은 요청을 허용하여 curl
참고
도메인에 대한 VPC 액세스를 활성화한 경우 IP 기반 정책을 구성할 수 없습니다. 대신에 보안 그룹을 사용하여 어느 IP 주소가 도메인에 액세스할 수 있는지 제어할 수 있습니다. 자세한 내용은 VPC 도메인 액세스 정책에 대하여 단원을 참조하십시오.
다음 정책은 지정된 IP 범위에서 시작된 모든 HTTP 요청에 대한 액세스 권한을 부여합니다. test-domain
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "es:ESHttp*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" } ] }
도메인에 퍼블릭 엔드포인트가 있고 세분화된 액세스 제어를 사용하지 않는 경우 IAM 보안 주체와 IP 주소를 결합하는 것이 좋습니다. 이 정책은 요청이 지정된 IP 범위에서 시작된 경우에만 test-user HTTP 액세스를 허용합니다.
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::987654321098:user/test-user" ] }, "Action": [ "es:ESHttp*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" }] }
OpenSearch 서비스 요청 작성 및 서명
완전히 개방된 리소스 기반 액세스 정책을 구성하더라도 OpenSearch 서비스 구성에 대한 모든 요청은 API 서명되어야 합니다. 정책에 IAM 역할이나 사용자가 지정된 경우 AWS 서명 버전 4를 사용하여 해당 OpenSearch APIs 요청에도 서명해야 합니다. 서명 방법은 다음과 같이 다릅니다. API
-
OpenSearch 서비스 구성을 API 호출하려면 다음 중 하나를 사용하는 것이 좋습니다. AWS SDKs
이렇게 하면 프로세스를 SDKs 크게 단순화하고 직접 요청을 만들고 서명하는 것에 비해 시간을 크게 절약할 수 있습니다. 구성 API 엔드포인트는 다음 형식을 사용합니다. es.region.amazonaws.com/2021-01-01/예를 들어 다음 요청은
movies도메인의 구성을 변경하지만, 사용자가 직접 서명해야 합니다(권장하지 않음).POST https://es.us-east-1.amazonaws.com/2021-01-01/opensearch/domain/movies/config { "ClusterConfig": { "InstanceType": "c5.xlarge.search" } }Boto3과 같은 방법
중 하나를 사용하는 경우 에서 요청 SDK 서명을 자동으로 처리합니다. SDKs import boto3 client = boto3.client(es) response = client.update_domain_config( DomainName='movies', ClusterConfig={ 'InstanceType': 'c5.xlarge.search' } )Java 코드 샘플의 경우 Amazon OpenSearch Service와 상호 작용하기 위한 AWS SDK 사용 섹션을 참조하세요.
-
에 전화를 걸려면 요청에 직접 서명해야 합니다. OpenSearch APIs 다음 형식을 OpenSearch APIs 사용하십시오.
domain-id.region.es.amazonaws.com예를 들어 다음 요청은
movies인덱스에서 thor를 검색합니다.GET https://my-domain.us-east-1.es.amazonaws.com/movies/_search?q=thor
참고
서비스는 서명 버전 4로 서명된 URLs HTTP POST 요청에 전달된 매개 변수를 무시합니다.
정책 충돌 시
정책이 서로 일치하지 않거나 사용자를 명시적으로 지정하지 않으면 복잡한 문제가 발생합니다. IAM사용 설명서의 IAM 작동 방식을 이해하면 정책 평가 논리를 간결하게 요약할 수 있습니다.
-
기본적으로 모든 요청을 거부합니다.
-
명시적 허용은 이러한 기본 설정을 무시합니다.
-
명시적 거부는 모든 허용을 무시합니다.
예를 들어 리소스 기반 정책에서는 도메인 하위 리소스 ( OpenSearch 인덱스 또는API) 에 대한 액세스를 허용하지만 ID 기반 정책에서는 액세스를 거부하면 액세스가 거부됩니다. 자격 증명 기반 정책이 액세스를 권한을 부여하고 리소스 기반 정책이 액세스 필요 여부를 지정하지 않을 경우에는 액세스가 허용됩니다. 정책이 서로 엇갈렸을 때 도메인 하위 리소스에 대한 결과는 아래 요약 표를 참조하세요.
| 리소스 기반 정책에서 허용됨 | 리소스 기반 정책에서 거부됨 | 리소스 기반 정책에서 허용 및 거부되지 않음 | |
|---|---|---|---|
| Allowed in identity-based policy |
허용 |
거부 | 허용 |
| Denied in identity-based policy | 거부 | 거부 | 거부 |
| Neither allowed nor denied in identity-based policy | 허용 | 거부 | 거부 |
정책 요소 참조
OpenSearch 서비스는 정책 요소 참조에 있는 대부분의 정책 요소를 지원합니다 (IAM단, 제외). NotPrincipal 다음 표에는 가장 일반적인 요소가 나와 있습니다.
| JSON정책 요소 | 요약 |
|---|---|
Version |
정책 언어의 현재 버전은 |
Effect |
이 요소는 명령문이 지정한 작업에 대한 액세스를 허용 또는 거부 여부를 지정합니다. 유효한 값은 |
Principal |
이 요소는 리소스에 대한 액세스를 허용하거나 거부할 수 있는 또는 IAM 역할 또는 사용자를 지정하며 여러 형식을 취할 수 있습니다. AWS 계정
|
Action
|
OpenSearch 서비스는 메서드에 일부 사용 가능한 모든 작업의 목록과 해당 작업이 도메인 하위 리소스 ( 무엇보다 이미 존재하는 도메인에 대한 생성 권한을 사용자에게 부여하는 이유를 알 수 없다는 점에서 물론 다음과 같이 리소스 요소의 제한을 줄여서 작업을 추가하는 것도 가능합니다.
작업과 리소스의 페어링에 대한 자세한 내용은 여기 표에서 |
Condition |
OpenSearch 서비스는 IAM사용 설명서의 AWS 글로벌 조건 컨텍스트 키에 설명된 대부분의 조건을 지원합니다. 주목할 만한 예외로는 OpenSearch 서비스가 지원하지 않는 IP 기반 정책을 구성할 때는 다음과 같은 조건으로 IP 주소 또는 CIDR 블록을 지정합니다. 에서 설명한 것처럼보안 인증 기반 정책, |
Resource |
OpenSearch 서비스는 다음과 같은 세 가지 기본 방식으로
리소스 수준 권한을 지원하는 작업에 대한 자세한 내용은 여기 표에서 |
고급 옵션 및 고려 사항 API
OpenSearch 서비스에는 몇 가지 고급 옵션이 있으며, 그 중 하나는 액세스 제어와 관련이 있습니다. rest.action.multi.allow_explicit_index 기본 설정 값인 true일 때는 사용자가 일부 상황에서 하위 리소스 권한을 우회할 수 있습니다.
예를 들어 다음과 같은 리소스 기반 정책이 있다고 가정하겠습니다.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttp*" ], "Resource": [ "arn:aws:es:us-west-1:987654321098:domain/test-domain/test-index/*", "arn:aws:es:us-west-1:987654321098:domain/test-domain/_bulk" ] }, { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttpGet" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*" } ] }
이 정책은 대량에 대한 test-user 전체 액세스 권한을 test-index 부여합니다 OpenSearch . API 또한 restricted-index에 대한 GET 요청도 허용합니다.
예상할 수 있겠지만 다음 인덱싱 요청은 권한 오류로 인해 실패할 수 밖에 없습니다.
PUT https://search-test-domain.us-west-1.es.amazonaws.com/restricted-index/movie/1 { "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" }
API인덱스와 달리 API 대량에서는 한 번의 호출로 많은 문서를 만들고, 업데이트하고, 삭제할 수 있습니다. 하지만 요청 대신 요청 본문에 이러한 작업을 지정하는 경우가 많습니다URL. OpenSearch 서비스는 도메인 하위 리소스에 대한 액세스를 제어하는 URLs 데 사용하므로 실제로 API 대량을 사용하여 도메인 하위 리소스를 변경할 test-user 수 있습니다. restricted-index 사용자에게 인덱스에 대한 POST 권한이 없더라도 다음 요청은 성공합니다.
POST https://search-test-domain.us-west-1.es.amazonaws.com/_bulk { "index" : { "_index": "restricted-index", "_type" : "movie", "_id" : "1" } } { "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" }
이러한 상황에서는 액세스 정책이 목적을 이루지 못합니다. 따라서 사용자가 액세스 제한을 우회하지 못하도록 rest.action.multi.allow_explicit_index를 false로 변경할 수 있습니다. 이 값이 false인 경우 요청 본문에 인덱스 이름을 APIs 지정하는 bulk, mget 및 msearch에 대한 모든 호출이 작동을 멈춥니다. 다시 말해서 _bulk 호출은 더 이상 유효하지 않지만 test-index/_bulk 호출은 유효합니다. 이 두 번째 엔드포인트에 인덱스 이름이 포함되기 때문에 요청 본문에 이름을 지정할 필요가 없습니다.
OpenSearch 대시보드는 mget과 msearch에 크게 의존하므로 이 변경 후에는 제대로 작동하지 않을 수 있습니다. 부분적 수정의 경우 rest.action.multi.allow_explicit_index true로 유지하고 특정 사용자가 이들 중 하나 이상에 액세스하는 것을 거부할 수 있습니다. APIs
이 설정의 변경에 대한 자세한 내용은 고급 클러스터 설정 섹션을 참조하세요.
마찬가지로 다음 리소스 기반 정책 역시 두 가지 미묘한 문제가 있습니다.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/test-user" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" }, { "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::123456789012:user/test-user" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*" } ] }
-
명시적인 거부에도 불구하고
test-user가 여전히GET https://search-test-domain.us-west-1.es.amazonaws.com/_all/_search나GET https://search-test-domain.us-west-1.es.amazonaws.com/*/_search같은 호출을 통해restricted-index의 문서에 액세스할 수 있습니다. -
Resource요소가restricted-index/*를 참조하기 때문에test-user는 인덱스의 문서에 직접 액세스할 수 있는 권한이 없습니다. 하지만 사용자에게 전체 인덱스를 삭제할 권한은 있습니다. 이러한 액세스 및 삭제 문제를 방지하려면 정책에restricted-index*를 지정해야 합니다.
광범위한 액세스 허용과 집약적 액세스 거부를 혼합하기보다 최소 권한 원칙을 따라 태스크에 필요한 권한만 부여하는 것이 가장 안전한 방법입니다. 개별 인덱스 또는 OpenSearch 작업에 대한 액세스 제어에 대한 자세한 내용은 을 참조하십시오. Amazon 서비스의 세밀한 액세스 제어 OpenSearch
중요
* 와일드카드를 지정하면 도메인에 익명으로 액세스할 수 있습니다. 와일드카드는 사용하지 않는 것이 좋습니다. 또한 다음 정책을 주의 깊게 검토하여 광범위한 액세스를 허용하지 않는지 확인하십시오.
-
관련 주체에 연결된 ID 기반 정책 (예 AWS : 역할) IAM
-
관련 리소스에 연결된 AWS 리소스 기반 정책 (예: 키) AWS Key Management Service KMS
액세스 정책 구성
추가 샘플 정책
이 장에는 여러 샘플 정책이 포함되어 있지만 AWS 액세스 제어는 복잡한 주제이므로 예제를 통해 가장 잘 이해할 수 있습니다. 자세한 내용은 IAM사용 설명서의 IAM ID 기반 정책 예를 참조하십시오.
