Proteção para a Internet com a inovação da nuvem

Clarke Rodgers (00:10):
É difícil acreditar que houve um tempo antes da Internet, em que as preocupações relacionadas à segurança eram mais simples e claras. O mundo se transformou significantemente nos últimos 40 anos, e as conexões on-line tornaram-se um aspecto fundamental para as nossas vidas e empresas. Com isso, há maiores oportunidades, mas também grandes riscos.

Sou Clarke Rodgers, diretor de estratégia empresarial da AWS e seu guia para uma série de conversas com líderes de segurança da AWS aqui no Executive Insights.

Hoje, vamos conversar com Paul Vixie, vice-diretor de segurança da informação, vice-presidente e engenheiro renomado da AWS. Paul traz uma perspectiva única para a segurança da AWS por ter sido uma das primeiras pessoas que influenciaram a evolução da Internet. Participe da nossa conversa enquanto discutimos sobre o papel dos líderes de segurança em tornar a Internet um local mais seguro para a comunicação. Esperamos que você aproveite.

Clarke Rodgers (00:57):
Paul, agrademos muito pela sua participação. Você já participa ativamente no setor da Internet há bastante tempo. Você pode compartilhar conosco algumas de suas constatações sobre como tudo começou e como evoluímos até chegar onde estamos hoje, especialmente sob o ponto de vista da segurança?

Paul Vixie (01:11):
Bem, a segurança foi uma consideração a posteriori. Portanto, ela passa a fazer parte da história consideravelmente mais tarde. Apesar disso, as histórias são verídicas. Tudo começou como uma rede do governo dos Estados Unidos. Essa rede nunca havia sido usada pelo setor militar, pelo menos não no início. Assim, existe uma ideia equivocada de que os protocolos foram projetados para resistir a ataques cinéticos ou algo similar. Isso não é verdade. A ideia sempre foi ter um sistema baseado em melhores esforços. Dessa forma, quando o sistema funciona, ele funciona muito bem para muitas pessoas. Porém, quando ele não funciona, podem ocorrer algumas falhas catastróficas que uma rede mais robusta não teria.

Clarke Rodgers (01:48):
Em que momento você percebeu: “Opa, ninguém pensou na segurança”? E o que você identificou que precisava acontecer?

Paul Vixie (01:56):
Comecei a alertar sobre esse problema bem no início. Minha preocupação inicial estava relacionada ao spam. Não tínhamos uma autenticação nem qualquer medida para evitar que pessoas enviassem tráfego indesejado, pois em uma rede estritamente governamental, não havia vantagem em enviar esse tipo de tráfego.

Portanto, comecei a alertar sobre esse problema no início de 1992. E depois que comecei a trabalhar por conta própria como consultor, iniciei o primeiro projeto antispam, que acabou se transformando na primeira empresa dedicada ao antispam. O nosso sistema de reputação distribuído foi pioneiro nesse sentido. Eu gostaria de ter patenteado esse projeto. E esse sistema ainda é amplamente utilizado hoje em dia, embora a empresa que fundei para combater o spam tenha sido processada e não exista mais. Então essa empresa acabou. Contudo, a ideia e as tecnologias permanecem vivas, e minha convicção estava correta.

Clarke Rodgers (02:57):
Portanto, se há algo, e espero que haja, é isso que está encorajando você neste momento em que vemos a segurança sendo tratada com mais seriedade, não apenas pelos grandes provedores de serviços em nuvem, mas também pelas empresas clientes. Isso traz uma esperança para você?

Paul Vixie (03:13):
Eu tenho esperança, apesar de ter uma desilusão, pois acredito que tudo o que estamos fazendo é muito pouco e tardio demais. Mas precisamos aguardar que todo o mercado desperte e reconheça o problema. Você não pode simplesmente soar o alarme sobre esse problema como uma empresa ou uma pessoa.

Uma coisa que me faz ter esperança é a coleção de tecnologias que descobri depois de começar a trabalhar na Amazon. Descobri que, em grande escala, existem determinados problemas que podem ser generalizados e soluções que podem ser implementadas. Isso é algo que não pode ser feito por empresas menores que se concentram somente em uma área específica. Um exemplo disso é o que fizemos nos processadores Graviton para tornar nossas VMs mais seguras em comparação com outras VMs. Nenhuma outra empresa fez isso, exceto nós.

Se você analisar o Chipset Nitro e o Hipervisor Nitro, ninguém fez isso, exceto nós. Quando o Log4j foi lançado, por exemplo, não fomos afetados, mas conseguimos disponibilizar uma aplicação de patch para todos os nossos clientes em questão de horas, pois tivemos capacidade e agilidade suficientes para fazer e implementar isso globalmente de forma rápida. Em contrapartida, em um sistema menos centralizado no qual cada pessoa é responsável por suas próprias soluções, é necessário aguardar que toda a cadeia de suprimentos se mobilize.

Muitas das atividades que realizamos no início, com recursos limitados, quando os transistores custavam apenas um dólar cada, estão sendo gradualmente substituídas. Além de evitar os erros que nos permitiram entrar no mercado mais rapidamente do que os protocolos OSI, não há outra solução para corrigir isso, exceto por meio de plataformas de nuvem como a nossa.

Clarke Rodgers (05:09):
Enquanto aguardamos com expectativa os próximos anos, existe alguma tecnologia ou metodologia específica com a qual você esteja particularmente entusiasmado e que, na sua opinião, ajudará não apenas empresas como a nossa, mas também nossos clientes, a avançarem com as workloads de segurança e de conformidade?

Paul Vixie (05:31):
Bem, algo que é muito empolgante internamente é o avanço contínuo dos contêineres. O fato de ser possível operar 10 mil contêineres em um único chip e iniciar milhares de contêineres por segundo, se houver picos de carga, sem precisar que alguém altere completamente a abordagem de desenvolvimento de software, é promissor. À medida que mais pessoas adotam esse modelo, podemos superar problemas atuais, como a aplicação de patches.

Todos os dias, há algo que precisa ser corrigido. A menos que você tenha uma equipe dedicada para isso, acabará adiando, realizando tarefas de correção uma vez por semana, uma vez por mês, e assim por diante. E quando você faz isso, pode descobrir: “Nossa, para integrar essa aplicação de patch ao meu sistema também preciso atualizar essas outras partes, o que significa colocar tudo em um ambiente de testes.” Dessa forma, pode demorar meses entre o momento em que você descobre algo que precisa desesperadamente de correção e o momento em que finalmente tem esse patch integrado em seu sistema.

Não acho que alcançaremos o futuro glorioso retratado em Star Trek, em que tudo funciona sem complicações, se continuarmos nesse caminho. Portanto, tecnologias como contêineres, pode ser o Lambda, o Kubernetes ou o Firecracker, oferecem a você a oportunidade de estabelecer seu próprio pipeline de desenvolvimento, o chamado CI/CD, em que é possível criar uma imagem, testá-la e, se tudo for aprovado, implantá-la de imediato.

Você não precisa ter uma VM com ferramentas e lógica de integração suficientes para que seja possível realmente acessá-la e usá-la para realizar correções. É o que fazemos hoje, e não acho que mudará em grande escala. Embora eu ainda trabalhe dessa forma porque foi assim que fui ensinado, percebo que já está apresentando algumas falhas, e não recomendo que outras pessoas sigam o mesmo caminho. Não há razão para fazer isso, e haveria muitos benefícios se pudéssemos concordar: “Sim, vamos desenvolver soluções sem a necessidade de constantes intervenções posteriores”.

A perspectiva de eliminar a intervenção humana é mais uma ideia animadora. É triste dizer isso, pois foram os seres humanos que inventaram e desenvolveram toda essa tecnologia, mas precisamos reduzir o elemento humano se quisermos garantir uma segurança que não seja reduzida com o tempo.

A quantidade de software e de hardware que existe entre um ser humano e o valor entregue a um cliente é maior do que nunca. A nossa compreensão, em contrapartida, permaneceu relativamente fixa, o que quer dizer que entendemos uma fração cada vez menor dela toda vez que cresce. Isso não vai funcionar. Teremos que descobrir como garantir que a complexidade não crie resultados indesejáveis. Novamente, isso requer mais disciplina e a redução da intervenção humana.

Clarke Rodgers (08:18):
Com essa ideia em mente sobre o acesso por parte dos seres humanos e as redes, a ideia da abordagem Zero Trust evoluiu ao longo dos anos. Qual é a sua opinião sobre o Zero Trust, tanto da perspectiva da AWS, ou seja, quais as nossas percepções sobre essa abordagem e como a implementamos internamente, quanto da perspectiva do cliente? Como os clientes devem encarar o modelo Zero Trust?

Paul Vixie (08:39):
O elemento central e irredutível do Zero Trust é mal compreendido. Por exemplo, já ouvi pessoas falando sobre isso e dizendo: “Basta colocar tudo on-line, tornar tudo acessível e proteger os serviços e servidores. Ofereça proteção para a rede sem depender de um perímetro.” Este não é o objetivo do Zero Trust, e essa ideia não funciona. Ainda é necessário ter um firewall, mas uma vez dentro dele, você não deve presumir que há uma confiança especial apenas por estar dentro do perímetro.

Isso elimina o pressuposto de que acessibilidade implica credibilidade. Essa presunção costumava ser conhecida como “exterior crocante” e “interior macio e pegajoso”. Não queremos ter um interior macio e pegajoso, mesmo que tenhamos um exterior crocante. Você precisa ter um sistema que automatize a identidade, a autenticação e as permissões em grande escala. Por exemplo, enquanto você e eu estamos conversando neste momento, há alguns bilhões de eventos de autenticação por segundo acontecendo na Amazon Cloud.

E não adotamos nenhum tipo de “truque barato”, como armazenar em cache os resultados recentes e presumir que, se você teve permissão há um segundo, ainda tem no momento. Não. Sempre realizamos a verificação e, em determinado momento, assumimos as consequências e falamos: “Nada menos do que isso abordará adequadamente a segurança no modelo Zero Trust”.

No entanto, a maioria dos sistemas foi projetada sob a premissa de que, se você conseguisse entrar, como eles não tinham um controle de acesso otimizado que funcionasse em grande escala, eles simplesmente permitiriam que você fizesse o que quisesse. É isso que estamos mudando. Existem vários padrões de autenticação diferentes. O nosso foi lançado antes e é bastante abrangente, mas nunca foi projetado para se tornar um padrão do setor. Assim, outras plataformas de nuvem estão desenvolvendo soluções semelhantes, e existem alguns padrões da indústria que estão tentando surgir.

E pelo que sei, sem ter ainda conversado com a equipe de atendimento, faremos o possível para garantir que qualquer cliente que deseje operar dessa maneira possa fazê-lo.

Clarke Rodgers (10:49):
No último ano, a IA generativa tem sido destaque em todos os noticiários e aparece quase diariamente em meu feed de notícias. Qual é a sua opinião sobre esse assunto do ponto de vista de um profissional de segurança? Qual é a sua visão sobre como os profissionais de segurança a estão utilizando para auxiliar na proteção, investigação e em atividades semelhantes?

Paul Vixie (11:10):
É necessário olhar para além da expectativa e se questionar: “Como será quando tudo se acalmar?” Em alguns casos, não sabemos. A IA generativa é uma tecnologia bastante nova, e muitos hardwares e softwares estão sendo criados para ela. Ninguém nunca sabe qual é o verdadeiro impacto de uma ferramenta até que ela seja usada por alguém que não seja o seu fabricante. Por exemplo, se você utilizar uma chave-inglesa como martelo, provavelmente não era essa a intenção do fabricante da chave-inglesa, mas pode funcionar em algumas situações.

Não temos ainda fortes indicações do que o uso dessa tecnologia realmente tornará possível. Isso só será possível quando o ciclo de expectativa chegar ao fim e um novo tema for destaque nas manchetes. Dito isso, a equipe da Amazon já realizou pesquisas, desenvolvimentos e implantações de soluções baseadas em inteligência artificial, no mínimo, nos últimos doze anos. Então, essa tecnologia não foi uma surpresa completa para nós.

Já temos um exemplo no sistema do CodeWhisperer que utiliza técnicas de IA generativa, porém, não se parece em nada com o que está sendo destaque nas manchetes. Vejo isso acontecendo em todos os tipos de sistemas. Por exemplo, ao realizar a detecção de anomalias, você analisa os fluxos de telemetria do seu sistema e examina eventos que podem indicar algo errado, ou eventos que sugerem um possível ataque. Agora, com essa tecnologia, será possível correlacionar esses eventos de forma mais eficaz. E, novamente, sinto que mal vimos 1% do que será possível.

Portanto, embora eu rejeite o ciclo de expectativas e deseje que possamos ser sérios desde o início, também reconheço que há algum mérito real aqui. Estou trabalhando com algumas equipes do setor de segurança da AWS que estão tentando responder exatamente a esta pergunta: “O que podemos fazer para atender melhor nossos clientes agora que essa tecnologia está disponível e é compreendida por todos?”

Clarke Rodgers (13:14):
E como auxiliar os profissionais de segurança, que são seres humanos, com grande parte do trabalho pesado do ponto de vista tecnológico, usando ferramentas de IA generativa?

Paul Vixie (13:25):
Sim, e não estou sugerindo que isso seja apenas um plug-in de produto. O maior sucesso da Amazon com nossa nuvem sempre foram os fluxos de trabalho que possibilitam que os nossos clientes a adotem e desenvolvam. E assim, uma das primeiras iniciativas que tivemos no campo dos grandes modelos de linguagem foi o Bedrock. A ideia é: se você optar por usar um grande modelo de linguagem, também estará disposto a arcar com o custo do treinamento? Você deseja ter que desenvolver o modelo?

Porque pode exigir milhares ou dezenas de milhares de horas de processamento em um computador bastante dispendioso. Se houver diversos modelos desenvolvidos previamente e disponíveis em um menu para você escolher, sem a necessidade de pagar para copiá-los para o seu próprio sistema, você pode simplesmente implementar sua lógica na VPC ou em qualquer outra solução que esteja trabalhando em nosso ambiente de nuvem com acesso direto às APIs que utilizam esses modelos de assinatura.

Assim, a premissa original, de que eu não estava ciente na época e tive que aprender após começar a trabalhar aqui, é a ideia fundamental da nuvem, que é ter uma quantidade elástica de recursos de computação em conjunto com uma quantidade elástica de recursos de armazenamento, disponíveis conforme necessário, sem penalidades de acesso. Foi essa premissa que nos permitiu evoluir. Agora, expandimos isso para a IA generativa para que as pessoas que são muito ambiciosas em seu segmento de mercado possam fazer com nossa nuvem e LLMs o que sempre fizeram com nossa nuvem sem esses LLMs. Nós adoramos essa ideia. Eu adoro porque o verdadeiro poder disso vai se revelar com o que nossos clientes fizeram com essa ideia..

Clarke Rodgers (15:13):
E os clientes já têm a confiança em todas as ferramentas de segurança que eles têm usado ao longo dos anos, bem como em outros aspectos que agora podem ser aplicados a ferramentas como o Bedrock e quaisquer outras que possam surgir.

Paul, muito obrigado pela sua participação.

Paul Vixie (15:26):
Foi um prazer. Obrigado novamente por me receber.