Amazon OpenSearch Service의 Identity and Access Management

Amazon OpenSearch Service는 도메인에 대한 액세스를 제어하는 여러 가지 방법을 제공합니다. 이 주제에서는 다양한 정책 유형과 정책 유형 사이의 상호 작용 방식, 그리고 사용자 지정 정책을 생성하는 방법에 대해서 살펴보겠습니다.

정책 유형

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

리소스 기반 정책

도메인을 생성할 때 도메인 액세스 정책이라고도 하는 리소스 기반 정책을 추가합니다. 이 정책은 보안 주체가 도메인의 하위 리소스에서 실행할 수 있는 작업을 지정합니다(클러스터 간 검색 제외). 하위 리소스에는 OpenSearch 인덱스 및 API가 있습니다. 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/*"
    }
  ]
}

이 정책에는 다음과 같이 두 가지 중요한 고려 사항이 있습니다.

와일드카드를 추가하여 부분 인덱스 이름을 지정할 수 있습니다. 이 예시는 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이(가) 문서를 추가하거나 수정하는 것은 제한됩니다.

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

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

가능한 작업에 대한 자세한 내용은 정책 요소 참조 섹션을 참조하세요. 데이터를 훨씬 더 세밀하게 제어하려면 세분화된 액세스 제어와 함께 개방형 도메인 액세스 정책을 사용합니다.

보안 인증 기반 정책

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

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

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

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

관리자는 OpenSearch Service 및 모든 도메인에 저장된 모든 데이터에 대한 전체 액세스 권한을 가지고 있을 수 있습니다.

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

자격 증명 기반 정책을 사용하면 태그를 사용하여 구성 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 메서드에만 적용됩니다. 예를 들어, 도메인에 environment:production 태그가 있을 경우 다음 정책은 연결된 보안 주체가 OpenSearch API에 GET 및 PUT 요청을 보낼 수 있도록 합니다.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Action": [
      "es:ESHttpGet",
      "es:ESHttpPut"
    ],
    "Effect": "Allow",
    "Resource": "*",
    "Condition": {
      "ForAnyValue:StringEquals": {
        "aws:ResourceTag/environment": [
          "production"
        ]
      }
    }
  }]
}

OpenSearch API를 보다 세부적으로 제어하려면 세분화된 액세스 제어 사용을 고려하세요.

OpenSearch Service는 OpenSearch API가 아닌 구성 API에 대한 RequestTag 및 TagKeys 전역 조건 키를 지원합니다. 이러한 조건은 CreateDomain, AddTags, RemoveTags와 같은 요청 내에 태그를 포함하는 API 직접 호출에만 적용됩니다. 다음 정책을 사용하면 연결된 보안 주체가 도메인을 생성할 수 있지만 요청에 team:it 태그를 포함하는 경우에만 해당합니다.

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

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

IP 기반 정책

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

IP 기반 정책의 기본적인 이점은 OpenSearch Service 도메인에 대한 무서명 요청이 가능하기 때문에 curl 및 OpenSearch Dashboards 같은 클라이언트를 사용하거나 프록시 서버를 통해 도메인에 액세스할 수 있다는 점입니다. 자세한 내용은 프록시를 사용하여 대시보드에서 OpenSearch 서비스에 액세스 섹션을 참조하세요.

다음은 지정된 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/*"
  }]
}

정책 충돌 시

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

예를 들어 리소스 기반 정책이 도메인 하위 리소스(OpenSearch 인덱스 또는 API)에 대한 액세스 권한을 부여하지만 자격 증명 기반 정책이 액세스를 거부할 경우에는 액세스가 거부됩니다. 자격 증명 기반 정책이 액세스를 권한을 부여하고 리소스 기반 정책이 액세스 필요 여부를 지정하지 않을 경우에는 액세스가 허용됩니다. 정책이 서로 엇갈렸을 때 도메인 하위 리소스에 대한 결과는 아래 요약 표를 참조하세요.

정책 요소 참조

OpenSearch Service는 NotPrincipal을 제외하고 IAM 정책 요소 참조에 포함된 대부분의 정책 요소를 지원합니다. 다음 표에는 가장 일반적인 요소가 나와 있습니다.

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

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

고급 옵션 및 API 고려 사항

OpenSearch Service에는 몇 가지 고급 옵션이 있으며, 그 중 하나인 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 Service는 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 호출은 유효합니다. 이 두 번째 엔드포인트에 인덱스 이름이 포함되기 때문에 요청 본문에 이름을 지정할 필요가 없습니다.

OpenSearch Dashboards는 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/*"
    }
  ]
}

광범위한 액세스 허용과 집약적 액세스 거부를 혼합하기보다 최소 권한 원칙을 따라 태스크에 필요한 권한만 부여하는 것이 가장 안전한 방법입니다. 개별 인덱스 또는 OpenSearch 작업에 대한 액세스 제어와 관련된 자세한 내용은 Amazon OpenSearch Service에서 세분화된 액세스 제어을(를) 참조하세요.

액세스 정책 구성

추가 샘플 정책

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