# Sécurité du cloud et du SaaS (FAQ)

> 25 questions sur Sécurité du cloud et du SaaS, en langage clair : quoi vérifier, ce que montre NetSenX et ce qu'une sonde ne voit pas.

Source page: https://netsenx.com/fr/faq/cloud

## Qu'est-ce que le modèle de responsabilité partagée dans le cloud ?

C'est la répartition des obligations de sécurité entre le fournisseur cloud et vous, et la plupart des incidents cloud se produisent de votre côté de la ligne. Le fournisseur sécurise ce qu'il exploite : centres de données, matériel, réseau qui les relie et, selon le service, le système d'exploitation et l'application elle-même. Vous restez responsable de l'usage : qui a des comptes et avec quels droits, l'authentification multifacteur (MFA), la configuration du stockage et des services, les données que vous y placez, vos propres applications et leurs correctifs, et vos sauvegardes. La ligne se déplace selon le type de service. Avec des serveurs virtuels loués, vous gérez presque tout au-dessus du matériel ; avec un produit SaaS comme une suite bureautique, vous gérez surtout les identités, les réglages de partage et les données. Lisez la matrice de responsabilités de votre fournisseur, attribuez chaque point à un responsable nommé dans l'entreprise et revoyez-la à chaque nouveau service. Les certificats d'un fournisseur couvrent sa part, pas votre configuration.

https://netsenx.com/fr/faq/what-is-the-shared-responsibility-model-in-the-cloud

## Quelle différence entre IaaS, PaaS et SaaS ?

Ces termes décrivent la part de la pile que le fournisseur exploite pour vous, et donc la part du travail de sécurité qui vous reste. Avec l'infrastructure en tant que service (IaaS), vous louez serveurs virtuels, stockage et réseaux ; vous installez et corrigez le système d'exploitation, configurez les pare-feu et faites tourner vos applications : le travail de sécurité ressemble à celui de vos propres serveurs. Avec la plateforme en tant que service (PaaS), le fournisseur gère le système d'exploitation et l'environnement d'exécution, comme une base de données gérée ou une plateforme applicative ; vous restez responsable de votre code, de la configuration, des identités et des données. Avec le logiciel en tant que service (SaaS), vous utilisez une application finie comme la messagerie, le CRM ou la comptabilité ; votre part porte surtout sur qui a accès, avec quels droits et quelle authentification multifacteur, sur le partage des données et sur votre propre copie des données importantes. Beaucoup d'entreprises utilisent les trois à la fois. Classez chaque service selon son type, car les questions d'un auditeur ou d'un assureur diffèrent pour chacun, tout comme les journaux disponibles.

https://netsenx.com/fr/faq/what-is-the-difference-between-iaas-paas-and-saas

## Passer au cloud nous rend-il plus sûrs ?

Cela peut être le cas pour ce que le fournisseur prend en charge, mais cela déplace le risque plus que cela ne le supprime. Un grand fournisseur corrige son infrastructure, exploite des centres de données redondants et emploie des équipes de sécurité que peu d'entreprises moyennes pourraient s'offrir : sécurité physique, pannes matérielles et disponibilité de base s'améliorent en général. Ce qui ne se déplace pas, c'est la responsabilité des identités, de la configuration et des données, qui deviennent plus exposées : un compte d'administration cloud est joignable depuis n'importe où sur internet, un réglage de stockage peut publier des fichiers au monde entier en un clic, et un mot de passe volé sans authentification multifacteur ouvre tout d'un coup. Les attaquants ont suivi les entreprises dans le cloud, et beaucoup des incidents qu'ils y provoquent commencent par un compte hameçonné ou une clé d'accès divulguée. Migrer en sécurité, c'est la MFA sur chaque compte, le moindre privilège pour les administrateurs, une journalisation activée et examinée, des sauvegardes que vous maîtrisez et quelqu'un responsable de la configuration cloud. Le réseau du bureau compte encore : portables, imprimantes et serveurs restés sur place sont souvent l'endroit où un attaquant pose d'abord le pied.

https://netsenx.com/fr/faq/does-moving-to-the-cloud-make-us-safer

## Que voit un capteur réseau de notre trafic cloud et SaaS ?

Les connexions entre vos appareils et le cloud, pas ce qui se passe dans le cloud. Une sonde sur le réseau du bureau ou un agent sur un serveur voit quels appareils se connectent à quels services cloud et SaaS, quand, à quelle fréquence et avec quel volume dans chaque sens, ainsi que le nom du serveur dans la négociation TLS là où les paquets sont capturés. Cela suffit pour remarquer un portable qui envoie des gigaoctets vers un service de stockage jamais utilisé, un serveur qui contacte une machine cloud louée toutes les quelques minutes ou un appareil qui parle à une région inattendue. Il ne voit pas ce que font les utilisateurs dans une application SaaS, comme partager un dossier publiquement, créer une règle de transfert ou accorder à une application l'accès à une boîte aux lettres ; il ne voit pas le trafic entre services cloud ; et il ne voit pas le personnel en télétravail sur des appareils non gérés. Cela relève des journaux d'audit et des consoles d'administration du fournisseur. NetSenX couvre le côté réseau : beaconing, balayages, mouvements latéraux et volumes sortants inhabituels dans chaque offre. Il ne remplace pas les journaux de votre fournisseur cloud.

https://netsenx.com/fr/faq/what-does-a-network-sensor-see-of-cloud-traffic

## NetSenX peut-il surveiller nos serveurs dans le cloud ?

En partie : il voit le comportement réseau des serveurs Linux qui portent son agent, où qu'ils tournent, mais il ne lit pas le plan de contrôle de votre fournisseur cloud. L'agent NetSenX fonctionne sous Linux et macOS : un serveur virtuel Linux que vous exploitez chez un fournisseur cloud peut donc l'accueillir comme n'importe quelle machine Linux ; l'agent voit alors les connexions de ce serveur, et les détections de base s'appliquent dans chaque offre : beaconing vers un serveur de commande et de contrôle, balayages, mouvements latéraux vers d'autres serveurs et volumes de données sortants inhabituels. Chaque serveur de ce type compte comme un appareil de votre offre. Restent en dehors : les services gérés que vous n'exploitez pas vous-même, comme les bases de données, les fonctions serverless et le stockage ; le trafic entre services cloud qui ne passe jamais par un serveur équipé de l'agent ; et tout ce qui relève de la couche d'administration du fournisseur, comme les connexions aux comptes, les changements de droits et la configuration. Pour cela, activez les journaux d'audit et de flux du fournisseur et envoyez-les là où quelqu'un les examine. Les deux vues réunies vous donnent le comportement réseau de vos serveurs et l'activité des comptes autour d'eux.

https://netsenx.com/fr/faq/can-netsenx-monitor-our-cloud-servers

## Comment distinguer un trafic cloud légitime du serveur loué par un attaquant ?

En regardant qui est la destination, comment se comporte la connexion et si quelque chose dans votre activité l'explique. Les attaquants apprécient les serveurs cloud loués, car n'importe qui peut en créer un en quelques minutes et l'adresse appartient à un fournisseur réputé : le nom du fournisseur seul ne prouve donc rien. De meilleures questions : la destination correspond-elle à un service que vous utilisez, d'après son nom dans la négociation TLS ou le DNS, et ce service figure-t-il dans votre liste de fournisseurs ? La connexion est-elle régulière, légère et permanente, comme un programme qui se signale, plutôt que portée par des humains aux heures de travail ? A-t-elle commencé juste après un événement inhabituel sur cet appareil, comme un nouveau programme ou une connexion depuis l'étranger ? Un serveur qui ne fait d'habitude que recevoir des connexions en ouvre-t-il soudain vers l'extérieur ? Un service légitime de sauvegarde ou de supervision a en général une destination documentée et un contrat ; une machine virtuelle inconnue contactée toutes les cinq minutes par un poste de travail, non. NetSenX signale dans chaque offre ce motif de contact régulier, appelé beaconing, et les volumes sortants inhabituels, avec la destination, pour que vous puissiez interroger le bon responsable.

https://netsenx.com/fr/faq/how-to-tell-legitimate-cloud-traffic-from-an-attackers-server

## Lesquels de nos serveurs se connectent à des hébergeurs cloud bon marché, et pourquoi ?

Établissez-le d'abord à partir des connexions, puis interrogez le responsable de chaque serveur, car la plupart de ces connexions ont une explication banale et quelques-unes non. Raisons légitimes : services de supervision et de sauvegarde, miroirs de mises à jour, API d'un fournisseur, machine de test d'un développeur, ou éditeur SaaS hébergé chez un fournisseur à bas coût. Les signes inquiétants sont l'inverse : un serveur qui n'a aucune raison métier de parler à internet, des connexions qui se répètent à intervalles fixes jour et nuit, un trafic apparu après un incident ou une nouvelle installation, et des destinations que personne dans l'entreprise ne reconnaît. Les serveurs virtuels loués chez des hébergeurs bon marché sont un lieu courant pour les serveurs de commande des attaquants et pour l'entreposage de données volées, justement parce qu'ils sont peu chers, rapides et anonymes à louer. Tenez la liste des destinations attendues par serveur, revoyez-la avec les responsables et bloquez le trafic sortant des serveurs qui n'en ont pas besoin. Dans chaque offre, NetSenX montre les connexions de vos hôtes avec leurs destinations et alerte sur le beaconing et les volumes sortants inhabituels, les comportements qui comptent le plus ici.

https://netsenx.com/fr/faq/why-do-our-servers-connect-to-cheap-cloud-hosting-providers

## Les attaquants peuvent-ils cacher leur commande et contrôle dans des services cloud de confiance ?

Oui, et ils le font, car le trafic vers un service cloud connu est rarement bloqué ou remis en question. Un logiciel malveillant peut récupérer des instructions dans un fichier d'un compte de stockage cloud public, un document partagé, un site d'hébergement de code, l'interface de robot d'une messagerie ou un réseau de diffusion de contenu, et renvoyer les données volées par le même chemin. Pour un pare-feu qui juge les destinations à leur réputation, cela ressemble à un salarié ordinaire utilisant un service populaire. Ce qui le trahit encore, c'est le comportement. Un programme qui consulte un fichier cloud à intervalles réguliers, jour et nuit, depuis un appareil dont l'utilisateur ne travaille pas, a un rythme qu'aucun humain n'a ; les envois peuvent être inhabituellement volumineux pour cet appareil ; et l'empreinte du client dans la négociation TLS peut ne correspondre ni à un navigateur ni à l'application officielle du service. Mesures pratiques : n'autorisez que les services cloud dont l'activité a besoin, par locataire quand vos outils le permettent, et examinez les appareils qui parlent à des comptes personnels de services populaires. NetSenX détecte le beaconing et les volumes sortants inhabituels dans chaque offre, quelle que soit la destination, et les empreintes TLS dès l'offre Starter là où l'agent capture les paquets.

https://netsenx.com/fr/faq/can-attackers-use-trusted-cloud-services-for-command-and-control

## Comment distinguer une synchronisation cloud légitime d'un vol de données ?

Comparez le transfert avec ce que fait habituellement cet appareil et avec les outils que l'entreprise utilise réellement. Un client de synchronisation qui envoie des fichiers vers le service de stockage approuvé suit un schéma : il tourne sur les postes de ceux qui l'utilisent, son volume suit les heures de travail et la destination est le service que vous payez. Un vol de données diffère en général sur au moins un point : c'est un serveur, et non un poste, qui envoie beaucoup ; la destination est un compte de stockage personnel ou inconnu, un site de partage de fichiers ou un serveur loué ; le volume dépasse de loin le niveau habituel de cet hôte ; cela se passe la nuit ou le week-end ; ou cela suit d'autres signaux d'alerte comme des balayages ou de nouvelles connexions d'administrateurs. Les outils qu'utilisent les attaquants pour cela, comme des utilitaires de synchronisation en ligne de commande, ressemblent souvent à une sauvegarde légitime. Interrogez d'abord le responsable de l'hôte, puis consultez les journaux du fournisseur de stockage pour le compte utilisé. Dans chaque offre, NetSenX alerte sur les volumes de données sortants inhabituels par hôte et montre la destination ; il ne voit pas quels fichiers ont été envoyés.

https://netsenx.com/fr/faq/how-to-tell-a-cloud-sync-from-data-theft

## Peut-on voir si un salarié sur le départ envoie des données de l'entreprise dans le cloud ?

Vous pouvez voir si un appareil de l'entreprise envoie des quantités inhabituelles de données vers des services cloud, souvent le signal précoce le plus utile, mais pas qui l'a fait ni quels fichiers. Dans les semaines qui précèdent un départ, une forte hausse des envois depuis son portable vers un stockage personnel, un site de transfert de fichiers ou un outil d'IA mérite une discussion, surtout à des heures inhabituelles. Un bon processus de départ compte davantage que la détection : convenir par écrit de ce qui reste à l'entreprise, retirer l'accès aux comptes SaaS et cloud le dernier jour, révoquer jetons et mots de passe d'application, vérifier liens de partage et règles de transfert dans la messagerie et le stockage, et récupérer les appareils. La prévention des fuites de données et les journaux d'audit de vos services de stockage et de messagerie peuvent montrer des noms de fichiers ; un capteur réseau, non. Gardez tout examen proportionné, centré sur les appareils et les données de l'entreprise, et convenu avec les RH et, si nécessaire, les représentants du personnel, car la surveillance des salariés est encadrée dans chaque pays de l'UE. Dans chaque offre, NetSenX alerte sur un volume de données sortant inhabituel depuis un appareil et montre la destination.

https://netsenx.com/fr/faq/can-we-see-if-a-leaving-employee-uploads-company-data-to-the-cloud

## Un rançongiciel peut-il atteindre les fichiers que nous gardons dans le cloud ?

Oui, surtout par les appareils et les comptes qui les synchronisent ou les administrent. Quand un rançongiciel chiffre des fichiers sur un portable dont les dossiers sont synchronisés avec un stockage cloud, le client de synchronisation envoie fidèlement les versions chiffrées, et les copies cloud changent aussi. Un attaquant muni d'un compte d'administration volé peut supprimer ou chiffrer des données directement dans le service, effacer sauvegardes et versions, ou tout exfiltrer d'abord et menacer de publier. Ce qui aide : gardez le versionnage des fichiers activé avec un historique suffisant et sachez restaurer un dossier entier d'un coup ; protégez les comptes d'administration par une authentification multifacteur résistante à l'hameçonnage et séparez-les des comptes du quotidien ; activez la protection contre la suppression ou les verrous de conservation quand le service les propose ; gardez une sauvegarde indépendante que les mêmes administrateurs ne peuvent pas supprimer ; et limitez la synchronisation aux dossiers dont les gens ont besoin. Surveillez les étapes qui précèdent le chiffrement, car c'est là qu'on peut encore intervenir : dans chaque offre, NetSenX détecte le beaconing, les balayages, les mouvements latéraux et les volumes sortants inhabituels, y compris les gros envois vers un stockage cloud. Il ne voit pas les actions menées dans la console d'administration du service cloud.

https://netsenx.com/fr/faq/can-ransomware-reach-our-cloud-files

## Nos données SaaS sont-elles sauvegardées par le fournisseur ?

En général, pas de la manière dont vous en avez besoin. Les fournisseurs SaaS protègent leur service contre leurs propres pannes, avec un stockage redondant et une reprise après sinistre, mais ils ne promettent en général pas de restaurer vos données après une action menée dans votre compte par vous ou par un attaquant. Les éléments supprimés restent dans les corbeilles et historiques de versions pendant une durée limitée, puis disparaissent ; une attaque par rançongiciel qui chiffre des fichiers synchronisés, un administrateur malveillant qui supprime des boîtes aux lettres ou une erreur de synchronisation qui écrase un dossier peuvent dépasser ces délais ; et à la fin d'un abonnement ou d'une licence utilisateur, les données peuvent être supprimées. Lisez les conditions de votre fournisseur : la plupart décrivent ce partage dans le cadre de la responsabilité partagée. Si les données comptent, gardez votre propre copie : un service de sauvegarde ou un export qui copie courriels, fichiers et données applicatives clés vers un stockage que les administrateurs SaaS ne peuvent pas effacer, conservé aussi longtemps que vos besoins métier et juridiques l'exigent. Testez au moins une fois la restauration d'une boîte aux lettres et d'un dossier, car c'est là que les lacunes apparaissent. Un capteur réseau n'aide pas ici ; c'est une question de sauvegarde et de conservation.

https://netsenx.com/fr/faq/is-our-saas-data-backed-up-by-the-provider

## Comment sécuriser nos comptes Microsoft 365 ou Google Workspace ?

Commencez par les identités, car la plupart des prises de contrôle de comptes partent d'un mot de passe hameçonné ou réutilisé. L'essentiel, dans l'ordre : authentification multifacteur pour chaque utilisateur, avec des méthodes résistantes à l'hameçonnage comme les clés de sécurité ou les passkeys pour les administrateurs ; des comptes d'administration séparés, réservés à l'administration, et le moins possible d'administrateurs globaux ; les anciens protocoles d'authentification qui contournent la MFA désactivés ; des règles de connexion bloquant les lieux à risque ou les appareils non gérés si votre licence le permet ; une journalisation d'audit activée et conservée assez longtemps pour enquêter ; des alertes sur les nouvelles règles de transfert de courrier, les nouveaux rôles d'administration et les nouvelles autorisations d'applications OAuth ; des limites au partage externe et aux applications tierces que les utilisateurs peuvent connecter ; et une sauvegarde du courrier et des fichiers hors du fournisseur, car ses corbeilles ne sont pas une sauvegarde. Revoyez rôles d'administration et comptes invités chaque trimestre. L'essentiel relève d'une configuration déjà payée. Un capteur réseau ne voit pas ce qui se passe dans ces services ; il ajoute la vue des appareils qui s'y connectent, comme un portable qui se met au beaconing après l'ouverture d'une pièce jointe piégée.

https://netsenx.com/fr/faq/how-to-secure-microsoft-365-and-google-workspace-accounts

## Qu'est-ce que l'hameçonnage par consentement OAuth ?

C'est une attaque où la victime est amenée à accorder à une application malveillante l'accès à son compte, au lieu de livrer son mot de passe. L'utilisateur reçoit un lien vers ce qui ressemble à une application utile ou à une demande de document, se connecte sur la vraie page Microsoft ou Google et clique pour approuver des permissions comme lire ses courriels, fichiers ou contacts. Dès lors, l'application de l'attaquant détient un jeton qui fonctionne sans mot de passe et survit souvent à un changement de mot de passe et à l'authentification multifacteur, puisque l'utilisateur a consenti. L'attaque est efficace justement parce que toutes les pages vues par la victime sont authentiques. Défenses : restreignez le consentement des utilisateurs pour que seuls les éditeurs vérifiés ou les applications approuvées par un administrateur puissent recevoir un accès, exigez une revue d'administrateur pour les permissions à haut risque, déclenchez des alertes sur les nouveaux consentements et revoyez régulièrement la liste des applications connectées en supprimant ce que personne ne reconnaît. Si vous trouvez une autorisation malveillante, révoquez l'application et ses jetons, puis vérifiez dans les journaux d'audit ce à quoi elle a accédé. Un capteur réseau ne voit pas les consentements, qui ont lieu chez le fournisseur d'identité ; c'est là que se placent les contrôles.

https://netsenx.com/fr/faq/what-is-oauth-consent-phishing

## Quels journaux cloud et SaaS activer et conserver ?

Ceux dont vous aurez besoin pour dire ce qui s'est passé après un incident : qui s'est connecté, ce qui a changé et à quelles données on a accédé. Pour chaque service cloud ou SaaS, vérifiez que sont activés : les journaux de connexion avec lieu et appareil ; les changements d'administration et de configuration, comme les nouveaux rôles, règles, règles de transfert et consentements d'applications ; les accès aux fichiers et boîtes aux lettres quand le service le permet ; l'activité des API pour les comptes cloud ; et les journaux de flux réseau de vos réseaux cloud si vous y faites tourner des serveurs. Vérifiez ensuite la durée de conservation par défaut de chacun, car certains services ne gardent qu'une courte fenêtre à moins de payer plus ou d'exporter. Stockez des copies là où les administrateurs du service ne peuvent pas les effacer, pour qu'un attaquant doté de droits d'administration ne puisse pas effacer la trace. Décidez qui les examine et quels événements déclenchent une alerte. La notification des incidents au titre de NIS2 et du RGPD, comme votre assureur, attendra que vous reconstituiez une chronologie. Un capteur réseau en apporte le côté appareils : NetSenX conserve les alertes pendant la durée prévue par votre offre, avec hôtes, destinations et horaires.

https://netsenx.com/fr/faq/what-logs-should-we-keep-for-cloud-and-saas

## Que se passe-t-il si des clés d'accès cloud fuitent, par exemple sur GitHub ?

En général rien de bon, et vite, car les attaquants scrutent en permanence les dépôts de code publics à la recherche de clés. Une clé d'accès cloud ou un jeton d'API agit comme un mot de passe qui ne demande jamais d'authentification multifacteur : qui la détient peut utiliser le compte avec les droits de la clé depuis n'importe où. Les abus typiques vont du lancement de ressources de calcul coûteuses pour miner des cryptomonnaies à la copie de buckets de stockage et de bases de données, jusqu'à la création de nouveaux utilisateurs pour garder l'accès après la révocation de la clé. Les fuites passent par du code poussé dans des dépôts publics ou partagés, des fichiers de configuration dans des sauvegardes, des captures d'écran, des journaux d'intégration continue et des messages de discussion. Si cela arrive : révoquez ou renouvelez la clé immédiatement, pas après l'enquête ; examinez les journaux d'activité du compte pour tout ce qui a été fait avec elle depuis la fuite, y compris de nouveaux utilisateurs, clés et ressources dans des régions inhabituelles ; supprimez ce que l'attaquant a créé ; et vérifiez la facturation. Pour l'éviter, utilisez l'analyse des secrets dans vos dépôts, des identifiants à courte durée de vie plutôt que des clés permanentes, des droits étroits par clé et des alertes budgétaires. Un capteur réseau ne voit pas une clé publiée sur internet ; il peut en voir les conséquences sur les serveurs qu'il surveille.

https://netsenx.com/fr/faq/what-happens-if-cloud-access-keys-leak

## Qu'est-ce qu'un bucket de stockage mal configuré et comment l'éviter ?

C'est un stockage cloud lisible, voire modifiable, par plus de monde que prévu, souvent par n'importe qui sur internet. Les services de stockage objet permettent de partager publiquement un bucket ou un conteneur par un seul réglage ou un lien, utile pour les images d'un site web et dangereux pour des sauvegardes, des exports, des factures ou des fichiers clients. Beaucoup d'expositions de données médiatisées n'étaient pas des piratages, mais des fichiers trouvés par quelqu'un qui cherchait des buckets ouverts. On l'évite avec quelques habitudes : activez chez le fournisseur le blocage de l'accès public au niveau du compte, sauf si un bucket doit vraiment être public, et gardez le contenu public dans des buckets séparés au nom explicite ; préférez des liens signés à durée limitée au partage public ; chiffrez les données et limitez qui peut modifier les réglages de partage ; utilisez les contrôles de configuration du fournisseur ou un outil de posture qui signale le stockage public ; et passez en revue les liens de partage du stockage SaaS, comme les liens qui fonctionnent pour quiconque les possède. Vérifiez après chaque nouveau projet, car les buckets de test sont un coupable fréquent. Un capteur réseau ne voit pas les réglages des buckets ; cela relève de la gestion de la configuration cloud.

https://netsenx.com/fr/faq/what-is-a-misconfigured-storage-bucket

## Qu'est-ce que le service de métadonnées cloud et pourquoi intéresse-t-il les attaquants ?

C'est une adresse interne spéciale présente sur chaque machine virtuelle cloud, depuis laquelle la machine peut lire des informations sur elle-même, y compris des identifiants temporaires correspondant aux permissions qui lui sont attribuées. Les logiciels qui tournent sur le serveur utilisent ces identifiants pour accéder au stockage, aux bases de données et à d'autres services cloud sans mot de passe dans leur configuration, ce qui est une bonne pratique. Le risque est que tout ce qui peut faire envoyer au serveur une requête web vers cette adresse peut aussi lire ces identifiants. Une voie courante est la falsification de requête côté serveur (SSRF) : une faille d'application web qui permet à un attaquant de faire récupérer par le serveur l'URL de son choix. Avec les identifiants en main, l'attaquant agit dans votre compte cloud avec les permissions du serveur. Défenses : exigez la version plus récente, fondée sur une session, du service de métadonnées quand votre fournisseur la propose, car elle bloque les requêtes falsifiées simples ; ne donnez à chaque rôle de serveur que les permissions nécessaires ; corrigez les failles SSRF et validez les URL que les applications récupèrent ; et déclenchez une alerte quand des identifiants issus du rôle d'un serveur sont utilisés depuis l'extérieur de votre environnement, ce que les journaux d'activité du fournisseur peuvent montrer.

https://netsenx.com/fr/faq/what-is-the-cloud-metadata-service-and-why-do-attackers-want-it

## Comment repérer du minage de cryptomonnaie dans un compte cloud compromis ?

En général d'abord sur la facture, c'est pourquoi les alertes budgétaires sont la détection la moins chère à mettre en place. Les attaquants qui obtiennent des identifiants cloud lancent souvent de nombreuses machines virtuelles ou conteneurs puissants, fréquemment dans des régions que vous n'utilisez jamais, pour miner de la cryptomonnaie à vos frais. Signes : hausse soudaine des dépenses de calcul ou du nombre d'instances, machines dotées de GPU que personne n'a commandées, nouvelles ressources dans des régions inconnues, nouvelles clés d'accès ou nouveaux utilisateurs créés au même moment, et serveurs à pleine charge processeur jour et nuit. Sur un serveur que vous exploitez, un processus de minage se voit aussi sur le réseau : des connexions régulières et durables vers des pools de minage, souvent sur des ports inhabituels, depuis une machine qui ne sert d'ordinaire que des requêtes web. Réagissez en révoquant les identifiants utilisés, en supprimant ce que l'attaquant a créé dans toutes les régions, en cherchant des mécanismes de persistance comme de nouveaux utilisateurs, rôles et fonctions planifiées, et en interrogeant le fournisseur sur les frais. NetSenX voit le comportement réseau des serveurs équipés de son agent, comme des connexions régulières vers une destination inconnue ; il ne surveille ni votre facture cloud ni les ressources sans agent.

https://netsenx.com/fr/faq/how-to-spot-cryptomining-in-a-compromised-cloud-account

## Comment trouver les applications SaaS que personne n'a approuvées ?

Combinez quelques sources peu coûteuses, car aucune ne voit tout. Le fournisseur d'identité montre à quelles applications les gens se connectent avec leur compte d'entreprise, y compris les applications OAuth reliées à la messagerie ou aux fichiers. Notes de frais et relevés de carte révèlent les abonnements achetés par les équipes. La gestion des navigateurs et des postes peut lister les extensions et applications de bureau installées. Les journaux DNS et ceux du pare-feu ou du proxy montrent quels services joignent les appareils de l'entreprise. Triez ensuite la liste : outils qui doublonnent un outil approuvé, outils qui détiennent des données de l'entreprise ou des clients, et outils anodins. Pour chaque outil qui traite des données, décidez de l'approuver en bonne et due forme, avec contrat et contrôle d'administration, de le remplacer ou de le retirer, et expliquez pourquoi aux utilisateurs. Fait une fois par trimestre, cela garde la liste courte. Une vue réseau aide pour la partie connexions : NetSenX montre quels hôtes se connectent à quelles destinations, avec une vue dédiée aux services d'IA dès l'offre Pro ; il n'identifie pas chaque application SaaS par son nom et ne voit ni les connexions aux comptes ni les consentements d'applications, qui relèvent du fournisseur d'identité.

https://netsenx.com/fr/faq/how-to-find-saas-apps-nobody-approved

## Que sont le CSPM, le CASB et le SSPM, et en avons-nous besoin ?

Ce sont trois familles d'outils de sécurité cloud qui regardent des choses différentes. La gestion de la posture de sécurité cloud (CSPM) vérifie la configuration de vos comptes cloud, comme un stockage public, des règles de pare-feu ouvertes, un chiffrement absent ou des permissions trop larges, au regard des bonnes pratiques, et signale les dérives. La gestion de la posture de sécurité SaaS (SSPM) fait de même pour les applications SaaS, en contrôlant des réglages comme l'obligation de MFA, le partage externe et les rôles d'administration. Un courtier de sécurité d'accès au cloud (CASB) se place entre les utilisateurs et les services cloud, via un proxy ou les API des fournisseurs, pour découvrir les services utilisés et appliquer des règles, comme bloquer l'envoi de données sensibles. En avoir besoin dépend de la taille. Une entreprise avec un compte cloud et une suite bureautique peut souvent aller loin avec les recommandations intégrées et les tableaux de score de sécurité des fournisseurs, sans surcoût. Plusieurs comptes cloud, de nombreux outils SaaS ou des données réglementées rendent les outils dédiés plus intéressants. Aucun ne surveille le comportement des appareils de votre réseau ; c'est une autre couche, que couvre la détection réseau.

https://netsenx.com/fr/faq/what-are-cspm-casb-and-sspm

## Que demander à un éditeur SaaS sur la sécurité avant de signer ?

Posez des questions dont les réponses sont vérifiables et qui comptent si quelque chose tourne mal. Preuves : quels rapports ou certificats indépendants couvrent le service acheté, comme un rapport SOC 2 Type II ou un certificat ISO/IEC 27001, avec périmètre et date, et pouvez-vous les lire ? Données : où sont-elles stockées et traitées, quels sous-traitants interviennent, servent-elles à entraîner des modèles, combien de temps sont-elles conservées et comment les récupérer dans un format exploitable en partant ? Accès : authentification unique, MFA imposée, droits par rôles et journaux d'audit exportables. Incidents : en combien de temps vous préviennent-ils, par quel canal, et quel soutien apportent-ils à vos propres obligations de notification au titre du RGPD ou de NIS2 ? Résilience : sauvegardes, objectifs de restauration et protection contre le détournement d'un compte d'administration. Vulnérabilités : comment traitent-ils les signalements et à quelle vitesse corrigent-ils ? Inscrivez les réponses clés dans le contrat ou l'accord de traitement des données, pas seulement dans un questionnaire. Un éditeur plus petit aux réponses claires et honnêtes peut être plus sûr qu'un grand aux réponses vagues.

https://netsenx.com/fr/faq/what-should-we-ask-a-saas-vendor-about-security

## Qui est responsable quand notre fournisseur SaaS subit une violation ?

En général les deux, pour des choses différentes. Le fournisseur est responsable de la sécurité de son service et, selon le RGPD, un fournisseur agissant comme votre sous-traitant doit vous notifier dans les meilleurs délais après avoir pris connaissance d'une violation de données à caractère personnel. Vous, en tant que responsable du traitement des données de vos clients ou salariés, restez chargé d'évaluer le risque pour les personnes concernées et, si nécessaire, de notifier l'autorité de contrôle dans les 72 heures après en avoir pris connaissance, ainsi que d'informer les personnes en cas de risque élevé. Si votre entreprise relève de NIS2, un incident important causé par un fournisseur peut déclencher vos propres obligations de notification, et NIS2 attend de vous que vous gériez la sécurité de la chaîne d'approvisionnement dans vos mesures de gestion des risques. Les contrats règlent une grande partie de la pratique : délais de notification, coopération, informations que vous recevrez et responsabilité. Préparez-vous avant : sachez quels fournisseurs détiennent quelles données, gardez leurs contacts sécurité et intégrez la violation chez un fournisseur à votre plan de réponse aux incidents. Votre loi nationale de transposition de NIS2 peut ajouter des détails ; vérifiez-la.

https://netsenx.com/fr/faq/who-is-responsible-when-a-saas-provider-is-breached

## NIS2 nous rend-elle responsables de la sécurité de nos fournisseurs cloud ?

Pas de son exploitation, mais de la gestion du risque qu'elle crée pour vous, si votre entreprise relève de NIS2. La directive (UE) 2022/2555 cite la sécurité de la chaîne d'approvisionnement, y compris les aspects de sécurité des relations avec les fournisseurs directs et les prestataires de services, parmi les mesures de gestion des risques en matière de cybersécurité de l'article 21. Concrètement, il s'agit de savoir de quels fournisseurs cloud et SaaS dépendent vos services importants, d'évaluer leur sécurité, d'inscrire des exigences dans les contrats et de prévoir leur défaillance ou leur compromission. Les fournisseurs de services d'informatique en nuage figurent eux-mêmes dans NIS2 parmi les entités du secteur des infrastructures numériques : beaucoup ont donc leurs propres obligations, ce qui aide sans remplacer votre évaluation. Preuves utiles à demander : rapports d'audit indépendants, certifications au périmètre clair, engagements de notification des incidents et conditions de sortie. Tenez un registre des fournisseurs indiquant les données et services que chacun soutient, et revoyez-le chaque année et après les incidents. Les transpositions nationales peuvent ajouter des exigences ou des recommandations ; vérifiez la loi de votre pays et les publications de votre autorité.

https://netsenx.com/fr/faq/does-nis2-make-us-responsible-for-our-cloud-providers

## Que faire si un compte cloud ou SaaS est compromis ?

Contenir d'abord, comprendre ensuite, et tout consigner au fur et à mesure. Confinement : réinitialisez le mot de passe et révoquez toutes les sessions et jetons actifs du compte ; supprimez les méthodes MFA que vous n'avez pas enregistrées et réenregistrez-les ; recherchez et supprimez les nouvelles règles de transfert, autorisations d'applications, clés d'API, utilisateurs ou rôles d'administration créés par l'attaquant ; et s'il s'agissait d'un compte d'administration, examinez tout le locataire ou tout le compte cloud, car les attaquants créent des portes dérobées. Investigation : utilisez les journaux de connexion et d'audit du fournisseur pour établir quand l'accès a commencé, d'où, et ce qui a été lu, modifié, partagé ou téléchargé ; vérifiez si le même mot de passe servait ailleurs. Décidez ensuite des obligations : un accès à des données personnelles peut impliquer une notification au titre du RGPD dans les 72 heures après en avoir pris connaissance, et un incident important peut devoir être notifié au titre de NIS2 dans votre pays. Regardez aussi les appareils : le mot de passe volé venait souvent d'un portable infecté ou d'une page d'hameçonnage. Dans chaque offre, NetSenX peut montrer si un appareil de votre réseau s'est mis à faire du beaconing, des balayages ou des envois inhabituels à ce moment-là. Il ne voit pas les connexions au compte cloud.

https://netsenx.com/fr/faq/what-to-do-if-a-cloud-account-is-compromised

FAQ: https://netsenx.com/fr/faq