기업 시스템을 운영하다 보면 SSO(Single Sign-On) 연동을 위해 기존 웹 서버의 DNS 설정을 변경해 달라는 요청을 받게 됩니다. 특히, "기존 운영 서버 IP 대신 SSO 장비(L4)의 IP로 연결해 달라"는 요청은 처음 접하는 분들에게는 의문을 줄 수 있습니다.

"왜 내 서버로 바로 들어오지 않고 다른 IP를 거쳐야 할까?"

이 글에서는 이러한 요청이 발생하는 리버스 프록시(Reverse Proxy) 방식의 SSO 구조와 트래픽의 흐름, 그리고 보안상의 이점에 대해 명쾌하게 설명해 드립니다.

 

1. 리버스 프록시(Reverse Proxy) SSO란?

질문하신 상황은 전형적인 게이트웨이(Gateway) 또는 리버스 프록시 방식의 SSO 연동 구조입니다.

쉽게 비유하자면 다음과 같습니다.

  • 기존: 손님(사용자)이 건물(웹 서버)로 바로 들어옵니다.
  • 변경 후: 건물의 정문을 폐쇄하고, 모든 손님이 **'경비실(SSO 서버)'**을 통해서만 들어오도록 구조를 변경합니다.

즉, 사용자는 실제 웹 서버가 어디에 있는지 모른 채, 앞단에 있는 SSO 서버와만 통신하게 되는 것입니다.

2. 트래픽 흐름의 변화 (Before & After)

DNS 변경 전후, 사용자의 접속 경로가 어떻게 바뀌는지 구체적인 IP 흐름으로 살펴보겠습니다.

1) 기존 (Direct Access)

사용자가 도메인을 입력하면 운영 서버로 직행합니다.

  • 흐름: 사용자 PC -> my-web.com (DNS: 111.111.111.111) -> 웹 서버 접속
  • 특징: 웹 서버가 직접 로그인 세션을 관리해야 하며, 서버의 공인 IP가 노출됩니다.

2) 변경 후 (Reverse Proxy SSO)

사용자가 도메인을 입력하면 **SSO 장비(L4)**가 먼저 요청을 받습니다. 이것이 DNS IP를 변경해야 하는 이유입니다.

  • 흐름: 사용자 PC -> my-web.com (DNS: 222.222.222.222) -> SSO 서버(인증) -> 웹 서버(111.111.111.111)
  • 핵심: 사용자는 111... IP의 존재를 전혀 알 수 없습니다. 오직 222... IP와 통신합니다.

3. 상세 동작 프로세스 (Under the Hood)

DNS가 SSO L4 IP(222.222.222.222)로 변경된 후, 실제 접속 시 일어나는 일은 다음과 같습니다.

  1. 접속 요청 (Request): 사용자가 브라우저에 주소를 입력하면 요청이 SSO 서버에 도착합니다.
  2. 인증 확인 (Authentication): SSO 서버는 *"이 사용자가 로그인된 상태인가?"*를 확인합니다.
    • 로그인이 안 되었다면 -> SSO 로그인 페이지를 띄웁니다.
  3. 트래픽 전달 (Proxy Pass): 인증된 사용자라면, SSO 서버가 사용자 대신 뒤단에 숨겨진 **운영 VM(111.111.111.111)**으로 데이터를 요청합니다.
  4. 정보 전달 (Header Injection): 이때 SSO 서버는 HTTP 헤더에 사용자 정보(ID, 부서 등)를 실어서 보냅니다.
    • 예: SSO_USER_ID: hong.gildong
  5. 응답 (Response): 운영 VM은 헤더 정보를 신뢰하여 별도 로그인 없이 페이지를 생성해 반환하고, SSO 서버가 이를 다시 사용자에게 전달합니다.

4. 왜 이 방식을 선호할까요? (장점)

SSO 운영팀이 이 방식을 제안한 데에는 확실한 기술적/보안적 이유가 있습니다.

  • 에이전트리스 (Agentless): 운영 중인 웹 서버(VM)에 복잡한 SSO 에이전트 프로그램을 설치할 필요가 없습니다. 단순히 헤더 값만 읽도록 소스를 수정하면 되므로 개발 부담이 적습니다.
  • 보안 강화 (IP Masking): 운영 서버의 실제 IP(111...)가 외부로 노출되지 않습니다. 모든 공격은 앞단의 SSO 장비가 1차적으로 방어합니다.
  • 중앙 집중 관리: SSL 인증서 설치나 접근 제어 정책을 SSO 장비에서 일괄적으로 관리할 수 있어 효율적입니다.

5. 작업 전 필수 체크리스트

성공적인 연동을 위해 다음 사항들을 반드시 확인해야 합니다.

  • [ ] 방화벽(ACL) 정책 변경:
  • 기존에는 Any -> 111... 접근을 허용했지만, 이제는 보안을 위해 오직 SSO IP(222...)에서만 111...로 접근 가능하도록 방화벽을 좁혀야 합니다. (우회 접속 차단)
  • [ ] 백엔드 매핑 설정:
  • SSO 장비 쪽에 my-web.com 요청이 들어오면 111.111.111.111로 포워딩하라는 설정이 되어 있는지 확인하세요.
  • [ ] 애플리케이션 소스 수정:
  • 기존 세션 방식이 아닌, HTTP 요청 헤더(Header)에서 사용자 ID를 추출하도록 로직 변경이 필요합니다.

결론: 보안과 편의성을 동시에

DNS 설정을 L4 IP로 변경하는 것은 단순한 주소 변경이 아니라, 시스템의 보안 아키텍처를 '직접 접속'에서 '안전한 중계 접속'으로 업그레이드하는 과정입니다.

  • 네이버 블러그 공유하기
  • 네이버 밴드에 공유하기
  • 페이스북 공유하기
  • 카카오스토리 공유하기