LECTURE SEULE
Les interactions non mutatives sont privilégiées et toute exception doit être explicite.
CONNECTEURS & SDK
Étendre la couverture.
Sans perdre le contrôle.
Les connecteurs SafeNetis privilégient la lecture seule. Une approche manifest-first décrit leur portée, leurs données et leurs exigences avant leur activation locale.
CONNECTEURS & SDK
LE PROBLÈME
Étendre la couverture sans transformer l’intégration en zone de confiance implicite.
Un connecteur accède à des systèmes sensibles et influence la représentation que la plateforme construit. Son comportement, ses permissions et sa compatibilité doivent donc être décrits et contrôlés avant toute activation.
SafeNetis adopte une approche vendor-neutral : la valeur d’une intégration vient des capacités et des preuves qu’elle apporte, pas du logo de son fabricant.
Inspecter, approuver et isoler chaque package avant son utilisation locale.
FONCTIONNEMENT
Un cycle local, déclaratif et contrôlé pour chaque package.
Les connecteurs privilégient la lecture seule. Un manifeste déclaratif et un contrat de capacités exposent données, permissions, limites et exigences. Les packages locaux passent par quarantaine, contrôles de compatibilité et approbation avant d’être confiés à des workers isolés. Une marketplace locale hors ligne permet de gouverner ce catalogue sans dépendre d’un service externe.
→
CONTRAT DE CAPACITÉS
Le package déclare précisément ce qu’il sait lire, produire et exiger.
MANIFESTE DÉCLARATIF
Identité, version, permissions, schémas et compatibilités sont décrits avant exécution.
PACKAGE LOCAL CONTRÔLÉ
Le code et ses dépendances sont distribués dans un artefact versionné et gouvernable.
QUARANTAINE & APPROBATION
Un package entrant reste inactif jusqu’aux contrôles et à l’autorisation locale.
COMPATIBILITÉ & READINESS
La préparation au déploiement est évaluée contre EdgeOS, les politiques et la cible annoncée.
WORKER ISOLÉ
L’exécution est séparée pour limiter le périmètre d’un défaut ou d’un comportement inattendu.
MARKETPLACE HORS LIGNE
Le site administre localement les packages autorisés, leurs versions et leur statut de maturité.
CONNECTOR ECOSYSTEM
Un catalogue gouverné.
Pas une collection de logos.
Chaque entrée décrit une capacité, un mode d’exécution et un niveau de préparation. Aucun statut ne vaut qualification production sans validation adaptée.
08 ENTRÉES AFFICHÉESSTATUTS DE MATURITÉ EXPLICITES
01 · SÉCURITÉ PHYSIQUEDISPONIBLE EN LABORATOIRE
ONVIF Discovery Reader
READ-ONLYDécouverte et lecture de métadonnées exposées dans un environnement contrôlé.
Aucune conformité ONVIF officielle n’est revendiquée.
02 · SÉCURITÉ PHYSIQUEPLANNED
Access Event Contract
CAPABILITY CONTRACTModèle déclaratif pour événements d’accès, contrôleurs, lecteurs et zones.
Direction produit, sans disponibilité annoncée.
03 · INFRASTRUCTUREEMULATOR-READY
CPS Asset Stream Emulator
LOCAL PACKAGEFlux simulé d’actifs, relations et observations pour tester le parcours de données.
Une émulation ne remplace pas une validation matérielle.
04 · OT / ICSVALIDATION MATÉRIELLE REQUISE
Modbus/TCP Evidence Profile
READ-ONLY TARGETProfil d’observation prudent pour registres et identités d’équipements autorisés.
À qualifier sur matériel, firmware et configuration cibles.
05 · OT / ICSPLANNED
OPC UA Observation Profile
MANIFESTContrat envisagé pour exposer identités, hiérarchies et observations qualifiées.
Aucune compatibilité production n’est revendiquée.
06 · IT / CYBERPLANNED
SNMP Infrastructure Reader
READ-ONLY TARGETCollecte envisagée de preuves d’identité et de topologie réseau autorisées.
Nécessite une validation séparée par équipement.
07 · INFRASTRUCTUREPLANNED
Inventory Package
DECLARATIVE IMPORTImport gouverné d’inventaires déclarés avec provenance et date de référence.
Un inventaire importé reste une déclaration, pas une observation.
08 · PROTOCOLESDISPONIBLE EN LABORATOIRE
Connector Manifest Schema
CAPABILITY CONTRACTSchéma décrivant capacités, permissions, dépendances et données produites.
Démontré dans le laboratoire contrôlé SafeNetis.
Vous avez une source à qualifier ? Commencez par son contrat de capacités, ses permissions et le matériel cible.
Évaluer un connecteur →BÉNÉFICES OPÉRATIONNELS
Une capacité conçue pour
améliorer la compréhension.
Contrôle local
L’organisation décide quels packages peuvent être installés et activés.
Compatibilité lisible
Les prérequis et limites sont connus avant le déploiement.
Réduction du périmètre
Lecture seule et isolation des workers limitent les interactions et les conséquences possibles.
Neutralité fournisseur
Le même contrat de capacités structure des intégrations issues d’écosystèmes différents.
LIMITES ACTUELLES
Ce que cette capacité ne prétend pas faire.
La transparence sur les limites fait partie de l’architecture de confiance SafeNetis.
- 01Aucune intégration matérielle non validée n’est présentée comme disponible en production.
- 02Emulator-ready signifie qu’un parcours peut être préparé avec un émulateur ; cela ne remplace pas une validation sur le matériel cible.
- 03La lecture seule dépend des capacités réellement offertes par le système source et doit être vérifiée.
- 04Compatibilité déclarée, approbation locale et readiness ne constituent pas à elles seules une qualification de production.
PROCHAINE ÉTAPE
