실용적인 관점에서 바라본 (마이크로)세그멘테이션

모범 사례와 전략을 시작하기 전에 먼저 배경을 정의해야 합니다. 네트워크 세그먼테이션은 네트워크를 부분(세그먼트)으로 ‘분할’하고 누가 무엇을, 어떤 방식으로 접속할 수 있는지(예: HTTP/S를 통해서만 웹 서버에 접속할 수 있음) 정의하는 것을 포함합니다. 

기존에는 VLAN과 물리적 방화벽을 사용하여 이러한 작업을 수행했지만 최근에는 방화벽 및 세그멘테이션에 대한 소프트웨어 기반 접근 방식이 점점 더 많아지고 있습니다(Akamai Guardicore Segmentation참조). 우리는 어느 한 가지 방법만 추천하지는 않을 것입니다. 두 가지 방법 모두 장단점이 있기 때문입니다. 우리의 권장 정책 및 전략은 벤더사에 구애받지 않으며 어디에든 적용할 수 있습니다.

VLAN, ACL(접속 제어 목록) 및 IP 범위를 사용한 트래픽 제어에서 벤더사에 구애받지 않는 사용자 지정 레이블 사용으로 전환하면 마이크로세그먼테이션의 영역으로 들어가게 됩니다. 이 블로그 게시물의 모든 전략은 우리가 마이크로세그멘테이션을 사용하고 있다고 가정합니다.

세그멘테이션이 필요 없도록 전략과 가이드라인을 조정할 수 있어야 하지만, 모든 VLAN, ACL 및 IP 목록을 정의한 다음 유지 관리하는 프로세스는 비현실적일 수 있고 모든 네트워크 관리자와 엔지니어가 극도의 피로감을 느낄 수도 있습니다. (모든 재무 서버의 IP 범위/그룹을 정의한다고 생각해 보세요. 작업 자체는 가능할지 모르지만, 해당 목록을 오랫동안 정확하게 유지할 수 있을까요? 또한 이는 서버 그룹이 하나뿐일 때의 이야기입니다. 엔터프라이즈 네트워크에는 보통 최종 사용자, 도메인 컨트롤러, 도메인 관리자, 프린터를 비롯한 수많은 그룹이 있기 마련입니다.)

세그멘테이션 방법에 대해 논의하기 전에 먼저 IT의 주요 전제 조건인 가시성에 대해 논의해 보겠습니다. 마이크로세그멘테이션은 고립되어선 안 됩니다. 볼 수 없는 공격은 방어할 수도 없습니다. 양호한 세그멘테이션은 트래픽을 구성하고 요약하는 네트워크 가시성이 뒷받침되어야만 효과적입니다.. 그러나 일반적으로 모든 것을 육안으로 분석하기에는 트래픽이 너무 많습니다.

실제 세그멘테이션 전략을 시작하기 전에 우리는 좋은 세그멘테이션을 위해 중요하다고 생각되는 몇 가지 가이드라인 또는 원칙에 대해 논의하고자 합니다.

일반적으로 웹 또는 파일 서버와 같이 수신 트래픽이 많은 서버는 요청을 처리하는 쪽에 더 가깝습니다(도메인 컨트롤러도 이 카테고리에 속함). 이 경우 발신 트래픽이 그렇게 많지 않거나, 최소한 엄격하게 정의되어야 합니다. 

또한 출력 및 입력에 대한 제한을 최소화하면 공격자가 서버에 보다 쉽게 접속할 수 있고 서버를 통해 네트워크의 더 넓은 부분에 접속할 수 있어 서버가 공격자의 피벗으로 이용될 리스크가 있습니다.

머신에서 나오는 트래픽이 너무 가변적이어서 정책을 느슨하게 유지해야 하는 머신들이 있습니다. 이 경우 많은 예외가 필요합니다. 

점프 박스 서버의 예를 들어 보겠습니다. 이 서버는 여러 사용자가 서로 다른 프로토콜을 사용해 서로 다른 서버에 연결하는 데 사용됩니다. 지나치게 허용적이지 않으면 모든 사용 사례를 다룰 수 없지만, 이렇게 되면 세그멘테이션의 진정한 목적에 배치됩니다. 

이러한 경우에는 다른 방어 메커니즘 을 대신 사용하여 좀 더 엄격하게 만드는 것이 최선이라고 생각합니다(예: 점프 박스에 더 강력한 사용자 접속 제어를 사용하거나 서비스 모니터링에 더 낮은 알림 임계값 사용).

세그멘테이션을 시작할 때는 일부 트래픽 가닥이 이미 존재한다고 해서 이를 허용해야 하는 것은 아닙니다. 애플리케이션이나 서버가 생성하는 트래픽이 불필요하다고 판단되어 기존 애플리케이션 또는 서버 구성을 수정해야 하는 경우가 있습니다. 때로는 특정 트래픽이 처음부터 존재하는 이유를 파악하기 위해 기존 구성을 참조해야 할 수도 있습니다.

이 경우 세그멘테이션은 기존 방화벽과 같습니다. 즉, 네트워크 외부에서 들어오는 트래픽이 유입되지 않도록 차단합니다. 이 작업은 일반적으로 인터넷에서 이루어지지만 사용자의 네트워크에 연결된 타사 네트워크에서 비롯될 수도 있습니다. 

따라서 노출된 SSH(Secure Shell) 또는 RDP(Remote Desktop Protocol) 포트(또는 기본적으로 측면 이동 섹션의 모든 포트)를 차단하는 것이 좋습니다. 실제로 네트워크 외부, 특히 인터넷에서 발생하는 트래픽에는 특히 일정 시점에 활성화된 인터넷 스캐너 수를 고려할 때 거부 목록 대신 허용 목록을 사용하는 것이 좋습니다.

물론 다른 보안 툴과 마찬가지로, 관행(또는 정책) 세그멘테이션이 위협에 맞서는 유일한 수단은 아닙니다. 이 경우 세그멘테이션은 모든 초기 접속 기법을 포괄할 수 없으며, 세그먼트에만 의존하면 네트워크가 리스크에 노출됩니다. 수많은 보안 유출이 피싱 이메일이나 링크 또는 기타 형태의 소셜 엔지니어링을 발단으로 시작됩니다. 

때로는 허용되어야 하는 프로토콜의 취약점 또는 VPN 서버와 같이 합법적으로 인터넷에 노출되는 서비스에 대한 취약한 인증정보로 시작됩니다. 이러한 이유로 초기 접속을 방지하기 위해 세그멘테이션에만 의존하기보다는 호스트 및 이메일 보호를 위한 보안 솔루션을 추가적으로 사용하는 것이 좋습니다.

측면 이동을 실행하는 방법에는 여러 가지가 있습니다만 여기서 모든 걸 다루기는 어렵습니다. 그중에서도 RDP 또는 SSH와 같은 프로토콜, 서비스 관리자 또는 작업 스케줄러와 같은 RPC 기반 서비스, PowerShell 또는 WMI와 같은 관리 툴 또는 별도 게시물에서 논의한 Linux에서 사용 가능한 일부 프로토콜 및 툴을 사용해 머신에 이미 존재하는 합법적인 프로세스를 통해 발생할 수 있는 측면 이동을 방지하는 방법을 주로 살펴보겠습니다.

원데이 또는 제로데이 취약점은 어떤 제품에도 있을 수 있고 구축 방식도 달라 이에 적용되는 일반적인 전략을 수립하는 것은 비현실적이므로 여기서 논의하지 않을 것입니다. 접근할 수 없다면 악용하기도 훨씬 어렵기 때문에 우리가 권장할 수 있는 유일한 방법은 세그멘테이션뿐입니다.

우선 공통적으로 적용되는 두 가지 원칙을 확인한 다음, 각 프로토콜의 서로 다른 고려 사항을 자세히 살펴보겠습니다.

사용자는 보통 네트워크를 통해 다른 사용자의 머신에 접속할 필요가 없습니다. IT 부서에서 근무하는 사람이 아닌 한, 다른 사용자의 머신에 원격으로 연결해야 할 정당한 이유가 많지 않습니다. 따라서 네트워크 운용성에 큰 영향을 주지 않고 사용자 머신 간의 트래픽을 제한할 수 있어야 합니다.

이 섹션에서 설명하는 프로토콜은 원격 제어 또는 실행에 사용되거나 초기 접속 기법으로 사용될 수도 있습니다. 그래서 우리는 이러한 프로토콜을 통한 임의 인터넷 접속를 제한해야 한다는 점을 거듭 강조합니다.

이러한 서비스는 대화형 및 그래픽 서비스이므로 자동화된 사용은 상당히 제한적입니다. 따라서 서버 간에 사용되는 프로토콜이 자주 보이지 않아야 합니다. 만약 자주 보일 경우 그 이유를 조사해야 합니다. 

사용자 머신 간에도 동일한 원리가 적용됩니다. 즉, 사용자들은 서로 연결할 필요가 없습니다. 이러한 가정의 예외는 사용자가 환경을 호핑하거나 서버에 접속할 수 있도록 하는 점프 박스 및 터미널 서버, 사용자 머신에 대한 IT 직원 연결 또는 애플리케이션 서버에 연결하는 애플리케이션 소유자입니다. 

이러한 예외를 처리하려면 세그멘테이션을 사용해 적절한 정책을 만들고 이를 적절한 IAM(Identity Access Management) 솔루션으로 보완해야 합니다.

SSH의 개념은 RDP와 유사하지만, 이에 관한 이야기는 좀 더 복잡합니다. SSH는 터미널(텍스트) 기반이기 때문에 소프트웨어와 상호 작용하는 데 훨씬 더 쉽게 사용할 수 있으며, 이를 위한 프로그램과 스크립트도 있습니다. 또한 SSH는 파일 전송 프로토콜의 SSH 캡슐화에 해당하는 SFTP와 같이 보안 수준이 낮은 프로토콜을 캡슐화하는 데도 사용됩니다.

이러한 이유로 SSH는 다른 RDP보다 훨씬 더 세분화된 접근 방식이 필요합니다. 네트워크 트래픽을 제대로 파악하지 못하면, 최종 사용자 또는 네트워크 운용성에 영향을 주지 않고 SSH를 제대로 세그멘테이션하기가 매우 어렵습니다.

MS-RPC와 SMB는 모두 측면 이동을 즉시 허용하지 않으며, 그 위에 구축된 다른 프로토콜은 수평 이동을 허용합니다(그림 4 참조). SMB는 파일 전송 및 통신에 사용되고, RPC는 정의된 인터페이스에서 원격 기능을 호출하는 데 사용됩니다. RPC는 SMB를 통해서도 전달되므로 이들은 긴밀하게 연결됩니다. 또한 Windows 도메인 시스템에 통합되어 있기 때문에 올바르게 세그멘테이션하기가 매우 어렵습니다. 

예를 들어, 도메인 인증은 RPC 기반 프로토콜인 Netlogon에 구축됩니다. 도메인 그룹 정책 및 로그온 스크립트는 SYSVOL이라는 도메인 컨트롤러의 공유 폴더에 저장되며, 도메인에 가입된 머신은 SMB를 통해 이 정책에 접속합니다.

전체 도메인을 중단하지 않고 SMB 및 RPC를 차단하기란 사실상 불가능합니다. 그렇다면 어떻게 해야 할까요? SMB를 사용하면 논리 유닛을 기반으로 정책을 생성할 수 있습니다. 목적지가 파일 서버가 아니라면, 대부분의 서버와 머신이 SMB를 통해 서로 통신할 수 없습니다. 따라서 적절한 링펜싱 세그멘테이션은 SMB의 리스크를 방어하는 데 도움이 됩니다.

유사한 접근 방식을 RPC에 적용할 수도 있지만, SMB에서와 달리 파일 서버에 대한 RPC 트래픽을 허용하지 않으므로 더욱 제한적일 수 있습니다. 또한 RPC는 사용자 모드에서 처리되므로 대상 서비스 또는 프로세스를 기반으로 세그멘테이션 정책을 만들 수 있고, 이에 따라 측면 이동에 악용될 수 있는 RPC 인터페이스만 관리하면 됩니다(프로세스 또는 서비스 기반 룰을 처리할 수 있는 세그멘테이션 에이전트가 있는 경우에만). 

다음 표는 측면 이동을 방지하기 위해 관리해야 하는 RPC 인터페이스를 보여줍니다.

이러한 RPC 인터페이스를 통한 모든 작업이 악의적인 것은 아니므로(예: 일부 모니터링 솔루션 및 감시 기능이 서비스 관리자와 원격으로 상호 작용하여 서비스 상태를 확인하는 경우), 기존 RPC 통신을 조사하는 것이 좋습니다. 일반적으로 원격 접속이 이뤄지지 않거나 소스 목록의 범위를 좁힐 수 있는 경우에는 추가적인 보안 이점을 위해 이러한 요소를 중심으로 세그멘테이션 정책을 만드는 것이 좋습니다.

PowerShell과 WMI는 모두 원격 머신과 상호 작용할 수 있으며 이러한 상호 작용은 Windows Remote Management (WinRM)를 통해 ‘이뤄집니다’. 일반적으로 사용되는 것은 원격 관리 또는 모니터링(WMI 사용)이기 때문에 사용자 네트워크에는 해당 사용 사례가 거의 없습니다. 여기서는 임의 사용을 제한하고 서버 또는 IT 머신 모니터링에만 이를 허용하는 세그멘테이션 정책을 만들 수 있어야 합니다. 

물론 예외적인 경우가 있을 수 있으며, 개발자들이 편의를 위해 원격 PowerShell을 광범위하게 활용한 몇몇 사례도 있습니다. 상황에 따라 적절하게 결정하는 것이 좋겠습니다.

1984년에 했던 것처럼 발신 트래픽을 모두 통제하고자 하는 경우가 아니라면, 세그멘테이션만으로 공격 중 데이터 유출을 방지하는 것은 현실적으로 불가능합니다. 인터넷은 크고 넓기 때문에 사용자가 네트워크에서 접속하는 모든 사이트와 서버에 대해 정확한 판단을 내리기란 현실적으로 어렵습니다. 따라서 공격자는 모든 아웃바운드 트래픽에 자신의 유출 시도를 쉽게 감출 수 있습니다.

아웃바운드 트래픽을 통제하는 대신 중요한 데이터에 접속할 수 있는 사람을 통제하는 것이 보다 실현 가능한 방식입니다. 아웃바운드 트래픽을 제한할 수 있는 유일한 위치는 네트워크의 서버입니다. 사용자 머신과 달리 아웃바운드 목적지에는 큰 차이가 없습니다.

이 섹션 전체에서 가장 중요한 원칙은 ‘존재한다고 해서 허용되어야 하는 것은 아니다.‘라는 것입니다. 비즈니스 크리티컬 애플리케이션(예: SWIFT), 운영 부서(예: 도메인 컨트롤러) 또는 환경(예: 프로덕션 서버) 등 네트워크의 일부를 세그멘테이션할 때 가장 먼저 해야 할 일은 기존 트래픽을 조사하는 것입니다(그림 5). 

기존 트래픽을 분석한 후에는 관련 흐름을 허용하고 나머지를 제한하는 정책을 만들 수 있습니다. (또한 세그멘테이션 대신 애플리케이션 소유자가 처리해야 하는 잘못된 설정을 찾을 수도 있습니다.) 

차단 정책은 즉시 구축하는 것보다 일정 시간 동안 알림 전용 모드로 실행하는 것이 좋습니다. 정책이 의도한 대로 실행되고 정책 위반 알림이 최소값 또는 제어된 값이라고 여겨지는 경우에만 제한 정책으로 이동해야 합니다. 

또한 현재 환경(세그멘테이션을 시작하기 전에 존재했던 환경)과 향후 환경(세그멘테이션 정책을 구축한 환경)을 구분하는 것도 중요합니다. 세그멘테이션을 처음 구축할 때는 주의 깊게 네트워크를 학습하여 문제가 발생하지 않도록 해야 합니다. 

새로운 사항은 기존 세그멘테이션 정책을 고려하여 추가해야 합니다. 정상적인 운영을 위해 필요한 경우 정책 예외를 적용하고 허용하되, 네트워크를 확장하는 중이라는 이유만으로 기존 정책을 무시해서는 안 됩니다.

링펜싱에서 우리가 관심을 가지는 부분은 주로 네트워크의 나머지 부분 그리고 전 세계 세그먼트의 인터페이스입니다. 우리는 세그먼트 내에서 무슨 일이 일어나고 있는지 고려하는 대신, 세그먼테이션하려는 네트워크의 일부에서 들어오고 나가는 것을 제어하고자 합니다.

링펜싱을 한 단계 더 발전시키고 목적에 따라 개별 머신에 정책을 적용할 수 있습니다. 일례로 서버가 데이터베이스로만 작동하는 경우 데이터베이스 포트, 즉 웹 포트를 통한 웹 서버 접속만 가능하도록 해야 합니다.

물론, 그렇게 간단한 일은 아닙니다. 일반적으로 감시 기능, 성능 모니터 또는 IT와 같이 이러한 서버에 접속해야 하는 서비스가 상당히 많습니다. 이러한 접속 포트는 보통 일종의 원격 제어와 관련이 있기 때문에 측면 이동 기법과 매우 유사해 보입니다. (예를 들어, 원격 감시 기능은 PsExec 측면 이동 기법과 유사한 방식으로 서비스 관리자에게 쿼라합니다. 여러 호출을 확실히 구별하는 유일한 방법은 대개 사용이 불가능한 심층 패킷 검사입니다.)

이 문제를 해결하려면 서비스에 이미 접속해야 하는 트래픽 외에 추가 트래픽을 허용해야 하는 모든 위치에서 허용되는 소스를 모니터링을 수행해야 하는 세그먼트로 제한하는 것이 좋습니다.

또한 필요하지 않은 민감한 위치로의 사용자 접속을 제한할 수 있습니다. 데이터베이스가 내부 애플리케이션만 제공하는 경우 임의 사용자가 쿼리하도록 허용할 이유가 없습니다. 많은 공격이 감염된 사용자로부터 시작되므로, 임의 사용자 접속을 차단하는 것이 가장 중요한 보안 단계라고 생각됩니다.

우리는 마이크로세그멘테이션을 사용해 세그멘테이션 정책에 또 다른 세그멘테이션 레이어를 적용하고 있습니다. 즉, 역할 또는 민감도에 따라 세그먼트에서 머신을 분리합니다. 일종의 애플리케이션 링펜싱과 일반 링펜싱을 혼합한 방식으로 생각할 수 있습니다. 링펜싱과의 큰 차이점은 이제 세그먼트 내의 트래픽도 제어하고 이웃을 자동으로 신뢰하지 않는다는 것입니다.

같은 세그먼트 내에 있다고 해서 주변 머신의 트래픽을 신뢰해서는 안 된다는 것이 우리의 원칙입니다. 공격자는 세그먼트에 관계없이 네트워크 전체에 전파할 수 있는 모든 연결을 사용합니다. 

따라서 세그먼트에 동일한 종류의 애플리케이션 서버가 있더라도 모든 포트 및 프로토콜에서 서로 통신이 가능하도록 할 이유가 없습니다. 마이크로세그멘테이션은 네트워크 세그먼트 내부 및 동일한 역할을 가진 머신 간에도 모든 종류의 트래픽에 정책 룰을 적용하는 것을 의미합니다.

물론 동일한 세그먼트 내의 머신은 일반적으로 더 긴밀하게 연결되어 있으므로 지나치게 허용적이지 않는 한 정책을 추가하기가 더 어렵습니다.

네트워크의 세그먼트를 정의하는 방법에 따라 애플리케이션 링펜싱의 원칙이 마이크로세그멘테이션 원칙으로 적용될 수도 있습니다. 예를 들어 네트워크를 사용자 세그먼트, 데이터베이스 세그먼트 및 웹 서버 세그먼트로 분할하는 경우 애플리케이션 링펜싱 에 정의된 원칙이 마이크로세그멘테이션에도 적합할 수 있습니다. 여기에 각 애플리케이션 세그먼트 내 서로 다른 머신 간에 동일한 원칙을 적용하기만 하면 됩니다.

그러나 네트워크가 재무 세그먼트, 영업 세그먼트 및 IT 세그먼트로 나뉘어 있고 각 세그먼트에 서버와 사용자 머신이 혼합되어 있다면 좀 더 창의적으로 접근해야 합니다. 세그먼트에 일반적인 링펜싱 전략을 적용한 후에는 세그먼트 간에 그리고 그 안에 정책을 만들어야 합니다. 우리는 각 세그먼트를 미니 네트워크로 간주할 수 있습니다. 그런 다음 각 세그먼트를 미니 네크워트를 위한 다양한 종류의 애플리케이션 및 머신으로 분할할 수 있습니다. 예를 들어 영업 세그먼트의 경우 파일 서버, 데이터베이스 및 사용자 머신이 있을 수 있습니다. 각 종류의 머신은 새로운 세그먼트로 취급하고, 링펜싱 또는 애플리케이션 링펜싱 가이드라인을 다시 따를 수 있습니다.

그림 6에는 다양한 세그멘테이션 전략 간의 관계가 요약되어 있습니다.

네트워크 세그멘테이션은 네트워크 보안을 강화하고 네트워크 기반 위협에 대처하는 데 매우 유용한 툴입니다. 또한 길고 고단한 세그멘테이션 프로젝트를 시작할 필요 없이 작업을 여러 하위 프로젝트로 분할하여 네트워크의 보안 체계를 한 번에 한 단계씩 개선할 수 있으므로 즉각적인 보안 가치를 제공할 수 있습니다. 

네트워크 관리자가 이러한 작업을 수행할 수 있도록 지원하는 다양한 세그멘테이션 정책 및 전략에 대한 가이드라인을 안내했습니다. 우리의 권장 사항이 기업의 보안을 더 안전하게 유지하는 데 실질적인 도움이 되기를 바랍니다.

Akamai Security Intelligence Group은 다양한 보안 주제를 지속적으로 모니터링 및 연구하고 리서치 결과를 게시할 예정입니다. 실시간 업데이트 및 최신 리서치를 확인하려면 Twitter에서 Akamai를 팔로우하세요!