# 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

| Décision | Propriétaire | Ce que CRISalid apporte | Statut |
| --- | --- | --- | --- |
| Unités et personnes exclues au titre de la ZRR | **FSD** | Rien : aucune notion de ZRR | **À confirmer** : liste blanche d'unités à valider |
| Base légale, registre des traitements, analyse d'impact (AIPD), information des personnes, durée de conservation | **DPO** | Liens configurables vers les conditions d'utilisation et la politique de confidentialité | **À confirmer** |
| Champs publiables en vitrine | **Direction de la communication**, avec le DPO | Rien : aucun champ n'est qualifié public ou privé ; seul le masquage d'une structure existe | **À confirmer** ([matrice des champs](/01-cadrage-saclay/02-scenarios/03-extrait-et-comparatif-du-poc)) |
| Exposition réseau des services CRISalid et accès du service d'export | **DSI** (RSSI) | Une clé d'API unique ; pas de compte en lecture seule | **À confirmer** |
| Rôles attribués dans SoVisu+ et validation des corrections | **DiBISO** | Huit rôles, à portée réglable | **À confirmer** |
| Correctifs de sécurité à demander en amont | **DSI** avec l'équipe CRISalid | — | **À confirmer** |

> **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](/01-cadrage-saclay/02-scenarios/02-partie-2-contribution-chercheurs) part de ces limites. Une correction de publication peut en outre ne pas être reportée après une fusion ([provenance et fusion](/03-crisalid/01-donnees/provenance-qualite-fusion)).

## Données personnelles

| Catégorie | Où | Protection | Statut |
| --- | --- | --- | --- |
| Nom, prénom, rattachements, emploi | Graphe, base de SoVisu+, passerelle d'annuaire, moissonneur | En clair | **Confirmé** |
| Emails | **Base de SoVisu+ seulement**, pas le graphe | En clair | **Confirmé** |
| Identifiants (ORCID, IdRef, IdHAL, identifiant de connexion) | Graphe, base de SoVisu+ | En clair | **Confirmé** |
| Jetons d'accès ORCID | Base de SoVisu+ | **Chiffrés** (détail en fin de page) | **Confirmé** |
| Coauteurs externes (833 195 personnes au total sur l'instance, externes compris) | Graphe | En clair | **Observé sur instance (dev)** |
| Publications | Graphe, moissonneur | Données publiques | **Confirmé** |

La liste des stockages est dans [Stockages et schémas](/03-crisalid/01-donnees/stockages-et-schemas).

**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](/03-crisalid/01-donnees/contrats-api-evenements#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](/01-cadrage-saclay/02-scenarios/01-partie-1-vitrine-marque-blanche)).

**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).

| Rôle | Ce qu'il permet |
| --- | --- |
| Administrateur | Tout |
| Éditeur de publications | Corriger titre, résumé, auteurs, identifiants, type, sujets, date |
| Fusion | Fusionner des publications (la défusion n'existe pas) |
| Collecte | Lancer un moissonnage pour une personne |
| Éditeur de compte | Corriger ses propres identifiants |
| Dépôt HAL | Déposer dans HAL pour soi |
| Dépôt HAL pour un tiers | Déposer pour un autre chercheur, sans son mot de passe HAL |
| Gestion des structures | Masquer ou afficher une structure |

**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](/03-crisalid/01-donnees/contrats-api-evenements#apollo--schéma-généré-et-clé-dapi)).

**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.

<details>
<summary>Détail : le chiffrement des jetons ORCID</summary>

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.

</details>
