렌더링 작업 부하 보안

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

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

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

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

프로젝트 및 액세스

프로젝트는 GCP의 핵심 조직 구성요소입니다. 프로젝트는 리소스를 특정 부서 또는 기능 팀과 연결하는 데 사용할 수 있는 추상적 그룹을 제공합니다. Compute Engine 인스턴스와 Cloud Storage 버킷 등 모든 GCP 리소스가 프로젝트에 속합니다. Google Cloud Platform 콘솔 및 Resource Manager API를 사용하여 프로젝트를 관리할 수 있습니다. Cloud Identity and Access(IAM) API에는 Resource Manager API를 통해 프로젝트 권한을 관리하기 위한 일련의 메소드가 포함되어 있습니다.

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

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

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

다음 이미지는 GCP 리소스 계층 구조의 예시입니다.

프로젝트 구조 다이어그램

액세스 권한 부여

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

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

SDK 및 API를 통해 액세스

gcloud 또는 gsutil SDK를 통해 GCP에 액세스하는 경우에는 Google Cloud API에 연결할 때 인증해야 합니다. 한 로컬 사용자 환경에서 한 번만 인증하면 됩니다.

애플리케이션 또는 스크립트가 API 클라이언트 라이브러리를 통해 GCP에 액세스하는 경우에는 먼저 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 사용량을 추적하는 로깅 메커니즘이나 소프트웨어를 통해 액세스 권한 부여
  • 작업 중에 자동으로 실행되는 작업의 실행

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

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

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

ID 및 액세스 관리(IAM)

GCP 리소스를 관리하기 위해 Cloud IAM에서는 조직, 프로젝트, 리소스 수준에서 권한을 만들고 관리할 수 있습니다. Cloud IAM은 GCP 서비스의 액세스 제어를 단일 시스템으로 통합하고 일관된 작업 집합을 제공합니다.

IAM 역할 및 그룹

owner, editor, viewer의 세 가지 기본 Cloud IAM 역할이 있습니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

서비스 계정

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

렌더링 파이프라인의 경우, 서비스 계정은 인스턴스를 배포하거나 종료하는 방법 그리고 인스턴스에서 작업을 할당하고 실행하는 방법을 제어하는 데 유용합니다. 렌더 대기열 소프트웨어는 서비스 계정 자격 증명을 사용하여 GCP에서 인스턴스를 시작함으로써 새로운 인스턴스에서 작업을 시작할 수 있게 해줍니다.

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

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

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

액세스 범위

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

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

인스턴스를 만들 때 기본 범위가 적용되지 않도록 --no-scopes 플래그를 지정하세요. --no-scopes를 지정하지 않은 상태에서 --scope 플래그로 범위를 지정하지 않으면 인스턴스에 기본 범위 집합이 적용됩니다.

기본적으로 인스턴스는 범위 집합과 함께 시작됩니다. 그 중 대부분은 Cloud IAM 사용자 계정에 액세스하고, Cloud Storage 버킷으로부터 읽고, Stackdriver API를 사용하여 로그를 쓰는 데 필요합니다.

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

범위

API 작업

read only

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

logging.write

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

monitoring.write

Stackdriver Monitoring API(v3)를 사용하여 인스턴스가 GCP 프로젝트에 측정항목 데이터를 게시하는 것을 허용합니다.

servicecontrol

Service Control API를 사용하여 인스턴스가 Google Service Control 데이터를 관리하는 것을 허용합니다.

service.management.readonly

Stackdriver Monitoring API(v3)를 사용하여 인스턴스가 GCP 프로젝트에 측정항목 데이터를 게시하는 것을 허용합니다.

trace.append

Stackdriver Trace API를 사용하여 인스턴스가 프로젝트 또는 애플리케이션의 기존 데이터를 수집하고 쓰는 것을 허용합니다.

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

암호화 키 관리

Cloud Storage

모든 프로젝트 데이터(그리고 GCP에 있는 모든 데이터)는 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는 클라우드에서 암호화 키를 중앙 집중식으로 관리하여 클라우드 서비스가 직접 사용할 수 있도록 해주는 GCP 서비스입니다. 현재는 다른 GCP 서비스에 저장된 데이터를 암호화하기 위한 저장소-계층 통합이 없습니다.

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

서비스 계정

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

네트워크 보안

모든 컴퓨팅 인스턴스는 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 권한을 두 방향 모두로 구성해야 합니다. 방화벽 규칙은 allow 전용 규칙입니다. deny 규칙은 만들 수 없습니다.

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

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

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

네트워크 경로

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

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

외부 IP 주소 사용 중지

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

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

디스크 이미지

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

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

공개 이미지

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

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

커스텀 이미지

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

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

연결

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

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

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

인터넷을 통해 연결

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

직접 피어링

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

Cloud Interconnect

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

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

Cloud VPN

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

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

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

고객 제공 VPN

GCP 내에서 VPN 게이트웨이를 직접 설정할 수 있지만, 유연성을 높이고 GCP와 더 긴밀히 통합하기 위해서는 Cloud VPN을 사용하는 것이 좋습니다.

파일 시스템

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

객체 기반

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

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

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

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

POSIX 규격

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

시설의 필요와 작업 부하에 따라 NFS 파일 시스템을 구현할 때 몇 가지를 선택할 수 있습니다.

단일 노드 파일 서버

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

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

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

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

기타 파일 시스템

클러스터형 파일 시스템, 캐싱 파일 시스템 등의 다른 타사 파일 시스템을 GCP와 함께 사용할 수 있습니다. 타사 캐싱 파일 시스템의 보안에 대해서는 개별 공급업체의 규정 준수 문서를 참조하세요.

저장소 보안

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

모든 저장소 등급은 데이터를 보호하기 위해 동일 OAuth 및 세부 액세스 제어를 지원합니다.

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

전송 옵션

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

명령줄

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

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

UDP

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

Stackdriver로 로깅

Google Stackdriver를 사용하여 프로젝트나 조직 내에서 다양한 활동을 모니터링하고 로깅할 수 있습니다. Stackdriver는 원래 웹 애플리케이션 및 서비스용으로 만들어졌지만 렌더링 파이프라인에서 로깅 서버로 사용되어 명령줄 렌더에 의해 생성되는 대규모 데이터의 수집 지점 역할을 할 수도 있습니다.

Stackdriver API는 기본적으로 새 GCP 프로젝트에서 사용 설정되지 않습니다. 현재 Debugging, Logging, Monitoring, Trace의 네 가지 API가 있습니다. 전부가 워크플로에 적용되는 것은 아니지만, Stackdriver가 외부 애플리케이션의 로깅 서버 역할을 하도록 적어도 Stackdriver Logging은 사용 설정하는 것이 좋습니다.

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

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

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

기타 고려사항

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

대기열 관리

많은 스튜디오에서 대기열 관리자를 사용하여 배포, 추적 그리고 온프레미스 렌더링 작업장에 배포되는 작업을 관리합니다. 때로는 같은 대기열 관리자를 사용하여 작업을 GCP에 배포할 수 있습니다. 구체적인 방법은 관련 소프트웨어마다 다를 수 있습니다.

일부 대기열 관리자는 서버와 클라이언트 모두 GCP에 연결할 수 있도록 허용하는 소프트웨어 플러그인을 제공합니다. 타사 문서에서 해당 보안 방침을 검토하세요.

대기열 관리자가 GCP에 보내는 지침은 gcloud 명령어를 통해 실행되어야 합니다. ssh,를 사용하여 명령어를 보내야 하는 경우에는 통신을 위한 SSH 키를 생성해야 합니다. 이러한 번거로움을 피하기 위해 온프레미스 대신 GCP에서 대기열 관리 서버를 실행하는 것을 고려해 볼 수도 있습니다.

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

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

커스텀 소프트웨어

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

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

라이선스

온프레미스 라이선스 서버

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

클라우드 라이선스 서버

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

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...