보안 AI에 모이는 데이터
보안 AI에 들어가는 정보는 공격자가 가장 원하는 것들입니다. 어떤 서버에 어떤 취약점이 남아 있는지, 관리자 계정이 어디서 로그인하는지, 내부망이 어떻게 나뉘어 있는지. 침입한 공격자가 몇 주를 들여 모을 정보가 한곳에 정리돼 있는 셈입니다.
AI 플랫폼에서 테넌트 경계가 깨진 사례
Wiz Research는 2024년 AI 서비스 플랫폼 두 곳에서 테넌트 격리를 깬 연구를 공개했습니다. Hugging Face에서는 Pickle 형식 모델 파일에 역방향 셸을 심어 비공개 모델로 올린 뒤 추론 API로 불러 코드를 실행했고, 컨테이너 탈출로 다른 고객의 모델에 접근할 수 있는 상태까지 갔습니다. Replicate에서는 악성 Cog 컨테이너로 비슷한 경로를 밟아 다른 고객의 프롬프트와 결과에 접근할 수 있었다고 밝혔습니다. 두 회사 모두 Wiz와 협력해 문제를 고쳤습니다.
두 사례에는 공통점이 있습니다. 고객이 올린 모델이나 컨테이너, 다시 말해 고객이 정한 코드가 공유 인프라에서 실행됐습니다. AI 서비스는 구조상 이런 일이 잦습니다. 같은 클러스터에 다른 고객의 작업이 올라와 있다면 우리 데이터의 안전은 그 클러스터의 격리가 얼마나 단단한지에 달리게 됩니다.
Genox가 택한 구조
Genox는 다른 고객과 연산 자원이나 네트워크를 나눠 쓰지 않습니다. 각 서브시스템은 다른 작업이 올라오지 않도록 지정한 전용 노드에서 돌고, 밖으로 나가는 통신은 정책으로 막습니다. Kubernetes 위에 이런 구성을 만든다면 대략 아래 모양이 됩니다.
# 예시: 전용 노드 지정 (다른 워크로드가 올라오지 않게)
kubectl taint nodes gx-node-01 dedicated=tenant-a:NoSchedule
# 예시: 네임스페이스 기본 외부 통신 차단
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-egress
namespace: tenant-a
spec:
podSelector: {}
policyTypes: ["Egress"]
taint는 다른 파드가 그 노드에 올라오는 것만 막습니다. 해당 고객의 파드에는 toleration과 함께 nodeAffinity를 걸어야 전용 노드로 갑니다. 이걸 빼먹으면 전용 노드는 비어 있고 고객 파드는 공용 노드에 뜨는 일이 생깁니다. NetworkPolicy도 클러스터의 네트워크 플러그인이 지원해야 실제로 동작하니 적용 후 꼭 시험해 보세요.
설치는 폐쇄망이 기본입니다. 클라우드를 쓰실 때도 국내 리전에 고객 전용 환경을 따로 구성합니다.
대가도 있습니다
전용 환경은 비쌉니다. 쓰지 않는 시간에도 자원이 고객 몫으로 잡혀 있습니다. 폐쇄망에서는 외부에 호스팅된 모델을 부를 수 없으니 모델과 탐지 규칙 업데이트를 반출입 절차에 맞춰 따로 전달해야 하고, 반영도 그만큼 늦습니다.
보안 AI가 다루는 데이터를 생각하면 저희는 이 비용을 치를 만하다고 봅니다. 그래도 모든 조직에 같은 답이 맞지는 않습니다. 다루는 데이터와 규제 요건, 운영 인력을 놓고 함께 따져 보시길 권합니다.
참고 자료
- Wiz and Hugging Face address risks to AI infrastructure, Wiz, 2024.4
- Wiz Research discovers critical vulnerability in Replicate, Wiz, 2024.5
- Taints and Tolerations, Kubernetes 문서
- Network Policies, Kubernetes 문서
