[ABVM①] 제로 트러스트 전제조건, 자산 식별·목록화

자산 정보에 컨텍스트 추가해야 실효성 있는 자산관리 가능 컨텍스트·실시간 변화 반영 동적 자산 인벤토리 필수

이용 위드네트웍스 상무

오늘날 기업은 막대한 비용을 투자해 최신 보안 솔루션을 도입하고, 24시간 내내 불을 밝히는 보안관제센터를 운영하고 있다. 견고한 성벽을 쌓고 최첨단 무기로 무장했지만, 정작 성 안의 지도를 제대로 가

지고 있지 못한 역설적인 상황이 벌어지고 있다.

버라이즌의 ‘2024년 데이터 침해 조사 보고서’에 따르면, 기업에서 발생하는 침해 사고의 상당수는 최신 제로데이 공격이 아닌, 오랫동안 패치되지 않은 채 방치되었거나, 관리자의 관심 밖으로 밀려나 있던 시스템의 취약점을 통해 발생한다고 분석했다. 이는 외부의 적에 맞서기 위해 성벽을 높이 쌓는 동안, 성안의 잊힌 통로나 관리되지 않는 창고에서 조용히 위협이 자라나고 있음을 시사한다.

디지털 전환(Digital Transformation)이라는 거대한 흐름 속에서 기업의 IT 인프라는 전례 없는 속도로 팽창하고 있다. 클라우드, 컨테이너, IoT, 원격 근무 환경 등은 비즈니스의 민첩성을 높이는 강력한 동력이지만, 과거에는 상상할 수 없었던 복잡성과 새로운 공격 표면(Attack Surface)을 만들고 있다.

문제는 이러한 확장 속도를 보안 가시성이 따라가지 못하고 있다는 점이다. 많은 기업이 자신이 보유한 전체 디지털 자산의 현황을 정확히 파악하지 못하고 있으며, 이는 마치 짙은 안개 속에서 운전하는 것과 같다. 눈에 보이는 앞차와의 간격만 유지하다가, 안갯속에 가려져 있던 장애물과 충돌하는 사고가 발생하는 것이다.

업계 전문가들은 상당수의 기업이 IT 자산의 완전한 가시성을 확보하지 못하고 있을 뿐만 아니라, 이러한 가시성 부재가 얼마나 심각한 문제인지조차 제대로 인식하지 못하고 있다는 사실을 지적한다. ‘방화벽과 백신만 있으면 안전하다’는 낡은 생각은 보이지 않는 자산이 가장 큰 위협이 되는 이 시대에는 더 이상 유효하지 않으며, 조직이 더 큰 위험에 직면하게 되는 원인이 된다.

withVTM 구성도

확장되는 공격 표면과 보안 사각지대

과거 보안 모델은 명확한 경계를 전제로 했다. 외부의 위협으로부터 내부의 자산을 보호하는 ‘성과 해자(Castle-and-moat)’는 네트워크 경계에 방화벽을 세우고, 내부의 PC에 백신을 설치하는 방식으로 구현되었다. 그러나 현대 IT 환경은 이러한 경계를 무의미하게 한다. 또한 다양한 영역에서 새로운 보안 사각지대를 만들어내고 있다.

클라우드 서비스의 보편화는 섀도우 IT(Shadow IT)를 전사적인 위험으로 확장시켰다. 예를 들어, 마케팅 부서가 IT 부서의 검토 없이 새로운 고객 분석 SaaS 솔루션을 구독하고, 구글 워크스페이스나 마이크로소프트 365 계정과 연동(SSO)하면, IT 및 보안 부서가 인지하지 못하는 경로로 민감한 고객 데이터가 외부 서비스로 유통된다. SaaS 플랫폼의 보안 수준이 기업의 표준을 충족하는지, 데이터는 어떻게 저장되고 관리되는지, 접근 제어는 적절한지에 대한 통제가 전혀 이뤄지지 않는다.

개발 환경에서의 섀도우 IT는 더욱 심각한 문제를 야기한다. 개발자가 프로젝트의 빠른 진행을 위해 AWS, 애저 등 퍼블릭 클라우드에 임시로 테스트용 데이터베이스 인스턴스를 생성하는 경우를 생각해보자.

많은 개발자가 편의를 위해 접근 제어 설정을 ‘모두에게 공개(Public)’로 설정하고, 테스트가 끝난 후 이를 삭제하는 것을 잊어버린다. 공격자들은 인터넷 전반을 스캔해 이처럼 잘못 구성된 클라우드 리소스를 자동으로 찾아내는 도구를 사용한다. 이렇게 방치된 테스트 서버는 기업 내부망으로 침투하는 완벽한 교두보가 된다.

한 금융기관이 전사 클라우드 자산을 실사한 결과, IT 부서가 공식적으로 파악하고 있던 것보다 40% 이상 많은 클라우드 리소스가 운영되고 있었다는 사례는 결코 남의 이야기가 아니다. 이는 빙산의 일각에 불과하며, 관리되지 않는 클라우드 리소스는 데이터 유출, 랜섬웨어 감염, 규제 위반 등 심각한 보안 사고로 직결될 수 있다.

IoT·OT 환경의 융합과 새로운 도전

사물인터넷(IoT) 기기의 확산은 IT 자산의 정의를 근본적으로 바꾸고 있다. 사무실의 스마트 TV, 회의실의 IP 카메라, 건물 관리 시스템의 각종 센서, 공장의 생산 설비를 제어하는 PLC까지, 네트워크에 연결되는 모든 것이 잠재적인 공격 경로가 되고 있다. 이러한 기기들은 몇 가지 공통적인 기술적 문제를 안고 있다.

첫째, 대부분의 IoT 기기는 윈도우, 리눅스 등 일반 상용 OS를 사용하지 않아 엔드포인트 보안 에이전트 설치가 불가능 하다. 둘째, 리소스가 제한적인 저사양 하드웨어로 구동되어 복잡한 보안 기능을 탑재하기 어렵다. 셋째, 제조사가 보안 업데이트를 제때 제공하지 않거나, 사용자가 패치 적용의 필요성을 인지하지 못하는 경우가 많다. 특히 이러한 기기들은 전통적인 IT 자산 관리 체계에서 벗어나 있는 경우가 많아, 보안 패치나 접근 통제가 제대로 이뤄지지 않는다.

최근에는 IT와 OT의 융합이 가속화되면서 위험은 더욱 커지고 있다. 과거 폐쇄망으로 운영되던 공장 제어 시스템, 빌딩 자동화 시스템 등이 원격 모니터링 및 데이터 분석을 위해 인터넷에 연결되면서, 사이버 공격이 물리적인 피해로 이어질 수 있는 가능성이 열렸다. 공격자가 공장 제어망에 침투해 생산 라인을 멈추거나 오작동을 유발하는 시나리오는 더 이상 영화 속 이야기가 아니다.

OT 환경은 가용성이 무엇보다 중요하기 때문에, 보안을 위한 스캔이나 패치 작업이 시스템 중단을 유발할 수 있다는 우려 때문에 보안 조치가 소홀해지는 경향이 있다. 이는 공격자에게 매우 매력적인 먹잇감을 제공하는 것과 같다.

하이브리드 근무와 무너진 경계

코로나19 이후 보편화된 하이브리드 및 원격 근무 환경은 ‘신뢰할 수 있는 내부 네트워크’와 ‘신뢰할 수 없는 외부 네트워크’라는 이분법적 보안 모델의 종말을 고했다. 이제 기업의 보안 경계는 물리적인 사무실을 넘어 각 직원의 집, 카페, 공항 등 전 세계로 확장되었다.

이러한 변화는 엔드포인트 보안의 중요성을 극대화시켰다. 직원이 개인 소유의 디바이스를 업무에 활용하는 BYOD 정책은 생산성을 높일 수 있지만, 동시에 보안 통제가 전혀 이뤄지지 않는 디바이스가 기업 데이터에 접근하는 것을 허용하게 된다. 해당 디바이스가 악성코드에 감염되어 있거나, 보안 설정이 취약할 경우 이는 기업 전체를 위험에 빠뜨리는 통로가 될 수 있다.

이러한 환경 변화로 제로 트러스트 아키텍처(ZTA) 도입이 필수가 되었다 제로 트러스트는 ‘절대 신뢰하지 말고, 항상 검증하라(Never Trust, Always Verify)’는 원칙에 기반해, 네트워크의 위치와 관계없이 모든 접근 요청을 의심하고 인증과 권한을 철저히 확인하는 모델이다.

성공적인 제로 트러스트 구현의 가장 기본적인 전제 조건은 ‘무엇을 보호해야 하는가’ 즉, 접근 대상이 되는 모든 자산(애플리케이션, 데이터, 인프라)을 식별하고 목록화하는 것이다. 조직이 가진 자산이 무엇인지도 모르면서, 그 자산에 대한 접근을 통제하겠다는 것은 어불성설이다.

데브옵스 환경의 속도와 복잡성

애자일, 데브옵스, CI/CD 파이프라인으로 대표되는 현대 소프트웨어 개발 환경은 비즈니스 요구에 신속하게 대응할 수 있는 역량을 제공했지만, 그 대가로 엄청난 복잡성을 낳았다. 과거의 모놀리식(Monolithic) 아키텍처와 달리, 마이크로서비스 아키텍처(MSA) 환경에서는 하나의 애플리케이션이 수십, 수백 개의 독립적인 서비스로 분리되어 운영된다. 각각의 서비스는 자체적인 개발 파이프라인을 통해 수시로 배포되고 업데이트되며, 이는 관리해야 할 대상이 기하급수적으로 증가했음을 의미한다.

특히 컨테이너 기술의 도입은 ‘자산’의 개념을 더욱 유동적으로 만들었다. 컨테이너는 필요에 따라 수 초 만에 생성되었다가 사라지는 ‘일시적인(Ephemeral)’ 특성을 가진다. 이러한 환경에서 몇 시간 또는 며칠 주기로 수행되는 전통적인 취약점 스캔 방식은 더 이상 유효하지 않다. 스캔이 완료될 시점에는 이미 해당 컨테이너가 사라졌거나, 완전히 새로운 버전으로 대체되었을 수 있기 때문이다.

또한 개발자들이 사용하는 컨테이너 베이스 이미지 자체에 취약점이 포함되어 있을 경우, 해당 이미지를 기반으로 생성되는 모든 컨테이너가 잠재적인 보안 위협을 안고 배포되는 ‘공급망 공격’의 시발점이 될 수도 있다. ‘임시로 사용하는 테스트 환경’이라는 안일한 생각이, 실제로는 전체 시스템을 위험에 빠뜨리는 출발점이 될 수 있다는 사실을 명심해야 한다. 해커들에게는 제대로 관리되지 않는 개발 서버나 테스트 환경이 가장 손쉬운 침투 경로가 되기 때문이다.

모든 보안의 시작점, 완전한 자산 인벤토리 구축

‘적을 알고 나를 알면 백 번 싸워도 위태롭지 않다(知彼知己 百戰不殆)’는 손자병법의 가르침은 사이버 보안의 핵심 원리를 관통한다. ‘나를 아는 것’은 바로 우리 조직이 보유한 모든 IT 자산을 예외 없이, 그리고 정확하게 파악하는 것을 의미한다. 앞서 살펴본 바와 같이 현대 IT 환경의 복잡성은 이 ‘나를 아는 것’을 매우 어려운 기술적 과제로 만들었다.

더 이상 구매 대장이나 수동으로 관리되는 엑셀 파일은 역동적으로 변화하는 자산의 현황을 담아낼 수 없다. 작성하는 순간부터 과거의 정보가 되어버리는 정적 목록을 넘어, 살아 숨 쉬는 IT 환경을 실시간으로 반영하는 동적인 자산 인벤토리를 구축하는 것이 무엇보다 중요하다.

완전한 자산 인벤토리를 구축하기 위해서는 단일 기술이 아니라, 여러 기술을 상호 보완적으로 활용하는 다층적인 접근 방식이 필수적이다.

• 능동적 스캐닝(Active Scanning): 네트워크에 탐지 패킷을 보내고 그 응답을 분석해 자산을 식별하는 전통적이면서도 강력한 방식이다. IP 주소, 열린 포트, 실행 중인 서비스, 운영체제 버전 등 상세한 정보를 수집할 수 있다. 하지만 민감한 OT 환경이나 프로덕션 시스템에서는 서비스에 영향을 줄 수 있어 신중한 사용이 요구된다.

• 수동적 모니터링(Passive Monitoring): 네트워크 트래픽을 미러링해 분석함으로써, 네트워크를 통신하는 모든 자산을 식별하는 방식이다. 시스템에 직접적인 영향을 주지 않아 안전하지만, 네트워크에 나타나지 않는 휴면 자산이나 트래픽을 발생시키지 않는 자산은 탐지할 수 없다는 한계가 있다.

• 에이전트 기반 수집(Agent-based Collection): 서버나 엔드포인트에 직접 설치된 에이전트를 통해 시스템 내부의 상세 정보를 수집하는 방식이다. 설치된 소프트웨어 목록, 패치 상태, 설정 값 등 가장 깊이 있는 정보를 제공하지만, 모든 자산에 에이전트를 설치하고 관리해야 하는 부담이 존재한다.

• API 연동(API Integration): 클라우드, 컨테이너, SaaS 등 현대적인 IT 환경에서 가장 핵심적인 자산 식별 방식이다. AWS, 애저, GCP 등의 클라우드 제공업체는 자사의 모든 리소스 정보를 조회할 수 있는 API를 제공한다. 보안팀은 이 API와 연동해 사람이 놓칠 수 있는 수많은 클라우드 자산(가상머신, 스토리지, 데이터베이스, 네트워크 설정 등)을 누락 없이, 그리고 가장 정확하게 파악할 수 있다. 쿠버네티스 API를 통해서는 수시로 생성되고 사라지는 컨테이너의 현황을 실시간으로 파악할 수 있다.

컨텍스트 담은 인벤토리 필수

성공적인 자산 관리는 단순히 존재 유무를 파악하는 것에서 그치지 않는다. ‘192.168.1.100 서버가 존재한다’는 정보만으로는 가치가 없다. 이 정보에 컨텍스트가 더해져야 비로소 의미 있는 자산 인벤토리가 된다. 효과적인 보안 관리를 위해서는 다음과 같은 상세 속성 정보가 반드시 포함되어야 한다.

• 기술적 정보: 운영체제 및 버전, 설치된 소프트웨어 목록, 열린 포트 및 실행 중인 서비스, 하드웨어 사양, 네트워크 구성(IP, MAC 주소) 등

• 비즈니스 정보: 자산의 소유자(관리 부서 및 담당자), 비즈니스 중요도(핵심 업무 시스템 여부), 서비스 영향도(해당 자산 장애 시 비즈니스에 미치는 영향) 등

• 데이터 정보: 해당 자산이 처리하거나 저장하는 데이터의 종류와 민감도(개인정보, 금융정보, 영업비밀 등)

• 위치 정보: 물리적 위치(데이터센터, 사무실 등) 및 네트워크 위치(내부망, DMZ, 외부 클라우드 등), 인터넷 노출 여부

이러한 상세하고 다차원적인 정보가 결합되었을 때, 비로소 우리는 각 자산이 가지는 고유한 가치와 위험을 이해할 수 있다. 그리고 이 이해는 다음 단계인 ‘자산 분류 및 중요도 평가’의 기반이 된다.

모든 자산이 동일한 가치를 가지지 않으며, 따라서 모든 자산을 동일한 수준으로 보호할 수도, 보호해서도 안 된다. 한정된 보안 자원을 가장 중요한 곳에 집중하기 위해서는, 어떤 자산이 우리 조직에 더 중요한지, 어떤 자산이 더 높은 위험을 내포하고 있는지를 명확히 구분하는 체계적인 분류와 평가 과정이 반드시 선행되어야 한다.

---

원문 보기

데이터넷