Sécurité cloud en PME : responsabilités et priorités

Par où commencer quand les services cloud se sont accumulés ?

Le point de départ n’est pas l’achat d’un outil de sécurité supplémentaire. C’est la liste des services dont l’entreprise dépend : messagerie, partage de fichiers, logiciel de facturation, portail client, hébergement applicatif et sauvegardes. Pour chacun, identifiez le responsable métier, l’administrateur, les données utilisées et les personnes capables de modifier les accès. Un service sans propriétaire identifié risque de rester oublié lors d’un départ, d’un changement de prestataire ou d’un incident.

Exemple illustratif. Une PME utilise Microsoft 365, un CRM en ligne et un stockage partagé avec ses partenaires. Le CRM sert à préparer les commandes ; la messagerie reçoit les demandes et les coordonnées bancaires ; le stockage contient les dossiers clients. Le premier arbitrage consiste à savoir quels accès pourraient bloquer les ventes ou exposer ces dossiers, plutôt qu’à donner la même priorité à tous les abonnements.

Le guide cloud de l’ANSSI pour les TPE et PME^[1] invite à comprendre les capacités des services et à les configurer selon les besoins de sécurité. À partir de cette base, demandez un inventaire exploitable : usage, données, comptes privilégiés, fournisseur, prestataire et dépendances. Les outils non déclarés doivent y entrer eux aussi ; une application souscrite directement par un métier peut contenir des données importantes.

Qui sécurise quoi entre la PME et le fournisseur ?

Pour votre messagerie SaaS, demandez qui contrôle les comptes administrateurs et qui vérifie une restauration de dossier. Le fournisseur exploite ses centres de données ; cela ne signifie pas qu’il choisit les droits de vos salariés ou les partages de fichiers. Demandez une répartition par service et par contrôle, puis vérifiez qui accomplit réellement la tâche : entreprise, fournisseur ou infogérant.

La documentation Microsoft sur la responsabilité partagée^[2] distingue SaaS, PaaS et IaaS. Les identités, les données et les paramètres contrôlés par le client restent à protéger. AWS décrit également une répartition dépendante du service utilisé^[3]. Ces modèles orientent l’analyse ; ils ne remplacent pas les documents du service exact ni le contrat. Une application hébergée sur une machine virtuelle et une messagerie SaaS n’impliquent pas le même travail de maintenance.

Cette grille est une aide de lecture, pas une matrice contractuelle universelle. Pour chaque ligne, inscrivez un nom et une preuve attendue. « Le prestataire s’en occupe » n’est pas une attribution suffisante si personne ne sait qui vérifie les comptes administrateurs ou qui restaure les données.

Quels comptes et quels droits vérifier en premier ?

Commencez par les comptes capables d’administrer les utilisateurs, d’accéder aux données sensibles ou de modifier les sauvegardes. Demandez la liste de leurs propriétaires, leurs usages et les protections réellement appliquées. Un compte nominatif permet de rattacher une action à une personne ; un compte partagé oblige à prévoir d’autres moyens de traçabilité et complique les départs.

Les bonnes pratiques IAM d’AWS^[4] recommandent notamment le MFA, les droits minimaux, les identifiants temporaires lorsque adaptés et la revue des accès inutilisés. Pour la PME, la question devient : un administrateur peut-il encore se connecter avec un simple mot de passe, et conserve-t-il des droits dont il n’a plus besoin ? Le mécanisme approprié dépend de l’identité utilisée et du service. Les exceptions doivent avoir un propriétaire et une justification.

Situation à examiner. Un ancien salarié conserve son accès au CRM, tandis qu’un ancien prestataire dispose d’un compte administrateur. Il faut rapprocher les comptes actifs des départs et des contrats, puis retirer ou ajuster les droits avec le responsable métier. Ne supprimez pas un compte de service sans vérifier quelle application en dépend : une correction précipitée peut interrompre la facturation.

• Vérifier les administrateurs et les moyens d’authentification effectivement imposés.
• Rapprocher les utilisateurs des salariés, partenaires et prestataires encore autorisés.
• Identifier le propriétaire des comptes techniques et des clés d’API.
• Prévoir une procédure de départ couvrant les différents SaaS, pas seulement la messagerie.

Comment repérer une exposition ou une configuration dangereuse ?

Une « mauvaise configuration » doit devenir une situation vérifiable. Le dossier client est-il accessible par un lien public ? Le portail d’administration est-il exposé sans nécessité ? Une clé d’intégration donne-t-elle accès à tout le stockage alors qu’elle ne sert qu’à lire un dossier ? Demandez une preuve sur le périmètre réel, pas une capture générale annonçant que la sécurité est activée.

Sur Amazon S3, Block Public Access permet de limiter les autorisations publiques^[5]. AWS demande aussi de tenir compte du fonctionnement des applications avant de modifier ces paramètres. Le cas illustre une règle pratique : distinguer une publication volontaire, comme un site web, d’un stockage de documents qui n’a aucune raison d’être public. Ce contrôle précis n’est pas transposable tel quel à tous les clouds.

Pour un partage de devis ou de pièces clients, le responsable métier peut préciser les destinataires attendus ; l’IT vérifie ensuite les autorisations effectives et les exceptions. Si des données ont déjà été exposées, fermer le partage ne suffit pas à déterminer ce qui a été consulté. Il faut conserver les éléments disponibles et analyser la situation avant de conclure à l’absence d’incident.

Pour le dossier client partagé, vérifiez d’abord quels comptes peuvent lire ou exporter les documents, puis demandez comment le stockage et les transferts sont chiffrés. Le chiffrement ne retire pas un droit excessif donné à un utilisateur autorisé : si un ancien prestataire peut toujours télécharger les fichiers, il faut corriger ses autorisations. Notez qui gère les clés et qui pourra récupérer les données en cas de perte d’accès.

Comment vérifier que les données pourront être restaurées ?

Un service disponible, une corbeille, un historique de versions et une sauvegarde ne répondent pas forcément au même besoin. Pour le logiciel de facturation, décrivez ce qu’il faudrait retrouver après une suppression, une erreur de synchronisation ou une compromission : données, pièces jointes, droits et configuration. Demandez ensuite le périmètre couvert, les points de restauration disponibles et les conditions d’accès à la récupération.

Microsoft 365 Backup documente une protection spécifique de SharePoint, OneDrive et Exchange^[6]. Cela ne prouve pas que cette protection est activée dans votre organisation, ni que les mêmes possibilités existent dans un autre SaaS. Vérifiez l’offre réellement souscrite et les objets protégés, sans supposer que tout abonnement cloud inclut une sauvegarde correspondant à votre besoin.

Exemple de vérification. Sur un jeu de données non sensible et avec une opération autorisée, faites restaurer un dossier représentatif. Notez le résultat, les délais constatés, les éléments manquants et la personne qui a pu lancer l’opération. Si l’activité ne peut reprendre qu’après intervention d’un fournisseur externe, cette dépendance doit figurer dans votre organisation de reprise.

Le critère de décision est métier : pouvez-vous recommencer à servir vos clients avec des données utilisables ? Une sauvegarde annoncée comme réussie, sans preuve de récupération, laisse une incertitude. Faites inscrire les écarts dans le plan de traitement plutôt que de déclarer la continuité acquise.

Quels journaux et quelles alertes sont réellement utiles ?

Les journaux servent à comprendre qui s’est connecté, quels droits ont changé et quelles actions administratives ont été réalisées. Ils n’aident que si quelqu’un sait où les trouver, si les événements utiles sont conservés et si les alertes importantes arrivent à une personne capable d’agir. L’achat d’un SIEM n’est pas une condition préalable à cette première organisation.

Microsoft distingue les journaux d’audit et de connexion Entra^[7]. Les premiers retracent notamment des changements sur les applications, groupes et utilisateurs ; les seconds renseignent les accès. La conservation dépend du type de journal et de la licence^[8], avec des possibilités d’archivage. Les journaux Entra et le journal unifié Microsoft 365 sont distincts : une réponse sur l’un ne valide pas automatiquement l’autre.

Demandez une démonstration adaptée à vos usages : retrouver un changement de rôle administrateur, identifier le destinataire d’une alerte et décrire sa conduite en cas d’absence. Pour une PME, une alerte non lue pendant les congés est une faiblesse d’organisation, même si le mécanisme technique fonctionne. La durée nécessaire dépend aussi du temps de détection et de vos contraintes ; n’adoptez pas un chiffre générique sans justification.

Que demander au prestataire avant de considérer le service maîtrisé ?

La proposition doit préciser qui crée les comptes, valide les droits, traite les alertes et teste la restauration. Une formule telle que « sécurité incluse » ne décrit ni le périmètre ni les limites. Demandez comment les changements sont approuvés, comment les accès de ses propres intervenants sont retirés et qui peut vous aider si son équipe habituelle est indisponible.

La CNIL souligne que la qualification des acteurs cloud au sens du RGPD influence les responsabilités^[9], notamment les contrats et la sécurité des données. Le partage opérationnel des tâches et la qualification juridique sont deux analyses à articuler, pas deux expressions interchangeables. Un fournisseur n’est pas automatiquement dans le même rôle pour tous les traitements.

• Qui détient les comptes administrateurs et comment accéderons-nous au service en cas de changement de prestataire ?
• Quels contrôles sont compris, optionnels ou explicitement exclus ?
• Quelles preuves recevrons-nous sur les droits, les alertes et les restaurations ?
• Comment les données et les accès seront-ils restitués ou retirés à la fin du contrat ?

La page Expertise sécurité cloud de Mobhitech présente l’accompagnement professionnel. Le présent guide sert à préparer vos décisions et vos questions ; il ne remplace pas l’examen de votre configuration et de vos engagements.

Exemple d’arbitrage : quelle faiblesse cloud traiter d’abord ?

Le tableau suivant illustre une décision, pas un classement universel. Les priorités changent selon les données, l’exposition et les protections déjà vérifiées. Faites expliciter le responsable, l’action et la preuve de fin avant d’engager le traitement.

Si plusieurs écarts se concurrencent, reliez-les aux activités critiques. Le guide sur la gestion des risques cyber en PME explique cet arbitrage plus largement. Ici, la décision reste centrée sur les accès, les données et la reprise de vos services cloud.

Comment organiser un plan réaliste sans tout changer en même temps ?

Construisez des jalons selon vos moyens et les urgences constatées. Une première étape rassemble l’inventaire, les responsables et les expositions critiques. La suivante produit des preuves sur les droits, les alertes et la restauration. Une dernière étape formalise les revues et les changements à venir. Ces jalons ne sont pas un délai garanti : une exposition active ou un compte compromis exige une réponse adaptée sans attendre le calendrier.

Attribuez chaque action à une personne avec un résultat vérifiable. « Améliorer la sécurité » n’est pas livrable ; « retirer les accès des intervenants dont le contrat est terminé et contrôler les comptes restants » l’est. Faites aussi noter les dépendances : un changement d’identité peut devoir précéder la réduction de droits d’une application.

Un audit cybersécurité peut établir les constats sur un périmètre ; la sécurisation cloud utilise ensuite ces constats pour modifier les configurations, vérifier leur effet et maintenir les contrôles. Si personne ne pilote les arbitrages, un accompagnement RSSI externalisé peut être une option de coordination, sans être une obligation pour toute PME.

Comment savoir si le niveau de sécurité est suffisant ?

Il n’existe pas de preuve unique garantissant qu’un environnement cloud est sûr. Cherchez plutôt une cohérence entre les risques importants, les contrôles en place et les preuves récentes. Vos administrateurs sont-ils protégés ? Les partages sensibles ont-ils des destinataires connus ? Une restauration utilisable a-t-elle été démontrée ? Les alertes ont-elles un responsable et une relève ?

Le suivi doit évoluer avec les usages : nouveau SaaS, nouvelle application, changement de prestataire ou départ d’une personne clé. Une revue ancienne n’atteste pas indéfiniment l’état actuel. Pour chaque risque encore accepté, consignez la raison, le décideur et le déclencheur de réexamen.

La valeur métier n’a pas besoin d’un ROI inventé : des accès retirés évitent de laisser une exposition inutile ; une reprise testée réduit l’incertitude sur la continuité ; des responsabilités écrites évitent d’attendre que chaque intervenant pense que l’autre agit. Aucun de ces contrôles ne permet de promettre une absence d’incident. Ils rendent la décision et la réponse plus solides.