Segmentazione di rete e sicurezza WireGuard per render farm: un'architettura Tier-1 + Tier-2

Introduzione

Una render farm è un problema di rete prima di essere un problema di rendering. I frame scorrono tra una macchina di submission, un manager, una flotta di worker, una cache di asset e uno store di output; le credenziali scorrono tra artisti e server di licenza; le sessioni remote scorrono tra artisti e la superficie workstation che stanno guidando. Quando la rete è uno switch in una stanza, il modello di sicurezza è prevalentemente perimetrale. Quando la farm si estende su datacenter o continenti, il perimetro non è più un'unità di analisi utile: ogni link che attraversa un confine di edificio è un link internet pubblico finché non provato altrimenti, ogni credenziale che tocca un sistema remoto può essere intercettata, e ogni worker che può raggiungere ogni altro worker è un worker che può pivottare se mai compromesso.

Questo articolo descrive l'architettura di sicurezza che operiamo per deployment render farm cross-site e cross-country — un modello firewall a due tier con edge default-deny, firewall host per nodo dietro, cifratura WireGuard end-to-end per ogni link che attraversa un confine di edificio, pattern di accesso a minimo privilegio per ogni ruolo operatore, e primitive di isolamento del cliente che scalano dall'infrastruttura multi-tenant condivisa ai cluster dedicati per singolo cliente. Il pubblico: team di sicurezza IT che valutano vendor di cloud-rendering, compliance officer e architetti di pipeline. Un articolo separato sull'architettura di rete — WireGuard hub-and-spoke, BBR, MSS clamping e cache SMB condivisa — copre il trasporto; questo articolo copre cosa accade sopra il cavo.

Principi di segmentazione di rete per render farm

La segmentazione qui significa tre cose distinte. Primo, nessun nodo può raggiungere un altro nodo che non deve raggiungere per il suo job. Un worker render legge asset dalla cache, tira job dal manager, scrive output di ritorno in una posizione nota e invia telemetria heartbeat — e nient'altro. Un worker compromesso che non può pivottare ad altri worker, raggiungere SSH operatore o il management plane è un guasto contenuto invece di un guasto cluster-wide. Il movimento laterale è la cosa più conseguente che una policy di segmentazione previene.

Secondo, nessun cliente può raggiungere un altro cliente. Su infrastruttura multi-tenant, questo significa che processi, account utente, percorsi del file system e check-out di licenza sono isolati per cliente a livello sistema operativo. Su infrastruttura dedicated cluster, questo significa confini hardware fisici, hub WireGuard, store di credenziali e superfici di gestione operativa separati. La forza dell'isolamento deve corrispondere alla sensibilità del workload — una freelance che renderizza una visualizzazione di prodotto e uno studio che renderizza lavoro entertainment pre-release non hanno bisogno dello stesso livello, ma devono poter scegliere il livello adatto al loro threat model.

Terzo, nessun cliente può raggiungere i sistemi interni dell'operatore oltre la superficie di cui il job ha effettivamente bisogno. Una submission render scrive nella coda del manager e legge i propri output; non deve enumerare altri clienti, leggere il database billing dell'operatore o raggiungere il suo source control. Questo è il confine di privilegio che protegge ogni cliente da ogni altro cliente attraverso i sistemi stessi dell'operatore.

Il modello tier che operiamo riflette questi tre principi. Tier 1 è il perimetro — l'edge gateway che dà sull'internet pubblico e decide quale traffico entra. Tier 2 è il firewall host per nodo — ogni macchina dentro il perimetro decide indipendentemente da quali peer accetta connessioni. Sopra entrambi i tier, i controlli di accesso a livello applicativo impongono separazione dei ruoli, isolamento del cliente e il confine di audit che le compliance review osservano. Ogni tier è auditabile indipendentemente; un guasto in uno non collassa gli altri.

Edge Tier-1 con ufw e default-deny

L'edge del cluster è un singolo gateway Linux con ufw, il frontend canonico per nftables su Ubuntu LTS. La postura configurata è default deny incoming e default allow outgoing. L'unica regola in ingresso sull'interfaccia pubblica è allow 51820/udp per WireGuard. Niente altro accetta traffico dal lato pubblico — niente SSH, niente HTTPS, niente SMB, niente API render manager, niente agenti monitoring. Quei servizi bindano solo su interfacce interne; raggiungerli dall'esterno del cluster richiede prima di terminare un tunnel WireGuard.

Il ragionamento è meccanico. Ogni porta aperta sull'internet pubblico viene scansionata in minuti e sondata continuamente dopo. Ridurre il numero di porte pubbliche a esattamente una, e fare in modo che quella porta parli un protocollo che non risponde a probe non autenticati (WireGuard non risponde nulla a un peer che non conosce), riduce la superficie di attacco all'unità significativa più piccola. SSH dietro un tunnel WireGuard è un bersaglio che l'attaccante non può raggiungere senza prima sconfiggere WireGuard.

La catena forward richiede attenzione esplicita. Il gateway agisce da router tra l'interfaccia WireGuard e la subnet cluster interna, e la postura forward default di ufw è deny. Impostiamo DEFAULT_FORWARD_POLICY="ACCEPT" in /etc/default/ufw, poi restringiamo i flussi effettivamente inoltrati con regole FORWARD esplicite che permettono il traffico tra subnet cluster note e negano tutto il resto. Il risultato è un perimetro auditabile che non instrada accidentalmente un pacchetto verso una destinazione non prevista.

Le regole in uscita meritano la stessa disciplina. I worker tirano da un piccolo insieme di asset store upstream, il manager parla con un piccolo insieme di server di licenza, la telemetria va a un piccolo insieme di endpoint monitoring, e gli aggiornamenti OS tirano da un mirror noto. Bloccare le destinazioni in uscita a quel piccolo insieme blocca un'intera classe di comportamenti post-compromise: un worker compromesso che vuole esfiltrare dati verso un host controllato dall'attaccante non lo raggiunge perché l'host non è nell'allowlist di egress. Il filtraggio egress trasforma l'esfiltrazione invisibile in un tentativo rumoroso che il monitoring può segnalare.

Il logging sull'edge Tier-1 registra ogni pacchetto in entrata droppato e ogni flusso inoltrato, spediti a un log host centrale dietro lo stesso tunnel WireGuard raggiungibile solo da workstation operatore autenticate. I log sono la fonte primaria di evidenza d'audit per le compliance review.

Firewall host Tier-2 su ogni nodo

L'edge Tier-1 è necessario e non sufficiente. Un worker raggiungibile da ogni altro worker sulla subnet interna è a un compromise di un pivot cluster-wide, indipendentemente da quanto forte sia l'edge. Tier 2 è la risposta: ogni macchina dentro il perimetro opera il proprio firewall host, con il proprio ruleset, decidendo indipendentemente quali peer accetta.

Su nodi Linux il firewall host è ufw, configurato con la stessa postura default-deny inbound dell'edge ma con regole interne che permettono solo le connessioni richieste dal ruolo del nodo. Un worker render accetta SMB dalla cache, il protocollo render-manager dal manager, telemetria monitoring dall'host monitoring e SSH dalla subnet bastion operatore. Tutto il resto, comprese connessioni da altri worker, viene negato. Un worker compromesso non può sondare il vicino perché il vicino non accetterà la connessione — l'edge Tier-1 è stato sconfitto in questo ipotetico, e il firewall host Tier-2 è la seconda linea che non lo è stata.

Su nodi Windows il firewall host è Windows Defender Firewall with advanced security, configurato con regole equivalenti. L'RDP in entrata è ristretto a una subnet operatore stretta per supporto di emergenza; il protocollo remote-desktop del cliente (una porta streaming dedicata per Moonlight o equivalente) è permesso solo dall'indirizzo peer WireGuard del cliente; tutto il resto viene negato. Per l'use case — applicare un piccolo ruleset su una flotta di macchine configurate identicamente — Windows Defender Firewall è pienamente adeguato, e la superficie di gestione si integra con Group Policy.

L'appartenenza a gruppo è l'unità di policy. I nodi sono raggruppati per ruolo e cliente: worker customer-A un gruppo, worker customer-B un altro, nodi management operatore un terzo, cache e storage un quarto. Le connessioni cross-gruppo richiedono una regola esplicita e sono negate di default. Un worker customer-A non può SMB-montare la cache di customer-B, non può RDP la workstation di customer-B e non può tirare un job da un manager customer-B — non perché il livello applicativo lo impone, ma perché il firewall host non permette al handshake TCP di completarsi.

Le regole firewall host sono gestite via configuration management così da essere version-controlled, reviewable e coerenti su ogni nodo. Un firewall mal configurato su un nodo su venti è difficile da rilevare a vista e facile da intercettare con drift detection.

Cifratura WireGuard end-to-end

Ogni link che attraversa un confine di edificio è cifrato con WireGuard. Le workstation artisti tunnelano WireGuard al gateway cluster. I link site-to-site tunnelano WireGuard tra gateway. Le sessioni SSH operatore tunnelano WireGuard dal laptop dell'operatore alla bastion cluster. La LAN cluster interna dentro un edificio non è cifrata WireGuard — quel traffico è su uno switch in una stanza che controlliamo — ma tutto ciò che lascia l'edificio sì.

L'attrattiva di WireGuard qui è una proprietà che non ha nulla a che fare con la crittografia in sé: non c'è fallback plaintext. WireGuard non negozia cipher suite, non seleziona algoritmi a runtime e non ha un percorso di codice "questo peer ha chiesto un cipher più vecchio quindi assecondiamo". Ogni tunnel usa Curve25519 per key exchange, ChaCha20-Poly1305 per il data plane, BLAKE2s per hashing e Poly1305 per message authentication. La scelta del cipher è fissa a livello di protocollo. Una classe significativa di attacchi a protocolli TLS-style negoziati — downgrade, weak-cipher selection, broken-cipher legacy fallback — non si applica perché il protocollo non ha lo step di negoziazione che quegli attacchi mirano.

Le chiavi per peer sono la seconda proprietà. Ogni peer ha la propria chiave pubblica, e l'hub permette o nega esplicitamente ogni peer in base alla sua chiave e ai suoi AllowedIPs. Non c'è segreto condiviso. Se la chiave privata di una workstation trapela, il fix lato hub è rimuovere quel peer e riemettere un nuovo keypair per quella singola workstation; ogni altro peer continua a operare indisturbato. La forward secrecy è la terza proprietà: WireGuard ruota le session key regolarmente, e le long-term key sono usate solo per l'handshake iniziale. Un attaccante che registra traffico e poi compromette una long-term key non può decifrare il traffico registrato, perché la session key derivata dallo scambio effimero non esiste più.

L'implementazione kernel-level è la quarta proprietà e determina se l'architettura sia operativamente tollerabile su scala. WireGuard è nel kernel Linux mainline dalla 5.6. Su un gateway Xeon tipico, WireGuard kernel sostiene throughput di classe gigabit per peer a un costo CPU a una sola cifra. Per un gateway che fa anche routing, firewall e DNS, kernel-vs-userspace crypto è la differenza tra una box comoda e una satura.

Pattern di accesso a minimo privilegio

Ogni account dentro il cluster ha i privilegi minimi per il suo job, e i ruoli operatore sono separati così che nessun ruolo singolo possa fare tutto. Quattro classi di account contano nei deployment che operiamo.

Account remote-desktop cliente si loggano nella superficie workstation del cliente con accesso ai propri dati e ambiente DCC. Non hanno accesso shell al sistema operativo sottostante. Il cliente guida la DCC tramite il protocollo remote-desktop, submitta render, scarica output e non tocca mai il livello di amministrazione OS. Un account cliente compromesso non può raggiungere credenziali OS-level, password di server di licenza o infrastruttura cluster condivisa.

Account operatore DevOps hanno accesso SSH ai nodi Linux tramite la bastion. L'accesso bastion richiede che l'operatore si autentichi prima tramite WireGuard, poi alla bastion con una chiave hardware-backed, poi al nodo di destinazione con una chiave per account. L'autenticazione a due fattori è imposta alla bastion. Ogni sessione SSH viene loggata in un audit log centrale che il proprio account dell'operatore non può modificare o cancellare — ora di inizio, indirizzo sorgente, nodo di destinazione, durata e cronologia comandi.

Agenti monitoring su ogni nodo hanno un account di servizio dedicato con accesso read-only alle metriche che raccolgono. Non possono eseguire comandi arbitrari, leggere dati applicativi o scrivere in alcuna posizione persistente oltre al proprio file log. Il principio è che l'osservazione non deve richiedere diritti di modifica. L'accesso storage è imposto da ACL SMB allo strato cache e NAS: un worker customer-A che monta la cache vede solo l'albero customer-A; il server SMB lo impone a livello file system invece di fare affidamento sul worker.

La separazione di ruoli più importante è quella tra operatore e cliente. L'operatore non ha accesso remote-desktop alle workstation cliente eccetto tramite una sessione di supporto auditata che il cliente deve autorizzare esplicitamente. Il cliente non ha accesso OS-level all'infrastruttura dell'operatore. Questo confine — imposto al livello WireGuard (configurazioni peer separate), al livello firewall host (regole di accesso separate) e al livello applicativo (realm di autenticazione separati) — è il confine che permette al cliente di confidare che il proprio workload sia solo suo.

Isolamento del cliente: multi-tenant versus dedicated cluster

L'isolamento del cliente ha due implementazioni pratiche. L'infrastruttura SaaS multi-tenant opera i job di molti clienti su una flotta condivisa, isolandoli a livello OS — account utente, percorsi del file system, gruppi di processo e scope di check-out di licenza separati. L'infrastruttura dedicated cluster opera i job di un cliente su hardware allocato a quel singolo cliente per la durata dell'engagement, senza che alcun processo, account o dato di un altro cliente tocchi le stesse macchine.

L'isolamento multi-tenant è il default, e per la maggior parte dei workload è la scelta corretta — l'economia è migliore, e l'isolamento a livello processo combinato con ACL file system e le regole firewall host sopra previene i pattern di accesso cross-customer che contano in pratica. L'isolamento dedicated cluster è la scelta corretta quando il valore del workload, l'ambiente regolatorio o gli obblighi contrattuali richiedono un confine più forte. Il threat model motivante è: e se l'isolamento OS-level avesse una vulnerabilità che ancora non conosciamo, o se l'accesso interno proprio dell'operatore fosse esso stesso il vettore d'attacco? Su hardware dedicato, le risposte sono limitate dalla fisica — i dati del cliente vivono sui dischi del cliente, i processi girano sulle CPU e GPU del cliente, l'hub WireGuard del cliente serve solo i suoi peer, e l'accesso operatore può essere configurato per richiedere autorizzazione esplicita per sessione. Una classe di rischi si sposta da "fidarsi dell'implementazione multi-tenant dell'operatore" a "fidarsi del proprio confine hardware del cliente".

Il modello customer-owned-credentials — BYOC, dove le licenze DCC e credenziali asset-store del cliente sono inserite dal cliente e mai viste dall'operatore — è l'abbinamento naturale con dedicated cluster; vedi il writeup customer-owned credentials per il modello completo. Hardware dedicato più customer-owned credentials significa che l'operatore opera l'infrastruttura ma non vede materiale di autenticazione, file sorgente o dati di progetto. Il ruolo dell'operatore diventa "mantenere l'infrastruttura sana" invece di "avere accesso ai dati del cliente e scegliere di non usarli".

Quando scegliere dedicated invece di multi-tenant è specifico al workload. Vediamo i clienti scegliere dedicated quando una di tre condizioni è presente: una soglia di sensibilità IP fissata per iscritto dal team legale o compliance del cliente; un framework regolatorio che richiede isolamento dei dati per cliente dimostrabile; o una soglia di scala dove la differenza di costo diventa abbastanza piccola che il vantaggio di isolamento domina. Un articolo separato copre il framework di decisione SaaS-vs-dedicated-cluster più in profondità.

Compliance readiness (senza rivendicazioni di certificazione)

La divulgazione onesta prima: Super Renders Farm attualmente non è certificata SOC 2, attualmente non è certificata ISO 27001 e non detiene alcuna altra certificazione formale di sicurezza dell'informazione che rappresenteremmo a un compliance reviewer come "abbiamo il certificato, può prenderlo come prova". Qualsiasi cliente il cui programma compliance richieda che i suoi vendor siano certificati dovrebbe saperlo prima di firmare un contratto.

Quello che forniamo è un insieme di blocchi tecnici che un auditor che esamina il programma compliance di un cliente può esaminare — i componenti dell'architettura descritta in questo articolo, visti attraverso le famiglie di controlli che SOC 2 e ISO 27001 condividono al livello tecnico.

Cifratura at-rest e in-transit. I dati in transito tra cliente e cluster, e tra nodi cluster che attraversano edifici, sono cifrati da WireGuard (Curve25519 + ChaCha20-Poly1305). I dati at-rest sullo strato cache e storage usano funzioni native OS di encryption-at-rest dove il cliente le richiede; questo è configurabile per engagement perché i tradeoff variano per workload. SMB3 è configurato per richiedere cifratura in-transit sul traffico cross-site.

Capacità di audit trail. I log di sessione SSH sono registrati con sorgente, destinazione, durata e cronologia comandi su un log host che gli account operatore non possono modificare. I log di handshake WireGuard registrano ogni tentativo di connessione peer. I log render-job registrano ora di submission, parametri, stato di completion e uso di risorse per cliente. Questi log possono essere esportati su richiesta per l'auditor del cliente.

Controllo d'accesso e segregazione. Il modello firewall Tier-1 + Tier-2 è il controllo di segregazione. La separazione di ruoli operatore-vs-cliente è il controllo di accesso basato sui ruoli. Le appartenenze ai gruppi firewall per cliente nel modello dedicated cluster sono il controllo di isolamento del cliente. Ognuno è auditabile indipendentemente come testo. La distruzione dei dati a fine engagement segue una procedura documentata — cancellazione a livello file, sovrascrittura dello spazio libero e una lettera di attestazione firmata dall'operatore che registra cosa è stato distrutto, quando e da chi. L'attestazione è l'artefatto che il programma compliance del cliente archivia come prova.

Monitoring di rete. Il cluster opera flow logging al gateway e monitoring a livello host su ogni nodo. La network intrusion detection continua al livello che un obiettivo SOC-2 "continuous monitoring" richiederebbe è sulla roadmap interna ma non attualmente in produzione.

L'inquadramento che conta: l'infrastruttura dell'operatore è un componente del programma compliance del cliente, non il programma stesso. Un cliente che persegue SOC 2 o ISO 27001 è valutato sulla totalità dei suoi controlli, dei quali il vendor di rendering è un input. Il nostro lavoro è fornire blocchi su cui il programma del cliente può fare affidamento, ed essere onesti su quali controlli sono maturi, parziali o non ancora in scope.

Threat model

I documenti d'architettura senza threat model tendono a lasciar intendere che l'architettura difenda contro tutto, cosa che non è mai vera. Lo scope di ciò che questa architettura affronta è delimitato; i guasti che non affronta sono reali e meritano di essere nominati.

Contro cosa difende l'architettura. Scanning e probing esterni: la postura default-deny Tier-1 e il comportamento authenticate-before-accept di WireGuard significano che l'unica risposta del cluster a uno scan non autenticato è silenzio — nessun banner da fingerprint, nessuna stringa di versione da attaccare, nessun prompt di auth da brute-forzare. Movimento laterale dopo un compromise single-node: il firewall host Tier-2 significa che un worker compromesso non può scannerare o pivottare ai vicini, raggiungere il management plane o la bastion operatore. Il blast radius è un nodo più ciò a cui il nodo aveva accesso legittimo — significativo, ma non cluster-wide. Furto di credenziali operatore usate contro il cliente: sul dedicated cluster con customer-owned credentials, l'operatore non detiene licenze, credenziali asset-store o chiavi di decifratura progetto del cliente, quindi un compromise dello store di credenziali operatore non espone materiale auth del cliente. Esfiltrazione di dati da personale operatore, in modo significativo ma non assoluto: l'accesso SSH operatore richiede sessioni bastion auditate, chiavi hardware-backed e autorizzazione per sessione, alzando sostanzialmente il costo di uno scenario insider malevolo senza ridurlo a zero.

Contro cosa l'architettura non difende pienamente. Attacchi supply-chain: sistemi operativi, DCC, plugin, render engine e il kernel stesso sono software scritti da parti diverse dall'operatore; possiamo mitigare (patch management, host hardening, segmentazione che limita ciò che un binario compromesso può raggiungere) ma non eliminare. Il rischio supply-chain è una categoria che condividiamo con tutta l'industria invece di una che abbiamo risolto. Minacce insider con accesso admin: un operatore con accesso bastion, accesso audit-log e intenzione sostenuta di abusare di quei privilegi è vincolato da audit log, autenticazione a due fattori, separazione di ruoli e il confine dedicated cluster per cliente — ma non eliminato. Assunzione di operatori, background check e visibilità audit-trail che i clienti possono esaminare sono i controlli che affrontano questo. Igiene credenziali del cliente: se la chiave privata WireGuard di un cliente trapela perché la workstation è compromessa, l'attaccante ha lo stesso accesso del cliente; l'operatore può rilevare pattern anomali e disabilitare il peer, ma non può prevenire il trapelo.

L'architettura rimuove grandi categorie di rischio e riduce altre a livelli gestibili; non rimuove ogni categoria, e qualsiasi rappresentazione vendor che suggerisca il contrario dovrebbe essere esaminata con scetticismo.

Domande frequenti

Q: WireGuard è production-grade per l'uso render farm enterprise? A: WireGuard è nel kernel Linux mainline dalla versione 5.6 (marzo 2020), è usato in produzione da grandi operatori di infrastruttura e il suo protocollo è stato formalmente verificato con il Tamarin prover. Le primitive crittografiche (Curve25519, ChaCha20-Poly1305, BLAKE2s, Poly1305) sono scelte moderne peer-reviewed usate in molti sistemi sensibili alla sicurezza. Per il trasporto render farm — tunnel di lunga durata, grandi flussi, piccola superficie operativa — è la scelta di produzione che operiamo da anni senza incidenti a livello protocollo.

Q: Se il nostro vendor render farm viene compromesso, i miei dati sono esposti? A: Su un modello multi-tenant, un compromise dell'infrastruttura operatore potrebbe esporre dati a cui i sistemi operatore hanno accesso, limitati dai controlli di isolamento del cliente sopra. Sul dedicated cluster con customer-owned credentials, l'operatore non detiene il materiale di autenticazione del cliente e i dati del cliente vivono su hardware allocato al cliente — un compromise dell'infrastruttura condivisa dell'operatore non espone automaticamente dati dedicated-cluster perché il dedicated cluster è un confine separato. Dedicated-plus-BYOC è la risposta pratica più forte per workload ad alta sensibilità IP.

Q: Potete fornire audit log per una compliance review? A: Sì. I log di sessione SSH, handshake WireGuard, render-job e flusso firewall possono essere esportati su richiesta per l'auditor del cliente, soggetto al periodo di retention definito nel contratto. Il formato di export è quello di cui l'auditor ha bisogno (più comunemente CSV o JSON). Non forniamo accesso read-write al log host stesso; il modello di export preserva l'integrità dell'audit trail dando al cliente le prove necessarie.

Q: Come si verifica la distruzione dei dati a fine engagement? A: La cancellazione a livello file è seguita da una sovrascrittura dello spazio libero sui dispositivi di storage rilevanti, poi una lettera di attestazione firmata dall'operatore che registra i dispositivi nello scope, data e ora, procedura e personale coinvolto. Per engagement che lo richiedono, la distruzione può essere testimoniata dal rappresentante del cliente. L'attestazione è l'artefatto che il programma compliance del cliente archivia come prova.

Q: E le minacce insider del vostro personale? A: La minaccia insider è mitigata da separazione di ruoli, autenticazione a due fattori alla bastion, audit log che gli account operatore non possono modificare e il confine dedicated cluster per cliente. Non è ridotta a zero, e lo diciamo onestamente. La revisione propria del cliente degli audit log, su richiesta, è uno dei controlli più efficaci contro l'abuso insider — mette il cliente nel ciclo su ciò che il personale operatore ha effettivamente fatto.

Q: Supportate integrazione SAML o single sign-on? A: L'SSO lato cliente è sulla roadmap interna e non è una funzionalità generalmente disponibile oggi. I clienti che hanno bisogno di SSO per le proprie ragioni di compliance dovrebbero sollevarlo nello scoping dell'engagement; alcune integrazioni sono state fatte per engagement, dove il provider d'identità del cliente può essere ponteggiato al livello auth del cluster tramite un percorso documentato.

Q: Il mio auditor SOC 2 o ISO 27001 può esaminare la vostra architettura? A: Sì. Come divulgato, non siamo certificati noi stessi, ma rispondiamo a questionari di vendor-review e a richieste di review architettura degli auditor cliente. I blocchi tecnici descritti in questo articolo sono gli stessi che l'auditor vedrà nelle nostre risposte scritte; le configurazioni sono auditabili come testo. Ciò che non possiamo fornire è un documento di certificazione proprio, perché attualmente non ne deteniamo uno.

Q: Qual è la vostra copertura intrusion detection? A: Il flow logging sull'edge Tier-1 e il monitoring a livello host su ogni nodo sono dispiegati oggi. La network intrusion detection continua al livello che un obiettivo SOC-2 "continuous monitoring" richiederebbe è sulla roadmap interna ma non attualmente in produzione. I clienti il cui programma compliance richiede un controllo continuous-IDS dovrebbero valutare il gap contro la propria tolleranza al rischio.

Per l'architettura di rete su cui questo modello di sicurezza poggia, vedi il nostro deep-dive architettura render farm cross-country. Per il modello customer-owned-credentials che si abbina a dedicated cluster, vedi il writeup BYOC. Per il deployment operativo, vedi la nostra guida render farm 20 nodi GPU dedicata. Per il framework di decisione d'acquisto, vedi il confronto SaaS versus dedicated cluster e la landing dedicated GPU cluster rental.