클라우드 보안에서 “밖에서 보인다”는 말은 생각보다 애매해. 설정표만 보면 열려 있는 것처럼 보이지만, 실제 인터넷에서는 닿지 않을 수도 있어. 반대로 여러 설정이 겹치면서 운영자가 예상하지 못한 문이 바깥에 보일 수도 있고.
AWS가 Security Hub에 붙인 Network Scanning은 이 애매함을 줄이려는 기능이야. 보안그룹과 라우팅 표를 보고 “닿을 수도 있다”고 추정하는 데서 멈추지 않고, 인터넷 쪽에서 직접 확인해 실제로 닿는 리소스와 열린 포트, 그 뒤의 서비스를 찾겠다는 발표거든.1
무슨 일
Security Hub는 AWS의 보안 상태를 모아 보여주는 서비스야. 최근에는 Azure 리소스까지 같은 화면에서 점검하는 쪽으로 범위를 넓혔고, 이번에는 점검 방식 하나를 더했다.
핵심은 “가능성”과 “실제 도달”을 나누는 거야.
기존의 network reachability finding은 보안그룹, 라우팅 표, 네트워크 설정을 보고 어떤 리소스가 인터넷에서 닿을 수 있는 상태인지 판단해. 이건 중요하지만 어디까지나 구성 기반 점검이야. Network Scanning은 거기서 한 걸음 더 나가, 인터넷에서 리소스를 직접 찔러보고 실제로 응답하는지 확인한다.
발표문에서 확인되는 대상은 AWS와 Azure 환경의 public IP, virtual machine, load balancer야. 스캔은 reachable port를 찾고, 그 뒤에서 어떤 서비스가 떠 있는지도 확인한다. 발견된 포트마다 Security Hub finding이 만들어지고, Security Hub Exposures가 다른 보안 결과와 리소스 구성을 묶어 더 큰 위험도를 판단한다고 설명돼.1
왜 중요한가
보안팀이 진짜 알고 싶은 건 “설정이 이론상 위험한가”보다 “공격자가 지금 볼 수 있는가”에 가까워. 설정표는 원인을 찾는 데 좋고, 바깥에서 본 결과는 우선순위를 정하는 데 좋다.
예를 들어 어떤 서버의 포트가 열려 있다는 사실만으로는 부족해. 그 서버가 실제 인터넷에서 닿는지, 어떤 서비스가 답하는지, 다른 취약점이나 권한 문제와 같이 묶일 때 얼마나 위험한지가 중요하지. AWS가 이 기능을 Security Hub Exposures와 연결한다고 말하는 이유도 여기에 있어. 단일 포트 목록이 아니라, 여러 보안 결과를 묶어 “이 노출이 얼마나 큰 문제인가”를 보겠다는 프레임이야.
이 변화는 멀티클라우드 보안에서도 이어져. 발표문은 AWS와 Azure 환경을 함께 언급해. 그러면 Security Hub는 단순히 AWS 계정 안의 설정 검사기가 아니라, 여러 클라우드의 외부 노출을 같은 방식으로 재는 화면에 가까워진다. AWS가 경쟁 클라우드까지 자기 보안 화면 안으로 끌어오는 흐름이 한 번 더 강화된 셈이야.
확인된 것과 AWS의 프레임
확인된 것은 기능 범위야. Network Scanning은 AWS와 Azure의 public IP, virtual machine, load balancer를 발견하고, 인터넷에서 닿는 포트와 서비스를 확인한다. 기존 Security Hub 고객은 계정·리전 단위나 조직 정책으로 켤 수 있고, 새 Security Hub 고객에게는 기본으로 켜진다. Security Hub Essentials에 포함되어 추가 비용은 없다고 설명돼.1
AWS의 프레임은 분명해. “우리가 더 많은 위험을 자동으로 찾아서 한 화면에서 연결해주겠다”는 쪽이야. 이 말은 맞지만, 곧바로 “보안팀의 일이 끝난다”는 뜻은 아니야.
스캔이 알려주는 건 바깥에서 보이는 표면이야. 실제로 위험을 줄이려면 왜 열렸는지, 어떤 팀이 소유하는지, 닫아도 서비스가 깨지지 않는지, 예외 승인이 있는지까지 이어져야 해. 특히 Azure 리소스까지 같은 화면에서 보게 되면, 발견은 AWS가 해도 수정 권한과 운영 책임은 다른 조직·도구에 남을 수 있어.
그래서 이 기능의 가치는 “자동으로 다 막아준다”가 아니라 “공격자가 볼 수 있는 것을 먼저 줄 세운다”에 있어. 보안 운영에서 이 차이는 커. 모든 경고를 같은 무게로 보면 아무것도 못 고치지만, 실제 인터넷에서 닿는 것부터 보이면 첫 수가 정해지거든.
다음에 볼 것
첫째, 이 스캔 결과가 실제 대응 흐름까지 이어지는지 봐야 해. finding이 생기는 것과 티켓이 닫히는 것은 다른 문제야. Security Hub가 EventBridge나 기존 대응 도구와 얼마나 자연스럽게 이어지는지가 중요해질 거야.
둘째, Azure 지원의 깊이를 봐야 해. 이번 발표는 리소스 발견과 외부 노출 확인을 말하지만, 클라우드마다 권한 모델과 네트워크 구조가 다르다. AWS 화면에서 본 Azure 위험이 Azure 쪽 실제 수정 흐름과 얼마나 잘 맞는지는 따로 확인해야 해.
셋째, 보안 제품의 경쟁 축이 “설정 점검”에서 “실제 노출 관리”로 움직이는지 봐야 해. 클라우드가 복잡해질수록 보안팀은 수천 개의 경고보다, 지금 바깥에서 보이는 문부터 알고 싶어 할 가능성이 크다.
클라우드 보안의 첫 질문은 점점 단순해지고 있어.
밖에서 실제로 보이는 게 뭐야?
댓글