Sécurité
Défense en profondeur sur les permissions, les secrets, l'audit, le réseau, l'ingress et le DLP — chaque couche documentée séparément pour être évaluée sur ses propres mérites.
Scrydon est conçu pour les organisations qui doivent défendre leurs données, pas seulement utiliser l'IA sur celles-ci. La sécurité chez Scrydon est en couches — chaque contrôle est appliqué en au moins deux endroits, et une défaillance dans une couche ne compromet pas les autres.
Cette section documente les contrôles de sécurité que les clients peuvent examiner, auditer et sur lesquels ils peuvent s'appuyer.
Défense en profondeur
Chaque requête externe franchit cinq portes avant d'atteindre un service. Chaque opération privilégiée, à chaque couche, est envoyée au journal d'audit.
| Couche | En savoir plus |
|---|---|
| Durcissement de l'ingress — supprime les en-têtes d'identité falsifiés | Durcissement de l'ingress |
| Autorisation — point de décision de politique unique sur les plans applicatif et données | Modèle de permissions, Autorisation |
| Maillage de services — tous les appels inter-services mutuellement authentifiés ; pas de tokens porteurs partagés | SPIFFE / mTLS, Frontière réseau |
| Secrets — chiffrement des identifiants au repos, occultation dans les journaux, accès limité aux utilisateurs approuvés | Gestion des secrets |
| DLP — sorties analysées pour PII, hallucination, filtres regex / JSON | Prévention des fuites de données |
| Audit — immuable, interrogeable, avec le contexte complet acteur + IP | Journal d'audit |
Par où commencer
Modèle de permissions
La hiérarchie à trois niveaux : rôles d'organisation, appartenance aux espaces de travail et droits basés sur les équipes.
Gestion des secrets
Les trois stratégies de gestion des identifiants — LOCAL, BYOK, HYOK — et l'usage adapté à chacune.
Journal d'audit
Ce qui est journalisé, ce qui est occulté, comment interroger et combien de temps cela est conservé.
Prévention des fuites de données
Le moteur de garde-fous — détection de PII, vérification des hallucinations, regex, validation JSON.
Preuves de conformité
Chaque contrôle de cette page correspond à une exigence de framework. Si vous vous préparez pour un audit ISO 27001 / ISO 42001 / EU AI Act / SOC 2 / SecNumCloud / GDPR / NIST / CRA / AIUC-1, consultez Conformité — chaque page de framework renvoie aux contrôles de sécurité qui satisfont ses exigences.
Valeurs de durcissement par défaut
La plateforme est livrée en mode fermé par défaut :
- Les requêtes inter-services sans identité mTLS valide sont refusées.
- Les contrôles d'autorisation qui ne trouvent pas de ressource retournent « refuser », pas « autoriser ».
- Les lectures de secrets sans droit valide échouent ; il n'existe pas de fallback vers les variables d'environnement.
- Les requêtes d'ingress portant des en-têtes d'identité internes sont nettoyées avant que la requête n'atteigne un service.
- Les workflows s'exécutent sous un droit d'exécution émis côté serveur, jamais sous une identité passée dans le payload.
Vous n'avez pas à activer la défense en profondeur. Elle est activée. La surface de configuration vous permet d'élever individuellement des contrôles (ex. passer de LOCAL à BYOK, resserrer l'égress, augmenter la rétention du journal d'audit) — jamais de les abaisser en dessous de la ligne de base.