render farm 네트워크 세분화 및 WireGuard 보안: Tier-1 + Tier-2 아키텍처

소개

render farm은 렌더링 문제이기 전에 네트워크 문제입니다. 프레임은 submission 머신, manager, worker 플릿, 에셋 캐시, 출력 스토어 사이를 흐릅니다; 자격 증명(license seat)은 아티스트와 라이선스 서버 사이를 흐릅니다; 원격 세션은 아티스트와 그들이 조작하는 workstation 표면 사이를 흐릅니다. 네트워크가 한 방의 한 스위치일 때 보안 모델은 대부분 경계 모델입니다. farm이 데이터센터나 대륙을 가로지를 때 경계는 더 이상 유용한 분석 단위가 아닙니다: 건물 경계를 넘는 모든 링크는 반대로 입증될 때까지 공용 인터넷 링크이며, 원격 시스템에 닿는 모든 자격 증명은 가로채일 수 있고, 모든 다른 worker에 도달할 수 있는 모든 worker는 한 번 침해되면 피벗할 수 있는 worker입니다.

이 문서는 우리가 cross-site 및 cross-country render farm 배포에 운영하는 보안 아키텍처를 설명합니다 — default-deny 엣지를 갖춘 2단계 방화벽 모델, 그 뒤에 노드별 호스트 방화벽, 건물 경계를 넘는 모든 링크에 대한 WireGuard 종단간 암호화, 모든 운영자 역할에 대한 최소 권한 접근 패턴, 그리고 공유 multi-tenant 인프라부터 단일 고객 dedicated 클러스터까지 확장되는 고객 격리 기본 요소입니다. 대상 청중: cloud-rendering 벤더를 평가하는 IT 보안 팀, compliance 담당자, 파이프라인 아키텍트. 네트워크 아키텍처에 대한 별도 글 — WireGuard hub-and-spoke, BBR, MSS clamping, 공유 SMB 캐시 — 가 전송을 다룹니다; 이 문서는 와이어 위에서 일어나는 일을 다룹니다.

render farm을 위한 네트워크 세분화 원칙

여기서 세분화는 세 가지 별개의 것을 의미합니다. 첫째, 어떤 노드도 그 job을 위해 도달할 필요가 없는 다른 노드에 도달할 수 없습니다. render worker는 캐시에서 에셋을 읽고, manager로부터 job을 가져오고, 알려진 위치에 출력을 다시 쓰고, 하트비트 텔레메트리를 보냅니다 — 그리고 그 외엔 아무것도 없습니다. 다른 worker로 피벗하거나, 운영자 SSH에 도달하거나, 관리 평면에 도달할 수 없는 침해된 worker는 클러스터 전체 실패가 아닌 봉쇄된 실패입니다. 측면 이동은 세분화 정책이 방지하는 가장 결과적인 것입니다.

둘째, 어떤 고객도 다른 고객에게 도달할 수 없습니다. multi-tenant 인프라에서 이는 프로세스, 사용자 계정, 파일 시스템 경로, 라이선스 체크아웃이 운영체제 수준에서 고객별로 격리됨을 의미합니다. dedicated 클러스터 인프라에서 이는 물리적 하드웨어 경계, 별도 WireGuard 허브, 별도 자격 증명 저장소, 별도 운영 관리 표면을 의미합니다. 격리의 강도는 workload의 민감성과 일치해야 합니다 — 제품 시각화를 렌더링하는 프리랜서와 사전 출시 엔터테인먼트 작업을 렌더링하는 스튜디오는 같은 수준이 필요하지 않지만, 그들의 위협 모델에 맞는 수준을 선택할 수 있어야 합니다.

셋째, 어떤 고객도 job이 실제로 필요로 하는 표면을 넘어 운영자의 내부 시스템에 도달할 수 없습니다. 렌더 submission은 manager의 job 큐에 쓰고 자신의 출력을 읽습니다; 다른 고객을 열거하거나, 운영자의 빌링 데이터베이스를 읽거나, 운영자의 소스 컨트롤에 도달할 필요가 없습니다. 이것이 운영자 자신의 시스템을 통해 모든 고객을 모든 다른 고객으로부터 보호하는 권한 경계입니다.

우리가 운영하는 티어 모델은 이 세 가지 원칙을 반영합니다. Tier 1은 경계입니다 — 공용 인터넷을 향한 엣지 게이트웨이로 어떤 트래픽이 들어올지 결정합니다. Tier 2는 노드별 호스트 방화벽입니다 — 경계 내부의 각 머신은 어떤 피어로부터 연결을 수락할지 독립적으로 결정합니다. 두 티어 위에서 애플리케이션 계층 접근 제어는 역할 분리, 고객 격리, compliance 리뷰가 주목하는 감사 경계를 시행합니다. 각 티어는 독립적으로 감사 가능합니다; 한 티어의 실패는 다른 티어를 무너뜨리지 않습니다.

ufw와 default-deny를 사용한 Tier-1 엣지

클러스터의 엣지는 ufw를 실행하는 단일 Linux 게이트웨이입니다 — Ubuntu LTS에서 nftables의 표준 프론트엔드입니다. 구성된 자세는 default deny incoming 및 default allow outgoing입니다. 공용 인터페이스의 유일한 인바운드 규칙은 WireGuard용 allow 51820/udp입니다. 그 외 어떤 것도 공용 측에서 트래픽을 수락하지 않습니다 — SSH 없음, HTTPS 없음, SMB 없음, render manager API 없음, 모니터링 에이전트 없음. 이러한 서비스는 내부 인터페이스에만 바인딩합니다; 클러스터 외부에서 도달하려면 먼저 WireGuard 터널을 종단해야 합니다.

근거는 기계적입니다. 공용 인터넷의 모든 열린 포트는 몇 분 안에 스캔되고 이후 지속적으로 프로브됩니다. 공용 포트 수를 정확히 하나로 줄이고, 그 포트가 인증되지 않은 프로브에 응답하지 않는 프로토콜(WireGuard는 모르는 피어에게 아무것도 응답하지 않습니다)을 말하게 하면 공격 표면이 가장 작은 의미 있는 단위로 감소합니다. WireGuard 터널 뒤의 SSH는 공격자가 먼저 WireGuard를 격파하지 않고는 도달할 수 없는 표적입니다.

포워드 체인은 명시적인 주의가 필요합니다. 게이트웨이는 WireGuard 인터페이스와 내부 클러스터 서브넷 사이의 라우터로 작동하며, ufw의 기본 forward 자세는 deny입니다. /etc/default/ufw에 DEFAULT_FORWARD_POLICY="ACCEPT"를 설정한 다음 알려진 클러스터 서브넷 간 트래픽을 허용하고 그 외 모든 것을 거부하는 명시적 FORWARD 체인 규칙으로 실제로 포워딩되는 흐름을 좁힙니다. 결과는 감사 가능하며 누구도 의도하지 않은 목적지로 실수로 패킷을 라우팅하지 않는 경계입니다.

아웃바운드 규칙은 같은 규율을 요구합니다. worker는 작은 업스트림 에셋 스토어 집합에서 가져오고, manager는 작은 라이선스 서버 집합과 통신하며, 텔레메트리는 작은 모니터링 엔드포인트 집합으로 가고, OS 패키지 업데이트는 알려진 미러에서 가져옵니다. 아웃바운드 목적지를 그 작은 집합으로 잠그면 침해 후 동작의 전체 클래스가 차단됩니다: 공격자가 제어하는 호스트로 데이터를 빼내려는 침해된 worker는 호스트가 egress allowlist에 없기 때문에 도달하지 못합니다. Egress 필터링은 보이지 않는 빼내기를 모니터링이 플래그할 수 있는 시끄러운 시도로 바꿉니다.

Tier-1 엣지의 로깅은 모든 인바운드 폐기 패킷과 라우터 체인의 모든 포워드된 흐름을 기록하며, 인증된 운영자 워크스테이션에서만 도달 가능한 동일한 WireGuard 터널 뒤의 중앙 로그 호스트로 전송됩니다. 로그는 compliance 리뷰를 위한 감사 증거의 주요 원천입니다.

각 노드의 Tier-2 호스트 방화벽

Tier-1 엣지는 필요하지만 충분하지 않습니다. 내부 서브넷의 모든 다른 worker에서 도달 가능한 worker는 엣지가 얼마나 강하든 클러스터 전체 피벗에서 한 번의 침해만 떨어져 있습니다. Tier 2가 답입니다: 경계 내부의 각 머신은 자체 룰셋으로 자체 호스트 방화벽을 운영하며, 어떤 피어를 수락할지 독립적으로 결정합니다.

Linux 노드에서 호스트 방화벽은 ufw이며, 엣지와 동일한 default-deny 인바운드 자세로 구성되지만 노드 역할이 요구하는 연결만 허용하는 내부 규칙이 있습니다. render worker는 캐시로부터의 SMB, manager로부터의 render-manager job 프로토콜, 모니터링 호스트로부터의 모니터링 텔레메트리, 운영자 bastion 서브넷으로부터의 SSH를 수락합니다. 다른 worker로부터의 연결을 포함한 그 외 모든 것은 거부됩니다. 침해된 worker는 이웃이 연결을 수락하지 않을 것이기 때문에 옆 worker를 프로브할 수 없습니다 — 이 가설에서 Tier-1 엣지는 격파되었고, Tier-2 호스트 방화벽은 격파되지 않은 두 번째 라인입니다.

Windows 노드에서 호스트 방화벽은 동등한 규칙으로 구성된 Windows Defender Firewall with advanced security입니다. 인바운드 RDP는 비상 지원을 위한 좁은 운영자 서브넷으로 제한됩니다; 고객의 원격 데스크톱 프로토콜(Moonlight 또는 동등한 것을 위한 전용 스트리밍 포트)은 고객의 WireGuard 피어 주소에서만 허용됩니다; 그 외 모든 것은 거부됩니다. 사용 사례 — 동일하게 구성된 머신 플릿에 작은 룰셋을 적용 — 에 대해 Windows Defender Firewall은 완전히 적절하며 관리 표면은 Group Policy와 통합됩니다.

그룹 멤버십이 정책 단위입니다. 노드는 역할과 고객별로 그룹화됩니다: customer-A worker가 한 그룹, customer-B worker가 다른 그룹, 운영자 관리 노드가 세 번째, 캐시 및 스토리지가 네 번째입니다. 교차 그룹 연결은 명시적 규칙을 요구하며 기본적으로 거부됩니다. customer-A worker는 customer-B의 캐시를 SMB로 마운트할 수 없고, customer-B의 워크스테이션에 RDP할 수 없으며, customer-B manager에서 job을 가져올 수 없습니다 — 애플리케이션 계층이 이를 시행하기 때문이 아니라 호스트 방화벽이 TCP 핸드셰이크가 완료되도록 허용하지 않기 때문입니다.

호스트 방화벽 규칙은 구성 관리를 통해 관리되어 버전 제어되고, 리뷰 가능하며, 각 노드에서 일관됩니다. 20개 노드 중 하나에서 잘못 구성된 방화벽은 검사로 감지하기 어렵고 드리프트 감지로 잡기 쉽습니다.

WireGuard 종단간 암호화

건물 경계를 넘는 모든 링크는 WireGuard로 암호화됩니다. 아티스트 워크스테이션은 클러스터 게이트웨이로 WireGuard 터널을 합니다. 사이트 간 링크는 게이트웨이 사이에 WireGuard 터널을 합니다. 운영자 SSH 세션은 운영자의 노트북에서 클러스터 bastion으로 WireGuard 터널을 합니다. 한 건물 내부의 내부 클러스터 LAN은 WireGuard 암호화되지 않습니다 — 그 트래픽은 우리가 제어하는 방의 스위치 위에 있습니다 — 하지만 건물을 떠나는 모든 것은 암호화됩니다.

여기서 WireGuard의 매력은 암호학과는 무관한 속성입니다: plaintext fallback이 없습니다. WireGuard는 cipher suite를 협상하지 않고, 런타임에 알고리즘을 선택하지 않으며, "이 피어가 더 오래된 cipher를 요청했으니 응해주자" 코드 경로가 없습니다. 모든 터널은 key exchange를 위해 Curve25519, 데이터 평면을 위해 ChaCha20-Poly1305, 해싱을 위해 BLAKE2s, 메시지 인증을 위해 Poly1305를 사용합니다. cipher 선택은 프로토콜 수준에서 고정됩니다. TLS 스타일 협상 프로토콜에 대한 중요한 공격 클래스 — 다운그레이드, 약한 cipher 선택, 깨진 cipher 레거시 fallback — 는 적용되지 않습니다. 프로토콜에 그 공격들이 노리는 협상 단계가 없기 때문입니다.

피어별 키가 두 번째 속성입니다. 모든 피어는 자체 공개 키를 가지며, 허브는 키와 할당된 AllowedIPs에 기반하여 각 피어를 명시적으로 허용하거나 거부합니다. 공유 비밀이 없습니다. 한 워크스테이션의 개인 키가 유출되면 허브 측 수정은 그 한 피어를 제거하고 그 한 워크스테이션에 대해 새 keypair를 재발급하는 것입니다; 다른 모든 피어는 방해받지 않고 계속 작동합니다. Forward secrecy가 세 번째 속성입니다: WireGuard는 세션 키를 정기적으로 교체하며, 장기 키는 초기 핸드셰이크에만 사용됩니다. 트래픽을 기록하고 나중에 장기 키를 침해한 공격자는 일시적 교환에서 파생된 세션 키가 더 이상 존재하지 않기 때문에 기록된 트래픽을 복호화할 수 없습니다.

커널 수준 구현이 네 번째 속성이며, 아키텍처가 규모에서 운영적으로 견딜 수 있는지 결정합니다. WireGuard는 5.6부터 mainline Linux 커널에 출하되었습니다. 일반적인 Xeon 게이트웨이에서 커널 WireGuard는 한 자릿수 CPU 백분율 비용으로 피어당 기가비트 클래스 처리량을 유지합니다. 라우팅, 방화벽, DNS도 수행하는 게이트웨이의 경우 커널 대 사용자 공간 암호화는 편안한 박스와 포화된 박스의 차이입니다.

최소 권한 접근 패턴

클러스터 내부의 모든 계정은 작업에 필요한 최소 권한을 가지며, 운영자 역할은 단일 역할이 모든 것을 할 수 없도록 분리됩니다. 우리가 운영하는 배포에서 네 가지 계정 클래스가 중요합니다.

고객 원격 데스크톱 계정은 자체 데이터와 DCC 환경에 대한 액세스로 고객의 워크스테이션 표면에 로그인합니다. 기본 운영체제에 대한 셸 액세스는 없습니다. 고객은 원격 데스크톱 프로토콜을 통해 DCC를 조작하고, 렌더를 제출하며, 출력을 다운로드하고, OS 관리 계층을 절대 건드리지 않습니다. 침해된 고객 계정은 OS 수준 자격 증명(license seat), 라이선스 서버 비밀번호, 공유 클러스터 인프라에 도달할 수 없습니다.

운영자 DevOps 계정은 bastion을 통해 Linux 노드에 대한 SSH 액세스를 가집니다. bastion 액세스는 운영자가 먼저 WireGuard를 통해, 그 다음 하드웨어 기반 키로 bastion에, 그 다음 계정별 키로 대상 노드에 인증할 것을 요구합니다. 이중 인증은 bastion에서 강제됩니다. 모든 SSH 세션은 운영자 자신의 계정이 수정하거나 삭제할 수 없는 중앙 감사 로그에 기록됩니다 — 시작 시간, 소스 주소, 대상 노드, 기간, 명령 기록.

모니터링 에이전트는 각 노드에 수집하는 메트릭에 대한 읽기 전용 액세스가 있는 전용 서비스 계정을 가집니다. 임의의 명령을 실행하거나, 애플리케이션 데이터를 읽거나, 자체 로그 파일 외의 영구 위치에 쓸 수 없습니다. 원칙은 관찰이 수정 권한을 요구해서는 안 된다는 것입니다. 스토리지 액세스는 캐시 및 NAS 계층의 SMB ACL에 의해 강제됩니다: 캐시를 마운트하는 customer-A worker는 customer-A의 디렉터리 트리만 봅니다; SMB 서버는 worker에 의존하는 대신 파일 시스템 수준에서 이를 시행합니다.

가장 중요한 역할 분리는 운영자와 고객 사이의 분리입니다. 운영자는 고객이 명시적으로 승인해야 하는 감사된 지원 세션을 통하지 않는 한 고객 워크스테이션에 대한 원격 데스크톱 액세스를 가지지 않습니다. 고객은 운영자 인프라에 대한 OS 수준 액세스를 가지지 않습니다. 이 경계는 — WireGuard 계층(별도 피어 구성), 호스트 방화벽 계층(별도 액세스 규칙), 애플리케이션 계층(별도 인증 영역)에서 시행되며 — 고객이 자신의 워크로드가 자기만의 것이라고 신뢰할 수 있게 하는 경계입니다.

고객 격리: multi-tenant 대 dedicated 클러스터

고객 격리에는 두 가지 실용적 구현이 있습니다. multi-tenant SaaS 인프라는 많은 고객의 job을 공유 플릿에서 실행하며, OS 수준에서 격리합니다 — 별도 사용자 계정, 파일 시스템 경로, 프로세스 그룹, 라이선스 체크아웃 범위. dedicated 클러스터 인프라는 한 고객의 job을 약정 기간 동안 그 한 고객에게 할당된 하드웨어에서 실행하며, 다른 고객의 프로세스, 계정, 데이터가 동일한 머신에 닿지 않습니다.

multi-tenant 격리가 기본이며, 대부분의 workload에서 올바른 선택입니다 — 경제성이 더 좋고, 프로세스 수준 격리는 파일 시스템 ACL 및 위의 호스트 방화벽 규칙과 결합되어 실제로 중요한 교차 고객 액세스 패턴을 방지합니다. dedicated 클러스터 격리는 workload의 가치, 규제 환경, 계약상 의무가 더 강한 경계를 요구할 때 올바른 선택입니다. 동기 부여 위협 모델: OS 수준 격리에 우리가 아직 모르는 취약점이 있다면? 운영자 자신의 내부 접근이 그 자체로 공격 벡터라면? dedicated 하드웨어에서 답은 물리에 의해 제한됩니다 — 고객의 데이터는 고객의 드라이브에 있고, 프로세스는 고객의 CPU 및 GPU에서 실행되고, 고객의 WireGuard 허브는 고객의 피어만 제공하며, 운영자 액세스는 명시적 세션별 승인을 요구하도록 구성될 수 있습니다. 위험 클래스는 "운영자의 multi-tenant 구현을 신뢰"에서 "고객 자신의 하드웨어 경계를 신뢰"로 이동합니다.

customer-owned-credentials 모델 — BYOC, 고객의 DCC 라이선스(license seat) 및 에셋 스토어 자격 증명이 고객에 의해 입력되고 운영자가 절대 보지 않음 — 은 dedicated 클러스터와의 자연스러운 짝입니다; 전체 모델은 customer-owned credentials 작성을 참조하세요. dedicated 하드웨어 + customer-owned credentials는 운영자가 인프라를 운영하지만 인증 자료, 소스 파일, 프로젝트 데이터를 보지 않음을 의미합니다. 운영자의 역할은 "고객 데이터에 액세스하고 사용하지 않기로 선택"하는 대신 "인프라를 건강하게 유지"가 됩니다.

multi-tenant 대신 dedicated를 선택할 때는 workload별로 다릅니다. 세 가지 조건 중 하나가 있을 때 고객이 dedicated를 선택하는 것을 봅니다: 고객의 법무 또는 compliance 팀이 서면으로 설정한 IP 민감도 임계값; 입증 가능한 고객별 데이터 격리를 요구하는 규제 프레임워크; 또는 비용 차이가 격리 상승이 지배할 만큼 작아지는 규모 임계값. 별도 문서가 SaaS 대 dedicated 클러스터 결정 프레임워크를 더 깊이 다룹니다.

Compliance readiness (인증 주장 없이)

먼저 정직한 공개: Super Renders Farm은 현재 SOC 2 인증을 받지 않았으며, 현재 ISO 27001 인증을 받지 않았으며, "우리는 인증서가 있고 증거로 받아들일 수 있습니다"라고 compliance 리뷰어에게 표현할 다른 공식 정보 보안 인증을 보유하지 않습니다. 자체 compliance 프로그램이 벤더가 인증되도록 요구하는 모든 고객은 계약 체결 전에 이를 알아야 합니다.

우리가 제공하는 것은 고객의 compliance 프로그램을 검토하는 감사자가 검사할 수 있는 일련의 기술적 빌딩 블록입니다 — 이 문서에 설명된 아키텍처의 구성 요소를 SOC 2 및 ISO 27001이 기술 계층에서 공유하는 통제 패밀리의 렌즈를 통해 본 것입니다.

At-rest 및 in-transit 암호화. 고객과 클러스터 사이, 건물을 가로지르는 클러스터 노드 사이의 전송 중 데이터는 WireGuard(Curve25519 + ChaCha20-Poly1305)로 암호화됩니다. 캐시 및 스토리지 계층의 at-rest 데이터는 고객이 요청한 곳에서 네이티브 OS encryption-at-rest 기능을 사용합니다; 트레이드오프가 workload별로 다르기 때문에 약정별로 구성 가능합니다. SMB3은 교차 사이트 트래픽에서 in-transit 암호화를 요구하도록 구성되어 있습니다.

감사 추적 능력. SSH 세션 로그는 소스, 대상, 기간, 명령 기록과 함께 운영자 계정이 수정할 수 없는 로그 호스트에 기록됩니다. WireGuard 핸드셰이크 로그는 모든 피어 연결 시도를 기록합니다. render-job 로그는 고객별 제출 시간, 매개변수, 완료 상태, 리소스 사용을 기록합니다. 이러한 로그는 요청 시 고객의 감사자에게 내보낼 수 있습니다.

액세스 통제 및 분리. Tier-1 + Tier-2 방화벽 모델이 분리 통제입니다. 운영자 대 고객 역할 분리가 역할 기반 액세스 통제입니다. dedicated 클러스터 모델의 고객별 방화벽 그룹 멤버십이 고객 격리 통제입니다. 각각은 텍스트로 독립적으로 감사 가능합니다. 데이터 파기는 약정 종료 시 문서화된 절차를 따릅니다 — 파일 수준 삭제, 빈 공간 덮어쓰기, 운영자가 서명한 무엇이 언제 누구에 의해 파기되었는지 기록하는 증명서. 증명서는 고객의 compliance 프로그램이 증거로 보관하는 아티팩트입니다.

네트워크 모니터링. 클러스터는 게이트웨이에서 흐름 로깅과 각 노드에서 호스트 수준 모니터링을 운영합니다. SOC-2 "continuous monitoring" 목표가 요구할 수준의 지속적인 네트워크 침입 탐지는 내부 로드맵에 있지만 현재 배포되지 않았습니다.

중요한 프레이밍: 운영자의 인프라는 고객의 compliance 프로그램의 한 구성 요소이며, 프로그램 자체가 아닙니다. SOC 2 또는 ISO 27001을 추구하는 고객은 전체 통제로 평가되며, 그 중 렌더링 벤더는 한 입력입니다. 우리의 일은 고객의 프로그램이 의존할 수 있는 빌딩 블록을 제공하고, 어떤 통제가 성숙한지, 부분적인지, 아직 범위에 없는지에 대해 정직한 것입니다.

위협 모델

위협 모델을 포함하지 않는 아키텍처 문서는 아키텍처가 모든 것에 대해 방어한다고 암시하는 경향이 있는데, 이는 결코 사실이 아닙니다. 이 아키텍처가 다루는 것의 범위는 제한됩니다; 다루지 않는 실패는 실제이며 명시적으로 명명할 가치가 있습니다.

아키텍처가 무엇에 대해 방어합니다. 외부 스캐닝 및 프로빙: Tier-1 default-deny 자세와 WireGuard의 authenticate-before-accept 동작은 인증되지 않은 스캔에 대한 클러스터의 유일한 응답이 침묵임을 의미합니다 — 핑거프린트할 배너 없음, 공격할 버전 문자열 없음, 무차별 대입할 인증 프롬프트 없음. 단일 노드 침해 후 측면 이동: Tier-2 호스트 방화벽은 침해된 worker가 이웃을 스캔하거나 피벗할 수 없고, 관리 평면이나 운영자 bastion에 도달할 수 없음을 의미합니다. 폭발 반경은 한 노드 + 노드가 합법적으로 액세스한 것입니다 — 의미 있지만 클러스터 전체는 아닙니다. 고객에 대해 사용되는 운영자 자격 증명(license seat) 도난: customer-owned credentials를 가진 dedicated 클러스터에서 운영자는 고객의 라이선스(license seat), 에셋 스토어 자격 증명, 프로젝트 복호화 키를 보유하지 않으므로 운영자의 자격 증명 저장소의 침해는 고객 인증 자료를 노출하지 않습니다. 운영자 직원에 의한 데이터 빼내기, 의미 있지만 절대적이지 않은 방식: dedicated 인프라에 대한 운영자 SSH 액세스는 감사된 bastion 세션, 하드웨어 기반 키, 세션별 권한 부여를 요구하여 악의적 인사이더 시나리오의 비용을 실질적으로 높이지만 0으로 줄이지는 않습니다.

아키텍처가 완전히 방어하지 않는 것. 공급망 공격: 운영체제, DCC, 플러그인, 렌더 엔진, 커널 자체는 운영자가 아닌 다른 당사자가 작성한 소프트웨어입니다; 우리는 완화할 수 있지만(패치 관리, 호스트 강화, 침해된 바이너리가 도달할 수 있는 것을 제한하는 세분화) 제거할 수 없습니다. 공급망 위험은 우리가 해결한 카테고리가 아니라 업계 전체와 공유하는 카테고리입니다. 관리자 액세스를 가진 인사이더 위협: bastion 액세스, 감사 로그 액세스, 그러한 권한을 남용할 지속적인 의도를 가진 운영자는 감사 로그, 이중 인증, 역할 분리, 고객별 dedicated 클러스터 경계로 제약되지만 — 제거되지는 않습니다. 운영자 채용, 배경 조사, 고객이 직접 검토할 수 있는 감사 추적 가시성이 이를 다루는 통제입니다. 고객 자격 증명 위생: 워크스테이션이 침해되어 고객의 WireGuard 개인 키가 유출되면 공격자는 고객이 가진 것과 같은 액세스를 가집니다; 운영자는 비정상 패턴을 감지하고 피어를 비활성화할 수 있지만 유출을 방지할 수 없습니다.

아키텍처는 큰 위험 카테고리를 제거하고 다른 것을 관리 가능한 수준으로 줄입니다; 모든 카테고리를 제거하지 않으며, 그렇지 않다고 시사하는 모든 벤더 표현은 회의적으로 검토되어야 합니다.

자주 묻는 질문

Q: WireGuard는 엔터프라이즈 render farm 사용을 위한 production-grade입니까? A: WireGuard는 5.6 버전(2020년 3월)부터 mainline Linux 커널에 있으며, 주요 인프라 운영자에 의해 production에서 사용되며, 프로토콜이 Tamarin prover로 공식 검증되었습니다. 암호화 기본 요소(Curve25519, ChaCha20-Poly1305, BLAKE2s, Poly1305)는 많은 보안에 민감한 시스템에서 사용되는 현대적이고 peer-reviewed된 선택입니다. render farm 전송 — 장기 실행 터널, 큰 흐름, 작은 운영 표면 — 의 경우, 우리가 프로토콜 수준 사고 없이 수년간 운영해 온 production 선택입니다.

Q: render farm 벤더가 침해되면 내 데이터가 노출됩니까? A: multi-tenant 모델에서 운영자 인프라의 침해는 위의 고객 격리 통제로 범위가 지정된 운영자 시스템이 액세스할 수 있는 데이터를 노출할 수 있습니다. customer-owned credentials를 가진 dedicated 클러스터 모델에서 운영자는 고객의 인증 자료를 보유하지 않으며 고객의 데이터는 고객에게 할당된 하드웨어에 있습니다 — 운영자의 공유 인프라의 침해는 dedicated 클러스터가 별도 경계이기 때문에 dedicated-cluster 고객 데이터를 자동으로 노출하지 않습니다. Dedicated-plus-BYOC는 높은 IP 민감도 workload에 대한 가장 강력한 실용적 답입니다.

Q: compliance 리뷰를 위한 감사 로그를 제공할 수 있습니까? A: 예. SSH 세션 로그, WireGuard 핸드셰이크 로그, render-job 로그, 방화벽 흐름 로그는 약정 계약에 정의된 보존 기간에 따라 고객의 감사자에게 요청 시 내보낼 수 있습니다. 내보내기 형식은 감사자가 필요로 하는 것입니다(가장 일반적으로 CSV 또는 JSON). 로그 호스트 자체에 대한 읽기-쓰기 액세스를 제공하지 않습니다; 내보내기 모델은 감사 추적 무결성을 보존하면서 고객에게 필요한 증거를 제공합니다.

Q: 약정 종료 시 데이터 파기는 어떻게 검증됩니까? A: 파일 수준 삭제 후 관련 스토리지 장치에서 빈 공간 덮어쓰기가 이어지고, 그 다음 범위의 장치, 날짜와 시간, 절차, 관련 인원을 기록한 운영자가 서명한 증명서가 이어집니다. 이를 요구하는 약정의 경우 파기는 고객의 대리인에 의해 입증될 수 있습니다. 증명서는 고객의 compliance 프로그램이 증거로 보관하는 아티팩트입니다.

Q: 귀사의 직원에 의한 인사이더 위협은 어떻게 됩니까? A: 인사이더 위협은 역할 분리, bastion에서의 이중 인증, 운영자 계정이 수정할 수 없는 감사 로그, 고객별 dedicated 클러스터 경계로 완화됩니다. 0으로 줄지 않으며, 우리는 이를 정직하게 말합니다. 요청 시 고객 자신이 감사 로그를 검토하는 것은 인사이더 오용에 대한 가장 효과적인 통제 중 하나입니다 — 운영자 직원이 실제로 한 일에 대해 고객을 루프에 둡니다.

Q: SAML 또는 single sign-on 통합을 지원합니까? A: 고객 측 SSO는 내부 로드맵에 있으며 현재 일반적으로 사용 가능한 기능이 아닙니다. 자체 compliance 이유로 SSO가 필요한 고객은 약정 범위 지정 중에 이를 제기해야 합니다; 일부 통합은 약정별로 수행되었으며, 고객의 신원 공급자가 문서화된 경로를 통해 클러스터의 인증 계층에 브리지될 수 있습니다.

Q: 제 SOC 2 또는 ISO 27001 감사자가 귀사의 아키텍처를 검토할 수 있습니까? A: 예. 위에서 공개한 대로 우리 자신은 인증되지 않았지만, 벤더 검토 설문지와 고객 감사자의 아키텍처 검토 요청에 응답합니다. 이 문서에 설명된 기술적 빌딩 블록은 감사자가 우리의 서면 응답에서 보게 될 것과 같은 것입니다; 구성은 텍스트로 감사 가능합니다. 우리가 제공할 수 없는 것은 자체 인증 문서입니다. 현재 보유하지 않기 때문입니다.

Q: 침입 탐지 커버리지는 어떻습니까? A: Tier-1 엣지의 흐름 로깅과 각 노드의 호스트 수준 모니터링은 오늘 배포되어 있습니다. SOC-2 "continuous monitoring" 목표가 요구할 수준의 지속적인 네트워크 침입 탐지는 내부 로드맵에 있지만 현재 production에 없습니다. 자체 compliance 프로그램이 continuous-IDS 통제를 요구하는 고객은 자체 위험 허용 범위에 대해 격차를 평가해야 합니다.

이 보안 모델이 그 위에 놓이는 네트워크 아키텍처는 cross-country render farm 아키텍처 deep-dive를 참조하세요. dedicated 클러스터와 짝을 이루는 customer-owned-credentials 모델은 BYOC 작성을 참조하세요. 운영 배포는 20노드 dedicated GPU render farm 가이드를 참조하세요. 구매 결정 프레임워크는 SaaS 대 dedicated 클러스터 비교와 dedicated GPU 클러스터 렌탈 랜딩을 참조하세요.