[TIL] Spring Boot Actuator - 운영 노출 범위 제어

in TIL on Til, Spring boot, Actuator, Security, 운영, Least privilege

Spring Boot Actuator 엔드포인트를 운영 환경에 그대로 노출할 때 발생하는 보안 위험과, health 중심 최소 노출 원칙, 환경별 분리 설정, 네트워크/시큐리티 방어층까지 한 번에 정리한 글이다.

Spring Boot Actuator는 운영 관측에 매우 유용하지만, /actuator/env, /actuator/heapdump, /actuator/beans 같은 엔드포인트를 외부에 열어두면 민감 정보 유출로 이어질 수 있다. 운영에서는 필요한 최소 엔드포인트만 노출하고, 애플리케이션/네트워크/인증 계층에서 방어를 겹겹이 두는 것이 안전하다.

들어가며

Actuator를 붙이면 헬스체크, 메트릭, 스레드/힙 상태 같은 운영 정보를 빠르게 볼 수 있다.

문제는 “편의성” 때문에 개발 환경 설정이 운영까지 흘러가는 순간이다.

  • 개발 중에는 편한 설정: management.endpoints.web.exposure.include=*
  • 운영에서는 위험한 설정: 동일하게 외부 노출

운영 환경에서는 관측 가능성(Observability)과 보안(Security)을 같이 가져가야 한다. 핵심은 단순하다.

  • “필요한 것만 노출한다.”

1. 왜 Actuator 노출이 위험한가

엔드포인트마다 리스크가 다르지만, 대체로 아래 문제가 발생한다.

  • /actuator/env: 환경변수/설정 키 이름 노출
  • /actuator/beans: 내부 빈 구조, 패키지/구성 정보 노출
  • /actuator/heapdump: 메모리 스냅샷 기반 민감 데이터 노출 위험

공격자 입장에서는 이 정보만으로도 시스템 구조를 빠르게 파악하고, 다음 공격 벡터를 찾기 쉬워진다.

즉, Actuator 자체가 위험한 기능이라기보다, 운영 노출 범위를 통제하지 않으면 정보 정찰에 유리한 표면을 제공하게 된다.

2. 운영에서 최소 노출 원칙 적용하기

보안에서 자주 쓰는 원칙이 있다.

  • 최소 권한 원칙(Principle of Least Privilege)

Actuator에도 똑같이 적용하면 된다.

  • “운영에서 외부에 꼭 필요한 엔드포인트만 노출”
  • “나머지는 비노출 + 내부망/인증 보호”

이 원칙을 지키면, 장애 대응에 필요한 관측 정보는 유지하면서도 불필요한 공격 표면을 줄일 수 있다.

3. 권장 기본값: health만 공개

외부 로드밸런서/오케스트레이터의 헬스체크 목적이라면, 보통 health만으로 충분하다.

management:
  endpoints:
    web:
      exposure:
        include: health
  endpoint:
    health:
      show-details: never

이 설정의 의미:

  • 외부 HTTP로는 health만 노출
  • 상세 상태(db, diskSpace 등)는 기본 비공개

모니터링 시스템이 내부망에서만 접근한다면, 상세 정보는 내부 채널에서만 보이도록 분리하는 편이 안전하다.

4. 환경별로 노출 정책 분리하기

개발/운영의 요구는 다르므로, 프로파일 기준으로 설정을 분리한다.

예시:

  • application-dev.yml: include: "*" (로컬/사내 개발망 한정)
  • application-prod.yml: include: health

운영 사고는 “코드 버그”보다 “설정 실수”에서 많이 시작된다. 그래서 설정 분리는 선택이 아니라 필수에 가깝다.

또한 CI/CD에서 운영 프로파일이 실제로 적용되는지(환경변수, 배포 매니페스트)까지 함께 검증해야 한다.

5. 보안 필터 체인으로 actuator 추가 보호

Actuator 노출 엔드포인트가 적더라도, 인증/인가 레이어를 함께 두면 더 안전하다.

예를 들어:

  • /actuator/health는 permitAll (외부 헬스체크 필요 시)
  • 나머지 /actuator/**는 관리자 권한 또는 내부 인증 토큰 필요

핵심은 “노출 제어 + 접근 제어”를 동시에 적용하는 것이다.

  • 노출 제어: 어떤 엔드포인트를 웹에 공개할지
  • 접근 제어: 공개된 엔드포인트를 누가 호출할 수 있는지

6. 네트워크 레벨에서 한 번 더 제한

애플리케이션 설정만 믿지 말고, 네트워크 계층에서 한 번 더 막는다.

  • 보안 그룹/방화벽으로 Actuator 경로 접근 IP 제한
  • Ingress/Nginx에서 경로 기반 접근 제한
  • 가능하면 내부 전용 포트/내부 서비스로만 분리

보안은 단일 장치가 아니라 다층 방어(Defense in Depth)로 설계할수록 실패 확률이 낮아진다.

7. 흔한 오해와 점검 포인트

오해 1: “내 서비스 URL은 잘 안 알려졌으니 괜찮다”

공개 인터넷 환경에서는 스캐닝이 상시 발생한다. “발견되지 않음”은 보안 전략이 아니다.

오해 2: “민감 값은 마스킹되니까 env 열어도 된다”

일부 값이 마스킹되어도 키 이름, 구성 구조, 힌트 정보가 공격에 유의미할 수 있다.

오해 3: “운영도 개발처럼 *로 열어두고 나중에 닫자”

나중은 대개 오지 않는다. 기본값을 안전하게 두고, 필요한 것만 예외적으로 여는 쪽이 맞다.

8. 운영 적용 체크리스트

  • 운영 프로파일에서 management.endpoints.web.exposure.include를 최소화했는가
  • 외부 공개가 꼭 필요한 엔드포인트만 남겼는가 (health 등)
  • /actuator/** 접근을 인증/인가 규칙으로 분리했는가
  • Ingress/방화벽에서 경로 또는 소스 IP 제한을 추가했는가
  • 배포 후 실제 운영 URL에서 노출 상태를 점검했는가

체크리스트를 배포 파이프라인의 릴리즈 점검 항목으로 넣으면, 설정 회귀를 줄이는 데 도움이 된다.

마무리

Actuator는 운영 가시성을 크게 올려주는 도구다. 다만 운영 공개 범위를 통제하지 않으면, 관측 도구가 공격 표면으로 바뀔 수 있다.

정리하면 아래 한 줄로 충분하다.

  • 운영에서는 health 중심 최소 노출 + 인증/인가 + 네트워크 제한을 함께 적용한다.

처음부터 안전한 기본값을 만들면, 이후 운영 자동화와 온콜 대응도 훨씬 편해진다.