WEBVTT

00:00.150 --> 00:01.770
-: O mais novo tipo de virtualização que

00:01.770 --> 00:03.540
está se tornando popular em nossas redes

00:03.540 --> 00:05.790
é conhecido como virtualização baseada em contêineres,

00:05.790 --> 00:07.980
também conhecida como conteinerização.

00:07.980 --> 00:10.290
No entanto, esse tipo de virtualização é muito mais

00:10.290 --> 00:12.780
voltado para servidores do que para o usuário final.

00:12.780 --> 00:14.460
Com esse tipo de virtualização, o kernel

00:14.460 --> 00:16.440
do sistema operacional é compartilhado

00:16.440 --> 00:19.440
entre várias máquinas virtuais, mas o espaço do usuário para cada

00:19.440 --> 00:22.740
máquina virtual é criado e gerenciado exclusivamente.

00:22.740 --> 00:25.020
A conteinerização é um tipo de virtualização

00:25.020 --> 00:27.900
que é aplicada por um sistema operacional host para fornecer

00:27.900 --> 00:31.230
um ambiente de execução isolado para um aplicativo.

00:31.230 --> 00:33.390
A conteinerização é considerada bastante

00:33.390 --> 00:35.370
segura porque impõe a segmentação e a separação

00:35.370 --> 00:38.280
de recursos no nível do sistema operacional.

00:38.280 --> 00:40.290
Agora, a virtualização de contêineres é

00:40.290 --> 00:42.210
comumente usada com servidores Linux e

00:42.210 --> 00:43.950
alguns exemplos dessa virtualização

00:43.950 --> 00:46.980
baseada em contêineres incluem coisas como o Docker, o Parallels

00:46.980 --> 00:48.960
Virtuozzo e o projeto OpenVZ.

00:48.960 --> 00:51.870
Agora, como é realmente a conteinerização?

00:51.870 --> 00:53.610
Bem, você tem um hardware e, em cima

00:53.610 --> 00:56.460
desse hardware, um sistema operacional host, geralmente

00:56.460 --> 00:59.430
Linux, e um gerenciador de contêineres.

00:59.430 --> 01:02.820
Algo como Kubernetes, Docker ou algo do gênero.

01:02.820 --> 01:05.100
Agora, esse gerenciador de contêineres será usado para

01:05.100 --> 01:08.070
criar diferentes contêineres que contêm diferentes aplicativos.

01:08.070 --> 01:10.290
Nesse caso, tenho três contêineres.

01:10.290 --> 01:12.000
Tenho o primeiro ambiente, que é baseado

01:12.000 --> 01:14.340
no kernel do sistema operacional host, neste exemplo,

01:14.340 --> 01:16.170
um sistema Linux que está sendo usado.

01:16.170 --> 01:18.720
Portanto, temos o contêiner um executando o Linnux

01:18.720 --> 01:20.700
e ele contém alguns aplicativos.

01:20.700 --> 01:23.130
Agora, o contêiner dois pode fazer a mesma coisa e

01:23.130 --> 01:25.290
o contêiner três pode fazer a mesma coisa.

01:25.290 --> 01:27.210
Como todos os três contêineres estão compartilhando os

01:27.210 --> 01:28.980
mesmos arquivos do sistema operacional do host.

01:28.980 --> 01:30.750
Isso consome muito menos recursos do

01:30.750 --> 01:33.690
que fazer a virtualização pura usando máquinas virtuais.

01:33.690 --> 01:35.730
Como falamos sobre a virtualização.

01:35.730 --> 01:38.340
Se, em vez disso, usarmos máquinas virtuais individuais, cada uma

01:38.340 --> 01:40.860
precisará de sua própria cópia de um sistema operacional.

01:40.860 --> 01:43.740
E isso pode representar de 8 a 10 gigabytes para cada um.

01:43.740 --> 01:45.000
Mas com os contêineres, todos nós

01:45.000 --> 01:47.280
podemos compartilhar o mesmo sistema operacional.

01:47.280 --> 01:50.250
Portanto, a conteinerização usa muito menos base de armazenamento e

01:50.250 --> 01:52.260
consome muito menos poder de processamento.

01:52.260 --> 01:55.050
Esse é o benefício real de usar algo como um contêiner

01:55.050 --> 01:56.970
do ponto de vista operacional.

01:56.970 --> 01:59.970
Agora, como esses contêineres são logicamente isolados.

01:59.970 --> 02:02.100
Na verdade, eles não podem interagir uns com os outros.

02:02.100 --> 02:04.080
Se eu quisesse que dois contêineres conversassem,

02:04.080 --> 02:06.480
teria que conectá-los por meio de uma rede virtual e fazer o roteamento

02:06.480 --> 02:07.890
e a comutação corretos para permitir

02:07.890 --> 02:09.330
que eles conversassem.

02:09.330 --> 02:11.970
Por padrão, eles não têm como se comunicar entre

02:11.970 --> 02:14.310
si, o que é ótimo do ponto de vista da segurança,

02:14.310 --> 02:16.410
pois temos essa segmentação.

02:16.410 --> 02:18.810
Agora, aqui está o seu grande aviso quando se trata de

02:18.810 --> 02:20.010
lidar com contêineres.

02:20.010 --> 02:22.890
Se um invasor comprometer o sistema operacional do host abaixo,

02:22.890 --> 02:24.990
por exemplo, o sistema operacional Linux

02:24.990 --> 02:27.960
que acabei de discutir, adivinhe o que acontece?

02:27.960 --> 02:30.810
Bem, esse ataque agora tem acesso a todos os contêineres em

02:30.810 --> 02:33.270
seus dados, porque esse único sistema operacional

02:33.270 --> 02:35.790
é usado por todos os contêineres hospedados.

02:35.790 --> 02:37.440
Essa é uma das maiores vulnerabilidades

02:37.440 --> 02:38.820
quando se usa contêineres.

02:38.820 --> 02:40.470
Posso ter um sistema de contêineres que esteja executando

02:40.470 --> 02:42.240
50 servidores diferentes no momento.

02:42.240 --> 02:43.980
E cada um deles está executando servidores

02:43.980 --> 02:46.230
e serviços diferentes usando a conteinerização.

02:46.230 --> 02:49.050
Mas se alguém conseguir acessar esse único servidor

02:49.050 --> 02:52.020
com o sistema operacional Linux, agora terá acesso a todos

02:52.020 --> 02:55.290
os 50 servidores hospedados e a todos os seus dados.

02:55.290 --> 02:57.480
Outro risco a ser considerado é como os contêineres

02:57.480 --> 03:00.390
e outras máquinas virtuais serão realmente hospedados.

03:00.390 --> 03:03.210
Quando começamos a contar com a virtualização e a computação em nuvem,

03:03.210 --> 03:05.040
torna-se muito importante reconhecer que

03:05.040 --> 03:07.680
nossos dados podem estar hospedados no mesmo servidor físico

03:07.680 --> 03:09.660
que os dados de outra organização.

03:09.660 --> 03:12.120
Ao fazer isso, introduzimos algumas vulnerabilidades

03:12.120 --> 03:13.920
na segurança de nossos sistemas.

03:13.920 --> 03:16.950
Primeiro, se o servidor físico falhar devido a algo que uma

03:16.950 --> 03:18.960
das outras organizações esteja fazendo,

03:18.960 --> 03:19.880
isso poderá afetar

03:19.880 --> 03:22.500
todas as organizações no mesmo servidor.

03:22.500 --> 03:24.960
Da mesma forma, se uma organização não estiver mantendo

03:24.960 --> 03:26.760
a segurança de seus ambientes virtuais,

03:26.760 --> 03:28.740
que estão hospedados nesse servidor físico,

03:28.740 --> 03:31.470
existe a possibilidade de um invasor utilizar isso em detrimento

03:31.470 --> 03:33.900
de todas as outras organizações hospedadas nesse

03:33.900 --> 03:35.880
mesmo servidor.

03:35.880 --> 03:38.220
Assim como há preocupações ao interconectar nossas

03:38.220 --> 03:40.170
redes com as de outras pessoas, também há preocupações

03:40.170 --> 03:42.210
ao hospedar dados de várias organizações no

03:42.210 --> 03:44.010
mesmo servidor físico.

03:44.010 --> 03:46.530
É importante configurar, gerenciar e auditar adequadamente

03:46.530 --> 03:48.780
o acesso dos usuários às máquinas virtuais que estão

03:48.780 --> 03:50.820
hospedadas nesses servidores.

03:50.820 --> 03:53.850
Além disso, queremos garantir que nossas máquinas virtuais

03:53.850 --> 03:56.580
tenham os patches, antivírus, animwire e controle de

03:56.580 --> 03:58.410
acesso mais recentes em vigor.

03:58.410 --> 03:59.760
Para minimizar o risco de sobrecarga

03:59.760 --> 04:02.490
dos recursos dos servidores físicos, é sempre uma boa

04:02.490 --> 04:04.920
ideia configurar nossas máquinas virtuais com

04:04.920 --> 04:08.280
failover, redundância e elasticidade adequados.

04:08.280 --> 04:09.810
Ao monitorar o desempenho da rede

04:09.810 --> 04:11.610
e os recursos dos servidores físicos,

04:11.610 --> 04:13.500
devemos ser capazes de equilibrar a carga

04:13.500 --> 04:15.570
em várias máquinas físicas em vez de depender

04:15.570 --> 04:17.370
de apenas uma.

04:17.370 --> 04:19.290
Outra vulnerabilidade que pode ser explorada

04:19.290 --> 04:21.330
por um invasor é quando usamos o mesmo tipo

04:21.330 --> 04:24.420
de hipervisor em todas as nossas máquinas virtuais.

04:24.420 --> 04:27.180
Assim, por exemplo, se nossa organização depender

04:27.180 --> 04:29.700
exclusivamente do hipervisor ESXi da VMware e uma

04:29.700 --> 04:32.280
nova exploração for criada para esse hipervisor,

04:32.280 --> 04:35.790
um invasor poderá usá-la contra todos os nossos sistemas.

04:35.790 --> 04:38.400
Portanto, se for bem-sucedido em um de nossos servidores, eles provavelmente

04:38.400 --> 04:40.830
tentarão fazê-lo no restante de nossos servidores.

04:40.830 --> 04:43.260
E se todos os nossos servidores usarem a mesma

04:43.260 --> 04:46.410
plataforma, neste caso, o ESXi da VMware, essa vulnerabilidade

04:46.410 --> 04:49.350
poderá ser explorada em toda a organização.

04:49.350 --> 04:51.420
No entanto, o desafio com isso é que, novamente,

04:51.420 --> 04:53.700
se utilizarmos várias plataformas de hipervisor,

04:53.700 --> 04:55.620
nossos custos de suporte e nossos requisitos

04:55.620 --> 04:57.360
de treinamento também aumentarão.

04:57.360 --> 05:00.090
Por esse motivo, a maioria das organizações opta por usar uma

05:00.090 --> 05:02.610
única plataforma, mas, pelo menos, elas estão tomando

05:02.610 --> 05:04.800
uma decisão de risco ponderada ao fazer isso.

05:04.800 --> 05:07.290
Para reduzir esse risco, a organização deve utilizar configurações

05:07.290 --> 05:09.690
adequadas, garantir que o hipervisor permaneça sempre

05:09.690 --> 05:11.520
corrigido e atualizado e que só seja acessível

05:11.520 --> 05:14.280
por meio de uma interface de gerenciamento segura, além de controlar

05:14.280 --> 05:16.830
rigorosamente o controle de acesso.

05:16.830 --> 05:19.230
Esses são alguns dos aspectos que você deve considerar

05:19.230 --> 05:21.570
quando começar a decidir se vai virtualizar seus

05:21.570 --> 05:23.880
sistemas e migrá-los para uma solução no local

05:23.880 --> 05:25.410
ou baseada na nuvem.

05:25.410 --> 05:27.540
Primeiro, você vai virtualizar?

05:27.540 --> 05:30.360
Em caso afirmativo, você usará máquinas virtuais tradicionais

05:30.360 --> 05:32.430
ou usará a conteinerização?

05:32.430 --> 05:34.410
Qual é o risco versus a recompensa aqui?

05:34.410 --> 05:35.970
Há um ato de equilíbrio que você precisa fazer.

05:35.970 --> 05:37.230
É uma decisão comercial

05:37.230 --> 05:39.780
e também uma decisão de segurança cibernética.

05:39.780 --> 05:41.460
Portanto, você terá que medir esses aspectos

05:41.460 --> 05:44.100
e decidir o que é melhor selecionar para sua organização e seus

05:44.100 --> 05:45.723
casos de uso específicos.