AWS Cloud DevOps 보안 관리

AWS Localzone Hanoi 정식 출범

2026년 07월 17일

새로운장의시작: 테크밸리호치민사무소, 새오피스로이전

2026년 07월 17일

우리가 모를 수 있는 클라우드 보안

최근 저희 TechValley 클라우드팀은 DevOps의 모의 운영 시스템을 대상으로 클라우드 환경에 대한 종합 보안 스캐닝을 임의적으로 수행했습니다. Trivy v0.61.0 스캐너를 활용하여 소스 코드 저장소와 프로덕션 Docker 이미지를 전수 분석한 결과, 예상외 심각한 문제들이 발견되었습니다.

이 글에서는 이번 스캔에서 발견된 실제 사례들을 바탕으로, AWS Cloud DevOps 환경에서 개발자와 DevOps 엔지니어라면 반드시 알아야 할 5가지 핵심 보안 함정과 그 해결책을 알기 쉽게 설명하겠습니다. 이 내용은 특정 서비스만의 문제가 아니라, 많은 팀이 실수하는 공통적인 패턴입니다.

1. 소스 코드에 AWS 키를 직접 넣지 말아야

이번 스캔에서 발견된 가장 심각하고 즉각적인 위협은 바로 AWS 크리덴셜(Access Key / Secret Key) 이 GitHub 저장소에 평문으로 커밋되어 있었던 것입니다. application.yml과 application-stg.yml 두 파일에서 각각 2건씩, 총 4건의 AWS 관리자 권한 크리덴셜이 노출되었습니다.

소스코드에 노출된 AWS 크리덴셜 Key 정보 (이미지는 임의 제작)

GitHub 저장시 왜 위험한가?

GitHub과 같은 공개 저장소라면 전 세계 누구나 이 키를 볼 수 있습니다.

비공개 저장소라 하더라도, 저장소 권한이 있는 모든 사람이 접근 가능합니다.

AWS 관리자 키가 탈취되면 S3 데이터 유출, EC2 인스턴스 무단 생성(채굴 악용), 데이터베이스 삭제 등 엄청난 피해가 발생할 수 있습니다.

Git 히스토리는 영구적으로 남습니다. 파일에서 지워도 커밋 기록에는 남아 있습니다.

올바른 해결책

▸즉시 해당 AWS 키를 폐기(Revoke)하고 새 키를 발급합니다.

▸AWS CloudTrail 로그를 확인하여 해당 키로 비정상 접근이 있었는지 점검합니다.

▸git filter-branch 또는 BFG Repo-Cleaner로 Git 히스토리에서 시크릿을 완전히 제거합니다.

▸향후에는 AWS Secrets Manager, Systems Manager Parameter Store, 또는 HashiCorp Vault에 시크릿을 저장합니다.

▸CI/CD 파이프라인에 git-secrets, gitleaks 같은 시크릿 스캐너를 Pre-commit Hook으로 추가합니다.

실전 적용법: 환경변수 방식으로 전환

# application.yml에서 이렇게 하면 안 됩니다 (BAD)

cloud.aws.credentials.access-key: AKIAIOSFODNN7EXAMPLE

# 이렇게 환경변수로 참조해야 합니다 (GOOD)

cloud.aws.credentials.access-key: ${AWS_ACCESS_KEY_ID}

# 그리고 실제 값은 CI/CD 시크릿 또는 AWS Secrets Manager에 저장합니다.

2. 오래된 OS 이미지로 Docker를 빌드하지 말것

애플리케이션을 안전하게 감싸야 할 컨테이너 베이스 때로는 이미지가 오히려 공격의 통로가 될 수 있습니다. 이번 스캔 대상 Docker 이미지는 Amazon Linux 2 기반으로 빌드되어 있었는데, OS 레이어에서 여러 취약점이 발견되었습니다. 그 중 가장 심각한 것은 expat XML 파서 라이브러리의 취약점(CVE-2022-23990, CVE-2022-25313)으로, 정수 오버플로우와 스택 고갈 공격이 가능한 수준이었습니다.

특히 expat 라이브러리에서 발견된 CVE-2022-23990 및 CVE-2022-25313은 XML 파싱 과정에서 정수 오버플로(Integer Overflow)나 스택 고갈(Stack Exhaustion)을 유발합니다. 공격자가 조작된 XML 요청을 보내 컨테이너를 강제 종료시키거나(DoS), 메모리 오염을 통해 임의 코드를 실행할 수 있는 위험이 큽니다. 현재 사용 중인 2.1.0-15.amzn2.0.2 버전은 즉각적인 업데이트가 필요합니다.

올바른 해결책

▸Docker 베이스 이미지는 ‘한 번 정하면 끝’이 아닙니다. 정기적으로 업데이트가 필요합니다.

▸Amazon Linux 2 대신 보안 패치가 활발한 Amazon Linux 2023 또는 distroless 이미지 사용을 추천합니다.

▸Dockerfile에 RUN yum update -y 또는 apt-get upgrade를 포함시켜 이미지 빌드 시 최신 패치를 적용합니다.

▸CI/CD 파이프라인에 Trivy, Snyk, Docker Scout 같은 컨테이너 이미지 스캐너를 통합하여 빌드 단계에서 취약점을 차단합니다.

▸불필요한 패키지와 개발 도구는 프로덕션 이미지에 포함시키지 않습니다 (Attack Surface 최소화).

CI/CD 보안 게이트 추가 예시 (GitHub Actions)

– name: Scan Docker image with Trivy

uses: aquasecurity/trivy-action@master

with:

image-ref: ‘myapp:${{ github.sha }}’

format: ‘table’

exit-code: ‘1’ # CRITICAL 발견 시 빌드 실패 처리

severity: ‘CRITICAL,HIGH’

3. Java 라이브러리 의존성에 관리를 방치하지 말것

이번 스캔에서 가장 많은 수의 취약점이 발견된 곳은 app.jar였습니다. 여러 취약점 중 일부는 CRITICAL 수준이었으며, 업계에서 악명 높은 여러 CVE들이 포함되어 있었습니다.

Java 라이브러리 보안 위험성

app.jar 이란?

app.jar (Java Archive File) (Java Library 압축 패키지)는 개발자가 작성한 소스 코드와 프로그램 구동에 필요한 수많은 외부 도구(라이브러리)들을 하나의 파일로 묶어놓은 ‘압축 파일’이자 ‘실행 파일’입니다.

app.jar 구조와 역할

저희 테크밸리 보고서에서 스캔한 Docker 컨테이너가 하나의 컴퓨터(서버)라면, 그 컴퓨터 안에서 핵심적인 일을 수행하는 주인공이 바로 app.jar입니다.

app.jar 파일 안에는 개발자가 짠 코드뿐만 아니라, 서비스를 돌리기 위한 필수 부품들이 함께 포장되어 있습니다. 보고서에 따르면 다음과 같은 주요 부품(Java 라이브러리)들이 포함되어 있습니다.

• Tomcat: 웹사이트에 접속할 수 있게 해주는 내장 웹 서버

• Log4j: 시스템의 기록(로그)을 남기는 도구

• Spring Framework / Spring Security: 프로그램의 뼈대를 구성하고, 로그인 및 권한 등 보안을 담당하는 도구

• Netty: 네트워크 통신을 처리하는 도구

app.jar 위험성과 보안 권장 사항

*부연 설명

• Spring4Shell (CVE-2022-22965): JDK 9 이상 환경에서 데이터 바인딩 기능을 악용하여 클래스 로더 속성을 조작합니다. 이를 통해 서버에 악성 JSP 파일을 생성하고 원격 제어권을 획득할 수 있는 치명적인 구멍입니다.

• Spring Security Bypass (CVE-2022-22978): 정규 표현식 매칭의 허점을 이용하여 특정 패턴의 URL 접근 시 인증을 우회합니다. 관리자 페이지가 탈취될 수 있는 시나리오가 성립됩니다.

• Netty Request Smuggling (CVE-2019-20444): 프론트엔드 프록시와 백엔드 서버 간의 HTTP 요청 해석 차이를 이용합니다. 공격자는 이를 통해 다른 사용자의 요청을 가로채거나 보안 필터링을 우회하여 시스템 내부로 침투할 수 있습니다.

Log4Shell(CVE-2021-44228)은 2021년에 발견된 이후 전 세계 수십만 개의 시스템을 공격한 역대 최악의 Java 취약점 중 하나입니다. 그런데 2025년에도 아직 이 버전을 사용하고 있다는 것은, 의존성 관리가 전혀 이루어지지 않았다는 의미입니다.

올바른 해결책

▸Spring Boot를 최신 안정 버전으로 업그레이드하세요. Spring Boot 버전을 올리면 대부분의 하위 의존성(Spring Framework, Tomcat, Spring Security 등)이 함께 패치됩니다.

▸mvn dependency:tree 또는 gradle dependencies 명령으로 취약한 라이브러리가 직접 의존성인지 간접 의존성인지 확인합니다.

▸간접 의존성인 경우 pom.xml 또는 build.gradle의 <dependencyManagement> 섹션에서 버전을 명시적으로 강제합니다.

▸OWASP Dependency-Check, Snyk, Dependabot 같은 도구를 CI에 통합하여 새로운 CVE가 발견될 때 자동으로 알림을 받도록 설정합니다.

▸특히 레거시 Netty 3.x처럼 더 이상 지원되지 않는 라이브러리는 즉시 제거하거나 최신 버전으로 교체해야 합니다.

위와 같은 취약점은 우리가 신뢰하고 사용하는 오픈소스 라이브러리가 관리되지 않을 때 얼마나 위험한지를 단적으로 보여줍니다.

4. IAM 권한은 최소한으로

이번에 노출된 AWS 크리덴셜은 단순 S3 읽기 권한이 아니라 관리자(Administrator) 권한을 가진 키였습니다. 이 키 하나만 탈취되어도 해당 AWS 계정의 모든 자원에 대한 무제한 접근이 가능합니다.

IAM 권한과 롤 세팅

최소 권한 원칙(Principle of Least Privilege)이란?

각 서비스나 사용자에게는 실제로 필요한 최소한의 권한만 부여해야 한다는 보안의 기본 원칙입니다.

예시: S3 버킷에서 파일을 읽기만 하는 서비스라면, s3:GetObject 권한만 부여해야 합니다.

s3: 권한이나 Administrator 권한을 부여하면 안 됩니다.

올바른 해결책

▸애플리케이션이 실제로 사용하는 AWS 서비스와 작업만 IAM 정책에 명시합니다.

▸EC2, ECS, EKS에서 실행되는 애플리케이션은 IAM User 키 대신 IAM Role을 활용하세요. 키 파일 자체가 필요 없어집니다.

▸AWS IAM Access Analyzer를 활용하면 실제로 사용된 권한을 분석하여 최소 권한 정책을 자동으로 생성해줍니다.

▸AWS Organizations의 SCP(Service Control Policy)를 활용하여 계정 수준에서 위험한 서비스 사용을 차단합니다.

▸루트 계정은 절대 일상 업무에 사용하지 말고, 반드시 MFA를 활성화하세요.

ECS/EKS 환경에서의 권장 방식: Task Role 활용

# 나쁜 방법: 환경변수에 직접 키 주입

environment:

– AWS_ACCESS_KEY_ID=AKIA…

– AWS_SECRET_ACCESS_KEY=…

# 좋은 방법: IAM Task Role 지정 (키 불필요)

taskRoleArn: arn:aws:iam::123456789:role/MyAppRole

# SDK가 자동으로 임시 크리덴셜을 가져옵니다.

5. 보안 스캐닝을 개발 전부터 시행해 봐야

왜 개발 마지막 단계에서 발견하면 늦는가?

이번 사례처럼 이미 프로덕션 배포 직전 또는 이후에 취약점이 발견되면, 긴급 패치와 재배포로 인한 서비스 중단, 이미 노출된 시크릿의 사후 처리, 그리고 비즈니스 타격이라는 삼중 부담을 안게 됩니다. 보안은 개발 사이클의 처음부터 함께 가야 합니다. 이를 ‘Shift-Left Security’ 또는 ‘DevSecOps‘라고 부릅니다.

DevSecOps CI/CD 파이프라인 구성시 권장안

DevSecOps CI/CD 주요 검사 항목

보안 스캔을 습관화하는 3가지 실천법

▸매주 자동 스캔: 저장소와 Docker 이미지 스캔을 매주 자동으로 실행하고 결과를 팀 Slack이나 이메일로 알림 설정

▸SBOM (소프트웨어 부품 목록) 생성: Trivy 또는 Syft로 배포 이미지의 모든 패키지 목록을 문서화하고 관리

▸취약점 SLA 정책 수립: CRITICAL은 24시간, HIGH는 7일, MEDIUM은 30일 이내 조치라는 팀 내부 정책을 명문화

조직의 각 IT 담당자의 역할은?

각 회사의 조직과 구성원은 책임 있는 리더십(accountable leadership)이 각 작업에 대한 담당자(owner)를 지정하여 조치를 취하고 배포를 차단할 것을 권고해야 할 것입니다.

그리고 사고가 발생시에는 사고 보고서의 ‘즉각적 조치 계획(Immediate Remediation Plan)’에 따라 담당 영역별로 요구되는 조치사항은 다음과 같습니다.

1. 자격 증명 관리 및 저장소 정리 담당자

application-stg.yml 및 application.yml에 하드코딩된 AWS 액세스 키를 즉각적으로 폐기 및 교체(revoke/rotate)해야 합니다

또한 CloudTrail 및 S3 로그를 검토하여 비정상적인 데이터 접근이 있었는지 확인하고, 활성 브랜치의 설정 파일에서 비밀값을 제거해야 합니다

그리고 Git 히스토리에서 노출된 비밀값을 완전히 삭제(purge)해야 합니다

런타임에 필요한 설정값들은 Secrets Manager, SSM, Vault 등의 관리형 비밀 저장소(managed secret store)로 마이그레이션해야 합니다.

향후 재발을 막기 위해 커밋 전(pre-commit) 및 CI 파이프라인에 비밀값 스캐닝 단계를 강제해야 합니다.

2. Java 애플리케이션 및 개발팀

Spring Boot, Spring Framework, Spring Security, 임베디드 Tomcat, Log4j, Netty 등 주요 Java 종속성(dependencies)을 안전한 버전으로 업그레이드해야 합니다

직접 추가한 라이브러리뿐만 아니라 취약한 전이적 종속성(transitive dependencies)까지 모두 해결해야 하며, 조치 이후 인가(authorization) 규칙 및 애플리케이션 기능이 정상 작동하는지 회귀 테스트(regression test)와 보안 테스트를 수행해야 합니다.

3. OS 및 컨테이너 및 인프라 팀 (DevOps)

expat 라이브러리(CVE-2022-23990 등)와 같이 CRITICAL 취약점이 존재하는 Amazon Linux 2 운영체제 패키지를 패치해야 합니다.

또는 패치가 완료된 최신 최소 런타임 이미지로 베이스 이미지를 재구축(rebuild)해야 합니다.

컨테이너 런타임 내의 불필요한 도구들을 모두 제거하고, 소프트웨어 자재 명세서(SBOM)를 생성해야 합니다.

4. CI/CD 및 보안 관리팀 (DevOps & DevSecOps)

배포 차단 (Validation gate): 코드 저장소와 Docker 이미지를 다시 스캔하여, 자격 증명 노출 문제와 CRITICAL 등급의 취약점이 완전히 해결되거나 리더십에 의해 유효기간이 설정된 공식적인 위험 수용(risk-accepted) 승인이 나기 전까지는 현재 이미지의 프로덕션 배포를 전면 차단해야 합니다.

CRITICAL 등급의 비밀값 노출, 원격 코드 실행(RCE), 인가 우회, HTTP 요청 스머글링(request smuggling) 등의 취약점은 발견 시 릴리스를 차단하도록 CI/CD 정책에 명시해야 합니다.

모든 서비스, 특히 외부(Public)에 노출되는 서비스의 프로덕션 배포 전 파이프라인(Scanning stage)에 보안 스캐닝을 의무적으로 도입해야 합니다.

이상으로 마치며 : 보안은 일회성 이벤트가 아니다.

이번 실제 스캔 사례를 통해 확인한 것처럼, AWS Cloud DevOps 환경에서 보안 취약점은 의도치 않게, 그리고 생각보다 빠르게 쌓입니다. 처음 개발 속도를 위해 ‘나중에 고치자’고 미뤄둔 것들이, 어느 순간 CRITICAL 212건이라는 숫자가 되어 돌아옵니다.

5가지 핵심 교훈을 정리하면 다음과 같습니다.

A-Z DevOps 체크 리스트 및 보안 권고 방안

핵심 체크리스트

① 코드에 AWS 키 직접 삽입 금지 → Secrets Manager / IAM Role 사용

② Docker 베이스 이미지 정기 업데이트 → 분기별 최신 이미지로 리빌드

③ Java 의존성 정기 점검 → Spring Boot 등 최신 안정 버전 유지

④ IAM 최소 권한 원칙 적용 → Task Role 활용, 관리자 키 사용 금지

⑤ CI/CD에 보안 스캔 통합 → CRITICAL 발견 시 자동 배포 차단

오늘 블로그는 TechValley는 베트남에서 Cloud 아웃소싱 및 DevOps 운영 서비스를 제공하는 전문 기업으로서, 고객사의 AWS 클라우드 환경에 대한 보안 스캐닝, 취약점 분석, 그리고 DevSecOps 파이프라인 구축을 지원하고 있습니다. 보안에 대한 고민이 있으신 분은 언제든지 문의해 주세요.