Périmètre réseau

Comment Scrydon limite le réseau — politique d'egress, terminaison d'ingress et périmètre du cluster.

Le modèle réseau de Scrydon repose sur un principe : le cluster client est la frontière de confiance. Tout ce qui se trouve à l'intérieur est appliqué par mTLS et des vérifications de capacité ; tout ce qui se trouve à l'extérieur est considéré comme non fiable.

Trafic entrant

Le trafic entrant se termine à Traefik. Trois classes de routes :

Classe de route	Authentifié comme	Où
Application côté utilisateur	Session utilisateur (SSO + Better Auth)	Éditeur de workflow, paramètres, chat, voix
API de workflow	Clé API (limitée au workflow)	`POST /api/workflows/{id}/execute`
Assets publics	Aucun	`/favicon.ico`, `/health` (liveness/readiness uniquement)

Il n'existe pas de points de terminaison publics exposant des données client. Le point de terminaison /health ne renvoie que la disponibilité de la plateforme — il ne divulgue pas la version, la configuration ni les données du tenant.

Voir Renforcement de l'ingress pour les règles de suppression d'en-têtes et de terminaison TLS.

Trafic sortant

Le trafic sortant se répartit en trois catégories :

Catégorie	Obligatoire ?	Où
Heartbeat de licence	Oui, pour le fonctionnement sous licence	`license.scrydon.com` — POST quotidien, fenêtre de grâce de 30 jours
Appels aux fournisseurs	Opt-in par intégration	Les points de terminaison déclarés par les intégrations installées (OpenAI, Microsoft Graph, etc.)

Rien d'autre ne quitte le cluster. Pas de télémétrie, pas de rapport d'erreurs à Scrydon, pas d'analytics anonymes. Les appels LLM de l'assistant IA (Chat/Cortex) sont acheminés en interne via le fournisseur configuré par l'organisation — ils font partie de la catégorie Appels aux fournisseurs ci-dessus, sans egress séparé hébergé par Scrydon. Si votre politique de sécurité requiert une liste d'autorisation d'egress strictement limitée, les deux points de terminaison ci-dessus plus ce que les intégrations installées déclarent constituent la liste complète.

Mode air-gap

Pour les déploiements vraiment isolés, vous pouvez :

Fonctionner hors ligne uniquement : ignorer le heartbeat de licence. Les opérations se poursuivent sous votre licence contractuelle ; le phone-home est désactivé.
Limiter les intégrations de fournisseurs aux seuls fournisseurs auto-hébergés. Aucun appel de fournisseur sortant ne se produit. Si aucun fournisseur LLM accessible n'est configuré, l'assistant IA (Chat/Cortex) n'a pas de modèle à appeler et sera indisponible ; le reste de la plateforme n'est pas affecté.

Voir Déploiement → Air-gap pour la procédure complète.

Liste d'autorisation d'egress

Pour les déploiements non air-gappés, la politique d'egress recommandée est :

ALLOW  license.scrydon.com:443                # required
ALLOW  <endpoints declared by installed integrations>
DENY   *                                       # everything else

Les appels LLM de l'assistant IA sont dirigés vers le fournisseur configuré par l'organisation (par ex. api.openai.com) et sont couverts par la ligne « intégrations installées » ci-dessus.

La plateforme n'effectue jamais d'appels sortants vers des destinations qui ne figurent pas dans cette liste. La liste est auditable depuis Paramètres → Plateforme → Extensions (chaque intégration installée liste ses points de terminaison d'egress déclarés).

Les points de terminaison d'egress déclarés d'un fournisseur font partie du manifeste d'intégration et sont validés à l'installation.

Domaines déclarés par l'intégration

Une intégration déclare dans son manifeste les destinations que ses outils contactent. Lorsque l'option Domaines déclarés par l'intégration est activée (valeur par défaut), ces destinations sont autorisées sans devoir également figurer dans votre liste d'autorisation : installer une intégration n'exige donc pas de découvrir au préalable les hôtes dont elle a besoin.

Les domaines déclarés sont affichés sur l'écran de configuration de l'intégration, au-dessus des champs d'identifiants, afin que vous voyiez ce que vous autorisez avant de connecter un compte.

Les limites qui s'appliquent toujours :

Un domaine présent sur votre liste de blocage reste bloqué. Un manifeste ne peut pas l'annuler.
Seuls les domaines déclarés sont autorisés ; tout le reste est refusé comme auparavant.
Les adresses privées, loopback, link-local et de métadonnées restent refusées.

Désactivez cette option si votre organisation exige que chaque destination soit explicitement approuvée. Vous listez alors vous-même les domaines de chaque intégration, et une intégration dont les domaines sont absents ne pourra pas les joindre.

Une intégration installée depuis un tiers déclare ses propres domaines. Avec cette option activée, l'installer autorise ces destinations. Examinez les domaines déclarés sur l'écran de configuration comme n'importe quelle autre permission.

Protection SSRF par outil

Les appels web-fetch et les appels sortants pilotés par des outils sont soumis à une vérification SSRF à l'exécution :

Les adresses RFC 1918 (privées) sont refusées.
Le link-local (169.254.0.0/16) est refusé.
L'IPv6 unique-local (fc00::/7) est refusé.
Le loopback est refusé.
Les noms d'hôtes internes au cluster (*.svc.cluster.local) sont refusés.

Cela s'applique à l'outil intégré fetch-webpage, au bloc API et à tout outil de fournisseur qui effectue une récupération sortante sur une entrée contrôlée par l'utilisateur. Les auteurs d'intégration ne peuvent pas contourner cette vérification ; la plateforme l'applique à chaque dispatch.

Voir aussi

Renforcement de l'ingress — le côté entrant de la frontière.
SPIFFE / mTLS — authentification du maillage interne.
Déploiement → Air-gap — mode déconnecté complet.