- há 4 semanas
Categoria
🗞
NotíciasTranscrição
00:00E começamos a semana com uma grande indisponibilidade dos serviços da Amazon.
00:05Diversos sites, diversas plataformas, sistemas que hospedam em um dos principais serviços da Amazon,
00:11o AWS apresentou diversas indisponibilidades lentidão.
00:16E a própria Amazon já soltou uma nota apresentando que houve erros em latência,
00:22já já vou explicar o que é isso, e também indisponibilidade em diversos serviços de comunicações
00:27com outras soluções de clientes, soluções também da própria Amazon.
00:32Isso começou por volta das 3 horas da manhã, horário dos Estados Unidos, início da manhã na Europa.
00:39E aqui merece nós fazermos uma análise técnica, claro, de modo não conclusivo,
00:43mas apenas observando os fatos e as notas que já foram lançadas
00:47e também trazendo como nós poderíamos minimizar os impactos.
00:51Então, primeiro de tudo, é importante você saber que a Amazon é um dos principais players de cloud.
00:57E o que são cloud? Cloud são servidores que estão disponíveis em data centers
01:02que entregam serviços, você pode passar os seus dados para lá e eles te entregam serviços
01:07e você pode utilizar os serviços nas suas empresas sem você precisar ter, comprar servidores caríssimos,
01:14manter uma infraestrutura de telecomunicações interna na sua empresa.
01:17É o que nós chamamos de cloud.
01:18E esse erro impactou diversos serviços internos da Amazon.
01:23E aqui a gente merece destacar alguns serviços que a própria Amazon divulgou,
01:26como, por exemplo, os serviços de DNS interno, que é uma das principais causas aí.
01:31O serviço de DNS interno, o API, significa que são sistemas que traduzem nomes para serviços
01:36e endereços aí, IPs nos computadores internos da Amazon.
01:40Além também de outros serviços como o DynamoDB, que é o banco de dados rápido
01:44e totalmente aí gerenciado pela Amazon.
01:46O Lambda também, que é um outro serviço que executa código sem precisar de servidores aí.
01:51Também nós temos um outro serviço da Amazon que foi impactado, que é o serviço EC2,
01:55que são máquinas virtuais que as pessoas podem alugar ao invés de comprar servidores caríssimos internos aí das empresas.
02:03E também serviços que também envolvem dependências em cascatas.
02:07Quaisquer serviços da Amazon com outros fornecedores.
02:11E o que aconteceu impactou diversos clientes no mundo.
02:13Nós podemos destacar aí clientes que envolvem aplicativos de redes sociais,
02:18jogos online, como, por exemplo, Fortnite, o Roblox, que é um jogo muito conhecido aí das crianças,
02:25bancos também, fintechs também na Europa,
02:28serviços que envolvem, empresas que envolvem IoT, internet das coisas,
02:32casas automatizadas que têm as suas dependências aí sendo monitoradas,
02:36sendo também hospedadas as plataformas, né, que gerenciam IoT por dispositivos que estão hospedados na Amazon.
02:42Também empresas que envolvem e-commerce e serviços aí em geral,
02:46que entregam serviços SaaS aí pela internet, tá?
02:49E, claro, tudo isso ainda está sendo investigado ainda pela equipe,
02:54tanto pela Amazon como também por outras equipes contratadas pela Amazon ou interessados também.
02:58Mas, de acordo com os sintomas, nós podemos aí identificar algumas causas aí possíveis.
03:04Claro, repito, de modo não conclusivo.
03:06Mas nós temos aí a possibilidade de ter isso ser uma falha técnica na conectividade interna da própria Amazon.
03:13Isso é uma nota que a própria Amazon divulgou quando falou que está acontecendo falhas nos servidores DNS
03:19e é o que até agora nós temos como uma informação mais sólida, ou seja, a rede de computadores.
03:26O que é o servidor DNS?
03:28É o servidor responsável por gerenciar o nome dos computadores,
03:32traduzindo para os endereços, onde os acessos são devidamente feitos, os endereços IPs.
03:38Claro, óbvio que a empresa ainda não vai,
03:41e mesmo depois que o caso estiver já finalizado,
03:44nenhuma empresa de tecnologia e também de outras áreas divulga 100% o que acontece nos problemas técnicos,
03:50até porque, senão, pode deixar o ambiente mais sujeito a ataques e comprometer segredos industriais.
03:56Então, é natural que aconteça, sim, a prestação de contas, a transparência,
04:01porém, de modo não assertivo, mostrando exatamente o que aconteceu,
04:06como ocorreu, por questão até de segurança da própria empresa
04:09e também protegendo a imagem da própria empresa.
04:12Mas, até agora, o que nós temos de modo transparente, divulgado pela Amazon, repito,
04:16é a falha na conectividade interna dos computadores,
04:20problemas na rede de computador da própria Amazon.
04:24Problemas internos também na rede aqui dos Estados Unidos,
04:28isso vale destacarmos que esse erro aconteceu principalmente na costa leste,
04:34nos servidores, nas redes de computadores,
04:36em toda a estrutura que está na costa leste dos Estados Unidos.
04:39também existe a possibilidade de um comportamento inesperado no sistema,
04:43alguma falha técnica.
04:44Não podemos, também, crucificar a Amazon.
04:46Todos os sistemas têm o que nós chamamos de tempo de uptime e tempo de downtime.
04:51O que significa tempo de uptime?
04:53É quanto que aquele sistema consegue operar por ano
04:57sem cair, sem ter uma degradação aí da qualidade daquele serviço.
05:01E também existe o tempo de downtime, que é o contrário.
05:05Quanto tempo que aquele serviço comumente acaba ficando indisponível por ano.
05:10E quando nós pegamos esses dois itens, é o que nós chamamos de SLA,
05:16que é o Service Level Agreement, que é importantíssimo.
05:18Depois, com essa falha, você também começar a reparar isso nos contratos que você assinar.
05:23Observe, seja o contrato com a Amazon, o contrato com a Microsoft,
05:26seja qualquer contrato, normalmente ele vem escrito lá qual que é o tempo de SLA
05:31que aquela empresa está conseguindo aí, observando o cenário passado,
05:36observando outros clientes, qual que é o tempo que aquela empresa consegue te entregar de SLA.
05:41E o SLA é composto pelo downtime e pelo uptime.
05:44E você, como cliente dessas empresas, tem que observar.
05:46Se, de repente, ficar oito horas por ano sem aquele serviço,
05:51ou seja, eles podem te garantir oito...
05:53Eles podem se comprometer, né?
05:55Eles podem tentar, pelo menos, declarar para você que aquele serviço tem oito horas,
06:00por exemplo, de downtime.
06:01E aí, para você saber o SLA, que é em porcentagem,
06:03você pega essas oito horas e faz análise comparado ao percentual relacionado ao tempo,
06:10pensando na quantidade de horas durante o ano, tá?
06:14Mas imagina se essas oito horas realmente são ok para você.
06:18Você aceitaria ficar sem aquele serviço por oito horas ao longo de um ano?
06:22E você pode tentar negociar isso aí com o provedor de serviços cloud,
06:26no caso aqui com a Amazon, ou seja lá qual for.
06:29Então, tanto o uptime quanto o downtime
06:31são componentes que interferem diretamente nas falhas que acontecem aí nos sistemas.
06:37Também nós temos aí erros, que pode ser também erros de atualização automática.
06:42Normalmente, os sistemas, eles são configurados para receberem as atualizações durante a madrugada,
06:50claro, até para evitar prejudicar aí o andamento, o uso durante o dia.
06:55Isso pode também estar relacionado com o que aconteceu,
06:58por causa que, repito, foi uma falha que aconteceu principalmente na madrugada,
07:02e nós temos serviços que monitoram isso.
07:05Existe o próprio serviço Downtown Detector, que apontou exatamente
07:09que por volta das três, entre três e quatro horas da manhã,
07:13foi onde diversos monitores de redes, de serviços online,
07:18começaram a monitorar que existiu aí, estava tendo um downtime,
07:22uma indisponibilidade por volta das três da manhã, horário dos Estados Unidos.
07:26Repito, pode sim ser uma causa de atualização automática.
07:30Fica questionável, se realmente for comprovável isso,
07:33porque uma atualização não pode vir diretamente para os equipamentos
07:37que estão sendo utilizados.
07:39Nós chamamos isso na área técnica de equipamentos em produção.
07:42Então, quando acontece uma atualização, primeiro nós temos que mandar para uma área
07:45que vai homologar, testar, para saber se aquela atualização
07:49de todos os equipamentos, dos roteadores, dos sistemas operacionais,
07:53das plataformas, de toda a arquitetura computacional que a Amazon utiliza, por exemplo,
07:58não pode uma atualização dos fornecedores entrar direto para o ambiente de produção.
08:04Tem que mandar para um ambiente de teste, ser testada, homologada, verificada
08:08e depois já ser passado para o ambiente de produção.
08:12Mas pode sim, acontece muito com empresas de pequeno, de médio, pode também empresas grandes,
08:17erros de atualização automática.
08:20Também pode, uma outra causa, pode ser o estresse operacional, né,
08:23que em larga escala, uma vez que a Amazon é um dos maiores players no mundo.
08:29Lembrando que quando é madrugada nos Estados Unidos, manhã na Europa e já final da tarde na Ásia.
08:38Ou seja, grande parte dos acessos, dois mercados importantes no mundo estão já trabalhando.
08:44Tanto a Europa quanto a Ásia já estão também conectados em servidores aí da Amazon.
08:49E pode sim, então, ter uma sobrecarga operacional que acabou trazendo essa indisponibilidade aí nos serviços.
08:55Isso também seria questionável, porque existe um processo que a gente chama de gerenciamento da capacidade,
09:01onde as empresas devem observar se todos os recursos computacionais estão preparados ou não
09:07para aguentar a demanda de que aqueles clientes podem gerar conectados nos sistemas.
09:13Óbvio, como estamos falando de uma empresa grande,
09:16é muito comum que empresas grandes trabalham com folga de capacidade.
09:20Só que se tiver um acesso muito maior do que a carga prevista,
09:28e até também do que aquela gordura esperada,
09:31óbvio que não teria nenhum sistema que aguentasse, porque aguentaria.
09:34Porque todo o sistema opera com uma folga, mas todo o sistema também tem o seu limite.
09:42E também existe uma possibilidade de ser ataques hackers.
09:46Repito, nada de modo conclusivo.
09:49Mas por que ataques hackers?
09:51Que é comum que ataques hackers façam aí uma exploração de vulnerabilidades
09:55e consiga derrubar e sequestrar serviços,
10:00trazendo situações como essas que nós estamos vendo.
10:02Mas também existe a possibilidade de ser sabotagens por governos,
10:07ataques silenciosos estratégicos para testar dependências.
10:12O mundo está em diversos conflitos geopolíticos, em diversas guerras.
10:17Não me surpreenderia se realmente fosse comprovado
10:20que isso foi uma sabotagem por um outro governo,
10:23como também sabotagens por funcionários,
10:25podendo ser infiltrados também ou por concorrentes ou por governo.
10:29É o que a gente chama de insiders maliciosos.
10:31E no caso, se for uma sabotagem por funcionário,
10:35que envolve justamente ações propositais ou erros humanos
10:38dentro da própria empresa.
10:40Quando a gente fala de sabotagens por funcionários,
10:42ou melhor, erros humanos, nós temos ataques humanos intencionais
10:47e ataques humanos não intencionais.
10:49Quando a pessoa acabou, na verdade, nem atacando,
10:51ela acabou deixando de fazer ou fez algo de errado,
10:54o que acabou comprometendo aí os sistemas.
10:57Mas o que interessa para nós é que, como uma vez que nós observamos
11:01todo esse panorama, como que a gente pode aí minimizar os impactos?
11:05Bom, primeiro, você que é um cliente da Amazon,
11:07que sentiu que algum serviço que você utiliza,
11:11ou talvez você nem sabe, mas você contrata uma empresa,
11:14essa empresa acaba hospedando o sistema que ela vendeu para você,
11:19ela acaba hospedando isso na Amazon.
11:20Talvez você foi acessar esse sistema, não percebeu,
11:24o sistema estava lento ou estava indisponível.
11:28E como que você pode aí conversar com essa empresa que vendeu o sistema,
11:31ou como você pode se precaver?
11:33Primeiro, usar múltiplas regiões.
11:35Repito, os servidores que apresentaram essa indisponibilidade,
11:39essa latência mais alta, e quando eu falo de latência,
11:42a latência acaba sendo percebida para o usuário,
11:45como uma maior demora para acessar,
11:49o usuário clica em alguma tela do sistema, em algum link,
11:52demora muito mais para ser processado aquilo,
11:55ou seja, o usuário fica esperando mais,
11:57achando que o sistema está mais lento.
11:59Como que isso pode, você pode se precaver para isso?
12:01Você utilizar múltiplas regiões.
12:03Na hora que você estiver fazendo um contrato com a Amazon,
12:05ou qualquer outra empresa,
12:07peça para o vendedor, ou veja no site,
12:10qual seria a alteração no valor,
12:12se você utilizasse mais de uma região
12:15para armazenar os seus dados.
12:18É possível você fazer essa customização
12:20na maioria dos contratos.
12:22Quando você faz essa customização,
12:24você acaba tendo uma maior disponibilidade
12:26dos seus serviços.
12:27Uma outra estratégia que a gente pode minimizar
12:30também é ter planos alternativos,
12:32planos de redundância.
12:34Não depender apenas da Amazon,
12:36não depender apenas da Microsoft,
12:38não depender apenas de um outro provedor.
12:40Quando a gente lida com data centers,
12:42com soluções em cloud,
12:43nós temos que sempre ter redundância,
12:47não depender apenas de um único fornecedor.
12:49O próprio CCC, Cloud Credential Council,
12:52já soltou uma nota e disse que o maior risco
12:54em tempos de cloud,
12:56além de ser a falência do provedor cloud,
12:58é a dependência de um único provedor cloud.
13:01Isso faz parte da gestão de riscos.
13:03Uma outra técnica para a gente minimizar
13:05é fazer a avaliação de SLA dos contratos,
13:07como eu já falei.
13:08É importante também você ter redundância interna.
13:12De nada adianta você ter os seus dados
13:14e confiar todo o seu histórico de trabalho
13:17da sua empresa apenas em uma outra empresa fora.
13:20Não quer dizer que trabalhar na modalidade
13:22cloud computing não é bom.
13:24É muito bom, sim.
13:25Só que você não pode apenas confiar em cloud.
13:27Você tem que ter, sim, uma cópia
13:29dos seus dados internos.
13:30E aí você pode aplicar a estratégia de backup
13:333, 2, 1.
13:35O que significa isso?
13:36Significa que você tem que ter 3 cópias
13:38dos seus dados, no mínimo.
13:39Os dados que você tem lá,
13:41que estão hospedados lá na AWS,
13:43lá naquele seu data center,
13:44é legal que você não tenha apenas um arquivo
13:46com o seu banco de dados.
13:48Tenha 3 cópias dos arquivos que você usa,
13:51podendo ser as 3 cópias, claro,
13:53dentro da Amazon.
13:54É a estratégia 3.
13:55Aí depois você aplica a estratégia 2.
13:57A estratégia 2 é você não depender
13:59apenas da Amazon.
14:00Você ter esses 3 arquivos de dados
14:02que você utiliza na Amazon
14:04e em um outro data center.
14:06E depois vem o 1.
14:08O que significa 1?
14:09Você ter uma cópia desses dados,
14:11além de estar em dois data centers,
14:13não somente na Amazon,
14:14você também ter uma cópia desligada,
14:17uma cópia que a gente chama de offline,
14:19uma cópia fria,
14:19uma cópia onde só você consegue acessar.
14:22Talvez uma cópia em algum HD externo,
14:24em alguma mídia,
14:25que está somente sobre a sua gerência.
14:27E você consegue evitar vários tipos de ataques,
14:29como ataques do tipo Hansel,
14:31que pode sequestrar os seus dados.
14:33E é muito comum que um ataque do tipo Hansel
14:35também criptografe os backups,
14:37porque principalmente se você tiver backups quentes,
14:40backups ligados.
14:41Por isso é importante você utilizar
14:43a estratégia de backup 3, 2, 1.
14:47Três backups dos seus dados
14:48em duas empresas diferentes
14:50e em um backup totalmente offline.
14:54Só que nós temos alguns insights também
14:58que nós podemos observar dessa indisponibilidade
15:00que a Amazon trouxe.
15:01Repito, as investigações estão sendo concluídas,
15:05estão em andamento.
15:06Mas perante o que está acontecendo,
15:09perante as situações que nós temos,
15:13não é nem diagnósticos,
15:16mas perante esses sintomas que nós temos,
15:20fica alguns alarmes para nós,
15:24alguns insights suspeitos.
15:25Primeiro, o horário da falha, né?
15:27O horário da falha foi de madrugada,
15:30fora do horário comercial.
15:31E só por aí já pode questionar
15:34algumas hipóteses que nós colocamos.
15:36Não é todo o pessoal da tecnologia
15:38que está trabalhando para fazer atualizações
15:41ou que está configurando coisas aí
15:43durante a madrugada.
15:45Embora que, como eu também já falei,
15:47madrugada nos Estados Unidos,
15:49muitos acessos na Europa,
15:51muitos acessos lá na Ásia também.
15:53Mas é um ponto de investigação,
15:56o horário da falha,
15:57a região afetada também,
15:59que foi a costa leste dos Estados Unidos,
16:01que é uma região estratégica e sensível aí da AWS.
16:04Começamos a observar isso.
16:06Outro ponto de análise suspeita
16:09são as tensões geopolíticas recentes, né?
16:12Tensão entre Estados Unidos, China,
16:14Rússia, Oriente Médio.
16:16Será que não pode ter alguma investida
16:19em questão aí em tempos de guerras híbridas,
16:22onde a cibersegurança,
16:24as guerras cibernéticas
16:26são um dos pilares das guerras híbridas?
16:28Fica esse ponto também para prestarmos atenção.
16:30Outro ponto é interesse crescente
16:34em testar dependências globais aí das Big Techs,
16:37uma vez que a maioria das Big Techs
16:38são americanas.
16:40Até em que ponto os países
16:42estão mesmo dependentes aí das Big Techs?
16:46Será que não pode ser também um teste
16:47para testar a resiliência dessas Big Techs?
16:50Outro insight é as possibilidades
16:53de movimento, de reconhecimento estratégico
16:55em uma eventual guerra cibernética.
16:58O que aconteceria se este player fosse desligado?
17:03Ou seja, quais seriam os impactos?
17:05Quais países, quais empresas que conseguir
17:08continuariam de pé?
17:09Quanto tempo que as empresas demorariam
17:11para subir operações paralelas
17:13sem depender daquele grande player?
17:16Isso é interessante.
17:18Pode ser também possível movimento
17:20para reconhecimento em uma eventual
17:21futura guerra cibernética.
17:25Também temos aí uma coincidência
17:27com o período eleitoral.
17:28Diversos países estão em períodos eleitorais,
17:31fiscais, financeiros em diversas nações.
17:35E por fim, trago um próximo,
17:37um último insight.
17:39É um padrão similar
17:40a testes de resiliência geopolíticas
17:42como já observados também em 2023, 2024.
17:47Nós já tivemos outros cenários
17:50em tempos similares
17:51onde empresas foram invadidas
17:55ou empresas tiveram seus serviços prejudicados,
17:58seus computadores e seus servidores prejudicados.
18:01E diversas estratégias foram refeitas
18:03com bases nos resultados desses testes.
18:06Bom, nós como usuários, repito,
18:09a principal dica, recomendação e lição aprendida
18:13que nós temos que observar em tempos como esses é
18:16até em que ponto você depende
18:21de um player externo?
18:24Até em que ponto você depende
18:25de uma tecnologia externa?
18:28Esse é o conceito da soberania digital.
18:30Até que ponto o seu país
18:33depende de uma tecnologia
18:35de uma empresa que está em um outro país.
18:38Como que está a sua autossuficiência tecnológica?
18:44Você faz backups?
18:45Se cair a internet, a sua empresa para?
18:48Estamos na hora de rever situações como essas
18:51e pensarmos que nós temos sim
18:53que ter planos de contingência
18:55porque o mundo passou um bom tempo
18:57sem precisar de internet,
18:59sem ter internet e sem ter computadores.
19:01Então acho que é hora nós voltarmos
19:03e revermos nossos planos
19:05e processos manuais
19:07ou paralelos ou tecnológicos
19:10sem depender da internet.
19:13É o conceito da desclaudilização
19:15que essa instabilidade de hoje
19:17nos faz repensar.
19:20E essa é a coluna de tecnologia e segurança
19:23aqui da nossa Jovem Pan Premium
19:24com o Davis Alves.
19:25Música
19:27Música
Recomendado
0:20
0:32
Seja a primeira pessoa a comentar