기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
Elasticsearch용 Security Hub
이러한 AWS Security Hub 제어는 Elasticsearch 서비스 및 리소스를 평가합니다.
이러한 제어는 일부 에서 사용하지 못할 수 있습니다 AWS 리전. 자세한 내용은 리전별 제어 기능 사용 가능 여부 단원을 참조하십시오.
[ES.1] Elasticsearch 도메인에는 저장 시 암호화가 활성화되어 있어야 합니다.
관련 요구 사항: PCI DSS v3.2.1/3.4, NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6)
범주: 보호 > 데이터 보호 > 암호화 data-at-rest
심각도: 중간
리소스 유형: AWS::Elasticsearch::Domain
AWS Config 규칙: elasticsearch-encrypted-at-rest
스케줄 유형: 주기적
파라미터: 없음
이 제어는 Elasticsearch 도메인에 저장 시 암호화 구성이 활성화되어 있는지 확인합니다. 유휴 시 암호화가 활성화되지 않은 경우 이 확인이 실패합니다.
에서 민감한 데이터에 대한 보안 계층을 추가하려면 저장 시 암호화 OpenSearch 되도록 를 구성해야 OpenSearch합니다. Elasticsearch 도메인은 저장 데이터 암호화를 제공합니다. 이 기능은 AWS KMS 를 사용하여 암호화 키를 저장하고 관리합니다. 암호화를 수행하기 위해 256비트 키(AES-256)가 있는 고급 암호화 표준 알고리즘을 사용합니다.
저장 데이터 OpenSearch 암호화에 대한 자세한 내용은 Amazon OpenSearch Service 개발자 안내서의 Amazon Service에 대한 저장 데이터 암호화를 참조하세요. OpenSearch
t.small
및 t.medium
등의 특정 인스턴스 유형은 저장 데이터의 암호화를 지원하지 않습니다. 자세한 내용은 Amazon OpenSearch Service 개발자 안내서의 지원되는 인스턴스 유형을 참조하세요.
이제 Security Hub가 와 통합되었습니다
새 Elasticsearch 도메인과 기존 Elasticsearch 도메인에 대해 유휴 데이터 암호화를 활성화하려면 Amazon OpenSearch Service 개발자 안내서의 유휴 데이터 암호화 활성화를 참조하세요.
[ES.2] Elasticsearch 도메인은 공개적으로 액세스할 수 없어야 합니다.
관련 요구 사항: PCI DSS v3.2.1/1.2.1,PCI DSS v3.2.1/1.3.1,PCI DSS v3.2.1/1.3.2,PCI DSS v3.2.1/1.3.4,PCI DSS v3.2.1/1.3.6, NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6 NIST.800-53.r5 SC-7,, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9)
범주: 보호 > 보안 네트워크 구성 > 내 리소스 VPC
심각도: 심각
리소스 유형: AWS::Elasticsearch::Domain
AWS Config 규칙: elasticsearch-in-vpc-only
스케줄 유형: 주기적
파라미터: 없음
이 제어는 Elasticsearch 도메인이 에 있는지 확인합니다VPC. 퍼블릭 액세스를 결정하기 위해 VPC 서브넷 라우팅 구성을 평가하지는 않습니다. Elasticsearch 도메인이 퍼블릭 서브넷에 연결되어 있지 않은지 확인해야 합니다. Amazon OpenSearch Service 개발자 안내서의 리소스 기반 정책을 참조하세요. 또한 권장 모범 사례에 따라 가 구성VPC되었는지 확인해야 합니다. Amazon VPC 사용 설명서의 에 대한 보안 모범 사례를 VPC 참조하세요.
에 배포된 Elasticsearch 도메인VPC은 퍼블릭 인터넷을 통과할 필요 없이 프라이빗 AWS 네트워크를 통해 VPC 리소스와 통신할 수 있습니다. 이 구성은 전송 중 데이터에 대한 액세스를 제한하여 보안 상태를 강화합니다. VPCs 는 네트워크 ACL 및 보안 그룹을 포함하여 Elasticsearch 도메인에 대한 액세스를 보호하기 위한 여러 네트워크 제어를 제공합니다. Security Hub는 이러한 제어를 활용VPCs하려면 퍼블릭 Elasticsearch 도메인을 로 마이그레이션하는 것이 좋습니다.
이제 Security Hub가 와 통합되었습니다
퍼블릭 엔드포인트가 있는 도메인을 생성하는 경우 나중에 에 배치할 수 없습니다VPC. 대신에 새 도메인을 만들어 데이터를 마이그레이션해야 합니다. 반대의 경우도 마찬가지입니다. 내에서 도메인을 생성하는 경우 퍼블릭 엔드포인트가 있을 VPC수 없습니다. 대신 다른 도메인을 만들거나 이 제어를 비활성화해야 합니다.
Amazon OpenSearch Service 개발자 안내서의 에서 Amazon Service 도메인 시작VPC을 참조하세요. OpenSearch
[ES.3] Elasticsearch 도메인은 노드 간에 전송되는 데이터를 암호화해야 합니다.
관련 요구 사항: NIST.800-53.r5 AC-4, NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2)
범주: 보호 > 데이터 보호 > 암호화 data-in-transit
심각도: 중간
리소스 유형: AWS::Elasticsearch::Domain
AWS Config 규칙: elasticsearch-node-to-node-encryption-check
스케줄 유형: 변경이 트리거됨
파라미터: 없음
이 제어는 Elasticsearch 도메인에 암호화가 node-to-node 활성화되어 있는지 확인합니다. Elasticsearch 도메인에 암호화가 활성화되지 않은 경우 제어가 node-to-node 실패합니다. Elasticsearch 버전이 암호화 검사를 지원하지 node-to-node 않는 경우에도 제어는 실패한 결과를 생성합니다.
HTTPS (TLS)를 사용하면 잠재적 공격자가 또는 유사한 공격을 사용하여 person-in-the-middle 네트워크 트래픽을 도청하거나 조작하는 것을 방지할 수 있습니다. HTTPS (TLS)를 통한 암호화된 연결만 허용해야 합니다. Elasticsearch 도메인에 암호화를 활성화 node-to-node하면 클러스터 내 통신이 전송 중에 암호화됩니다.
이 구성과 관련하여 성능이 저하될 수 있습니다. 이 옵션을 활성화하기 전에 성능 균형을 파악하고 테스트해야 합니다.
이제 Security Hub가 와 통합되었습니다
새 도메인과 기존 도메인에서 암호화를 활성화 node-to-node하는 방법에 대한 자세한 내용은 Amazon OpenSearch Service 개발자 안내서의 암호화 활성화 node-to-node를 참조하세요.
[ES.4] CloudWatch Logs에 대한 Elasticsearch 도메인 오류 로깅을 활성화해야 합니다.
관련 요구 사항: NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8)
범주: 식별 - 로깅
심각도: 중간
리소스 유형: AWS::Elasticsearch::Domain
AWS Config 규칙: elasticsearch-logs-to-cloudwatch
스케줄 유형: 변경이 트리거됨
파라미터:
-
logtype = 'error'
(사용자 지정할 수 없음)
이 제어는 Elasticsearch 도메인이 CloudWatch 로그에 오류 로그를 보내도록 구성되어 있는지 확인합니다.
Elasticsearch 도메인에 대한 오류 로그를 활성화하고 보존 및 응답을 위해 CloudWatch 로그로 해당 로그를 보내야 합니다. 도메인 오류 로그는 보안 및 액세스 감사에 도움이 되며 가용성 문제를 진단하는 데 도움이 될 수 있습니다.
이제 Security Hub가 와 통합되었습니다
로그 게시를 활성화하는 방법에 대한 자세한 내용은 Amazon OpenSearch Service 개발자 안내서의 로그 게시 활성화(콘솔)를 참조하세요.
[ES.5] Elasticsearch 도메인에는 감사 로깅이 활성화되어 있어야 합니다.
관련 요구 사항: NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8)
범주: 식별 > 로깅
심각도: 중간
리소스 유형: AWS::Elasticsearch::Domain
AWS Config 규칙: elasticsearch-audit-logging-enabled
(사용자 지정 Security Hub 규칙)
스케줄 유형: 변경이 트리거됨
파라미터:
-
cloudWatchLogsLogGroupArnList
(사용자 지정할 수 없음). Security Hub는 이 파라미터를 채우지 않습니다. 감사 로그에 대해 구성해야 하는 CloudWatch 로그 로그 그룹의 쉼표로 구분된 목록입니다.이 규칙은 Elasticsearch 도메인의 CloudWatch 로그 로그 그룹이 이 파라미터 목록에 지정되지 않은
NON_COMPLIANT
경우 적용됩니다.
이 제어는 Elasticsearch 도메인에 감사 로깅이 활성화되어 있는지 여부를 확인합니다. Elasticsearch 도메인에 감사 로깅이 활성화되어 있지 않으면 이 제어가 실패합니다.
감사 로그는 고도로 사용자 지정이 가능합니다. 이를 통해 인증 성공 및 실패, 에 대한 요청, OpenSearch인덱스 변경 및 수신 검색 쿼리를 포함하여 Elasticsearch 클러스터의 사용자 활동을 추적할 수 있습니다.
이제 Security Hub가 와 통합되었습니다
감사 로그 활성화에 대한 자세한 지침은 Amazon OpenSearch Service 개발자 안내서의 감사 로그 활성화를 참조하세요.
[ES.6] Elasticsearch 도메인에는 최소 세 개의 데이터 노드가 있어야 합니다.
관련 요구 사항: NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)
범주: 복구 > 복원력 > 고가용성
심각도: 중간
리소스 유형: AWS::Elasticsearch::Domain
AWS Config 규칙: elasticsearch-data-node-fault-tolerance
(사용자 지정 Security Hub 규칙)
스케줄 유형: 변경이 트리거됨
파라미터: 없음
이 제어는 Elasticsearch 도메인이 최소 세 개의 데이터 노드로 구성되어 있고 zoneAwarenessEnabled
이 true
인지 확인합니다.
Elasticsearch 도메인에는 고가용성 및 내결함성을 위해 최소 3개의 데이터 노드가 필요합니다. 최소 3개의 데이터 노드가 있는 Elasticsearch 도메인을 배포하면 노드에 장애가 발생하더라도 클러스터 운영이 보장됩니다.
이제 Security Hub가 와 통합되었습니다
Elasticsearch 도메인의 데이터 노드 수를 수정하려면
에서 Amazon OpenSearch Service 콘솔을 엽니다https://console.aws.amazon.com/aos/
. -
도메인에서 편집하려는 도메인의 이름을 선택합니다.
-
도메인 편집을 선택합니다.
-
데이터 노드에서 노드 수를
3
이상의 수로 설정합니다.3개의 가용 영역 배포의 경우 가용 영역 전체에 균등하게 배포되도록 3의 배수로 설정합니다.
-
제출을 선택합니다.
[ES.7] Elasticsearch 도메인은 최소 3개의 전용 프라이머리 노드로 구성해야 합니다.
관련 요구 사항: NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)
범주: 복구 > 복원력 > 고가용성
심각도: 중간
리소스 유형: AWS::Elasticsearch::Domain
AWS Config규칙: elasticsearch-primary-node-fault-tolerance
(사용자 지정 Security Hub 규칙)
스케줄 유형: 변경이 트리거됨
파라미터: 없음
이 제어는 Elasticsearch 도메인이 최소 3개의 전용 기본 노드로 구성되어 있는지 확인합니다. 도메인이 전용 기본 노드를 사용하지 않으면 이 제어가 실패합니다. 이 제어는 Elasticsearch 도메인에 5개의 전용 기본 노드가 있는 경우 전달됩니다. 그러나 가용성 위험을 완화하기 위해 3개 이상의 프라이머리 노드를 사용하지 않아도 될 수 있으며, 이로 인해 추가 비용이 발생할 수 있습니다.
Elasticsearch 도메인에는 고가용성과 내결함성을 위해 최소 3개의 전용 프라이머리 노드가 필요합니다. 관리할 추가 노드가 있으므로 데이터 노드 블루/그린 배포 중에 전용 프라이머리 노드 리소스에 부담을 줄 수 있습니다. 전용 프라이머리 노드가 3개 이상인 Elasticsearch 도메인을 배포하면 노드가 실패할 경우 충분한 프라이머리 노드 리소스 용량과 클러스터 작업을 보장할 수 있습니다.
이제 Security Hub가 와 통합되었습니다
OpenSearch 도메인의 전용 기본 노드 수를 수정하려면
에서 Amazon OpenSearch Service 콘솔을 엽니다https://console.aws.amazon.com/aos/
. -
도메인에서 편집하려는 도메인의 이름을 선택합니다.
-
도메인 편집을 선택합니다.
-
전용 프라이머리 노드에서 인스턴스 유형을 원하는 인스턴스 유형으로 설정합니다.
-
프라이머리 노드 수를 3개 이상으로 설정합니다.
-
제출을 선택합니다.
[ES.8] Elasticsearch 도메인에 대한 연결은 최신 TLS 보안 정책을 사용하여 암호화해야 합니다.
관련 요구 사항: NIST.800-53.r5 AC-17(2), NIST.800-53.r5 AC-4, NIST.800-53.r5 IA-5(1), NIST.800-53.r5 SC-12(3), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), NIST.800-53.r5 SI-7(6)
범주: 보호 > 데이터 보호 > 암호화 data-in-transit
심각도: 중간
리소스 유형: AWS::Elasticsearch::Domain
AWS Config 규칙: elasticsearch-https-required
(사용자 지정 Security Hub 규칙)
스케줄 유형: 변경이 트리거됨
파라미터: 없음
이 제어는 Elasticsearch 도메인 엔드포인트가 최신 TLS 보안 정책을 사용하도록 구성되어 있는지 확인합니다. Elasticsearch 도메인 엔드포인트가 지원되는 최신 정책을 사용하도록 구성되지 않았거나 가 활성화되지 않은 경우 제어HTTPs가 실패합니다. 현재 지원되는 최신 TLS 보안 정책은 입니다Policy-Min-TLS-1-2-PFS-2023-10
.
HTTPS (TLS)를 사용하면 잠재적 공격자가 또는 유사한 공격을 사용하여 person-in-the-middle 네트워크 트래픽을 도청하거나 조작하는 것을 방지할 수 있습니다. HTTPS (TLS)를 통한 암호화된 연결만 허용해야 합니다. 전송 중 데이터를 암호화하면 성능에 영향을 미칠 수 있습니다. 이 기능으로 애플리케이션을 테스트하여 성능 프로파일과 의 영향을 이해해야 합니다TLS. TLS 1.2는 이전 버전의 에 비해 몇 가지 보안 개선 사항을 제공합니다TLS.
이제 Security Hub가 와 통합되었습니다
TLS 암호화를 활성화하려면 UpdateDomainConfig API 를 구성하는 작업 DomainEndpointOptions 객체. 이렇게 하면 가 설정됩니다TLSSecurityPolicy
.
[ES.9] Elasticsearch 도메인에 태그를 지정해야 합니다.
범주: 식별 > 인벤토리 > 태깅
심각도: 낮음
리소스 유형: AWS::Elasticsearch::Domain
AWS Config 규칙: tagged-elasticsearch-domain
(사용자 지정 Security Hub 규칙)
스케줄 유형: 변경이 트리거됨
파라미터:
파라미터 | 설명 | 형식 | 허용된 사용자 지정 값 | Security Hub 기본값 |
---|---|---|---|---|
requiredTagKeys
|
평가된 리소스에 포함되어야 하는 비시스템 태그 키 목록입니다. 태그 키는 대소문자를 구별합니다. | StringList | AWS 요구 사항을 충족하는 태그 목록 |
No default value
|
이 제어는 Elasticsearch 도메인에 파라미터 에 정의된 특정 키가 있는 태그가 있는지 확인합니다requiredTagKeys
. 도메인에 태그 키가 없거나 파라미터 에 지정된 모든 키가 없는 경우 제어가 실패합니다requiredTagKeys
. 파라미터requiredTagKeys
가 제공되지 않으면 제어는 태그 키의 존재만 확인하고 도메인에 키로 태그가 지정되지 않은 경우 실패합니다. 자동으로 적용되고 로 시작하는 시스템 태그aws:
는 무시됩니다.
태그는 AWS 리소스에 할당하는 레이블이며 키와 선택적 값으로 구성됩니다. 태그를 생성하여 용도, 소유자, 환경 또는 기타 기준으로 리소스를 분류할 수 있습니다. 태그는 리소스를 식별, 구성, 검색 및 필터링하는 데 도움이 될 수 있습니다. 태그 지정은 작업 및 알림에 대한 책임 리소스 소유자를 추적하는 데도 도움이 됩니다. 태그 지정을 사용하는 경우 속성 기반 액세스 제어(ABAC)를 태그를 기반으로 권한을 정의하는 권한 부여 전략으로 구현할 수 있습니다. IAM 엔터티(사용자 또는 역할) 및 AWS 리소스에 태그를 연결할 수 있습니다. 보안 IAM 주체에 대해 단일 ABAC 정책 또는 별도의 정책 세트를 생성할 수 있습니다. 보안 주체의 태그가 리소스 태그와 일치할 때 작업을 허용하도록 이러한 ABAC 정책을 설계할 수 있습니다. 자세한 내용은 IAM 사용 설명서AWS의 에 ABAC 대한 정의 를 참조하세요.
참고
태그에 개인 식별 정보(PII) 또는 기타 기밀 또는 민감한 정보를 추가하지 마세요. 태그는 를 AWS 서비스포함한 많은 에서 액세스할 수 있습니다 AWS Billing. 태그 지정 모범 사례에 대한 자세한 내용은 의 AWS 리소스 태그 지정을 참조하세요AWS 일반 참조.
이제 Security Hub가 와 통합되었습니다
Elasticsearch 도메인에 태그를 추가하려면 Amazon OpenSearch Service 개발자 안내서의 태그 작업을 참조하세요.