Secure Web Gateway 이전: 전환 및 롤백 체크리스트

secure web gateway 의 마이그레이션은 웹 트래픽 검사 및 정책을 한 프록시 플랫폼에서 다른 플랫폼으로 이전하는 과정으로, 온프레미스 어플라이언스에서 새로운 어플라이언스로, 클라우드 서비스로, 또는 하이브리드 모델로 이전하는 경우를 모두 포함합니다. 이 체크리스트는 자산 현황 파악, 대상 설계, 정책 변환, 롤백 준비, 시범 운영, 테스트, 단계별 전환, 그리고 인수 검증에 이르는 전체 과정을 다룹니다.

이 문서는 ‘하이브리드 클라우드 보안’ 가이드의 일부입니다. 시만텍( Blue Coat ) ProxySG 및 Symantec Edge SWG에 대한 자세한 내용은 ‘Blue Coat ’ 및 ‘ProxySG 지원 종료: 마이그레이션 계획’을 참조하십시오.

1단계: 현황 파악

1단계에서는 설계 작업을 시작하기 전에 현재의 게이트웨이 인프라, 트래픽 유도, 신원 확인, TLS 검사, 정책 및 통합 현황을 파악합니다.

인프라

• 모든 게이트웨이: 모델, 소프트웨어 버전, 위치, 역할 및 지원 종료일 (ProxySG 및 Edge SWG의 경우, Broadcom의 수명 주기 문서를 참조하십시오)
• 사이트별 트래픽 양 및 최대 처리량 (TLS 복호화 비율 포함)
• 사이트별 및 원격 접속 사용자 수
• 상류 및 하류 프록시 연쇄, 부하 분산 장치, 장애 조치 설계

교통 유도

• 명시적 프록시 설정, PAC 파일 및 WPAD
• 투명한 차단 지점 (WCCP, 정책 기반 라우팅)
• 지점 간 터널(IPsec, GRE)
• 엔드포인트의 에이전트
• 인터넷 직접 판매 예외 사항

정체성

• 인증 영역 (SAML, Kerberos/IWA, LDAP, 클라이언트 인증서)
• 정책에서 사용되는 그룹 매핑
• 인증되지 않은 트래픽(서버, IoT, OT) 및 이에 대한 처리 방식

TLS 검사

• 검사 CA, 주요 위치, 유효기간 및 배포 방법
• 이유 및 담당자가 명시된 암호 해독 우회 목록

정책

• 규칙 순서, 카테고리, 사용자 정의 목록 및 예외를 포함한 전체 정책 내보내기
• 지난 90일 동안 조회수가 없는 규칙 (폐지 대상)

통합

• DLP, 안티바이러스 및 샌드박싱과의 ICAP 연결
• SIEM 및 보고 도구로의 로그 전달
• 모니터링 및 알림

2단계: 타깃 설계

2단계에서는 각 사이트와 사용자 그룹에 대한 검사 대상과 트래픽, 인증서, 로그를 어떻게 처리할지 결정합니다.

• 각 사이트 및 사용자 그룹에 대한 검사가 온프레미스, 클라우드, 또는 하이브리드 환경 중 어디에서 수행될지 결정합니다.
• 각 경우에 대한 트래픽 유도 방식을 정의하십시오: 관리 대상 네트워크의 경우 명시적 프록시 또는 PAC, 로밍 사용자의 경우 에이전트 또는 브라우저 제어, 지사의 경우 터널
• 각 데이터 흐름이 한 번만 복호화되도록 TLS 검사 위치를 확인하십시오. NSA 지침에 따르면, 기업 네트워크 내에서 한 번만 검사를 수행하고, 연쇄된 프록시를 통한 중복 검사를 피해야 합니다 (NSA).
• 복호화된 피크 처리량 및 향후 성장분을 고려한 용량
• 고가용성 및 장애 대응 방식 설계
• 로그 및 DLP 증거 자료를 어디에 저장할지 결정하십시오
• 새로운 검사 CA를 계획하거나 기존 검사 CA를 이전하고, 지원되는 키 저장 방식 및 필요한 HSM 통합 사항을 확인하십시오.

3단계: 정책 반영

3단계에서는 직접적인 파일 변환이 아닌, 체계적이고 검증된 매핑 과정을 통해 기존 정책을 새로운 플랫폼으로 전환합니다.

• 각 소스 규칙을 이에 상응하는 대상 규칙에 매핑하거나, 폐기 대상으로 표시하십시오.
• 공급업체별 URL 범주를 매핑하고, 영향력이 큰 범주에 대한 차이점을 검토합니다.
• 사용자 지정 목록, 허용 목록 및 차단 목록을 다시 생성합니다.
• 인증에 따라 달라지는 규칙을 변환하고 그룹 매핑을 확인합니다.
• 암호 해독 우회 방법을 재현하고, 각 방법에 대한 필요성이 여전히 있는지 검토하십시오.
• 가능한 경우 ICAP 기반 DLP 핸드오프를 플랫폼 자체의 데이터 보호 서비스로 대체하고, 검사가 어디에서 이루어지는지 확인하거나 통합 기능을 재구축하십시오.
• 구성 변경 관리 프로세스에 따라 모든 변경 사항과 폐지된 규칙을 그 사유와 함께 기록하십시오(NIST SP 800-128에는 보안 중심의 구성 관리 관행이 설명되어 있습니다).

일부 플랫폼에서는 기존 정책을 자동으로 가져올 수 있는 기능을 제공합니다. 어떤 방식으로 가져오더라도, 이는 여전히 검토와 테스트가 필요한 출발점일 뿐임을 명심하십시오.

4단계: 롤백 준비

4단계에서는 시범 운영에 앞서 롤백 트리거와 메커니즘을 정의합니다. 시범 운영 기간 동안 롤백을 테스트하고, 각 본격 운영 단계에 앞서 준비 상태를 확인합니다.

롤백 트리거 (예시)

• 약정된 임계값을 초과하는 인증 실패
• 합의된 시간보다 더 오랫동안 비즈니스에 필수적인 애플리케이션을 사용할 수 없는 경우
• 기준치의 일정 배수를 초과하는 헬프데스크 티켓
• 보안 통제 조치가 적용되지 않는 것으로 확인됨

롤백 메커니즘

• 최종 인수 시까지 기존 게이트웨이를 계속 가동하고 패치를 적용해 두십시오.
• PAC 파일, DNS 및 라우팅 변경 사항에 버전 관리를 적용하여 필요 시 원상 복구할 수 있도록 하십시오
• 롤백 예상 시간을 산정할 때 DNS 및 PAC 캐싱 시간을 고려해야 합니다.
• 전환 기간 동안 기존 검사 인증 기관(CA)이 기기에서 계속 신뢰 대상인지 확인하십시오.
• 롤백을 승인할 수 있는 담당자를 지정하고, 해당 절차를 문서화하십시오.
• 시범 운영 기간 동안 테스트 롤백을 수행하고, 각 전환 단계에 앞서 준비 상태를 확인하십시오.

5단계: 시범 운영

5단계에서는 기존 게이트웨이와 병행하여 새로운 게이트웨이에서 대표 시범 그룹을 운영하며, 이 기간은 최소한 한 번의 비즈니스 주기를 포함한다.

• 주요 부서, 기기 유형 및 위치를 대표하는 시범 사용자를 선정하되, 여기에는 IT 담당자와 소수의 비즈니스 파워 유저도 포함됩니다.
• 기존 게이트웨이와 새 게이트웨이를 병렬로 운영하십시오
• PAC, 에이전트 또는 라우팅 변경을 통해 파일럿 트래픽을 새로운 게이트웨이로 유도하되, 이러한 변경 사항은 신속하게 원상복구할 수 있어야 합니다.
• 시범 사용자들이 문제를 보고할 수 있는 명확한 경로를 마련해 주세요
• 해당되는 경우 월말까지 포함하여 최소한 한 번의 완전한 사업 주기가 끝날 때까지 시범 운영을 유지하십시오.

6단계: 테스트

6단계에서는 인증부터 성능, 장애 조치에 이르기까지 사용자가 차이를 체감할 수 있는 모든 영역을 테스트합니다.

7단계: 단계별 전환

7단계에서는 위험도가 가장 낮은 사이트부터 시작하여, 사용자와 사이트를 단계적으로 새로운 게이트웨이로 이전합니다.

• 위험도와 복잡도에 따라 사용자와 사이트를 ‘웨이브’로 묶되, 위험도가 낮은 사이트부터 시작하십시오.
• 지원 담당자와 사전에 각 단계에 대해 소통하십시오.
• 주요 업무 시간대를 피하여 일정을 조정하십시오
• 각 공격 물결이 시작될 때 처음 몇 시간 동안은 비상대책본부를 운영한다
• 기준치와 비교하여 헬프데스크 티켓, 차단율 및 오류율을 모니터링합니다.
• 다음 단계로 넘어가기 전에, 각 단계 사이에 잠시 멈춰서 문제를 해결하세요

8단계: 인수 및 폐기

8단계에서는 수용 기준이 충족되었음을 확인한 후, 기존 게이트웨이, 인증서 및 계약을 폐기합니다.

수락 기준 (예시)

• 모든 사용자와 사이트가 이전되었습니다.
• 헬프데스크 문의 건수가 2주 만에 정상 수준으로 회복
• 프로덕션 환경에서 모든 테스트 케이스가 통과됨
• 보안 운영 및 규정 준수 부서에서 검증한 로그 및 보고서
• 예외 목록 검토 및 승인 완료

운용 종료

• PAC 파일, 라우팅 및 DNS에서 오래된 게이트웨이를 제거합니다.
• 교체된 경우, 기기에서 기존 검사용 CA를 취소하고 제거하십시오.
• 보존 정책에 따라 오래된 로그를 아카이브합니다.
• 하드웨어를 안전하게 초기화하고 폐기하기
• 라이선스 및 지원 계약 종료

일반적인 일정

소요 기간은 상속 재산의 규모와 보험 계약의 복잡성에 따라 달라집니다.

단일 사업장 조직의 경우 몇 주 만에 마이그레이션을 완료할 수 있습니다. 대규모 다중 사업장 기업의 경우, Skyhigh Security.

Skyhigh가 SWG 마이그레이션을 지원하는 방법

Skyhigh는 병렬 배포, 검증된 CPL 정책 가져오기 및 유연한 배포 모델을 통해 SWG 마이그레이션을 지원합니다.

Skyhigh Hybrid SSE Mesh는 기존 게이트웨이와 함께 배포되므로, 전환 전에 병렬 트래픽을 통해 정책을 검증할 수 있습니다. Skyhigh는 검증된 가져오기 프로세스를 통해 기존 Blue Coat CPL 정책을 통합 정책 콘솔에서 재구성하며, 정책은 Skyhigh 클라우드 콘솔에서 작성됩니다. 웹 및 사내 애플리케이션 정책은 온프레미스 게이트웨이에서 적용될 수 있으며, 클라우드 기반 데이터 보호가 필요한 트래픽은 Skyhigh 클라우드로 전달됩니다. 원격 사용자에게는 클라우드 PoP(Point of Presence)를 통해 서비스가 제공됩니다. Skyhigh SWG는 온프레미스, 하이브리드 또는 클라우드 환경에서 모두 실행되므로, 마이그레이션 시 배포 모델을 변경할 필요가 없습니다. ‘Blue Coat ’ 현대화 프로그램은 적격 고객을 대상으로 서비스 지원 및 상업적 비용 상쇄 혜택을 제공합니다.

출처

1. NSA. 전송 계층 보안(TLS) 검사에서 발생하는 위험 관리 (2019년 11월). https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
2. NIST. SP 800-128: 정보 시스템의 보안 중심 구성 관리를 위한 지침. https://csrc.nist.gov/pubs/sp/800/128/upd1/final
3. 브로드컴. Edge SWG(ProxySG) 및 Advanced Secure Gateway의 단종 및 제품 수명 주기 (KB 151102). https://knowledge.broadcom.com/external/article/151102/end-of-life-and-product-lifecycle-for-pr.html
4. Skyhigh Security. “Skyhigh Hybrid SSE Mesh를 활용한 시만텍 엣지 Secure Web Gateway 현대화” (2026년 7월 15일). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html
5. Skyhigh Security. “Skyhigh SSE 플랫폼으로 하이브리드 도입이 한층 더 쉬워졌습니다” (2024년 10월 3일). https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html