2026 웹 보안 실전 가이드

5장. 당신의 공격면을 지도화하라

외부에서 보이는 모든 것: 포트, 서비스, 서브도메인, API 엔드포인트, 노출된 메타데이터. 모르는 자산은 지킬 수 없다.

보이지 않는 것은 지킬 수 없고, 모르는 것은 패치할 수 없습니다. 모든 방어는 인벤토리에서 시작됩니다.

들어가며: 방어의 첫걸음은 도구가 아니라 지도다

1부에서 우리는 위협의 전모를 그렸습니다. 인터넷에 연결되는 순간 발견되고, 다양한 공격자가 노리며, AI가 공격을 가속하고, CVE의 홍수가 무기화됩니다. 이제 방어로 넘어갑니다. 그런데 방어의 첫걸음은, 많은 사람의 기대와 달리, 방화벽을 설치하거나 보안 도구를 도입하는 것이 아닙니다.

방어의 첫걸음은 지도를 그리는 것입니다. 자신이 무엇을 가지고 있는지, 그중 무엇이 외부에 노출되어 있는지를 정확히 아는 것입니다. 이것을 공격면 지도화(attack surface mapping) 또는 자산 인벤토리(asset inventory)라고 부릅니다.

왜 이것이 첫걸음일까요? 4장의 우선순위화 5단계가 모두 "내가 무엇을 쓰는지 안다"에서 출발했던 것을 기억하실 것입니다. 자신이 무엇을 운영하는지 모르면, 어떤 CVE가 자신과 관련 있는지 알 수 없고, 무엇을 패치해야 할지 알 수 없으며, 무엇을 모니터링해야 할지도 알 수 없습니다. 보안의 모든 후속 작업이 이 지도 위에서 이루어집니다.

그리고 현실의 침해 사고에서 반복적으로 드러나는 한 가지 패턴이 있습니다. 조직이 자신이 가지고 있는 줄도 몰랐던 자산을 통해 뚫린다는 것입니다. 누군가 테스트용으로 띄워 놓고 잊어버린 서버, 더 이상 쓰지 않지만 여전히 살아 있는 옛 서비스, 관리에서 누락된 서브도메인, 문서화되지 않은 API 엔드포인트 — 이런 "잊힌 자산", 즉 그림자 자산(shadow asset)이 가장 약한 고리가 되는 경우가 많습니다. 아무도 신경 쓰지 않으니 패치도 안 되고 모니터링도 안 되기 때문입니다.

2026년 현재까지도 이 패턴은 그대로입니다. 인터넷에 노출되어 있다는 사실 자체를 잊은 한 대의 서버가, 패치 한 번 빠진 채로 대형 침해의 입구가 됩니다. 예컨대 Citrix Bleed(CVE-2023-4966)는 이미 패치가 나와 있었는데도 미적용 장비를 통해 대규모 침해로 번졌고, MOVEit Transfer(CVE-2023-34362)는 Cl0p 랜섬웨어 조직이 노출된 인스턴스를 무더기로 악용했습니다. 두 사건의 공통점은 "관리되지 않은(혹은 노출된 줄도 몰랐던) 자산"이 출발점이었다는 것입니다. 지도가 없으면 이런 자산은 끝내 사각지대에 남습니다.

이 장에서는 공격면이 정확히 무엇인지, 그것이 어디까지 뻗어 있는지, 그리고 어떻게 체계적으로 지도화하는지를 다룹니다. 공격자의 시선으로 자신을 바라보는 법을 배우는 것입니다. 공격자가 1장에서 본 방법으로 당신을 발견하고 조사한다면, 당신은 같은 방법으로 자신을 먼저 발견하고 조사하여, 그들이 찾기 전에 구멍을 막아야 합니다.

합법성에 대한 사전 안내: 이 장과 이후 장에서 다루는 스캔과 정찰 기법은, 반드시 자신이 소유하거나 서면으로 명시적 허가를 받은 자산에 대해서만 수행해야 합니다. 자신의 공격면을 점검하는 것은 합법이며 권장되지만, 타인의 시스템을 허가 없이 스캔하는 것은 한국의 정보통신망법을 비롯한 여러 법률 위반입니다. 이 책의 모든 기법은 오직 자기 방어와 자가 점검을 위한 것입니다.

5.1 공격면이란 무엇인가

공격면(attack surface)이란, 공격자가 시스템에 진입하거나 영향을 미치려 시도할 수 있는 모든 지점의 총합입니다. 더 쉽게 말하면, 외부에서 당신의 시스템에 닿을 수 있는 모든 접점입니다. 문이 많은 건물일수록 침입 경로가 많듯, 공격면이 넓을수록 방어해야 할 지점이 많아집니다.

공격면은 여러 층위로 존재합니다. 이를 구분해 두면 빠뜨리는 부분을 줄일 수 있습니다.

네트워크 공격면. 외부에서 접근 가능한 모든 IP 주소와 포트, 그리고 그 포트에서 응답하는 서비스입니다. 열린 22번 포트(SSH), 80·443번 포트(웹), 데이터베이스 포트, 그 밖에 의도했든 안 했든 열려 있는 모든 포트가 여기에 속합니다.

도메인과 DNS 공격면. 당신이 소유한 모든 도메인과 서브도메인입니다. 1장에서 본 CT 로그를 통해 노출되는 호스트명들, 그리고 각 도메인이 가리키는 대상들입니다. 잊힌 서브도메인이 특히 위험합니다.

웹 애플리케이션 공격면. 웹 서비스가 노출하는 모든 경로, 페이지, 폼, API 엔드포인트입니다. 사용자가 입력을 보낼 수 있는 모든 지점, 인증을 거치는 모든 관문, 데이터를 주고받는 모든 통로가 잠재적 공격 지점입니다.

소프트웨어 공격면. 시스템에서 돌아가는 모든 소프트웨어와 그 버전, 그리고 4장에서 본 의존성의 빙산입니다. 각각이 알려진 취약점을 가질 수 있습니다.

클라우드·인프라 공격면. 클라우드 환경의 설정, 권한, 스토리지, 관리 인터페이스입니다. 잘못 설정된 스토리지 버킷, 과도한 권한, 노출된 관리 콘솔 등입니다.

사람과 물리 공격면. 2장에서 본 대로, 공격면은 기술에만 있지 않습니다. 직원, 협력사, 물리적 접근도 공격면의 일부입니다. 이 책에서는 14장에서 별도로 다루므로, 이 장에서는 주로 기술적 공격면에 집중합니다.

이 모든 층위의 공통점은, 당신이 의도적으로 만든 것뿐 아니라 의도치 않게 노출된 것까지 포함한다는 점입니다. 그리고 공격자는 당신의 의도를 모릅니다. 그들에게는 "의도적으로 공개한 웹 서버"나 "실수로 노출된 관리 패널"이나 똑같이 두드릴 수 있는 문일 뿐입니다.

5.2 공격면 축소: 가장 강력한 방어 원리

공격면을 지도화하는 목적은 단순히 목록을 만드는 데 있지 않습니다. 궁극적인 목적은 그 공격면을 줄이는 것입니다. 이것이 이 책의 첫 번째 원칙, "공격면을 줄여라"입니다.

논리는 명쾌합니다. 존재하지 않는 것은 공격당하지 않습니다. 닫힌 포트는 무차별 대입의 대상이 되지 않고, 삭제된 서비스는 취약점을 가질 수 없으며, 제거된 기능은 악용될 수 없습니다. 가장 확실하게 보호되는 자산은, 애초에 노출되지 않은 자산입니다.

이것은 다른 모든 방어와 성격이 다릅니다. 방화벽, 침입 탐지, 모니터링 같은 방어는 "노출된 것을 지키는" 적극적 방어입니다. 이런 방어는 그 자체로 복잡성을 더하고, 설정 실수의 여지를 만들며, 우회될 수 있습니다. 반면 공격면 축소는 "지킬 필요 자체를 없애는" 소극적이지만 근본적인 방어입니다. 지킬 것이 없으면 지키다 실수할 일도 없습니다.

그래서 공격면을 지도화하면서 던져야 할 질문은 항상 이것입니다. "이것이 정말 외부에 노출되어 있어야 하는가?" 발견되는 모든 자산, 열린 모든 포트, 노출된 모든 서비스에 대해 이 질문을 던지십시오. 답이 "아니오"이거나 "잘 모르겠다"라면, 그것은 줄일 수 있는 공격면입니다.

구체적인 축소의 방향은 다음과 같습니다.

  • 불필요한 포트를 닫습니다. 쓰지 않는 서비스의 포트는 방화벽에서 차단합니다. 6장에서 인바운드 포트를 0개로 만드는 극단적 축소를 다룹니다.
  • 불필요한 서비스를 끕니다. 기본으로 설치되었지만 쓰지 않는 서비스, 테스트용으로 띄웠다가 잊은 서비스를 종료합니다.
  • 불필요한 자산을 제거합니다. 더 이상 쓰지 않는 서버, 옛 서브도메인, 폐기된 API를 정리합니다.
  • 노출을 게이트 뒤로 옮깁니다. 외부에 직접 노출할 필요가 없는 것(관리 패널, 내부 도구 등)은 Zero Trust 게이트웨이 뒤로 옮겨, 공개 인터넷에서 보이지 않게 합니다(6장).
  • 기능을 최소화합니다. 소프트웨어의 쓰지 않는 기능, 과도한 권한, 불필요한 의존성을 줄입니다(원칙 1, 4장).

지도화와 축소는 한 쌍입니다. 지도를 그리는 이유는 줄이기 위해서이고, 줄이고 나면 지도가 단순해져 관리가 쉬워집니다.

5.3 네트워크 공격면 지도화: 포트와 서비스

이제 실제로 지도를 그려 보겠습니다. 가장 기본이 되는 네트워크 공격면부터 시작합니다. 핵심 질문은 "내 서버의 어떤 포트가 외부에 열려 있고, 거기서 무엇이 돌아가는가"입니다.

자신의 외부 포트 점검하기

자신의 서버를 외부의 시선에서 스캔하는 것은, 공격자가 1장에서 보는 것을 똑같이 보는 것입니다. 가장 널리 쓰이는 도구는 nmap입니다. Nmap은 대상의 어떤 포트가 열려 있고 거기서 무슨 서비스가 도는지 알아내는, 수십 년간 검증된 무료 네트워크 스캐너입니다. 데스크톱에 설치해 두면 됩니다.

# 자신의 서버에 대한 전체 포트 스캔과 서비스 버전 탐지
# 반드시 자신이 소유한 대상에만 사용하십시오.
nmap -sV -p- your-server-ip

# 더 빠르게, 자주 쓰이는 상위 포트만 점검
nmap -sV --top-ports 1000 your-server-ip

# UDP 포트도 점검 (시간이 오래 걸리며, 별도 권한이 필요할 수 있음)
sudo nmap -sU --top-ports 100 your-server-ip

-sV 옵션은 단순히 포트가 열려 있는지뿐 아니라, 그 포트에서 어떤 서비스가 어떤 버전으로 돌아가는지를 탐지하려 시도합니다. 이 버전 정보가 중요합니다. 4장에서 보았듯, 버전을 알면 그에 해당하는 알려진 취약점을 찾을 수 있기 때문입니다. 공격자도 정확히 이 정보를 노립니다.

현장에서 제가 새 서버를 맡으면 가장 먼저 하는 일이 바로 이 외부 스캔입니다. 인계받은 문서에는 "80, 443만 열려 있다"고 적혀 있어도, 실제로 밖에서 찍어 보면 잊힌 관리 포트나 옛 DB 포트가 같이 응답하는 경우가 드물지 않았습니다. 문서가 아니라 스캔 결과가 진짜 공격면입니다.

서버 내부에서 리스닝 포트 확인하기

외부 스캔과 함께, 서버 내부에서 실제로 어떤 프로세스가 어떤 포트를 듣고 있는지를 확인하는 것도 중요합니다. 외부 스캔은 방화벽에 막힌 포트를 못 보지만, 내부 확인은 모든 리스닝 포트를 보여 줍니다. 이 둘을 비교하면 "내부에서는 열려 있지만 방화벽이 막고 있는 포트"와 "외부까지 노출된 포트"를 구분할 수 있습니다.

# 현재 리스닝 중인 모든 포트와 해당 프로세스 (권장)
sudo ss -tulpn

# 전통적인 방식 (netstat)
sudo netstat -tulpn

# 특정 포트를 누가 듣고 있는지 확인
sudo ss -tulpn | grep ':3306'

이 결과를 보면서 5.2의 질문을 던지십시오. 여기 보이는 각 포트가 정말 필요한가? 외부까지 노출되어야 하는가? 모르는 프로세스가 포트를 듣고 있지는 않은가? 특히 데이터베이스(예: 3306, 5432)나 캐시(예: 6379) 같은 백엔드 서비스가 외부 인터페이스(0.0.0.0)에 바인딩되어 있다면, 그것은 즉시 점검해야 할 위험 신호입니다. 이런 서비스는 거의 항상 로컬(127.0.0.1)에만 바인딩되어야 합니다.

외부 자산 검색 엔진 활용

1장에서 본 Shodan, Censys 같은 인터넷 자산 검색 엔진은 공격자만의 도구가 아닙니다. 이들은 인터넷 전체를 미리 스캔해 "어떤 IP에서 무슨 서비스가 도는지"를 색인해 둔 검색 엔진으로, 내가 직접 스캔하지 않아도 이미 수집된 결과를 보여 줍니다. 방어자도 이를 이용해 "내 자산이 외부에 어떻게 보이는지", "내가 모르던 자산이 노출되어 있지는 않은지"를 확인할 수 있습니다. 자신의 IP 대역이나 도메인으로 검색하여, 공개적으로 색인된 자신의 자산 목록을 점검하는 것은 매우 유용한 자가 점검입니다. 내가 기억하지 못하는 자산이 검색 결과에 나타난다면, 그것이 바로 그림자 자산일 수 있습니다.

지금 당장 할 수 있는 일은 간단합니다. Shodan에서 자신의 서버 IP를 그대로 검색창에 넣어 보십시오(예: 1.2.3.4), 또는 자신의 도메인을 hostname:example.com 형태로 검색해 보십시오. Censys도 마찬가지로 IP나 도메인으로 조회할 수 있습니다. 무료 계정으로도 자기 자산 확인에는 충분합니다. 결과에 보이는 포트·배너·인증서 가운데 "이게 왜 밖에서 보이지?" 싶은 항목이 있다면, 그것이 바로 5.2에서 던진 질문("정말 노출되어야 하는가")의 대상입니다. 한 가지 유의할 점은, 검색 엔진의 색인은 며칠~몇 주 전 스냅숏일 수 있다는 것입니다. 그래서 검색 엔진 결과와 앞의 직접 Nmap 스캔을 함께 보는 것이 가장 정확합니다.

5.4 도메인과 서브도메인 공격면 지도화

네트워크 다음으로 중요한 것이 도메인과 서브도메인의 지도화입니다. 특히 서브도메인은 그림자 자산이 가장 많이 숨어 있는 곳입니다.

왜 서브도메인이 위험한가

조직은 시간이 지나면서 수많은 서브도메인을 만듭니다. www, mail, api, dev, staging, test, admin, old, backup, vpn 등 헤아릴 수 없습니다. 문제는, 이것들을 만들기는 쉬워도 추적하고 정리하기는 어렵다는 점입니다. 프로젝트가 끝나고, 담당자가 떠나고, 서비스가 폐기되어도, 서브도메인은 종종 그대로 남습니다.

이렇게 잊힌 서브도메인이 두 가지 위험을 만듭니다. 첫째, 그 뒤에 패치되지 않고 방치된 옛 서비스가 살아 있을 수 있습니다. 아무도 관리하지 않으니 취약점이 쌓여 갑니다. 둘째, 더 교묘한 위험으로 서브도메인 탈취(subdomain takeover) 가 있습니다. 서브도메인이 외부 서비스(클라우드 호스팅 등)를 가리키도록 설정되어 있는데, 그 외부 서비스 쪽 자원은 이미 해제된 경우, 공격자가 그 자원을 자신이 차지하여 당신의 서브도메인으로 악성 콘텐츠를 서비스할 수 있습니다. 당신의 신뢰받는 도메인 이름이 공격자의 손에 들어가는 것입니다.

자신의 서브도메인 열거하기

따라서 자신이 소유한 모든 서브도메인을 파악하는 것이 중요합니다. 공격자가 정찰에 쓰는 것과 같은 방법으로, 방어자도 자신의 서브도메인을 열거할 수 있습니다.

가장 중요한 출처는 1장에서 본 인증서 투명성(CT) 로그입니다. CT 로그란, 전 세계 인증기관이 발급한 TLS 인증서를 누구나 검증할 수 있도록 공개 기록으로 남기는 장부입니다. HTTPS를 쓰는 모든 호스트명이 여기 기록되므로, CT 로그를 조회하면 자신이 인증서를 발급받은 모든 호스트명을 확인할 수 있습니다. 이것은 공개 정보이므로 누구나(당신을 포함해) 조회할 수 있습니다. 가장 손쉬운 조회 창구는 crt.sh입니다. 브라우저에서 https://crt.sh/?q=%25.example.com처럼 자신의 도메인만 넣어도(여기서 %25는 와일드카드 %의 인코딩입니다) 발급 이력이 바로 보입니다.

# CT 로그를 조회하여 자신의 도메인에 대한 인증서 발급 기록 확인
# (예시: crt.sh의 JSON 출력을 가공)
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | python3 -c "import sys,json; [print(c['name_value']) for c in json.load(sys.stdin)]" \
  | sort -u

이 외에도 DNS 조회, 공개 데이터 출처를 종합하는 여러 서브도메인 열거 도구가 있습니다. 핵심은, 자신이 기억하는 서브도메인 목록과 실제로 존재하는 서브도메인 목록을 대조하는 것입니다. 기억에 없던 서브도메인이 나타난다면, 그것이 정리 대상 또는 점검 대상입니다.

DNS 레코드 점검

서브도메인 목록과 함께, 각 도메인의 DNS 레코드 자체도 점검해야 합니다. 어떤 레코드가 어디를 가리키는지, 더 이상 유효하지 않은 곳을 가리키는 레코드(앞서 말한 서브도메인 탈취의 원인)는 없는지, 메일 관련 레코드(SPF, DKIM, DMARC)는 제대로 설정되어 있는지 등입니다. 메일 인증 레코드의 부재나 오설정은 3장에서 본 피싱과 도메인 사칭의 통로가 될 수 있으므로 중요합니다. 아래 dig 명령이 번거롭다면, MXToolbox에 도메인만 넣어도 MX·SPF·DMARC 설정을 웹에서 한눈에 점검할 수 있습니다(메일 인증 설정은 부록 G에서 더 깊이 다룹니다).

# 도메인의 주요 DNS 레코드 조회
dig example.com ANY +noall +answer
dig example.com MX +short
dig example.com TXT +short      # SPF, DMARC 등 확인
dig _dmarc.example.com TXT +short

5.5 웹 애플리케이션 공격면 지도화

웹 서비스를 운영한다면, 웹 애플리케이션 자체가 큰 공격면입니다. 12장에서 웹 취약점을 깊이 다루므로, 여기서는 "무엇이 노출되어 있는지를 파악하는" 지도화에 집중합니다.

노출된 경로와 엔드포인트 파악

웹 애플리케이션의 공격면은 그것이 외부에 노출하는 모든 경로의 총합입니다. 사용자가 보는 페이지뿐 아니라, API 엔드포인트, 폼 제출 경로, 파일 업로드 지점, 그리고 의도치 않게 접근 가능한 경로까지 포함합니다.

특히 주의할 것은, 의도적으로 만든 경로가 아니라 실수로 노출된 경로입니다. 1장 1.3에서 본 것들이 대표적입니다. 노출된 .env나 .git, 백업 파일, 디버그 페이지, 관리 인터페이스, 문서화되지 않았지만 살아 있는 옛 API 등입니다. 이런 경로는 공식 문서에는 없지만 실재하며, 공격자의 자동 탐색에 걸립니다.

자신의 웹 애플리케이션이 어떤 경로를 노출하는지 파악하는 방법은 여러 가지입니다. 애플리케이션의 라우팅 정의를 직접 검토하는 것이 가장 정확하고, 웹 서버 로그를 분석해 실제로 어떤 경로에 요청이 오는지 보는 방법, 그리고 공격자의 시선에서 흔한 민감 경로의 노출 여부를 점검하는 방법도 있습니다.

민감 경로 노출 여부 자가 점검

다음은 가장 흔히 노출되는 민감 경로들이 자신의 사이트에서 접근 가능한지 빠르게 확인하는 예시입니다. 자신의 사이트에 대해서만 수행하십시오.

# 흔한 민감 경로의 노출 여부 점검 (자신의 사이트에만)
# 200 응답이 나오면 노출된 것이므로 즉시 차단해야 합니다.
for path in .env .git/config .git/HEAD config.php.bak \
            backup.sql .DS_Store phpinfo.php server-status; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://example.com/$path")
  echo "$code  /$path"
done

이 점검에서 .env나 .git/config 같은 경로에 200 응답이 나온다면, 그것은 심각한 정보 노출이며 9장과 11장에서 다룰 방법으로 즉시 차단해야 합니다. 노출된 .env 하나가 DB 비밀번호와 API 키를 통째로 넘겨주고, 노출된 .git은 소스 코드 전체를 복원하게 해 줍니다. 실제로 PHP/Laravel 환경에서는 디버그 모드가 켜진 채 노출된 정보가 원격 코드 실행으로 이어진 사례(Laravel Ignition, CVE-2021-3129)도 있었습니다. 이 자가 점검을 체계적으로 수행하고 결과를 우선순위와 함께 정리하는 것이, 10장에서 다룰 자가 진단의 핵심입니다. 이런 점검을 어떤 도구로 자동화하는지도 10장에서 함께 다룹니다.

클라이언트에 노출되는 정보

웹 애플리케이션에서 종종 간과되는 공격면은, 브라우저로 전송되는 클라이언트 측 코드입니다. 자바스크립트 파일, HTML 주석, 응답 헤더 등에 의도치 않게 민감한 정보가 담길 수 있습니다. 내부 API 주소, 주석으로 남긴 자격 증명, 디버그 정보, 사용 중인 기술과 버전 정보 등입니다. 3장에서 본 대로, 공격자는 이 클라이언트 측 코드를 (AI의 도움으로) 분석하여 약점의 단서를 얻습니다. 자신의 사이트가 브라우저로 무엇을 보내고 있는지 점검하는 것도 공격면 지도화의 일부입니다.

5.6 소프트웨어와 인프라 공격면 지도화

마지막으로, 4장과 직접 이어지는 소프트웨어 공격면, 그리고 클라우드 인프라 공격면을 다룹니다.

소프트웨어 인벤토리

4장의 우선순위화가 "내가 무엇을 쓰는지 안다"에서 시작했듯, 소프트웨어 인벤토리는 취약점 관리의 전제입니다. 운영체제, 웹 서버, 런타임, 데이터베이스, 그리고 애플리케이션이 의존하는 모든 라이브러리의 종류와 버전을 파악해야 합니다.

# 설치된 패키지 목록과 버전 (데비안/우분투 계열)
dpkg -l | awk '{print $2, $3}'

# 실행 중인 주요 서비스의 버전 확인 예시
nginx -v
php -v
mysql --version

# 보안 업데이트가 필요한 패키지 확인 (데비안/우분투)
apt-get update && apt-get -s upgrade | grep -i security

애플리케이션의 의존성은 사용하는 언어와 패키지 관리자에 따라 확인 방법이 다르지만, 핵심은 동일합니다. 직접 의존성뿐 아니라 4장에서 본 간접 의존성의 빙산 전체를 파악하고, 그중에 알려진 취약점이 있는 버전이 포함되어 있는지를 점검하는 것입니다. 인벤토리에서 특정 버전을 확인했다면, OSV나 GitHub Advisory에서 그 패키지 이름과 버전으로 알려진 취약점이 있는지 바로 조회할 수 있고, OS·서버 소프트웨어라면 NVD에서 검색하면 됩니다. 특히 "지금 실제로 악용되고 있는" 취약점만 추리고 싶다면 CISA KEV(알려진 악용 취약점 목록)를 함께 보십시오. 4장에서 강조했듯, 모든 CVE가 똑같이 급한 것이 아니라 실제 악용 여부가 우선순위를 가릅니다. 이 작업은 자동화에 적합하며, 부록 E의 영역 2에서 AI 활용을 다룹니다.

클라우드와 인프라 설정

클라우드 환경을 쓴다면, 인프라 설정 자체가 중요한 공격면입니다. 점검해야 할 주요 항목은 다음과 같습니다.

  • 스토리지 공개 설정. 클라우드 스토리지(버킷 등)가 의도치 않게 공개로 설정되어 있지 않은지. 이것은 대규모 데이터 노출의 흔한 원인입니다.
  • 보안 그룹과 방화벽 규칙. 클라우드 방화벽이 불필요하게 넓은 범위를 허용하고 있지 않은지. 0.0.0.0/0(모든 곳)에서의 접근을 허용하는 규칙은 특히 주의 깊게 검토해야 합니다.
  • 권한(IAM) 설정. 계정과 역할에 부여된 권한이 최소 권한 원칙을 따르는지, 과도한 권한을 가진 자격 증명이 없는지.
  • 관리 인터페이스 노출. 클라우드 관리 콘솔이나 인프라 관리 도구가 적절히 보호되고 있는지.
  • 노출된 자격 증명. 클라우드 접근 키가 코드나 설정 파일에 하드코딩되어 노출되어 있지 않은지.

이런 설정 점검 역시 사람이 일일이 검토하기보다, 자동화 도구와 AI의 도움을 받아 정기적으로 수행하는 것이 효과적입니다(부록 E의 영역 1).

5.7 인벤토리를 살아 있게 유지하기

공격면 지도화에서 가장 흔한 실패는, 한 번 멋지게 인벤토리를 만들어 놓고 그 후 갱신하지 않는 것입니다. 시스템은 끊임없이 변합니다. 새 서비스가 추가되고, 새 서브도메인이 생기고, 새 의존성이 들어오고, 설정이 바뀝니다. 어제의 정확한 지도가 오늘은 부정확해집니다. 이것은 원칙 5(보안은 과정이지 상태가 아니다)의 직접적인 적용입니다.

살아 있는 인벤토리를 유지하기 위한 현실적인 조언은 다음과 같습니다.

정기적으로 재발견하십시오. 5.3부터 5.6까지의 점검을 일회성이 아니라 주기적으로 반복하십시오. 정기적인 포트 스캔, 서브도메인 재열거, 의존성 재점검, 설정 재검토를 일정에 넣으십시오.

변화를 감지하십시오. 이상적으로는, 인벤토리에 변화가 생겼을 때(새 포트가 열렸다거나, 새 서브도메인이 나타났다거나) 그것을 자동으로 감지하고 알림을 받는 것이 좋습니다. 예상치 못한 변화는 그 자체로 점검해야 할 신호입니다. 누군가 모르게 무언가를 열었거나, 침해의 흔적일 수도 있습니다.

자동화하십시오. 이 모든 반복적 점검은 자동화에 이상적입니다. 사람이 매번 손으로 스캔하고 대조하는 것은 지속되지 못합니다. 점검을 스크립트로 만들어 정기 실행하고, 결과를 한곳에 모아 비교하며, AI의 도움으로 변화와 위험을 해석하게 하는 것이 현실적입니다(원칙 6, 부록 E). 그리고 4장에서 강조했듯, 새 CVE가 공개되거나 AI 모델이 업그레이드될 때를 재점검의 트리거로 삼으십시오.

문서로 남기십시오. 인벤토리는 머릿속이 아니라 문서로 존재해야 합니다. 특히 1인 운영이라도, 미래의 자신을 위해, 그리고 만약의 인수인계를 위해, 무엇이 어디에 왜 있는지를 기록해 두십시오. 그림자 자산의 상당수는 "그때는 알았지만 잊어버린" 자산입니다. 기록은 망각을 막습니다.

5.8 이 장이 남기는 교훈

이 장에서 확인한 것을 압축합니다.

첫째, 방어의 첫걸음은 도구가 아니라 지도입니다. 자신이 무엇을 가지고 있고 무엇이 노출되어 있는지를 모르면, 그 어떤 후속 방어도 토대가 없습니다.

둘째, 그림자 자산이 가장 약한 고리입니다. 잊힌 서버, 방치된 서브도메인, 문서화되지 않은 엔드포인트가 침해의 흔한 출발점입니다. 모르는 자산은 패치도 모니터링도 되지 않습니다.

셋째, 공격면은 여러 층위에 걸쳐 있습니다. 네트워크, 도메인, 웹 애플리케이션, 소프트웨어, 클라우드 인프라 — 각 층위를 빠뜨림 없이 지도화해야 합니다.

넷째, 지도화의 목적은 축소입니다. 모든 자산에 "이것이 정말 노출되어야 하는가"를 물으십시오. 존재하지 않는 것은 공격당하지 않습니다. 지키는 것보다 없애는 것이 근본적입니다(원칙 1).

다섯째, 자신을 공격자의 시선으로 보십시오. 공격자가 1장의 방법으로 당신을 발견하고 조사한다면, 당신은 같은 방법으로 자신을 먼저 점검하여, 그들이 찾기 전에 막아야 합니다.

여섯째, 인벤토리는 살아 있어야 합니다. 한 번 만들고 잊으면 무용지물입니다. 정기적으로 재발견하고, 변화를 감지하고, 자동화하고, 문서로 남기십시오(원칙 5, 6).

자, 이제 우리는 지도를 손에 쥐었습니다. 무엇이 노출되어 있는지 알았으니, 다음은 그것을 줄일 차례입니다. 그리고 공격면 축소의 가장 강력하고 극적인 형태가 다음 장에서 기다리고 있습니다. 인터넷에 열린 포트를 0개로 만드는 것 — 공격자가 두드릴 문 자체를 없애는 것입니다. 6장에서 Cloudflare Tunnel과 Zero Trust로 이 일을 어떻게 해내는지 살펴보겠습니다.

이 장의 실행 항목

  1. 자신의 서버를 외부에서 포트 스캔하십시오. 공격자가 보는 것을 똑같이 보십시오. (5.3)
  2. 내부 리스닝 포트를 확인하고 백엔드 서비스의 바인딩을 점검하십시오. 데이터베이스가 외부에 노출되어 있지 않은지 확인하십시오. (5.3)
  3. CT 로그로 자신의 모든 서브도메인을 열거하십시오. 기억에 없던 그림자 서브도메인을 찾으십시오. (5.4)
  4. 흔한 민감 경로의 노출 여부를 자가 점검하십시오. .env, .git 등이 접근 가능한지 확인하십시오. (5.5, 10장)
  5. 소프트웨어와 의존성 인벤토리를 만드십시오. 4장의 취약점 관리는 이 인벤토리 없이는 불가능합니다. (5.6, 4장)
  6. 클라우드 설정을 점검하십시오. 공개 스토리지, 넓은 방화벽 규칙, 과도한 권한이 없는지 확인하십시오. (5.6)
  7. 이 모든 점검을 정기 루틴으로 만들고 문서화하십시오. 인벤토리를 살아 있게 유지하십시오. (5.7, 부록 E)

다음 장: 6장 — 포트를 닫아라. Cloudflare Tunnel과 Zero Trust로 인바운드 포트를 0개로. 공격면 축소의 가장 극적인 형태.