P.S.S.

I
Infrastructure Cloud
Politique de sécurité des Systèmes d’information

CAP-TEL
174, ALLEE DE RIOTTIER – 69400 LIMAS
RCS 490836574 Villefranche Tarare

1
Préambule .......................................................................................................................................4
1 Gestion de la PSSI..................................................................................................................5
2 Organisation de la sécurité du SI............................................................................................5
2.1 Le responsable de la sécurité du SI (RSSI) .......................................................................5
2.2 Coordination de la sécurité du SI ...................................................................................6
2.3 Correspondant informatique et libertés (CIL) .................................................................6
2.4 Prise en compte de la sécurité en interne.......................................................................6
2.5 Organisation relative aux tiers .......................................................................................7
3 Classification des biens et des ressources du SI .......................................................................8
4 Sécurité physique et environnementale .................................................................................8
4.1 Protection des zones sensibles ......................................................................................8
4.1.1 OVH Certifications concernant la sécurité ....................................................................................... 8
4.1.2 OVH Datacenter(s) ........................................................................................................................... 9
4.2 Sécurité des matériels hors des locaux de la société ..................................................... 10
5 Gestion de l’exploitation informatique et des réseaux .......................................................... 11
5.1 Organisation et procédures d’exploitation ................................................................... 11
5.2 Exploitation sous-traitée ............................................................................................. 11
5.3 Mise en production ..................................................................................................... 11
5.4 Virus, codes malveillants et vulnérabilités ................................................................... 12
5.5 Sauvegarde ................................................................................................................. 12
5.6 Sécurité du réseau ...................................................................................................... 12
5.7 Sécurité des systèmes ................................................................................................. 14
5.8 Protection des fichiers ................................................................................................. 14
6 Contrôle d’accès logique...................................................................................................... 15
6.1 Enregistrement des utilisateurs et droits d’accès.......................................................... 15
6.2 Mots de passe ............................................................................................................. 15
6.3 Matériel laissé sans surveillance .................................................................................. 15
7 Sécurité liée aux projets et aux applications ......................................................................... 16
8 Gestion des incidents de sécurité ......................................................................................... 16
9 Continuité d’activité et continuité du SI................................................................................ 17
10 Conformité.......................................................................................................................... 17
10.1 Exigences légales et réglementaires ............................................................................. 17
10.2 Conformité technique et respect de la PSSI .................................................................. 17
11 Actifs du SI .......................................................................................................................... 18

11.1 Tableau ...................................................................................................................... 18

11.2 Référentiel.................................................................................................................. 19

2
Préambule
La sécurité des systèmes d’information (SSI) est l’ensemble des moyens techniques, organisationnels,
juridiques et humains nécessaires pour garantir la sécurité de l'information.
La sécurité de l’information est un facteur essentiel de confiance pour les acteurs internes et externes
de l’établissement et en particulier pour les professionnels de santé et pour les patients vis-à-vis de
leurs données de santé.
La sécurité de l’information peut s'évaluer suivant plusieurs critères :
• Disponibilité : garantit que les éléments considérés (équipements, applications, documents et
bases de données…) sont accessibles au moment voulu par les personnes autorisées.

• Intégrité : garantit que les éléments considérés sont exacts et complets.

• Confidentialité : garantit que seules les personnes autorisées ont accès aux éléments
considérés.

• Auditabilité (ou traçabilité ou imputabilité) : garantit la traçabilité des actions réalisées sur le
SI et la conservation des preuves.

La présente Politique de Sécurité du Système d’Information (PSSI) a pour but de définir les principes
et les règles garantissant le respect de ces critères de sécurité par la protection des biens et des
informations sensibles. Elle constitue une référence par rapport à laquelle toute évolution du système
d'information devra être justifiée, que ce soit pour l'intégration d'un élément nouveau du système ou
pour la modification d'un élément existant.
La PSSI s’adresse à l’ensemble des utilisateurs internes du SI ainsi qu’à toute personne ou organisme
extérieur (partenaire, prestataire…) susceptible de se connecter, d’utiliser ou d’intervenir sur le SI de
l’établissement.

3
1 Gestion de la PSSI
La PSSI est rédigée par le responsable de la sécurité du SI (RSSI) et approuvée par le dirigeant de la
société.
Cette PSSI est complétée :
- De procédures de gestion dont la liste figure en annexe, et en particulier d’une procédure
de gestion des droits d’accès,
- D’un plan de reprise informatique (PRI) intégré au plan de continuité d’activité de
l’établissement.

La PSSI est révisée une fois tous les 2 ans au moins et en cas de modification majeure du SI ayant un
impact significatif sur la sécurité de l’information. Ces révisions sont proposées par le RSSI et validées
par la direction.

2 Organisation de la sécurité du SI

Les rôles et responsabilités en matière de sécurité du SI sont résumés dans le tableau de l’annexe A.4.

2.1 Le responsable de la sécurité du SI (RSSI)

La fonction de responsable de sécurité du SI est confiée à Monsieur Guillaume Pouilly, Président de la

SAS CYD Solutions

Ses rôles et responsabilités dans le cadre de la sécurité du SI recouvrent :

- Le maintien du référentiel des actifs du SI et de leur niveau de criticité, tel que présenté en
annexe,
- La rédaction et la mise à jour de la charte d’utilisation du SI,
- L’animation de la sensibilisation interne relative à la sécurité du SI et au bon usage des
moyens informatiques,
- La prise en compte des règles de la PSSI par les prestataires,
- L’élaboration du plan de reprise informatique et des procédures concernant la sécurité du
SI,
- La mise en œuvre des projets et des plans d’amélioration concernant la sécurité du SI,
- La définition du plan d’évaluation de la PSSI (audits, enquêtes, indicateurs…) et le suivi de ce
plan,
- La coordination des actions à mener en cas d’incident de sécurité ou de sinistre majeur
affectant le SI,

- La veille permanente concernant les thématiques liées à la sécurité du SI (nouvelles menaces,

nouvelle réglementation, nouvelles technologies…),
- La proposition de modifications de la PSSI à la direction.

4
2.2 Coordination de la sécurité du SI

L’instance chargée de piloter les projets et la sécurité du SI est le CODIR SECURITE, auquel participent
la direction et les différents partenaires informatiques de la société.
Cette instance :
- Analyse les résultats de l’évaluation de la PSSI et les incidents de sécurité,
- Propose des projets et plans d’amélioration à conduire par le RSSI et en supervise la mise en
œuvre, y compris les actions de sensibilisation et de formation,
- Revoit la PSSI et ses modifications, ainsi que la charte d’utilisation du SI et le plan de reprise
informatique, avant approbation par la direction.

Elle se réunit une fois par an au moins et en cas de besoin.

2.3 Correspondant informatique et libertés (CIL)

La fonction de correspondant informatique et libertés (CIL) est confiée à Monsieur François BERTOTTO,
Gérant de CAP-TEL.

Le CIL est chargé :

- Des relations avec la CNIL pour toute demande d’information, d’avis ou d’autorisation,
- De tenir à jour le registre des traitements de données nominatives, informatisées ou non,
- De participer à la sensibilisation interne relative au traitement des données nominatives.

2.4 Prise en compte de la sécurité en interne

Tout personnel de l’établissement, qu’il soit permanent, intérimaire ou stagiaire, doit :

- Prendre connaissance et signer la charte d’utilisation du SI,
- Se conformer aux règles définies dans cette charte,
- Signaler au RSSI tout événement ou incident susceptible de mettre en péril la sécurité de
l’information ou de contrevenir aux règles de la PSSI.

5
2.5 Organisation relative aux tiers

Les relations avec les tiers susceptibles d’accéder au SI ou d’échanger des informations avec
l’établissement font l’objet de règles écrites en matière de sécurité de l’information.
Ces relations peuvent concerner :
- Les partenaires hébergeurs (OVH, AWS)
- Les partenaires Éditeurs (Nixxis),
- Les prestataires, qui dans le cadre dans leur mission, doivent accéder au SI,
- Les clients.

Ces règles de sécurité sont formalisées dans le cadre de contrats, conventions ou chartes. Elles
imposent à minima l’utilisation de comptes nominatifs et de mots de passe respectant les
recommandations de la CNIL, des droits d’accès limités, et, pour les échanges d’informations de
santé, l’utilisation d’une messagerie sécurisée.
Les fournisseurs informatiques susceptibles d’accéder aux locaux techniques et aux équipements
informatiques et réseau doivent par ailleurs suivre les règles suivantes :

- Toute opération sur le SI doit donner lieu à une autorisation préalable de CAP-TEL et à un
compte-rendu précis (détail des actions, compte rendu des tests…),
- Tout accès distant au SI de CAP-TEL se fait via une connexion sécurisée.

Tout contrat avec un hébergeur doit prévoir les clauses prévues au décret et en particulier un plan de
continuité et une clause de réversibilité.

6
3 Classification des biens et des ressources du SI
Le RSSI tient à jour un inventaire des types de biens ou « actifs » (applications, bases de données,
répertoires bureautiques…) et des services essentiels (accès internet, réseau, etc.) composant le SI de
l’établissement.

A chaque actif sont associés des critères de disponibilité, d’intégrité et de confidentialité, dont la
combinaison détermine un niveau de criticité qui est exploité pour définir les mesures de sécurité et
les actions d’amélioration.

Le référentiel des actifs et de leur criticité figure en annexe de la présente PSSI.

4 Sécurité physique et environnementale

4.1 Protection des zones sensibles

Sont considérés comme des zones sensibles :

• Les locaux techniques dans lequel sont installés les serveurs et équipements réseau,
• Les locaux techniques abritant les baies de brassage et les passages de câbles,
• Les locaux techniques abritant les baies de stockage,

Ces locaux, sont tous situés chez OVH, CAP-TEL n’héberge aucun serveur et aucun élément de
stockage de données client dans ses locaux. CAP-TEL s’appuie sur les moyens certifiés de son
partenaire hébergeur pour garantir la sécurité physique des serveurs et stockages impliqués dans
son infrastructure cloud.

4.1.1 OVH Certifications concernant la sécurité

Depuis le 19 mars 2019, OVH Cloud a obtenu la certification ISO/IEC 27001 : 2013

ISO / CEI 27001 est une norme internationale qui décrit les « exigences pour l'établissement, la mise en
œuvre, le maintien et l'amélioration continue d'un système de gestion de la sécurité de l’information »
(SMSI). Il décrit la méthode d'organisation qui assure la confidentialité, l'intégrité, la disponibilité et la
traçabilité d'un système d'information.

OVH Cloud a reçu la certification PCI-DSS

La certification PCI DSS (Payment Card Industry Data Security Standard) niveau 1 assure aux
organismes bancaires et aux utilisateurs de services en ligne un haut niveau de sécurité. Les acteurs
manipulant ces données confidentielles répondent à des exigences de sécurité spécifiques définies par
cette certification. Le référentiel est édité et maintenu par le PCI Council, un groupement professionnel
de fournisseurs de cartes de paiement dont font partie Visa, Mastercard, American Express, JCB et
Discovery. Ce standard de sécurité est l'un des plus exigeants en matière de protection de la
confidentialité de l'information.

7
OVH Cloud a reçu l’attestation SOC 1 TYPE II

SOC1 type I (SSAE 16 ISAE 3402) garantit que les objectifs de contrôle sont définis de manière
appropriée et que les contrôles établis pour protéger les données des clients sont mis en place.

OVH Cloud a reçu l’attestation SOC 2 TYPE II

Le rapport SOC 2 type I évalue les contrôles par rapport à la norme internationale établie par
l'AICPA (American Institute of Certified Public Accountants) dans ses principes sur les services de
confiance (« Trust Services Principles »)

OVH Cloud a reçu l’agreement HDS, pour l’hébergement des données de santé.

4.1.2 OVH Datacenter(s)

CAP-TEL utilise dans le cadre de son infrastructure Cloud essentiellement les Datacenters de :
- Roubaix (FR)
o Les Datacenter de Roubaix (OVH: RBX-1 à OVH: RBX -7) est situé dans le nord dans la
France en proximité de la ville de roubaix (59820).
Les certifications des datacenters sont :
▪ ISO 27001
▪ ISAE-3402
▪ SSAE-16 Type 1
▪ SOC 2 Type 2
▪ PCI-DSS
o Les Datacenters de Gravelines sont protégés pour l’accès physique :
▪ Contrôle d’accès, ne laissant l’accès aux serveurs, uniquement au personnel
OVH autorisé.
▪ Vidéosurveillance 24h/24 et 7j/7
▪ Détection incendie dans chaque salle
▪ Présence de techniciens sur site 24/7
o Les Datacenters de Gravelines sont protégés pour leur adduction électrique par :
▪ Double alimentation systématique
▪ 250 KVA par onduleur
▪ Générateurs avec autonomie initiale de 48h

8
 - Gravelines (FR)
o Les Datacenter de Gravelines (OVH : GRA-1 et OVH : GRA-2) est situé dans le
nord dans la France en proximité de la ville de Gravelines (59820).
Les certifications des datacenters sont :
▪ ISO 27001
▪ ISAE-3402
▪ SSAE-16 Type 1
▪ SOC 2 Type 2
▪ PCI-DSS
o Les Datacenters de Gravelines sont protégés pour l’accès physique :
▪ Contrôle d’accès, ne laissant l’accès aux serveurs, uniquement au personnel
OVH autorisé.
▪ Vidéosurveillance 24h/24 et 7j/7
▪ Détection incendie dans chaque salle
▪ Présence de techniciens sur site 24/7
o Les Datacenters de Gravelines sont protégés pour leur adduction électrique par :
▪ Double alimentation systématique
▪ 250 KVA par onduleur
▪ Générateurs avec autonomie initiale de 48h

4.2 Sécurité des matériels hors des locaux de la société

La charte d’utilisation du SI décrit les précautions à prendre lors du déplacement d’un matériel et lors
de l’utilisation d’équipements mobiles.
Lors de la mise au rebut d’un équipement ayant stocké des données confidentielles, il doit être procédé
soit à l’effacement des données ou au retrait du disque dur, soit à la remise de cet équipement à un
prestataire en mesure de garantir une destruction sécurisée des données et de la tracer.

9
5 Gestion de l’exploitation informatique et des réseaux

5.1 Organisation et procédures d’exploitation

L’exploitation de l’infrastructure Cloud et des réseaux associés est opérée par le personnel de la société
CYD Solutions.

L’exploitation recouvre les activités suivantes :

- Installation des nouvelles versions des logiciels système et des applications,
- Configuration système et réseau (notamment en ce qui concerne la sécurité) et mise à jour
des composants de sécurité (firewall, anti-virus, patch système),
- Création des comptes utilisateurs et administrateurs,
- Surveillance des systèmes, du réseau et des applications,
- Traitement des alarmes et incidents issus de la surveillance ou signalés par des utilisateurs,
- Déclenchement des opérations de maintenance préventive,
- Réalisation des sauvegardes et des restaurations,
- Détermination des évolutions de capacité nécessaires pour répondre aux besoins d’utilisation
du SI et mise en place de ces évolutions après approbation par la direction,
- Réalisation de tests annuels du plan de reprise informatique (ou participation à ces tests).

Ces activités font l’objet de procédures documentées, rédigées par l’exploitant et approuvées par le
RSSI.

5.2 Exploitation sous-traitée

Les fournisseurs et prestataires assurant l’exploitation de l’infrastructure Cloud et du réseau

présentent au moins une fois par an au RSSI un rapport d’exploitation concernant :
- Le déroulement des opérations d’exploitation au cours de la période (changements, gestion
des comptes, réponse aux demandes, opérations de maintenance…),
- L’analyse des alarmes et incidents traités au cours de la période,
- Le résultat des indicateurs de qualité de service figurant au contrat,
- L’analyse du dimensionnement du système et de son état technique (versions des logiciels
systèmes en particulier),
- Les besoins de changements ou d’extension de système.

5.3 Mise en production

Tout changement apporté au SI doit faire l’objet de tests préalables, si possible dans un environnement
distinct de l’environnement de production. Ces tests font l’objet de critères d’acceptation et de
comptes rendus formalisés. Les changements apportés aux applications doivent être testés par des
représentants des utilisateurs concernés.

10
5.4 Virus, codes malveillants et vulnérabilités

Les postes de travail et les serveurs sont équipés d’antivirus mis à jour et surveillés régulièrement.

Le flux de messagerie extérieur est filtré par un mécanisme anti-spam.

Les vulnérabilités système sont surveillées au moyen du CERT-FR (Centre gouvernemental de veille,
d’alerte et de réponse aux attaques informatiques), et font l’objet de mises à jour régulières des
systèmes.

5.5 Sauvegarde

La gestion des sauvegardes et restaurations des données est réalisée selon les règles suivantes :
- Il existe une procédure documentée de sauvegarde ; celle-ci définit la couverture du plan de
sauvegarde (système, applications, données) ainsi que les fréquences des sauvegardes et les
durées de rétention, qui sont fonction des systèmes et des applications, et de leur criticité ;
o Les images des serveurs applicatifs (Pas de données) sont hebdomadaires
o Les images des serveurs de base de données sont quotidiennes
o Les données applicatives sont sauvegardées quotidiennement

- Il est systématiquement procédé à deux copies de sauvegardes conservées dans des lieux
différents :
o Serveurs de backup OVH dans un autre Datacenter
o Amazon S3

- Des tests de restauration (système, applications, données) des serveurs et/ou applications
critiques sont réalisés tous les mois, les rapports de tests sont conservés.
- Les sauvegardes sont intégralement chiffrées avec gpg

5.6 Sécurité du réseau

L’accès à l’infrastructure Cloud est soumis à l’identification et authentification par un système de

login et mot de passe, assorti d’un certificat.

Les accès distants sont sécurités par :

- Dans le cadre du mode « Liaison de deux sites distants » par des VPN IPSEC respectant les
recommandations de l’ANSSI 1 notamment :
o R3 : L’emploi d’IPsec doit se faire avec le protocole ESP
o R4 : Le service de confidentialité d’ESP ne doit jamais être employé sans activer le
mécanisme de contrôle d’intégrité.
o R7 : Il est préférable de fixer a priori les algorithmes et tailles de clés employés (voir
infra pour le choix) et de n’utiliser IKE que pour l’échange de clés. À défaut de pouvoir
les fixer, on ne permettra la négociation que sur un nombre réduit d’algorithmes.
o R8 : Utilisation de IKEv22

1
[Link]
2
Lorsque les équipements du client le permettent.

11
 o R11 : S’il est nécessaire de recourir au NAT sur des flux IPsec, il est nécessaire d’activer
le mécanisme de NAT-Traversal.
o R12 : Dès lors que cette possibilité est offerte par les équipements employés, il est
recommandé de mettre en œuvre la propriété PFS en phase 2 en utilisant dans le «
quick mode » l’échange de clé Diffie-Hellman éphémère classique ou sa variante sur
courbes elliptiques.
o R13 : Dès lors que cette possibilité est offerte par les équipements employés, il est
recommandé de forcer le renouvellement périodique des clés, par exemple toutes les
heures et tous les 100 Go de données, afin de limiter l’impact de la compromission
d’une clé sur le trafic des données.
o R14 : Il est fortement déconseillé d’employer la fonction de hachage MD5, le
chiffrement DES, des clés RSA de taille inférieure à 2048 bits ou des clés ECDSA de
taille inférieure à 200 bits.3
o R15 : Il est déconseillé d’utiliser 3DES, SHA-1 ou ECDSA avec des clés de moins de 256
bits si des alternatives plus sécurisées telles qu’AES (AES-128 ou AES-256), SHA-2
(SHA224, SHA-256, SHA-384 ou SHA-512) ou ECDSA avec des clés d’au moins 256 bits
sont disponibles.2
o R16 : On prendra garde au groupe de Diffie-Hellman employé. Les groupes 1 ou 2, très
fréquemment proposés dans les configurations par défaut, ne sont plus d’une taille
acceptable. On privilégiera les groupes ayant des modules de taille plus importante
(comme les groupes 14 et 15) voire (si possible) les groupes construits sur des courbes
elliptiques d’au moins 256 bits (comme la courbe ecp256, aussi nommée groupe 19
ou encore la courbe ecp384bp, normalisée sous l’appellation groupe 29).2

- Dans le cadre du mode « utilisation nomade » par des VPN OpenVPN 2.4.6 certifiés par l’ANSSI4
o Chaque utilisateur « nomade » doit s’authentifier avec un couple login/mot de passe
ainsi qu’un certificat unique et par utilisateur.
o Chaque utilisateur n’accède qu’aux ressources qui lui sont propres et autorisées.

Toutes les bordures de réseau sont protégées par des firewalls ; Aucun accès publique n’est autorisé
sur les équipements de l’infrastructure sans avoir été analysé et filtrer par un firewall. Chaque adresse
IP publique hébergeant des services à authentification est surveillée par un système de bannissement
d’adresse d’IP, afin d’éviter toute tentative de brute force.

Le réseau de l’infrastructure cloud, est segmenté en VLAN, il existe des VLANS d’administration
uniquement accessibles au personnel de la société. Chaque client connecté à l’infrastructure cloud est
connecté à son VLAN, et de fait il est complétement séparé des autres clients. Tous les accès VPN d’un
client (nomades & site à site), ne peuvent lui donner accès qu’à son ou ses VLAN dédiés.

Le réseau est protégé contre le DDOS, par le système de protection contre les attaques par déni de
service distribuées d’OVH Cloud5

3
Lorsque les équipements du client le permettent
4
[Link]
5
[Link]

12
5.7 Sécurité des systèmes

Les baies de stockages utilisées par l’infrastructure Cloud sont des baies NAS de 13.2TB en RAID10,
permettant d’assurer une sécurité maximale des données en les répliquant sur un disque miroir, et
d’optimiser les performances en lecture/écriture.

Ces baies de stockages ne sont accessibles qu’à travers les VLANS d’administration, et en aucun cas
depuis les accès clients, ou publics.

Les baies de stockages utilisent ZFS et sont capables en standard de fournir les snapshots (il y a 1 heure,
il y a un jour, il y a une semaine) des images des serveurs virtuels, on pourra utiliser ces snapshots dans
le cadre du PRA.

Les hyperviseurs (Proxmox 6.2, VMWare Esx 6.7U3) sont mis à jour dès qu’une note de sécurité est
publiée.

Les serveurs virtuels, qu’ils soient sous Windows, ou Linux subissent la même règle de mise à jour
dès la publication de notes de sécurité.

L’accès aux serveurs, s’il doit être public est obligatoirement filtré et analysé par un firewall, et seuls
les adresses IP déclarées des clients permettent d’y accéder.

5.8 Protection des fichiers

Les fichiers en exploitation (exécutables, paramètres, bases de données), les programmes source, et
les fichiers permettant de journaliser les traces d’activité (« logs » système et réseau), sont protégés
contre les accès non autorisés et sauvegardés.

13
6 Contrôle d’accès logique

6.1 Enregistrement des utilisateurs et droits d’accès

La procédure de gestion des accès définit les modalités pratiques d’attribution et de retrait des accès.
Elle s’appuie sur les principes suivants :
- Toute création, suppression ou modification d’un compte utilisateur et des droits associés lors
d’une arrivée, d’un départ ou d’un changement de poste, doit faire l’objet d’une demande ;
- Chaque utilisateur, qu’il soit interne ou externe, possède pour l’accès aux systèmes un
identifiant unique nominatif strictement personnel ;
- Les comptes d’accès aux applications sont également nominatifs ; ils sont créés et tenus à jour
par le client ;
- Les exploitants et administrateurs système utilisent également des comptes nominatifs sauf
exception ; l’utilisation des comptes génériques doit être restreinte aux situations où elle est
indispensable (installation initiale, création d’un compte administrateur, dépannage) ;
- Il est procédé périodiquement à une revue des comptes et des droits d’accès de manière à
détecter la présence de comptes obsolètes ou de droits d’accès inadéquats ; cette revue est
organisée par le RSSI.
La procédure de gestion des accès définit également des règles relatives a :
- L’attribution et la restitution des biens (postes de travail, licences logicielles, cartes à puces,
etc.) lors de l’arrivée, du départ, ou du changement de fonction d’un membre du personnel de
l’établissement,
- La redirection des messages après un départ,
- La destruction des données personnelles hébergées par le SI (fichiers bureautiques,
messagerie, etc.),
- La mise à jour des paramètres des applications liés à l’utilisateur.

6.2 Mots de passe

Les mots de passe des utilisateurs et des administrateurs doivent comprendre 8 caractères au moins
avec un mélange de lettres, de chiffres et de caractères spéciaux.
Les mots de passe des exploitants et administrateurs système doivent être modifiés tous les 6 mois.
Ceux des utilisateurs doivent être remplacés en cas de doute sur la confidentialité de leur mot de passe
et si possible une fois par an.

6.3 Matériel laissé sans surveillance

Tout poste de travail laissé sans surveillance doit au préalable être verrouillé logiquement ou
déconnecté des sessions actives. Un verrouillage automatique est mis en place après une période
d’inutilisation de 5 minutes.
A la fin de la journée, l’utilisateur doit éteindre son poste de travail et mettre sous clé les documents
papier sensibles et en particulier tout document comportant des données de santé ou des données
relatives au personnel.

14
7 Sécurité liée aux projets et aux applications
Tout projet d’acquisition ou de modification d’une application du SI doit respecter les règles suivantes :
- Il doit être rédigé un document d’expression de besoins, ou cahier des charges, définissant
les besoins de disponibilité, d’intégrité et de confidentialité de l’information, et déterminant la
criticité de l’application. Le cahier des charges doit en particulier insister sur les contrôles de
saisie des informations, sur les exigences liées aux accès (mise en place d’habilitations,
journalisation des accès), et, pour les applications critiques, sur l’existence d’un mode dégradé
permettant un fonctionnement a minima en cas de sinistre majeur.
- Il doit être procédé à des tests d’acceptation, sur la base de fiches de tests et de critères
d’acceptation. Ces tests couvrent les aspects fonctionnels et techniques. Ils sont à réaliser
lors de la première mise en production et lors des évolutions majeures ; ils ont lieu dans un
environnement de test séparé.
- Il doit être procédé à une formation des utilisateurs préalablement au démarrage. Cette
formation a lieu si possible dans un environnement dédié qui sera conservé pour permettre
les formations ultérieures à l’occasion des nouvelles versions.

8 Gestion des incidents de sécurité

Sont considérés comme incidents de sécurité :
- La divulgation d’informations confidentielles,
- Le vol ou la disparition d’un équipement ou d’un support,
- La perte ou l’altération de données dans une application ou un service critique, ou dans un
« log »,
- Les pannes et sinistres qui affectent gravement la disponibilité du SI,
- La présence d’un virus,
- Une intrusion ou une tentative d’accès non autorisé sur les infrastructures informatiques,
- Et plus généralement toute non-conformité aux règles de la PSSI détectée lors d’un audit, de
la surveillance régulière, ou d’un test du PRI.

Ces incidents sont tracés en tant qu’événements indésirables et rapportés sans tarder au RSSI. Celui-
ci est chargé de coordonner l’analyse et la mise en place d’actions de traitement immédiat puis de
correction sur le fond (action corrective), en lien avec le coordonnateur de la gestion des risques de
l’établissement.
Le RSSI présente le bilan périodique des incidents de sécurité aux dirigeants de la société et l’état des
plans d’actions associés.

15
9 Continuité d’activité et continuité du SI
La société a procédé à une analyse des risques mettant en péril la continuité de son activité. Il a élaboré
un plan de continuité d’activité (PCA) et un Plan Blanc permettant de faire face aux scénarios de risque
identifiés.
Dans ce cadre, les scénarios de risque liés au SI, et les exigences de continuité de fonctionnement du
SI ont été analysés pour élaborer le plan de reprise informatique (PRI).
Le plan de reprise informatique a pour objet de :
- Décrire les scénarios de risque susceptibles d’affecter gravement la disponibilité du SI,
- Présenter les moyens techniques ou organisationnels permettant de faire face à ces risques,
- Décrire ou référencer les procédures dégradées qui sont obligatoirement mises en place pour
les applications critiques ;
- Décrire les procédures à mettre en œuvre pour déclencher le passage en secours informatique
et pour assurer le retour à la normale ;
- Décrire le fonctionnement de la cellule de crise ;
- Décrire les modalités de test du PRI.

Le PRI est présenté une fois par an aux dirigeants et approuvé par la direction.

10 Conformité

10.1 Exigences légales et réglementaires

La conformité aux exigences réglementaires et légales repose sur les dispositifs suivants :
- Une veille réglementaire est assurée par la direction. Les exigences susceptibles d’impacter le
SI sont communiquées au RSSI. Celui-ci s’assure de leur prise en compte dans les procédures
internes et par les prestataires.
- Les applications du SI comportant des données nominatives font l’objet d’une déclaration ou
d’une demande d’autorisation auprès de la CNIL. La prise en compte des exigences CNIL est
assurée par le RSSI.
- Les contrôles techniques sont réalisés selon la périodicité définie. Les résultats de ces contrôles
et inspections sont analysés par le RSSI pour ce qui concerne la sécurité de l’information ; des
actions de mise en conformité sont engagées si besoin.

10.2 Conformité technique et respect de la PSSI

La conformité technique du SI et la conformité aux règles de la PSSI font l’objet d’audits périodiques :
- Un audit technique est réalisé une fois tous les deux ans sur un sujet particulier (ex : tests
d’intrusion, audit de la sécurité physique, accès réseau) ; ces audits sont confiés à des
prestataires ;
- Un audit organisationnel est réalisé tous les deux ans soit en interne par un auditeur formé,
soit par un prestataire extérieur.

Les résultats de ces audits font l’objet d’une analyse et de plans d’actions.

Le respect de la PSSI fait l’objet d’autres dispositifs de contrôle : surveillance dans le cadre de
l’exploitation, revue des droits d’accès, analyse des logs système et réseau, analyse des incidents de
sécurité, rapports de l’exploitant, remontées des utilisateurs. La synthèse de ces éléments est
présentée aux dirigeants et elle fait l’objet de plans d’actions.

16
11 Actifs du SI

11.1 Tableau

Niveau (*)
Actif Commentaire
D I C A
Serveurs techniques
Hyperviseurs 3 3 2 3
Monitoring 2 2 2 2
Backup 4 3 4 3

Serveurs applicatifs
Serveur Applicatif Nixxis 4 4 2 3
Serveurs Media Nixxis 3 2 3 3

Serveurs base de données

Serveurs base de données Nixxis 4 4 3 3

Réseau
Firewall 4 4 4 4
Concentrateurs VPN 4 4 4 3

Informations
Dossiers client 2 4 3 2
Wiki Client 3 4 3 2
Notes de projet 2 2 3 2
Wiki Infrastructure 3 4 3 3

Hébergeur
OVH Cloud 4 4 3 3
Amazon AWS 2 3 3 3

(*) D : disponibilité – I : intégrité – C : confidentialité – A : Auditabilité . L’établissement utilise les échelles décrites dans le
« Guide méthodologique SSI » de la FNEHAD.

17
11.2 Référentiel

18