기술AWS Fargate 환경의 컨테이너 보안 점검 방법: ECS 설정부터 이미지 취약점 점검까지

컨테이너 기반 서비스를 운영할 때는 애플리케이션의 정상 동작뿐 아니라, 배포와 운영 과정에서 보안 통제가 적절히 적용되는지도 함께 확인해야 합니다.

이번 글에서는 ECS on Fargate 환경에서 컨테이너 서비스를 운영할 때 확인해야 할 주요 보안 점검 항목을 정리해 보겠습니다.

1. Fargate 환경에서 컨테이너 점검 방식이 달라지는 이유

기존 Docker 호스트 환경에서는 서버에 접속해 실행 중인 컨테이너를 확인하고, 필요에 따라 Docker 설정, 호스트 OS 계정과 파일 권한, 로그 파일, 네트워크 설정까지 함께 점검할 수 있습니다.

하지만 Fargate에서는 컨테이너를 실행하는 기반 인프라를 AWS가 관리합니다. 따라서 호스트 OS에 접속하거나 Docker 데몬, Docker 소켓, 호스트 파일 권한을 직접 점검하는 방식은 적용하기 어렵습니다.

그렇다고 해서 점검해야 하는 인프라 환경이 사라지거나 줄어든 것은 아닙니다. 핵심은 관리의 주체가 바뀌면서 우리가 점검해야 하는 위치와 방식이 바뀐다는 것입니다.

2. 점검 전 알아둘 Amazon ECS 구성 요소

Fargate 환경에서 무엇을 점검해야 하는지 이해하려면 Amazon ECS 구성 요소의 관계를 먼저 알아둘 필요가 있습니다.

컨테이너 이미지는 태스크 정의에 지정되며, 서비스는 이를 사용해 클러스터 안에서 태스크를 실행·유지합니다. 클러스터는 서비스와 태스크를 관리하는 논리적 범위입니다.

태스크 정의는 클러스터 외부에서 등록되며, 서비스는 클러스터 안에서 해당 정의를 바탕으로 태스크를 실행·유지하고 각 태스크 안에서 컨테이너가 실행됩니다.

3. 태스크 정의에서 확인해야 할 컨테이너 보안 설정

태스크 정의는 컨테이너를 어떤 방식으로 실행할지를 기록한 설정입니다. 따라서 실행 중인 태스크만 확인하는 것이 아니라, 태스크 정의에 안전하지 않은 설정이 포함되어 있지 않은지도 함께 점검해야 합니다.

표의 주요 설정은 AWS Security Hub의 Amazon ECS 보안 점검 항목에서도 주요 확인 대상으로 다뤄집니다.

민감한 정보는 태스크 정의에 직접 입력하기보다 Secrets Manager 또는 Systems Manager Parameter Store를 참조해 전달하는 방식을 검토하는 것이 좋습니다.

태스크 정의 변경 사항은 기존 실행 중인 태스크에 자동으로 반영되지 않으므로, 새 개정을 등록한 뒤 서비스가 해당 개정을 사용하도록 배포해야 합니다.

4. 서비스·태스크 상태와 로그 모니터링 점검

태스크 정의가 적절하게 구성되어 있더라도 실제 서비스가 정상적으로 운영되지 않으면 점검의 의미가 줄어듭니다. 이 단계에서는 설정값보다 실제 실행 상태와 이상 징후를 탐지할 수 있는지를 확인합니다.

운영 중 발생한 문제를 추적하려면 컨테이너 로그가 CloudWatch 로그 그룹에 수집되고, 서비스와 태스크의 상태 변경 이력을 함께 확인할 수 있어야 합니다.

또한 AWS는 Fargate의 기본 인프라를 유지 관리하며, 플랫폼 개정 과정에서 기존 태스크를 중지할 수 있습니다. 이때 서비스가 대체 태스크를 정상적으로 시작해 원하는 실행 수를 유지하는지, 관련 이벤트를 확인할 수 있는지도 점검 대상입니다.

ECS Exec는 필요한 경우 실행 중인 특정 컨테이너에서 명령을 실행하거나 셸을 열어 진단 정보를 확인하는 기능입니다. Fargate 호스트에 접속하는 기능은 아니며, 정기 점검 전체를 대신하기보다 장애 분석이나 제한적인 런타임 확인에 활용하는 편이 적절합니다. ECS Exec 접근 권한과 CloudTrail 감사 기록도 함께 관리해야 합니다.

5. IAM 및 네트워크 접근제어 점검

태스크 역할과 태스크 실행 역할은 사용하는 주체와 목적이 다르므로, 애플리케이션 권한과 태스크 실행 권한을 분리해 관리해야 합니다.

태스크 역할에는 애플리케이션이 실제로 필요한 권한만 부여해야 합니다. 예를 들어 특정 S3 버킷의 일부 경로만 읽으면 되는 서비스에 모든 S3 리소스에 대한 읽기·쓰기 권한을 부여할 필요는 없습니다.

Fargate 태스크에는 네트워크 인터페이스와 보안 그룹이 적용됩니다. 따라서 외부에서 태스크로 들어오는 경로와 태스크가 외부로 나가는 통신 범위를 함께 검토해야 합니다.

이 예시는 인터넷 요청을 ALB를 통해 프라이빗 영역의 Fargate 태스크로 전달하고, 태스크와 내부 서비스가 인터넷에 직접 노출되지 않도록 필요한 통신만 허용하는 구조를 보여줍니다.

6. ECR 이미지 취약점 점검과 CVE 대응

이미지 취약점 점검의 대상은 Fargate 기반 서버가 아니라, 서비스에 배포하는 컨테이너 이미지입니다. 컨테이너 이미지에는 애플리케이션 코드뿐 아니라 운영 체제 패키지와 Python, Node.js, Java 등의 프로그래밍 언어 패키지가 포함될 수 있습니다.

Amazon ECR은 컨테이너 이미지의 소프트웨어 취약점을 확인하기 위해 기본 스캔과 고급 스캔을 제공합니다. 두 방식은 이미지 내 점검 범위와 스캔 실행 방식에 차이가 있습니다.

기본 스캔은 ECR을 사용한다고 자동으로 모든 이미지에 적용되는 기능은 아닙니다. 리포지토리에 푸시 시 스캔을 구성하지 않았다면 수동으로 이미지 스캔을 시작해야 합니다.

6.1. 스캔 결과를 실제 배포 이미지와 연결하기

취약점 결과를 확인했다면, 해당 결과가 실제 서비스에 배포된 이미지에 대한 것인지도 함께 확인해야 합니다. 이때 이미지 태그와 이미지 다이제스트를 함께 활용할 수 있습니다.

태그 변경이 허용된 리포지토리에서는 같은 태그가 다른 이미지를 가리킬 수 있으므로, latest 태그만으로 배포 이미지를 식별하는 방식에는 한계가 있습니다. 따라서 취약점 점검 기록에는 태그와 이미지 다이제스트를 함께 남기는 편이 좋습니다.

6.2. CVE 발견 시 대응 흐름

1. 영향을 받는 OS 패키지, 프로그래밍 언어 패키지, 베이스 이미지를 확인합니다.
2. 심각도와 수정 버전 제공 여부를 확인합니다.
3. 최신 베이스 이미지 또는 수정된 패키지 버전을 반영해 이미지를 재빌드합니다.
4. 새 이미지를 ECR에 푸시합니다.
5. 새 태스크 정의 개정을 등록하고 서비스를 재배포합니다.
6. 새 이미지의 스캔 결과와 서비스 상태를 다시 확인합니다.

7. Fargate 컨테이너 보안 점검 체크포인트 정리

Fargate 기반 컨테이너 서비스를 점검할 때는 다음 항목을 중심으로 확인하는 것이 좋습니다.

김창식 | kcs@cela.kr