Amazon Elasticsearch Service Identity and Access Management - Amazon Elasticsearch Service

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

Amazon Elasticsearch Service Identity and Access Management

Amazon Elasticsearch Service (Amazon ES) 는 도메인에 대한 액세스를 제어하는 여러 가지 방법을 제공합니다. 이 항목에서는 다양한 정책 유형, 정책 유형 간의 상호 작용 방식 및 사용자 지정 정책을 생성하는 방법에 대해 살펴보겠습니다.

중요

VPC 지원으로 Amazon ES 액세스 제어를 위한 몇 가지 고려해야 할 사항이 추가되었습니다. 자세한 내용은 VPC 도메인의 액세스 정책 섹션을 참조하세요.

정책

Amazon ES는 다음 세 가지 유형의 액세스 정책을 지원합니다.

리소스 기반 정책

도메인을 생성할 때 도메인 액세스 정책이라고도 하는 리소스 기반 정책을 추가합니다. 이 정책은 보안 주체가 도메인의 하위 리소스에서 실행할 수 있는 작업을 지정합니다. 하위 리소스에는 Elasticsearch 인덱스와 API가 있습니다.

Principal 요소는 액세스가 허용된 계정, 사용자 또는 역할을 지정합니다. Resource 요소는 이러한 보안 주체가 액세스할 수 있는 하위 리소스를 지정합니다. 다음 리소스 기반 정책이test-user full access (es:*) 의 하위 리소스에test-domain:

{ "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 can only access test-domain.

  • 후행/*Resource요소가 중요하기 때문에 리소스 기반 정책이 도메인 자체가 아닌 도메인의 하위 리소스에만 적용된다는 점을 나타냅니다. 리소스 기반 정책에서es:* action is equivalent to 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/2015-01-01/es/domain/test-domain/config)을 업데이트하지는 못합니다. 두 엔드포인트의 차이점을 참고하십시오. 구성 API에 액세스하기 위해서는 자격 증명 기반 정책이 필요합니다.

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/test-index/_search" } ] }

이제 test-user는 한 가지 작업, 즉 test-index에 대한 비교 검색만 실행할 수 있습니다. 그 밖에 도메인에 속한 모든 인덱스에는 액세스할 수 없으며, es:ESHttpPut 또는 es:ESHttpPost 작업 사용 권한이 없기 때문에 test-user가 문서를 추가하거나 수정하는 것은 제한됩니다.

다음으로 고급 사용자 역할을 구성할 수도 있습니다. 이 정책은 인덱스에 있는 모든 URI의 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/test-index/*" } ] }

VPC 있는 도메인이거나 세분화된 액세스 제어를 사용하는 경우에는 개방형 도메인 액세스 정책을 사용할 수 있습니다. 그렇지 않으면 도메인 액세스 정책에 보안 주체 또는 IP 주소별로 몇 가지 제한 사항이 포함되어야 합니다.

가능한 작업에 대한 자세한 내용은 정책 요소 참조 단원을 참조하십시오. 데이터를 훨씬 더 세밀하게 제어하려면세분화된.

자격 증명 기반 정책

각 Amazon ES 도메인의 일부인 리소스 기반 정책AWS Identity and Access Management 달리 자격 증명 기반 정책은 (IAM) 서비스를 사용하여 사용자 또는 역할에 연결됩니다. 자격 증명 기반 정책 역시 리소스 기반 정책과 마찬가지로 서비스에 대한 액세스 주체와 실행 가능한 작업, 그리고 해당되는 경우에 한해 작업을 실행할 수 있는 리소스까지 지정합니다.

반드시 그래야 하는 것은 아니지만 자격 증명 기반 정책은 더욱 포괄적으로 적용되는 경우가 많습니다. 대부분의 경우 사용자가 수행할 수 있는 구성 API 동작만 관리합니다. 이러한 정책을 할당한 후에는 리소스 기반 정책 (또는세분화된) 를 사용하여 사용자에게 Elasticsearch 인덱스 및 API에 대한 액세스 권한을 제공할 수 있습니다.

참고

AWS 관리형 AmazonESReadOnlyAccess 정책이 적용되는 사용자는 콘솔에서 클러스터 상태를 볼 수 없습니다. 이러한 사용자가 클러스터 상태 (및 기타 Elasticsearch 데이터) 를 볼 수 있게 하려면es:ESHttpGet작업을 액세스 정책에 연결하고 이를 해당하는 계정 또는 역할에 연결합니다.

자격 증명 기반 정책은 사용자 또는 역할(보안 주체)에 연결되기 때문에 JSON이 보안 주체를 따로 지정하지 않습니다. 다음 정책은 DescribeList로 시작하는 작업에 대한 액세스 권한을 부여합니다. 이러한 조합의 작업은 도메인 구성에 대한 읽기 전용 액세스 권한을 제공하지만, 도메인 자체에 저장된 데이터에 대한 액세스 권한은 제공하지 않습니다.

{ "Version": "2012-10-17", "Statement": [ { "Action": [ "es:Describe*", "es:List*" ], "Effect": "Allow", "Resource": "*" } ] }

관리자는 Amazon ES 및 모든 도메인에 저장된 모든 데이터에 대한 모든 액세스를 가질 수 있습니다.

{ "Version": "2012-10-17", "Statement": [ { "Action": [ "es:*" ], "Effect": "Allow", "Resource": "*" } ] }

ID 기반 정책을 사용하면 태그를 사용하여 구성 API에 대한 액세스를 제어할 수 있습니다 (하지엘라스틱 검색 API). 예를 들어 다음 정책은 연결된 보안 주체가 도메인 구성을 보고 업데이트할 수 있도록 허용합니다.team:devops태그를 사용합니다.

{ "Version": "2012-10-17", "Statement": [{ "Action": [ "es:UpdateElasticsearchDomainConfig", "es:DescribeElasticsearchDomain", "es:DescribeElasticsearchDomainConfig" ], "Effect": "Allow", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/team": [ "devops" ] } } }] }

마찬가지로, 아마존 ES는RequestTagTagKeys구성 API에 대한 전역 조건 키입니다. 이러한 조건은 요청 내에 태그를 포함하는 API 호출에만 적용됩니다 (예:CreateElasticsearchDomain,AddTags, 및RemoveTags. 다음 정책은 연결된 보안 주체가 도메인을 만들 수 있도록 허용하지만team:it요청에 태그를:

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "es:CreateElasticsearchDomain", "es:AddTags" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/team": [ "it" ] } } } }

액세스 제어에 태그를 사용하는 방법과 리소스 기반 정책과 ID 기반 정책의 차이점에 대한 자세한 내용은IAM 사용 설명서.

IP 기반 정책

IP 기반 정책은 도메인에 대한 액세스를 하나 이상의 IP 주소 또는 CIDR 블록으로 제한합니다. 기술적으로 보았을 때 IP 기반 정책은 별개의 정책이 아닙니다. 오히려 익명의 보안 주체를 지정한 후 특별한 Condition 요소를 추가하는 리소스 기반 정책이라고도 할 수 있습니다.

IP 기반 정책의 기본적인 특징은 Amazon ES 도메인에 대한 무서명 요청이 가능하기 때문에curlAmazon Elasticsearch Service 와 함께 Kibana 사용프록시 서버를 통해 도메인에 액세스할 수 있습니다. 자세한 내용은 프록시를 사용하여 키바나에서 Amazon ES에 액세스 단원을 참조하십시오.

참고

도메인에서 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/*" }] }

아마존 ES 요청 작성 및 서명

완전히 열려 있는 리소스 기반 액세스 정책을 구성하는 경우에도allAmazon ES 구성 API에 대한 요청에 서명해야 합니다. 또한 정책에 IAM 사용자 또는 역할을 지정하는 경우에는 Elasticsearch API에 대한 요청에도 AWS 서명 버전 4를 사용하여 서명이 필요합니다. 서명 메서드는 API에 따라 다음과 같이 다릅니다.

  • Amazon ES 구성 API를 호출할 때는AWS SDK. SDK는 프로세스를 대폭 간소화할 뿐만 아니라 사용자 자신의 요청을 생성한 후 서명을 추가할 때와 비교하여 시간을 크게 절감할 수 있습니다. 구성 API 엔드포인트는 다음 형식을 사용합니다.

    es.region.amazonaws.com/2015-01-01/

    예를 들어 다음 요청은 movies 도메인의 구성을 변경하지만, 사용자가 직접 서명해야 합니다(권장하지 않음).

    POST https://es.us-east-1.amazonaws.com/2015-01-01/es/domain/movies/config { "ElasticsearchClusterConfig": { "InstanceType": "c5.xlarge.elasticsearch" } }

    SDK 중 하나를 사용하면(예: Boto 3) SDK가 서명하여 자동으로 요청을 처리합니다.

    import boto3 client = boto3.client('es') response = client.update_elasticsearch_domain_config( DomainName='movies', ElasticsearchClusterConfig={ 'InstanceType': 'c5.xlarge.elasticsearch' } )

    Java 코드 샘플의 경우 AWS SDK를 사용하여 Amazon Elasticsearch Service 상호 작용 단원을 참조하십시오.

  • Elasticsearch API를 호출할 때는 사용자 자신의 요청에 서명이 필요합니다. 다양한 언어로 작성된 샘플 코드를 보려면 Amazon Elasticsearch Service HTTP 요청 서명 단원을 참조하십시오. Elasticsearch API는 다음 형식을 사용합니다.

    domain-id.region.es.amazonaws.com

    예를 들어 다음 요청은 movies 인덱스에서 thor를 검색합니다.

    GET https://my-domain.us-east-1.es.amazonaws.com/movies/_search?q=thor
참고

서명 버전 4로 서명된 HTTP POST 요청을 위해 URL로 전달된 파라미터는 무시됩니다.

정책이 충돌할 때

정책이 서로 일치하지 않거나 사용자를 명시적으로 지정하지 않으면 복잡한 문제가 발생합니다. IAM의 작동 방식 이해IAM 사용 설명서에서는 정책 평가 논리에 대한 간략한 요약을 제공합니다.

  • 기본적으로 모든 요청을 거부합니다.

  • 명시적 허용은 이러한 기본 설정을 무시합니다.

  • 명시적 거부는 모든 허용을 무시합니다.

예를 들어 리소스 기반 정책이 도메인 하위 리소스 (Elasticsearch 인덱스 또는 API) 에 대한 액세스 권한을 부여하지만 자격 증명 기반 정책이 액세스를 거부할 경우에는 액세스가 거부됩니다. 자격 증명 기반 정책이 액세스를 권한을 부여하고 리소스 기반 정책이 액세스 필요 여부를 지정하지 않을 경우에는 액세스가 허용됩니다. 도메인 하위 리소스에 대한 전체 요약

리소스 기반 정책에서 허용됨 리소스 기반 정책에서 거부됨 리소스 기반 정책에서 허용 및 거부되지 않음
Allowed in Identity-based Policy

허용

Deny Allow
Denied in Identity-based Policy Deny Deny Deny
Neither Allowed nor Denied in Identity-based Policy Allow Deny Deny

정책 요소 참조

Amazon ES는 대부분의 정책 요소를IAM 정책를 제외하고NotPrincipal. 다음 표에는 가장 일반적인 요소가 나와 있습니다.

JSON 정책 요소 요약
Version

정책 언어의 현재 버전은 2012-10-17입니다. 모든 액세스 정책이 이 값을 지정해야 합니다.

Effect

이 요소는 명령문이 지정한 작업에 대한 액세스를 허용 또는 거부 여부를 지정합니다. 유효한 값은 Allow 또는 Deny입니다.

Principal

이 요소는 리소스에 대한 액세스가 허용 또는 거부되는 AWS 계정이나 IAM 사용자 및 역할을 지정하며, 다음과 같이 몇 가지 형식을 따릅니다.

  • AWS 계정: "Principal":{"AWS": ["123456789012"]} 또는 "Principal":{"AWS": ["arn:aws:iam::123456789012:root"]}

  • IAM 사용자: "Principal":{"AWS": ["arn:aws:iam::123456789012:user/test-user"]}

  • IAM 역할: "Principal":{"AWS": ["arn:aws:iam::123456789012:role/test-role"]}

* 와일드카드를 지정하면 도메인에 대한 익명 액세스가 가능하므로 IP 기반 조건을 추가하거나, VPC 지원을 사용하거나, 세분화된 액세스 제어를 활성화하지 않는 한 권장되지 않습니다.

Action

Amazon ES는 HTTP 메서드에 대해 다음 작업을 사용합니다.

  • es:ESHttpDelete

  • es:ESHttpGet

  • es:ESHttpHead

  • es:ESHttpPost

  • es:ESHttpPut

  • es:ESHttpPatch

Amazon ES는 다음과 같은 작업을구성 API:

  • es:AddTags

  • es:AssociatePackage

  • es:CreateElasticsearchDomain

  • es:CreateElasticsearchServiceRole

  • es:CreatePackage

  • es:DeleteElasticsearchDomain

  • es:DeleteElasticsearchServiceRole

  • es:DeletePackage

  • es:DescribeElasticsearchDomain

  • es:DescribeElasticsearchDomainConfig

  • es:DescribeElasticsearchDomains

  • es:DescribeElasticsearchInstanceTypeLimits

  • es:DescribeReservedElasticsearchInstanceOfferings

  • es:DescribeReservedElasticsearchInstances

  • es:DissociatePackage

  • es:ESCrossClusterGet

  • es:GetCompatibleElasticsearchVersions

  • es:ListDomainNames

  • es:ListElasticsearchInstanceTypeDetails

  • es:ListElasticsearchInstanceTypes

  • es:ListElasticsearchVersions

  • es:ListTags

  • es:PurchaseReservedElasticsearchInstanceOffering

  • es:RemoveTags

  • es:UpdateElasticsearchDomainConfig

작은 정보

와일드카드를 사용하여 작업의 하위 집합을 지정하는 것도 가능합니다(예: "Action":"es:*" 또는 "Action":"es:Describe*").

일부 es: 작업은 리소스 수준 권한을 지원합니다. 예를 들어 모든 도메인이 아닌 특정 도메인 1개만 삭제할 수 있는 권한을 사용자 1명에게 부여할 수 있습니다. 그 밖의 작업은 서비스 자체에만 적용됩니다. 예를 들어 es:ListDomainNames는 단일 도메인으로 이해하지 않기 때문에 와일드카드가 필요합니다.

중요

리소스 기반 정책은 리소스 수준 권한과 다릅니다. 리소스 기반 정책은 도메인에 연결되는 모든 JSON 정책입니다. 따라서 리소스 수준 권한에서는 작업을 특정 도메인이나 하위 리소스로 제한할 수 있습니다. 실제로 리소스 수준 권한을 리소스 또는 자격 증명 기반 정책의 옵션으로 볼 수도 있습니다.

The following 자격 증명 기반 정책모든 나열es:작업을 수행하고 도메인 하위 리소스에 적용되는지 여부에 따라 그룹화합니다 (test-domain/*), 도메인 구성 (test-domain) 또는*):

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "es:ESHttpDelete", "es:ESHttpGet", "es:ESHttpHead", "es:ESHttpPost", "es:ESHttpPut", "es:ESHttpPatch" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" }, { "Effect": "Allow", "Action": [ "es:AssociatePackage", "es:CreateElasticsearchDomain", "es:DeleteElasticsearchDomain", "es:DescribeElasticsearchDomain", "es:DescribeElasticsearchDomainConfig", "es:DescribeElasticsearchDomains", "es:DissociatePackage", "es:ESCrossClusterGet", "es:GetCompatibleElasticsearchVersions", "es:UpdateElasticsearchDomainConfig" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain" }, { "Effect": "Allow", "Action": [ "es:AddTags", "es:CreateElasticsearchServiceRole", "es:CreatePackage", "es:DeleteElasticsearchServiceRole", "es:DeletePackage", "es:DescribeElasticsearchInstanceTypeLimits", "es:DescribeReservedElasticsearchInstanceOfferings", "es:DescribeReservedElasticsearchInstances", "es:ESCrossClusterGet", "es:ListDomainNames", "es:ListElasticsearchInstanceTypeDetails", "es:ListElasticsearchInstanceTypes", "es:ListElasticsearchVersions", "es:ListTags", "es:PurchaseReservedElasticsearchInstanceOffering", "es:RemoveTags" ], "Resource": "*" } ] }
참고

에 대한 리소스 수준es:CreateElasticsearchDomain가 직관적이지 않은 것처럼 보일 수 있습니다. 결국 사용자에게 이미 존재하는 도메인을 만들 수있는 권한을 부여하는 이유는 무엇입니까? — 와일드카드를 사용하여 도메인에 대해 간단한 명명 체계를 적용할 수 있습니다."Resource": "arn:aws:es:us-west-1:987654321098:domain/my-team-name-*".

물론 다음과 같이 리소스 요소의 제한을 줄여서 작업을 추가하는 것도 가능합니다.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "es:ESHttpGet", "es:DescribeElasticsearchDomain" ], "Resource": "*" } ] }

작업과 리소스의 페어링에 대한 자세한 내용은 여기 표에서 Resource 요소를 참조하십시오.

Condition

Amazon ES는사용 가능한 전역 조건 키IAM 사용 설명서. 주목할 만한 예외aws:SecureTransportaws:PrincipalTag키는 Amazon ES에서 지원하지 않습니다.

IP 기반 정책을 구성할 때는 다음과 같이 IP 주소 또는 CIDR 블록을 조건으로 지정합니다.

"Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/32" ] } }

에서 언급 한 바와 같이자격 증명 기반 정책,aws:ResourceTag,aws:RequestTag, 및aws:TagKeys조건 키는 엘라스틱 검색 API가 아닌 구성 API에만 적용됩니다.

Resource

Amazon ES는Resource는 다음과 같이 세 가지 기본적인 방법으로 요소를

  • Amazon ES 자체에 적용되는 작업 (예:es:ListDomainNames또는 모든 액세스를 허용할 때는 다음 구문을 사용하십시오.

    "Resource": "*"
  • 도메인 구성과 관련된 작업(es:DescribeElasticsearchDomain 등)일 때는 다음 구문을 사용합니다.

    "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name"
  • 도메인 하위 리소스에 적용되는 작업(es:ESHttpGet 등)일 때는 다음 구문을 사용합니다.

    "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/*"

    와일드카드를 사용할 필요가 없습니다. Amazon ES에서는 각 Elasticsearch 인덱스 또는 API에 대해 서로 다른 액세스 정책을 정의할 수 있습니다. 예를 들어 다음과 같이 사용자의 권한을 test-index 인덱스로 제한할 수도 있습니다.

    "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index"

    test-index에 대한 모든 액세스 권한 대신 검색 API만 사용하도록 정책을 제한할 수 있습니다.

    "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index/_search"

    다음과 같이 개별 문서에 대한 액세스를 제어할 수도 있습니다.

    "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index/test-type/1"

    기본적으로 Elasticsearch가 하위 리소스를 URI로 표현하는 경우에는 액세스 정책을 사용하여 액세스를 제어할 수 있습니다. 사용자가 액세스할 수 있는 리소스에 대한 한층 세부적인 제어가 필요한 경우 Amazon Elasticsearch Service 세분화된 액세스 제어 단원을 참조하십시오.

리소스 수준 권한을 지원하는 작업에 대한 자세한 내용은 여기 표에서 Action 요소를 참조하십시오.

AWS 관리형

Amazon ES에는 AWS에서 관리하는 세 가지 자격 증명 기반 IAM 정책이 있습니다. 단원을 참조하십시오.VPC 액세스를 위한 서비스 연결 역할에서 서비스 연결AWSServiceRoleForAmazonElasticsearchService) 를 사용하여 VPC 내에 도메인을 배치할 수 있습니다.

AWS 관리형 정책 설명

AmazonESFullAccess

엘라스틱 검색 API에 대한 Amazon ES 구성 API 및 모든 HTTP 메소드에 대한 전체 액세스 권한을 제공합니다. 세분화된 액세스 제어리소스 기반 정책는 여전히 액세스를 제한할 수 있습니다.

AmazonESReadOnlyAccess

Amazon ES 구성 API에 대한 읽기 전용 액세스를 제공합니다 (es:Describe*,es:List*, 및es:Get*) 및아니요엘라스틱 검색 API에 대한 HTTP 메소드에 대한 액세스를 제공합니다.

AmazonESCognitoAccess

활성화하는 데 필요한 최소 Amazon Cognito 권한을 제공합니다.Kibana에 대한 Amazon Cognito 인증 구성.

고급 옵션 및 API 고려 사항

Amazon ES에는 몇 가지 고급 옵션이 있으며, 그 중 하나인 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및 엘라스틱 검색 대량 API를 사용합니다. 또한 GET에 대한 restricted-index 요청도 허용합니다.

예상할 수 있겠지만 다음 인덱싱 요청은 권한 오류로 인해 실패할 수 밖에 없습니다.

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이 아닌 요청 본문에 지정하는 경우가 많습니다. Amazon ES는 URL을 사용하여 도메인 하위 리소스에 대한 액세스를 제어하기 때문에test-user실제로 는 대량 API를 사용하여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일 경우에는 요청 본문에서 인덱스 이름을 지정하는 대량, mget 및 msearch API 호출이 모두 중단됩니다. 다시 말해서 _bulk 호출은 더 이상 유효하지 않지만 test-index/_bulk 호출은 유효합니다. 이 두 번째 엔드포인트에 인덱스 이름이 포함되기 때문에 요청 본문에 이름을 지정할 필요가 없습니다.

Kibana는 mget 및 msearch에 대한 의존도가 크기 때문에 위와 같은 변경 이후 정상적으로 실행될 가능성이 거의 없습니다. 이러한 문제를 부분적으로 해결하고 싶다면 rest.action.multi.allow_explicit_index를 true로 남겨두고 하나 이상의 mget 및 msearch API에 대한 일부 사용자 액세스를 거부하는 방법도 있습니다.

이 설정의 변경에 대한 자세한 내용은 다음(고급 옵션 선택 사항)을 참조하십시오.

마찬가지로 다음 리소스 기반 정책 역시 두 가지 미묘한 문제가 있습니다.

{ "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/_searchGET https://search-test-domain.us-west-1.es.amazonaws.com/*/_search 같은 호출을 통해 restricted-index의 문서에 액세스할 수 있습니다.

  • Resource 요소가 restricted-index/*를 참조하기 때문에 test-user는 인덱스의 문서에 직접 액세스할 수 있는 권한이 없습니다. 하지만 사용자에게 전체 인덱스를 삭제할 권한은 있습니다. 이러한 액세스 및 삭제 문제를 방지하려면 정책에 restricted-index*를 지정해야 합니다.

광범위한 액세스 허용과 집약적 액세스 거부를 혼합할 바에는 최소 권한 원칙을 따라 작업에 필요한 권한만 부여하는 것이 가장 안전한 방법입니다. 개별 인덱스 또는 Elasticsearch 작업에 대한 액세스를 제어하는 방법에 대한 자세한 내용은Amazon Elasticsearch Service 세분화된 액세스 제어.

Configuring access policies

  • Amazon ES에서 리소스 및 IP 기반 정책을 생성하거나 수정하는 방법에 대한 자세한 내용은 단원을 참조하십시오.액세스 정책 구성 중.

  • IAM에서 자격 증명 기반 정책을 생성하거나 수정하는 방법에 대한 자세한 내용은 단원을 참조하십시오.IAM 정책IAM 사용 설명서.

추가 정책

이번 단원에 다수의 샘플 정책이 포함되어 있지만 AWS 액세스 제어는 복잡한 주제이기 때문에 예제를 통해 이해의 폭을 최대한 넓혀야 합니다. 자세한 내용은 단원을 참조하십시오.정책 예제IAM 사용 설명서.