기술Spring Boot 주요 배포 방식과 보안 점검 범위

지난 글에서는 Spring Boot의 기본 개념과 기존 설치형 WAS 환경과의 차이점을 살펴보았습니다. 

Spring Boot는 애플리케이션 내부에 Tomcat, Jetty, Undertow 등의 웹 서버를 포함하여 실행할 수 있기 때문에 기존의 별도 WAS 설치 방식과 점검 대상이 다를 수 있습니다. 또한 같은 Spring Boot 애플리케이션이라도 Docker 컨테이너, Kubernetes, 가상머신, 외부 Tomcat 등 배포 환경에 따라 확인해야 하는 보안 항목이 달라집니다.

이번 글에서는 Spring Boot 애플리케이션의 주요 배포 방식과 각 환경별 보안 점검 범위를 살펴보겠습니다.

1. JAR 파일 직접 실행 방식

Spring Boot에서 가장 기본적인 배포 방식은 애플리케이션을 실행 가능한 JAR 파일로 생성한 뒤 직접 실행하는 방식입니다.

java -jar application.jar

JAR 파일 내부에는 애플리케이션 소스와 라이브러리뿐만 아니라 Embedded Tomcat과 같은 내장 웹 서버가 함께 포함될 수 있습니다.

따라서 서버에 별도로 설치된 Tomcat이 없더라도 실제로는 애플리케이션 내부에서 웹 서버가 동작하고 있을 수 있습니다.

주요 보안 점검 범위

• Spring Boot 및 내장 WAS 버전

• JDK 버전과 보안 지원 여부

• 애플리케이션 실행 계정 권한

• JAR 파일 및 설정 파일 접근 권한

• 외부 노출 포트

• Actuator, JMX, Debug 기능 노출 여부

• application.properties 또는 application.yml 내 중요정보 포함 여부

• HTTPS 및 보안 헤더 설정

• 로그 내 개인정보 및 인증정보 기록 여부

특히 애플리케이션이 root 또는 관리자 권한으로 실행되고 있지 않은지 확인해야 합니다. JAR 파일을 직접 실행하는 구조에서는 별도의 WAS 관리 콘솔보다 Spring Boot 설정과 운영체제의 프로세스 실행 권한이 주요 점검 대상이 됩니다.

2. Docker 컨테이너 배포 방식

Spring Boot 애플리케이션을 Docker 이미지로 생성하여 컨테이너 형태로 실행하는 방식입니다.

일반적으로 다음과 같은 구조로 배포됩니다.

운영체제
└ Docker Engine
                 └ 컨테이너
                            └ Spring Boot 애플리케이션
                                                    └ Embedded Tomcat

이 환경에서는 Spring Boot 설정뿐만 아니라 Docker 이미지와 컨테이너 실행 설정도 함께 점검해야 합니다.

주요 보안 점검 범위

• Spring Boot 및 내장 WAS 버전

• 기반 이미지의 JDK 및 운영체제 패키지 취약점

• 컨테이너 내부 중요정보 저장 여부

• 컨테이너의 root 권한 실행 여부

• privileged 옵션 사용 여부

• 불필요한 Linux Capability 부여 여부

• 호스트 디렉터리 마운트 범위

• 컨테이너 포트 공개 범위

• 이미지 태그 관리 여부

• 컨테이너 CPU 및 메모리 제한 여부

• Dockerfile 내 계정정보 또는 인증정보 포함 여부

예를 들어 다음과 같이 컨테이너가 root 계정으로 실행되는 경우 애플리케이션 취약점이 컨테이너 내부의 높은 권한으로 이어질 수 있습니다.

FROM eclipse-temurin:17 

COPY application.jar /application.jar 

ENTRYPOINT ["java", "-jar", "/application.jar"]

가능한 경우 별도의 일반 사용자를 생성하고 해당 계정으로 애플리케이션을 실행하는 것이 안전합니다.

RUN addgroup --system spring && adduser --system --ingroup spring spring USER spring

Docker 환경에서는 애플리케이션 점검과 컨테이너 보안 점검을 분리하지 않고 함께 확인하는 것이 중요합니다.

3. 외부 Tomcat에 WAR 파일을 배포하는 방식

Spring Boot 애플리케이션을 WAR 파일로 생성하여 별도로 설치된 Tomcat에 배포할 수도 있습니다.

운영체제 

└ Tomcat    

         └ application.war

이 구조는 기존 Java 웹 애플리케이션의 배포 방식과 유사합니다. 내장 WAS가 아닌 외부 Tomcat을 사용하기 때문에 Spring Boot 설정뿐만 아니라 설치형 Tomcat의 보안 설정도 함께 점검해야 합니다.

주요 보안 점검 범위

• Spring Boot 및 사용 라이브러리 버전

• 외부 Tomcat 버전

• Tomcat 실행 계정 권한

• Tomcat 설정 파일 권한

• 기본 예제 및 불필요한 애플리케이션 제거 여부

• Manager 및 Host Manager 접근 제한

• AJP Connector 사용 여부

• 디렉터리 목록 노출 여부

• 오류 페이지 정보 노출 여부

• Tomcat 로그 및 애플리케이션 로그 관리

• 불필요한 HTTP Method 허용 여부

이 환경에서는 기존 WAS 보안 점검 기준을 적용할 수 있지만, Spring Boot에서 별도로 사용하는 Actuator나 환경설정 파일도 추가로 확인해야 합니다. 즉, 설치형 Tomcat 점검과 Spring Boot 애플리케이션 점검이 모두 필요한 구조입니다.

4. Nginx 또는 Apache를 앞단에 구성하는 방식

실제 운영 환경에서는 Spring Boot 애플리케이션을 인터넷에 직접 노출하지 않고 Nginx 또는 Apache와 같은 웹 서버나 Reverse Proxy를 앞단에 구성하는 경우가 많습니다.

사용자 

└ Nginx 또는 Apache    

                 └ Spring Boot      

                             └ Embedded Tomcat

앞단 웹 서버에서는 HTTPS 처리, 접근 통제, 보안 헤더 설정 등을 담당하고 Spring Boot는 내부 포트에서만 동작하도록 구성할 수 있습니다.

주요 보안 점검 범위

앞단 웹 서버

• 웹 서버 버전 및 보안 패치

• HTTPS와 TLS 설정

• 불필요한 HTTP Method 제한

• 서버 정보 노출 방지

• 디렉터리 목록 노출 방지

• 보안 헤더 설정

• Reverse Proxy 설정

• 접근 허용 IP 제한

• 요청 크기 및 Timeout 설정

Spring Boot 애플리케이션

• 내부 포트의 외부 노출 여부

• Actuator와 관리 기능 접근 제한

• Spring Boot 및 내장 WAS 버전

• Forwarded Header 처리 설정

• 오류 메시지 및 상세정보 노출 여부

• 애플리케이션 실행 권한

앞단 웹 서버에서 HTTPS를 적용하고 있더라도 Spring Boot 포트가 외부에 직접 공개되어 있다면 사용자가 웹 서버를 거치지 않고 애플리케이션에 접근할 수 있습니다. 따라서 방화벽, Security Group, Docker 포트 설정 등을 통해 Spring Boot 포트가 내부에서만 접근 가능하도록 제한되어 있는지 확인해야 합니다.

5. Kubernetes 또는 ECS 배포 방식

Spring Boot 애플리케이션을 Kubernetes Pod나 AWS ECS Task 형태로 운영하는 환경도 증가하고 있습니다. 이 경우 개별 서버의 설정만 확인하는 방식으로는 전체 보안 상태를 판단하기 어렵습니다. 애플리케이션 이미지와 함께 Kubernetes YAML, Helm Chart, ECS Task Definition 등 배포 설정을 확인해야 합니다.

주요 보안 점검 범위

• 컨테이너 이미지 취약점

• 신뢰할 수 있는 이미지 저장소 사용 여부

• 이미지 태그 관리 여부

• 컨테이너 root 권한 실행 여부

• privileged 설정 여부

• Security Context 설정

• Linux Capability 제한

• Read-only Root Filesystem 적용 여부

• Secret 및 ConfigMap 관리

• CPU와 메모리 제한

• Service와 Ingress 공개 범위

• Network Policy 적용 여부

• Kubernetes ServiceAccount 권한

• 클라우드 IAM 역할 권한

Kubernetes 환경에서는 다음과 같은 설정을 확인할 수 있습니다.

securityContext:  

runAsNonRoot: true  

allowPrivilegeEscalation: false  

readOnlyRootFilesystem: true

다만 위 설정이 모든 환경에 동일하게 적용될 수 있는 것은 아니므로 애플리케이션 운영 방식과 필요한 파일 쓰기 경로를 함께 확인해야 합니다. Kubernetes 또는 ECS 환경에서는 서버 내부 명령어 실행 결과뿐만 아니라 배포 정의 파일과 클라우드 콘솔 설정을 주요 점검 증적으로 활용할 수 있습니다.

6. SaaS 또는 PaaS 환경

AWS Elastic Beanstalk, Azure App Service, Google App Engine 등 관리형 플랫폼에 Spring Boot 애플리케이션을 배포하는 경우도 있습니다. 이러한 환경에서는 운영체제나 WAS 설정에 직접 접근하기 어려울 수 있습니다. 따라서 기존 서버 점검 항목을 그대로 적용하기보다 플랫폼에서 제공하는 관리 기능과 설정 증적을 기반으로 점검해야 합니다.

주요 보안 점검 범위

• Spring Boot 및 애플리케이션 라이브러리 버전

• 배포 패키지 내 중요정보 포함 여부

• 환경변수 및 Secret 관리

• 외부 공개 범위

• HTTPS 적용 여부

• 접근 통제 및 인증 설정

• 플랫폼 IAM 권한

• 로그 저장 및 모니터링 설정

• 백업 및 장애 대응 설정

• 플랫폼에서 제공하는 보안 설정 적용 여부

운영체제 계정이나 WAS 설정에 직접 접근할 수 없는 경우에는 해당 항목을 단순히 미점검으로 처리하기보다 플랫폼 관리 영역인지 확인해야 합니다. 필요한 경우 클라우드 콘솔 화면, 배포 설정, 보안 정책 문서 등을 통해 점검 결과를 대체할 수 있습니다.

배포 환경별 점검 범위 정리

배포 방식주요 점검 대상

점검 전 확인해야 할 체크포인트

Spring Boot 보안 점검을 시작하기 전에는 다음 사항을 먼저 확인하는 것이 좋습니다.

1. 애플리케이션이 JAR와 WAR 중 어떤 형태로 배포되어 있는지 확인합니다.

2. Tomcat, Jetty, Undertow 중 어떤 웹 서버를 사용하는지 확인합니다.

3. 내장 WAS인지 외부 설치형 WAS인지 구분합니다.

4. Docker 또는 Kubernetes 사용 여부를 확인합니다.

5. Nginx나 Apache와 같은 앞단 웹 서버가 있는지 확인합니다.

6. Spring Boot 포트가 외부에 직접 공개되어 있는지 확인합니다.

7. 서버 설정에 직접 접근할 수 있는 환경인지 확인합니다.

8. 접근이 제한된 경우 대체 가능한 설정 파일이나 콘솔 증적을 확인합니다.

마무리

Spring Boot 애플리케이션은 동일한 소스코드를 사용하더라도 배포 방식에 따라 보안 점검 대상과 확인 방법이 달라집니다. 특히 Docker나 Kubernetes 환경에서는 기존 WAS 설정만 확인해서는 컨테이너 권한, 이미지 취약점, Secret 관리와 같은 위험 요소를 놓칠 수 있습니다.

반대로 외부 Tomcat에 WAR 파일로 배포된 환경에서는 Spring Boot만 확인하는 것이 아니라 기존 설치형 WAS 보안 설정도 함께 점검해야 합니다. 따라서 Spring Boot 보안 점검에서는 상세 항목을 확인하기 전에 애플리케이션의 배포 구조와 운영 환경을 먼저 식별하는 과정이 중요합니다.

다음 글에서는 Spring Boot 애플리케이션 점검 시 가장 먼저 확인해야 하는 내장 WAS 종류와 버전을 식별하는 방법을 살펴보겠습니다.

서혜림 | seohr@cela.kr