임직원의 업무용 PC와 서버의 IP 대역을 vlan이든 방화벽이든 물리적이나 논리적으로 나눴는데도, PC에서 데이터베이스와 서버 관리 포트까지 접속할 수 있다면 보안 경계는 충분히 작동하지 않는 상태다. 네트워크 세분화의 효과는 나눈 망의 개수보다 ‘업무에 필요 없는 연결이 실제로 거부되는가’를 확인할 필요가 있다.
이 글에서는 영역 단위의 네트워크 세분화와 워크로드 단위의 마이크로세그멘테이션을 구분하고, 기업이 어떤 통신부터 확인해서 통제할지 판단하는 기준을 살펴본다. 정책표와 적용 순서는 설계를 돕기 위한 가상 예시와 실무 제안이다.
망을 분리하는 것과 통신을 통제하는 것
네트워크 세분화는 하나의 네트워크를 업무·보안 요구에 따라 여러 영역으로 나누는 방식이다. 사용자망, 운영 서버망, 개발망, 관리망처럼 큰 경계를 만드는 접근을 매크로세그멘테이션이라고 부른다. 호주 ASD의 지침은 영역을 나누는 세분화와 호스트·서비스 사이의 통신 규칙을 강제하는 통제를 구분한다.
VLAN은 논리적으로 네트워크를 분리하는 수단이지만, VLAN을 만들었다는 사실만으로 서버 접근까지 제한되지는 않는다. 서로 다른 VLAN 사이의 라우팅이 허용되고 ACL이나 방화벽 규칙이 넓게 열려 있다면 업무상 불필요한 통신도 통과할 수 있다. 따라서 ‘어느 망인가’와 함께 ‘어떤 경로에서 어떤 규칙으로 검사하는가’를 확인해야 한다.[2]
마이크로세그멘테이션이 좁히는 경계
마이크로세그멘테이션은 같은 서버 영역 안에서도 개별 워크로드·애플리케이션·서비스 단위로 허용 통신을 세밀하게 정하는 접근이다. 예를 들어 같은 운영 서버망에 있는 주문 애플리케이션과 인사 데이터베이스라도 업무 연관성이 없다면 서로 접근하지 못하게 설계할 수 있다.
| 구분 | 영역 단위 세분화 | 마이크로세그멘테이션 |
|---|---|---|
| 주요 경계 | 사용자망·개발망·운영망 등 | 개별 워크로드·애플리케이션·서비스 |
| 정책 질문 | 어느 영역 사이에 통신을 허용할까 | 어떤 자원이 어떤 서비스에 접근해야 할까 |
| 구현 예 | VLAN·VRF와 경계 방화벽·ACL | 호스트 방화벽·분산 방화벽·클라우드 제어 등 |
| 운영 초점 | 영역 간 경로와 예외 | 자원 식별·업무 의존성·정책 변경 |
두 방식은 함께 사용할 수 있다. 먼저 개발·운영 환경을 큰 경계로 나누고, 운영 환경 내부에서 애플리케이션별 접근을 더 좁히는 식이다. 마이크로세그멘테이션을 특정 제품이나 에이전트 설치 방식과 같은 뜻으로 볼 필요는 없다. 실제 집행 위치와 지원 범위는 구현에 따라 달라진다.
가상 예시로 보는 허용·차단 정책
직원이 사내 웹 업무 시스템을 사용하고, 애플리케이션 서버가 전용 DB에 접속하는 가상 환경을 가정했을때, 직원은 웹 화면을 사용하면 되므로 업무 PC에서 DB로 직접 연결할 이유가 없다. 다음 표는 전체 정책이 아닌 핵심 연결의 설계 예시다.
| 출발지 → 목적지 | 통신 목적 | 설계 예시 |
|---|---|---|
| 업무 PC → 업무 애플리케이션 | HTTPS 웹 화면 사용 | 필요한 사용자·단말 범위에 허용 |
| 업무 PC → DB | 직접 DB 접속 | 일반 업무 PC는 차단 |
| 업무 애플리케이션 → 전용 DB | 업무 데이터 조회·저장 | 해당 애플리케이션과 DB 서비스만 허용 |
| 다른 애플리케이션 → 해당 DB | 업무 의존성 없음 | 차단 |
| 승인된 관리 경로 → 서버 | 점검·관리 | 관리 대상·서비스·승인 조건으로 제한 |
표의 방향은 통신의 흐름을 뜻한다. 웹 응답이나 DB 응답을 없앤다는 의미가 아니며, 상태 추적 여부에 따라 응답 트래픽의 규칙 처리 방식도 확인해야 한다. DNS, 시간 동기화, 인증, 백업, 모니터링 같은 공통 의존성은 별도로 조사해 허용 범위를 정한다.
이 구성이 적용되면 업무 PC가 침해로 인해 탈취돼도 DB로 직접 접근하는 경로는 제한된다. 다만 허용된 애플리케이션 경로를 악용하거나 애플리케이션 자체가 침해되는 상황까지 해결되지는 않는다. DB 계정 권한과 애플리케이션 인증·취약점 관리도 함께 점검해야 한다.
보안 효과와 남는 한계
기대하는 효과는 침해 이후 lateral movement허용 대상을 줄이는 것이다. 허용 관계가 명확하면 업무상 이유가 없는 접속 시도를 조사 대상으로 구분하기도 쉬워진다. 사고 시에는 정의된 경계를 이용해 영향을 받은 자원을 제한적으로 격리하는 방안을 검토할 수 있다.
그러나 차단 로그가 발생했다고 곧바로 공격으로 판정해서는 안 된다. 누락된 업무 의존성이나 잘못 배포된 정책도 같은 신호를 만든다. 또한 허용된 연결의 악성 행위, 탈취된 계정의 권한 남용, 정책 집행 지점을 우회하는 별도 경로는 다른 통제와 함께 다뤄야 한다.
마이크로세그멘테이션만으로 제로 트러스트가 완성되는 것도 아니다. NIST SP 800-207은 내부망에 있다는 이유만으로 신뢰를 부여하지 않으며, 자원 접근에 앞서 인증과 인가를 수행하는 원칙을 설명한다. 세분화는 접근 범위를 제한하는 수단이고, 신원·단말 상태·권한 판단을 모두 대신하지는 않는다.[4]
업무 장애를 줄이는 적용 순서
처음부터 모든 통신을 차단하면 드물게 실행되는 배치나 복구 작업이 중단될 수 있다. 다음 순서는 업무 연속성을 확인하면서 범위를 넓히기 위한 실무 제안이다. ASD의 구현 지침도 주요 자산과 필요한 통신을 식별하고, 배포 전 시험을 수행하는 접근을 제시한다.
- 보호 대상을 정한다. 업무 PC에서 DB·관리 인터페이스로 직접 연결되는 경로처럼 목적이 분명한 범위부터 고른다.
- 통신을 관찰한다. 평상시 사용뿐 아니라 월말 배치, 백업, 장애 조치와 복구 시 필요한 연결까지 업무 담당자와 대조한다.
- 허용 관계를 문서화한다. 출발지·목적지·서비스·업무 목적·소유자·예외 만료일을 기록하고, 관측됐다는 이유만으로 모두 허용하지 않는다.
- 적용 전 영향을 확인한다. 지원되는 경우 관찰·시뮬레이션 기능을 쓰고, 시험 환경이나 제한된 대상에서 정상 업무와 차단 동작을 검증한다.
- 범위를 단계적으로 넓힌다. 로그인·조회·등록·배치·백업을 확인하고, 장애 발생 시 되돌릴 정책과 담당자를 준비한다.
차단 후에는 업무가 정상이라는 확인과 차단해야 할 경로가 실제로 막힌다는 확인을 함께 남겨야 한다. 서비스가 정상이어도 정책이 집행되지 않는 상태일 수 있고, 차단이 잘돼도 필수 업무가 중단되는 상태일 수 있기 때문이다.
실무자 관점: 세분화 수준보다 정책을 유지할 능력
도입 판단에서 먼저 볼 것은 자산과 업무 관계를 누가 설명하고 정책 변경을 누가 책임지는지다. 자원 분류가 틀리거나 담당자가 불명확하면 세밀한 정책도 광범위한 홀이 발생하기 쉽다. 소규모 환경에서는 기존 방화벽과 호스트 통제로 핵심 경로부터 제한하는 접근이 현실적일 수 있다.
워크로드가 자주 생성·이동되는 환경이라면 IP 주소만으로 정책을 유지하기 어려울 수 있다. 이때는 역할·환경·애플리케이션 같은 라벨을 활용하는 방식을 검토하되, 라벨 변경 권한과 잘못 분류된 자원의 처리 방법도 정해야 한다. 기능 지원 여부는 실제 제품과 운영 환경에서 확인한다.
완료 기준은 정책 수가 아니라 검증 가능한 결과로 잡는 편이 낫다. 예를 들어 ‘일반 업무 PC의 DB 직접 연결은 거부되고, 지정된 애플리케이션의 DB 연결과 승인된 관리 작업은 정상 수행된다’는 기준은 시험과 재점검이 가능하다. 이후 배포나 네트워크 변경이 있을 때 같은 조건을 다시 확인한다.
결론
네트워크 세분화는 큰 보안 경계를 만들고, 마이크로세그멘테이션은 그 안의 자원 간 통신을 더 세밀하게 제한한다. 적용의 출발점은 중요한 자원 하나를 고르고, 그 자원에 꼭 필요한 연결과 차단할 연결을 구분하는 일이다. 정상 업무·차단 결과·복구 방법을 함께 검증할 수 있는 범위부터 확장해야 정책을 지속적으로 유지할 수 있다.