렌더링 워크로드 보안

이 문서에서는 Google Cloud에서 렌더링 파이프라인을 보호하는 방법을 설명합니다. 액세스 제어, 자동 정책 확인, 암호화, 서브네트워크, 방화벽 규칙에 프로젝트 및 ID 및 액세스 관리(IAM)와 같은 Google Cloud 보안 기능을 활용할 수 있습니다. 이 문서에서는 주요 영화 촬영 스튜디오에서 요구하는 보안 프로토콜을 준수하는 방법을 설명합니다.

다음 이미지는 하이브리드 렌더링 아키텍처를 참조로 보여줍니다.

하이브리드 렌더링 아키텍처 다이어그램

더 큰 버전을 보려면 클릭하세요.

프로젝트 및 액세스

프로젝트는 Google Cloud의 핵심적인 조직 구성요소입니다. 프로젝트는 리소스를 특정 부서, 애플리케이션 또는 기능팀과 연결하는 데 사용할 수 있는 추상적 그룹을 제공합니다. Compute Engine 인스턴스 및 Cloud Storage 버킷과 같은 모든 Google Cloud 리소스는 프로젝트에 속합니다. Resource Manager API뿐 아니라 Google Cloud Console을 사용하여 프로젝트를 관리할 수 있습니다. IAM API에는 Resource Manager API를 통해 프로젝트 권한을 관리하는 메서드 세트가 포함되어 있습니다.

프로젝트를 사용하여 리소스 액세스 제어

프로젝트는 네트워크 데이터 및 프로젝트 관리를 위한 격리 경계를 제공합니다. 그러나 조직 또는 조직 내의 다른 프로젝트에서 사용하는 Google Cloud 리소스 간에 상호 연결을 명시적으로 부여할 수 있습니다. 다양한 프로젝트에 대해 viewer, editor, owner와 같은 다양한 역할을 사용자 및 그룹에 부여할 수 있습니다. 역할을 할당하려면 Cloud Console 또는 IAM API의 IAM 및 관리 페이지를 사용하면 됩니다.

또한 특정 프로젝트에 대한 액세스 권한을 가진 사람에게 제어를 위임할 수 있습니다. owner 역할이 부여된 사용자는 사용자, 그룹, 서비스 계정의 액세스 권한을 부여 및 취소할 수 있습니다.

다음 이미지는 Google Cloud 리소스 계층 구조의 예시를 보여줍니다.

프로젝트 구조 다이어그램

액세스 권한 부여

조직에서 Google Workspace를 구현한 경우 조직의 모든 사용자 또는 그룹에 모든 Google Cloud 프로젝트에 대한 액세스 권한을 부여할 수 있습니다. Google Workspace 외부에서 ID를 관리하는 경우에는 Cloud Directory Sync를 사용하여 Microsoft Active Directory 등의 자체 LDAP 서버를 기반으로 사용자 인증 정보를 설정할 수도 있습니다.

조직 내 사용자를 특정 프로젝트나 리소스에 대한 액세스 권한을 가진 Google Group에 추가함으로써 해당 프로젝트나 리소스에 대한 액세스 권한을 제공할 수도 있습니다. 그룹을 사용하면 계약자나 프리랜서 같은 외부 주체에 신속하게 액세스 권한을 제공할 수 있습니다. 그러나 조직은 보안 정책에 따라 이러한 유연성을 원하지 않을 수도 있습니다. Cloud API를 사용하여 정책에 반하는 할당을 감시하고 자동으로 알림을 보내거나 할당을 취소하는 모니터링 기능을 구축할 수 있습니다.

SDK 및 API를 통해 액세스

gcloud 또는 gsutil SDK를 통해 Google Cloud에 액세스하는 경우에는 Google Cloud API에 연결할 때 인증해야 합니다. 로컬 사용자 환경별로 이 작업을 한 번씩만 수행해야 합니다.

애플리케이션 또는 스크립트가 API 클라이언트 라이브러리를 통해 Google Cloud에 액세스한다면 먼저 SDK를 통해 인증해야 합니다. 그러면 API 클라이언트 라이브러리가 생성된 사용자 인증 정보를 선택합니다.

프로젝트 식별

각 프로젝트에는 소문자, 숫자, 대시로 구성되는 범용 고유 프로젝트 ID가 있습니다. 프로젝트를 만들 때 프로젝트 이름을 직접 지정합니다. 프로젝트 ID에는 이 이름에 숫자가 추가되어 전역적으로 고유하게 됩니다. 할당된 프로젝트 ID를 재정의할 수 있지만, 해당 이름은 전역적으로 고유해야 합니다.

자동으로 생성되는 길고 전역적으로 고유한 랜덤 프로젝트 번호도 프로젝트에 할당됩니다. 프로젝트 ID는 길이 6~30자일 수 있으며 프로젝트 이름의 길이는 4~30자로 지정할 수 있습니다.

프로젝트를 만든 후에는 프로젝트 이름을 변경하더라도 프로젝트 ID 및 프로젝트 번호는 그대로 유지됩니다.

관리 편의성을 위해 시간을 투자하여 프로젝트 이름을 계획하는 것이 좋습니다. 적절히 명명된 프로젝트는 올바르게 정렬되고 혼동을 줄일 수 있습니다.

일반적인 프로젝트 명명 규칙은 다음과 같은 패턴을 따를 수 있습니다.

[studio]-[project]-[role (rnd, dev, prod)]

결과 파일 이름은 예를 들면 mystudio-myproject-rnd일 수 있습니다.

보안 검사 자동화

Policy Scanner는 정책이 올바르게 설정될 수 있도록 프로젝트에서 자동화된 보안 검사를 수행하는 프레임워크를 제공합니다. 스캔된 프로젝트 중에서 정상 정책을 벗어나는 것들은 태그되고 문제가 통보됩니다. 필요할 때 Policy Scanner를 실행하거나, 매주 또는 매일 실행되도록 설정할 수 있습니다.

사용자 액세스 제어

프로젝트에서 모두가 실행 중인 모든 인스턴스, 서비스, 저장된 데이터에 무제한 액세스 권한을 가져야 하는 것은 아닙니다. 렌더링 파이프라인에서는 사용자 권한이 일반적으로 온프레미스에서 OS 수준 권한 설정에 의해 처리되며, LDAP 또는 Active Directory와 같은 디렉터리 서비스와 결합됩니다.

일반 렌더링 파이프라인과 달리, 대부분의 아티스트들은 프로젝트 액세스 권한이 전혀 필요하지 않습니다. 애셋 동기화, 렌더링, 데이터 쓰기 및 복사 등 대부분의 클라우드 기반 작업이 서비스 계정으로 작동하는 큐 관리 소프트웨어에 의해 수행되기 때문입니다.

온프레미스와 클라우드 모두에서 최소 권한 원칙을 구현함으로써 프로젝트 영역에만 또는 역할을 기반으로 특정 작업을 수행하는 데 필요한 정보에만 사용자가 액세스하도록 제한할 수 있습니다.

웹 기반 워크로드와 달리, 렌더링 파이프라인은 일반적으로 실행 중인 인스턴스에 대한 직접 액세스 권한이 필요합니다. 예를 들어 특정 인스턴스 유형에서 렌더링 문제를 해결해야 하기 때문입니다. gcloud 명령어 등의 API를 사용하여 인스턴스에 로그인하거나, SSH 키 쌍을 설정했다면 SSH를 사용하여 인스턴스에 직접 연결할 수 있습니다.

렌더를 관리하고 관련 문제를 해결해야 하는 시스템 관리자 및 기타 역할만이 직접 액세스하도록 제한하세요. 직접 액세스는 다음의 경우 필수적입니다.

  • 실패한 작업의 디버깅 및 문제 해결
  • 시작 중이거나 종료 중인 인스턴스에 대한 렌더링 큐 관리자 제어
  • 메모리 또는 CPU 사용량을 추적하는 로깅 메커니즘이나 소프트웨어를 통해 액세스 권한 부여
  • 작업 중에 자동으로 실행되는 작업의 실행

IAM의 사용자 권한과 실행 중인 인스턴스의 OS 수준에서 설정되는 권한을 차별화하는 것이 중요합니다. 이 두 시스템은 서로 결합되어 완전한 사용자 프로필을 제공하지만, 각기 다른 목적에 사용되며 서로 다른 메커니즘으로 생성되고 수정됩니다.

IAM은 개별 인스턴스에 대한 SSH 또는 사용자 액세스 권한을 관리하지 않습니다. 액세스는 IAM과 동기화할 수 있는 OS 수준 사용자 권한에 의해 처리됩니다. IAM 권한을 사용자 또는 서비스 계정에 부여해도 사용자가 인스턴스에 로그인하는 방법이나 로그인 후 갖게 되는 권한은 바뀌지 않습니다. 두 시스템은 상호 보완되도록 설계되었습니다. IAM은 콘솔 또는 API와 같은 Google Cloud 리소스에 대한 액세스 권한을 부여하는 데 사용되며 직접 액세스가 필요한 사용자에게만 프로비저닝됩니다.

커스텀 이미지를 만들 때는 부팅 디스크에서 ssh 및 Google 계정 데몬을 수정함으로써 SSH 액세스 권한을 사용하거나 사용 중지할 수 있습니다. 안내가 필요하면 공개 이미지에 이미 통합된 보안 기능을 조사해보세요.

IAM

Google Cloud 리소스를 관리하려면 IAM을 사용 설정하여 조직, 프로젝트, 리소스 수준에서 권한을 만들고 관리하면 됩니다. IAM은 Google Cloud 서비스의 액세스 제어를 단일 시스템으로 통합하고 일관성 있는 작업 집합을 제공합니다.

IAM 역할 및 그룹

기본 IAM 역할에는 owner, editor, viewer 등 세 가지가 있습니다.

소유자 시설 내에서 또는 프로젝트에서 IT 부서 구성원, 시스템 관리자, 프로덕션 관리자 등 몇몇 신뢰할 수 있는 이들만이 프로젝트 소유자 수준 권한을 가져야 합니다. 프로젝트 소유자는 청구 계정부터 다른 사용자의 액세스 수준까지 모든 것을 변경할 수 있기 때문에 이 역할을 할당할 때는 매우 주의해야 합니다.

소유자를 한 명 이상으로 하여 프로젝트를 만들 수 있습니다. 조직 관리자 역할은 이러한 소유자들을 조직 수준에서 유지관리할 수 있습니다. 이 관리자 역할은 개별 프로젝트에 대한 완전한 소유자 수준 액세스 권한을 부여하지 않고도 프로젝트를 만들고, 프로젝트 청구를 수정하고, 역할을 할당할 수 있습니다.

조직 관리자는 조직 내 모든 프로젝트에 대해 대부분의 알림을 받지만, 기본적으로 몇몇 알림은 프로젝트 소유자에게만 전달됩니다.

편집자 프로젝트 편집자는 프로젝트 데이터 읽기 및 쓰기, 인스턴스 시작 및 종료, 프로젝트 내 모든 리소스에서 프로젝트 메타데이터 읽기 및 쓰기 등 상태를 수정하는 작업을 수행할 수 있습니다.

뷰어 이 읽기 전용 역할은 모든 파이프라인에서 유용한 것은 아닙니다. 하지만 외부 시스템을 모니터링하고 로그인하는 일부 서비스 계정에 이 역할을 할당하는 것은 유용할 수 있습니다. 예를 들어 이미지 또는 동영상을 읽는 일일 검토 시스템이나 Shotgun과 같이 프로젝트 관리 시스템과 통신하는 API에 이 역할을 할당합니다.

사전 정의된 역할 여러 사전 정의된 역할은 사용자 또는 서비스 계정을 특정 작업으로 제한합니다. 예를 들어 이러한 역할은 아티스트가 프로덕션의 청구 데이터에 액세스하지 못하거나 프로덕션 어시스턴트가 실행 중인 인스턴스를 삭제하지 못하도록 하는 데 도움이 될 수 있습니다.

액세스 제어에 리소스 계층 구조 사용

리소스 계층 구조의 여러 수준에서 IAM 정책을 설정할 수 있습니다. 리소스는 상위 리소스의 정책을 상속합니다. 따라서 IAM 정책 계층 구조를 조직 구조에 반영할 수 있습니다. 리소스 계층 구조를 구현하기 위한 몇 가지 권장사항이 있습니다.

사용하지 않는 역할의 사용 중지

기본적으로 여러 역할이 사용 설정되어 있으며 프로젝트 생성자 및 소유자에 의해 할당될 수 있습니다. 혼동을 줄이기 위해 특정 워크플로에 적용되지 않는 역할을 사용 중지할 수 있습니다. 프로젝트별로 사용 중지할 수는 없고 조직의 설정에서 사용 중지해야 합니다.

인스턴스에 대한 SSH 액세스 권한 제어

필요한 사람이 필요한 리소스에 액세스할 수 있도록 하기 위해서는 다음이 필요합니다.

  • Cloud Directory Sync를 사용하는 디렉터리 서비스와 IAM 간의 동기화. 온프레미스와 클라우드에서 사용자 및 권한 목록을 동일하게 유지하는 데 도움이 됩니다.
  • 인스턴스에 대한 SSH 액세스 권한을 위한 사용자 인증 메커니즘(예: PAM Linux 모듈을 LDAP와 함께 사용)

렌더링 워크로드의 경우에는 IT 부서, 시스템 관리자, 렌더 랭글러 등 특정 사용자들에게만 SSH 액세스 권한을 부여하는 것이 좋습니다.

큐 관리자가 클라우드에 제출한 작업은 일반적으로 전용 렌더 사용자 또는 데몬에서 소유합니다. 예를 들어 기본적으로 Qube! 렌더 작업은 사용자 'qubeproxy'로 실행됩니다. 이 Qube 구성을 변경하여 Qube에서 '사용자 모드'라고 칭하는 작업을 시작한 사용자로 실행되도록 하는 것이 좋습니다. 이렇게 하면 작업을 실행한 사용자가 모든 프로세스를 실행합니다. 완료된 렌더는 이 소유권을 유지합니다.

부팅 이미지를 온프레미스 렌더링 작업자와 동일한 프로토콜을 사용하여 수행되는 인증을 통해 온프레미스 렌더링 작업자와 마찬가지로 설정해야 합니다.

서비스 계정

서비스 계정은 Google 서비스 및 리소스에 프로그래매틱 방식으로 액세스하는 데 사용할 수 있는 특수한 Google 계정입니다.

렌더링 파이프라인의 경우 서비스 계정은 인스턴스를 배포하거나 종료하는 방법 그리고 인스턴스에서 작업을 할당하고 실행하는 방법을 제어하는 데 유용합니다. 렌더링 큐 소프트웨어는 서비스 계정 사용자 인증 정보를 사용하여 Google Cloud에서 인스턴스를 실행하므로 새 인스턴스에서 작업을 실행할 수 있습니다.

새 프로젝트를 만들 때 여러 개의 기본 서비스 계정이 만들어집니다. 큐 소프트웨어에서 인스턴스를 실행할 때 사용하는 서비스 계정의 이름은 Compute Engine default service account로만 유지하는 것이 좋습니다. 일부 프로젝트 리소스에 대한 액세스 권한이 삭제될 수 있기 때문에 서비스 계정을 삭제할 때는 주의해야 합니다.

프로그램 중심 이벤트를 실행하기 위해 개별 파이프라인 작업에 별도의 서비스 계정을 둘 수도 있습니다. 이러한 서비스 계정은 필요한 범위에 따라 IAM 역할로 할당됩니다. 예를 들면 다음과 같습니다.

  • 렌더링 큐 관리자에 의한 인스턴스 배포: GCP에서 렌더링 작업을 실행하기 위한 기본 서비스 계정입니다. 이 서비스 계정에는 compute.instanceAdminiam.serviceAccountActor 역할이 할당됩니다.
  • 애셋 관리자: 애셋 게시, 검색, 데이터베이스 관리를 위한 서비스 계정입니다. Cloud Storage를 사용하고 있다면 이 서비스 계정에 storage.admin 역할이 할당됩니다.
  • Logging 에이전트: 특히 Cloud Logging과 같은 프로젝트의 로깅 메커니즘에서 사용하는 서비스 계정입니다. 이 서비스 계정에는 logging.logWriter 역할이 할당됩니다.

액세스 범위

액세스 범위는 인스턴스에 권한을 지정하는 기존의 방법입니다. 이 권한은 인스턴스의 모든 사용자에게 적용됩니다. 액세스 범위는 인스턴스로부터 Google API에 기본 권한을 부여합니다. 이 API를 통해 Compute Engine 및 Cloud Storage 같은 리소스에 액세스합니다.

인스턴스의 모든 사용자에게 기본 권한을 부여하는 대신 IAM 역할을 액세스 범위와 함께 사용하여 단일 사용자나 서비스 계정에 권한을 부여할 수 있습니다.

인스턴스를 만들 때 기본 범위가 적용되지 않도록 --no-scopes 플래그를 지정합니다. --no-scopes를 지정하지 않고 --scope 플래그가 지정된 범위가 없으면 인스턴스에 기본 범위 집합이 적용됩니다.

기본적으로 인스턴스는 범위 집합으로 시작되며 대부분의 인스턴스에서는 IAM 사용자 계정에 대한 액세스, Cloud Storage 버킷에서 읽기, Cloud Logging API를 사용한 로그 작성이 필요합니다.

새 인스턴스를 만들 때 다음과 같은 범위가 인스턴스에 부여됩니다.

범위

API 작업

read only

이 범위는 인스턴스에서 사용자가 Compute Engine API를 사용하여 Cloud Storage 버킷에 쓰는 것을 방지합니다.

logging.write

Cloud Logging API(v2)를 사용하여 인스턴스가 Compute Engine 로그에 쓰기를 허용합니다.

monitoring.write

Cloud Monitoring API(v3)를 사용하여 인스턴스가 측정항목 데이터를 Google Cloud 프로젝트에 게시할 수 있도록 허용합니다.

servicecontrol

Service Control API를 사용하여 인스턴스가 Google Service Control 데이터를 관리할 수 있도록 허용합니다.

service.management.readonly

Cloud Monitoring API(v3)를 사용하여 인스턴스가 측정항목 데이터를 Google Cloud 프로젝트에 게시할 수 있도록 허용합니다.

trace.append

Trace API를 사용하여 인스턴스가 프로젝트 또는 애플리케이션의 지연 시간 데이터를 수집하고 쓸 수 있도록 허용합니다.

예를 들어 기본 범위 집합은 인스턴스가 Cloud Storage 버킷에 쓰는 것을 허용하지 않습니다. 렌더링 파이프라인에서 인스턴스로 Cloud Storage에 완성된 렌더를 쓰기를 요구한다면 렌더링 전용 작업자 인스턴스를 시작하기 전에 storage-rw 범위를 추가합니다. 하지만 추가한 경우에는 사용자가 인스턴스에 있는 데이터를 다른 곳으로 복사할 수 있기 때문에 중요한 데이터에 액세스하는 인스턴스에는 이 범위를 추가하지 마세요.

암호화 키 관리

Cloud Storage

모든 프로젝트 데이터를 비롯하여 Google Cloud에 있는 모든 데이터는 AES128 또는 AES256 암호화를 사용하여 저장 상태에서 암호화됩니다. Cloud StorageCompute Engine 디스크에 자체적인 암호화 키를 제공할 수도 있습니다.

Cloud Storage는 데이터를 디스크에 쓰기 전에 서버 측에서 항상 암호화를 수행합니다. 기본적으로 Cloud Storage는 자체적인 서버 측 키를 사용하여 데이터를 암호화합니다. 데이터는 데이터 암호화 키(DEK)를 사용하여 정밀하게 암호화되며, DEK 자체도 키 암호화 키(KEK)에 의해 암호화됩니다. KEK는 중앙 키 관리 서비스에서 관리되며 Gmail 같은 다른 Google 서비스와 공유됩니다.

데이터 청크를 복호화하기 위해 스토리지 서비스가 Google의 키 관리 서비스를 호출하여 해당 데이터 청크에 대해 래핑 해제된 데이터 암호화 키(DEK)를 조회합니다.

이미지

키 암호화 키를 관리하기 위해 Cloud KMS를 선택할 수도 있습니다.

이 문서에서는 단일 키로 언급된 경우가 많지만, 실제로 데이터는 하나의 키 집합을 사용하여 보호됩니다. 여기에는 암호화를 위한 활성 키 하나와 복호화를 위한 이전 키 집합이 포함되며 그 수는 키 순환 일정에 따라 결정됩니다.

Cloud Storage 및 Compute Engine 영구 디스크에 사용할 자체 암호화 키를 제공할 수도 있지만, 온프레미스 키 관리 서비스를 이미 사용 중인 경우가 아니라면 Google에서 스토리지 데이터의 키를 관리 및 순환하도록 하는 것이 좋습니다. Google에서는 키를 90일마다 순환합니다.

Cloud KMS는 클라우드 서비스에서 직접 사용할 수 있도록 암호화 키를 클라우드에 보관할 수 있는 Google Cloud 서비스입니다. 현재 다른 Google Cloud 서비스에 저장된 데이터를 암호화하기 위한 스토리지 레이어 통합은 없습니다.

모든 프로젝트에서 Cloud KMS를 실행하기 위한 별도의 중앙 집중식 프로젝트를 설정하는 것이 좋습니다.

서비스 계정

서비스 계정을 만들 때 해당 계정 전용의 공개 키/비공개 키 쌍이 자동으로 생성됩니다. 공개 키는 Google에서 관리하지만 비공개 키는 사용자가 관리합니다. 이 비공개 키는 Google Cloud에서 작업을 실행할 때 서비스 계정을 인증하는 데 필요합니다.

네트워크 보안

모든 컴퓨팅 인스턴스는 Cloud Virtual Network의 구성원으로 생성됩니다. 기본적으로 모든 네트워크는 지역 하위 네트워크가 자동으로 생성되는 자동 서브넷 네트워크입니다. 각 네트워크에는 단일 프로젝트만 있을 수 있습니다. 같은 네트워크에 여러 프로젝트가 존재할 수 없습니다. 프로젝트 소유자, 조직 관리자, 컴퓨팅 네트워크 관리자라는 특정한 역할을 가진 사용자만 네트워크 속성을 변경할 수 있습니다.

네트워크 및 하위 네트워크

별도의 네트워크에서 리소스를 격리하여 보안을 한층 더 강화할 수 있습니다. 예를 들어 기밀 콘텐츠가 많은 일련의 촬영본은 나머지 프로젝트 데이터와 격리된 별도의 네트워크 내에서만 렌더링될 수 있습니다. 개별 프로젝트가 데이터를 분리하는 데 더 효과적인 방법일 수 있습니다.

새 프로젝트를 만들면 자동 서브넷 기능 때문에 Compute Engine 리전마다 하나씩 여러 개의 서브네트워크가 만들어지기 때문입니다. 특정 리전에서 새 인스턴스를 시작할 때는 해당 지역의 서브네트워크에 배치되고 해당 서브네트워크 내에서 내부 IP가 할당됩니다.

방화벽 규칙

각 네트워크에는 인스턴스로 수신되는 모든 트래픽을 차단하는 방화벽이 있습니다. 수신 트래픽을 허용하려면 '허용' 방화벽 규칙을 만들어야 합니다.

각 프로젝트에서 default 라벨이 지정된 네트워크에는 아래와 같은 기본 방화벽 규칙이 있습니다. 수동으로 생성된 모든 유형의 네트워크에는 방화벽 규칙이 없습니다. 기본 네트워크를 제외한 모든 네트워크에 대해 필요한 방화벽 규칙을 만들어야 합니다.

렌더링 파이프라인에 아래의 모든 기본 규칙이 필요한 것은 아닙니다.

규칙

참고

추천

default-allow-internal

인스턴스 간 통신을 허용하는 데 필수적입니다. 큐 관리자가 온프레미스에 있는 경우에는 아마도 인스턴스가 서로 간에 통신할 필요가 없을 것입니다.

인스턴스가 다른 인스턴스와 통신할 필요가 없는 경우에는 이 규칙을 삭제하세요.

default-allow-ssh

포트 22를 통한 SSH 액세스를 허용하는 데 사용됩니다.

이 규칙을 삭제하고, VPN이나 알려진 IP를 통해서만 SSH를 허용하는 비슷한 규칙을 만드세요.

default-allow-rdp

포트 3389를 통해 원격 데스크톱 프로토콜(RDP)로 인스턴스에 액세스하려는 경우에만 필요합니다. 대부분의 경우 SSH 액세스만으로 충분하므로 이 규칙을 삭제할 수 있습니다.

Windows를 실행하는 머신을 사용 중인 경우를 제외하고는 이 규칙을 삭제하세요.

default-allow-icmp

네트워크에서 오류 또는 운영 정보의 통신을 허용합니다. 이 규칙은 어느 IP에서든지 액세스를 허용합니다.

이 규칙을 삭제하고, 알려진 IP 주소에서 ICMP를 허용하는 비슷한 규칙을 만드세요.

방화벽 규칙은 기본적으로 전체 네트워크에 적용됩니다. 서브네트워크가 트래픽을 교환하길 원한다면 두 방향 모두에서 allow 권한을 구성해야 합니다.

인스턴스 태그를 파이프라인에 통합함으로써 방화벽 규칙을 통해 특정 인스턴스 유형의 액세스를 허용할 수 있습니다. 예를 들어 모든 렌더 인스턴스에 태그를 지정함으로써 특정 역할이 문제를 해결하도록 SSH 액세스를 허용할 수 있습니다. 이 태그에 없는 인스턴스에서는 라이선스 서버 등의 SSH 액세스가 자동으로 제한됩니다.

방화벽 규칙을 만들 때 sourceRangessourceTags 중에 아무것도 지정하지 않으면 기본 sourceRange0.0.0.0/0이 되므로, 규칙이 네트워크 안팎의 모든 수신 트래픽에 적용됩니다.

TCP 또는 UDP 방화벽 규칙을 만들 때 포트를 지정하지 않으면 모든 포트에서 연결이 허용됩니다.

네트워크 경로

모든 네트워크에는 공개 인터넷과 네트워크의 IP 범위로 연결되는 자동 생성 경로가 있습니다. 아웃바운드 트래픽은 기본적으로 차단되지 않습니다. 외부 IP 주소와 기본 인터넷 게이트웨이 경로가 있는 인스턴스만 네트워크 외부로 패킷을 보낼 수 있습니다.

Google Cloud APIs(예: gcloud, gsutil)는 공개 IP를 통해서만 액세스할 수 있으므로 네트워킹 > 경로에서 기본 인터넷 게이트웨이 경로를 유지해야 합니다.

외부 IP 주소 사용 중지

보안상 인스턴스에 외부 IP 주소가 없는 것이 좋습니다. 기본적으로 외부 IP 주소는 시작할 때 모든 인스턴스에 할당됩니다. 이를 방지하려면 인스턴스를 --no-address 플래그로 시작하면 됩니다.

렌더링 큐 관리자가 외부 IP 주소 없이 인스턴스를 제어하기 위해서는 Cloud VPN을 구현해야 합니다. Border Gateway Protocol(BGP)을 사용하여 온프레미스 네트워크와 Google Cloud 네트워크 사이에 비공개 IP 범위를 브로드캐스트하는 Cloud Router를 추가하지 않는 한 VPN Gateway가 네트워크에서 외부 IP 주소를 사용하는 유일한 리소스입니다.

디스크 이미지

VFX 파이프라인에서는 이미지 관리를 위해 조직 수준에서 별도의 프로젝트를 사용하는 것이 좋습니다. 이 접근 방식은 모든 프로젝트에서 현재 사용되고 있을 수 있는 시설 전체의 기본 이미지 템플릿이 수정되는 것을 방지합니다. 또한 부팅 이미지를 중앙 위치에 정리해 놓음으로써 적절한 역할이 할당될 경우 다른 모든 프로젝트가 액세스할 수 있도록 합니다.

IAM 역할을 사용하여 프로젝트 간에 이미지를 공유할 수 있습니다. 자세한 내용은 프로젝트 간 이미지 공유를 참조하세요.

공개 이미지

Compute Engine은 Linux 및 Windows 운영체제와 호환되도록 다양한 사전 구성 공개 이미지를 제공합니다. 각 OS 이미지는 Cloud SDK와 같은 특정 패키지를 포함하거나 SSH와 같은 서비스를 사용하도록 구성됩니다.

이 이미지는 사용자 계정을 설정 및 관리하고 SSH 키 기반 인증을 사용하는 패키지 모음도 포함합니다.

커스텀 이미지

기존 이미지를 바탕으로 커스텀 디스크 이미지를 직접 만들 수 있습니다. 이미지는 보안 권장사항을 준수해야 합니다.

공개 이미지에서 기본적으로 제공되는 기능에 액세스하기 위해 Compute Engine용 Linux 게스트 환경을 설치하는 것이 좋습니다. 게스트 환경을 설치하면 메타데이터 액세스, 시스템 구성, Google Cloud에서 사용하기 위한 OS 최적화 등 커스텀 이미지에서와 동일한 보안 제어로 작업을 수행할 수 있습니다.

연결

시설과 Google을 연결하는 방법은 여러 가지가 있습니다. 모든 경우에 가상 사설망(VPN)을 구현해야 합니다. 몇몇 방법의 경우, 데이터의 보안 전송을 보장하기 위해 아래에 설명된 추가적인 구성이 필요합니다.

데이터에 적용되는 보안 방법은 다음과 같습니다.

  • Google의 인증 기관에서 생성한 2048비트 인증서로 TLS를 사용하여 Google로 연결되는 데이터 링크를 암호화합니다.
  • 사설 네트워크에서 데이터 센터 사이를 이동하는 데이터를 암호화합니다.
  • 모든 RSA 인증서를 2048비트 키로 업그레이드하여 Google Cloud 및 기타 모든 Google 서비스의 전송 중인 데이터 암호화를 강화합니다.
  • 키 유출 또는 암호 해독으로 인한 침투의 영향을 최소화하는 데 도움이 되는 PFS(Perfect Forward Secrecy)를 사용합니다.

인터넷을 통해 연결

간단히 인터넷을 통해 Google Cloud 서비스에 액세스하여 Google 네트워크에 연결하고 엔드 투 엔드 보안 모델을 활용할 수 있습니다. VPN 터널을 통과할 때 데이터는 인증되고 암호화된 프로토콜에 의해 보호됩니다.

다이렉트 피어링

Google은 전 세계 100개가 넘는 접속 지점 시설에서 Google Cloud 고객이 직접 연결할 수 있는 에지 네트워킹 인프라를 호스팅합니다. 공개 ASN 및 공개 라우팅이 가능한 IP 프리픽스가 있는 모든 Google Cloud 고객은 Google과 피어링할 수 있습니다. 이 옵션은 공개 인터넷과 동일한 상호 연결 모델을 활용합니다.

Cloud Interconnect

공개 ASN이 없거나 서비스 제공업체를 통해 Google에 연결하기를 원하는 고객은 Cloud Interconnect 서비스를 이용할 수 있습니다. Cloud Interconnect는 Google 에지에 대한 엔터프라이즈급 연결을 원하는 고객을 위한 것입니다. Cloud Interconnect 파트너 서비스 제공업체가 다음 두 가지 방법 중 하나로 엔터프라이즈급 연결을 제공할 수 있게 도와줍니다.

  • 높은 성능과 짧은 지연 시간을 보장하기 위해 공동으로 용량을 관리하는 기존 피어링 연결을 통해
  • Google Cloud 고객 트래픽만 전송하는 전용 상호 연결을 통해(단, Google은 이 링크를 통해 모든 서비스의 경로를 공지함)

Cloud VPN

온프레미스 렌더링 파이프라인이 전송 중인 데이터를 항상 암호화는 것은 아닙니다. 하지만 하이브리드 클라우드 렌더링 파이프라인의 경우에는 전송 중 데이터를 모두 암호화하는 것이 좋습니다.

어떤 방식으로 Google에 연결하든 항상 VPN으로 연결을 보호해야 합니다. Cloud VPN은 피어 VPN 게이트웨이를 IPsec VPN 연결을 통해 Google Cloud 네트워크에 연결합니다. 한쪽 VPN 게이트웨이에서 두 네트워크 사이의 트래픽 이동을 암호화하면 이후 다른 쪽 VPN 게이트웨이에서 이를 복호화합니다. 이렇게 하면 인터넷을 통해 이동하는 데이터를 보호하는 데 도움이 되며, 렌더링 파이프라인에 데이터 암호화를 포함할 필요가 없습니다.

시설에 여러 개의 위치나 네트워크가 있는 경우에는 Cloud Router를 사용하여 해당 위치와 Cloud VPN 간에 경로를 동기화할 수 있습니다.

고객 제공 VPN

Google Cloud 내에서 자체 VPN 게이트웨이를 설정할 수 있지만 Cloud VPN을 사용하여 Google Cloud와의 유연성과 통합성을 높이는 것이 좋습니다.

파일 시스템

데이터를 관리하는 데 사용할 수 있는 다수의 파일 서버가 있습니다. 파이프라인 방법론에 따라 여러 개를 구현해야 할 수도 있습니다.

객체 기반

Cloud Storage는 렌더링 파이프라인 전반에서 생성되거나 소비되는 모든 데이터에 적합한 통합 객체 저장소입니다. Cloud Storage는 Google Cloud에 속하므로 액세스 제어, IAM, 암호화와 같은 Google Cloud의 보안 기능을 활용할 수 있습니다.

버킷을 생성하는 위치가 리전이라면 버킷 내 데이터는 프로젝트 구성원이 전 세계에서 액세스할 수 있지만 데이터는 특정 데이터 센터에 저장됩니다. 성능 측면에서는 처리량을 높이고 지연 시간을 단축하기 위해 같은 리전에서 저장하고 컴퓨팅하는 것이 가장 좋습니다.

Cloud Storage에 있는 데이터는 전 세계에서 액세스할 수 있기 때문에 복제 없이도 세계의 다른 곳에 있는 다른 시설들과 데이터를 공유할 수 있습니다. 이로 인해 추가적인 송신 비용이 발생할 수 있습니다. 전 세계에서 이 데이터에 액세스할 수 있으므로 데이터가 렌더링 파이프라인에서 유출되지 않도록 VM 범위, 사용자, 액세스 키를 적절히 관리하는 것이 중요합니다.

Cloud Storage의 객체 기반 아키텍처와 연결하기 위해 애셋 관리 파이프라인을 조정해야 할 수도 있습니다.

POSIX 규격

실제 프로덕션 데이터는 종종 POSIX 규격 파일 서버에 저장됩니다. 이 파일 서버는 수정 시간 같은 파일 메타데이터에 액세스해야 하거나 장면 애셋을 위해 파일 경로를 사용하는 렌더링 파이프라인에 적합할 수 있습니다.

시설의 필요와 워크로드에 따라 NFS 파일 시스템을 구현할 때 몇 가지를 선택할 수 있습니다.

단일 노드 파일 서버

POSIX 규격 NFS 서버는 클릭하여 배포 솔루션으로 사용할 수 있습니다. 여러 개의 단일 노드 파일 서버를 실행하고 인스턴스에 마운트할 수 있습니다. 즉, 온프레미스 파일 시스템과 동일한 방식으로 운영체제 사용자 및 그룹 수준에서 액세스를 제한함으로써 파이프라인의 각 부분에서 저장소를 격리할 수 있습니다.

렌더 인스턴스에 읽기 전용으로 마운트함으로써 단일 노드 파일 서버의 데이터를 보호할 수도 있습니다. 소프트웨어, 파이프라인 도구, 애셋 라이브러리는 렌더 인스턴스에서 절대로 수정되어서는 안 됩니다. 따라서 읽기 전용으로 마운트하는 것이 이러한 제한을 적용하는 가장 쉬운 방법입니다.

프로젝트를 더 안전하게 보호하기 위해 네트워크당 하나의 단일 노드 파일러를 배포할 수도 있습니다. 인스턴스는 같은 네트워크에만 파일 서버를 마운트할 수 있기 때문입니다.

프로덕션에 최소한의 영향을 주면서 이전 버전으로 빠르게 롤백하기 위해 소프트웨어 또는 파이프라인 디스크의 스냅샷을 생성할 수도 있습니다.

기타 파일 시스템

클러스터링 및 캐싱 파일 시스템과 같은 다른 타사 파일 시스템을 Google Cloud에서 사용할 수 있습니다. 타사 캐싱 파일 시스템의 보안에 대해서는 개별 공급업체의 규정 준수 문서를 참조하세요.

스토리지 보안

기본적으로 Cloud Storage에는 엄격한 키 액세스 제어와 감사를 포함하여 Google이 자체적으로 데이터를 암호화하는 데 사용하는 강화된 키 관리 시스템이 동일하게 적용되어 있어 사용자 대신 서버 측 암호화 키를 관리합니다. Cloud Storage는 미사용 사용자 콘텐츠를 암호화하며, 각 암호화 키 자체는 정기적으로 회전되는 루트 키 집합을 통해 암호화됩니다.

모든 스토리지 클래스는 데이터를 보호하기 위해 동일 OAuth 및 세부 액세스 제어를 지원합니다.

IAM을 사용하여 Cloud Storage 버킷이나 프로젝트 내의 데이터에 액세스할 수 있는 사용자를 제한하는 것이 좋습니다. 적은 수의 객체만 관리해야 하는 경우에는 액세스 제어 목록을 활용할 수도 있습니다.

전송 옵션

전송 중인 데이터의 보안은 온프레미스 저장소와 클라우드를 오가는 데이터의 안전을 의미합니다. 온프레미스와 클라우드 간 이동을 관리하는 데 도움을 주는 다양한 파이프라인 방법론이 있으며, 각각의 설계와 구현 방법에 대해서는 이 문서에서 다루지 않습니다. 아래에 설명된 모든 전송 방법(타사 전송 방법 제외)은 인증 및 승인을 위한 Google의 전체 보안 제품군 내에서 실행됩니다.

명령줄

Cloud Storage에서 데이터를 주고받을 때 gsutil 명령어를 사용하여 크기가 10TB 미만인 데이터를 복사, 이동, 동기화하는 것이 좋습니다. gsutil 명령어는 Google Cloud와 동일한 보안 기능 및 인증을 사용하고, IAM 역할을 준수하고, 전송 계층 암호화(HTTPS)를 사용하여 모든 작업을 수행합니다. gsutil동시 업로드도 지원합니다.

단일 노드 파일 서버와 Persistent Disk 같은 POSIX 규격 파일 시스템에서 데이터를 주고받을 때는 VPN 연결을 통해 scp 또는 rsync를 사용하는 것이 좋습니다.

UDP

Aspera, Tervela Cloud FastPath, BitSpeed, FDT 등의 타사 UDP 기반 데이터 전송 프로토콜을 사용하여 데이터를 Cloud Storage에 직접 업로드하려는 경우에는 타사 문서를 참조하여 보안 모델과 권장사항에 대해 알아보세요. 이러한 타사 서비스는 Google에서 관리하지 않습니다.

Cloud Logging

Cloud Logging을 사용하면 프로젝트 또는 조직 내의 다양한 활동을 모니터링하고 로깅할 수 있습니다. Cloud Logging은 원래 웹 애플리케이션 및 서비스용으로 작성되었지만, 렌더링 파이프라인의 로깅 서버로 사용될 수 있으므로 명령줄 렌더에서 생성된 대규모 데이터의 컬렉션 지점을 제공합니다.

새 Google Cloud 프로젝트에서는 Cloud Logging API가 기본적으로 사용 설정되지 않습니다. Cloud Logging API를 사용 설정하면 Cloud Logging이 외부 애플리케이션의 로깅 서버 역할을 할 수 있습니다.

감사 로깅은 콘솔 또는 API를 통해 서비스 또는 프로젝트의 구성 또는 메타데이터를 수정하여 관리 활동을 추적하는 데 도움이 됩니다. 감사 로그는 수정하거나 삭제할 수 없습니다.

모든 로그가 일정 기간 동안 보관된 후에 삭제됩니다. Cloud Logging 할당량 정책은 로그 항목의 보관 기간을 설명합니다. 보관 기간보다 더 오래 로그를 보관하기 위해 Cloud Storage 버킷, BigQuery 데이터 세트, Cloud Pub/Sub 주제 또는 이 세 가지의 조합으로 로그를 내보낼 수 있습니다.

로그는 Logging 에이전트(기본적으로 설치되지 않음)를 통해 개별 인스턴스로부터 수집됩니다. 여기에서 설치 지침을 확인할 수 있습니다.

기타 고려사항

이 섹션에서는 Google 제품 라인에는 포함되지 않지만 일반적으로 하이브리드 렌더링 파이프라인에 포함되는 주제에 대해 설명합니다.

큐 관리

많은 촬영 스튜디오에서 큐 관리자를 사용하여 배포, 추적, 온프레미스 렌더 팜에 배포되는 작업을 관리합니다. 때로는 동일한 큐 관리자를 사용하여 작업을 Google Cloud에 배포할 수 있습니다. 구체적인 방법은 관련 소프트웨어에 따라 다를 수 있습니다.

일부 큐 관리자는 서버와 클라이언트가 모두 Google Cloud에 연결할 수 있도록 소프트웨어 플러그인을 제공합니다. 타사 문서를 참조하여 보안 방침을 검토하세요.

큐 관리자가 Google Cloud로 보낸 지침은 gcloud 명령어를 사용하여 실행해야 합니다. ssh,를 사용하여 명령어를 보내야 한다면 통신용 SSH 키를 생성해야 합니다. 이를 방지하려면 온프레미스가 아닌 Google Cloud에서 큐 관리 서버를 실행하는 것이 좋습니다.

인스턴스 생성 및 종료 자동화

때로는 작업 시작될 때 인스턴스를 생성하는 것과 작업이 성공적으로 완료될 때 인스턴스를 종료하는 것을 자동화하고자 할 수도 있습니다. 비용 및 보안 문제로 인해 작업을 실행 중이 아닐 때는 인스턴스를 계속 실행하는 것을 피해야 합니다.

커스텀 소프트웨어

렌더링 파이프라인에 타사 소프트웨어와 커스텀 소프트웨어가 모두 포함된 경우가 흔히 있습니다. 커스텀 소프트웨어는 간단한 스크립트부터 여러 개의 종속 항목이 있는 컴파일된 복잡한 바이너리까지 모든 것을 포함할 수 있습니다.

스크립트 또는 프로그램 내에서 Google Cloud 인스턴스를 조작하려면 제공되는 클라이언트 라이브러리를 사용하세요. 버전마다 OAuth 2.0 승인을 위한 메서드를 제공합니다.

라이선스

온프레미스 라이선스 서버

자체적인 온프레미스 라이선스 서버를 사용하면 VPN을 통해 실행할 때 더 안전한 환경을 제공할 수 있습니다. 그래도 여전히 보안 수준은 사용되는 라이선스 기술의 제한을 받습니다.

클라우드 라이선스 서버

Google Cloud에서 자체 라이선스 서버를 실행하는 경우 추가 제어 및 모니터링을 위해 별도의 네트워크에서 실행하는 것이 좋습니다.

다음 단계