최소 실행 가능 네트워크의 힘

클라우드 네트워킹에 대한 이해는 클라우드 여정을 시작하는 조직이 겪는 가장 큰 변화 중 하나입니다. 주소 체계와 구성 요소를 살펴보면 IP 네트워크처럼 보입니다. 대부분의 관점에서 실제로도 그렇습니다. 그러나 다른 많은 영역에서는 그렇지 않습니다. 클라우드에서 제공되는 것과 같은 소프트웨어 정의 네트워크(SDN)는 물리적 네트워크와 동일한 제약을 받지 않으며, 이는 처음 접할 때 상당히 혼란스러울 수 있습니다.

SDN이 물리적 네트워크와 어떻게 다른지 이해하려 하기보다는, 네트워크가 무엇을 해야 하는지, 그리고 더 중요하게는 무엇이 허용되어서는 안 되는지에 집중해 보겠습니다. “기본 거부(default deny)”라는 개념을 기억하실 수도 있습니다. 명시적으로 허용하지 않은 연결은 기본적으로 차단된다는 의미였습니다. 그 후 웹이 등장했고, 거의 모든 애플리케이션이 포트 80과 443을 사용했기 때문에 이를 제한하는 것은 불가능해졌습니다. 게다가 “기본 거부”는 경계를 넘어서까지 적용되지 못했고, 내부 네트워크는 평면적이고 개방적인 형태를 띠면서 외부의 악성 트래픽을 걸러내기 위해 DMZ에 의존했습니다. 거듭된 침해 사고가 보여주듯이, 이 모델의 효과는 제한적입니다.

그러나 SDN을 활용하면 “최소 실행 가능 네트워크(Minimum Viable Network)”라고 부르는 개념을 통해 기본 거부에 훨씬 더 가까이 다가갈 수 있습니다. 이 개념은 업무 수행에 필요한 요소만으로, 그 이상은 포함하지 않는 맞춤형 네트워크를 구축할 수 있게 해줍니다.

최소 실행 가능 네트워크는 먼저 애플리케이션 아키텍처를 결정한 다음, 해당 애플리케이션을 지원하는 데 필요한 네트워킹만을 생성하고, 최소 권한 라우팅과 보안 그룹을 적용하며, 클라우드 로드 밸런서와 같은 PaaS 구성 요소도 활용해야 합니다. 이를 통해 패킷 교환 네트워크는 사실상 회선 교환 네트워크로 바뀌며, 애플리케이션 구성 요소는 허용된 다른 구성 요소와만 통신할 수 있고 그 사이의 트래픽은 (일부 경우 클라우드 제공업체를 제외하고) 누구도 스니핑할 수 없습니다. 네트워크는 그 외 모든 트래픽을 폐기합니다. 네트워크 자체가 전체적으로 최소 권한과 기본 거부를 따르므로, 전통적인 DMZ나 네트워크 존과 같은 구성이 더 이상 필요하지 않습니다.

예시를 통해 좀 더 구체적으로 살펴보겠습니다. 공개용 Application Load Balancer를 두고, 그 뒤의 프라이빗 서브넷에 로드 밸런서의 트래픽만 수락하는 웹 서버를 배치하는 전통적인 3계층 애플리케이션 스택을 구성할 수 있습니다. 웹 서버는 자신의 연결을 수락하는 애플리케이션 서버에만 연결할 수 있습니다. 마찬가지로 애플리케이션 서버는 해당 연결을 허용하는 데이터베이스로만 트래픽을 보낼 수 있습니다. 각 계층은 기본 거부 상태이며, 로드 밸런서로부터의 인바운드 연결과 데이터베이스로의 아웃바운드 연결만 허용합니다. 많은 경우, 클라우드 제공업체가 관리하는 매우 안전한 PaaS 구성 요소인 퍼블릭 로드 밸런서를 제외하면 인터넷 연결 없이(프라이빗 서브넷에서) 이를 구현할 수 있습니다.

네트워크를 먼저 구축하고 그 안에 애플리케이션을 배치하는 대신, 애플리케이션을 설계한 후 그 요구 사항에 맞춰 네트워크를 구성하는 것입니다. 이 방식은 애플리케이션 스택의 공격 표면을 크게 줄이고, 그에 따라 위험도 감소시킵니다.

당사는 securosis.com 사이트를 구축할 때 이러한 원칙을 적용했으며, 아래 아키텍처 다이어그램에서 이를 확인하실 수 있습니다. 네트워크 보안 관점에서 이 설계를 살펴보면 다음과 같습니다.

• 클라우드 WAF에서 접근이 제한되어 정상 트래픽만 VPC로 전달됩니다.
• 애플리케이션 로드 밸런서(ALB)는 공개용 서브넷에 있는 유일한 리소스이며 80/443 트래픽만 허용합니다.
• 모든 인스턴스는 프라이빗 서브넷에 있으며 ALB의 트래픽만 수락합니다.
• “admin” 인스턴스는 로그인을 수락하지만, 다른 환경에서 호스팅되는 VPN을 통해서만 가능합니다.
• 그림에 표시되지 않은 RDS 데이터베이스용 서브넷 역시 프라이빗 전용이며, 인스턴스의 트래픽만 수락합니다. 데이터 정제를 위해 직접 로그인이나 RDBMS 접근이 필요한 경우에는 보안 그룹 규칙을 변경하여 일시적으로 접근을 허용합니다.
• S3 연결은 서비스 엔드포인트를 통해 이루어지므로 인터넷 접속을 위한 NAT 게이트웨이가 필요하지 않습니다.
• admin 이외의 인스턴스에서는 SSH가 비활성화되어 있습니다. 이들 인스턴스는 오토스케일링되는 불변(immutable) 인스턴스로, 기본 이미지를 변경하는 방식으로만 수정됩니다.
• 수평 공격을 방지하기 위해 자기 참조 보안 그룹(내부 접근을 허용하는 보안 그룹)은 사용하지 않습니다. AWS의 보안 그룹은 서브넷 수준이 아닌 리소스 수준에서 작동하므로 동서(East/West) 방향 공격을 차단하는 데 매우 효과적입니다.
• 이 아키텍처는 전체 공격 표면을 크게 줄입니다. 네트워크는 최소한으로 필요한 연결만 허용하며, 접근에 필요한 최소한의 서브넷과 라우팅 테이블만 포함합니다. 사실상 네트워크를 애플리케이션에 맞춘 것입니다. 실제로 네트워크는 애플리케이션 스택의 아키텍처가 설계된 이후에야 설계되었습니다.
• 이는 소규모 사이트의 매우 단순한 예시이지만, 동일한 원칙을 더 많은 계층, 내부 로드 밸런서, API 게이트웨이, PaaS 구성 요소를 갖춘 훨씬 큰 아키텍처에도 적용할 수 있습니다.

보시다시피 클라우드 네트워킹 구성 요소를 사용하면 매우 높은 유연성을 확보할 수 있습니다. 기존 네트워크에 애플리케이션을 맞추는 것이 아니라, 애플리케이션이 필요로 하는 네트워크를 구축할 수 있게 된 것입니다. 그러나 이러한 유연성에는 설정을 잘못 구성하여 인프라의 상당 부분을 공개 인터넷에 노출시킬 수 있는 위험도 따릅니다. 따라서 (DisruptOps가 제공하는 것과 같은) 클라우드 보안 운영 플랫폼으로 클라우드 보안 상태를 모니터링하고 모범 사례를 적용하실 것을 항상 권장드립니다.