WEBVTT

00:00.660 --> 00:01.710
Conférencier : Dans cette

00:01.710 --> 00:04.920
leçon, nous allons parler de l'importance des répartiteurs de charge.

00:04.920 --> 00:06.120
Les équilibreurs de charge,

00:06.120 --> 00:08.340
également connus sous le nom de commutateurs de contenu,

00:08.340 --> 00:10.410
sont utilisés pour répartir les demandes entrantes

00:10.410 --> 00:11.910
sur un certain nombre de serveurs à l'intérieur

00:11.910 --> 00:15.330
d'un formulaire de serveur ou d'une infrastructure en nuage.

00:15.330 --> 00:17.370
Si vous gérez un site web ou un service de grande

00:17.370 --> 00:20.040
envergure, vous ne pouvez pas tout faire sur un seul serveur.

00:20.040 --> 00:22.680
Par exemple, j'ai actuellement plusieurs centaines de milliers

00:22.680 --> 00:23.513
d'étudiants qui suivent

00:23.513 --> 00:25.680
mes cours et regardent mes vidéos.

00:25.680 --> 00:29.100
Il est impossible qu'un seul serveur puisse supporter une telle charge.

00:29.100 --> 00:30.630
Nous devons donc le distribuer

00:30.630 --> 00:32.460
sur un grand nombre de serveurs différents

00:32.460 --> 00:33.810
dans le monde entier.

00:33.810 --> 00:36.300
Mais lorsqu'un étudiant veut visiter mon site web, il

00:36.300 --> 00:38.340
ne doit pas choisir un serveur spécifique.

00:38.340 --> 00:41.070
Au lieu de cela, ils se contentent d'aller à diontraining. com et notre équilibreur de

00:41.070 --> 00:43.230
charge et notre commutateur de contenu redirigent

00:43.230 --> 00:45.960
cette demande vers le prochain serveur disponible pour

00:45.960 --> 00:47.460
pouvoir la traiter.

00:47.460 --> 00:49.590
En fait, nous avons des tonnes de serveurs différents

00:49.590 --> 00:50.880
répartis dans le monde entier

00:50.880 --> 00:53.100
pour traiter toutes ces demandes.

00:53.100 --> 00:55.230
La même chose se produit avec Netflix,

00:55.230 --> 00:57.480
Hulu, Facebook ou Amazon, mais à une échelle

00:57.480 --> 00:59.280
beaucoup plus grande.

00:59.280 --> 01:01.920
Tous ces grands sites web doivent utiliser un équilibreur

01:01.920 --> 01:03.570
de charge, faute de quoi un seul serveur

01:03.570 --> 01:06.263
s'effondrerait sous la charge et ils subiraient une attaque

01:06.263 --> 01:08.400
par déni de service auto-imposée en raison de

01:08.400 --> 01:10.650
la popularité de leur site web.

01:10.650 --> 01:12.510
Un équilibreur de charge agit essentiellement

01:12.510 --> 01:13.500
comme un régulateur de trafic

01:13.500 --> 01:15.120
en se plaçant devant vos serveurs et en acheminant

01:15.120 --> 01:17.310
les demandes des clients vers les serveurs qui sont les

01:17.310 --> 01:19.410
plus disponibles pour répondre à ces demandes à un moment

01:19.410 --> 01:20.970
donné.

01:20.970 --> 01:23.940
Cela maximise la vitesse de réponse à l'utilisateur et utilise

01:23.940 --> 01:25.530
plus efficacement toute la capacité

01:25.530 --> 01:28.170
existante de vos serveurs pour toutes les demandes

01:28.170 --> 01:30.060
de l'utilisateur.

01:30.060 --> 01:32.220
La raison pour laquelle un équilibreur de charge est si important,

01:32.220 --> 01:34.230
c'est qu'il s'agit de l'une des principales mesures que

01:34.230 --> 01:36.750
nous pouvons prendre pour nous défendre contre une attaque par déni

01:36.750 --> 01:39.270
de service ou une attaque par déni de service distribué.

01:39.270 --> 01:41.730
Qu'est-ce qu'une attaque par déni de service ?

01:41.730 --> 01:43.560
Une attaque par déni de service consiste

01:43.560 --> 01:46.410
à inonder continuellement les systèmes victimes de demandes

01:46.410 --> 01:48.090
de services, ce qui a pour effet d'épuiser

01:48.090 --> 01:50.070
la mémoire du système et de le faire tomber

01:50.070 --> 01:51.570
en panne.

01:51.570 --> 01:52.830
Aujourd'hui, la plupart des systèmes

01:52.830 --> 01:55.230
modernes ne peuvent pas être détruits par une seule machine.

01:55.230 --> 01:58.230
Les attaquants ont donc recours à une attaque par

01:58.230 --> 02:00.540
déni de service distribué (DDoS).

02:00.540 --> 02:02.490
Dans une attaque par déni de service distribué,

02:02.490 --> 02:04.920
au lieu d'un seul attaquant ciblant un serveur, ce sont

02:04.920 --> 02:07.200
des centaines, voire des milliers de machines qui

02:07.200 --> 02:10.050
lancent simultanément cette attaque sur le serveur, pour le forcer

02:10.050 --> 02:11.670
à se déconnecter.

02:11.670 --> 02:14.040
En mars 2018, par exemple, GitHub a été frappé

02:14.040 --> 02:16.410
par le plus grand DDoS à ce jour, où des dizaines

02:16.410 --> 02:18.570
de milliers de points d'extrémité uniques

02:18.570 --> 02:20.160
ont mené une attaque coordonnée

02:20.160 --> 02:22.230
pour frapper ce serveur avec un pic de trafic

02:22.230 --> 02:25.620
qui a mesuré 1. 35 térabits par seconde.

02:25.620 --> 02:28.980
Le site a ainsi été mis hors ligne pendant cinq minutes.

02:28.980 --> 02:30.750
Mais la vraie question est de savoir comment

02:30.750 --> 02:32.670
survivre à l'une de ces attaques et empêcher

02:32.670 --> 02:35.760
qu'elle ne mette hors service les serveurs de notre organisation.

02:35.760 --> 02:37.620
Il suffit de regarder du côté d'Amazon pour

02:37.620 --> 02:39.330
trouver les meilleures pratiques.

02:39.330 --> 02:41.520
En février 2020, Amazon a été victime du

02:41.520 --> 02:44.130
plus grand DDoS à ce jour, plus important encore

02:44.130 --> 02:45.630
que celui de GitHub.

02:45.630 --> 02:47.130
Il y a eu une attaque coordonnée

02:47.130 --> 02:49.230
pour frapper ce serveur avec un pic de

02:49.230 --> 02:52.410
trafic mesuré à 2. 3 térabits par seconde, mais grâce

02:52.410 --> 02:55.470
à sa bonne architecture de sécurité et à sa capacité à augmenter

02:55.470 --> 02:57.480
ses ressources pour soutenir cette attaque,

02:57.480 --> 02:58.950
l'entreprise n'a subi aucun

02:58.950 --> 03:01.650
temps d'arrêt pendant l'attaque, même si celle-ci

03:01.650 --> 03:03.900
était 70 % plus importante que celle qui a fait

03:03.900 --> 03:05.880
tomber GitHub.

03:05.880 --> 03:07.410
La première technique qu'ils ont utilisée

03:07.410 --> 03:09.750
est connue sous le nom de blackholing ou sinkholing.

03:09.750 --> 03:10.800
Il s'agit d'une technique

03:10.800 --> 03:13.020
qui identifie toutes les adresses IP attaquantes

03:13.020 --> 03:14.400
et achemine l'ensemble de leur

03:14.400 --> 03:17.160
trafic vers un serveur inexistant par le biais d'une interface

03:17.160 --> 03:19.410
nulle, ce qui permet de mettre fin à l'attaque.

03:19.410 --> 03:22.050
Malheureusement, les attaquants peuvent toujours changer d'adresse

03:22.050 --> 03:23.760
IP et recommencer l'attaque.

03:23.760 --> 03:25.950
Cela n'empêchera donc pas un DDoS pour toujours, mais cela vous

03:25.950 --> 03:27.480
permettra de gagner du temps pendant que vous

03:27.480 --> 03:29.640
travaillez sur d'autres mesures d'atténuation.

03:29.640 --> 03:32.070
Les IPS, ou systèmes de prévention des intrusions, peuvent

03:32.070 --> 03:33.510
également être utilisés pour identifier

03:33.510 --> 03:35.730
les attaques par déni de service et y répondre.

03:35.730 --> 03:37.560
Cela peut fonctionner pour des attaques à

03:37.560 --> 03:38.520
petite échelle contre

03:38.520 --> 03:40.920
votre réseau, mais la puissance de traitement ne sera pas

03:40.920 --> 03:42.780
suffisante pour gérer une attaque à grande

03:42.780 --> 03:45.060
échelle, comme celle dont Amazon a été la cible.

03:45.060 --> 03:46.920
L'une des méthodes les plus efficaces consiste

03:46.920 --> 03:49.140
à utiliser une infrastructure en nuage élastique, car

03:49.140 --> 03:52.290
elle permet d'augmenter la capacité à la demande en fonction des besoins, de

03:52.290 --> 03:54.300
manière à pouvoir résister à l'attaque.

03:54.300 --> 03:55.770
Le problème de cette stratégie est que

03:55.770 --> 03:57.090
la plupart des fournisseurs de services

03:57.090 --> 03:58.920
vous facturent sur la base de la capacité et des

03:58.920 --> 04:00.510
ressources que vous utilisez.

04:00.510 --> 04:02.190
Au fur et à mesure que l'on monte en puissance,

04:02.190 --> 04:04.380
on reçoit une facture beaucoup plus importante de la part

04:04.380 --> 04:05.940
de notre fournisseur de services d'informatique

04:05.940 --> 04:07.320
en nuage, et il se peut que nous n'obtenions

04:07.320 --> 04:09.390
aucun retour sur investissement, parce que tout ce

04:09.390 --> 04:13.110
trafic ne générait aucun revenu pour notre organisation, il faisait simplement partie de

04:13.110 --> 04:15.090
l'attaque.

04:15.090 --> 04:17.280
Cela dit, au moins vous restez en ligne pour

04:17.280 --> 04:18.750
servir vos clients payants.

04:18.750 --> 04:20.400
Il s'agit donc de savoir si l'on

04:20.400 --> 04:22.140
peut se permettre de durer plus

04:22.140 --> 04:24.213
longtemps que l'attaque DDoS.