WEBVTT

00:00.150 --> 00:01.770
-: El nuevo tipo de virtualización que

00:01.770 --> 00:03.540
se está popularizando en nuestras redes

00:03.540 --> 00:05.790
se conoce como virtualización basada en contenedores

00:05.790 --> 00:07.980
también conocida como containerización.

00:07.980 --> 00:10.290
Sin embargo, este tipo de virtualización se centra

00:10.290 --> 00:12.780
mucho más en los servidores que en el usuario final.

00:12.780 --> 00:14.460
Con este tipo de virtualización, el

00:14.460 --> 00:16.440
núcleo del sistema operativo se comparte

00:16.440 --> 00:19.440
entre varias máquinas virtuales, pero el espacio de usuario

00:19.440 --> 00:21.720
de cada máquina virtual se crea y gestiona de forma

00:21.720 --> 00:22.740
exclusiva.

00:22.740 --> 00:25.020
La contenedorización es un tipo de virtualización

00:25.020 --> 00:27.900
que aplica un sistema operativo anfitrión para proporcionar

00:27.900 --> 00:31.230
un entorno de ejecución aislado para una aplicación.

00:31.230 --> 00:33.390
La contenedorización se considera bastante

00:33.390 --> 00:35.370
segura porque impone la segmentación y

00:35.370 --> 00:38.280
separación de recursos a nivel del sistema operativo.

00:38.280 --> 00:40.290
Ahora la contenedorización se utiliza comúnmente

00:40.290 --> 00:42.210
con servidores Linux y algunos ejemplos

00:42.210 --> 00:43.950
de esta virtualización basada en contenedores

00:43.950 --> 00:46.980
incluyen cosas como, Docker, Parallels Virtuozzo y el proyecto

00:46.980 --> 00:48.960
OpenVZ.

00:48.960 --> 00:51.870
Ahora bien, ¿cómo es realmente la contenedorización?

00:51.870 --> 00:53.610
Bueno, tienes una pieza de hardware y luego,

00:53.610 --> 00:56.460
encima de ese hardware, tienes un sistema operativo anfitrión,

00:56.460 --> 00:59.430
normalmente Linux, y luego tienes un gestor de contenedores.

00:59.430 --> 01:02.820
Algo como Kubernetes o Docker o algo así.

01:02.820 --> 01:05.100
Ahora este gestor de contenedores se va a utilizar para crear

01:05.100 --> 01:08.070
diferentes contenedores que contienen diferentes aplicaciones.

01:08.070 --> 01:10.290
En este caso, tengo tres contenedores.

01:10.290 --> 01:12.000
Tengo el primer entorno, que se basa en el núcleo

01:12.000 --> 01:14.340
del sistema operativo anfitrión, en este ejemplo, un sistema

01:14.340 --> 01:16.170
Linux que se está utilizando.

01:16.170 --> 01:18.720
Y así tenemos contenedor uno ejecutando Linnux y contiene

01:18.720 --> 01:20.700
algunas aplicaciones allí.

01:20.700 --> 01:23.130
Ahora el contenedor dos puede hacer lo mismo y el

01:23.130 --> 01:25.290
contenedor tres puede hacer lo mismo.

01:25.290 --> 01:27.210
Dado que los tres contenedores comparten los mismos

01:27.210 --> 01:28.980
archivos del sistema operativo anfitrión.

01:28.980 --> 01:30.750
Esto requiere muchos menos recursos

01:30.750 --> 01:33.690
que la virtualización pura mediante máquinas virtuales.

01:33.690 --> 01:35.730
Como hablamos de la virtualización.

01:35.730 --> 01:38.340
Si en su lugar utilizamos máquinas virtuales individuales, cada

01:38.340 --> 01:40.860
una necesitaría su propia copia de un sistema operativo.

01:40.860 --> 01:43.740
Y podrían ser de 8 a 10 gigabytes por cada uno.

01:43.740 --> 01:45.000
Pero con los contenedores, todos

01:45.000 --> 01:47.280
podemos compartir el mismo sistema operativo.

01:47.280 --> 01:50.250
Así, la contenedorización utiliza mucha menos base de almacenamiento y requiere

01:50.250 --> 01:52.260
mucha menos potencia de procesamiento.

01:52.260 --> 01:55.050
Esta es la verdadera ventaja de utilizar algo como un contenedor

01:55.050 --> 01:56.970
desde una perspectiva operativa.

01:56.970 --> 01:59.970
Ahora, debido a que estos contenedores están lógicamente aislados.

01:59.970 --> 02:02.100
En realidad, no pueden interactuar entre sí.

02:02.100 --> 02:04.080
Si quiero que dos contenedores hablen, tengo

02:04.080 --> 02:06.480
que conectarlos a través de una red virtual y hacer el enrutamiento

02:06.480 --> 02:07.890
y la conmutación adecuados para

02:07.890 --> 02:09.330
que puedan hablar.

02:09.330 --> 02:11.970
Por defecto, no tienen forma de hablar entre ellos y esto

02:11.970 --> 02:14.310
es algo genial desde el punto de vista de la seguridad

02:14.310 --> 02:16.410
porque tenemos esta segmentación.

02:16.410 --> 02:18.810
Esta es la gran advertencia cuando se trata

02:18.810 --> 02:20.010
de contenedores.

02:20.010 --> 02:22.890
Si un atacante compromete el sistema operativo anfitrión por

02:22.890 --> 02:24.990
debajo de, por ejemplo, ese sistema operativo

02:24.990 --> 02:27.960
Linux del que hablaba hace un momento, ¿adivina qué ocurre?

02:27.960 --> 02:30.810
Pues bien, este ataque tiene ahora acceso a todos los contenedores

02:30.810 --> 02:33.270
de sus datos, porque ese único sistema operativo es utilizado

02:33.270 --> 02:35.790
por todos los contenedores alojados.

02:35.790 --> 02:37.440
Esta es una de las mayores vulnerabilidades

02:37.440 --> 02:38.820
cuando se utilizan contenedores.

02:38.820 --> 02:40.470
Puedo tener un sistema contenedor que esté ejecutando

02:40.470 --> 02:42.240
50 servidores diferentes en este momento.

02:42.240 --> 02:43.980
Y cada uno de ellos está ejecutando diferentes

02:43.980 --> 02:46.230
servidores y servicios utilizando la contenedorización.

02:46.230 --> 02:49.050
Pero si alguien es capaz de acceder a ese único servidor

02:49.050 --> 02:52.020
bajo ese sistema operativo Linux, ahora tiene acceso

02:52.020 --> 02:55.290
a los 50 servidores alojados y a todos sus datos.

02:55.290 --> 02:57.480
Otro riesgo a tener en cuenta es cómo se van a alojar

02:57.480 --> 03:00.390
realmente sus contenedores y otras máquinas virtuales.

03:00.390 --> 03:03.210
Una vez que empezamos a confiar en la virtualización y la computación

03:03.210 --> 03:05.040
en nube, se vuelve muy importante reconocer

03:05.040 --> 03:07.680
que nuestros datos podrían estar alojados en el mismo servidor

03:07.680 --> 03:09.660
físico que los datos de otra organización.

03:09.660 --> 03:12.120
Al hacerlo, introducimos algunas vulnerabilidades

03:12.120 --> 03:13.920
en la seguridad de nuestros sistemas.

03:13.920 --> 03:16.950
En primer lugar, si el servidor físico se bloquea debido a algo que está

03:16.950 --> 03:18.960
haciendo una de las otras organizaciones, en

03:18.960 --> 03:19.880
realidad puede afectar

03:19.880 --> 03:22.500
a todas las organizaciones en ese mismo servidor.

03:22.500 --> 03:24.960
Del mismo modo, si una organización no mantiene la

03:24.960 --> 03:26.760
seguridad de sus entornos virtuales,

03:26.760 --> 03:28.740
que están alojados en ese servidor físico,

03:28.740 --> 03:31.470
existe la posibilidad de que un atacante pueda utilizarlo

03:31.470 --> 03:33.900
en detrimento de todas las demás organizaciones alojadas

03:33.900 --> 03:35.880
en ese mismo servidor.

03:35.880 --> 03:38.220
Al igual que la interconexión de nuestras redes con

03:38.220 --> 03:40.170
las de otros suscita preocupación, también

03:40.170 --> 03:42.210
lo hace alojar los datos de varias organizaciones

03:42.210 --> 03:44.010
en el mismo servidor físico.

03:44.010 --> 03:46.530
Es importante que configuremos, gestionemos y auditemos

03:46.530 --> 03:48.780
correctamente el acceso de los usuarios a las máquinas

03:48.780 --> 03:50.820
virtuales alojadas en esos servidores.

03:50.820 --> 03:53.850
Además, queremos asegurarnos de que nuestras máquinas virtuales

03:53.850 --> 03:56.580
cuentan con los últimos parches, antivirus, animwire

03:56.580 --> 03:58.410
y control de acceso.

03:58.410 --> 03:59.760
Para minimizar el riesgo de que los

03:59.760 --> 04:02.490
recursos de los servidores físicos se vean desbordados, siempre

04:02.490 --> 04:04.920
es una buena idea configurar nuestras máquinas virtuales

04:04.920 --> 04:08.280
con una conmutación por error, redundancia y elasticidad adecuadas.

04:08.280 --> 04:09.810
Al supervisar el rendimiento de

04:09.810 --> 04:11.610
la red y los recursos de los servidores

04:11.610 --> 04:13.500
físicos, deberíamos poder equilibrar

04:13.500 --> 04:15.570
la carga entre varias máquinas físicas en

04:15.570 --> 04:17.370
lugar de depender de una sola.

04:17.370 --> 04:19.290
Otra vulnerabilidad que podría ser explotada

04:19.290 --> 04:21.330
por un atacante es cuando utilizamos el mismo

04:21.330 --> 04:24.420
tipo de hipervisor en todas nuestras máquinas virtuales.

04:24.420 --> 04:27.180
Así, por ejemplo, si nuestra organización depende

04:27.180 --> 04:29.700
únicamente del hipervisor ESXi de VMware y se

04:29.700 --> 04:32.280
crea un nuevo exploit para ese hipervisor, un atacante

04:32.280 --> 04:35.790
podría utilizarlo contra todos nuestros sistemas.

04:35.790 --> 04:38.400
Así que, si tiene éxito en uno de nuestros servidores,

04:38.400 --> 04:40.830
es probable que lo prueben en el resto.

04:40.830 --> 04:43.260
Y si todos nuestros servidores utilizan la misma

04:43.260 --> 04:46.410
plataforma en este caso, ESXi de VMware, esta vulnerabilidad

04:46.410 --> 04:49.350
podría ser explotada en toda nuestra organización.

04:49.350 --> 04:51.420
Sin embargo, el problema es que si utilizamos

04:51.420 --> 04:53.700
varias plataformas de hipervisores, también aumentarán

04:53.700 --> 04:55.620
nuestros costes de soporte y nuestros requisitos

04:55.620 --> 04:57.360
de formación.

04:57.360 --> 05:00.090
Por este motivo, la mayoría de las organizaciones optan por utilizar

05:00.090 --> 05:02.610
una única plataforma, pero al menos están tomando una decisión

05:02.610 --> 05:04.800
de riesgo medido cuando lo hacen.

05:04.800 --> 05:07.290
Para mitigar ese riesgo, la organización debe utilizar configuraciones

05:07.290 --> 05:09.690
adecuadas, asegurarse de que el hipervisor permanece siempre

05:09.690 --> 05:11.520
parcheado y actualizado y de que sólo se puede

05:11.520 --> 05:14.280
acceder a él a través de una interfaz de gestión segura, así como controlar

05:14.280 --> 05:16.830
estrictamente el acceso.

05:16.830 --> 05:19.230
Ahora bien, estas son algunas de las cosas que debe

05:19.230 --> 05:21.570
tener en cuenta a la hora de decidir si va a virtualizar

05:21.570 --> 05:23.880
sus sistemas y migrarlos a una solución local

05:23.880 --> 05:25.410
o basada en la nube.

05:25.410 --> 05:27.540
En primer lugar, ¿va a virtualizar?

05:27.540 --> 05:30.360
En caso afirmativo, ¿va a utilizar máquinas virtuales tradicionales

05:30.360 --> 05:32.430
o va a recurrir a la contenedorización?

05:32.430 --> 05:34.410
¿Cuál es el riesgo frente a la recompensa?

05:34.410 --> 05:35.970
Hay que encontrar el equilibrio.

05:35.970 --> 05:37.230
Es una decisión empresarial

05:37.230 --> 05:39.780
y también de ciberseguridad.

05:39.780 --> 05:41.460
Así que tendrás que medir estas cosas

05:41.460 --> 05:44.100
y decidir qué es lo mejor para tu organización y sus casos

05:44.100 --> 05:45.723
de uso particulares.