Copy page

Fonctionnement transversal

Sécurité, droits et données personnelles

En bref : CRISalid ne connaît ni la ZRR ni la notion de champ public : tout le filtrage doit se faire à l'export, par des listes blanches validées par le FSD, le DPO et la communication. Aujourd'hui, un chercheur corrige dans SoVisu+ ses publications (titre, résumé, type, sujets, auteurs, fusion), mais sur sa fiche, seulement ses identifiants : ni son nom ni ses rattachements. C'est la limite de départ de la Partie 2. Trois défauts de sécurité sont confirmés dans le code ; aucun accès en lecture seule n'existe pour un service d'export.

Cette page fait foi pour la ZRR, les données personnelles, les droits, la clé de l'API Apollo et les défauts de sécurité du code. Le détail technique des défauts est réservé à l'équipe CRISalid.

Les décisions et leur propriétaire

Ce qu'un chercheur peut corriger aujourd'hui

Statut : Confirmé dans le code de SoVisu+ et du graphe.

• Sur sa fiche personne : seulement ses identifiants (ORCID, IdRef, IdHAL…). Ni son nom, ni ses rattachements : ils viennent de l'annuaire, et aucune correction ne remonte vers l'annuaire.
• Sur ses publications : titre, résumé, type, sujets, auteurs, et la fusion de doublons. Le graphe applique ces corrections envoyées par SoVisu+.
• La date de publication : corrigeable dans SoVisu+, mais le graphe ne traite pas cette correction ; elle ne lui parvient pas.

Ces corrections supposent que l'établissement attribue les rôles correspondants (voir plus bas). La Partie 2 part de ces limites. Une correction de publication peut en outre ne pas être reportée après une fusion (provenance et fusion).

Données personnelles

La liste des stockages est dans Stockages et schémas.

Base légale. La mission d'intérêt public de l'établissement (article 6.1.e du RGPD) est envisageable, mais non acquise : le DPO doit la confirmer, l'inscrire au registre et dire si une analyse d'impact est requise pour une publication nominative à grande échelle. Aucune AIPD connue : À confirmer.

Droits des personnes.

• Information : SoVisu+ prévoit des liens configurables vers les conditions d'utilisation, la politique de confidentialité et un contact support. Confirmé.
• Rectification : voir l'encadré ci-dessus. Les corrections ne sont pas renvoyées vers l'annuaire ; un nouveau chargement de l'annuaire peut les écraser. Confirmé pour l'absence de renvoi ; écrasement À confirmer.
• Effacement et opposition : non outillés de bout en bout, car les suppressions ne sont pas propagées (suppressions non propagées). Aucune purge des personnes parties n'est fournie. Confirmé.

ZRR : CRISalid n'en a aucune notion

Statut : Confirmé (lecture des 21 dépôts).

• Aucune référence à la ZRR ou à la protection du potentiel scientifique dans le code, les schémas ou les règles de traitement.
• Aucun attribut ne qualifie la sensibilité d'une structure.
• Le moissonneur collecte les publications de tout chercheur rattaché, sans distinction.

Risques : publier la liste des personnels d'une unité sensible, ce qui facilite le ciblage ; agréger publiquement des travaux qui ne devraient pas l'être sous le nom de cette unité.

Règle : un seul point de filtrage, à l'export, par une liste blanche d'unités et de personnes validée par le FSD, avant la première génération et à chaque changement de périmètre. Une unité absente de la liste n'apparaît pas, ni ses membres, ni leurs publications rattachées à cette unité. Retirer une unité de l'annuaire en amont ne suffit pas : une publication moissonnée peut la citer. Le POC exclut les unités ZRR : Projection Saclay (Partie 1).

Cadre réglementaire : dispositif de protection du potentiel scientifique et technique de la Nation (articles R. 413-1 et suivants du code pénal, instruction interministérielle n° 3410/SGDSN) ; accès à une ZRR soumis à autorisation, après avis du FSD. À confirmer par le FSD.

Droits et accès dans CRISalid

Connexion. On se connecte à SoVisu+ par le service d'authentification de la suite (Keycloak), qui s'appuie sur l'annuaire de l'établissement ou sur ORCID. La session dure 12 heures par défaut, réglable entre 1 heure et 7 jours. Statut : Confirmé dans le code ; configuration de l'instance À confirmer.

Rôles. SoVisu+ définit huit rôles. Chacun s'applique à une portée : tout l'établissement, un ensemble de structures, ou la seule fiche de la personne connectée. Statut : Confirmé (exemple de configuration).

API Apollo. Une clé d'API unique ouvre les 60 requêtes et les 60 mutations du schéma : pas d'accès en lecture seule, pas de filtrage des champs. Statut : Confirmé par test local (détail).

Neo4j. L'édition Community ne permet pas de compte en lecture seule restreint. Statut : Confirmé (configuration par défaut) et Observé sur instance (dev).

Défauts de sécurité confirmés dans le code

Statut : Confirmé. Trois défauts de sécurité dans le code, signalés à l'équipe CRISalid ; le détail lui est réservé. L'un d'eux est la clé d'API unique d'Apollo décrite plus haut, qui conditionne l'architecture de l'export.

À cela s'ajoute, dans le déploiement de référence, une gestion des secrets à durcir. Statut : Confirmé pour le déploiement de référence ; pratique sur l'instance À confirmer.

L'exposition réseau de l'instance n'est pas décrite sur ce site public : elle relève de la DSI et du responsable de l'instance.

Recommandations pour la vitrine

1. La vitrine lit l'export, jamais Apollo. Apollo n'est pas exposé hors du réseau interne.
2. Accès du service d'export : faute de compte en lecture seule, requêtes figées, compte dédié et réseau isolé ; ou édition Enterprise de Neo4j, ou clé Apollo en lecture seule développée en amont, à chiffrer.
3. Liste blanche de champs : aucun email, aucun identifiant technique, aucun jeton ; seuls des identifiants publics (ORCID, IdRef, IdHAL) selon la matrice des champs.
4. Liste blanche d'unités validée par le FSD, et analyse d'impact validée par le DPO avant l'ouverture publique.
5. Correctifs en amont des trois défauts ci-dessus avant toute mise en production de SoVisu+ pour la Partie 2.

Détail : le chiffrement des jetons ORCID

Statut : Confirmé dans le code de SoVisu+.

• Algorithme : AES-256-GCM, chiffrement authentifié, vecteur d'initialisation de 12 octets, étiquette d'authentification de 16 octets.
• Chaque valeur chiffrée porte une version de format et l'identifiant de la clé utilisée.
• Les clés forment un trousseau versionné avec une clé active, ce qui permet la rotation sans interruption.
• Périmètre : seuls les jetons d'accès ORCID sont chiffrés. Noms, rattachements et publications sont en clair, dans la base de SoVisu+ comme dans le graphe ; les emails, absents du graphe, sont en clair dans la base de SoVisu+.
• Limite : dans le déploiement de référence, la clé réside sur le même serveur que la base. Un attaquant qui compromet le serveur obtient les deux.