안전하게 Cloud 사용하기#2 - 네트워크 보안

1. 가상 네트워크 설계

Cloud에서는 각 고객별로 가상의 네트워크를 제공합니다. 이는 물리적으로 같은 환경 내에서, 고객별로 전용 사설 클라우드를 운영할 수 있다는 뜻이죠.

 

각 고객은 자신의 가상 네트워크를 다시 분리할 수 있습니다. 이를 Subnet이라 합니다. 같은 Subnet은 보안 위협이 전파 가능한 상태로 간주되므로, 네트워크를 분리하여 보안 위협 전파를 방지할 수 있습니다.

 

KT Cloud 또한 모든 고객에 Virtual Network과 Subnet을 제공하며, Subnet은 Tier라 부릅니다.

 

각 Subnet은 통신을 제한할 수 있으며, 이를 위해 ACL(Access Control List)이나 방화벽(Firewall)으로 불리는 서비스를 사용하게 됩니다. 여기서는 Stateful Inspection기반의 동적 필터링이 가능할 경우 방화벽으로, 그렇지 않을 경우 ACL로 부르겠습니다. (Stateful Inspection이란, 보낸 트래픽에 대한 응답 트래픽은 별도의 방화벽 허용 정책 없이 통신이 가능한 기술입니다) 

 

 

1-1. Subnet

Subnet은 VM(가상서버)의 네트워크를 격리하는 것으로, IP 대역을 기준으로 분리합니다.

 

이는 병원에 비유하여 이해할 수 있는데, 각 VM을 사람, 각 subnet을 병실, 네트워크 전체를 하나의 병원으로 생각하면 됩니다. 감염자의 전파를 막기 위해, 모든 사람을 병실에 위치시키고, 각 병실은 외부와의 접촉을 차단하는 것 처럼 말이죠.

병실을 어떻게 나눌 것인지가 Subnet의 문제이고, 각 병실 내의 출입 정책이 방화벽의 문제입니다. (병원에 방문하는 사람들에 대한 검사 체계가 침해대응으로 볼 수 있습니다.)

 

보안 관점에서 네트워크는 최대한 세분화시켜 격리하는 것이 좋지만, 이는 운영 관점에서의 불편함을 야기합니다. 그렇기에 각 Subnet은 비슷한 성향을 가진 VM들을 묶어서 만드는 것이 일반적입니다.

 

예를 들어 Subnet을 2개(DMZ, Private)로 분리하여, 인터넷(Public)과 통신하는 VM들은 DMZ에, 그렇지 않은 VM들은 Private에 위치시킵니다. Private의 경우 비즈니스 로직부와 데이터를 분리하여, 3개의 Subnet을 운영하는 경우도 일반적입니다.

또한, Cloud에서 개발과 상용 서버를 같이 운영할 경우 개발과 운영을 분리하기 위해 Subnet을 추가할 수도 있습니다.

 

개발과 상용을 분리하고, 개발에서는 상용 부분에 접근이 불가능하도록 합니다. 또한 상용에 대해서도 DMZ/Logic/DB로 Subnet을 분리한뒤, DMZ > Logic > DB 순으로만 통신하는 것이 좋습니다.

 

1-2. 방화벽과 ACL

방화벽과 ACL은 네트워크의 접속을 어떻게 허용할지를 정합니다.

 

KT Cloud에서는 Whitelist 방식의 방화벽을 제공합니다. 이는 모든 트래픽을 차단하며, 그 중 어떤 트래픽을 허용할지를 정하는 것으로, 마치 모든 면을 벽으로 감싼 뒤, 문을 만드는 개념으로 이해할 수 있습니다.

 

ACL과 방화벽의 Stateful Inspection 유무는 보안관점에서 큰 차이를 만들어 냅니다. 일반적인 TCP 통신의 경우, 통신을 시작하는 주체와 응답하는 주체가 존재합니다. Stateful Inspection은 통신을 시작하는 주체에 대해서만 방화벽 정책을 넣으면 이에 대한 응답은 막지 않는 것을 의미합니다.

웹서버를 예로 들면 ACL의 경우, 들어오는 통신에 대해서 모두 허용하고, 나가는 통신에 대해서도 모두 허용해주어야 합니다. 이 때, 정상 응답이 아닌 통신으로 데이터가 유출될 수 있죠.

반면 방화벽은 들어오는 통신에 대해서만 허용해 주면, 이를 방화벽이 기억해 정상 응답만 통신을 허용해줍니다.

 

방화벽 정책은 최소한으로만 허용하는 것이 중요합니다. 이를 위해서는 각 애플리케이션에서의 Flow 설계가 매우 중요합니다. 통신의 시작이 어디인지, 각 상황별로 어떤 Port를 사용할지, 통신할 VM은 무엇인지 등이 정의되어야 합니다.

 

만약, 각 애플리케이션 운영자별로 보안을 관리한다면 네트워크 방화벽에서 차단하지 않고 각 VM 내에 방화벽을 설치하여 운영하는 방안을 고려할 수도 있습니다.

 

1-3. 전용회선과 VPN

고객사의 기존 네트워크와 클라우드, 또는 협력사 네트워크와 클라우드 네트워크를 연결할 때 전용회선이나 VPN을 고려할 수 있습니다.

 

일반적으로는 VPN은 전용회선을 대체할 수 있는 안전한 수단으로 여겨집니다. 따라서, 대역폭이나 속도 등 네트워크 품질 보장 측면에서 전용회선을 검토하거나 비용적인 측면에서 VPN 사용을 고려할 수 있습니다.

 

 

2. 네트워크 보안

모든 서비스는 외부와의 통신을 하게 되므로, 취약점을 내포하게 됩니다. 이에 따라, Cloud에서도 침해를 대응할 수 있는 체계를 갖추어야 합니다.

서버 방어를 위해 주로 고려되는 네트워크 보안 솔루션은 앞에서 소개한 방화벽, VPN에 더해 IPS, Anti-DDoS, WAF 등이 고려됩니다.

 

설계 관점에서는 계층적 보안 체계를 구축한다는 관점에서 접근해야하며, 단순히 솔루션을 구축하는 것뿐 아니라 운영, 관리하는 것까지도 고려해야 합니다.

KT Cloud의 경우 아래의 IPS, Anti-DDoS, WAF 등의 네트워크 솔루션에 대해 Managed 보안관제 서비스라는 보안 관제 및 운영 대행 서비스를 제공하고 있습니다.

 

2-1. IPS

외부에서의 침입 시도를 탐지하고 차단하는 시스템을 IPS라 합니다. IPS는 Host방식과 Network방식으로 구분됩니다.

 

Host IPS의 경우 각 VM에 설치되어 내부 감염의 전파를 방어할 수 있다는 것과 고객사의 Cloud 영역에서 온전히 솔루션을 관리할 수 있다는 장점이 있지만, 리소스의 제약으로 정밀한 탐지를 수행하기는 어렵습니다. 이러한 문제를 해결하기 위해서는 애플리케이션 관점에서 더 많이 보안을 고려해야 합니다.

 

반면 Network IPS의 경우 네트워크 경계에 설치되어 침입 시도를 방어합니다. Network IPS의 경우에는 경계 기반 보안을 전제로 하므로, 다양한 리전에 VM을 구성할 경우에는 적합하지 않습니다.

 

KT Cloud는 Host방식과 Network방식의 IPS를 모두 제공하고 있으며, Host방식은 Marketplace를 활용해 고객이 라이선스를 구매하고 VM에 설치하여 구성할 수 있습니다. 반면 Network방식은 VPC를 신청해 전용장비를 구매하거나, Enterprise Security의 공유형 IPS로 사용할 수 있습니다.

 

2-2. Anti-DDoS

Anti-DDoS는 서비스의 가용성을 보장하기 위해 필요합니다.

 

클라우드 전체 네트워크의 가용성을 위해 기본적인 DDoS 방어 체계를 제공하지만, 각 고객별 가용성을 보장하고 있지는 않습니다. 이를 위해 고객사의 서비스의 품질을 보장하기 위해서는 추가적인 DDoS 방어 체계를 고려해야합니다.

 

KT의 경우 24시간 관제를 포함한 Clean-zone 서비스를 제공하고 있습니다. 그 외에도 비용적 측면을 고려해 Marketplace에서 제3자의 서비스를 이용하거나, CDN 형태로 제공되는 외부의 서비스를 사용할 수 있습니다.

 

2-3. WAF

오늘날 대부분의 서비스가 웹을 기반으로 제공하고, 웹 서비스는 모든 접속을 허용하게 되므로 IPS와 방화벽으로 침입을 차단하는 것에 한계가 있습니다. 이에 웹 애플리케이션에 대해 강화된 보호를 제공하는 WAF 서비스를 검토해야 합니다.

 

WAF의 경우 OWASP TOP 10 등을 포함해 주요 공격에 대한 필터링 정책이 포함됩니다. 일반적으로 WAF는 웹 서버 앞단에서 Proxy 형태로 구축하게 됩니다.

 

특히, 최근 암호화된 트래픽이 많고 WAF에서 복호화를 수행할 경우 성능적 저하가 발생할 수 있습니다. 이러할 경우 별도의 복호화 시스템을 이용할 수 있습니다.

 

KT Cloud의 경우 3rd-Party 제품과 협업해 KT Cloud WAF 서비스를 제공하고 있습니다.

 

관련글

안전하게 Cloud이용하기-접근제어 - https://ktcloudplatform.tistory.com/74