Politique de sécurité du SI et résilience organisationnelle

Introduction

Après l’identification et l’analyse des risques liés aux systèmes d’information (voir la leçon 102), l’étape suivante consiste à définir et piloter une politique de sécurité du système d’information. Cette politique ne se réduit pas à une liste d’outils techniques. Elle constitue un cadre de gouvernance, d’organisation et de contrôle destiné à protéger les actifs informationnels, à sécuriser les processus critiques et à assurer la résilience organisationnelle.

Autrement dit, une organisation ne sécurise pas son SI uniquement en achetant des solutions de cybersécurité. Elle le sécurise surtout en mettant en place une politique de sécurité des systèmes d’information cohérente, fondée sur l’analyse des risques, portée par la gouvernance, traduite en règles opérationnelles, contrôlée dans le temps et articulée avec la continuité d’activité.

Cette leçon traite donc de la manière de :

• concevoir une politique de sécurité du SI ;
• mettre en œuvre cette politique ;
• contrôler son efficacité ;
• relier la sécurité à la résilience organisationnelle ;
• comprendre les briques essentielles d’une architecture de confiance : authentification, chiffrement, segmentation, IAM, PCA et PRA.

1. Pourquoi une politique de sécurité du SI est indispensable

1.1. Définition

La politique de sécurité des systèmes d’information (souvent abrégée en PSSI) est le document-cadre qui fixe :

• les objectifs de sécurité de l’organisation ;
• les principes directeurs applicables au SI ;
• les rôles et responsabilités ;
• les règles de protection, de détection, de réaction et de continuité ;
• les modalités de contrôle et d’amélioration continue.

Elle répond à une question simple : comment l’organisation protège-t-elle ses informations, ses applications, ses infrastructures et ses processus critiques ?

1.2. Une logique de pilotage, pas seulement de protection

La sécurité du SI relève du pilotage, de la sécurisation et de l’évolution des systèmes d’information. Cela signifie que la sécurité n’est pas un bloc isolé :

• elle accompagne les transformations du SI ;
• elle s’adapte aux nouveaux usages ;
• elle soutient la performance et la conformité ;
• elle contribue à la durabilité du SI en évitant les interruptions, pertes de données et dégradations de confiance.

Une politique efficace permet donc de concilier :

• protection ;
• continuité de service ;
• conformité réglementaire ;
• maîtrise des risques de cybersécurité ;
• résilience organisationnelle.

1.3. Pourquoi la simple accumulation d’outils ne suffit pas

Installer un antivirus, un pare-feu ou une solution d’authentification multifacteur ne constitue pas, à lui seul, une politique de sécurité. Sans cadre global :

• les mesures sont incohérentes ;
• les responsabilités sont floues ;
• les exceptions se multiplient ;
• les contrôles sont insuffisants ;
• la réaction en cas d’incident est désorganisée.

La politique de sécurité donne donc une cohérence d’ensemble. Elle transforme des mesures techniques dispersées en système de maîtrise.

2. Les objectifs fondamentaux d’une politique de sécurité

Une politique de sécurité du SI vise classiquement à protéger trois propriétés essentielles de l’information.

2.1. La confidentialité

La confidentialité signifie que l’information n’est accessible qu’aux personnes autorisées.

Exemples :

• les données de paie ne doivent être consultées que par les personnes habilitées ;
• les informations bancaires d’un client ne doivent pas être exposées ;
• les documents stratégiques ne doivent pas être diffusés hors du périmètre autorisé.

2.2. L’intégrité

L’intégrité signifie que l’information est exacte, complète et non altérée de manière non autorisée.

Exemples :

• un fichier comptable ne doit pas être modifié sans traçabilité ;
• une base clients ne doit pas être corrompue ;
• une écriture ne doit pas être changée sans contrôle.

2.3. La disponibilité

La disponibilité signifie que les informations et services sont accessibles au moment où ils sont nécessaires.

Exemples :

• l’ERP doit rester accessible pendant la clôture comptable ;
• la messagerie doit fonctionner pour les échanges critiques ;
• les applications de production ne doivent pas être interrompues durablement.

2.4. Au-delà du triptyque classique

Dans la pratique, une politique de sécurité intègre aussi :

• la traçabilité ;
• l’authenticité ;
• la preuve ;
• la conformité ;
• la résilience.

La résilience organisationnelle désigne la capacité à absorber un incident, à maintenir les activités essentielles, puis à revenir à un fonctionnement acceptable dans des délais compatibles avec les enjeux de l’organisation.

3. Le point de départ : une politique fondée sur l’analyse des risques

3.1. Principe général

On ne définit pas une politique de sécurité « en général ». On la construit à partir des risques effectifs de l’organisation.

La logique est la suivante :

1. identifier les actifs critiques ;
2. repérer les menaces ;
3. apprécier les vulnérabilités ;
4. mesurer les impacts potentiels ;
5. hiérarchiser les risques ;
6. choisir des mesures de traitement adaptées.

3.2. Quels actifs protéger ?

Les actifs du SI ne se limitent pas aux serveurs. Il faut distinguer :

• les données ;
• les applications ;
• les infrastructures ;
• les flux ;
• les identités numériques ;
• les processus métiers dépendants du SI ;
• les prestations externalisées.

Exemple : dans un cabinet ou une direction financière, les actifs critiques peuvent être :

• la comptabilité générale ;
• les dossiers clients ;
• les outils de paie ;
• les applications de trésorerie ;
• les sauvegardes ;
• les annuaires d’identité.

3.3. Exemples de risques de cybersécurité à traiter

Une politique de sécurité doit permettre de gérer les risques de cybersécurité, par exemple :

• hameçonnage et compromission d’identifiants ;
• rançongiciel ;
• fuite de données ;
• erreur de paramétrage ;
• usurpation de compte ;
• indisponibilité d’un service critique ;
• mauvaise gestion des habilitations ;
• propagation latérale d’une attaque dans le réseau.

3.4. Prioriser selon la criticité

Tous les risques ne se valent pas. Une organisation doit arbitrer en fonction de :

• la probabilité de survenance ;
• la gravité de l’impact ;
• les obligations réglementaires ;
• la sensibilité métier ;
• les conséquences financières, opérationnelles et réputationnelles.

La politique de sécurité doit donc être proportionnée : plus le risque est critique, plus le niveau d’exigence doit être élevé.

4. Les composantes d’une politique de sécurité du SI

4.1. Le périmètre

La politique doit préciser son périmètre d’application :

• sièges, sites, filiales ;
• utilisateurs internes ;
• prestataires ;
• équipements fixes et mobiles ;
• services en nuage ;
• applications critiques ;
• données internes, confidentielles ou réglementées.

Sans périmètre clair, la politique devient théorique.

4.2. Les principes directeurs

Une politique de sécurité repose sur des principes structurants, par exemple :

• besoin d’en connaître ;
• moindre privilège ;
• séparation des tâches ;
• défense en profondeur ;
• traçabilité ;
• révision périodique des habilitations ;
• sécurité dès la conception.

4.3. Les rôles et responsabilités

La sécurité est une responsabilité partagée. La politique doit identifier :

• la direction générale, qui valide l’orientation et arbitre les moyens ;
• la DSI, qui met en œuvre techniquement ;
• les directions métiers, responsables des besoins et de la classification des données ;
• les utilisateurs, tenus de respecter les règles ;
• les prestataires, soumis à des exigences contractuelles ;
• les responsables sécurité lorsqu’ils existent.

4.4. Les règles opérationnelles

La politique doit se décliner en règles concrètes sur :

• les accès ;
• les mots de passe et l’authentification ;
• les habilitations ;
• le chiffrement ;
• les équipements mobiles ;
• le télétravail ;
• les sauvegardes ;
• la journalisation ;
• la gestion des incidents ;
• la continuité et la reprise.

4.5. Le contrôle

Une politique sans contrôle est une déclaration d’intention. Il faut prévoir :

• des indicateurs ;
• des revues périodiques ;
• des audits internes ;
• des tests de restauration ;
• des exercices de crise ;
• des plans d’actions correctifs.

5. L’architecture de confiance

La leçon met l’accent sur plusieurs briques essentielles d’une architecture de confiance. Il ne s’agit pas d’entrer dans l’implémentation technique détaillée, mais de comprendre leur rôle dans la politique de sécurité.

5.1. Définition

Une architecture de confiance désigne l’ensemble cohérent de mécanismes organisationnels et techniques qui permettent de sécuriser les accès, les échanges, les traitements et la continuité des services.

Elle vise à répondre à quatre questions :

• qui accède ?
• à quoi ?
• dans quelles conditions ?
• avec quel niveau de preuve et de protection ?

Ses briques essentielles, au programme de cette leçon, sont :

• l’authentification ;
• le chiffrement ;
• la segmentation ;
• l’IAM (Identity & Access Management) ;
• le PCA ;
• le PRA.

6. L’authentification : vérifier l’identité avant d’autoriser l’accès

6.1. Définition

L’authentification est le mécanisme qui permet de vérifier l’identité d’un utilisateur, d’un administrateur, d’un terminal ou parfois d’une application.

Il faut bien distinguer :

• identification : l’utilisateur déclare qui il est ;
• authentification : le système vérifie cette identité ;
• autorisation : le système détermine ce que l’utilisateur peut faire.

6.2. Les facteurs d’authentification

L’authentification peut reposer sur :

• quelque chose que l’on connaît : mot de passe, code ;
• quelque chose que l’on possède : téléphone, jeton, carte ;
• quelque chose que l’on est : biométrie.

L’authentification multifacteur consiste à combiner plusieurs facteurs pour réduire le risque d’usurpation.

6.3. Pourquoi elle est centrale

Une grande part des incidents de cybersécurité commence par la compromission d’un compte. Si l’identité est mal protégée :

• l’attaquant peut se connecter avec des droits légitimes ;
• les mécanismes de contrôle sont contournés ;
• la détection devient plus difficile ;
• l’attaque peut se propager rapidement.

6.4. Bonnes pratiques de politique de sécurité

Une politique de sécurité peut imposer :

• l’authentification multifacteur pour les accès sensibles ;
• des règles de robustesse des secrets d’authentification ;
• une gestion spécifique des comptes à privilèges ;
• la désactivation rapide des comptes inactifs ;
• une traçabilité des connexions.

6.5. Exemple

Une entreprise autorise l’accès distant à son ERP financier. Sans authentification forte, un mot de passe volé suffit à entrer. Avec une authentification multifacteur, le risque diminue fortement, car l’attaquant doit aussi posséder le second facteur.

7. Le chiffrement : protéger les données contre la lecture non autorisée

7.1. Définition

Le chiffrement consiste à transformer une information lisible en information inintelligible pour toute personne ne disposant pas de la clé ou du mécanisme autorisé de déchiffrement.

7.2. Finalité

Le chiffrement protège principalement la confidentialité. Il peut aussi contribuer à :

• la protection des données en transit ;
• la protection des données stockées ;
• la réduction des conséquences d’une fuite ou d’un vol de support.

7.3. Deux usages majeurs

a) Chiffrement des données en transit

Il protège les échanges entre :

• un utilisateur et une application ;
• deux systèmes ;
• un site et un service distant.

Objectif : éviter l’interception ou l’altération lors du transport.

b) Chiffrement des données au repos

Il protège les données stockées sur :

• serveurs ;
• postes ;
• ordinateurs portables ;
• supports amovibles ;
• sauvegardes.

Objectif : limiter l’exposition en cas de perte, de vol ou d’accès non autorisé.

7.4. Pourquoi le chiffrement ne suffit pas à lui seul

Le chiffrement n’est efficace que si la gestion des clés est maîtrisée. Si les clés sont mal protégées, le dispositif perd sa valeur. La politique de sécurité doit donc encadrer :

• qui gère les clés ;
• où elles sont stockées ;
• comment elles sont renouvelées ;
• comment l’accès aux clés est contrôlé.

7.5. Exemple

Des sauvegardes contenant des données sensibles sont externalisées. Si elles ne sont pas chiffrées, leur exposition crée un risque majeur. Si elles sont chiffrées et que les clés sont séparées et protégées, le niveau de sécurité est nettement supérieur.

8. La segmentation : limiter la propagation d’un incident

8.1. Définition

La segmentation consiste à diviser le système d’information ou le réseau en zones distinctes afin de limiter les communications et de mieux contrôler les flux.

8.2. Pourquoi segmenter

Si tout communique avec tout, une compromission locale peut devenir une crise généralisée. La segmentation permet :

• de réduire la surface d’attaque ;
• d’isoler les environnements sensibles ;
• de ralentir la propagation latérale ;
• de mieux surveiller les échanges ;
• de protéger les systèmes critiques.

8.3. Exemples de segmentation

Une organisation peut distinguer :

• le réseau bureautique ;
• l’environnement de production ;
• les serveurs financiers ;
• les postes administrateurs ;
• les accès prestataires ;
• les zones exposées vers l’extérieur.

8.4. Logique de politique de sécurité

Une politique de sécurité doit définir :

• quelles zones doivent être isolées ;
• quels flux sont autorisés ;
• qui valide les ouvertures de communication ;
• comment les exceptions sont tracées et revues.

8.5. Exemple concret

Sans segmentation, un poste utilisateur infecté peut atteindre les serveurs de sauvegarde ou les applications comptables. Avec une segmentation adaptée, l’attaque reste contenue à un périmètre plus restreint, ce qui améliore la résilience.

9. L’IAM : piloter les identités et les accès

9.1. Définition

L’IAM (Identity & Access Management) désigne l’ensemble des processus, règles et outils permettant de gérer :

• les identités numériques ;
• les habilitations ;
• les droits d’accès ;
• les cycles de vie des comptes ;
• les contrôles associés.

9.2. Pourquoi l’IAM est stratégique

Dans la plupart des organisations, les incidents majeurs impliquent des problèmes d’identité ou d’accès :

• comptes trop ouverts ;
• droits non révoqués ;
• comptes génériques ;
• absence de séparation des tâches ;
• comptes administrateurs mal contrôlés.

L’IAM est donc au cœur de la politique de sécurité.

9.3. Les fonctions essentielles de l’IAM

Un dispositif IAM bien conçu couvre :

• la création des comptes ;
• l’attribution des droits selon les fonctions ;
• la modification des habilitations en cas de mobilité ;
• la suppression ou désactivation lors du départ ;
• la revue périodique des droits ;
• la gestion des comptes à privilèges ;
• la traçabilité des accès.

9.4. Lien avec le contrôle interne

L’IAM soutient directement le contrôle interne. Par exemple :

• un même utilisateur ne doit pas créer un fournisseur et valider le paiement ;
• les accès à la paie doivent être restreints ;
• les privilèges d’administration doivent être limités et surveillés.

9.5. Exemple de cycle de vie des accès

Étape 1 : arrivée d’un collaborateur

Création d’une identité numérique et attribution des droits selon son poste.

Étape 2 : changement de fonction

Révision des habilitations : ajout de certains droits, retrait d’autres.

Étape 3 : départ de l’organisation

Désactivation immédiate des accès et récupération des moyens d’authentification.

Sans ce cycle de vie, les droits s’accumulent et deviennent un risque majeur.

10. Le PCA et le PRA : cœur de la résilience organisationnelle

10.1. La résilience organisationnelle

La résilience organisationnelle est la capacité de l’organisation à :

• résister à une perturbation ;
• maintenir ses activités essentielles ;
• restaurer un niveau de service acceptable ;
• tirer des enseignements de l’incident.

Dans le domaine du SI, cette résilience repose notamment sur le PCA et le PRA.

10.2. Le PCA : plan de continuité d’activité

Le plan de continuité d’activité (PCA) organise le maintien des activités essentielles pendant une perturbation.

Il répond à la question : comment continuer à fonctionner, même en mode dégradé ?

Le PCA peut prévoir :

• des procédures de contournement ;
• des priorités de traitement ;
• des ressources de substitution ;
• des responsabilités de crise ;
• des modalités de communication.

10.3. Le PRA : plan de reprise d’activité

Le plan de reprise d’activité (PRA) organise la restauration du SI après un incident majeur.

Il répond à la question : comment redémarrer les services et dans quel ordre ?

Le PRA prévoit notamment :

• les sauvegardes ;
• les environnements de reprise ;
• les séquences de redémarrage ;
• les délais cibles ;
• les tests de restauration.

10.4. Différence entre PCA et PRA

• PCA : maintenir l’activité malgré la crise.
• PRA : remettre en fonctionnement les systèmes après la crise.

Les deux sont complémentaires. Une organisation peut avoir un PRA technique correct mais un PCA insuffisant, ce qui signifie qu’elle sait redémarrer plus tard, mais pas continuer entre-temps.

10.5. Pourquoi ils doivent être intégrés à la politique de sécurité

Une politique de sécurité qui ne traite pas la continuité est incomplète. La cybersécurité ne consiste pas seulement à empêcher une attaque ; elle consiste aussi à :

• réduire ses effets ;
• organiser la réaction ;
• restaurer rapidement les services critiques.

10.6. Exemple

Une attaque par rançongiciel chiffre les serveurs de fichiers. Sans PRA testé, les sauvegardes peuvent être inutilisables ou trop lentes à restaurer. Sans PCA, les équipes ne savent pas comment poursuivre les opérations essentielles. Avec un PCA/PRA préparé, l’organisation peut prioriser les applications critiques, communiquer, basculer sur des procédures de secours et reprendre plus vite.

11. Concevoir une politique de sécurité du SI : démarche structurée

11.1. Étape 1 : cadrer les enjeux

Il faut d’abord identifier :

• les objectifs métiers ;
• les processus critiques ;
• les obligations de conformité ;
• les dépendances techniques et humaines.

11.2. Étape 2 : s’appuyer sur l’analyse des risques

Comme vu plus haut, la politique doit être construite à partir de la criticité réelle des actifs et des scénarios de menace.

11.3. Étape 3 : définir les principes de sécurité

L’organisation formalise ses exigences sur :

• les identités ;
• les accès ;
• la protection des données ;
• la segmentation ;
• la journalisation ;
• la gestion des incidents ;
• la continuité et la reprise.

11.4. Étape 4 : attribuer les responsabilités

Chaque acteur doit savoir ce qu’il doit faire :

• validation ;
• mise en œuvre ;
• contrôle ;
• escalade ;
• arbitrage.

11.5. Étape 5 : décliner en procédures

La politique générale doit être complétée par des procédures plus opérationnelles, par exemple :

• gestion des habilitations ;
• gestion des incidents ;
• gestion des sauvegardes ;
• gestion des accès distants ;
• gestion des comptes à privilèges ;
• activation du PCA/PRA.

11.6. Étape 6 : former et sensibiliser

Une politique de sécurité ignorée des utilisateurs est inefficace. Il faut :

• expliquer les règles ;
• former aux bons réflexes ;
• rappeler les procédures d’alerte ;
• intégrer la sécurité dans les pratiques quotidiennes.

11.7. Étape 7 : tester et améliorer

La politique doit vivre. Cela suppose :

• des contrôles périodiques ;
• des exercices ;
• des retours d’expérience ;
• des mises à jour selon l’évolution du SI.

12. Mettre en œuvre la politique de sécurité

12.1. De la règle à l’application concrète

La mise en œuvre consiste à transformer les principes en mesures effectives. Par exemple :

• imposer l’authentification multifacteur ;
• revoir les habilitations ;
• segmenter les environnements ;
• chiffrer les supports sensibles ;
• documenter le PCA/PRA ;
• définir une cellule de crise.

12.2. Importance de la cohérence organisationnelle

Une mesure isolée produit peu d’effet si elle n’est pas articulée avec les autres. Exemple :

• authentification forte sans revue des droits = sécurité incomplète ;
• sauvegardes sans test de restauration = fausse assurance ;
• segmentation sans gouvernance des flux = dérive rapide.

12.3. Intégrer les prestataires et systèmes critiques

La politique doit couvrir aussi :

• les accès des prestataires ;
• les services externalisés ;
• les dépendances critiques ;
• les engagements contractuels liés à la sécurité et à la continuité.

13. Contrôler la politique de sécurité du SI

13.1. Pourquoi contrôler

Concevoir une politique est nécessaire ; la contrôler est indispensable. Le contrôle permet de vérifier :

• si les règles sont appliquées ;
• si les mesures sont efficaces ;
• si les écarts sont détectés ;
• si la résilience est réelle et non supposée.

13.2. Types de contrôles

Le contrôle peut prendre plusieurs formes :

• revue des habilitations ;
• suivi des incidents ;
• contrôle des journaux ;
• audit interne ;
• vérification des sauvegardes ;
• test du PRA ;
• exercice de crise ;
• revue de conformité.

13.3. Exemples d’indicateurs

Une organisation peut suivre :

• le taux d’activation de l’authentification multifacteur ;
• le nombre de comptes inactifs non supprimés ;
• le délai de révocation des accès après départ ;
• le taux de chiffrement des postes sensibles ;
• le nombre d’exceptions de segmentation ;
• le taux de succès des restaurations ;
• le délai moyen de reprise d’un service critique.

13.4. Logique d’amélioration continue

Le pilotage d’une politique de sécurité s’inscrit dans une logique d’amélioration continue :

1. définir ;
2. mettre en œuvre ;
3. contrôler ;
4. corriger ;
5. réviser.

14. Étude de cas : construire une politique de sécurité dans une PME multi-sites

14.1. Situation

Une PME de 250 salariés dispose :

• d’un ERP comptable et commercial ;
• d’un outil de paie ;
• d’un accès distant pour les commerciaux ;
• d’un prestataire d’infogérance ;
• de sauvegardes externalisées.

Elle a connu deux incidents :

• un compte compromis par hameçonnage ;
• une restauration de sauvegarde trop lente lors d’une panne.

14.2. Analyse synthétique

Les faiblesses principales sont :

• authentification insuffisante ;
• gestion des accès peu formalisée ;
• dépendance forte au prestataire ;
• PRA non suffisamment testé ;
• cloisonnement réseau limité.

14.3. Mesures à intégrer dans la politique de sécurité

a) Sur l’authentification

• authentification multifacteur pour les accès distants ;
• règles renforcées pour les comptes à privilèges.

b) Sur l’IAM

• procédure d’entrée, mobilité, sortie ;
• revue trimestrielle des habilitations sensibles.

c) Sur la segmentation

• isolement des serveurs financiers ;
• séparation des accès prestataires ;
• contrôle formalisé des flux entre zones.

d) Sur le chiffrement

• chiffrement des postes nomades ;
• chiffrement des sauvegardes externalisées.

e) Sur la résilience

• formalisation du PCA pour les processus critiques ;
• PRA avec ordre de reprise des applications ;
• test semestriel de restauration.

14.4. Résultat attendu

L’entreprise ne supprime pas tout risque, mais elle améliore nettement sa capacité à :

• empêcher des accès frauduleux ;
• contenir un incident ;
• restaurer ses activités essentielles ;
• démontrer une gouvernance sérieuse de la sécurité.

15. Erreurs fréquentes dans la définition d’une politique de sécurité

15.1. Confondre politique et documentation technique

Une politique de sécurité n’est pas un manuel d’administration. Elle fixe des principes, responsabilités et règles de pilotage.

15.2. Oublier la dimension métier

Une politique définie uniquement par la DSI, sans lien avec les processus critiques, risque d’être mal calibrée.

15.3. Négliger les identités

Les habilitations obsolètes et les comptes mal gérés constituent un risque majeur.

15.4. Penser que la sauvegarde suffit

Une sauvegarde non testée ne garantit pas la reprise.

15.5. Ignorer les exercices de crise

La résilience se vérifie par des tests, pas par des suppositions.

15.6. Laisser proliférer les exceptions

Chaque exception non revue fragilise l’architecture de confiance.

16. Méthode pratique pour un écrit professionnel

Lorsqu’il faut analyser une politique de sécurité du SI dans un cas, une démarche simple et rigoureuse peut être suivie.

Étape 1 : identifier les actifs et processus critiques

Repérer ce qui doit être protégé en priorité.

Étape 2 : qualifier les principaux risques de cybersécurité

Accès frauduleux, fuite de données, indisponibilité, propagation d’attaque, etc.

Étape 3 : examiner les briques de sécurité présentes ou absentes

• authentification ;
• chiffrement ;
• segmentation ;
• IAM ;
• PCA ;
• PRA.

Étape 4 : apprécier la gouvernance

Qui décide ? Qui met en œuvre ? Qui contrôle ?

Étape 5 : formuler des préconisations hiérarchisées

Prioriser selon la criticité et la faisabilité.

Étape 6 : relier sécurité et résilience

Montrer non seulement comment prévenir, mais aussi comment maintenir et reprendre l’activité.

17. Points clés à retenir

• La politique de sécurité des systèmes d’information est un cadre de gouvernance fondé sur l’analyse des risques.
• Elle participe au pilotage, à la sécurisation et à l’évolution des systèmes d’information.
• Elle vise à gérer les risques de cybersécurité de manière cohérente et proportionnée.
• Elle doit être conçue, mise en œuvre et contrôlée.
• Une architecture de confiance repose notamment sur :
  • l’authentification ;
  • le chiffrement ;
  • la segmentation ;
  • l’IAM ;
  • le PCA ;
  • le PRA.
• L’IAM est essentiel pour maîtriser les identités, habilitations et accès.
• Le PCA organise la continuité ; le PRA organise la reprise.
• La résilience organisationnelle suppose non seulement de prévenir les incidents, mais aussi d’en limiter les effets et de restaurer rapidement les activités critiques.

Mémo de synthèse

Définir et piloter une politique de sécurité du SI

1. Partir des risques

• actifs critiques
• menaces
• vulnérabilités
• impacts
• priorisation

2. Formaliser la politique

• périmètre
• principes directeurs
• rôles et responsabilités
• règles de sécurité
• continuité et reprise

3. Déployer les briques essentielles

• authentification
• chiffrement
• segmentation
• IAM
• PCA
• PRA

4. Contrôler

• indicateurs
• revues
• audits
• tests de restauration
• exercices de crise

5. Améliorer

• retour d’expérience
• correction des écarts
• mise à jour selon l’évolution du SI

En résumé, sécuriser et rendre durable le système d’information, c’est organiser une protection cohérente, gouvernée, testée et capable de soutenir la continuité des activités de l’organisation.