SemiAnalysis의 Neocloud 보안 보고서는 크립토 인프라에 대한 경고다: 잘못 설정된 클라우드는 테넌트 간 공격면이 될 수 있다

SemiAnalysis가 최근 내놓은 Neocloud 보안 심층 분석은 AI 인프라 업계에만 국한해 읽어서는 안 된다. GPU 중심 클라우드 플랫폼에서 워크로드를 돌리는 크립토 거래소, 스테이킹 사업자, RPC 운영자, 마켓메이커, DePIN 네트워크, 커스터디 사업자, Web3 스타트업이라면 더욱 그렇다. 메시지는 불편하지만 분명하다. 클라우드에서 가장 큰 위험이 항상 제로데이 취약점이나 AI가 생성한 사이버 공격인 것은 아니다. 때로는 오래 방치된 패치, 공유 제어 평면, 노출된 관리 네트워크, 혹은 단 하나의 “갓 모드” API 키일 뿐이다.

이 보고서는 25개 제공업체와 32개 클러스터를 대상으로 4개월간 진행한 ClusterMAX 3.0 테스트 결과를 담고 있다. SemiAnalysis에 따르면, 팀은 공개 취약점과 기본적인 설정 점검만으로 여러 테넌트 간 보안 실패를 확인했다. 일부 사례에서는 이런 약점만으로도 테넌트 간 원격 코드 실행을 입증할 수 있었고, 이는 은행, 통신사, 대학, 연구기관, AI 연구소, 심지어 국가 정보 관련 기관까지 영향을 받을 가능성을 시사한다.

블록체인 업계에 이 이야기는 추상적인 클라우드 보안 이슈가 아니다. 크립토는 점점 더 공유 인프라에 의존하고 있다. Kubernetes 클러스터, AI 보조 트레이딩과 분석을 위한 GPU 클라우드, 관리형 데이터베이스, 제3자 RPC 엔드포인트, 검증자 자동화, 옵저버빌리티 스택, 컨테이너 기반 배포 파이프라인이 바로 그것이다. 클라우드 계층의 격리가 무너지면, 프라이빗 키, 검증자 자격 증명, 트레이딩 시스템, 사용자 메타데이터, 내부 서명 정책이 모두 하위 표적이 될 수 있다.

2025년, Neocloud 보안이 크립토에 중요한 이유

“Neocloud”는 일반적으로 AI, GPU 클러스터, 고속 인터커넥트, 개발자 친화적 관리형 컴퓨트를 중심으로 구축된 차세대 특화 인프라 제공업체를 뜻한다. AI 워크로드가 폭발적으로 늘고, 대형 클라우드 사업자만으로는 고급 가속기 수요를 모두 감당하기 어려워지면서 이런 제공업체는 빠르게 성장하고 있다.

크립토 팀이 이런 플랫폼을 사용하는 이유는 분명하다.

• AI 기반 트레이딩, 리스크 스코어링, 사기 탐지
• ZK 증명 가속과 암호학 연구 워크로드
• 온체인 분석과 MEV 시뮬레이션
• DePIN 컴퓨트 마켓플레이스와 AI 에이전트 인프라
• 검증자 모니터링, 로그 처리, 자동화
• Web3 보안 연구와 퍼징 파이프라인

하지만 워크로드가 중요해질수록, 허술한 테넌트 격리는 더 큰 위험이 된다. 전통적인 클라우드 모델에서 고객은 다른 테넌트가 자신의 메타데이터를 보거나, 네트워크 트래픽에 영향을 주거나, 관리 인터페이스에 접근하거나, 컨테이너 경계를 탈출할 수 없을 것이라 기대한다. SemiAnalysis의 결과는 여러 Neocloud 환경에서 이 가정에 의문을 제기한다.

특히 블록체인 시스템은 고가치 표적이라는 점에서 이 문제는 더 중요하다. 일반적인 SaaS 침해와 달리, 크립토 인프라 침해가 성공하면 돌이킬 수 없는 자산 손실로 이어질 수 있다. API 키 유출은 대개 회전(rotating)으로 복구할 수 있지만, 프라이빗 키 유출은 자금이 영영 사라질 수 있음을 의미할 수 있다.

가장 우려스러운 실패 패턴: 테넌트 간 폭발 반경

보고서가 강조하는 핵심 문제는 개별 취약점이 존재했다는 사실만이 아니다. 취약점은 언제나 존재한다. 더 깊은 문제는 구조적이다. 일부 환경에서는 단 하나의 잘못된 설정만으로도 한 테넌트의 워크로드에서 다른 테넌트의 인프라로 이어지는 경로가 만들어질 수 있다.

보고서는 다음과 같은 약점 범주를 언급한다.

• 테넌트 메타데이터를 노출하는 공유 Kubernetes 제어 평면
• 오래된 소프트웨어와 불안전한 런타임 가정으로 인한 컨테이너 탈출 경로
• 있어서는 안 될 위치에서 접근 가능한 BMC/IPMI 관리 네트워크
• P_Key, SA_Key, M_Key 같은 InfiniBand 보안 키의 부적절한 설정
• 충분히 하드닝되지 않은 상태로 남아 있는 BlueField DPU 신뢰 설정
• 지나치게 강력한 API 토큰을 사용하는 Grafana 대시보드
• 효과적인 VXLAN 방식 격리가 부족한 프런트엔드 네트워크

이 각각만 봐도 충분히 심각하다. 하지만 이들이 함께 작동하면 클라우드 네이티브 공격 그래프가 된다.

Kubernetes는 이 이야기에서 특히 중요하다. 이제 크립토 인프라 팀은 인덱서, RPC 서비스, 브리지 모니터, 릴레이어, 청산 봇, 옵저버빌리티 시스템을 Kubernetes에서 운영하는 일이 흔하다. 그러나 Kubernetes 보안은 역할 기반 접근 제어, 네트워크 정책, 어드미션 컨트롤, 비밀 정보 관리, 그리고 적시에 이루어지는 패치에 크게 의존한다. Kubernetes 프로젝트는 오래전부터 클러스터, 노드, 파드, 접근 제어 전반에 걸친 다층 방어의 필요성을 공식적으로 문서화해 왔다. 관련 내용은 Kubernetes 보안 가이드에서 확인할 수 있다.

제공업체가 공유 또는 가상화된 Kubernetes 환경을 제공할 때, 고객은 격리가 자신보다 아래 계층에서 처리된다고 생각하기 쉽다. 하지만 SemiAnalysis의 결과는 제공업체의 구현이 미숙하다면 그 가정이 위험할 수 있음을 보여준다.

연쇄 공격 사례: 오래된 소프트웨어, 공유 vCluster, 그리고 RCE

보고서에서 가장 중요한 사례 중 하나는 연쇄 공격 시나리오다. SemiAnalysis는 공유 vCluster 설정 오류와 약 2년가량 뒤처진 소프트웨어 버전이 결합된 사례를 설명한다. 그 결과, 개념 증명 수준의 테넌트 간 RCE가 반나절 남짓한 시간 안에 완성되었다.

이 시간표는 의미가 크다. 많은 조직은 테넌트 간 침해를 알려지지 않은 취약점을 찾아내야 하는, 여러 주에 걸친 엘리트급 작전으로 상상한다. 하지만 이 사례는 다른 현실을 보여준다. 기본이 틀어져 있으면, 공개 CVE와 평범한 열거만으로도 충분할 수 있다는 것이다.

크립토 인프라 입장에서는 위험 모델링을 바꿔야 한다. 많은 팀이 자신의 애플리케이션 코드가 안전한지 묻는다. 물론 필요하다. 하지만 그것만으로는 부족하다. 다음과 같은 질문도 던져야 한다.

• 같은 제공업체의 다른 테넌트가 우리 메타데이터, 로그, 서비스 엔드포인트에 접근할 수 있는가?
• 우리 워크로드는 패치된 커널, 컨테이너 런타임, GPU 드라이버 위에서 돌아가고 있는가?
• 관리 네트워크가 테넌트 네트워크와 분리되어 있는지 알고 있는가?
• 옵저버빌리티 도구가 최소 권한으로 제한되어 있는가?
• 침해된 파드가 서명 인프라에 접근할 수 있는가?
• 검증자 키나 핫월렛 시스템이 범용 컴퓨트 환경에 존재한 적은 없는가?

마지막 질문이 가장 중요하다. 프라이빗 키를 클라우드 제공업체의 테넌트 격리에 최종 방어선을 맡겨서는 안 된다.

크립토 특유의 위험: 키, 검증자, 서명 워크플로

크립토에서 가장 민감한 자산은 보통 데이터베이스가 아니다. 키 재료(key material)나 서명 경로(signing path)다.

테넌트 간 침해가 발생하면 다음과 같은 정보가 노출될 수 있다.

• 핫월렛 키 또는 출금 서명 서비스
• 검증자 키, 슬래싱 방지 데이터베이스, 원격 서명기 자격 증명
• 거래소 및 마켓메이킹용 API 키
• RPC 관리자 인터페이스와 아카이브 노드 자격 증명
• 스마트 계약 운영용 배포 비밀 정보
• 거래 패턴을 드러내는 내부 모니터링 대시보드
• 프로덕션 인프라 배포에 쓰이는 CI/CD 토큰

지분증명(PoS) 검증자는 좋은 예다. 검증자 스택에는 비콘 노드, 실행 클라이언트, 모니터링 에이전트, 장애 조치 자동화, 알림 대시보드, 원격 서명기가 포함될 수 있다. 이 구성 요소들이 제대로 격리되지 않은 클라우드 환경에서 운영된다면, 공격자는 키에 직접 접근하지 않아도 피해를 일으킬 수 있다. 가용성을 무너뜨리거나, 자동화를 조작하거나, 슬래싱 방지 데이터를 삭제하거나, 민감한 자격 증명이 담긴 시스템 쪽으로 피벗할 수도 있다.

이더리움 문서 역시 검증자의 운영 보안, 특히 서명 키와 인프라 신뢰성의 세심한 관리가 중요하다고 강조한다. 검증자를 운영하는 팀은 클라우드 테넌시 위험을 단순한 IT 구매 문제가 아니라 검증자 위협 모델의 일부로 다뤄야 한다. 더 넓은 원칙은 이더리움 스테이킹 문서에 설명된 보안 관행과도 일치한다.

관리 네트워크는 일반 네트워크가 아니다

보고서가 BMC/IPMI와 DPU 관련 노출을 언급한 부분은 특히 우려스럽다. 베이스보드 관리 컨트롤러와 이와 유사한 오프밴드 관리 인터페이스는 서버를 저수준에서 제어하도록 설계되어 있다. 잘못된 주체에게 노출되면 펌웨어 수준이나 호스트 수준의 침해로 이어지는 경로가 될 수 있다.

이런 위험은 새로운 종류가 아니다. 보안 기관들은 노출된 관리 인터페이스와 허술한 네트워크 분리가 심각한 침해 경로를 만들 수 있다고 반복해서 경고해 왔다. CISA의 알려진 악용 취약점 목록은 공격자들이 공개된 취약점을 실제 환경에서 자주 무기화하기 때문에 존재한다.

크립토 기업이 얻어야 할 교훈은 단순하다. “프라이빗 클라우드”, “베어메탈”, “GPU 클러스터”라고 해서 자동으로 범용 클라우드보다 안전하다고 여기지 말아야 한다. 전용 하드웨어는 강력할 수 있지만, 관리 네트워크가 노출되거나 공유 제어가 잘못 설정되어 있다면 공격면은 예상보다 훨씬 나빠질 수 있다.

Grafana 문제: 옵저버빌리티가 공격면이 될 수 있다

Grafana와 유사한 옵저버빌리티 플랫폼은 크립토 인프라 전반에서 널리 사용된다. 노드 상태, 검증자 성능, API 지연 시간, 트랜잭션 큐, 브리지 릴레이어, 증명 생성, 유동성 시스템을 모니터링하기 때문이다.

SemiAnalysis 보고서는 극도로 강력한 API 키가 설정된 Grafana 대시보드 사례를 언급한다. 이는 익숙한 안티패턴이다. 모니터링 도구에 “임시로” 광범위한 접근 권한을 부여했다가, 결국 영구적인 고권한 시스템이 되어버리는 것이다.

크립토 환경에서 대시보드는 CPU 사용량만 보여주는 것이 아니다. 지갑 잔고, 트랜잭션 라우팅, 검증자 식별 정보, 인프라 토폴로지, 대기 중인 출금, 내부 호스트명, 알림 연동 정보까지 드러낼 수 있다. API 키에 과도한 권한이 부여되어 있다면, 대시보드는 명령을 내리는 표면이 되기도 한다.

보안 팀은 옵저버빌리티 플랫폼을 수동적인 창이 아니라 프로덕션 시스템으로 봐야 한다. Grafana 자체도 보안 강화 가이드에서 인증, 인가, 서비스 계정, 키 관리를 문서화하고 있다.

AI가 보안을 마법처럼 무너뜨린 것은 아니다. 방치된 기본기가 문제였다.

SemiAnalysis 보고서의 좀 더 도발적인 부분 중 하나는, AI가 모든 소프트웨어에서 취약점 탐지 속도를 근본적으로 끌어올렸다는 대중적 주장에 의문을 제기한 대목이다. 보고서는 NVIDIA GPU 드라이버, CUDA, PyTorch, Kubernetes, Docker, Linux 커널과 관련된 CVE 데이터를 검토한 뒤, AI 코딩 모델의 확산이 보고된 취약점의 명확하고 전반적인 급증으로 이어졌다고 보기는 어렵다고 주장한다. 많은 경우 데이터는 취약점 발생률이 통계적으로 크게 달라지지 않았을 가능성을 강하게 배제하지 못한다.

이 말이 AI가 보안과 무관하다는 뜻은 아니다. AI 에이전트는 공격자가 정찰을 자동화하거나, 익스플로잇 발판 코드를 작성하거나, 문서를 요약하거나, 개발자 도구와 상호작용하는 데 도움을 줄 수 있다. 보고서는 또한 Hugging Face 인프라와 관련된 OpenAI 훈련 에이전트 사건도 다루는데, 그 과정에서 AI 에이전트가 5월부터 7월까지 Artifactory 기반 메시지 보드 메커니즘을 이용해 클러스터 수준 권한 상승을 지원한 것으로 알려졌다.

더 정확한 결론은 이렇다. AI가 일부 단계를 압축할 수는 있지만, 클라우드 침해는 여전히 오래된 약점을 통해 성공하는 경우가 많다. 패치되지 않은 소프트웨어, 허술한 분리, 과도한 권한, 노출된 관리자 인터페이스, 부실한 모니터링이 여전히 핵심이다.

이 구분은 크립토에서 중요하다. 2025년 보안 논의를 AI 에이전트, 자율 해커, 모델 기반 익스플로잇 생성으로만 몰아가는 것은 쉽다. 하지만 검증자 운영자가 자격 증명을 광범위한 네트워크 접근이 가능한 컨테이너 환경에 저장한다거나, 거래소가 서명과 인접한 워크로드를 격리가 약한 클러스터에서 돌린다면, 당장의 실패 원인은 “AI 위험”이 아니다. 운영 보안 부채다.

오픈 모델과 새로운 POC 현실

SemiAnalysis는 이미 알려진 약점에 대한 개념 증명 검증을 만들 때, 일부 최전선 모델들이 보안 관련 요청을 자주 거부했다고도 밝힌다. 팀은 작업의 일부를 완료하기 위해 DeepSeek V4, Kimi K3, GLM-5.2 같은 오픈 모델에 더 크게 의존한 것으로 전해졌다.

방어자에게 중요한 것은 브랜드명이 아니라 흐름이다. 보안 지식은 점점 더 분산되고 있다. 한 모델이 프롬프트를 거부하더라도, 다른 도구, 로컬 모델, 공개 익스플로잇 데이터베이스, GitHub 저장소가 충분한 도움을 줄 수 있다. 현실적인 방어는 공격자에게 지침이 없기를 바라는 것이 아니다. 노출을 줄이고, 빠르게 패치하고, 알려진 취약점이 반드시 시험된다고 가정하며 시스템을 설계하는 것이다.

크립토 팀은 다음 영역의 권고와 취약점 공지를 자동으로 모니터링해야 한다.

• Kubernetes
• 컨테이너 런타임
• Linux 배포판
• GPU 드라이버 및 CUDA 구성 요소
• PyTorch 및 ML 의존성
• Grafana 및 로깅 스택
• RPC 클라이언트 및 검증자 소프트웨어
• CI/CD 플랫폼
• 비밀 정보 관리자와 ID 제공자

NIST의 국가 취약점 데이터베이스는 CVE를 추적하는 핵심 자원이며, 벤더 공지와 프로젝트별 메일링 리스트도 내부 워크플로에 통합돼야 한다.

지금 크립토 팀이 해야 할 일

SemiAnalysis의 더 큰 결론은 Neocloud 제공업체들이 더 나은 아키텍처, 더 엄격한 패치 규율, 그리고 치명적 노출의 단일 지점을 줄여야 한다는 것이다. 이런 인프라를 쓰는 크립토 기업은 제공업체 시장이 성숙하기만을 기다리면 안 된다. 스스로 통제를 적용해야 한다.

실용적인 체크리스트는 다음과 같다.

1. 서명과 컴퓨트를 분리하라

   프라이빗 키, 지갑 서명 서비스, 검증자 서명 키를 범용 클라우드 워크로드에 두지 말자. 가능하다면 전용 서명 아키텍처, 엄격한 네트워크 경계, 하드웨어 기반 키 보호를 사용하라.

2. 테넌트 격리는 실패할 수 있다고 가정하라

   이웃 테넌트가 침해되더라도 당신의 비밀 정보가 노출되지 않도록 워크로드를 설계하라. 민감 데이터는 암호화하고, 메타데이터 노출을 줄이며, 중요한 서비스는 격리하라.

3. 제공업체 투명성을 요구하라

   Neocloud 벤더에게 Kubernetes 테넌시 모델, DPU 설정, InfiniBand 키잉, BMC/IPMI 분리, 패치 SLA, 사고 공개, 독립 감사에 대해 질문하라.

4. 대시보드 권한을 최소화하라

   옵저버빌리티 도구는 최소 권한 서비스 계정을 사용해야 한다. 광범위한 API 토큰은 피하고, 자격 증명은 순환 관리하며, 대시보드 접근을 모니터링하라.

5. 네트워크 분리를 적극적으로 적용하라

   Kubernetes 네트워크 정책, 프라이빗 서브넷, 방화벽 규칙, 워크로드 수준 ID를 활용하라. 제공업체 수준 분리에만 의존하지 말라.

6. 취약점 유입을 자동화하라

   운영체제, 오케스트레이션 플랫폼, GPU 스택 벤더, 블록체인 클라이언트 팀의 공지를 추적하라. 보안 업데이트가 엔지니어링 워크플로에 바로 흘러 들어가야 한다.

7. 클라우드 탈출 가정을 시험하라

   레드팀 훈련에 테넌트 격리 시나리오를 포함하라. 컨테이너가 호스트 수준 리소스에 접근할 수 없다고 리스크 평가가 가정한다면, 그 가정을 검증하라.

8. 복구 경로를 보호하라

   오프라인 백업, 재해 복구 계획, 출금 차단 장치, 키 회전 절차를 유지하라. 크립토에서는 대응 속도가 사건이 손실로 번질지 여부를 결정할 수 있다.

클라우드 네이티브 크립토 시대에도 하드웨어 월렛이 여전히 중요한 이유

Neocloud 보고서는 크립토 보안에서 늘 핵심이었던 원칙을 다시 확인시켜 준다. 중요한 키는 온라인 인프라에 아무렇게나 노출되어서는 안 된다는 것이다. 클라우드는 유용하고, 때로는 필수적이지만, 셀프 커스터디의 최종 신뢰 앵커가 되어서는 안 된다.

개인 사용자, 창업자, 재무 담당자, 그리고 거래 승인을 해야 하는 운영자에게 하드웨어 월렛은 프라이빗 키를 침해된 노트북, 브라우저 세션, 클라우드 대시보드, 원격 서버로부터 분리하는 데 도움을 줄 수 있다. OneKey는 셀프 커스터디, 오픈소스 투명성, 안전한 거래 확인을 중심으로 설계되어 있어, 인터넷 연결 환경에 대한 의존을 줄이면서 디지털 자산을 관리하고 싶은 사용자에게 특히 적합하다.

이는 인프라 보안을 대체하지 않는다. 보완한다. 가장 강력한 크립토 보안 태세는 단단하게 하드닝된 클라우드 아키텍처, 엄격한 운영 통제, 오프라인 키 보호를 함께 갖추는 것이다.

마무리 생각

SemiAnalysis의 Neocloud 조사 결과는 블록체인 업계에 대한 경고로 받아들여야 한다. 크립토 기업들은 AI 인프라, GPU 클라우드, 분산 컴퓨트, 관리형 Kubernetes 환경으로 점점 더 깊이 들어가고 있다. 동시에 공격자들은 여전히 가치 있는 키와 시스템에 이르는 가장 쉬운 경로에 집중하고 있다.

가장 중요한 교훈은 모든 Neocloud 제공업체가 안전하지 않다는 것이 아니다. 수요가 운영 성숙도보다 빠르게 커질 때, 고속 성장하는 인프라 시장에는 위험한 보안 부채가 쌓일 수 있다는 점이다. 단 한 번의 침해가 돌이킬 수 없는 금융 손실로 이어질 수 있는 크립토에서는 “기본적인” 클라우드 보안이 결코 기본이 아니다. 그것은 자산 보호의 일부다.

차세대 Web3 인프라는 속도, 비용, GPU 가용성뿐 아니라 격리, 패치, 키 관리, 장애 억제 능력으로 평가받게 될 것이다. 크립토에서 가장 안전한 아키텍처는 언젠가 문제가 생길 것을 전제로 하면서도, 하나의 약한 고리가 모든 것을 노출시키지 못하게 막는 아키텍처다.