2부의 마지막에서 이런 질문이 남았다.
“그렇다면 결국, 이렇게 늘어난 자산과 연결을 모두 더 세밀하게 통제해야 하는 것일까?”
결론부터 말하면, 현실은 그렇지 않다.
모든 자산을 완벽하게 정의하고, 모든 통제를 한 번에 설계하는 것은 매우 어렵다.
경계 이후의 보안, 무엇부터 바꿔야 하는가.
경계 중심 보안의 한계는 이제 충분히 논의되었다.
이제 남는 질문은 하나다.
“그래서, 무엇부터 바꿔야 하는가?”
최근의 공격 양상을 보면 한 가지 분명한 변화가 있다.
공격이 더 정교해진 것이 아니라, ‘속도’와 ‘자동화’가 폭발적으로 증가했다는 점이다.
취약점은 공개되자마자 스캔되고, 노출된 자산은 자동으로 탐색되며, 계정과 권한은 반복적으로 공격이 시도된다.
이런 미토스 등 AI를 이용한 공격 환경에서는 모든 것을 완벽하게 막는 전략은 더 이상 현실적이지 않다.
이제 보안은 다음과 같은 흐름으로 재정의 될 필요가 있다.
• 노출을 최소화하고
• 침투를 가능한 한 차단하며
• 침투 이후 확산을 막고
• 빠르게 복구할 수 있는 구조를 만드는 것
이 관점에서 보면 지금 필요한 것은 새로운 기술방향이 아니라 실행 순서의 문제이다.
모든 것을 한 번에 바꿀 수는 없다.
완벽한 설계가 아니라 현실적으로 시작할 수 있는 지점이다.
1. 자산을 ‘목록’이 아니라 ‘상태’로 본다
대부분의 조직은 자산 목록을 가지고 있다.
하지만 그 자산들이 어떤 상태인지까지는 정확히 알지 못하는 경우가 대부분이다.
또한 오픈소스와 같은 영역은 자산 목록에서 아예 누락되어 있기도 하다.
IDC 환경에서는 서버, DB 목록은 존재하지만 어떤 사용자가 접근하는지, 어떤 포트가 열려 있는지, 외부와 연결되어 있는지까지 정확히 관리되지 않는 경우가 많다.
클라우드 환경에서는 상황이 더 복잡해진다.
예를 들어 AWS 환경에서는 기존의 서버, DB, 스토리지 개념을 넘어 EC2, S3, RDS, Lambda, 각종 네이티브 서비스 등 더 다양한 자산에 대한 관리 포인트가 필요하다.
또한 최근에는 AI를 활용한 공격이 증가하면서 오픈소스 구성 요소, 자산의 취약점(CVE), 패치 상태 등이 주요 공격 대상이 되고 있어 이 부분도 관리가 필요하나 이러한 영역은 관리가 미비한 것이 현실이다.
문제는 이런 자산들의 설정 하나, 취약점 하나로 외부에 노출될 수 있다는 점이다.
예를 들어
• 인터페이스용 API가 악용되거나
• S3 버킷이 Public으로 설정되거나
• EC2 관리 포트(SSH, RDP)가 외부에 노출되거나
• CVE 취약점을 통해 권한이 탈취되는 경우는
지금도 반복되는 사고 원인이다.
그래서 첫 단계는 단순하다.
“무엇이 있는가”가 아니라 “무엇이 있고, 그 자산이 지금 어떤 상태인가”를 아는 것.
• 외부에서 접근 가능한가
• 어떤 계정이 접근 가능한가 (사용자 및 시스템 포함)
• 어떤 데이터가 저장되어 있는가 (암호화 여부 포함)
• 공개된 취약점이 존재하는가 (CVE, CVSS 기준)
이 4가지 자산 상태가 보일 때 비로소 보안을 시작할 수 있다.
2. 전체를 바꾸지 말고, ‘순서를 정한다’
다만, 모든 자산의 상태를 한 번에 가시화하고 조치하는 것은 쉽지 않다.
또한 모든 것을 동시에 바꾸려는 시도는 대부분 실패한다.
그래서 현실적인 적용 순서는 명확하다.
먼저, 외부와 연결된 시스템과 그렇지 않은 시스템을 식별해야 한다.
이때 중요한 점은 단 하나의 접점이라도 놓치지 않는 것이다.
API, 외부 인터페이스, 간접 연결된 서비스까지 모두 포함된다.
두 번째로, 외부와 연결된 시스템을 대상으로 취약점(CVE, 고위험 CVSS 등)을 확인하고 조치한다.
세 번째로, 현재 기준에서 다음과 같은 우선순위로 자산 상태 4가지를 정리한다.
• 개인정보 및 핵심 데이터 시스템
• 외부에 노출된 시스템
• 신규 시스템
• 그 외 시스템
정리가 완료되면 확인된 자산 상태를 기준으로 우선순위를 다시 재배치한다.
여기까지 진행되면 조치, 도식화, 그리고 중요도 기반 대응체계를 수립할 수 있는 준비가 된다.
댓글
0