render farmのネットワークセグメンテーションとWireGuardセキュリティ: Tier-1 + Tier-2アーキテクチャ

はじめに

render farmはレンダリングの問題である前にネットワークの問題です。フレームはsubmissionマシン、manager、workerフリート、アセットキャッシュ、出力ストアの間を流れます; license seatはアーティストとライセンスサーバーの間を流れます; リモートセッションはアーティストと彼らが操作するワークステーション面の間を流れます。ネットワークが一部屋の一スイッチである場合、セキュリティモデルは主に境界モデルです。farmがデータセンターや大陸にまたがる場合、境界はもはや有用な分析単位ではありません: 建物の境界を越えるすべてのリンクは、そうでないと証明されるまでパブリックインターネットリンクであり、リモートシステムに触れるすべての認証情報は傍受される可能性があり、他のすべてのworkerに到達できるすべてのworkerは、一度侵害されればピボットできるworkerです。

この記事は、私たちがcross-siteおよびcross-country render farmデプロイメントに運用しているセキュリティアーキテクチャを説明します — default-denyエッジを持つ二層ファイアウォールモデル、その背後にノードごとのホストファイアウォール、建物の境界を越えるすべてのリンクに対するWireGuardエンドツーエンド暗号化、すべてのオペレーターロールに対する最小権限アクセスパターン、そして共有multi-tenantインフラストラクチャから専用シングルカスタマークラスタまでスケールする顧客分離プリミティブです。対象オーディエンス: 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 clusterインフラでは、物理ハードウェア境界、別個のWireGuardハブ、別個の認証情報ストア、別個の運用管理面を意味します。分離の強さはワークロードの感度に一致すべきです — 製品ビジュアライゼーションをレンダリングするフリーランサーとプリリリースエンターテインメント作業をレンダリングするスタジオは同じレベルを必要としませんが、彼らの脅威モデルに合うレベルを選択できるべきです。

第三に、どの顧客も、jobが実際に必要とする面を超えてオペレーターの内部システムに到達できません。renderサブミッションはmanagerのjobキューに書き込み、自身の出力を読み取ります; 他の顧客を列挙したり、オペレーターのbillingデータベースを読んだり、ソースコントロールに到達したりする必要はありません。これが、オペレーター自身のシステムを通じてすべての顧客を他のすべての顧客から保護する権限境界です。

私たちが運用するティアモデルはこれら三つの原則を反映します。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のデフォルトフォワード姿勢は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 inbound姿勢で構成されますが、ノードのロールが必要とする接続のみを許可する内部ルールがあります。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またはequivalentのStream専用ポート)は顧客の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ノードのうち1ノードの誤構成されたファイアウォールは目視で検出するのが難しく、ドリフト検出で捕まえやすいです。

WireGuardエンドツーエンド暗号化

建物の境界を越えるすべてのリンクはWireGuardで暗号化されます。アーティストワークステーションはクラスタゲートウェイにWireGuardをトンネルします。サイト間リンクはゲートウェイ間でWireGuardをトンネルします。オペレーターSSHセッションはオペレーターのラップトップからクラスタbastionにWireGuardをトンネルします。一つの建物内の内部クラスタLANはWireGuard暗号化されていません — そのトラフィックは私たちが制御する部屋のスイッチ上にあります — が、建物を出るすべてのものは暗号化されます。

ここでのWireGuardの魅力は、暗号化そのものとは関係のない性質です: plaintextフォールバックがありません。WireGuardはcipher suiteをネゴシエートせず、ランタイムでアルゴリズムを選択せず、「このピアがより古いcipherを要求したので応じよう」というコードパスを持ちません。すべてのトンネルはkey exchangeにCurve25519、data planeにChaCha20-Poly1305、ハッシングにBLAKE2s、message authenticationにPoly1305を使用します。cipher選択はプロトコルレベルで固定されています。TLS-styleのネゴシエートされたプロトコルに対する重要な攻撃クラス — downgrade、weak-cipher selection、broken-cipher legacy fallback — は、プロトコルにそれらの攻撃が標的とするネゴシエーションステップがないため適用されません。

ピアごとのキーが第二の性質です。すべてのピアは独自の公開キーを持ち、ハブは各ピアをそのキーと割り当てられたAllowedIPsに基づいて明示的に許可または拒否します。共有秘密はありません。あるワークステーションの秘密キーが漏れた場合、ハブ側の修正はその一つのピアを削除し、その一つのワークステーションに新しいkeypairを再発行することです; 他のすべてのピアは妨げられずに動作を続けます。Forward secrecyが第三の性質です: WireGuardはセッションキーを定期的にローテーションし、長期キーは初期ハンドシェイクにのみ使用されます。トラフィックを記録し、後で長期キーを侵害した攻撃者は、エフェメラル交換から派生したセッションキーがもはや存在しないため、記録されたトラフィックを復号化できません。

カーネルレベルの実装が第四の性質であり、アーキテクチャが運用上スケールで許容できるかを決定します。WireGuardは5.6からmainline Linuxカーネルに出荷されています。典型的なXeonゲートウェイでは、カーネルWireGuardは一桁のCPUパーセンテージコストでピアあたりギガビットクラスのスループットを持続します。ルーティング、ファイアウォール、DNSも行うゲートウェイでは、カーネル対ユーザースペース暗号化は快適なボックスと飽和したボックスの違いです。

最小権限アクセスパターン

クラスタ内のすべてのアカウントは仕事に必要な最小権限を持ち、オペレーターロールは単一のロールがすべてを行えないように分離されています。私たちが運用するデプロイメントで重要な四つのアカウントクラスです。

顧客リモートデスクトップアカウントは、自分自身のデータとDCC環境へのアクセスで顧客のワークステーション面にログインします。基盤となるオペレーティングシステムへのシェルアクセスはありません。顧客はリモートデスクトッププロトコルを介してDCCを操作し、renderを送信し、出力をダウンロードし、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 cluster

顧客分離には二つの実用的な実装があります。multi-tenant SaaSインフラは多くの顧客のjobを共有フリート上で実行し、OSレベルで分離します — 別個のユーザーアカウント、ファイルシステムパス、プロセスグループ、ライセンスチェックアウトスコープ。dedicated clusterインフラは、契約期間中その一人の顧客に割り当てられたハードウェア上で一人の顧客のjobを実行し、他の顧客のプロセス、アカウント、データは同じマシンに触れません。

multi-tenant分離がデフォルトであり、ほとんどのワークロードで正しい選択です — 経済性が優れており、プロセスレベルの分離はファイルシステムACLと上記のホストファイアウォールルールと組み合わさって、実際に重要なクロスカスタマーアクセスパターンを防ぎます。dedicated cluster分離は、ワークロードの価値、規制環境、契約上の義務がより強い境界を要求するときに正しい選択です。動機となる脅威モデル: OSレベルの分離にまだ知らない脆弱性があったら? オペレーター自身の内部アクセスがそれ自体攻撃ベクトルだったら? dedicatedハードウェアでは、答えは物理によって境界づけられます — 顧客のデータは顧客のドライブにあり、プロセスは顧客のCPUとGPUで実行され、顧客のWireGuardハブは顧客のピアのみにサービスを提供し、オペレーターアクセスはセッションごとの明示的な認可を要求するように構成できます。リスクのクラスが「オペレーターのmulti-tenant実装を信頼する」から「顧客自身のハードウェア境界を信頼する」に移ります。

customer-owned-credentialsモデル — BYOC、顧客のDCC license seatとアセットストア認証情報が顧客によって入力されオペレーターによって決して見られない — はdedicated clusterとの自然なペアリングです; 完全なモデルはcustomer-owned credentialsの記事を参照してください。dedicatedハードウェア+customer-owned credentialsは、オペレーターがインフラを運用するが認証材料、ソースファイル、プロジェクトデータを見ないことを意味します。オペレーターの役割は「顧客のデータにアクセスでき、それを使用しないことを選ぶ」のではなく「インフラを健全に保つ」になります。

multi-tenantではなくdedicatedを選択するタイミングはワークロード固有です。顧客がdedicatedを選択するのを見るのは、三つの条件のうち一つが存在する場合です: 顧客の法務またはcomplianceチームが書面で設定したIP感度しきい値; 実証可能な顧客ごとのデータ分離を要求する規制フレームワーク; またはコスト差が分離のアップサイドが優勢になるほど小さくなるスケールしきい値。別の記事がSaaS対dedicated cluster決定フレームワークをより深くカバーします。

Complianceレディネス(認証主張なし)

最初に正直な開示: 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暗号化機能を使用します; トレードオフはワークロードによって異なるため、エンゲージメントごとに構成可能です。SMB3はクロスサイトトラフィックでin-transit暗号化を要求するように構成されています。

監査トレイル能力。 SSHセッションログは、ソース、宛先、期間、コマンド履歴とともに、オペレーターアカウントが変更できないログホストに記録されます。WireGuardハンドシェイクログはすべてのピア接続試行を記録します。render-jobログは顧客ごとに送信時刻、パラメータ、完了ステータス、リソース使用量を記録します。これらのログは要求に応じて顧客の監査人にエクスポートできます。

アクセス制御と分離。 Tier-1 + Tier-2ファイアウォールモデルが分離制御です。オペレーター対顧客ロール分離がロールベースアクセス制御です。dedicated clusterモデルでの顧客ごとのファイアウォールグループメンバーシップが顧客分離制御です。それぞれはテキストとして独立して監査可能です。データ破壊はエンゲージメント終了時に文書化された手順に従います — ファイルレベル削除、空き領域上書き、何がいつ誰によって破壊されたかを記録したオペレーターが署名した証明書。証明書は顧客のcomplianceプログラムが証拠として保管するアーティファクトです。

ネットワークモニタリング。 クラスタはゲートウェイでフローロギング、各ノードでホストレベルモニタリングを運用します。SOC-2「continuous monitoring」目標が要求するレベルの継続的ネットワーク侵入検知は内部ロードマップにありますが、現在デプロイされていません。

重要なフレーミング: オペレーターのインフラは顧客のcomplianceプログラムの一構成要素であり、プログラム自体ではありません。SOC 2またはISO 27001を追求する顧客は彼らの制御の総体で評価され、その中でレンダリングベンダーは一つの入力です。私たちの仕事は顧客のプログラムが頼れるビルディングブロックを提供し、どの制御が成熟しているか、部分的か、まだスコープにないかを正直であることです。

脅威モデル

脅威モデルを含まないアーキテクチャドキュメントは、アーキテクチャがすべてに対して防御することを暗示する傾向があり、それは決して真実ではありません。このアーキテクチャが扱うものの範囲は限定的です; 扱わない失敗は現実であり、明示的に名前を挙げる価値があります。

アーキテクチャが何に対して防御するか。外部スキャンとプロービング: Tier-1 default-deny姿勢とWireGuardのauthenticate-before-acceptの動作は、認証されていないスキャンに対するクラスタの唯一の応答が沈黙であることを意味します — フィンガープリントするバナーなし、攻撃するバージョン文字列なし、ブルートフォースする認証プロンプトなし。単一ノード侵害後の横方向移動: Tier-2ホストファイアウォールは、侵害されたworkerが隣をスキャンまたはピボットできず、管理プレーンに到達できず、オペレーターbastionに到達できないことを意味します。ブラスト半径は一つのノード+そのノードが正当にアクセスできたもの — 意味があるがクラスタ全体ではありません。顧客に対して使用されるオペレーター認証情報の盗難: customer-owned credentialsを持つdedicated clusterモデルでは、オペレーターは顧客のlicense seat、アセットストア認証情報、プロジェクト復号化キーを保持しないため、オペレーターの認証情報ストアの侵害は顧客認証材料を公開しません。オペレータースタッフによるデータエクスフィルトレーションは、意味があるが絶対的ではない方法で: dedicatedインフラへのオペレーターSSHアクセスは監査されたbastionセッション、ハードウェアバックキー、セッションごとの認可を要求し、悪意のあるインサイダーシナリオのコストを大幅に上げますが、ゼロにはしません。

アーキテクチャが完全には防御しないもの。サプライチェーン攻撃: オペレーティングシステム、DCC、プラグイン、レンダーエンジン、カーネル自体はオペレーター以外の当事者によって書かれたソフトウェアです; 緩和できます(パッチ管理、ホストハードニング、侵害されたバイナリが到達できるものを制限するセグメンテーション)が排除できません。サプライチェーンリスクは私たちが解決したカテゴリではなく業界全体と共有するカテゴリです。管理者アクセスを持つインサイダー脅威: bastionアクセス、監査ログアクセス、それらの権限を悪用する持続的な意図を持つオペレーターは、監査ログ、二要素認証、ロール分離、顧客ごとのdedicated cluster境界によって制約されます — が、排除されません。オペレーター採用、バックグラウンドチェック、顧客自身がレビューできる監査トレイル可視性がこれに対処する制御です。顧客の認証情報衛生: ワークステーションが侵害されたために顧客の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 clusterモデルでは、オペレーターは顧客の認証材料を保持せず、顧客のデータは顧客に割り当てられたハードウェア上にあります — オペレーターの共有インフラの侵害はdedicated clusterが別個の境界であるため、dedicated-cluster顧客データを自動的に公開しません。Dedicated-plus-BYOCは高IP感度ワークロードに対する最強の実用的回答です。

Q: complianceレビュー用に監査ログを提供できますか? A: はい。SSHセッションログ、WireGuardハンドシェイクログ、render-jobログ、ファイアウォールフローログは、契約で定義された保持期間に従って、要求に応じて顧客の監査人にエクスポートできます。エクスポート形式は監査人が必要とするもの(最も一般的にはCSVまたはJSON)です。ログホスト自体への読み書きアクセスは提供しません; エクスポートモデルは監査トレイル整合性を保ちながら顧客に必要な証拠を提供します。

Q: エンゲージメント終了時のデータ破壊はどう検証されますか? A: ファイルレベル削除に続いて、関連ストレージデバイス上の空き領域上書き、そしてスコープのデバイス、日付と時刻、手順、関与した人員を記録したオペレーターが署名した証明書。それを要求するエンゲージメントでは、破壊は顧客の代表者によって立ち会われます。証明書は顧客のcomplianceプログラムが証拠として保管するアーティファクトです。

Q: 御社の自社スタッフからのインサイダー脅威についてはどうですか? A: インサイダー脅威はロール分離、bastionでの二要素認証、オペレーターアカウントが変更できない監査ログ、顧客ごとのdedicated cluster境界によって緩和されます。ゼロには減らされず、それを正直に言います。要求に応じた顧客自身による監査ログのレビューは、インサイダー悪用に対する最も効果的な制御の一つです — オペレータースタッフが実際に何をしたかについて顧客をループに入れます。

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 clusterとペアになるcustomer-owned-credentialsモデルについてはBYOC記事を参照してください。運用デプロイメントについては20ノードdedicated GPU render farmガイドを参照してください。購買決定フレームワークについてはSaaS対dedicated cluster比較とdedicated GPUクラスタレンタルランディングを参照してください。