Struct / Annexes - Review section sécurité / imputabilité

[jguihot]

Description du problème

Les aspects signature et imputabilité / sécurité sont à reviewer par l'équipe ANS dédiée

Fichier•s concerné•s

Page Architecture/Signature : Structure de l'archive de portabilité - Portabilité des Données LGC v0.1.0
Page Annexes/Sécurité : Sécurité - Portabilité des Données LGC v0.1.0

Solution proposée

[apocinho-kereval]

Premier retour en date du 20/08/2026

• Page Architecture/Signature : Structure de l'archive de portabilité - Portabilité des Données LGC v0.1.0

Partie de texte relue	Proposition/Suggestion de correction
"En fonction de sa politique de sécurité, un système cible peut choisir ou pas de les mettre en œuvre. Les référentiels de sécurité édités par l’ANS fournissent des recommandations sur ce sujet."	Proposition de correction: "Elles peuvent être adaptées si tout ou partie des éléments suivants le justifient : - Les réglementations applicables : RGPD, Cyber Resilience Act, PGSSI-S, NIS2, etc.) ; - L'analyse de risques réalisée sur le système cible."
Paragraphe 3.1.1.1 Confidentialité	Proposition : "Les données véhiculées dans le cadre de ce volet sont des données à caractère personnel contenant notamment des données médicales sensibles qu'il convient de protéger. À ce titre les données exportées doivent : - Être stockées avant transfert sur un environnement sécurisé, conforme HDS ; - Faire l'objet de chiffrement suivant des protocoles et algorithmes à l'état de l'art* ; - Être rendues accessibles uniquement aux personnes concernées grâce à la mise en œuvre d'une authentification forte. * L’ANSSI met à disposition le Référentiel Général de Sécurité et le guide des mécanismes cryptographiques qui précisent le cadre à suivre (protocoles et algorithmes de chiffrement sécurisés)"
"L'imputabilité du dépôt des documents est obtenue par une signature électronique de type XAdES utilisant un certificat de signature émis par une IGC autorisée par les référentiels d’authentification de la PGSSI-S."	Il ne faut pas pointer vers la PGSSI-S de mon point de vue (les référentiels d'authentification n'existent plus). Aujourd'hui le référentiel force probante de la PGSSI-S donne un cadre, toutefois il pointe vers l'IGC Santé en tant qu'Autorité de certification sectorielle pour la santé. L'inconvénient est que celle-ci ne fait pas partie de la Trusted list de l'ANSSI à ce jour et les signatures réalisées sur cette base ne sont donc pas reconnues par les applications et outils par défaut (absent des stores) ce qui peut être déroutant.
"[...]le système cible vérifie la signature et valide que le certificat utilisé pour la signature est un certificat émis par une IGC autorisée par les référentiels d’authentification de la PGSSI-S."	On peut éventuellement demander l'utilisation d'un certificat issu d'une AC qualifiée qui donnera de bonnes garanties de sécurité. Si trop restrictif on peut parler sinon d'AC de confiance (pour exclure les auto-signés par exemple).
Les éléments signés sont l'ensemble des hash des archives	La section signature indique que la signature couvre « l'ensemble des fichiers de données ». Il peut y avoir une confusion de notre point de vue sur ce qui est signé. Peut-être s'assurer que l'on est bien aligné de part et d'autre et que les éléments à signer sont clairement définis pour les éditeurs.

• Page Annexes/Sécurité : Sécurité - Portabilité des Données LGC v0.1.0

Partie de texte relue

Proposition/Suggestion de correction

`"Les fichiers à vocation documentaire (README, documentation technique, schémas, exemples, etc.) ne sont pas couverts par la signature électronique."

Le guide indique que les fichiers documentaires (documentation technique, schémas, exemples…) ne sont pas couverts par la signature électronique. Or le référentiel, dans son annexe 2, demande que l'intégrité de tous les répertoires soit vérifiable via un checksum. Il faudrait donc de notre point de vue préciser comment ces documents sont protégés contre une éventuelle altération (ou aligner le référentiel).