86 questions / réponses
86 questions / réponses
Les preuves sont analysées une fois que l'ensemble du chapitre est complet et soumis.
Cette réponse vous a-t-elle été utile ?
Ces exigences SC.SSI/IAM.91 et SC.SSI/IAM.92 définissent la manière dont le système doit tracer certaines opérations et gérer la robustesse des mots de passe administrateurs.
Avant, le système devait conserver les traces de l’ensemble des opérations mentionnées (SC.SSI/IAM.91) et permettre à la structure de santé de mettre en place une politique de mots de passe robuste s’il gérait des comptes d’administration dans sa base de compte propre (SC.SSI/IAM.92).
Maintenant, le système doit uniquement conserver les traces des opérations mentionnées qu’il gère localement (SC.SSI/IAM.91) et peut utiliser un MIE sans mot de passe s’il garantit un niveau de sécurité équivalent ou supérieur, par exemple une clé FIDO (SC.SSI/IAM.92).
Ce changement est lié au fait que la rédaction initiale de ces exigences ne prenait pas en compte des cas d’usage remontés durant la procédure de référencement.
Concrètement :
- Dans la nouvelle version de l'exigence SC.SSI/IAM.91 : possibilité pour chaque scénario de déposer un justificatif expliquant le fonctionnement de l’application et indiquant que l’action n’est pas gérée localement.
- Dans la nouvelle version de l'exigence version SC.SSI/IAM.92 : possibilité de montrer l’authentification au système d’un administrateur pour justifier de l’utilisation d’un MIE sans mot de passe (NB : les codes PIN sont proscrits).
A noter qu'il n'y a aucune obligation pour l'éditeur, il s’agit d’une prise en compte de cas d’usage existants.
Cette réponse vous a-t-elle été utile ?
La définition du périmètre des tests d’intrusion relève de la responsabilité de l’éditeur, en fonction des cas d’usage et de l’architecture de la solution. Le processus générique est le suivant :
- L'éditeur prend connaissance du périmètre du REM et candidate pour une solution dont il donne le nom et la version.
- L’éditeur a la responsabilité de présenter à l’auditeur le périmètre concerné par le test d’intrusion, en s’appuyant sur sa connaissance de la solution et en se portant garant de la justification apportée.
- L'auditeur doit mentionner dans le rapport de pentest le nom/version de l'application concernée.
- Le guichet conformité vérifie que le nom et la version de l’application concernée correspondent à ceux déclarés par l'éditeur, et que le rapport est conforme aux exigences.
Cette réponse vous a-t-elle été utile ?
Après certification, le CNDA remet à l’éditeur :
- L'attestation de conformité ;
- La lettre de référencement.
L’éditeur utilise ensuite l’attestation de conformité comme preuve de certification auprès de l’ANS.
Vous trouverez ci-dessous un exemple d'attestation de conformité :
Cette réponse vous a-t-elle été utile ?
Le contenu des traces fonctionnelles attendues est défini par l’exigence SC.MSS/CONF.18.
L’objectif est de permettre un suivi des actions significatives réalisées sur les boîtes aux lettres MSSanté, sans conserver l’intégralité des échanges IMAP/SMTP ni le contenu des messages.
Ainsi, pour chaque boîte aux lettres, il est attendu a minima que les traces permettent de connaître :
- l’identifiant de l’auteur de l’action, dûment authentifié ;
- l’horodatage local du poste au moment de l’action ;
- le type d’action réalisée (consultation, envoi, suppression, etc.) ;
- la demande effectuée sur le serveur de messagerie MSSanté ;
- la réponse fournie par le serveur (y compris en cas d’échec).
Le contenu des messages ne doit en aucun cas être tracé. Le choix du niveau de détail des traces et des traitements suivis est laissé à l’appréciation de l’éditeur, dans la mesure où ces traces visent avant tout à le protéger, notamment en cas de requête judiciaire ou d’incident de sécurité. Il est toutefois attendu a minima que les actions d’envoi et de suppression de messages soient tracées.
Concernant la durée de conservation :
- Comme indiqué au §5 du référentiel #2 MSSanté, une durée de conservation de 6 mois est recommandée pour ces traces fonctionnelles.
- Le responsable de traitement (LPS) reste libre de définir la durée exacte de conservation, en fonction de son analyse de risques et de son cadre réglementaire.
- Les traces doivent être soumises aux mêmes mesures de sécurité et de confidentialité que les données MSSanté auxquelles elles se rattachent (mesures organisationnelles, techniques, etc.).
Cette réponse vous a-t-elle été utile ?
Le CIBA est prévu dans la vague 2 du Ségur en tant que profil optionnel. En cas de client lourd, l'éditeur doit proposer les deux solutions (code flow et CIBA) => SC.PSC.01 et SC.PSC.13. Le profil est obligatoire lorsque l’éditeur a choisi d’implémenter dans sa solution logicielle l’authentification ProSanté Connect par le protocole CIBA (§3.1 du DSR DPI).
Cette réponse vous a-t-elle été utile ?
Il n'entre pas dans le rôle de la PFI de générer les documents, d'en contrôler le contenu, ou de les modifier, mais bien de les transmettre.
Cette réponse vous a-t-elle été utile ?
Les durées de conservation sont une responsabilité du responsable de traitement.
En tant qu'éditeur, vos logiciels doivent être capables de gérer deux durées de conservation distinctes :
- Les traces techniques (ex. logs d'erreurs, événements système) pour le support et la maintenance du logiciel, conservées sur une courte période de 6 mois à 1 an (recommandations CNIL).
- Les traces applicatives (ex. journaux d'accès aux dossiers patients) pour des raisons légales et de traçabilité, conservées sur une longue période de 20 ans, conformément à la durée de conservation des dossiers médicaux (article R.1112-7 du code de la santé publique).
Ces traces constituent des données à caractère personnel et il faut donc prévoir des mesures de sécurité adaptées à cette longue durée de conservation, ainsi qu’une information adaptée (par exemple, via les conditions générales d'utilisation (CGU) ou la politique de confidentialité) du responsable de traitement, voire une capacité d’adaptation des durées par ce dernier.
Cette réponse vous a-t-elle été utile ?
Oui, il doit être possible d'envoyer le courriel MDN à une ou plusieurs BAL organisationnelles ou personnelles en fonction de la BAL destinataire du mail initial.
Cette réponse vous a-t-elle été utile ?
Non, cela n'est pas interdit. Toutefois dans le cadre des échanges automatisés décrits dans les exigences, seuls sont concernés les CDA.
Cette réponse vous a-t-elle été utile ?