Différences

Ci-dessous, les différences entre deux révisions de la page.

--- issue100:site_web_from_scratch [2015/09/14 00:04] – d52fr
+++ issue100:site_web_from_scratch [2015/09/15 11:14] (Version actuelle) – auntiee
@@ Ligne 11: / Ligne 11: @@
 Titre : Site Web avec infrastructure à partir de 0
-Le but de cette série, surtout destinée aux débutants,  est de vous guider pas-à-pas dans la construction d'un site Web, avec toute l'infrastructure Linux - à partir de zéro. En bref, déployer une distribution Linux (Ubuntu) dans le nuage, sécuriser l'OS, installer le serveur Web Apache et sécuriser Apache.
+Le but de cette série, surtout destinée aux débutants, est de vous guider pas à pas dans la construction d'un site Web, avec toute l'infrastructure Linux, à partir de zéro. En bref, déployer une distribution Linux (Ubuntu) dans le Nuage, sécuriser l'OS, installer le serveur Web Apache et sécuriser Apache.
 Vous pourriez vous demander pourquoi nous ferions tout ça alors qu'il est si facile et possible de prendre une solution hôte peu chère et complète comme Wordpress ?
-Je crois fortement qu'il n'y a pas de « solution universelle » - la construction à partir de zéro remplira totalement vos besoins, alors que la solution toute faite ne le fera probablement pas. À l'inverse, une solution « prête à l'emploi », particulièrement en open source, peut fournir une fonctionnalité (complexe) directement à l'installation, épargnant du temps de développement, et en général gratuite.
+Je crois fortement qu'il n'y a pas de « solution universelle », la construction à partir de zéro répondra entièrement à vos besoins, alors que la solution toute faite ne le fera probablement pas. À l'inverse, une solution « prête à l'emploi », particulièrement en Open Source, peut fournir une fonctionnalité (complexe) directement à l'installation, épargnant du temps de développement et, en général, gratuite.
-Mais la raison principale d'une construction intégrale est d'apprendre ! Quand j'ai construit le site Web de ma femme à partir de rien, j'ai beaucoup appris - principalement autour de la sécurité, du paramétrage de l'OS et d'Apache - en d'autres mots, j'ai acquis un expérience inestimable de Linux.
+Mais la raison principale d'une construction intégrale est d'apprendre ! Quand j'ai construit le site Web de ma femme à partir de rien, j'ai beaucoup appris, principalement pour ce qui concerne la sécurité et le paramétrage de l'OS et d'Apache ; autrement dit, j'ai acquis une expérience inestimable de Linux.
 **Enough talking – let's start!
@@ Ligne 37: / Ligne 37: @@
 • Choose “Create a new droplet” (“droplet” is just a VM).**
-Assez parlé - Commençons !
+Assez parlé - commençons !
 Voici, au niveau global, ce que nous allons réaliser :
-• Premièrement, déployer Linux VM (Virtual Machine - machine virtuelle) dans le Nuage,
+• Premièrement, déployer une VM (Virtual Machine - machine virtuelle) Linux dans le Nuage,
-• ensuite, nous allons sécuriser cette VM Linux,
+• Puis, nous allons sécuriser cette VM Linux,
-• suivi de l'installation et de la sécurisation d'Apache (serveur Web),
+• Ensuite, nous nous occupérons de l'installation et de la sécurisation d'Apache (serveur Web),
-• enfin, je vous montrerai comment enregistrer un domaine et relier ce domaine à Apache, hébergé dans la VM Linux.
+• Enfin, je vous montrerai comment enregistrer un domaine et relier ce domaine à Apache, hébergé dans la VM Linux.
 Déployer Linux dans le Nuage
@@ Ligne 49: / Ligne 49: @@
 Il y a beaucoup de solutions disponibles pour déployer une VM dans le Nuage. Juste un exemple : Amazon Web Services (service Web d'Amazon), probablement connu dans le monde entier.
-Dans mon document, je vais utiliser Digital Ocean. Je n'essaie pas de faire de la publicité pour Digital Ocean. Personnellement, j'ai choisi ce fournisseur parce qu'il est bon marché (il facture à l'heure de connexion, soit environ 5€/mois pour la plus petite configuration avec un usage réseau limité), très pratique pour déployer une VM Linux et d'une certaine façon, de proximité (j'ai choisi New-York).
+Dans mon document, je vais utiliser Digital Ocean. Je n'essaie pas de faire de la publicité pour Digital Ocean. Personnellement, j'ai choisi ce fournisseur parce qu'il est bon marché (il facture à l'heure de connexion, soit environ 5€/mois pour la plus petite configuration avec un usage réseau limité), très pratique pour déployer une VM Linux et, d'une certaine façon, de proximité (j'ai choisi New York).
 Faisons tourner une nouvelle VM et nous choisirons Ubuntu 14.04 :
-• Allez sur https://www.digitalocean.com et connectez-vous,
+• allez sur https://www.digitalocean.com et connectez-vous,
 • choisissez « Create a new droplet » (créer une nouvelle droplet - droplet égale VM).
@@ Ligne 74: / Ligne 74: @@
 As convention, all commands starting with # should run as root while all starting with $ will start as regular user.**
-Saisissez un nom de VM et choisissez la taille de la VM. Le plus petit format fonctionne vraiment bien. Oui, il n'y a pas beaucoup de mémoire - mais, souvenez-vous que nous allons faire tourner Linux ; aussi, c'est largement suffisant pour une paire de sites.
+Saisissez un nom de VM et choisissez la taille de la VM. Le plus petit format fonctionne vraiment bien. Oui, il n'y a pas beaucoup de mémoire, mais souvenez-vous que nous allons faire tourner Linux ; aussi, c'est largement suffisant pour une paire de sites.
 Ensuite, choisissez la saveur de Linux - pour nous, Ubuntu 14.04 64-bits - et, enfin, utilisez le bouton « Create Droplet » (Créer la droplet) en bas de la page.
-Quelques secondes après, la VM sera créée et un mot de passe administrateur (root) avec l'adresse IP vous sera envoyé par mail. Nous en aurons besoin pour nous connecter à la VM. Notez que je ne vais pas cacher l'adresse IP (après tout, c'est temporaire) et, bien que je sois supposé sécuriser cette VM, je n'ai pas peur d'être attaqué.
+Quelques secondes plus tard, la VM sera créée et un mot de passe administrateur (root) avec l'adresse IP vous sera envoyé par mail. Nous en aurons besoin pour nous connecter à la VM. Notez que je ne vais pas cacher l'adresse IP (après tout, c'est temporaire) et, puisque je dois sécuriser cette VM, je n'ai pas peur d'être attaqué.
 IMPORTANT
-Digital Ocean facture à l'heure même si la VM est éteinte. Merci de lire la documentation de Digital Ocean sur la facturation pour tous les détails.
+Digital Ocean facture à l'heure, même si la VM est éteinte. Merci de lire la documentation de Digital Ocean sur la facturation pour tous les détails.
-Si vous voulez arrêter tout coût supplémentaire, faites un instantané de votre VM (vous pourrez la restaurer plus tard) et détruisez la VM.
+Si vous voulez arrêter tout coût supplémentaire, faites un instantané de votre VM (vous pourrez ainsi la restaurer plus tard) et détruisez la VM.
-Prenez note, s'il vous plaît, que nous allons continue la préparation du serveur en utilisant uniquement la ligne de commande.
+Veuillez noter que nous allons continuer la préparation du serveur en utilisant uniquement la ligne de commande.
-• Premièrement, la bande passante est limitée (1 To seulement est compris dans notre abonnement mensuel) et l'interface graphique en utilise une bonne partie,
+• Premièrement, la bande passante est limitée (1 To seulement est compris dans notre abonnement mensuel) et l'interface graphique en utilise une bonne partie.
-• deuxièmement, la ligne de commande est plus rapide.
+• Deuxièmement, la ligne de commande est plus rapide.
-Par convention, toutes les commandes commençant par # devront être lancées comme root alors que celles avec $ le seront par un utilisateur normal.
+Par convention, toutes les commandes commençant par # devront être lancées par root alors que celles avec $ le seront par un utilisateur normal.
 **Basic Security
@@ Ligne 118: / Ligne 118: @@
 Sécurité minimum
-Maintenant que la VM est configurée et en fonctionnement, elle est accessible depuis n'importe où par SSH - aucune sécurité n'est fournie par défaut, sauf le mot de passe root - et nous devons régler ça rapidement.
+Maintenant que la VM est configurée et fonctionne, elle est accessible depuis n'importe où par SSH - aucune sécurité n'est fournie par défaut, sauf le mot de passe root - et nous devons régler cela rapidement.
-Laissez-moi faire un parallèle avec l'immobilier - quand vous achetez une maison, l’adage est « localisation, emplacement, environnement ». De même, pour sécuriser un serveur Linux avec SSH, la maxime devrait être « pas d'accès root », « Clé RSA », « pas de mot de passe ».
+Laissez-moi faire un parallèle avec l'immobilier : quand vous achetez une maison, la devise est « localisation, emplacement, environnement ». De même, pour sécuriser un serveur Linux avec SSH, la devise devrait être « pas d'accès root », « Clé RSA », « pas de mot de passe ».
 Etape 0 - Créer un utilisateur
-La première fois que vous vous connectez à votre VM Linux toute neuve, créez un nouvel utilisateur nommé « tux ». Ensuite, nous attribuons le mot de passe « linux » à ce nouvel utilisateur (choisissez un meilleur mot de passe).
+La première fois que vous vous connectez à votre VM Linux toute neuve, créez un nouvel utilisateur nommé « tux ». Ensuite, nous attribuons le mot de passe « linux » à ce nouvel utilisateur (bien entendu, il faut choisir un meilleur mot de passe).
-Connectez-vous à la VM - nous nous connectons comme root dans un premier temps. Ouvrez un terminal :
+Connectez-vous à la VM - nous nous connectons comme root cette première fois. Ouvrez un terminal :
 ssh root@104.236.124.121
-Puis ajoutez un nouvel utilisateur:
+Puis ajoutez un nouvel utilisateur :
 useradd -m -s /bin/bash tux
@@ Ligne 138: / Ligne 138: @@
 Attendez l'invite et saisissez linux.
-le commutateur -m pour useradd crée un répertoire home et le -s indique que nous voulons bash comme shell.
+Le commutateur -m pour useradd crée un répertoire home et le -s indique que nous voulons bash comme shell.
 **Now we must ensure that we can log in with the new user created. Open a new terminal session and let's try it out:
@@ Ligne 170: / Ligne 170: @@
 Level 1 of security completed!**
-Maintenant, nous devons vérifier que nous pouvons nous connecter avec le nouvel utilisateur juste créé. Ouvrez un nouveau terminal et essayez :
+Maintenant, nous devons vérifier que nous pouvons nous connecter avec le nouvel utilisateur. Ouvrez un nouveau terminal et essayez :
 ssh tux@104.236.124.121
@@ Ligne 188: / Ligne 188: @@
 DenyUsers       root
-J'utilise l'éditeur de texte vi mais vous pouvez en choisir un autre (on m'a dit que nano est probablement mieux pour des débutants).
+J'utilise l'éditeur de texte vi, mais vous pouvez en choisir un autre (on m'a dit que nano est probablement meilleur pour des débutants).
-Pour que ça prenne effet, nous devons redémarrer la démon ssh :
+Pour que ça prenne effet, nous devons redémarrer le démon ssh :
 service ssh restart
@@ Ligne 198: / Ligne 198: @@
 Essayez ssh root@104.236.124.121 ; le message d'erreur devrait être « permission denied » (autorisation refusée).
-Le niveau 1 est terminé.
+Le niveau 1 sécuritaire est terminé !
 **2 – RSA key
@@ Ligne 222: / Ligne 222: @@
 - Clé RSA
-Une clé RSA est une façon bien sécurisée de se connecter à un serveur SSH. La génération de la clé RSA créera deux composantes - une clé privée et une clé publique. En français ordinaire, une clé privée, c'est un petit fichier. Une clé publique est un autre petit fichier. Pour accéder au système avec les clés RSA (ce que nous appellerons « l’authentification RSA »), SSH vérifiera que les deux fichiers se correspondent - si c'est le cas, vous pourrez vous connecter.
+Une clé RSA est une façon bien sécurisée de se connecter à un serveur SSH. La génération de la clé RSA créera deux composantes : une clé privée et une clé publique. En français ordinaire, une clé privée, c'est un petit fichier. Une clé publique est un autre petit fichier. Pour accéder au système avec les clés RSA (ce que nous appellerons « l’authentification RSA »), SSH vérifiera que les deux fichiers se correspondent et, si c'est le cas, vous pourrez vous connecter.
-Laissez-moi faire un nouveau parallèle avec un billet de banque - imaginez que nous coupions aléatoirement le billet en deux. Seules ces deux parties vont ensemble. C'est pareil pour les clés RSA.
+Laissez-moi faire un nouveau parallèle avec un billet de banque : imaginez que nous coupions aléatoirement le billet en deux. Seules ces deux parties vont ensemble. C'est pareil pour les clés RSA.
 La clé publique est stockée dans le serveur SSH (iceberg dans notre exemple), alors que tux conservera la clé privée. Quand tux essaie de se connecter à iceberg, tux doit montrer la clé privée correspondant à la clé publique. Et la taille de la clé sera si grande que la probabilité que quelqu'un puisse reproduire la correspondance est virtuellement impossible.
@@ Ligne 230: / Ligne 230: @@
 En résumé, sans la bonne clé privée, il n'y a pas d'accès au serveur.
-IMPORTANT - Nous allons générer des clés pour tux et pas pour root (souvenez-vous - « pas d'accès root »)
+IMPORTANT - Nous allons générer des clés pour tux et pas pour root (souvenez-vous : « pas d'accès root »).
-Pour la génération de la paire de clés privée/publique, nous allons les taper en dur et demander un clé de 10 Ko (je crois que par défaut la taille est de 4 Ko). Ce processus peut prendre du temps - jusqu'à une minute maximum (pour une grosse clé).
+Pour la génération de la paire de clés privée/publique, nous allons les taper en dur et demander une clé de 10 Ko (je crois que par défaut la taille est de 4 Ko). Ce processus peut prendre du temps, jusqu'à une minute maximum (pour une grosse clé).
 ssh-keygen -t rsa -b 10240
@@ Ligne 261: / Ligne 261: @@
 As a general rule, modern encryption systems are pretty robust. However corners are sometimes cut and the entire system will be easier to defeat.**
-Un peu d'explication, ici - Le mot de passe est utilisé pour protéger la clè privée elle-même. Dans le scénario improbable où quelqu'un vole votre clé privée, l'attaquant serait capable de se connecter à votre serveur. Mais, s'il ne connaît pas le mot de passe de la clé privée, il ne pourra pas l'utiliser.
+Un peu d'explication : le mot de passe est utilisé pour protéger la clé privée elle-même. Dans le scénario improbable où quelqu'un vole votre clé privée, l'attaquant serait capable de se connecter à votre serveur. Mais s'il ne connaît pas le mot de passe de la clé privée, il ne pourra pas l'utiliser.
-Je sais que certains de vous ne sont pas d'accord, mais réfléchissez à ceci - quelle est le risque réel que quelqu'un vous vole votre clé ? Virtuellement personne, non ? C'est mon point de vue - il n'y a donc pas besoin d'un mot de passe pour nos sujets.
+Je sais que certains d'entre vous ne sont pas d'accord, mais réfléchissez à ceci : quel est le risque réel que quelqu'un vous vole votre clé ? Virtuellement aucun, non ? Voici ce que je veux dire - nous n'avons peut-être pas besoin d'un mot de passe.
-Mais faisons-le, comme s'il fallait - choisissons le mot de passe 12345 (à nouveau - si vous prévoyez de l'utiliser - ne choisissez pas un mauvais mot de passe, c'est juste un tutoriel).
+Mais faisons-le selon les règles de l'art : choisissons le mot de passe 12345 (à nouveau, si vous prévoyez de tout faire comme il faut, ne choisissez pas un mauvais mot de passe - ceci n'est qu'un tutoriel).
 Nous devrions avoir 2 fichiers dans le répertoire /home/tux/.ssh
-• id_rsa_iceberg pour la clé privée
+• id_rsa_iceberg pour la clé privée.
 • id_rsa_iceberg.pub pour la clé publique.
-Maintenant, faites une copie de la clé publique comme suit - le nom est important car ssh cherchera spécifiquement les clés autorisées (vous pouvez changer ce comportement par défaut en ajustant /etc/ssh/sshd_config) :
+Maintenant, faites une copie de la clé publique comme suit : le nom est important car ssh cherchera spécifiquement les clés autorisées (vous pouvez changer ce comportement par défaut en ajustant /etc/ssh/sshd_config) :
 cp id_rsa_iceberg.pub authorized_keys
-Sécurité spéciale du mot de passe de la clé privée
+Sécurité spéciale du mot de passe de la clé privée.
-Maintenant, avant de poursuivre, parlons un peu de la sécurité du mot de passe de la clé privée.
+Avant de poursuivre, parlons un peu de la sécurité du mot de passe de la clé privée.
-En règle générale, les systèmes de chiffrage modernes sont plutôt robustes. Cependant, il peut exister quelques biais qui font plus facilement tomber les défenses de tout le système.
+En règle générale, les systèmes modernes de chiffrage sont plutôt robustes. Cependant, parfois des libertés sont prises et on pourrait plus facilement faire tomber les défenses de tout le système.
 **If you are familiar with the Enigma encryption system used by Germans during World War 2 – that was a really robust encryption system. For whatever (good?) reason, the creators decided that a character could not be encrypted as itself. Well, this feature inserted a weakness because it reduced the number of combinations the cypher could produce. It's obviously not the only reason why the code was broken – my point is that a small decision (by sloppiness or not) lowered the encryption strength of a well thought system.
@@ Ligne 308: / Ligne 308: @@
 [NOTE: the above is all one line]**
-Si vous connaissez le système de chiffrage Enigma utilisé par les allemands pendant la seconde guerre mondiale, c'était un système de chiffrage vraiment robuste. Pour quelque (bonne ?) raison, les créateurs avaient décidé qu'un caractère ne pouvait pas s'encoder lui-même. Et bien, cette fonctionnalité a introduit une faiblesse parce qu'elle réduisait le nombre de combinaisons que le codeur pouvait produire. Ce n'est pas l'unique raison qui a conduit à casser le code - de mon point de vue, cette décision mineure (par négligence ou non) a réduit la force de chiffrage de tout le système.
+Si vous connaissez le système de chiffrage Enigma utilisé par les Allemands pendant la Seconde Guerre mondiale, c'était un système de chiffrage vraiment robuste. Pour quelque (bonne ?) raison, les créateurs avaient décidé qu'un caractère ne pouvait pas s'encoder lui-même. Eh bien, cette fonctionnalité a introduit une faiblesse parce qu'elle réduisait le nombre de combinaisons que le codeur pouvait produire. Ce n'est pas l'unique raison pour laquelle le code fut cassé mais il me semble que cette décision mineure (par négligence ou non) a réduit la force de chiffrage de tout le système.
-C'est pareil pour SSH - les clés privées peuvent être protégées par mot de passe (rappel - 12345 dans notre exemple), cependant, le chiffrage n'est pas aussi fort que vous pourriez le penser. Grâce à l'Open Source, quelqu'un a remarqué la faiblesse et il est facilement possible d'augmenter sérieusement le chiffrage de la clé privée. Si vous êtes intéressé pour le faire - juste pour le plaisir, en fait - je vous recommande de lire cet excellent blog : http://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html.
+C'est pareil pour SSH : les clés privées peuvent être protégées par mot de passe (rappel : 12345 dans notre exemple), cependant, le chiffrage n'est pas aussi fort que vous pourriez le penser. Grâce à l'Open Source, quelqu'un a remarqué la faiblesse et il est facilement possible d'augmenter sérieusement le chiffrage de la clé privée. Si vous le faire vous intéresse - juste pour le plaisir, en fait - je vous recommande de lire cet excellent blog : http://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html.
 En résumé :
 • Faites une copie de votre clé privée,
-• créez 2 fichiers - file1.txt avec le mot de passe d'origine et file2.txt avec le nouveau mot de passe. Les deux fichiers peuvent avoir le même mot de passe (12345 pour nous) mais vous devez créer les deux fichiers,
+• créez 2 fichiers - file1.txt avec le mot de passe d'origine et file2.txt avec le nouveau mot de passe. Les deux fichiers peuvent avoir le même mot de passe (12345 pour nous), mais vous devez créer les deux fichiers,
 • modifiez le chiffrage.
@@ Ligne 333: / Ligne 333: @@
 openssl pkcs8 -topk8 -v2 des3 -in /home/tux/.ssh/id_rsa_iceberg.bak -out /home/tux/.ssh/id_rsa_iceberg -passin file:file1.txt -passout file:file2.txt
-[NOTE : Ci-dessus, il s'agit d'une seule ligne !)
+[NOTE : Ci-dessus, il ne s'agit que d'une seule ligne !)
 **Now the private key will be protected with the password included in file2.txt, and properly encrypted!
@@ Ligne 363: / Ligne 363: @@
 (this is read-only and expected by ssh).**
-À partir de maintenant, la clé privée la clé privée sera protégée avec le mot de passe inclus dans file2.txt, et proprement chiffrée !
+À partir de maintenant, la clé privée sera protégée par le mot de passe inclus dans file2.txt, et chiffrée comme il faut !
-De façon à se connecter à iceberg, nous avons besoin d'une copie de la clé privée id_rsa_iceberg sur notre ordinateur. On peut le faire de différentes façons (scp par exemple - ou une copie sécurisée) ; cependant, pourquoi pas un simple copier/coller ?
+Pour pouvoir se connecter à iceberg, nous avons besoin d'une copie de la clé privée id_rsa_iceberg sur notre ordinateur. On peut le faire de différentes façons (scp par exemple, ou une copie sécurisée) ; cependant, pourquoi pas un simple copier/coller ?
 Faisons-le :
@@ Ligne 371: / Ligne 371: @@
 cat id_rsa_iceberg
-• Sélectionner tout ce qui commence à -----BEGIN RSA PRIVATE KEY----- jusqu'à -----END RSA PRIVATE KEY----- et copiez-le dans le presse-papier.
+• Sélectionnez tout ce qui commence à -----BEGIN RSA PRIVATE KEY----- jusqu'à -----END RSA PRIVATE KEY----- et copiez-le dans le presse-papier.
 Sur votre bureau :
@@ Ligne 385: / Ligne 385: @@
 Là, collez, enregistrez et fermez.
-• Changer les permissions du fichier :
+• Changez les permissions du fichier :
 chmod 400 id_rsa_iceberg
-(il est en lecture seule, sauf pour ssh).
+(il est en lecture seule et ssh s'y attend).
 **We should now try to connect to iceberg using our ssh key.
@@ Ligne 425: / Ligne 425: @@
 Vous devriez avoir une demande de mot de passe pour la clé privée (c'est 12345) et vous devriez ensuite être connecté à iceberg.
-Réglage final de la sécurité - nous allons maintenant interdire toutes les connexions à iceberg.
+Réglage final de la sécurité : nous allons maintenant interdire toutes les connexions par mot de passe à iceberg.
 Revenez au fichier /etc/ssh/sshd_config et faites quelques modifications :
@@ Ligne 435: / Ligne 435: @@
 • Changez LoginGraceTime de 120 à 20 (ceci autorise 20 connexions simultanées – c'est largement assez).
-Sauvegardez et redémarrez le service ssh (service ssh restart).
+Enregistrez, quittez et redémarrez le service ssh (service ssh restart).
 Essayez ssh tux@104.236.124.121
-Vous devriez recevoir Permission denied (publickey) -permission refusée (clé publique). Cela signifie que l'authentification du mot de passe n'est pas autorisée.
+Vous devriez recevoir Permission denied (publickey) - permission refusée (clé publique). Cela signifie que l'authentification du mot de passe n'est pas autorisée.
 Maintenant, nous sommes complètement sécurisés.
@@ Ligne 461: / Ligne 461: @@
 En résumé :
 • root ne peut pas se connecter.
-• Seules les clés RSA sont autorisées pour l'authentification.
+• seules les clés RSA sont autorisées pour l'authentification.
-La prochaine fois, nous sécuriserons le serveur en utilisant les règles du pare-feu (le serveur est grans ouvert, mais quand même assez sécurisé pour aujourd'hui).
+La prochaine fois, nous sécuriserons le serveur en utilisant les règles du pare-feu (le serveur est grand ouvert, mais quand même assez sécurisé pour aujourd'hui).
-Nous installerons apache (le serveur web) et nous le sécuriserons.
+Nous installerons apache (le serveur Web) et nous le sécuriserons.
 Dernière note importante
@@ Ligne 473: / Ligne 473: @@
 Avec l'instantané, la VM peut être recréée dans le même état qu'au moment où il a été pris.
-Si vous utilisez un autre fournisseur de Nuage, vérifiez leur documentation pour ne pas payer quand la VM n'est pas en cours d'utilisation.
+Si vous utilisez un autre fournisseur de Nuage, vérifiez leur documentation pour vous assurer de ne pas payer quand la VM n'est pas en cours d'utilisation.