レンダリング ワークロードのセキュリティ保護

この記事では、Google Cloud Platform(GCP)でレンダリング パイプラインをセキュリティ保護するための手順を説明します。アクセス制御用のプロジェクトや Cloud IAM、自動ポリシー チェック、暗号化、サブネットワーク、ファイアウォール ルールなどの GCP セキュリティ機能を利用できます。この記事では、大きな映画撮影スタジオで要求されるセキュリティ プロトコルを遵守する方法について説明します。

次の図は、参照用のハイブリッド レンダリング アーキテクチャです。

ハイブリッド レンダリング アーキテクチャの図

クリックすると拡大します。

プロジェクトとアクセス

プロジェクトは GCP の中核的な構成要素です。プロジェクトでは、リソースを特定の部門、アプリケーション、機能チームと関連付けるために使用できる抽象的なグループ化が提供されます。Compute Engine インスタンスや Cloud Storage バケットなど、すべての GCP リソースはプロジェクトに属します。Google Cloud Platform Console と Resource Manager API を使用してプロジェクトを管理できます。Cloud Identity and Access(IAM)API には、Resource Manager API を使用してプロジェクトの権限を管理するための一連のメソッドが含まれています。

プロジェクトを使用したリソースへのアクセスの制御

プロジェクトは、ネットワーク データとプロジェクト管理の両方に対して分離境界を提供します。ただし、組織または組織内の他のプロジェクトによって使用される GCP リソース間の相互接続を、明示的に許可できます。ユーザーおよびグループに対し、プロジェクトごとに viewereditorowner などの異なる役割を付与できます。役割を割り当てるには、GCP Console の [IAM と管理] ページまたは Cloud IAM API を使用できます。

さらに、特定のプロジェクトにアクセスできる人物を決める権限を委任することも可能です。owner の役割を与えられたユーザーは、ユーザー、グループ、サービス アカウントのアクセス権限を付与したり、取り消したりできます。

次の図は、GCP リソース階層の例を示します。

プロジェクト構造図

アクセス権の付与

組織が G Suite を導入している場合は、組織内の任意のユーザーまたはグループに対して、任意の GCP プロジェクトへのアクセス権を付与できます。G Suite を使わずに ID を管理している場合でも、Google Cloud Directory Sync を使用して、Microsoft Active Directory などの独自の LDAP サーバーを基にしてユーザーの認証情報を設定できます。

また、プロジェクトやリソースへのアクセス権を持つ Google グループに組織内のユーザーを追加することにより、そのプロジェクトやリソースへのアクセス権をユーザーに付与できます。グループを使用すると、請負業者やフリーランサーなどの外部の関係者にすばやくアクセス権を付与できます。ただし、セキュリティ ポリシーによっては、このレベルの柔軟性が組織で許可されない場合もあります。Cloud API を使用することで、ポリシー外の割り当てをモニタリングし、アラートを生成したり、自動的に取り消したりするモニタリング機能を構築できます。

SDK と API によるアクセス

gcloudgsutil SDK を使用して GCP にアクセスする場合は、Google Cloud API に接続するときに認証が必要です。認証は、ローカル ユーザー環境ごとに 1 回行うだけで済みます。

アプリケーションやスクリプトが API クライアント ライブラリを使用して GCP にアクセスする場合は、最初に SDK で認証を行う必要があります。その後、API クライアント ライブラリが作成された認証情報を取得します。

プロジェクトの識別

各プロジェクトは、ユニバーサルに一意なプロジェクト ID を持っています。この ID は、英小文字、数字、ダッシュを使用した短い文字列です。プロジェクトを作成するときは、独自のプロジェクト名を指定します。プロジェクト 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 レベルで設定される権限を区別することが重要です。両者は連携して完全なユーザー プロフィールを提供しますが、2 つのシステムは異なる目的を果たし、異なるメカニズムで作成および変更されます。

Cloud IAM は、個々のインスタンスへの SSH アクセスやユーザー アクセスを管理しません。アクセスは、Cloud IAM と同期できる OS レベルのユーザー権限によって処理されます。ユーザーやサービス アカウントに Cloud IAM の権限を付与しても、ユーザーがインスタンスにログインする方法や、ログインした後の権限は変わりません。2 つのシステムは補完的に設計されています。IAM はコンソールや API などの GCP リソースへのアクセスを許可するために使用され、直接アクセスはそれを必要とするユーザーにのみプロビジョニングされます。

カスタム イメージを作成する場合、ブートディスク上の ssh と Google アカウント デーモンを変更することにより、SSH アクセスを有効または無効にできます。ガイダンスについては、公開イメージにすでに組み込まれているセキュリティ機能を調べてください。

Identity and Access Management(IAM)

Cloud IAM では、GCP リソースを管理する目的で、組織、プロジェクト、リソースのレベルで権限を作成して管理できます。Cloud IAM は、GCP サービスに関するアクセス制御を 1 つのシステムに統合し、一貫性のあるオペレーションのセットを提供します。

IAM の役割とグループ

Cloud IAM の基本的な役割は、ownereditorviewer の 3 つです。

owner: IT 部門のメンバー、システム管理者、プロダクション マネージャーなど、施設またはプロジェクトの信頼できるユーザーの限定されたグループだけが、プロジェクト オーナーレベルの特権を持つ必要があります。プロジェクト オーナーは、請求先アカウントから他のユーザーのアクセスレベルに至るまでのすべてを変更できるため、この役割の割り当てには細心の注意を払う必要があります。

1 人または複数のオーナーがいるプロジェクトを作成することができます。組織管理者の役割は、組織レベルでこれらのオーナーを維持することができます。この管理者の役割は、個々のプロジェクトに対する完全なオーナーレベルのアクセス権を与えることなく、プロジェクトの作成、プロジェクト課金の変更、役割の割り当てを行うことができます。

組織の管理者は、組織内のすべてのプロジェクトについてほぼすべての通知を受け取りますが、意図的にプロジェクト オーナーにのみ送信される通知もあります。

編集者: プロジェクトの編集者は、プロジェクト データの読み書き、インスタンスの起動と終了、プロジェクトのすべてのリソースのプロジェクト メタデータの読み書きなど、状態を変更する操作を行えます。

閲覧者: この読み取り専用の役割は、すべてのパイプラインで役立つわけではありませんが、外部システムをモニタリングしてログインする一部のサービス アカウントに割り当てることが必要になる場合があります。たとえば、画像や動画を読み取る日次レビュー システムや、Shotgun などのプロジェクト管理システムと通信する API などです。

定義済みの役割: いくつかの定義済みの役割は、ユーザーやサービス アカウントを特定のタスクに限定します。これらの役割は、たとえば、アーティストが作品の課金データにアクセスできないようにする、または制作アシスタントが実行中のインスタンスを削除できないようにする、といったことに役立ちます。

リソース階層を使用したアクセス制御

IAM ポリシーは、リソース階層のさまざまなレベルに設定することができます。リソースは親リソースのポリシーを継承します。これにより、IAM ポリシーの階層構造を組織の構造に反映できます。リソース階層の実装に関するベスト プラクティスのセットについて、以下のことが推奨されます。

未使用の役割を無効にする

多くの役割がデフォルトで有効になっており、プロジェクトの作成者やオーナーによる割り当てに使用できます。混乱を避けるため、特定のワークフローには適用されない役割を無効にすることができます。未使用の役割を無効にする場合は、プロジェクトごとではなく、組織の設定で行う必要があります。

インスタンスへの SSH アクセスの制御

適切なユーザーがリソースにアクセスできるようにするには、以下の必要条件があります。

  • Cloud Directory Sync によるディレクトリ サービスと Cloud IAM の間の同期。これにより、ユーザーリストとその権限がオンプレミスとクラウドで一致します。
  • インスタンスへの SSH アクセスのためのユーザー認証メカニズム(例: LDAP と結合された PAM Linux モジュールの使用)。

レンダリング ワークロードの場合、IT 部門のメンバー、システム管理者、レンダリング ラングラーなど、限定された少数のユーザーに SSH アクセスを制限することをおすすめします。

キュー マネージャによってクラウドに送信されたジョブは、通常、専用のレンダリング ユーザーまたはデーモンによって所有されます。たとえば、デフォルトでは、Qube! レンダリング ジョブは、ユーザー「qubeproxy」として実行します。この Qube の設定を、ジョブを開始したユーザーとして実行するように変更することをおすすめします。Qube ではこれは「ユーザーモード」と呼ばれます。これにより、ジョブを開始したユーザーの下ですべてのプロセスが実行されます。完了したレンダリングはこの所有権を保持します。

オンプレミスのレンダリング ワーカーを設定する場合と同様に、ブートイメージを設定する必要があります。つまり、オンプレミスのレンダリング ワーカーと同じプロトコルを使用して認証を実行します。

サービス アカウント

サービス アカウントは、Google のサービスとリソースにプログラムでアクセスするために使用できる特別な Google アカウントです。

パイプラインをレンダリングする場合、サービス アカウントは、インスタンスのデプロイ方法や終了方法、インスタンスでのジョブの割り当て方法や実行方法を制御するのに便利です。レンダリング キューイング ソフトウェアは、サービス アカウントの認証情報を使用して GCP 上のインスタンスを起動するので、新しいインスタンスでジョブを起動できます。

新しいプロジェクトを作成すると、いくつかのサービス アカウントがデフォルトで作成されます。Compute Engine default service account という名前のサービス アカウントと、キューイング ソフトウェアがインスタンスを起動するために使用するサービス アカウントだけを、保持することをおすすめします。サービス アカウントを削除するときは、一部のプロジェクト リソースへのアクセスが削除される場合があるため、注意してください。

個々のパイプライン タスクがプログラム駆動イベントを実行するために、個別のサービス アカウントを使用する場合があります。これらのサービス アカウントには、必要な範囲に基づいて Cloud IAM の役割が割り当てられます。次に例を示します。

  • レンダリング キュー マネージャーによるインスタンスのデプロイ: GCP でレンダリング ジョブを実行するためのメインサービス アカウント。このサービス アカウントには、役割 compute.instanceAdminiam.serviceAccountActor が割り当てられます。
  • アセット管理者: アセットの公開、取得、データベース管理のためのサービス アカウント。Cloud Storage を使用している場合、このサービス アカウントには役割 storage.admin が割り当てられます。
  • ロギング エージェント: プロジェクトのロギング メカニズム(Google Stackdriver など)専用のサービス アカウント。このサービス アカウントには、役割 logging.logWriter が割り当てられます。

アクセス スコープ

アクセス スコープは、インスタンスの権限を指定するレガシーな方法です。これらの権限は、インスタンスのすべてのユーザーに適用されます。アクセス スコープは、インスタンスから Google API にデフォルトの権限を付与します。Compute Engine や Cloud Storage などのリソースは、これらの API を通じてアクセスされます。

インスタンスからすべてのユーザーにデフォルトの権限を付与するのではなく、アクセス スコープと一緒に 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 で鍵暗号鍵を管理することもできます。

鍵と言えば 1 つの鍵を指すことが多いですが、厳密にはデータは 1 組の鍵のセットで保護されています。つまり、暗号化にはアクティブな 1 つの鍵、復号化には複数の履歴鍵を使用します。履歴鍵の数は鍵のローテーションのスケジュールで決まります。

または、Cloud Storage および Compute Engine の永続ディスクで使用する独自の暗号鍵を提供することもできますが、オンプレミスの鍵管理サービスがない場合は、Google にストレージ データの鍵の管理とローテーションを任せることを強くおすすめします。Google は 90 日ごとにローテーションを行います。

Cloud KMS は、クラウド サービスで直接使用するために暗号鍵をクラウド内で集中管理できる GCP サービスです。現在、他の GCP サービスに保存されているデータを暗号化するためのストレージ レイヤでの統合はありません。

独立した一元的プロジェクトを設定して、すべてのプロジェクトに対する Cloud KMS を実行することをおすすめします。

サービス アカウント

サービス アカウントを作成すると、そのアカウントに固有の公開鍵 / 秘密鍵のペアが自動的に生成されます。公開鍵は Google によって管理されますが、秘密鍵の管理はユーザーが行う必要があります。この秘密鍵は、GCP でタスクを実行するときにサービス アカウントを認証するために必要です。

ネットワーク セキュリティ

すべてのコンピューティング インスタンスは、Cloud Virtual Network のメンバーとして作成されます。デフォルトでは、すべてのネットワークは自動サブネット ネットワークであり、リージョンのサブネットワークが自動的に作成されます。各ネットワークは単一のプロジェクトにのみ属することができ、1 つのネットワークに複数のプロジェクトが存在することはできません。プロジェクト オーナー、組織管理者、または Compute ネットワーク管理者の特定の役割を持つユーザーだけが、ネットワーク プロパティを変更できます。

ネットワークとサブネットワーク

別のネットワークにリソースを分離して、新しいセキュリティ レベルを追加できます。たとえば、機密性の高いコンテンツを含む一連のショットを、他のプロジェクト データから分離された独立したネットワーク内でのみレンダリングできます。個別のプロジェクトにすると、より効果的にデータを分離できます。

新しいサブプロジェクトを作成すると、自動サブネット機能により、Compute Engine のリージョンごとに 1 つずつ、複数のサブネットワークが作成されます。特定のリージョンで開始された新しいインスタンスは、そのリージョンのサブネットワークに配置され、そのサブネットワーク内の内部 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 のみを許可する同様のルールを作成します。

デフォルトでは、ファイアウォール ルールはネットワーク全体に適用されます。2 つのサブネットワークでトラフィックを交換する場合は、両方向で 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 を実装する必要があります。Cloud Router を追加しない限り、VPN ゲートウェイはネットワーク内で外部 IP アドレスを持つ唯一のリソースです。Cloud Router は、境界ゲートウェイ プロトコル(BGP)を使用して、オンプレミス ネットワークと Cloud Platform ネットワークの間でプライベート IP 範囲をブロードキャストします。

ディスク イメージ

VFX パイプラインでは、イメージ管理のために組織レベルで別のプロジェクトを使用することをおすすめします。このようにすると、すべてのプロジェクトでアクティブに使用されている可能性がある施設全体のデフォルト イメージ テンプレートを変更しないで済みます。また、この方法は、ブートイメージを 1 か所にまとめて、適切な役割が割り当てられている他のすべてのプロジェクトからアクセスできるようにするのにも役立ちます。

IAM の役割を使用して、プロジェクト間でイメージを共有できます。詳細については、プロジェクト間でのイメージの共有をご覧ください。

公開イメージ

Compute Engine には事前設定済みの公開イメージが数多く用意されており、それぞれに互換性のある Linux および Windows オペレーティング システムが存在します。各 OS イメージは、Cloud SDK などの特定のパッケージを含むように設定されているか、SSH などのサービスが有効になるように設定されています。

また、これらのイメージには、ユーザー アカウントを設定して管理し、SSH 認証鍵ベースの認証の有効化も行う、パッケージのコレクションが含まれています。

カスタム イメージ

既存のイメージに基づいて、独自のカスタム ディスク イメージを作成できます。セキュリティのベスト プラクティスに準拠したイメージを作成することを強くおすすめします。

Google Compute Engine 用の Linux ゲスト環境をインストールし、公開イメージにおいてデフォルトで使用できる機能にアクセスすることをおすすめします。ゲスト環境をインストールすると、メタデータ アクセス、システム設定、GCP で使用するための OS の最適化など、公開イメージと同じセキュリティ コントロールをカスタム イメージで使用して、タスクを実行できます。

接続

施設から Google に接続するにはいくつかの方法があります。いずれの場合でも、仮想プライベート ネットワーク(VPN)を実装する必要があります。一部の方法では、以下で説明する追加設定を行って、データの安全な送信を保証する必要があります。

データに適用されるセキュリティ方法の一部を以下に示します。

  • Google の認証局が生成した 2048 ビットの証明書を TLS で使用して、Google へのデータリンクを暗号化します。
  • データセンター間のプライベート ネットワーク上を移動するデータを暗号化します。
  • すべての RSA 証明書を 2048 ビット鍵にアップグレードして、GCP や他のすべての Google サービスへの転送における暗号化を強化します。
  • Perfect forward secrecy(PFS)を使用します。これは、鍵が侵害された場合や暗号が解読された場合の影響を最小限に抑えるのに役立ちます。

インターネットを介した接続

インターネット経由で GCP サービスにアクセスするだけで、Google のネットワークに接続し、エンドツーエンドのセキュリティ モデルを利用できます。VPN トンネル内を移動するとき、データは認証済みで暗号化されたプロトコルによって保護されます。

ダイレクト ピアリング

Google は世界中の 100 以上の拠点施設でエッジ ネットワーク インフラストラクチャをホストしており、GCP のお客様はそれらに直接接続できます。パブリック ASN とパブリック ルーティング可能な IP 接頭辞をお持ちの GCP のお客様については、Google とピアリングを自由に行えます。このオプションは、公共のインターネットと同じ相互接続モデルを使用します。

Cloud Interconnect

パブリック ASN がないお客様、またはそれ以外の理由でサービス プロバイダを使用して Google に接続することを希望しているお客様は、Cloud Interconnect サービスを選択できます。Cloud Interconnect は、Google のエッジへのエンタープライズ グレードの接続を希望するお客様向けです。Cloud Interconnect のパートナー サービス プロバイダが、次の 2 つの方法のいずれかでエンタープライズ グレードの接続を提供します。

  • 既存のピアリング接続を使用。容量管理がまとめて行われ、高いパフォーマンスと低いレイテンシを保証します。
  • 専用の相互接続を使用。GCP のお客様のトラフィック伝送専用です(ただし、Google はこれらのリンクを介してすべてのサービスのルートをアナウンスします)。

Cloud VPN

オンプレミスのレンダリング パイプラインは、転送中のデータを常に暗号化するわけではありません。ただし、ハイブリッド クラウド レンダリング パイプラインでは、転送中のすべてのデータを暗号化することをおすすめします。

Google への接続方法に関係なく、VPN との接続をセキュリティ保護する必要があります。Cloud VPN は、IPsec VPN 接続によりピア VPN ゲートウェイを GCP ネットワークに接続します。2 つのネットワーク間のトラフィックは、一方の VPN ゲートウェイで暗号化され、もう一方の VPN ゲートウェイで復号化されます。これにより、インターネット上を移動するデータは保護されるので、レンダリング パイプラインの一部としてデータの暗号化を実装する必要はありません。

施設に複数の場所またはネットワークがある場合は、Cloud Router を使用してこれらの場所と Cloud VPN の間でルートの同期を維持できます。

顧客提供の VPN

GCP 内に独自の VPN ゲートウェイを設定することもできますが、柔軟性および GCP との統合が向上するので、Cloud VPN を使用することをおすすめします。

ファイル システム

データの管理に利用できる複数のファイル サーバー オプションがあります。パイプラインの方法によっては、複数のオプションの実装が必要になる場合があります。

オブジェクトベース

Cloud Storage は、レンダリング パイプライン全体で生成または使用されるすべてのデータに適した統合オブジェクト ストレージです。GCP の一部である Cloud Storage では、アクセス制御Cloud IAM暗号化など、GCP のセキュリティ機能を利用できます。

リージョンのストレージ クラスにバケットを作成すると、プロジェクトのメンバーがバケット内のデータにグローバルにアクセスできるようになりますが、データはやはり特定のデータセンターに格納されています。パフォーマンスの点から最も望ましいのは、スループット向上とレイテンシ低減のために、同じリージョンにストレージとコンピューティングを置くことです。

Cloud Storage のデータはグローバルに利用できるため、レプリケーションを必要とせずに離れた場所にある別の施設とデータを共有できます。その際、追加の下り料金が発生する可能性があります。このデータはグローバルにアクセスされるので、レンダリング パイプラインからデータが漏えいしないように、VM スコープユーザーアクセスキーを適切に管理することが不可欠です。

Cloud Storage のオブジェクトベース アーキテクチャとのインターフェースを持つことができるように、アセット管理パイプラインの調整が必要になる場合があります。

POSIX 準拠

本番環境のライブデータは POSIX 準拠のファイル サーバーに格納されることがよくありますが、これは変更時刻などのファイル メタデータにアクセスする必要のあるレンダリング パイプラインや、シーンアセットのファイルパスに依存するレンダリング パイプラインに非常に適しています。

施設のニーズとワークロードによっては、NFS ファイル システムを実装するときにいくつかの選択肢があります。

単一ノード ファイル サーバー

POSIX 準拠の NFS サーバーは、クリック デプロイ ソリューションとして使用できます。複数の単一ノード ファイルサーバーを実行し、それらをインスタンスにマウントできます。つまり、パイプラインの各部分のストレージを分離し、オンプレミスのファイル システムと同じ方法を使用して、オペレーティング システムのユーザーとグループのレベルでアクセスを制限できます。

また、データをレンダリング インスタンスに読み取り専用としてマウントすることで、単一ノード ファイルサーバー上のデータの保護にも役立ちます。ソフトウェア、パイプライン ツール、アセット ライブラリをレンダリング インスタンスから変更してはならないため、読み取り専用としてマウントすると、この制限を簡単に適用できます。

インスタンスは同じネットワークにしかファイル サーバーをマウントできないので、プロジェクトのセキュリティをさらに強化するには、ネットワークごとに 1 つの単一ノード ファイラーをデプロイすることもできます。

また、本番環境への影響を最小限に抑えながら、以前のバージョンにすばやくロールバックできるように、ソフトウェアまたはパイプライン ディスクのスナップショットを作成することもできます。

他のファイル システム

クラスタ化されたキャッシュ ファイル システムなど、他のサードパーティ ファイル システムを GCP で使用できます。サードパーティのキャッシュ ファイル システムでのセキュリティについては、個々のベンダーのコンプライアンス文書を参照してください。

ストレージ セキュリティ

デフォルトで、Cloud Storage は、Google が独自の暗号化データに使用するものと同じ堅牢な鍵管理システム(厳格なアクセス管理や監査を含む)を使用して、ユーザーに代わって暗号鍵を管理します。Cloud Storage は、保存時のユーザー コンテンツを暗号化し、各暗号鍵自体も定期的にローテーションされるマスター鍵のセットによって暗号化されます。

すべてのストレージ クラスは、データを保護するために同じ OAuth ときめ細かいアクセス制御をサポートします。

Cloud IAM を使用して、Cloud Storage バケット内またはプロジェクト内のデータにアクセスできるユーザーを制限することをおすすめします。少数のオブジェクトだけを管理する必要がある場合は、アクセス制御リストを利用することもできます。

転送オプション

転送中のデータのセキュリティとは、オンプレミスのストレージとクラウドの間でやり取りされるときのデータの安全性を指します。オンプレミスとクラウドの間のデータの移動を管理するのに役立つさまざまなパイプライン手法がありますが、それらの設計と実装はこのドキュメントの範囲外です。以下で概要を説明するすべての転送方法(サードパーティの転送方法を除きます)は、認証と承認に関する Google の完全なセキュリティ スイート内で実行されます。

コマンドライン

Cloud Storage との間で 10 TB 未満のデータをコピー、移動、同期するには、gsutil コマンドを使用することをおすすめします。gsutil コマンドは、GCP と同じセキュリティ機能と認証を使用し、Cloud IAM の役割に従い、トランスポート層暗号化(HTTPS)を使用してすべてのオペレーションを実行します。また、gsutil並列アップロードをサポートします。

単一ノード ファイル サーバーや永続ディスクなどの POSIX 準拠ファイル システムとの間での転送には、VPN 接続で scp または rsync を使用することをおすすめします。

UDP

AsperaTervela Cloud FastPathBitSpeedFDT など、サードバーティの UDP ベースのデータ転送プロトコルを使用して Cloud Storage バケットにデータを直接アップロードする場合は、サードパーティのドキュメントでセキュリティ モデルとベスト プラクティスをご確認ください。これらのサードパーティ サービスは Google によって管理されていません。

Stackdriver でのロギング

Google Stackdriver では、プロジェクト内や組織内のさまざまなアクティビティをモニタリングして記録することができます。Stackdriver はもともとはウェブ アプリケーションとウェブサービス向けに作成されましたが、レンダリング パイプラインのロギング サーバーとして使用でき、コマンドライン レンダリングによって生成される大量のデータの収集ポイントを提供します。

新しい GCP プロジェクトでは、Stackdriver API はデフォルトでは有効になりません。現在、Debugging、Logging、Monitoring、Trace の 4 つの API があります。そのすべてがワークフローに適用されるわけではありませんが、Stackdriver が外部アプリケーションのロギング サーバーとして機能できるように、少なくとも Stackdriver Logging を有効にすることをおすすめします。

監査ログは、サービスまたはプロジェクトの構成またはメタデータを変更する、コンソールまたは API を使用して行われた管理アクティビティを追跡するのに役立ちます。監査ログを変更または削除することはできません。

すべてのログは指定された期間保持された後、削除されます。ログエントリの保持期間は、Stackdriver Logging の割り当てポリシーによって指定されています。保持期間を超えてログを保持するには、Cloud Storage バケット、BigQuery データセット、Cloud Pub/Sub トピック、またはこれらの任意の組み合わせに、ログをエクスポートできます。

ログは Logging エージェントによって個々のインスタンスから収集されます。Logging エージェントはデフォルトではインストールされません。インストール方法については、こちらをご覧ください。

その他の考慮事項

このセクションでは、Google プロダクト ラインには含まれませんが、通常はハイブリッド レンダリング パイプラインの一部であるトピックについて説明します。

キュー管理

多くのスタジオでは、キュー マネージャを使用して、デプロイ、追跡、オンプレミスのレンダリング ファームにデプロイされるタスクを制御します。同じキュー マネージャを使用して、GCP にジョブをデプロイできる場合もあります。具体的なアプローチは、関連するソフトウェアによって異なる場合があります。

一部のキュー マネージャでは、サーバーとクライアントの両方が GCP に接続できるソフトウェア プラグインが提供されています。これらのセキュリティの実践方法を確認するには、サードパーティのドキュメントをご覧ください。

キュー マネージャから GCP に送信される指示は、gcloud コマンドを使用して発行する必要があります。ssh, を使用してコマンドを送信する必要がある場合は、通信用の SSH キーを生成する必要があります。これを回避するには、キュー管理サーバーをオンプレミスではなく GCP で実行することもできます。

インスタンスの作成と終了の自動化

場合によっては、ジョブ開始時のインスタンスの作成と、ジョブの正常終了時のインスタンスの終了を自動化することもできます。コストとセキュリティ上の理由から、ジョブを実行していないときはインスタンスを実行し続けないでください。

カスタム ソフトウェア

レンダリング パイプラインには、通常、サードパーティ製ソフトウェアとカスタム ソフトウェアの両方が含まれます。単純なスクリプトから、複数の依存関係を持つ複雑なコンパイル済みバイナリまで、あらゆるソフトウェアをカスタム ソフトウェアとすることができます。

スクリプトまたはプログラム内から GCP インスタンスを操作するには、使用可能なクライアント ライブラリを使用します。各バージョンでは、OAuth 2.0 認証用のメソッドが提供されます。

ライセンス

オンプレミス ライセンス サーバー

VPN を介して実行している場合、独自のオンプレミス ライセンス サーバーを使用すると、より安全な環境を提供できます。ただし、セキュリティ レベルは使用しているライセンス技術に制限されます。

クラウド ライセンス サーバー

GCP で独自のライセンス サーバーを実行する場合は、別のネットワーク上で実行して、制御とモニタリングを追加できるようにすることをおすすめします。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...