IMPORTANT
Prenez des captures d'écran de chaque tâche de votre travail pour les ajouter à votre portefeuille.
Cet atelier pratique ne peut être réalisé que sur un ordinateur de bureau ou un ordinateur portable.
Vous ne pouvez tenter l'atelier que cinq fois.
Pour rappel, il est normal de ne pas répondre correctement à toutes les questions du premier coup, et même de devoir refaire un exercice. Cela fait partie du processus d'apprentissage.
Une fois l'atelier démarré, le minuteur ne peut pas être mis en pause. Au bout d'une heure et demie, l'atelier se terminera et vous devrez le recommencer.
Pour en savoir plus, consultez le document Conseils techniques pour les ateliers.
Présentation de l'activité
Cet atelier fait partie du projet de synthèse. Dans cet atelier, vous allez mettre en pratique vos connaissances sur la cybersécurité dans le cloud pour identifier et corriger des failles.
Vous allez découvrir un scénario et un ensemble de tâches à effectuer dans Google Cloud Security Command Center. Vous allez devoir utiliser vos compétences pour analyser et corriger des failles actives liées à un incident de sécurité, répondre à des questions sur les failles et relever des défis qui permettront d'évaluer vos compétences en cybersécurité cloud.
L'atelier comporte également plusieurs défis. Un défi est une tâche que vous devez réaliser par vous-même, sans instructions.
En terminant cet atelier, vous démontrerez votre capacité à identifier, hiérarchiser et corriger les failles de sécurité et les erreurs de configuration dans l'environnement cloud. Ces compétences sont essentielles pour renforcer la stratégie de sécurité des environnements Google Cloud, en réduisant le risque de violations de données, d'accès non autorisés et d'autres incidents de sécurité.
Scénario
Vous travaillez depuis un an en tant qu'analyste junior de la sécurité cloud chez Cymbal Retail. Cymbal Retail est un acteur majeur du marché qui exploite actuellement 170 magasins physiques et une plate-forme en ligne dans 28 pays. L'entreprise a généré 15 milliards de dollars de revenus en 2022, et emploie actuellement 80 400 personnes dans le monde.
Cymbal Retail dispose d'une vaste clientèle et enregistre chaque jour une multitude de transactions sur sa plate-forme en ligne. L'entreprise s'engage à assurer la sécurité et la protection de ses clients, de ses employés et de ses actifs, et à veiller à ce que ses opérations respectent les exigences de conformité réglementaire internes et externes dans tous les pays où elle exerce ses activités.
Récemment, l'entreprise a été victime d'une violation massive de ses données. En tant que membre junior de l'équipe de sécurité, vous allez aider l'équipe de sécurité tout au long du cycle de vie de cet incident de sécurité. Vous commencerez par identifier les failles liées à la violation, isoler et contenir celle-ci pour empêcher tout autre accès non autorisé, restaurer les systèmes compromis, corriger les éventuels problèmes de conformité en suspens et vérifier la conformité avec les frameworks.
Voici comment vous allez réaliser cette activité : pour commencer, vous allez examiner les failles et les résultats dans Google Cloud Security Command Center. Puis, vous arrêterez l'ancienne VM et en créerez une nouvelle à partir d'un instantané. Ensuite, vous révoquerez l'accès public au bucket de stockage et passerez au contrôle uniforme des accès au niveau du bucket. Puis, vous limiterez l'accès aux ports du pare-feu et corrigerez les règles de pare-feu. Enfin, vous exécuterez un rapport pour vérifier que les failles ont bien été corrigées.
Préparation
Avant de cliquer sur "Démarrer l'atelier"
Lisez ces instructions. Les ateliers sont minutés, et vous ne pouvez pas les mettre en pause. Le minuteur, qui démarre lorsque vous cliquez sur Démarrer l'atelier, indique combien de temps les ressources Google Cloud resteront accessibles.
Cet atelier pratique vous permet de suivre vous-même les activités dans un véritable environnement cloud, et non dans un environnement de simulation ou de démonstration. Nous vous fournissons des identifiants temporaires pour vous connecter à Google Cloud le temps de l'atelier.
Pour réaliser cet atelier :
- Vous devez avoir accès à un navigateur Internet standard (nous vous recommandons d'utiliser Chrome).
Remarque : Ouvrez une fenêtre de navigateur en mode incognito/navigation privée pour effectuer cet atelier. Vous éviterez ainsi les conflits entre votre compte personnel et le compte temporaire de participant, qui pourraient entraîner des frais supplémentaires facturés sur votre compte personnel.
- Vous disposez d'un temps limité. N'oubliez pas qu'une fois l'atelier commencé, vous ne pouvez pas le mettre en pause.
Remarque : Si vous possédez déjà votre propre compte ou projet Google Cloud, veillez à ne pas l'utiliser pour réaliser cet atelier afin d'éviter que des frais supplémentaires ne vous soient facturés.
Démarrer l'atelier et se connecter à la console Google Cloud
-
Cliquez sur le bouton Démarrer l'atelier. Sur la gauche, vous trouverez le panneau Détails concernant l'atelier, qui contient les éléments suivants :
- Le temps restant
- Le bouton Ouvrir la console Google Cloud
- Les identifiants temporaires que vous devez utiliser pour cet atelier
- D'éventuelles informations complémentaires vous permettant d'effectuer l'atelier
Remarque : Si l'atelier est payant, un pop-up s'affiche pour vous permettre de sélectionner un mode de paiement.
-
Cliquez sur Ouvrir la console Google Cloud (ou effectuez un clic droit et sélectionnez Ouvrir le lien dans la fenêtre de navigation privée) si vous utilisez le navigateur Chrome. La page Se connecter s'ouvre dans un nouvel onglet du navigateur.
Conseil : Vous pouvez réorganiser les onglets dans des fenêtres distinctes, placées côte à côte, pour passer facilement de l'un à l'autre.
Remarque : Si la boîte de dialogue Sélectionner un compte s'affiche, cliquez sur Utiliser un autre compte.
-
Si nécessaire, copiez le nom d'utilisateur Google Cloud ci-dessous et collez-le dans la boîte de dialogue Se connecter. Cliquez sur Suivant.
{{{user_0.username | "Google Cloud username"}}}
Vous trouverez également le nom d'utilisateur Google Cloud dans le panneau Détails concernant l'atelier.
- Copiez le mot de passe Google Cloud ci-dessous et collez-le dans la boîte de dialogue Bienvenue. Cliquez sur Suivant.
{{{user_0.password | "Google Cloud password"}}}
Vous trouverez également le mot de passe Google Cloud dans le panneau Détails concernant l'atelier.
Important : Vous devez utiliser les identifiants qui vous ont été fournis pour l'atelier. N'utilisez pas ceux de votre compte Google Cloud.
Remarque : Si vous utilisez votre propre compte Google Cloud pour cet atelier, des frais supplémentaires peuvent vous être facturés.
- Parcourez les pages suivantes :
- Acceptez les conditions d'utilisation.
- N'ajoutez pas d'options de récupération ni d'authentification à deux facteurs (ce compte est temporaire).
- Ne vous inscrivez pas à des essais sans frais.
Après quelques instants, la console s'ouvre dans cet onglet.
Remarque : Vous pouvez afficher le menu qui contient la liste des produits et services Google Cloud en cliquant sur le menu de navigation en haut à gauche.
Tâche 1 : Analyser la violation de données et recueillir des informations
Un matin, l'équipe de sécurité détecte une activité inhabituelle dans ses systèmes. Une enquête plus approfondie révèle rapidement que l'entreprise a subi une brèche de sécurité massive dans ses applications, ses réseaux, ses systèmes et ses dépôts de données. Les pirates ont obtenu un accès non autorisé à des informations sensibles sur les clients, y compris des données de carte de crédit et des informations personnelles. Cet incident nécessite une attention immédiate et une enquête approfondie. La première étape pour comprendre l'étendue et l'impact de cette violation consiste à recueillir des informations et à analyser les données disponibles.
Dans cette tâche, vous allez examiner les failles et les résultats dans Google Cloud Security Command Center pour déterminer comment les pirates informatiques ont accédé aux données, et vous allez identifier les mesures correctives à prendre.
Important : Les failles listées dans cette section reposent sur des vérifications de sécurité spécifiques qui doivent être effectuées au préalable. Si certaines vérifications n'ont pas encore été effectuées, les failles associées risquent de ne pas apparaître dans Security Command Center lorsque vous aurez terminé les étapes de cette section. Mais ne vous inquiétez pas. Vous pourrez toujours utiliser les informations fournies dans cette tâche pour analyser les résultats disponibles et suivre les étapes de correction dans les tâches suivantes.
Tout d'abord, accédez à Security Command Center pour obtenir une vue d'ensemble des failles actives.
- Dans la console Google Cloud, accédez au menu de navigation (
), puis cliquez sur Sécurité > Aperçu des risques. La page "Présentation" de Security Command Center s'ouvre.
- Dans le volet Erreurs de configuration, sélectionnez l'onglet Par type de ressource. Les résultats de sécurité ou les failles sont organisés en fonction du type de ressource cloud concerné (par exemple, instances, buckets, bases de données). En examinant les failles et les résultats actifs par type de ressource, vous pouvez prioriser et résoudre efficacement les problèmes de sécurité.

Vous remarquerez que le bucket Cloud Storage, la machine virtuelle Compute Instance et le pare-feu comportent des résultats de gravité élevée et moyenne.
Ensuite, accédez au rapport PCI DSS.
- Dans le menu de Security Command Center, cliquez sur Conformité. La page "Conformité" s'ouvre.
- Dans la section Normes de conformité Google Cloud, cliquez sur Afficher les détails dans l'encadré PCI DSS 3.2.1. Le rapport PCI DSS 3.2.1 s'ouvre.
- Cliquez sur la colonne Résultats pour trier les résultats et afficher les résultats actifs en premier.
Remarque : Suivez ces étapes pour évaluer le rapport PCI. N'actualisez pas la page, sinon les filtres requis seront supprimés et les informations qui s'afficheront ne seront pas les bonnes.
La norme PCI DSS (Payment Card Industry Data Security Standard) est un ensemble d'exigences de sécurité que les organisations doivent respecter pour protéger les données sensibles des titulaires de cartes. En tant qu'entreprise de vente au détail qui accepte et traite les paiements par carte de crédit, Cymbal Retail doit également s'assurer de respecter les exigences de la norme PCI DSS afin de protéger les données des titulaires de cartes.
En examinant le rapport PCI DSS 3.2.1, vous remarquez qu'il dresse une liste des règles non conformes liées à la violation de données :
-
La journalisation des règles de pare-feu devrait être activée pour permettre d'auditer les accès au réseau : ce résultat de gravité moyenne indique que la journalisation des règles de pare-feu est désactivée. Cela signifie qu'il n'existe aucun enregistrement des règles de pare-feu appliquées, ni du trafic autorisé ou refusé. Cela représente un risque pour la sécurité, car il est difficile de suivre et d'examiner les activités suspectes.
-
Les règles de pare-feu ne devraient pas autoriser les connexions en provenance de toutes les adresses IP sur le port TCP ou UDP 3389 : ce résultat de gravité élevée indique que le pare-feu est configuré pour autoriser le trafic RDP (Remote Desktop Protocol) pour toutes les instances du réseau depuis l'ensemble d'Internet. Cela présente un risque pour la sécurité, car cela permet à n'importe quel internaute de se connecter au port RDP sur n'importe quelle instance du réseau.
-
Les règles de pare-feu ne devraient pas autoriser les connexions en provenance de toutes les adresses IP sur le port TCP ou SCTP 22 : ce résultat de gravité élevée indique que le pare-feu est configuré pour autoriser le trafic Secure Shell (SSH) vers toutes les instances du réseau depuis l'ensemble d'Internet. SSH est un protocole qui permet d'accéder à un ordinateur à distance de façon sécurisée. Si un pirate informatique parvient à accéder à une machine via SSH, il peut potentiellement voler des données, installer des logiciels malveillants ou perturber les opérations.
-
Il est déconseillé d'attribuer des adresses IP publiques aux VM : ce résultat de gravité élevée indique qu'une adresse IP particulière est activement exposée à l'Internet public et est potentiellement accessible à des personnes non autorisées. Ce résultat est considéré comme un risque de sécurité potentiel, car il pourrait permettre aux pirates informatiques de rechercher des failles ou de lancer des attaques sur la ressource associée.
-
Les buckets Cloud Storage ne doivent pas être accessibles publiquement ou anonymement : ce résultat de gravité élevée indique qu'il existe une entrée de liste de contrôle d'accès (LCA) pour le bucket de stockage qui est accessible publiquement, ce qui signifie que n'importe quel internaute peut lire les fichiers stockés dans le bucket. Il s'agit d'une faille de sécurité à haut risque qui doit être corrigée en priorité.
-
Les instances ne devraient pas être configurées pour utiliser le compte de service par défaut avec un accès complet à toutes les API Cloud : ce résultat de gravité moyenne indique qu'une identité ou un compte de service particulier s'est vu accorder un accès complet à toutes les API Google Cloud. Ce résultat est considéré comme un risque de sécurité important, car il accorde à l'identité ou au compte de service la possibilité d'effectuer n'importe quelle action dans l'environnement Google Cloud, y compris d'accéder à des données sensibles, de modifier des configurations et de supprimer des ressources.
Comme vous vous concentrez sur l'identification et la correction des problèmes liés à l'incident de sécurité, veuillez ignorer les résultats suivants, car ils ne sont pas liés aux tâches de correction que vous effectuez :
-
Les journaux de flux VPC devraient être activés sur chaque sous-réseau du réseau VPC : plusieurs résultats de gravité faible indiquent que les journaux de flux sont désactivés. Cela indique que les journaux de flux ne sont pas activés pour un certain nombre de sous-réseaux dans le projet Google Cloud utilisé pour cet atelier. Cela représente un risque de sécurité potentiel, car les journaux de flux fournissent des informations précieuses sur les schémas de trafic réseau, ce qui peut aider à identifier les activités suspectes et à enquêter sur les incidents de sécurité.
Remarque : Il est important d'activer la journalisation pour les ressources cloud afin de maintenir l'observabilité. Toutefois, vous ne corrigerez pas ce résultat dans cette activité, car les sous-réseaux font partie de l'environnement de l'atelier. Par conséquent, ce résultat restera visible dans le rapport une fois que vous aurez effectué les tâches de correction.
-
Les rôles de base ("Propriétaire", "Rédacteur," "Lecteur") sont trop permissifs et, par conséquent, ne doivent pas être utilisés : ce résultat de gravité moyenne indique que des rôles primitifs sont utilisés dans l'environnement Google Cloud. Cela représente un risque de sécurité potentiel, car les rôles primitifs accordent un accès étendu à un large éventail de ressources.
-
Vous devez définir une règle de refus du trafic de sortie : ce résultat de faible gravité indique qu'aucune règle de refus du trafic sortant n'est définie pour le pare-feu surveillé. Ce résultat soulève des problèmes de sécurité potentiels, car il suggère que le trafic sortant n'est pas limité, ce qui pourrait exposer des données sensibles ou permettre des communications non autorisées.
Le tableau suivant indique pour chaque règle listée dans le rapport la catégorie correspondante de résultats. Par la suite, cela vous aidera à examiner les résultats par type de ressource :
| Catégorie de résultats |
Règle |
| Journalisation des règles de pare-feu désactivée |
La journalisation des règles de pare-feu devrait être activée pour permettre d'auditer les accès au réseau |
| Port RDP ouvert |
Les règles de pare-feu ne devraient pas autoriser les connexions en provenance de toutes les adresses IP sur le port TCP ou UDP 3389 |
| Port SSH ouvert |
Les règles de pare-feu ne devraient pas autoriser les connexions en provenance de toutes les adresses IP sur le port TCP ou SCTP 22 |
| Adresse IP publique |
Il est déconseillé d'attribuer des adresses IP publiques aux VM |
| LCA de bucket publique |
Les buckets Cloud Storage ne doivent pas être accessibles publiquement ou anonymement |
| Accès complet aux API |
Les instances ne devraient pas être configurées pour utiliser le compte de service par défaut avec un accès complet à toutes les API Cloud |
| Journaux de flux désactivés |
Les journaux de flux VPC devraient être activés sur chaque sous-réseau du réseau VPC |
| Rôles primitifs utilisés |
Les rôles de base ("Propriétaire", "Rédacteur," "Lecteur") sont trop permissifs et, par conséquent, ne doivent pas être utilisés |
| Règle de refus du trafic sortant non définie |
Vous devez définir une règle de refus du trafic de sortie |
Globalement, ces résultats indiquent un manque critique de contrôles de sécurité et un non-respect des exigences essentielles de la norme PCI DSS. Ils mettent également en évidence les failles associées à la violation des données.
Ensuite, accédez à Security Command Center et filtrez les résultats pour examiner et analyser plus en détail les failles dans l'environnement Google Cloud.
- Dans la console Google Cloud, accédez au menu de navigation (
), puis cliquez sur Sécurité > Résultats. La page Résultats s'ouvre.
- Dans le panneau Filtres rapides, dans la section Type de ressource, cochez le type de ressource Bucket Google Cloud Storage.
Les résultats actifs suivants concernant le bucket de stockage doivent être affichés :
-
LCA de bucket publique : ce résultat figure dans le rapport PCI DSS et indique que n'importe quel internaute peut lire les données stockées dans le bucket.
-
Stratégie du bucket seulement désactivée : cela indique qu'aucune stratégie de bucket explicite n'est en place pour contrôler qui peut accéder aux données du bucket.
-
Journalisation du bucket désactivée : cela indique qu'aucune journalisation n'est activée pour le bucket. Il sera donc difficile de savoir qui accède aux données.
Ces résultats indiquent que le bucket est configuré avec une combinaison de paramètres de sécurité qui pourraient exposer les données à un accès non autorisé. Vous devez corriger cela en supprimant la liste de contrôle d'accès publique, en désactivant l'accès public au bucket et en activant la règle d'accès uniforme au niveau du bucket.
Remarque : Il est important d'activer la journalisation pour les ressources cloud afin de maintenir l'observabilité. Toutefois, vous ne corrigerez pas le résultat "Journalisation du bucket désactivée" dans cette activité, car cela nécessiterait de travailler sur plusieurs projets. Par conséquent, ce résultat restera visible même après que vous avez effectué les tâches de correction.
- Dans le panneau Filtres rapides, dans la section Type de ressource, décochez la case Bucket Google Cloud Storage et cochez le type de ressource Instance Google Compute.
Les résultats actifs suivants concernant la machine virtuelle nommée cc-app-01 doivent s'afficher :
-
Domaine malveillant : ce résultat indique qu'un domaine connu pour être associé à un logiciel malveillant a été consulté à partir de l'instance google.compute.instance nommée "cc-app-01". Bien que ce résultat soit considéré comme peu grave, il indique qu'une activité malveillante s'est produite sur l'instance de machine virtuelle et qu'elle a été compromise.
-
Démarrage sécurisé Compute désactivé : ce résultat de gravité moyenne indique que le démarrage sécurisé est désactivé pour la machine virtuelle. Cela représente un risque de sécurité, car la machine virtuelle peut démarrer avec du code non autorisé, qui pourrait être utilisé pour compromettre le système.
-
Compte de service par défaut utilisé : ce résultat de gravité moyenne indique que la machine virtuelle utilise le compte de service par défaut. Cela présente un risque pour la sécurité, car le compte de service par défaut dispose d'un niveau d'accès élevé et pourrait être compromis si un pirate informatique accède au projet.
-
Adresse IP publique : ce résultat de gravité élevée figure dans le rapport PCI DSS et indique que la machine virtuelle possède une adresse IP publique. Cela présente un risque de sécurité, car n'importe quel internaute peut se connecter directement à la machine virtuelle.
-
Accès complet aux API : ce résultat de gravité moyenne figure dans le rapport PCI DSS et indique que la machine virtuelle s'est vu accorder un accès complet à toutes les API Google Cloud.
Ces résultats indiquent que la machine virtuelle a été configurée d'une façon qui la rend très vulnérable aux attaques. Pour corriger ces failles, vous allez arrêter la VM d'origine (cc-app-01) et créer une autre VM (cc-app-02) à l'aide d'un instantané propre du disque. La nouvelle VM aura les paramètres suivants :
- Aucun compte de service Compute
- Tag de règle de pare-feu pour une nouvelle règle d'accès SSH contrôlé
- Démarrage sécurisé activé
- Adresse IP publique définie sur "Aucune"
- Dans le champ Période, développez le menu déroulant et sélectionnez 30 derniers jours. Vous vous assurez ainsi que la liste inclut les résultats des 30 derniers jours.
- Dans le panneau Filtres rapides, dans la section Type de ressource, décochez Instance Google Compute et cochez Pare-feu Google Compute.
Les résultats actifs suivants doivent être affichés pour le pare-feu :
-
Port SSH ouvert : ce résultat de gravité élevée indique que le pare-feu est configuré pour autoriser le trafic Secure Shell (SSH) vers toutes les instances du réseau depuis l'ensemble d'Internet.
-
Port RDP ouvert : ce résultat de gravité élevée indique que le pare-feu est configuré pour autoriser le trafic RDP (Remote Desktop Protocol) vers toutes les instances du réseau depuis l'ensemble d'Internet.
-
Journalisation des règles de pare-feu désactivée : ce résultat de gravité moyenne indique que la journalisation des règles de pare-feu est désactivée. Cela signifie qu'il n'existe aucun enregistrement des règles de pare-feu appliquées ni du trafic autorisé ou refusé.
Ces résultats sont tous listés dans le rapport PCI DSS et mettent en évidence une faille de sécurité importante dans la configuration du réseau. L'absence de restriction d'accès aux ports RDP et SSH, associée à la désactivation de la journalisation des règles de pare-feu, rend le réseau très vulnérable aux tentatives d'accès non autorisées et aux violations de données potentielles. Vous devez corriger ces failles en supprimant les règles de pare-feu trop permissives et en les remplaçant par une règle de pare-feu qui autorise l'accès SSH uniquement à partir des adresses utilisées par le service IAP SSH de Google Cloud.
Maintenant que vous avez analysé les failles de sécurité, il est temps de corriger les problèmes signalés dans le rapport.
Tâche 2 : Corriger les failles de Compute Engine
Dans cette tâche, vous allez arrêter la VM vulnérable cc-app-01 et créer une autre VM à partir d'un instantané pris avant l'infection par le logiciel malveillant. Les instantanés de VM sont efficaces pour restaurer le système à un état propre et garantissent que la nouvelle VM ne sera pas infectée par le même logiciel malveillant que la VM d'origine.
- Dans la console Google Cloud, cliquez sur le menu de navigation (
).
- Sélectionnez Compute Engine > Instances de VM. La page "Instances de VM" s'ouvre.
La VM actuelle cc-app-01 doit figurer dans la liste des instances de VM. Il s'agit de la VM vulnérable qui a été compromise et qui doit être arrêtée.
- Cochez la VM cc-app-01.
- Cliquez sur Arrêter.
- Une fenêtre pop-up s'affiche pour vous demander de confirmer l'arrêt de la VM. Cliquez sur Arrêter.
Cliquez sur Vérifier ma progression pour vérifier que vous avez correctement accompli cette tâche.
Arrêter la VM vulnérable
Ensuite, créez une VM à partir d'un instantané. Cet instantané a déjà été créé lors du plan de sauvegarde des données à long terme de Cymbal Retail.
- Dans la barre d'action, cliquez sur + Créer une instance.
- Dans la section Configuration de la machine, saisissez cc-app-02 dans le champ Nom.
- Pour le champ Type de machine, développez le menu déroulant, sélectionnez Cœur partagé, puis e2-medium.
- Cliquez sur la section OS et stockage, puis sur Modifier pour Système d'exploitation et stockage.
- Sélectionnez l'onglet Instantanés.
- Développez le menu déroulant Instantané et sélectionnez cc-app01-snapshot.
- Cliquez sur Sélectionner.
- Dans la section Mise en réseau, saisissez cc dans le champ Tags réseau. Vous utiliserez ce tag pour appliquer des règles de pare-feu à cette VM spécifique.
- Dans la section Interfaces réseau, développez le réseau par défaut.
- Développez le menu déroulant Adresse IPv4 externe et sélectionnez Aucune.
- Dans la section Sécurité, pour la section Identité et accès à l'API, développez le menu déroulant Comptes de service et sélectionnez Compte de service d'utilisateur Qwiklabs.
- Cliquez sur Créer.
La nouvelle VM cc-app-02 doit maintenant être créée à partir de l'instantané cc-app01-snapshot. (Sa création peut prendre quelques minutes.)
Maintenant, activez le démarrage sécurisé pour la nouvelle VM cc-app-02 afin de traiter le résultat Démarrage sécurisé désactivé.
- Cochez la VM cc-app-02.
- Cliquez sur Arrêter.
- Une fenêtre pop-up s'affiche pour vous demander de confirmer l'arrêt de la VM. Cliquez sur Arrêter.
Attendez que la VM cc-app-02 soit arrêtée avant de continuer.
- Dans la section Instances de VM, cliquez sur le lien cc-app-02. La page "cc-app-02" s'ouvre.
- Dans la barre d'outils de cc-app-02, cliquez sur Modifier. La page "Modifier l'instance cc-app-02" s'ouvre.
- Faites défiler la page jusqu'à la section Sécurité et accès, puis, sous VM protégée, cochez Activer le démarrage sécurisé. Cela permettra de traiter le résultat Démarrage sécurisé Compute désactivé.
- Cliquez sur Enregistrer.
- Dans le menu Compute Engine, sélectionnez Instances de VM.
- Cochez la VM cc-app-02.
- Cliquez sur Démarrer/Reprendre.
- Une fenêtre pop-up s'affiche pour vous demander de confirmer le démarrage de la VM. Cliquez sur Démarrer.
L'instance de VM cc-app-02 va redémarrer, et le résultat Démarrage sécurisé désactivé sera corrigé.
Cliquez sur Vérifier ma progression pour vérifier que vous avez correctement accompli cette tâche.
Créer une VM à partir d'un instantané existant
Défi : Supprimer la VM compromise
Supprimez la VM compromise cc-app-01.
Cliquez sur Vérifier ma progression pour vérifier que vous avez correctement accompli cette tâche.
Supprimer la VM compromise
En suivant ces étapes, vous avez créé une VM à partir de l'instantané, vous assurant ainsi qu'elle ne contenait aucun logiciel malveillant ni aucune erreur de configuration. Vous avez également supprimé la VM compromise, ce qui a éliminé la source de la brèche de sécurité.
Tâche 3 : Corriger les autorisations du bucket Cloud Storage
Dans cette tâche, vous allez révoquer l'accès public au bucket de stockage et passer au contrôle uniforme des accès au niveau du bucket, ce qui réduira considérablement le risque de violations des données. En supprimant toutes les autorisations utilisateur du bucket de stockage, vous pouvez empêcher l'accès non autorisé aux données qu'il contient.
- Dans le menu de navigation (
), sélectionnez Cloud Storage > Buckets. La page "Buckets" s'ouvre.
- Cliquez sur le lien du bucket de stockage _bucket. La page "Détails du bucket" s'ouvre.
Vous remarquerez qu'il existe un fichier myfile.csv dans le bucket accessible au public. Il s'agit du fichier contenant les informations sensibles qui ont été extraites par la personne malveillante. Pour traiter le résultat LCA de bucket publique :
-
Cliquez sur l'onglet Autorisations.
-
Dans la section Accès public, cliquez sur Empêcher l'accès public.
-
Cliquez sur Confirmer.
Défi : Modifier l'accès au bucket de stockage
Définissez le contrôle des accès sur "uniforme" et supprimez les autorisations des comptes principaux allUsers du bucket de stockage afin d'appliquer un seul ensemble d'autorisations au bucket et à ses objets. Vous devez également vous assurer que les utilisateurs qui ont besoin des rôles de base pour accéder au bucket ne perdront pas l'accès.
Cliquez sur Vérifier ma progression pour vérifier que vous avez correctement accompli cette tâche.
Modifier l'accès au bucket de stockage
En suivant ces étapes, vous avez empêché l'accès public au bucket, activé le contrôle des accès uniforme au niveau du bucket et supprimé toutes les autorisations utilisateur. Vous avez ainsi corrigé les failles LCA de bucket publique, Stratégie de bucket seulement désactivée et Journalisation de bucket désactivée.
Tâche 4 : Limiter l'accès aux ports du pare-feu
Dans cette tâche, vous allez restreindre l'accès aux ports RDP et SSH en le limitant aux seuls réseaux sources autorisés, afin de réduire la surface d'attaque et le risque d'accès à distance non autorisé.
Faites preuve d'une extrême prudence avant de modifier des règles de pare-feu trop permissives. Les règles peuvent autoriser du trafic légitime, et le restreindre de manière inappropriée pourrait perturber des opérations critiques. Dans cet atelier, vous devez vous assurer que les instances de machine virtuelle Compute Engine taguées avec le tag cible "cc" restent accessibles via des connexions SSH depuis la plage d'adresses Google Cloud Identity-Aware Proxy (35.235.240.0/20). Veillez à ne pas interrompre l'accès aux fonctionnalités de gestion : créez une règle de pare-feu à accès limité pour le trafic SSH avant de supprimer la règle existante qui autorise les connexions SSH depuis n'importe quelle adresse.
Défi : Limiter l'accès SSH
Créez une règle de pare-feu nommée limit-ports. Cette règle doit restreindre l'accès SSH aux adresses IP autorisées du réseau source 35.235.240.0/20 en le limitant aux instances de calcul portant le tag cible cc.
Cliquez sur Vérifier ma progression pour vérifier que vous avez correctement accompli cette tâche.
Limiter l'accès SSH
Tâche 5 : Corriger la configuration du pare-feu
Dans cette tâche, vous allez supprimer trois règles de pare-feu VPC spécifiques qui autorisent un accès illimité à certains protocoles réseau, à savoir ICMP, RDP et SSH, depuis n'importe quelle source au sein du réseau VPC. Ensuite, vous activerez la journalisation sur les règles de pare-feu restantes.
Défi : Personnaliser les règles de pare-feu
Supprimez les règles de pare-feu default-allow-icmp, default-allow-rdp et default-allow-ssh. Étant donné que ces règles sont trop générales, les supprimer permet de créer un environnement réseau plus sécurisé et mieux contrôlé.
En supprimant ces règles, vous avez limité l'accès à ces protocoles, ce qui réduit le risque de tentatives d'accès non autorisées et la surface d'attaque de votre réseau.
Personnaliser les règles de pare-feu
Défi : Activer la journalisation
Activez la journalisation pour les règles de pare-feu restantes : limit-ports (celle que vous avez créée dans une tâche précédente) et default-allow-internal.
L'activation de la journalisation vous permet de suivre et d'analyser le trafic autorisé par cette règle, qui est probablement un trafic interne entre les instances de votre VPC.
Cliquez sur Vérifier ma progression pour vérifier que vous avez correctement accompli cette tâche.
Activer la journalisation
En personnalisant les règles de pare-feu et en activant la journalisation, vous avez corrigé les failles Port SSH ouvert, Port RDP ouvert et Journalisation des règles de pare-feu désactivée. La nouvelle règle de pare-feu protège mieux le réseau et améliore sa visibilité.
Tâche 6 : Vérifier la conformité
Après avoir corrigé avec soin les failles identifiées dans le rapport PCI DSS 3.2.1, il est essentiel de vérifier l'efficacité de vos mesures correctives. Dans cette tâche, vous allez exécuter à nouveau le rapport pour vous assurer que les failles précédemment identifiées ont été corrigées et ne présentent plus de risque pour la sécurité de l'environnement.
- Dans le menu de Security Command Center, cliquez sur Conformité. La page "Conformité" s'ouvre.
- Dans la section Normes de conformité Google Cloud, cliquez sur Afficher les détails dans l'encadré PCI DSS 3.2.1. Le rapport PCI DSS 3.2.1 s'ouvre.
- Cliquez sur la colonne Résultats pour trier les résultats et afficher les résultats actifs en premier.
Toutes les principales failles sont désormais résolues.
Remarque : Bien que vous ayez corrigé les failles de gravité élevée et moyenne, les journaux de flux restent désactivés pour un certain nombre de sous-réseaux. Ce résultat restera visible dans le rapport une fois les tâches de correction effectuées, car il est lié à l'environnement de cet atelier.
Conclusion
Bravo !
Vous avez aidé l'équipe de sécurité de Cymbal Bank à atténuer l'impact de la violation des données, à corriger les failles identifiées et à renforcer considérablement la stratégie de sécurité de l'environnement Google Cloud de Cymbal Bank.
Vous avez d'abord examiné et analysé les failles et les résultats dans Google Cloud Security Command Center.
Puis, vous avez arrêté l'ancienne VM et créé une nouvelle VM à partir d'un instantané pris avant l'infection par le logiciel malveillant.
Ensuite, vous avez corrigé les autorisations Cloud Storage en révoquant l'accès public au bucket de stockage et en activant le contrôle uniforme des accès au niveau du bucket. Vous avez également supprimé toutes les autorisations utilisateur du bucket de stockage.
Ensuite, vous avez corrigé les règles de pare-feu en supprimant les règles default-allow-icmp, default-allow-rdp et default-allow-ssh, et en activant la journalisation pour les règles restantes.
Enfin, vous avez exécuté un rapport de conformité pour vérifier que les problèmes de sécurité ont été corrigés.
N'oubliez pas qu'en tant qu'analyste de la sécurité, il est essentiel que vous réalisiez régulièrement des audits de sécurité et mettiez en place des pratiques de surveillance continue pour assurer une protection constante contre les failles et les menaces en constante évolution.
Terminer l'atelier
Avant de terminer l'atelier, assurez-vous d'avoir bien accompli toutes les tâches. Cliquez alors sur Terminer l'atelier, puis sur Envoyer.
Une fois l'atelier terminé, vous n'aurez plus accès à l'environnement de l'atelier ni au travail que vous avez effectué.
Copyright 2026 Google LLC Tous droits réservés. Google et le logo Google sont des marques de Google LLC. Tous les autres noms de société et de produit peuvent être des marques des sociétés auxquelles ils sont associés.