Segmentation réseau et sécurité WireGuard pour render farm : une architecture Tier-1 + Tier-2

Introduction

Une render farm est un problème réseau avant d'être un problème de rendu. Les frames circulent entre une machine de submission, un manager, une flotte de workers, un cache d'assets et un store de sorties ; les credentials circulent entre artists et serveurs de licence ; les sessions remote circulent entre artists et la surface de workstation qu'ils pilotent. Quand le réseau est un switch dans une salle, le modèle de sécurité est principalement périmétrique. Quand la farm s'étend sur des datacenters ou des continents, le périmètre n'est plus une unité d'analyse utile : chaque lien qui franchit une frontière de bâtiment est un lien internet public jusqu'à preuve du contraire, chaque credential qui touche un système distant peut être intercepté, et chaque worker capable d'atteindre chaque autre worker est un worker capable de pivoter en cas de compromission.

Cet article décrit l'architecture de sécurité que nous opérons pour les déploiements render farm cross-site et cross-country — un modèle pare-feu à deux tiers avec edge default-deny, pare-feux hôte par nœud derrière, chiffrement WireGuard de bout en bout pour chaque lien franchissant une frontière de bâtiment, modèles d'accès moindre privilège pour chaque rôle opérateur, et primitives d'isolation client qui passent de l'infrastructure multi-tenant partagée aux clusters dédiés à un seul client. Le public visé : équipes sécurité IT évaluant des vendeurs de cloud-rendering, compliance officers et architectes pipeline. Un article séparé sur l'architecture réseau — WireGuard hub-and-spoke, BBR, MSS clamping et cache SMB partagé — couvre le transport ; cet article couvre ce qui se passe au-dessus du fil.

Principes de segmentation réseau pour render farm

La segmentation signifie ici trois choses distinctes. D'abord, aucun nœud ne peut joindre un autre nœud dont il n'a pas besoin pour son job. Un worker render lit des assets dans le cache, tire des jobs du manager, écrit ses sorties à un emplacement connu et envoie de la télémétrie heartbeat — rien d'autre. Un worker compromis incapable de pivoter vers d'autres workers, d'atteindre le SSH opérateur ou le management plane est une défaillance contenue plutôt qu'une défaillance cluster-wide. Le mouvement latéral est la chose la plus conséquente qu'une politique de segmentation empêche.

Ensuite, aucun client ne peut atteindre un autre client. Sur infrastructure multi-tenant, cela signifie que les processus, comptes utilisateur, chemins du système de fichiers et check-outs de licence sont isolés par client au niveau OS. Sur infrastructure dédiée, cela signifie des frontières matérielles, hubs WireGuard, stores de credentials et surfaces de gestion opérationnelle séparés. La force de l'isolation doit correspondre à la sensibilité du workload — une freelance rendant une visualisation produit et un studio rendant un travail entertainment pre-release n'ont pas besoin du même niveau, mais doivent pouvoir choisir le niveau adapté à leur threat model.

Troisièmement, aucun client ne peut atteindre les systèmes internes de l'opérateur au-delà de la surface dont le job a besoin. Une submission render écrit dans la queue du manager et lit ses propres sorties ; elle n'a pas besoin d'énumérer d'autres clients, de lire la base billing de l'opérateur ou d'atteindre son source control. C'est la frontière de privilège qui protège chaque client de chaque autre client à travers les systèmes propres de l'opérateur.

Le modèle tiers que nous opérons reflète ces trois principes. Tier 1 est le périmètre — la gateway edge face à l'internet public qui décide quel trafic entre. Tier 2 est le pare-feu hôte par nœud — chaque machine à l'intérieur du périmètre décide indépendamment quels peers elle accepte. Au-dessus des deux tiers, les contrôles d'accès au niveau application appliquent la séparation des rôles, l'isolation client et la frontière d'audit que les compliance reviews regardent. Chaque tier est auditable indépendamment ; une défaillance à un tier ne fait pas s'effondrer les autres.

Edge Tier-1 avec ufw et default-deny

L'edge du cluster est une gateway Linux unique avec ufw, le frontend canonique pour nftables sur Ubuntu LTS. La posture configurée est default deny incoming et default allow outgoing. La seule règle entrante sur l'interface publique est allow 51820/udp pour WireGuard. Rien d'autre n'accepte de trafic du côté public — pas SSH, pas HTTPS, pas SMB, pas l'API render manager, pas les agents monitoring. Ces services bindent sur des interfaces internes uniquement ; les atteindre depuis l'extérieur du cluster exige d'abord de terminer un tunnel WireGuard.

Le raisonnement est mécanique. Chaque port ouvert sur l'internet public est scanné en quelques minutes et sondé en continu. Réduire le nombre de ports publics à exactement un, et faire parler ce port un protocole qui ne répond pas aux probes non authentifiés (WireGuard ne répond rien à un peer qu'il ne connaît pas), réduit la surface d'attaque à l'unité significative la plus petite. SSH derrière un tunnel WireGuard est une cible que l'attaquant ne peut pas atteindre sans d'abord vaincre WireGuard.

La chaîne forward exige une attention explicite. La gateway agit comme routeur entre l'interface WireGuard et le sous-réseau cluster interne, et la posture forward par défaut d'ufw est deny. Nous mettons DEFAULT_FORWARD_POLICY="ACCEPT" dans /etc/default/ufw, puis nous restreignons les flux effectivement forwardés avec des règles FORWARD explicites qui autorisent le trafic entre sous-réseaux cluster connus et refusent tout le reste. Le résultat est un périmètre auditable qui ne route pas accidentellement un paquet vers une destination non prévue.

Les règles sortantes méritent la même discipline. Les workers tirent d'un petit ensemble d'asset stores upstream, le manager parle à un petit ensemble de serveurs de licence, la télémétrie va à un petit ensemble d'endpoints de monitoring, et les mises à jour OS tirent d'un mirror connu. Verrouiller les destinations sortantes sur ce petit ensemble bloque toute une classe de comportements post-compromise : un worker compromis qui veut exfiltrer des données vers un hôte contrôlé par l'attaquant n'y arrive pas parce que l'hôte n'est pas sur l'allowlist d'egress. Le filtrage d'egress transforme l'exfiltration invisible en tentative bruyante que le monitoring peut signaler.

Le logging sur l'edge Tier-1 enregistre chaque paquet entrant droppé et chaque flux forwardé, envoyés à un log host central derrière le même tunnel WireGuard joignable uniquement depuis des workstations opérateur authentifiées. Les logs sont la source primaire d'évidence d'audit pour les compliance reviews.

Pare-feu hôte Tier-2 sur chaque nœud

L'edge Tier-1 est nécessaire et non suffisant. Un worker joignable depuis chaque autre worker du sous-réseau interne est à un compromise d'un pivot cluster-wide, quelle que soit la force de l'edge. Tier 2 est la réponse : chaque machine à l'intérieur du périmètre opère son propre pare-feu hôte, avec son propre ruleset, décidant indépendamment quels peers elle accepte.

Sur les nœuds Linux le pare-feu hôte est ufw, configuré avec la même posture default-deny inbound que l'edge mais avec des règles internes n'autorisant que les connexions exigées par le rôle du nœud. Un worker render accepte SMB depuis la cache, le protocole render-manager depuis le manager, la télémétrie monitoring depuis le host monitoring, et SSH depuis le sous-réseau bastion opérateur. Tout le reste, y compris les connexions depuis d'autres workers, est refusé. Un worker compromis ne peut pas sonder son voisin parce que le voisin n'acceptera pas la connexion — l'edge Tier-1 a été vaincu dans cette hypothèse, et le pare-feu hôte Tier-2 est la seconde ligne qui ne l'a pas été.

Sur les nœuds Windows le pare-feu hôte est Windows Defender Firewall with advanced security, configuré avec des règles équivalentes. RDP entrant est restreint à un sous-réseau opérateur étroit pour le support d'urgence ; le protocole remote-desktop du client (un port streaming dédié pour Moonlight ou équivalent) n'est autorisé que depuis l'adresse peer WireGuard du client ; tout le reste est refusé. Pour le use case — appliquer un petit ruleset sur une flotte de machines identiquement configurées — Windows Defender Firewall est pleinement adéquat, et la surface de gestion s'intègre avec Group Policy.

L'appartenance à un groupe est l'unité de policy. Les nœuds sont groupés par rôle et par client : workers customer-A un groupe, workers customer-B un autre, nœuds management opérateur un troisième, cache et stockage un quatrième. Les connexions inter-groupes exigent une règle explicite et sont refusées par défaut. Un worker customer-A ne peut pas SMB-monter la cache de customer-B, ne peut pas RDP la workstation de customer-B et ne peut pas tirer un job d'un manager customer-B — non parce que la couche applicative l'impose, mais parce que le pare-feu hôte n'autorise pas le handshake TCP à se compléter.

Les règles pare-feu hôte sont gérées via configuration management pour être versionnées, reviewables et cohérentes sur chaque nœud. Un pare-feu mal configuré sur un nœud parmi vingt est difficile à détecter par inspection et facile à attraper avec la drift detection.

Chiffrement WireGuard de bout en bout

Chaque lien qui franchit une frontière de bâtiment est chiffré avec WireGuard. Les workstations artistes tunnellent WireGuard vers la gateway cluster. Les liens site-à-site tunnellent WireGuard entre gateways. Les sessions SSH opérateur tunnellent WireGuard du laptop de l'opérateur vers la bastion cluster. Le LAN cluster interne à l'intérieur d'un bâtiment n'est pas chiffré WireGuard — ce trafic est sur un switch dans une salle que nous contrôlons — mais tout ce qui quitte le bâtiment l'est.

L'attrait de WireGuard ici est une propriété qui n'a rien à voir avec la cryptographie en soi : il n'y a pas de fallback plaintext. WireGuard ne négocie pas de cipher suites, ne sélectionne pas d'algorithmes au runtime et n'a pas de chemin de code « ce peer a demandé un cipher plus ancien, nous allons obliger ». Chaque tunnel utilise Curve25519 pour le key exchange, ChaCha20-Poly1305 pour le data plane, BLAKE2s pour le hachage et Poly1305 pour la message authentication. Le choix de cipher est figé au niveau protocole. Une classe d'attaques sur les protocoles TLS-style négociés — downgrade, weak-cipher selection, broken-cipher legacy fallback — ne s'applique pas parce que le protocole n'a pas l'étape de négociation que ces attaques visent.

Les clés par peer sont la seconde propriété. Chaque peer a sa propre clé publique, et le hub autorise ou refuse explicitement chaque peer selon sa clé et son AllowedIPs. Il n'y a pas de secret partagé. Si la clé privée d'une workstation fuite, le fix côté hub est de retirer ce peer et de reissuer un nouveau keypair pour cette seule workstation ; chaque autre peer continue à opérer non perturbé. La forward secrecy est la troisième propriété : WireGuard fait tourner les session keys régulièrement, et les long-term keys ne servent qu'au handshake initial. Un attaquant qui enregistre le trafic et compromet plus tard une long-term key ne peut pas déchiffrer le trafic enregistré, car la session key dérivée de l'échange éphémère n'existe plus.

L'implémentation kernel-level est la quatrième propriété, et elle détermine si l'architecture est opérationnellement tolérable à l'échelle. WireGuard est dans le kernel Linux mainline depuis 5.6. Sur une gateway Xeon typique, WireGuard kernel soutient un débit gigabit-class par peer à un coût CPU à un chiffre. Pour une gateway faisant aussi du routing, du firewall et du DNS, kernel-vs-userspace crypto est la différence entre une box confortable et une box saturée.

Modèles d'accès moindre privilège

Chaque compte dans le cluster a les privilèges minimum pour son job, et les rôles opérateur sont séparés de sorte qu'aucun rôle unique ne puisse tout faire. Quatre classes de comptes comptent dans les déploiements que nous opérons.

Comptes remote-desktop client se loggent sur la surface workstation du client avec accès à ses propres données et environnement DCC. Ils n'ont pas d'accès shell au système d'exploitation sous-jacent. Le client pilote la DCC via le protocole remote-desktop, submitte les renders, télécharge les sorties et ne touche jamais la couche d'administration OS. Un compte client compromis ne peut pas atteindre les credentials OS, mots de passe de serveur de licence ou infrastructure cluster partagée.

Comptes opérateur DevOps ont accès SSH aux nœuds Linux via la bastion. L'accès bastion exige que l'opérateur s'authentifie d'abord via WireGuard, puis à la bastion avec une clé hardware-backed, puis au nœud de destination avec une clé par compte. L'authentification à deux facteurs est imposée à la bastion. Chaque session SSH est loggée dans un audit log central que le compte propre de l'opérateur ne peut pas modifier ou supprimer — heure de début, adresse source, nœud de destination, durée et historique de commandes.

Agents monitoring sur chaque nœud ont un compte de service dédié avec accès read-only aux métriques qu'ils collectent. Ils ne peuvent pas exécuter de commandes arbitraires, lire des données applicatives ou écrire à un emplacement persistant autre que leur propre fichier log. Le principe est que l'observation ne doit pas exiger des droits de modification. L'accès stockage est imposé par les ACL SMB à la couche cache et NAS : un worker customer-A montant la cache ne voit que l'arborescence customer-A ; le serveur SMB impose cela au niveau système de fichiers plutôt que de se fier au worker.

La séparation de rôles la plus importante est celle entre opérateur et client. L'opérateur n'a pas d'accès remote-desktop aux workstations clients sauf via une session de support auditée que le client doit explicitement autoriser. Le client n'a pas d'accès OS-level à l'infrastructure de l'opérateur. Cette frontière — imposée à la couche WireGuard (configurations peer séparées), à la couche pare-feu hôte (règles d'accès séparées) et à la couche application (realms d'authentification séparés) — est la frontière qui permet à un client d'avoir confiance que son workload est le sien seul.

Isolation client : multi-tenant versus dedicated cluster

L'isolation client a deux implémentations pratiques. L'infrastructure SaaS multi-tenant opère les jobs de nombreux clients sur une flotte partagée, les isolant au niveau OS — comptes utilisateur, chemins de système de fichiers, groupes de processus et scopes de check-out de licence séparés. L'infrastructure dedicated cluster opère les jobs d'un client sur du matériel alloué à ce seul client pendant la durée de l'engagement, sans qu'aucun processus, compte ou donnée d'un autre client ne touche les mêmes machines.

L'isolation multi-tenant est le défaut, et pour la plupart des workloads c'est le bon choix — l'économie est meilleure, et l'isolation au niveau processus combinée aux ACL système de fichiers et aux règles pare-feu hôte ci-dessus empêche les patterns d'accès cross-customer qui comptent en pratique. L'isolation dedicated cluster est le bon choix quand la valeur du workload, l'environnement réglementaire ou les obligations contractuelles exigent une frontière plus forte. Le threat model motivant est : et si l'isolation OS-level avait une vulnérabilité que nous ne connaissons pas encore, ou et si l'accès interne propre de l'opérateur était lui-même le vecteur d'attaque ? Sur matériel dédié, les réponses sont bornées par la physique — les données du client vivent sur les disques du client, les processus tournent sur les CPU et GPU du client, le hub WireGuard du client ne sert que ses peers, et l'accès opérateur peut être configuré pour exiger une autorisation explicite par session. Une classe de risques passe de « faire confiance à l'implémentation multi-tenant de l'opérateur » à « faire confiance à la propre frontière matérielle du client ».

Le modèle customer-owned-credentials — BYOC, où les licences DCC et credentials asset-store du client sont saisis par le client et jamais vus par l'opérateur — est l'appariement naturel avec dedicated cluster ; voir le writeup customer-owned credentials pour le modèle complet. Matériel dédié plus customer-owned credentials signifie que l'opérateur opère l'infrastructure mais ne voit ni le matériel d'authentification, ni les fichiers source, ni les données projet. Le rôle de l'opérateur devient « garder l'infrastructure saine » plutôt que « avoir accès aux données du client et choisir de ne pas les utiliser ».

Quand choisir dedicated plutôt que multi-tenant est spécifique au workload. Nous voyons les clients choisir dedicated quand l'une de trois conditions est présente : un seuil de sensibilité IP fixé par écrit par l'équipe légale ou compliance du client ; un cadre réglementaire qui exige une isolation des données par client démontrable ; ou un seuil d'échelle où la différence de coût devient assez petite pour que l'avantage d'isolation domine. Un article séparé couvre le framework de décision SaaS-vs-dedicated-cluster plus en profondeur.

Compliance readiness (sans revendications de certification)

D'abord la divulgation honnête : Super Renders Farm n'est actuellement pas certifié SOC 2, n'est actuellement pas certifié ISO 27001 et ne détient aucune autre certification formelle de sécurité de l'information que nous représenterions à un compliance reviewer comme « nous avons le certificat, vous pouvez le prendre comme preuve ». Tout client dont le programme de compliance exige que ses vendeurs soient certifiés doit le savoir avant de signer un contrat.

Ce que nous fournissons est un ensemble de briques techniques qu'un auditeur reviewant le programme compliance d'un client peut examiner — les composants de l'architecture décrite dans cet article, vus à travers les familles de contrôles que SOC 2 et ISO 27001 partagent à la couche technique.

Chiffrement at-rest et in-transit. Les données en transit entre le client et le cluster, et entre nœuds cluster qui franchissent des bâtiments, sont chiffrées par WireGuard (Curve25519 + ChaCha20-Poly1305). Les données at-rest sur la couche cache et stockage utilisent les fonctions natives OS d'encryption-at-rest là où le client les demande ; c'est configurable par engagement parce que les tradeoffs varient par workload. SMB3 est configuré pour exiger le chiffrement in-transit sur le trafic cross-site.

Capacité de traçabilité d'audit. Les logs de session SSH sont enregistrés avec source, destination, durée et historique de commandes sur un log host que les comptes opérateur ne peuvent pas modifier. Les logs de handshake WireGuard enregistrent chaque tentative de connexion peer. Les logs render-job enregistrent heure de submission, paramètres, statut de completion et usage ressources par client. Ces logs peuvent être exportés sur demande pour l'auditeur du client.

Contrôle d'accès et ségrégation. Le modèle pare-feu Tier-1 + Tier-2 est le contrôle de ségrégation. La séparation de rôles opérateur-versus-client est le contrôle d'accès basé sur rôles. Les appartenances aux groupes pare-feu par client dans le modèle dedicated cluster sont le contrôle d'isolation client. Chacun est auditable indépendamment comme texte. La destruction de données en fin d'engagement suit une procédure documentée — suppression au niveau fichier, écrasement de l'espace libre et une lettre d'attestation signée par l'opérateur enregistrant ce qui a été détruit, quand et par qui. L'attestation est l'artefact que le programme compliance du client classe comme preuve.

Monitoring réseau. Le cluster opère du flow logging à la gateway et du monitoring au niveau host sur chaque nœud. La network intrusion detection continue au niveau qu'un objectif SOC-2 « continuous monitoring » exigerait est sur la roadmap interne mais pas actuellement déployée.

Le cadrage qui compte : l'infrastructure de l'opérateur est un composant du programme compliance du client, pas le programme lui-même. Un client poursuivant SOC 2 ou ISO 27001 est évalué sur la totalité de ses contrôles, dont le vendeur de rendu est un input. Notre travail est de fournir des briques sur lesquelles le programme du client peut compter, et d'être honnêtes sur quels contrôles sont matures, partiels ou pas encore dans le scope.

Threat model

Les documents d'architecture sans threat model tendent à laisser entendre que l'architecture défend contre tout, ce qui n'est jamais vrai. Le scope de ce que cette architecture adresse est borné ; les défaillances qu'elle n'adresse pas sont réelles et méritent d'être nommées.

Ce contre quoi l'architecture défend. Scanning et probing externes : la posture default-deny Tier-1 et le comportement authenticate-before-accept de WireGuard signifient que la seule réponse du cluster à un scan non authentifié est le silence — pas de bannière à fingerprinter, pas de chaîne de version à attaquer, pas de prompt d'auth à brute-forcer. Mouvement latéral après un compromise single-node : le pare-feu hôte Tier-2 signifie qu'un worker compromis ne peut pas scanner ou pivoter vers ses voisins, atteindre le management plane ou la bastion opérateur. Le blast radius est un nœud plus ce auquel le nœud avait un accès légitime — significatif, mais pas cluster-wide. Vol de credentials opérateur utilisés contre le client : sur le dedicated cluster avec customer-owned credentials, l'opérateur ne détient ni licences, ni credentials asset-store, ni clés de déchiffrement projet du client, donc un compromise du store de credentials opérateur n'expose pas le matériel d'auth client. Exfiltration de données par le personnel opérateur, de manière significative mais non absolue : l'accès SSH opérateur exige des sessions bastion auditées, des clés hardware-backed et une autorisation par session, ce qui élève substantiellement le coût d'un scénario d'insider malveillant sans le réduire à zéro.

Ce contre quoi l'architecture ne défend pas pleinement. Attaques supply-chain : systèmes d'exploitation, DCCs, plugins, render engines et le kernel lui-même sont des logiciels écrits par d'autres parties que l'opérateur ; nous pouvons mitiger (patch management, host hardening, segmentation qui limite ce qu'un binary compromis peut atteindre) mais pas éliminer. Le risque supply-chain est une catégorie que nous partageons avec toute l'industrie plutôt qu'une que nous aurions résolue. Menaces internes avec accès admin : un opérateur avec accès bastion, accès audit-log et l'intention soutenue de mésuser de ces privilèges est contraint par les audit logs, l'auth deux facteurs, la séparation de rôles et la frontière dedicated cluster par client — mais pas éliminé. L'embauche, les background checks et la visibilité audit-trail que les clients peuvent eux-mêmes reviewer sont les contrôles qui adressent ceci. Hygiène credentials côté client : si la clé privée WireGuard d'un client fuite parce que la workstation est compromise, l'attaquant a le même accès que le client ; l'opérateur peut détecter des patterns anormaux et désactiver le peer, mais ne peut pas empêcher la fuite.

L'architecture retire de larges catégories de risque et réduit d'autres à des niveaux gérables ; elle ne retire pas chaque catégorie, et toute représentation vendeur suggérant le contraire doit être examinée avec scepticisme.

Foire aux questions

Q: WireGuard est-il production-grade pour l'usage render farm enterprise ? A: WireGuard est dans le kernel Linux mainline depuis la version 5.6 (mars 2020), est utilisé en production par de grands opérateurs d'infrastructure et son protocole a été formellement vérifié avec le Tamarin prover. Les primitives cryptographiques (Curve25519, ChaCha20-Poly1305, BLAKE2s, Poly1305) sont des choix modernes peer-reviewed utilisés dans beaucoup de systèmes sensibles à la sécurité. Pour le transport render farm — tunnels longue durée, gros flux, petite surface opérationnelle — c'est le choix de production que nous opérons depuis des années sans incident au niveau protocole.

Q: Si notre vendeur render farm est compromis, mes données sont-elles exposées ? A: Sur un modèle multi-tenant, un compromise de l'infrastructure opérateur pourrait exposer des données auxquelles les systèmes opérateur ont accès, bornées par les contrôles d'isolation client ci-dessus. Sur le dedicated cluster avec customer-owned credentials, l'opérateur ne détient pas le matériel d'authentification client et les données du client vivent sur du matériel alloué au client — un compromise de l'infrastructure partagée de l'opérateur n'expose pas automatiquement les données dedicated-cluster parce que le dedicated cluster est une frontière séparée. Dedicated-plus-BYOC est la réponse pratique la plus forte pour les workloads à haute sensibilité IP.

Q: Pouvez-vous fournir des audit logs pour une compliance review ? A: Oui. Les logs de session SSH, handshake WireGuard, render-job et flux pare-feu peuvent être exportés sur demande pour l'auditeur du client, sous réserve de la période de rétention définie dans le contrat. Le format d'export est celui dont l'auditeur a besoin (le plus souvent CSV ou JSON). Nous ne fournissons pas d'accès read-write au log host lui-même ; le modèle d'export préserve l'intégrité de la trace d'audit tout en donnant au client les preuves nécessaires.

Q: Comment la destruction de données en fin d'engagement est-elle vérifiée ? A: La suppression au niveau fichier est suivie d'un écrasement de l'espace libre sur les périphériques de stockage concernés, puis d'une lettre d'attestation signée par l'opérateur enregistrant les périphériques dans le scope, la date et l'heure, la procédure et le personnel impliqué. Pour les engagements qui l'exigent, la destruction peut être témoignée par le représentant du client. L'attestation est l'artefact que le programme compliance du client classe comme preuve.

Q: Et les menaces internes de votre propre personnel ? A: La menace insider est mitigée par la séparation de rôles, l'authentification deux facteurs à la bastion, les audit logs que les comptes opérateur ne peuvent pas modifier et la frontière dedicated cluster par client. Elle n'est pas réduite à zéro, et nous le disons honnêtement. La review des audit logs par le client lui-même, sur demande, est l'un des contrôles les plus efficaces contre l'abus insider — elle met le client dans la boucle sur ce que le personnel opérateur a effectivement fait.

Q: Supportez-vous l'intégration SAML ou single sign-on ? A: Le SSO côté client est sur la roadmap interne et n'est pas une fonctionnalité généralement disponible aujourd'hui. Les clients qui ont besoin de SSO pour leurs propres raisons de compliance devraient le soulever lors du scoping de l'engagement ; certaines intégrations ont été faites par engagement, où le fournisseur d'identité du client peut être ponté à la couche d'auth du cluster via un chemin documenté.

Q: Mon auditeur SOC 2 ou ISO 27001 peut-il reviewer votre architecture ? A: Oui. Comme divulgué, nous ne sommes pas certifiés nous-mêmes, mais nous répondons aux questionnaires de vendor-review et aux demandes de review d'architecture des auditeurs clients. Les briques techniques décrites dans cet article sont les mêmes que l'auditeur verra dans nos réponses écrites ; les configurations sont auditables comme texte. Ce que nous ne pouvons pas fournir, c'est un document de certification propre, parce que nous n'en détenons pas actuellement.

Q: Quelle est votre couverture intrusion detection ? A: Le flow logging sur l'edge Tier-1 et le monitoring au niveau host sur chaque nœud sont déployés aujourd'hui. La network intrusion detection continue au niveau qu'un objectif SOC-2 « continuous monitoring » exigerait est sur la roadmap interne mais pas en production. Les clients dont le programme compliance exige un contrôle continuous-IDS devraient évaluer l'écart contre leur propre tolérance au risque.

Pour l'architecture réseau sur laquelle ce modèle de sécurité repose, voir notre deep-dive architecture render farm cross-country. Pour le modèle customer-owned-credentials qui s'apparie avec dedicated cluster, voir le writeup BYOC. Pour le déploiement opérationnel, voir notre guide render farm 20 nœuds GPU dédiée. Pour le framework de décision d'achat, voir la comparaison SaaS versus dedicated cluster et la landing dedicated GPU cluster rental.