Protection des données d’entreprise dans le cloud : ce que ça implique vraiment

Externaliser ses données vers le cloud allège l’infrastructure interne, mais déplace la question de sécurité, elle ne la résout pas. Ce que votre fournisseur VPN cloud entreprise garantit et ce qui reste de votre responsabilité sont deux périmètres distincts que beaucoup d’entreprises confondent. Cette page détaille les risques réels, le cadre réglementaire applicable et les mesures qui comptent.

Illustration : VPN Cloud les bonnes pratiques

Sommaire

Le modèle de responsabilité partagée : ce que votre fournisseur ne couvre pas

AWS, Azure, Google Cloud, tous publient un modèle de responsabilité partagée. Le principe est constant : le fournisseur prend en charge une partie de la sécurité de l’infrastructure cloud, dont l’infrastructure physique et une part des couches techniques sous-jacentes ; l’étendue exacte de cette responsabilité dépend du modèle de service utilisé (IaaS, PaaS, SaaS). Ce qui reste invariablement côté client : la configuration des services, la gestion des accès, le chiffrement des données applicatives, le comportement des utilisateurs.

En pratique, cela signifie qu’un bucket S3 mal configuré, des permissions trop larges sur un compte de service, ou des identifiants compromis n’engagent pas la responsabilité d’AWS. Ce sont vos données, votre configuration, votre exposition.

Les erreurs de configuration font partie des causes les plus fréquentes d’exposition dans le cloud. Dans beaucoup d’organisations, le problème vient moins du fournisseur lui-même que d’une gouvernance incomplète des accès, des paramètres et des usages.

Illustration : VPN cloud

Les vecteurs de risque réels

Dans beaucoup d’organisations, les incidents cloud tiennent souvent à trois familles de problèmes :

Erreurs de configuration : stockage ouvert publiquement par inadvertance, règles de pare-feu trop permissives, journalisation désactivée. Ces erreurs sont fréquentes lors de migrations rapides ou de déploiements sans revue de sécurité.

Accès non révoqués : comptes d’anciens collaborateurs, tokens d’API oubliés, accès prestataires jamais désactivés. Le principe du moindre privilège est rarement appliqué avec rigueur dans les PME.

Nomadisme et BYOD : accéder aux ressources internes depuis un réseau Wi-Fi public sans tunnel maîtrisé élargit la surface d’attaque réseau, détournement DNS, portails captifs, exposition de métadonnées, accès à des ressources internes sans politique d’accès appliquée. Le problème n’est pas uniquement le chiffrement du contenu (TLS couvre déjà une partie des échanges applicatifs) mais l’absence de chemin maîtrisé, de point de sortie contrôlé et de politique d’accès uniforme. C’est un vecteur d’exposition fréquent et souvent mal maîtrisé dans les PME.

A lire : Quels VPN Business pour les agences ?

Ce qu’un VPN couvre dans ce contexte et ce qu’il ne couvre pas

Un VPN cloud d’entreprise sécurise le transit des données : la connexion entre le poste du collaborateur et les ressources de l’entreprise est chiffrée, l’adresse IP source est masquée, l’accès aux ressources internes peut être conditionné à une authentification forte.

Ce qu’il ne couvre pas : le chiffrement des données au repos dans le cloud, la gestion des droits d’accès, la configuration des services, la détection des comportements anormaux. Un VPN ne remplace ni une politique IAM rigoureuse, ni le chiffrement at-rest, ni un SIEM.

Pour les environnements majoritairement SaaS, Microsoft 365, Google Workspace, Notion, Slack, Salesforce, le VPN d’entreprise n’est pas toujours le contrôle prioritaire. Selon l’architecture, un accès conditionnel (conditional access), une solution CASB, du device posture checking ou un ZTNA peuvent être plus structurants. Le VPN reste pertinent pour l’accès aux ressources internes et aux environnements hybrides ; il devient insuffisant seul dès que l’essentiel du travail passe par des applications cloud tierces.

Son rôle est précis : imposer un chemin maîtrisé, une politique d’accès uniforme et un périmètre contrôlé pour le trafic vers les ressources internes. C’est une mesure nécessaire dans ce périmètre, pas une réponse universelle.

Illustration : tout au clavier avantages du cloud computing

A découvrir : Comment sécuriser les point d’accès d’un réseau professionnel ?

Les confusions les plus fréquentes

« Nos données sont chez AWS ou Google Cloud, donc elles sont sécurisées. » L’infrastructure peut être robuste, cela ne dit rien sur la qualité de vos configurations, la rigueur de vos droits d’accès ou le comportement de vos utilisateurs. Ce sont trois problèmes distincts que le fournisseur ne résout pas à votre place.

« Le chiffrement natif du stockage suffit. » Il protège les données au repos contre un accès physique non autorisé aux disques. Il ne protège pas contre un compte légitime trop permissif, des identifiants compromis ou un accès prestataire jamais révoqué. Le chiffrement at-rest n’est pas une politique d’accès.

« On utilise surtout Microsoft 365 et Google Workspace, un VPN suffit pour sécuriser nos accès. » Dans un environnement majoritairement SaaS, le tunnel réseau n’est pas le contrôle principal. L’enjeu est l’identité, l’état du terminal et les politiques d’accès conditionnelles. Un collaborateur avec un compte compromis, un terminal non géré ou des permissions trop larges représente un risque que le VPN ne réduit pas.

Ce qu’il faut prioriser selon votre environnement

Les bonnes mesures ne sont pas les mêmes selon l’architecture réelle de votre organisation.

PME majoritairement SaaS : MFA sur tous les comptes, accès conditionnel, gestion des terminaux (MDM), revue régulière des droits, journalisation des connexions. Le VPN est secondaire si vos ressources internes sont limitées.

PME hybride avec ressources internes : VPN ou ZTNA pour l’accès distant, segmentation des accès, bastion d’administration, logs centralisés. Le tunnel réseau maîtrisé devient ici structurant.

Données sensibles ou contraintes sectorielles : localisation des données, gouvernance des clés de chiffrement, choix du fournisseur (SecNumCloud), traçabilité complète, exigences contractuelles répercutées sur les prestataires.

Les mesures qui comptent

Chiffrement in-transit : TLS 1.2 minimum, TLS 1.3 dès que possible, et VPN ou ZTNA pour les accès distants aux ressources internes.

Journalisation et détection : activer les logs d’accès et de configuration. Définir des alertes sur les comportements anormaux (connexions depuis des géographies inhabituelles, volumes de téléchargement atypiques).
Chiffrement at-rest : activer le chiffrement natif des services de stockage (S3, Azure Blob, GCS). Gérer les clés séparément si le niveau de sensibilité le justifie (KMS, HSM).
Sauvegardes et restauration : conserver des sauvegardes séparées du système principal, vérifier leur intégrité et tester réellement la restauration. Une sauvegarde non testée est une hypothèse, pas une garantie.
IAM strict : principe du moindre privilège appliqué systématiquement. Revue régulière des accès. Suppression immédiate des comptes lors des départs. MFA obligatoire sur tous les comptes à privilèges.

Plan de réponse aux incidents : définir avant l’incident qui fait quoi, dans quel délai, avec quelles procédures de notification, y compris les obligations RGPD (72h pour notifier la CNIL en cas de violation).

Le risque principal du cloud n’est pas l’hébergement externalisé lui-même. C’est la croyance qu’un fournisseur, même excellent, absorbe à votre place la responsabilité des accès, des configurations et de la gouvernance. Cette confusion alimente une part importante des expositions dans le cloud. Dans de nombreuses organisations, les incidents tiennent moins à une défaillance du fournisseur qu’à des droits trop larges, des configurations fragiles ou une gouvernance incomplète.

Share This