WEBVTT 00:00.150 --> 00:01.770 - : Le nouveau type de virtualisation qui 00:01.770 --> 00:03.540 devient populaire dans nos réseaux est connu 00:03.540 --> 00:05.790 sous le nom de virtualisation basée sur les conteneurs, 00:05.790 --> 00:07.980 également connue sous le nom de conteneurisation. 00:07.980 --> 00:10.290 Ce type de virtualisation est toutefois beaucoup plus 00:10.290 --> 00:12.780 axé sur les serveurs que sur l'utilisateur final. 00:12.780 --> 00:14.460 Avec ce type de virtualisation, le noyau 00:14.460 --> 00:16.440 du système d'exploitation est partagé entre 00:16.440 --> 00:19.440 plusieurs machines virtuelles, mais l'espace utilisateur de chaque 00:19.440 --> 00:22.740 machine virtuelle est créé et géré de manière unique. 00:22.740 --> 00:25.020 La conteneurisation est un type de virtualisation 00:25.020 --> 00:27.900 appliqué par un système d'exploitation hôte afin de fournir 00:27.900 --> 00:31.230 un environnement d'exécution isolé pour une application. 00:31.230 --> 00:33.390 La conteneurisation est considérée comme relativement 00:33.390 --> 00:35.370 sûre car elle applique la segmentation et la séparation 00:35.370 --> 00:38.280 des ressources au niveau du système d'exploitation. 00:38.280 --> 00:40.290 Aujourd'hui, la conteneurisation est couramment 00:40.290 --> 00:42.210 utilisée avec les serveurs Linux et certains 00:42.210 --> 00:43.950 exemples de cette virtualisation basée 00:43.950 --> 00:46.980 sur les conteneurs incluent des choses comme Docker, Parallels Virtuozzo 00:46.980 --> 00:48.960 et le projet OpenVZ. 00:48.960 --> 00:51.870 Maintenant, à quoi ressemble réellement la conteneurisation ? 00:51.870 --> 00:53.610 Il s'agit d'un matériel sur lequel 00:53.610 --> 00:56.460 est installé un système d'exploitation hôte, généralement 00:56.460 --> 00:59.430 Linux, ainsi qu'un gestionnaire de conteneurs. 00:59.430 --> 01:02.820 Quelque chose comme Kubernetes ou Docker ou quelque chose comme ça. 01:02.820 --> 01:05.100 Ce gestionnaire de conteneurs va être utilisé pour créer 01:05.100 --> 01:08.070 différents conteneurs contenant différentes applications. 01:08.070 --> 01:10.290 Dans ce cas, j'ai trois conteneurs. 01:10.290 --> 01:12.000 J'ai le premier environnement, qui est basé 01:12.000 --> 01:14.340 sur le noyau du système d'exploitation hôte, dans cet exemple, 01:14.340 --> 01:16.170 un système Linux qui est utilisé. 01:16.170 --> 01:18.720 Nous avons donc un conteneur qui fonctionne sous Linnux 01:18.720 --> 01:20.700 et qui contient quelques applications. 01:20.700 --> 01:23.130 Maintenant, le conteneur deux peut faire la même chose 01:23.130 --> 01:25.290 et le conteneur trois peut faire la même chose. 01:25.290 --> 01:27.210 Étant donné que les trois conteneurs partagent les mêmes 01:27.210 --> 01:28.980 fichiers du système d'exploitation hôte. 01:28.980 --> 01:30.750 Cela nécessite beaucoup moins de ressources 01:30.750 --> 01:33.690 que la virtualisation pure à l'aide de machines virtuelles. 01:33.690 --> 01:35.730 Comme dans le cas de la virtualisation. 01:35.730 --> 01:38.340 Si nous utilisons plutôt des machines virtuelles individuelles, chacune d'entre 01:38.340 --> 01:40.860 elles aura besoin de sa propre copie d'un système d'exploitation. 01:40.860 --> 01:43.740 Et cela pourrait représenter 8 à 10 gigaoctets pour chacun d'entre eux. 01:43.740 --> 01:45.000 Mais avec les conteneurs, nous 01:45.000 --> 01:47.280 pouvons tous partager le même système d'exploitation. 01:47.280 --> 01:50.250 La conteneurisation utilise donc beaucoup moins d'espace de 01:50.250 --> 01:52.260 stockage et de puissance de traitement. 01:52.260 --> 01:55.050 C'est là le véritable avantage de l'utilisation d'un outil tel qu'un 01:55.050 --> 01:56.970 conteneur d'un point de vue opérationnel. 01:56.970 --> 01:59.970 Maintenant, parce que ces conteneurs sont logiquement isolés. 01:59.970 --> 02:02.100 Ils ne peuvent pas s'interfacer entre eux. 02:02.100 --> 02:04.080 Si je veux que deux conteneurs se parlent, je dois les connecter 02:04.080 --> 02:06.480 par l'intermédiaire d'un réseau virtuel et effectuer le routage 02:06.480 --> 02:07.890 et la commutation appropriés pour leur 02:07.890 --> 02:09.330 permettre de se parler. 02:09.330 --> 02:11.970 Par défaut, ils n'ont aucun moyen de se parler et c'est 02:11.970 --> 02:14.310 une excellente chose du point de vue de la sécurité 02:14.310 --> 02:16.410 car nous avons cette segmentation. 02:16.410 --> 02:18.810 Voici votre principal avertissement en ce qui concerne 02:18.810 --> 02:20.010 les conteneurs. 02:20.010 --> 02:22.890 Si un attaquant compromet le système d'exploitation hôte, 02:22.890 --> 02:24.990 par exemple le système d'exploitation Linux 02:24.990 --> 02:27.960 dont je viens de parler, devinez ce qui se passe ? 02:27.960 --> 02:30.810 Cette attaque a désormais accès à tous les conteneurs dans 02:30.810 --> 02:33.270 leurs données, car ce système d'exploitation est 02:33.270 --> 02:35.790 utilisé par tous les conteneurs hébergés. 02:35.790 --> 02:37.440 C'est l'une des plus grandes vulnérabilités lorsque 02:37.440 --> 02:38.820 vous utilisez des conteneurs. 02:38.820 --> 02:40.470 Je peux avoir un système de conteneurs qui fait tourner 02:40.470 --> 02:42.240 50 serveurs différents en ce moment même. 02:42.240 --> 02:43.980 Et chacun d'entre eux exécute différents serveurs 02:43.980 --> 02:46.230 et services en utilisant la conteneurisation. 02:46.230 --> 02:49.050 Mais si quelqu'un est capable d'accéder à ce serveur sous 02:49.050 --> 02:52.020 le système d'exploitation Linux, il a désormais accès à l'ensemble 02:52.020 --> 02:55.290 des 50 serveurs hébergés et à toutes leurs données. 02:55.290 --> 02:57.480 Un autre risque à prendre en compte est la manière dont 02:57.480 --> 03:00.390 vos conteneurs et autres machines virtuelles seront hébergés. 03:00.390 --> 03:03.210 Lorsque nous commençons à nous appuyer sur la virtualisation et l'informatique 03:03.210 --> 03:05.040 en nuage, il devient très important de reconnaître 03:05.040 --> 03:07.680 que nos données peuvent être hébergées sur le même serveur physique que 03:07.680 --> 03:09.660 les données d'une autre organisation. 03:09.660 --> 03:12.120 Ce faisant, nous introduisons certaines vulnérabilités 03:12.120 --> 03:13.920 dans la sécurité de nos systèmes. 03:13.920 --> 03:16.950 Tout d'abord, si le serveur physique tombe en panne à cause d'une 03:16.950 --> 03:18.960 action de l'une des autres organisations, 03:18.960 --> 03:19.880 cela peut affecter 03:19.880 --> 03:22.500 toutes les organisations sur ce même serveur. 03:22.500 --> 03:24.960 De même, si une organisation n'assure pas la sécurité 03:24.960 --> 03:26.760 de ses environnements virtuels, qui sont 03:26.760 --> 03:28.740 hébergés sur ce serveur physique, il est possible 03:28.740 --> 03:31.470 qu'un attaquant puisse utiliser cette situation au détriment 03:31.470 --> 03:33.900 de toutes les autres organisations hébergées sur 03:33.900 --> 03:35.880 ce même serveur. 03:35.880 --> 03:38.220 Tout comme l'interconnexion de nos réseaux avec ceux de quelqu'un 03:38.220 --> 03:40.170 d'autre pose des problèmes, l'hébergement des données 03:40.170 --> 03:42.210 de plusieurs organisations sur le même serveur physique 03:42.210 --> 03:44.010 en pose également. 03:44.010 --> 03:46.530 Il est important pour nous de configurer, de gérer et d'auditer 03:46.530 --> 03:48.780 correctement l'accès des utilisateurs aux machines 03:48.780 --> 03:50.820 virtuelles hébergées sur ces serveurs. 03:50.820 --> 03:53.850 Nous voulons également nous assurer que nos machines virtuelles 03:53.850 --> 03:56.580 disposent des derniers correctifs, de l'antivirus, de l'animwire 03:56.580 --> 03:58.410 et du contrôle d'accès. 03:58.410 --> 03:59.760 Afin de minimiser le risque de voir 03:59.760 --> 04:02.490 les ressources des serveurs physiques débordées, c'est toujours 04:02.490 --> 04:04.920 une bonne idée de configurer nos machines virtuelles avec 04:04.920 --> 04:08.280 un basculement, une redondance et une élasticité appropriés. 04:08.280 --> 04:09.810 En surveillant les performances du 04:09.810 --> 04:11.610 réseau et les ressources des serveurs physiques, 04:11.610 --> 04:13.500 nous devrions être en mesure d'équilibrer la 04:13.500 --> 04:15.570 charge entre plusieurs machines physiques au lieu 04:15.570 --> 04:17.370 de dépendre d'une seule. 04:17.370 --> 04:19.290 Une autre vulnérabilité susceptible d'être 04:19.290 --> 04:21.330 exploitée par un pirate est l'utilisation du 04:21.330 --> 04:24.420 même type d'hyperviseur pour toutes nos machines virtuelles. 04:24.420 --> 04:27.180 Par exemple, si notre organisation s'appuie uniquement 04:27.180 --> 04:29.700 sur l'hyperviseur ESXi de VMware et qu'un nouvel 04:29.700 --> 04:32.280 exploit est créé pour cet hyperviseur, un pirate 04:32.280 --> 04:35.790 pourrait l'utiliser contre tous nos systèmes. 04:35.790 --> 04:38.400 Par conséquent, si l'opération réussit sur l'un de nos serveurs, 04:38.400 --> 04:40.830 il est probable qu'elle sera tentée sur les autres serveurs. 04:40.830 --> 04:43.260 Et si tous nos serveurs utilisent la même plateforme, 04:43.260 --> 04:46.410 en l'occurrence ESXi de VMware, cette vulnérabilité pourrait être 04:46.410 --> 04:49.350 exploitée dans l'ensemble de notre organisation. 04:49.350 --> 04:51.420 Le problème est que si nous utilisons plusieurs 04:51.420 --> 04:53.700 plates-formes d'hyperviseurs, nos coûts d'assistance 04:53.700 --> 04:55.620 et nos besoins de formation vont également 04:55.620 --> 04:57.360 augmenter. 04:57.360 --> 05:00.090 Pour cette raison, la plupart des organisations choisissent d'utiliser 05:00.090 --> 05:02.610 une plateforme unique, mais elles prennent au moins une décision 05:02.610 --> 05:04.800 mesurée en termes de risques. 05:04.800 --> 05:07.290 Pour réduire ce risque, l'organisation doit utiliser des 05:07.290 --> 05:09.690 configurations appropriées, s'assurer que l'hyperviseur 05:09.690 --> 05:11.520 reste toujours patché et à jour et qu'il n'est 05:11.520 --> 05:14.280 accessible qu'à travers une interface de gestion sécurisée, ainsi 05:14.280 --> 05:16.830 que contrôler étroitement le contrôle d'accès. 05:16.830 --> 05:19.230 Ce sont là quelques-uns des éléments que vous devez prendre 05:19.230 --> 05:21.570 en compte lorsque vous commencez à réfléchir à la possibilité 05:21.570 --> 05:23.880 de virtualiser vos systèmes et de les migrer vers une solution 05:23.880 --> 05:25.410 sur site ou dans le nuage. 05:25.410 --> 05:27.540 Tout d'abord, allez-vous virtualiser ? 05:27.540 --> 05:30.360 Dans ce cas, allez-vous utiliser des machines virtuelles traditionnelles 05:30.360 --> 05:32.430 ou allez-vous recourir à la conteneurisation ? 05:32.430 --> 05:34.410 Quel est le rapport risque/récompense dans ce cas ? 05:34.410 --> 05:35.970 Il faut trouver un équilibre. 05:35.970 --> 05:37.230 Il s'agit d'une décision 05:37.230 --> 05:39.780 commerciale et d'une décision de cybersécurité. 05:39.780 --> 05:41.460 Vous allez donc devoir mesurer ces éléments 05:41.460 --> 05:44.100 et décider ce qui convient le mieux à votre organisation et à ses 05:44.100 --> 05:45.723 cas d'utilisation particuliers.