Accueil/Guides pratiques/Sécurité des entreprises

Sécurité des entreprises

Organiser la sécurité d’une entreprise en six étapes

Par où commencer pour sécuriser une entreprise ? Par un service essentiel, ses dépendances et la conséquence d’une interruption. Ce guide relie six décisions de direction à des preuves opérationnelles : responsables nommés, actifs connus, accès limités, fournisseurs vérifiés, reprise exercée et indicateurs expliqués. Le résultat attendu est un plan priorisé que les métiers peuvent comprendre et que l’équipe technique peut contrôler après chaque correction.

SOCCloudResilience
Relais de télécommunications isolé à la tombée du jour, sans personnel
Illustration éditoriale générée par IA

Votre checklist d’action

  1. 01

    Nommer les responsables

    Désignez un sponsor de direction et des responsables opérationnels. Identifiez les prestataires, assureurs et contacts de crise sans confondre contrat de support et capacité de réponse à incident. Pour chaque décision critique, distinguez préparation, autorisation et exécution. Conservez un titulaire et un relais joignable hors des outils habituels. Vérifiez que les contrats indiquent les horaires, limites et prérequis d’intervention avant d’en avoir besoin.

  2. 02

    Identifier les services vitaux

    Définissez les activités indispensables, leurs données et leurs fournisseurs. Faites valider des objectifs de reprise réalistes et testables par les métiers. Décrivez une chaîne complète, par exemple commande, paiement, confirmation et livraison. Une application disponible peut rester inutile si son fournisseur d’identité ou son export comptable ne fonctionne plus. Les objectifs de reprise doivent couvrir ces dépendances.

  3. 03

    Réduire les accès et l’exposition

    Revoir les accès distants, les privilèges, la messagerie et les services exposés. Supprimez les comptes dormants et les usages non approuvés de logiciels ou d’IA. Contrôlez l’arrivée et le départ d’un salarié ou d’un prestataire sur un exemple réel autorisé. Vérifiez que comptes, sessions, clés et accès partagés sont traités ensemble. Toute exception conserve une justification, une date de revue et un responsable.

  4. 04

    Exiger des preuves des fournisseurs

    Vérifiez les responsabilités partagées, les sous-traitants, l’export des données et les procédures de sortie. Demandez des éléments datés adaptés au service, au-delà d’un logo de certification. Posez une question testable : pouvez-vous récupérer vos données dans un format exploitable et redémarrer une activité ? Vérifiez le périmètre des attestations et la date des tests fournis. Un engagement commercial ne remplace pas une démonstration de réversibilité.

  5. 05

    Exercer la continuité

    Simulez une indisponibilité de messagerie ou d’un SaaS critique. Testez les contacts hors ligne, la restauration et les décisions de communication avec les équipes métiers. Annoncez un scénario et mesurez décisions, délais et obstacles, sans perturber la production. Un exercice peut montrer que les contacts ne sont plus valides ou que les moyens de paiement dépendent du même compte que la messagerie.

  6. 06

    Suivre des mesures utiles

    Suivez délais de correction, comptes privilégiés, restauration testée et alertes traitées. Présentez les risques résiduels et les décisions attendues plutôt qu’un score global sans méthode. Associez chaque indicateur à une population, une période et une décision. Distinguez sauvegardes exécutées et restaurations réussies, correctifs déployés et expositions supprimées. Évitez de comparer des pourcentages dont le dénominateur change sans explication.

    Exemple pédagogique : une PME dépend d’une messagerie hébergée pour ses commandes et ses accès administratifs. Rejouez la perte du compte principal avec un contact de secours et un canal indépendant. Vérifiez l’accès aux informations nécessaires à la reprise sans utiliser le compte indisponible. Notez ensuite les dépendances circulaires, le responsable de chaque correction et la preuve attendue au prochain essai.

Références : données, usages et limites

Documentation consultée le .

Références : données, usages et limites
Source et objetDonnée ou repère vérifiéComment l’utiliserLimite à conserver
NIST · Cybersecurity Framework

Structurer les résultats attendus d’un programme de cybersécurité.

CSF 2.0 comporte six fonctions : Govern, Identify, Protect, Detect, Respond et Recover. Le cadre ne prescrit pas une unique façon d’obtenir les résultats. Décrivez un profil actuel et un profil cible avec preuves, écarts et responsables. Rattachez chaque priorité aux services qu’elle aide à protéger.

Approfondir la méthode →

Une correspondance avec le cadre n’équivaut pas à une certification ni à la preuve que chaque contrôle fonctionne.
NIST · SP 800-61 Rev. 3

Préparer la réponse à incident dans la gestion du risque cyber.

La révision 3 a été publiée en avril 2025 et remplace la révision 2. Elle se présente comme un profil communautaire du CSF 2.0. Exercez décision de confinement, conservation des traces, communication et reprise. Comparez ce qui était prévu aux preuves produites pendant l’exercice.

Approfondir la méthode →

Lire le guide ne valide pas un plan local. Les contacts, accès de secours et dépendances doivent être testés dans votre environnement.
NIST · Privacy Framework

Examiner les risques pour les personnes liés au traitement de données.

Le Privacy Framework est un outil volontaire de gestion des risques pour la vie privée. Il se distingue d’une liste unique d’obligations juridiques. Décrivez le traitement réel : données, finalités, destinataires, accès et durées. Comparez documents, configurations et tests de suppression ou de récupération.

Approfondir la méthode →

L’utilisation du cadre ne détermine pas à elle seule la conformité au droit applicable. Le contexte du traitement et la juridiction restent à examiner.

Sécurité email : identité, alignement et transport

Messagerie d’entreprise : séparer identité et disponibilité

Une messagerie peut réussir SPF ou DKIM pour un domaine tiers tout en échouant à l’alignement du domaine From. Documentez chaque prestataire et chaque usage avant d’interpréter un indicateur global.

  • Séparer les alertes critiques, les échanges humains et les campagnes.
  • Associer les résultats d’authentification au domaine réellement évalué.
  • Rapprocher les rapports DMARC des incidents de transport TLS ; ils n’observent pas le même phénomène.

Consulter le comparatif et le simulateur DMARC →

Références et statut consultés le · SPF · RFC 7208 DKIM · RFC 6376 DMARC · RFC 9989

Retry-After : attente, budget et décision de reprise

Une reprise peut amplifier une panne de dépendance

Le délai global et le nombre d’essais doivent traverser les couches de l’intégration. Chaque étage qui réessaie sans coordination peut augmenter le travail final.

  • Identifier client, SDK, proxy et file qui peuvent chacun relancer une demande.
  • Comparer délai serveur, délai local et budget restant avant de relancer.
  • Séparer lecture rejouable et écriture dont l’effet doit d’abord être rapproché.

Explorer Retry-After et le modèle de reprise →

Références relues le · RFC 9110 · §9.2.2, §10.2.3 · RFC 6585 · §4 · AWS

Webhooks : signatures et rejeu

Une reprise API et une reprise webhook suivent deux contrats

Pour une notification entrante, suivez l’événement, la tentative de transport et l’effet métier séparément. La signature authentifie un message ; elle ne constitue pas une clé d’idempotence.

  • Conserver les octets bruts requis et authentifier chaque nouvelle tentative.
  • Préparer une reprise propre au fournisseur : Stripe peut réessayer automatiquement ; GitHub ne relivre pas automatiquement les échecs.
  • Tester réponse perdue, concurrence et rapprochement après panne.

Voir les signatures, les empreintes et les dix cas webhooks →

Sources vérifiées le · Stripe · Webhooks · Stripe · Manage webhook endpoints · GitHub · Validating webhook deliveries · GitHub · Best practices for using webhooks · GitHub · Handling failed webhook deliveries

PDF : expurgation et diffusion

La revue documentaire porte sur le fichier et son partage

Un dossier de confiance numérique doit montrer quels contrôles ont porté sur quelle copie. Une grille de résultats ne remplace ni la vérification des contenus ni celle des accès et versions accessibles.

  • Définir le périmètre de confidentialité et les informations nécessaires au destinataire.
  • Conserver les résultats et les contrôles non réalisés sans les convertir en score rassurant.
  • Faire correspondre la copie approuvée au fichier réellement diffusé.

Voir les surfaces et la matrice de revue avant partage →

Sources vérifiées le · Adobe · Redacting and sanitizing PDFs · Adobe · Redact sensitive content · Adobe · Sanitize PDFs · ICO · Avoid accidental breaches when redacting · ICO · Hidden information in documents · Microsoft · Document Inspector