클라우드 전환 시 보안 인프라를 다시 설계해야 하는 이유

클라우드 보안 아키텍처가 온프레미스와 달라야 하는 이유

기업의 클라우드 전환은 이제 선택이 아닌 필수가 되었습니다. 비용 효율성과 유연한 확장성, 빠른 서비스 배포를 위해 많은 기업이 핵심 시스템을 퍼블릭 또는 프라이빗 클라우드로 이전하고 있습니다.

하지만 실제 프로젝트에서는 예상하지 못한 문제가 자주 발생합니다. 
"애플리케이션은 클라우드로 옮겼는데 기존 보안 체계를 그대로 유지할 수 있을까?"

온프레미스에서는 문제없이 동작하던 웹방화벽(WAF), IPS, IDS, SSL 가시화(SSL Visibility), DDoS 방어 장비 등이 클라우드에서는 기대했던 방식으로 동작하지 않는 경우가 적지 않습니다. 그 이유는 단순히 장비가 달라서가 아니라, 클라우드의 네트워크 구조 자체가 온프레미스와 근본적으로 다르기 때문입니다. 

클라우드에서는 네트워크 구조부터 달라진다

온프레미스 환경에서는 방화벽, IPS, WAF 등을 네트워크 경로에 물리적으로 배치해 트래픽을 원하는 순서대로 통과시키는 것이 일반적입니다.
그러나 클라우드에서는 대부분의 서비스가 VPC(Virtual Private Cloud) 기반으로 구성됩니다.

모든 서버와 보안 장비는 가상 네트워크 안에서 동작하며, 물리적인 L2 연결이나 브리지 방식으로 장비를 연결할 수 없습니다. 따라서 기존 데이터센터에서 사용하던 Transparent 방식의 보안 구성을 그대로 구현하기 어렵습니다.
즉, 클라우드에서는 단순히 보안 장비를 가상머신(VM)으로 올리는 것이 아니라, 트래픽이 어떤 경로로 이동할 것인지부터 다시 설계해야 합니다. 

클라우드 전환 시 가장 많이 발생하는 5가지 보안 제약

 

1. 보안 장비를 원하는 위치에 배치할 수 없다

온프레미스에서는 장비 사이를 직접 연결해 트래픽을 자유롭게 제어할 수 있습니다.
하지만 클라우드에서는 모든 통신이 가상 스위치와 라우팅 정책을 기반으로 이루어지므로 보안 장비 역시 하나의 라우팅 홉으로 동작합니다.

이 때문에 기존 인라인(Inline) 구조를 그대로 적용하기 어렵고, DPI(Deep Packet Inspection)나 여러 보안 장비 간 협업에도 제약이 발생합니다.

2. SNAT 때문에 원본 IP를 잃을 수 있다

클라우드에서는 응답 트래픽을 정상적으로 전달하기 위해 SNAT(Source NAT) 이 사용되는 경우가 많습니다.
문제는 이 과정에서 원본 클라이언트 IP가 변경될 수 있다는 점입니다.
원본 IP가 사라지면 다음과 같은 문제가 발생합니다.

• 실제 공격자의 위치 추적 어려움
• 세션 기반 보안 정책 정확도 저하
• 로그 분석 및 포렌식 한계
• 보안 가시성 감소
  

보안 장비는 정상적으로 동작하더라도 분석해야 할 정보가 달라지는 것입니다.

3. SSL/TLS 복호화도 원하는 대로 하기 어렵다

오늘날 대부분의 트래픽은 HTTPS 기반 암호화 통신입니다.
이를 분석하려면 SSL/TLS 복호화가 필요하지만, 클라우드에서 제공하는 기본 Load Balancer의 SSL Termination 기능은 전체 구간을 일괄 복호화하는 경우가 많습니다.

그러나 실제 운영에서는

• 특정 서비스만 복호화
• 개인정보 구간 제외
• 특정 보안 장비에서만 복호화

처럼 선택적 SSL 복호화가 필요한 경우가 많습니다.

특히 금융·공공기관처럼 개인정보 보호 요구사항이 높은 환경에서는 이러한 세밀한 제어가 더욱 중요합니다.

4. Redirect 방식이 아닌 라우팅 기반 설계가 필요하다

온프레미스에서는 L2 Redirect, GRE 터널, 정책 기반 라우팅(PBR) 등 다양한 방법으로 트래픽을 유도할 수 있습니다.
반면 클라우드는 대부분 정적인 라우팅 테이블을 기반으로 동작합니다.
즉, "필요한 트래픽만 IPS를 거치게 하자."와 같은 유연한 구성이 쉽지 않으며, 처음부터 전체 보안 아키텍처를 라우팅 중심으로 설계해야 합니다.

5. 고가용성(HA)은 선택이 아니라 필수

클라우드에서는 보안 장비 하나에 장애가 발생하면 서비스 전체가 영향을 받을 수 있습니다.

이를 방지하기 위해서는 아래를 함께 설계해야 합니다. 

• Active-Standby 구성
• Load Balancer
• Health Check
• Failover

하지만 이는 운영 복잡성과 비용 증가라는 새로운 과제를 동반합니다.

 

해결책은 '보안 장비'가 아니라 '트래픽 설계'

이러한 문제를 해결하기 위해 최근에는 클라우드 전용 L4/L7 스위치(ADC) 의 역할이 더욱 중요해지고 있습니다.
클라우드 기본 Load Balancer는 서버 부하분산(SLB)에 집중하지만, 실제 보안 환경에서는 다음과 같은 기능이 필요합니다.

• 서비스 체인(Service Chain)
• 조건부 SSL 복호화
• 보안 장비별 트래픽 분기
• WEB/Non-WEB 트래픽 분리
• 미러링 기반 탐지
• 인라인 보안 처리
• 장애 발생 시 자동 Failover

이처럼 트래픽을 원하는 보안 장비로 유연하게 연결하고 제어하는 기능이 있어야 기존 온프레미스 수준의 보안 정책을 클라우드에서도 구현할 수 있습니다.

 

공공기관이 요구하는 '3선 보안관제체계'도 클라우드에서 구현 가능

정부와 공공기관은 클라우드 환경에서도 3선 보안관제체계 구축을 요구하고 있습니다.
이를 위해서는 단순한 로그 수집이 아니라

• 미러링 기반 탐지
• 인라인 실시간 탐지
• SSL 복호화
• 서비스 체인
• 정책 기반 트래픽 제어

등을 함께 구현해야 합니다.

실제로 네이버클라우드 환경에서는 클라우드 전용 ADC를 활용해 프라이빗 보안 영역을 구성하고, WAF·IPS·IDS 등 다양한 보안 솔루션을 연계한 3선 보안관제체계를 구축한 사례가 있습니다. 이러한 방식은 정부의 클라우드 보안 권고사항을 충족하면서도 보안성과 가용성을 동시에 확보할 수 있는 현실적인 아키텍처로 활용되고 있습니다.

 

클라우드 시대의 보안은 '제품'보다 '아키텍처'가 중요하다

클라우드 전환은 서버를 옮기는 작업이 아니라 보안 아키텍처를 다시 설계하는 과정입니다.
온프레미스에서 검증된 보안 제품이라도 클라우드 환경에서는 동일한 방식으로 동작하지 않을 수 있으며, 네트워크 구조의 차이를 고려한 설계가 필수입니다.

앞으로의 클라우드 보안은 트래픽의 경로(Path) 를 중심으로 설계되는 방향으로 발전하고 있습니다. 선택적 SSL 복호화, 서비스 체인, 미러링 기반 탐지, 고가용성(HA)과 같은 기술을 적절히 조합해야만 클라우드의 유연성을 유지하면서도 기존 수준 이상의 보안성을 확보할 수 있습니다.
결국 성공적인 클라우드 전환의 핵심은 보안 제품을 클라우드에 배치하는 것이 아니라, 클라우드 환경에 최적화된 보안 아키텍처를 설계하는 것에 있습니다.