Amazon ECS의 Security Hub 제어

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

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

이러한 Security Hub 제어는 Amazon Elastic Container Service(Amazon ECS) 서비스 및 리소스를 평가합니다.

이러한 제어는 일부만 사용할 수 있습니다 AWS 리전. 자세한 내용은 리전별 제어 기능 사용 가능 여부 단원을 참조하십시오.

[ECS.1] Amazon ECS 작업 정의에는 보안 네트워킹 모드와 사용자 정의가 있어야 합니다.

관련 요구 사항: NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-5, NIST.800-53.r5 AC-6

범주: 보호 > 보안 액세스 관리

심각도: 높음

리소스 유형: AWS::ECS::TaskDefinition

AWS Config 규칙: ecs-task-definition-user-for-host-mode-check

스케줄 유형: 변경이 트리거됨

파라미터:

이 제어는 호스트 네트워킹 모드를 사용하는 활성 Amazon ECS 작업 정의에 privileged 또는 user 컨테이너 정의가 있는지 확인합니다. 호스트 네트워크 모드가 있는 작업 정의와 privileged=false , 비어 있음 및 user=root, 또는 비어 있는 컨테이너 정의에 대한 제어가 실패합니다.

이 제어는 Amazon ECS 작업 정의의 최신 활성 개정만 평가합니다.

이 제어의 목적은 호스트 네트워크 모드를 사용하는 작업을 실행할 때 액세스가 의도적으로 정의되도록 하는 것입니다. 작업 정의에 상승된 권한이 있는 것은 해당 구성을 선택했기 때문입니다. 이 제어는 태스크 정의에 호스트 네트워킹이 활성화되어 있고 사용자가 상승된 권한을 선택하지 않은 경우, 예기치 않은 권한 상승을 확인합니다.

문제 해결

태스크 정의를 업데이트하는 방법에 대한 자세한 내용은 Amazon Elastic Container Service 개발자 안내서의 작업 정의 업데이트를 참조하세요.

작업 정의를 업데이트하면 이전 작업 정의에서 시작된 실행 중인 작업은 업데이트되지 않습니다. 실행 중인 작업을 업데이트하려면 새로운 작업 정의를 사용하여 작업을 재배포해야 합니다.

[ECS.2] ECS 서비스에 퍼블릭 IP 주소가 자동으로 할당되어서는 안 됩니다.

관련 요구 사항: 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 NIST.800-53.r5 SC-75 NIST.800-53.r5 SC-7 NIST.800-53.r5 SC-7

범주: 보호 > 보안 네트워크 구성 > 공개적으로 액세스할 수 없는 리소스

심각도: 높음

리소스 유형: AWS::ECS::Service

AWS Config규칙: ecs-service-assign-public-ip-disabled (사용자 지정 Security Hub 규칙)

스케줄 유형: 변경이 트리거됨

파라미터: 없음

이 제어는 Amazon ECS 서비스가 퍼블릭 IP 주소를 자동으로 할당하도록 구성되었는지 여부를 확인합니다. 이 제어는 AssignPublicIP가 ENABLED인 경우, 실패합니다. 이 제어는 AssignPublicIP가 DISABLED인 경우, 통과됩니다.

퍼블릭 IP 주소는 인터넷을 통해 연결할 수 있는 IPv 주소입니다. 퍼블릭 IP 주소로 Amazon ECS 인스턴스를 시작하면 인터넷에서 Amazon ECS 인스턴스에 연결할 수 있습니다. Amazon ECS 서비스는 공개적으로 액세스할 수 없어야 합니다. 이렇게 하면 컨테이너 애플리케이션 서버에 의도하지 않은 액세스가 허용될 수 있기 때문입니다.

문제 해결

먼저 awsvpc 네트워크 모드를 사용하고 requiresCompatibilities에 대해 FARGATE을 지정하는 클러스터에 대한 작업 정의를 생성해야 합니다. 그런 다음 컴퓨팅 구성에서 시작 유형 및 FARGATE를 선택합니다. 마지막으로 네트워킹 필드에서 퍼블릭 IP를 꺼서 서비스에 대한 자동 퍼블릭 IP 할당을 비활성화합니다.

[ECS.3] ECS 작업 정의는 호스트의 프로세스 네임스페이스를 공유해서는 안 됩니다.

관련 요구 사항: NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2

범주: 식별 > 리소스 구성

심각도: 높음

리소스 유형: AWS::ECS::TaskDefinition

AWS Config규칙: ecs-task-definition-pid-mode-check

스케줄 유형: 변경이 트리거됨

파라미터: 없음

이 제어는 Amazon ECS 작업 정의가 호스트의 프로세스 네임스페이스를 컨테이너와 공유하도록 구성되어 있는지 확인합니다. 태스크 정의가 호스트의 프로세스 네임스페이스를 호스트에서 실행되는 컨테이너와 공유하면 제어가 실패합니다. 이 제어는 Amazon ECS 작업 정의의 최신 활성 개정만 평가합니다.

프로세스 ID(PID) 네임스페이스는 프로세스 간 분리를 제공합니다. 시스템 프로세스가표시되는 것을 방지하고 PID 1을 포함한 PID를 재사용할 수 있습니다. 호스트의 PID 네임스페이스를 컨테이너와 공유하면 컨테이너는 호스트 시스템의 모든 프로세스를 볼 수 있습니다. 이렇게 하면 호스트와 컨테이너 간의 프로세스 수준 격리의 이점이 줄어듭니다. 이러한 상황에서는 프로세스를 조작하고 종료하는 기능을 포함하여 호스트 자체에 있는 프로세스에 대한 무단 액세스가 발생할 수 있습니다. 고객은 호스트의 프로세스 네임스페이스를 호스트에서 실행되는 컨테이너와 공유해서는 안 됩니다.

문제 해결

태스크 정의에 대해 pidMode를 구성하려면 Amazon Elastic Container Service 개발자 안내서의 태스크 정의 파라미터를 참조하세요.

[ECS.4] ECS 컨테이너는 권한이 없는 상태로 실행해야 합니다.

관련 요구 사항: NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-5, NIST.800-53.r5 AC-6

범주: 보호 > 보안 액세스 관리 > 루트 사용자 액세스 제한

심각도: 높음

리소스 유형: AWS::ECS::TaskDefinition

AWS Config규칙: ecs-containers-nonprivileged

스케줄 유형: 변경이 트리거됨

파라미터: 없음

이 제어는 Amazon ECS 태스크 정의의 컨테이너 정의에 있는 privileged 파라미터가 true로 설정되어 있는지 확인합니다. 이 파라미터가 true과 같으면 제어가 실패합니다. 이 제어는 Amazon ECS 작업 정의의 최신 활성 개정만 평가합니다.

ECS 태스크 정의에서 상승된 권한을 제거하는 것이 좋습니다. 권한 파라미터가 true인 경우, 컨테이너는 호스트 컨테이너 인스턴스에 대해 상승된 권한을 부여받습니다(루트 사용자와 비슷함).

문제 해결

태스크 정의에 대한 privileged 파라미터를 구성하려면 Amazon Elastic Container Service 개발자 안내서의 고급 컨테이너 정의 파라미터를 참조하세요.

[ECS.5] ECS 컨테이너는 루트 파일 시스템에 대한 읽기 전용 액세스로 제한되어야 합니다.

관련 요구 사항: NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-5, NIST.800-53.r5 AC-6

범주: 보호 > 보안 액세스 관리

심각도: 높음

리소스 유형: AWS::ECS::TaskDefinition

AWS Config규칙: ecs-containers-readonly-access

스케줄 유형: 변경이 트리거됨

파라미터: 없음

이 제어는 Amazon ECS 컨테이너가 마운트된 루트 파일 시스템에 대한 읽기 전용 액세스로 제한되는지 확인합니다. readonlyRootFilesystem 파라미터가 false로 설정되거나 파라미터가 작업 정의 내 컨테이너 정의에 없는 경우, 제어가 실패합니다. 이 제어는 Amazon ECS 작업 정의의 최신 활성 개정만 평가합니다.

이 옵션을 활성화하면 파일 시스템 폴더 및 디렉터리에 대한 명시적인 읽기-쓰기 권한이 없는 한 컨테이너 인스턴스의 파일 시스템을 조작하거나 쓸 수 없으므로 보안 공격 벡터가 줄어듭니다. 이 제어는 또한 최소 권한 원칙을 준수합니다.

문제 해결

[ECS.8] 암호는 컨테이너 환경 변수로 전달되어서는 안 됩니다.

관련 요구 사항: NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, PCI DSS v4.0.1/8.6.2

범주: 보호 > 보안 개발 > 하드 코딩되지 않은 보안 인증

심각도: 높음

리소스 유형: AWS::ECS::TaskDefinition

AWS Config규칙: ecs-no-environment-secrets

스케줄 유형: 변경이 트리거됨

파라미터:

이 제어는 컨테이너 정의의 environment 파라미터에 있는 변수의 키 값에 AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY 또는 ECS_ENGINE_AUTH_DATA가 포함되어 있는지 확인합니다. 컨테이너 정의의 단일 환경 변수가 AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY 또는 ECS_ENGINE_AUTH_DATA와 같으면 이 제어가 실패합니다. 이 제어에는 Amazon S3와 같은 다른 위치에서 전달된 환경 변수는 포함되지 않습니다. 이 제어는 Amazon ECS 작업 정의의 최신 활성 개정만 평가합니다.

AWS Systems Manager Parameter Store는 조직의 보안 태세를 개선하는 데 도움이 될 수 있습니다. 암호와 보안 인증을 컨테이너 인스턴스로 직접 전달하거나 코드에 하드 코딩하는 대신 Parameter Store를 사용하여 암호와 보안 인증을 저장하는 것이 좋습니다.

문제 해결

SSM을 사용하여 파라미터를 생성하려면 AWS Systems Manager 사용 설명서의 Systems Manager 파라미터 생성을 참조하세요. 암호를 지정하는 작업 정의 생성에 대한 자세한 내용은 Amazon Elastic Container Service 개발자 안내서의 Secrets Manager를 사용하여 중요한 데이터 지정을 참조하세요.

[ECS.9] ECS 작업 정의에는 로깅 구성이 있어야 합니다.

관련 요구 사항: NIST.800-53.r5 AC-4(26), 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-7(8)

범주: 식별 > 로깅

심각도: 높음

리소스 유형: AWS::ECS::TaskDefinition

AWS Config규칙: ecs-task-definition-log-configuration

스케줄 유형: 변경이 트리거됨

파라미터: 없음

이 제어 최신 활성 Amazon ECS 작업 정의에 로깅 구성이 지정되어 있는지 확인합니다. 작업 정의에 정의된 logConfiguration 속성이 없거나 하나 이상의 컨테이너 정의에서 logDriver의 값이 null인 경우, 제어가 실패합니다.

로깅은 Amazon ECS의 안정성, 가용성 및 성능을 유지하는 데 도움이 됩니다. 작업 정의에서 데이터를 수집하면 가시성이 제공되므로 프로세스를 디버깅하고 오류의 근본 원인을 찾는 데 도움이 됩니다. ECS 작업 정의에 정의할 필요가 없는 로깅 솔루션(예: 타사 로깅 솔루션)을 사용하는 경우, 로그가 제대로 캡처되고 전달되었는지 확인한 후 이 제어를 비활성화할 수 있습니다.

문제 해결

Amazon ECS 작업 정의의 로그 구성을 정의하려면 Amazon Elastic Container Service 개발자 안내서의 작업 정의에 로그 구성 지정을 참조하세요.

[ECS.10] ECS Fargate 서비스는 최신 Fargate 플랫폼 버전에서 실행되어야 합니다.

관련 요구 사항: NIST.800-53.r5 SI-2, NIST.800-53.r5 SI-2(2), NIST.800-53.r5 SI-2(4), NIST.800-53.r5 SI-2(5), PCI DSS v4.0.1/6.3.3

범주: 식별 > 취약성, 패치 및 버전 관리

심각도: 중간

리소스 유형: AWS::ECS::Service

AWS Config규칙: ecs-fargate-latest-platform-version

스케줄 유형: 변경이 트리거됨

파라미터:

이 제어는 Amazon ECS Fargate 서비스가 최신 Fargate 플랫폼 버전을 실행하고 있는지 확인합니다. 플랫폼 버전이 최신 버전이 아닌 경우, 이 제어가 실패합니다.

AWS Fargate 플랫폼 버전은 커널 및 컨테이너 런타임 버전의 조합인 Fargate 작업 인프라의 특정 런타임 환경을 나타냅니다. 런타임 환경이 발전함에 따라 새로운 플랫폼 버전이 출시됩니다. 예를 들어, 커널 또는 운영 체제 업데이트, 새로운 기능, 버그 수정 또는 보안 업데이트용으로 새 버전이 릴리스될 수 있습니다. 보안 업데이트 및 패치는 Fargate 태스크에서 자동 배포됩니다. 플랫폼 버전에 영향을 미치는 보안 문제가 발견되면는 플랫폼 버전을 AWS 패치합니다.

문제 해결

플랫폼 버전을 비롯한 기존 서비스를 업데이트하려면 Amazon Elastic Container Service 개발자 안내서의 서비스 업데이트를 참조하세요.

[ECS.12] ECS 클러스터는 Container Insights를 사용해야 합니다.

관련 요구 사항: NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SI-2

범주: 식별 > 로깅

심각도: 중간

리소스 유형: AWS::ECS::Cluster

AWS Config규칙: ecs-container-insights-enabled

스케줄 유형: 변경이 트리거됨

파라미터: 없음

이 제어는 ECS 클러스터가 컨테이너 인사이트를 사용하는지 확인합니다. Container Insights가 클러스터에 설정되지 않은 경우, 이 제어는 실패합니다.

모니터링은 Amazon ECS 클러스터의 안정성, 가용성 및 성능을 유지하는 데 중요한 부분입니다. CloudWatch Container Insights를 사용해 컨테이너화된 애플리케이션 및 마이크로서비스의 메트릭 및 로그를 수집하고 집계하며 요약할 수 있습니다. CloudWatch는 CPU, 메모리, 디스크, 네트워크와 같은 많은 리소스에 대한 메트릭를 자동으로 수집합니다. 또한 Container Insights는 컨테이너 재시작 오류 같은 진단 정보를 제공하여 문제를 격리하고 신속하게 해결할 수 있도록 도와줍니다. Container Insights가 수집하는 메트릭에 대해 CloudWatch 경보를 설정할 수도 있습니다.

문제 해결

Container Insights를 사용하려면 Amazon CloudWatch 사용 설명서의 서비스 업데이트를 참조하세요.

[ECS.13] ECS 서비스에 태그를 지정해야 합니다

범주: 식별 > 인벤토리 > 태그 지정

심각도: 낮음

리소스 유형: AWS::ECS::Service

AWS Config규칙: tagged-ecs-service (사용자 지정 Security Hub 규칙)

스케줄 유형: 변경이 트리거됨

파라미터:

이 제어 검사는 Amazon ECS 서비스에 파라미터 requiredTagKeys에 정의된 특정 키가 있는 태그가 있는지 확인합니다. 서비스에 태그 키가 없거나 파라미터 requiredTagKeys에 지정된 모든 키가 없는 경우, 제어가 실패합니다. 파라미터 requiredTagKeys이 제공되지 않은 경우, 제어는 태그 키의 존재만 확인하고 서비스에 키로 태그가 지정되지 않은 경우 제어가 실패합니다. 자동으로 적용되고 aws:로 시작하는 시스템 태그는 무시됩니다.

태그는 AWS 리소스에 할당하는 레이블이며 키와 선택적 값으로 구성됩니다. 태그를 생성하여 용도, 소유자, 환경 또는 기타 기준으로 리소스를 분류할 수 있습니다. 태그를 사용하면 리소스를 식별, 정리, 검색 및 필터링하는 데 도움을 줍니다. 태깅은 또한 작업 및 알림에 대한 책임 리소스 소유자를 추적하는 데도 도움이 됩니다. 태깅을 사용하는 경우, 속성 기반 액세스 제어(ABAC)를 태그를 기반으로 권한을 정의하는 권한 부여 전략으로 구현할 수 있습니다. IAM 엔터티(사용자 또는 역할) 및 AWS 리소스에 태그를 연결할 수 있습니다. IAM 보안 주체에 대해 단일 ABAC 정책 또는 별도의 정책 세트를 생성할 수 있습니다. 이러한 ABAC 정책은 보안 주체의 태그가 리소스 태그와 일치할 때 작업을 허용하도록 설계할 수 있습니다. 자세한 내용은 IAM 사용 설명서의 ABAC란 무엇입니까 AWS?를 참조하세요.

문제 해결

ECS 서비스에 태그를 추가하려면 Amazon Elastic Container Service 개발자 안내서의 Amazon ECS 리소스 태그 지정을 참조하세요.

[ECS.14] ECS 클러스터에 태그를 지정해야 합니다.

범주: 식별 > 인벤토리 > 태그 지정

심각도: 낮음

리소스 유형: AWS::ECS::Cluster

AWS Config규칙: tagged-ecs-cluster (사용자 지정 Security Hub 규칙)

스케줄 유형: 변경이 트리거됨

파라미터:

이 제어는 Amazon ECS 클러스터에 파라미터 requiredTagKeys에 정의된 특정 키가 있는 태그가 있는지 확인합니다. 클러스터에 태그 키가 없거나 파라미터 requiredTagKeys에 지정된 모든 키가 없는 경우, 제어가 실패합니다. 파라미터 requiredTagKeys이 제공되지 않은 경우, 제어는 태그 키의 존재만 확인하고 클러스터에 키로 태그가 지정되지 않은 경우, 제어가 실패합니다. 자동으로 적용되고 aws:로 시작하는 시스템 태그는 무시됩니다.

태그는 AWS 리소스에 할당하는 레이블이며 키와 선택적 값으로 구성됩니다. 태그를 생성하여 용도, 소유자, 환경 또는 기타 기준으로 리소스를 분류할 수 있습니다. 태그를 사용하면 리소스를 식별, 정리, 검색 및 필터링하는 데 도움을 줍니다. 태깅은 또한 작업 및 알림에 대한 책임 리소스 소유자를 추적하는 데도 도움이 됩니다. 태깅을 사용하는 경우, 속성 기반 액세스 제어(ABAC)를 태그를 기반으로 권한을 정의하는 권한 부여 전략으로 구현할 수 있습니다. IAM 엔터티(사용자 또는 역할) 및 AWS 리소스에 태그를 연결할 수 있습니다. IAM 보안 주체에 대해 단일 ABAC 정책 또는 별도의 정책 세트를 생성할 수 있습니다. 이러한 ABAC 정책은 보안 주체의 태그가 리소스 태그와 일치할 때 작업을 허용하도록 설계할 수 있습니다. 자세한 내용은 IAM 사용 설명서의 ABAC란 무엇입니까 AWS?를 참조하세요.

문제 해결

ECS 클러스터에 태그를 추가하려면 Amazon Elastic Container Service 개발자 안내서의 Amazon ECS 리소스 태그 지정을 참조하세요.

[ECS.15] ECS 작업 정의에 태그를 지정해야 합니다.

범주: 식별 > 인벤토리 > 태그 지정

심각도: 낮음

리소스 유형: AWS::ECS::TaskDefinition

AWS Config규칙: tagged-ecs-taskdefinition (사용자 지정 Security Hub 규칙)

스케줄 유형: 변경이 트리거됨

파라미터:

이 제어는 Amazon ECS 태스크 정의에 파라미터 requiredTagKeys에 정의된 특정 키가 있는 태그가 있는지 확인합니다. 태스크 정의에 태그 키가 없거나 파라미터 requiredTagKeys에 지정된 모든 키가 없는 경우, 제어가 실패합니다. 파라미터 requiredTagKeys이 제공되지 않은 경우, 제어는 태그 키의 존재만 확인하고 작업 정의에 키로 태그가 지정되지 않은 경우 제어가 실패합니다. 자동으로 적용되고 aws:로 시작하는 시스템 태그는 무시됩니다.

태그는 AWS 리소스에 할당하는 레이블이며 키와 선택적 값으로 구성됩니다. 태그를 생성하여 용도, 소유자, 환경 또는 기타 기준으로 리소스를 분류할 수 있습니다. 태그를 사용하면 리소스를 식별, 정리, 검색 및 필터링하는 데 도움을 줍니다. 태깅은 또한 작업 및 알림에 대한 책임 리소스 소유자를 추적하는 데도 도움이 됩니다. 태깅을 사용하는 경우, 속성 기반 액세스 제어(ABAC)를 태그를 기반으로 권한을 정의하는 권한 부여 전략으로 구현할 수 있습니다. IAM 엔터티(사용자 또는 역할) 및 AWS 리소스에 태그를 연결할 수 있습니다. IAM 보안 주체에 대해 단일 ABAC 정책 또는 별도의 정책 세트를 생성할 수 있습니다. 이러한 ABAC 정책은 보안 주체의 태그가 리소스 태그와 일치할 때 작업을 허용하도록 설계할 수 있습니다. 자세한 내용은 IAM 사용 설명서의 ABAC란 무엇입니까 AWS?를 참조하세요.

문제 해결

ECS 작업 정의에 태그를 추가하려면 Amazon Elastic Container Service 개발자 안내서의 Amazon ECS 리소스 태그 지정을 참조하세요.

[ECS.16] ECS 작업 세트는 퍼블릭 IP 주소를 자동으로 할당해서는 안 됩니다.

관련 요구 사항: PCI DSS v4.0.1/1.4.4

범주: 보호 > 보안 네트워크 구성 > 공개적으로 액세스할 수 없는 리소스

심각도: 높음

리소스 유형: AWS::ECS::TaskSet

AWS Config규칙: ecs-taskset-assign-public-ip-disabled (사용자 지정 Security Hub 규칙)

스케줄 유형: 변경이 트리거됨

파라미터: 없음

이 제어는 Amazon ECS 작업 세트가 퍼블릭 IP 주소를 자동으로 할당하도록 구성되었는지 여부를 확인합니다. AssignPublicIP을 ENABLED로 설정하면 제어가 실패합니다.

퍼블릭 IP 주소는 인터넷을 통해 연결할 수 있는 주소입니다. 퍼블릭 IP 주소로 작업 세트를 구성하는 경우, 인터넷에서 작업 세트와 연결된 리소스에 연결할 수 있습니다. ECS 작업 세트는 공개적으로 액세스할 수 없어야 합니다. 이렇게 하면 컨테이너 애플리케이션 서버에 의도하지 않은 액세스가 허용될 수 있기 때문입니다.

문제 해결

퍼블릭 IP 주소를 사용하지 않도록 ECS 태스크 세트를 업데이트하려면 Amazon Elastic Container Service 개발자 안내서의 콘솔을 사용하여 Amazon ECS 태스크 정의 업데이트 섹션를 참조하세요.