Segurança na nuvem: uma cartilha para formuladores de políticas

O crescimento da nuvem foi realmente surpreendente. Em menos de quinze anos, ele se tornou parte da vida cotidiana e de conversas casuais sobre como mover fotos e outros dados para a nuvem. Anúncios onipresentes em aeroportos, ônibus e sites incorporam ainda mais o termo na consciência coletiva da sociedade. As empresas de tecnologia relatam receitas de vários bilhões de dólares, cada vez mais impulsionadas por seus negócios em nuvem. Até o Pentágono está apostando na nuvem com seu contrato de US $ 10 bilhões com Joint Enterprise Defense Infrastructure (JEDI). ¹ Em 2020, espera-se que o mercado geral de serviços em nuvem seja de $ 266,4 bilhões, um aumento de 17 por cento em comparação com 2019. ²

A pandemia de coronavírus revelou a importância da nuvem para aumentar a resiliência social. De acordo com um artigo do Business Insider de março de 2020 , um especialista projetou que mais da metade (55 por cento) das cargas de trabalho seriam migradas para a nuvem em 2022, em comparação com 33 por cento agora; ele afirmou que essas projeções “agora parecem conservadoras, já que essas metas podem ser alcançadas um ano antes das expectativas, dado o ritmo [atual].” ³ Na esteira do surto inicial da pandemia e da mudança para o teletrabalho, executivos antes cautelosos começaram a ver a migração para a nuvem como uma necessidade urgente.

À medida que as empresas dependem cada vez mais dos serviços em nuvem, o papel dos enormes provedores de serviços em nuvem (CSPs) tem recebido maior escrutínio. As solicitações para regulamentar os CSPs têm crescido em meio a preocupações sobre o risco sistêmico de mudança das empresas para a nuvem. Por exemplo, um relatório de 2018 estima que uma interrupção de três a seis dias de um CSP importante causaria perdas econômicas de até US $ 15 bilhões. ⁴

No entanto, o debate sobre a segurança na nuvem permanece vago e as implicações de políticas públicas mal compreendidas. Isso começa com a pergunta: o que é a nuvem? A maior parte do debate é sobre a nuvem pública, ⁵ e a resposta curta é “a computação em nuvem é realmente apenas um nome chique para o computador de outra pessoa”, como explicou Rob Joyce, então chefe das Operações de Acesso Personalizado da Agência de Segurança Nacional dos EUA em 2016. ⁶

Pensando nas implicações das políticas públicas, a imagem de uma nuvem obscurece tanto quanto explica. Uma imagem mais matizada surge quando a nuvem é considerada em termos de suas camadas – desde os data centers físicos e cabeamento de rede que formam sua base até os ambientes de software virtual e aplicativos com os quais os usuários diários interagem. No entanto, um entendimento mais técnico só irá até certo ponto. Uma apreciação do mercado multibilionário de serviços em nuvem também é necessária.

O que torna a nuvem pública interessante é que os milhares de “computadores de outra pessoa” que a compõem estão concentrados nas mãos de alguns CSPs. Amazon Web Services (AWS), Microsoft Azure e Google Cloud são conhecidos como CSPs em hiperescala, com empresas como Alibaba Cloud e Tencent desempenhando um papel semelhante na China. À medida que os serviços em nuvem cresceram, algumas grandes empresas construídas nas costas desses gigantes da tecnologia, em suas variantes nos Estados Unidos e na China, garantiram a maior parte desse mercado lucrativo.

Proteger essa nova infraestrutura altamente complexa é uma tarefa hercúlea, possibilitada pelo tamanho e talento acumulado dos principais provedores de nuvem, mas também potencialmente ameaçada por sua crescente importância para setores críticos. Ao pensar sobre a segurança na nuvem a partir de uma perspectiva de política pública, a necessidade de abordar um problema de política pública existente deve ser ainda mais diferenciada da necessidade de abordar um problema de política pública emergente. O problema existente é o custo crescente dos ataques cibernéticos e a realidade de que a maioria das organizações – governos e empresas – não pode se proteger com eficácia. Muito poucas organizações podem rivalizar com as equipes de segurança dos principais CSPs e, portanto, é melhor confiar sua segurança às equipes de segurança dessas empresas externas. O problema emergente é o risco sistêmico associado a uma abordagem centralizada.

De modo geral, a segurança na nuvem é uma área de política nascente, especialmente para formuladores de políticas preocupados com o potencial risco sistêmico. À medida que os legisladores consideram os riscos associados à nuvem, será importante para eles conectar as ameaças aos impactos. Esta é uma tarefa difícil devido à variação no impacto potencial dependendo dos dados e serviços em risco. Além disso, qualquer regulamentação em potencial terá que equilibrar outras áreas de interesse da política pública, como governança de dados, geopolítica e política antitruste.

Esta cartilha fornece uma visão geral da nuvem e de suas dimensões de segurança, cobrindo os fundamentos de algumas das questões mais urgentes para formuladores de políticas e tecnólogos hoje. Em muitos casos, este artigo é apenas um ponto de partida, destacando a necessidade de mais estudos. Para evitar a recriação de um ciberespaço inseguro na nuvem, um estudo mais aprofundado sobre esses tópicos deve ser uma prioridade urgente. Esta cartilha agrega valor especificamente ao oferecer (1) uma conceituação das camadas da arquitetura dos serviços de nuvem na tabela 1 na página 9, (2) uma visão geral da evolução do mercado de nuvem no capítulo 2 começando na página 10, (3 ) uma linha do tempo dos principais incidentes de segurança em nuvem na tabela 5 na página 25, (4) um mapeamento de vetores de ameaças potenciais de segurança em nuvem para seus impactos de uma perspectiva técnica na figura 5 na página 30,

INTRODUÇÃO

Contar com outra pessoa, como um provedor de serviços em nuvem (CSP), para armazenar e processar dados requer confiança e disposição para abrir mão do controle. Existem diferentes razões pelas quais as pessoas às vezes estão dispostas a fazer isso. Freqüentemente, outra pessoa tem mais experiência para fazer algo, então as pessoas estão dispostas a deixá-los fazer isso. Às vezes, outra pessoa pode fazer uma tarefa mais barata ou mais rápida, então outros estão dispostos a entregar a tarefa. Em outras ocasiões, as pessoas podem simplesmente fazer algo porque aparentemente todo mundo está fazendo. Governos, empresas e indivíduos têm confiado cada vez mais na nuvem pública ou híbrida, administrada por CSPs, por essas várias razões.

O que torna a nuvem particularmente interessante é que os milhares de “computadores de outra pessoa” que a compõem estão concentrados nas mãos de alguns CSPs. Ao contrário da Organização dos Países Exportadores de Petróleo (OPEP), esse oligopólio não é determinado pela localização geográfica dos recursos; a estrutura de mercado da nuvem é uma combinação de dependência do caminho histórico, acesso a grandes mercados e, mais importante, o efeito de rede. ⁷ Amazon Web Services (AWS), Microsoft Azure e Google Cloud são conhecidos como CSPs de hiperescala, com empresas como Alibaba e Tencent desempenhando um papel semelhante na China. ⁸

Com esse crescimento explosivo, não é surpresa que os legisladores estejam cada vez mais voltando sua atenção para a nuvem. A computação em nuvem e o armazenamento afetam (e são afetados por) formuladores de políticas em diversas áreas, como governança de dados, desenvolvimento tecnológico, influência geopolítica e legislação antitruste, tornando a segurança da nuvem um tópico particularmente relevante para políticas públicas. Conforme a infraestrutura de nuvem pública se tornou mais consolidada no mercado de infraestrutura de nuvem, aumentaram as preocupações sobre os riscos sistêmicos potenciais. Por exemplo, um relatório de 2018 estima que uma interrupção de três a seis dias de um CSP importante causaria perdas econômicas de até US $ 15 bilhões. ⁹No entanto, o debate sobre a segurança na nuvem permanece vago e as implicações de políticas públicas são mal compreendidas. Este artigo fornece uma visão geral das diferentes dimensões das políticas que devem ser consideradas, de modo a informar um debate mais matizado e robusto.

As preocupações com os riscos sistêmicos da nuvem se tornaram comuns. No entanto, é importante não perder de vista o quadro completo e não confundir duas dimensões importantes das preocupações de política pública em torno da segurança da nuvem: a necessidade de resolver um problema de política pública existente e a necessidade de resolver um problema emergente.

O problema de política pública existente é a segurança cibernética. Em 2017, o crime cibernético custou à economia global até US $ 600 bilhões. ¹⁰ Em 2019, a Accenture estimou que um valor total de US $ 5,2 trilhões estará em risco devido ao crime cibernético em todo o mundo nos próximos cinco anos. ¹¹ É claro que essas estimativas são apenas isso – aproximações que variam amplamente. Os números precisos importam menos do que a escala de custos potenciais. Resumindo, apesar dos vários esforços para conter esses riscos nos últimos vinte e cinco anos, os custos dos ataques cibernéticos continuam a aumentar, não diminuir, e a maioria das organizações – governos e empresas – luta para se proteger com eficácia.

A mudança para a nuvem pública ou híbrida é uma das opções mais promissoras para melhor proteger as organizações contra ataques cibernéticos. Muito poucas organizações podem rivalizar com as equipes de segurança dos grandes CSPs e, portanto, é melhor confiar sua segurança a essas equipes externas. Isso não significa que a nuvem seja segura, mas é mais segura em relação às medidas de segurança que a maioria das organizações poderia alcançar. Essa é parte da razão pela qual empresas como a Capital One continuam a buscar sua estratégia de “nuvem primeiro”, apesar dos enormes custos de reputação que se seguiram à violação de dados em 2019 e porque os governos têm implementado políticas de “nuvem primeiro”. ¹²

Resumindo, a mudança para a nuvem é a solução “Fort Knox” para o problema existente e crescente de insegurança cibernética. De acordo com o professor de Harvard Jonathan Zittrain, “Fort Knox representa o ideal de segurança por meio da centralização: navios de guerra, tanques e 30.000 soldados cercam um cofre contendo mais de $ 700 bilhões em ouro do governo americano”. ¹³ CSPs privados representam a mesma ideia para a proteção de ativos e processos digitais. ¹⁴ De Alex Stamos, que atuou como ex-diretor de segurança da informação (CISO) do Facebook, ao CISO de uma grande instituição financeira, os especialistas técnicos concordam que a segurança fornecida pelos principais CSPs é significativamente melhor do que a maioria das organizações pode alcançar. ¹⁵

O problema emergente de políticas públicas são as novas formas de risco sistêmico que os serviços em nuvem podem criar. Como destacado pelo vilão Goldfinger no filme homônimo de 1964, James Bond, a desvantagem de criar um Fort Knox é que ele se torna uma inspiração e um sonho para os criminosos atacarem e que, uma vez violado, o impacto pode ser devastador e generalizado. Este é um problema de política pública importante a ser considerado, mas que permanece hipotético até o momento.

No entanto, a segurança na nuvem não é uma questão de tudo ou nada. É simplesmente menos bem conceitualizado do que a segurança cibernética existente. Os riscos potenciais variam desde os efeitos em cascata de interrupções temporárias até a exploração de vulnerabilidades no hardware e software subjacentes que executam a nuvem. E, é claro, embora a nuvem possa ser vista como “o computador de outra pessoa”, os fundamentos da segurança cibernética ainda se aplicam e os clientes podem se expor ao não cumprir sua parte da responsabilidade compartilhada pela segurança. Compreender os novos riscos potenciais associados à nuvem e quais podem ser seus impactos é uma tarefa crucial para os formuladores de políticas empreenderem agora.

Este artigo é o primeiro passo para construir esse entendimento. Como uma cartilha para formuladores de políticas na nuvem, este estudo descreve como conceituar a nuvem e descreve a evolução do mercado de nuvem. Em seguida, discute a segurança da nuvem em detalhes, usando uma linha do tempo de incidentes anteriores junto com estudos de caso detalhados dos incidentes mais significativos que são conhecidos publicamente. Juntos, eles servem como base para o desenvolvimento de uma estrutura abrangente para mapear os vários riscos e um esquema de gravidade para priorizá-los. O documento então descreve brevemente questões adicionais de políticas públicas a serem levadas em consideração ao considerar a segurança na nuvem. Finalmente, ele resume e discute as implicações para as políticas públicas, ao mesmo tempo que relaciona áreas promissoras para futuras pesquisas relacionadas à segurança.

CAPÍTULO 1: O QUE É A NUVEM?

Em seu nível mais básico, a nuvem é simplesmente o computador mais poderoso de outra pessoa que funciona para outras pessoas. Não há uma única nuvem – portanto, embora possa ser correto dizer que os dados cruzam a Internet, não é correto dizer que esses dados são armazenados de forma efêmera, pairando em algum lugar do céu. Na verdade, a nuvem armazena e transporta dados em uma infraestrutura global de centros de dados e redes. Uma descrição mais precisa da nuvem é que os serviços em nuvem são uma abstração de um sistema paralelo de computadores, data centers, cabos, infraestrutura e redes que fornecem o poder de executar operações digitais de empresas e organizações modernas e de armazenar seus dados. Construir a infraestrutura necessária para serviços em nuvem em uma escala verdadeiramente global foi uma das conquistas arquitetônicas mais significativas da última década – e existe principalmente nos bastidores, fora do conhecimento comum. Dito isso, como destaca o capítulo 2, o mercado de nuvem evoluiu significativamente ao longo dos anos, assim como a própria nuvem.

Para entender o impacto transformador dos serviços em nuvem, primeiro considere como a computação, por exemplo, funcionava antes da ampla adoção da nuvem. Nas últimas décadas, para cada tarefa computacional que uma empresa ou indivíduo precisava realizar, eles precisavam ter seus próprios computadores, servidores e até mesmo centros de dados. Por exemplo, a Capital One, uma grande empresa do setor de serviços financeiros, anunciou em 2015 que moveria todos os seus aplicativos para a nuvem AWS, o que significa que, subsequentemente, não precisou construir e comprar armazenamento de data center à medida que lançava novo aplicativos. ¹⁶ Para empresas menores, os custos de aquisição de tecnologia da informação (TI) – ou seja, comprar todos os computadores necessários e configurar a rede necessária para armazenamento interno de dados e recursos de processamento – eram proibitivos para um crescimento rápido.

Quando empresas como Amazon, Google e Microsoft começaram a oferecer armazenamento e poder de computação como serviços no final dos anos 2000, elas mudaram esse paradigma. Esses gigantescos gigantes de TI poderiam gerenciar redes de data centers, servidores e redes em escalas globais – o que significa que poderiam tirar proveito das economias de escala para oferecer computação como serviço – a preços que superariam os custos internos da maioria das empresas e ainda os tornariam um lucro, especialmente após quedas significativas de preços a partir de 2014.

Amazon, Google e Microsoft se concentram principalmente em fornecer os elementos básicos da infraestrutura de TI – espaço de servidor e capacidade de computação – que são altamente escalonáveis, configuráveis de maneira personalizada e capazes de ser rapidamente implantados e alterados. No entanto, a computação em nuvem abrange uma ampla gama de tipos de serviço em que predominam diferentes empresas (ver capítulo 2), e os serviços fornecidos incluem a infraestrutura básica para construir plataformas digitais em cima de aplicativos prontos entregues pela Internet. Esses vários serviços podem ser agrupados nos três principais tipos de serviços em nuvem. Na prática, os principais CSPs oferecem serviços diferentes abrangendo todas as três categorias. ¹⁷

Infraestrutura como serviço (IaaS): os CSPs fornecem acesso básico a armazenamento, rede, servidores ou outros recursos de computação.
Plataforma como serviço (PaaS): os CSPs fornecem um ambiente – uma plataforma – para que os clientes criem e entreguem aplicativos.
Software como serviço (SaaS): os CSPs criam, executam e hospedam aplicativos fornecidos pela Internet, que os clientes pagam para acessar. ¹⁸

DEFININDO COMPUTAÇÃO EM NUVEM

Dada a importância particular da computação em nuvem como um serviço, vale a pena considerar uma definição de 2011 de computação em nuvem pelo Instituto Nacional de Padrões e Tecnologia (NIST) do Departamento de Comércio dos EUA – a agência que define os padrões de tecnologia. De acordo com o NIST, “a computação em nuvem é um modelo para permitir acesso onipresente, conveniente e sob demanda a um pool compartilhado de recursos de computação configuráveis (… Redes, servidores, armazenamento, aplicativos e serviços) que podem ser rapidamente provisionados e lançado com o mínimo esforço de gerenciamento ou interação do provedor de serviços. ” ¹⁹ Essencialmente, esta definição aborda cinco características principais da computação em nuvem: 1) autoatendimento sob demanda, 2) elasticidade rápida, 3) serviço medido, 4) amplo acesso à rede e 5) pool de recursos. ²⁰

O primeiro, o autoatendimento sob demanda, significa que os clientes podem usar os recursos apenas quando necessário e não precisam pagar mais. Eles também são isolados uns dos outros, mesmo quando fazem uso dos mesmos recursos. Os clientes podem selecionar recursos de computação automaticamente – sem a necessidade de qualquer suporte humano dos CSPs que usam. E do lado do CSP, o autoatendimento sob demanda significa que qualquer solicitação do cliente pode ser tratada automaticamente. Nenhum técnico precisa configurar um servidor quando um cliente seleciona capacidade de computação adicional. Os sistemas digitais automáticos tratam da alocação, provisionamento e implantação da infraestrutura, plataformas e serviços necessários.

Em segundo lugar, elasticidade rápida significa que a quantidade de recursos dedicados a qualquer cliente pode, a qualquer momento, aumentar ou diminuir rapidamente, dependendo das necessidades do cliente. Como a capacidade de recursos de um CSP é exponencialmente maior do que as necessidades prováveis de qualquer cliente, os clientes podem escalar suas operações rapidamente sem sobrecarregar o CSP.

Terceiro, o serviço medido captura como os CSPs gerenciam e definem o preço de seus serviços. Os CSPs, como AWS e Microsoft Azure, cobram dos clientes pelos recursos que usam em uma base de unidade por hora – essas unidades são uma abstração dos recursos usados. Por exemplo, o Elastic Compute Cloud da AWS mede seu serviço em unidades que a AWS define em termos de poder de processamento inteiro da unidade central de processamento (CPU) padrão. ²¹

Quarto, amplo acesso à rede significa que os clientes acessam esses serviços pela rede, incluindo potencialmente a Internet pública. Este é um ponto direto, mas muito importante do ponto de vista da segurança. Os recursos de computação não são mais apenas parte da rede interna de uma empresa – em vez disso, em muitos casos, os principais sistemas operacionais dependem de conexões que podem ser abertas para toda a Internet global. Nesse sentido, tanto a capacidade quanto a segurança dessas conexões de rede são críticas. Mesmo as soluções de nuvem privada, onde os servidores em nuvem são acessados por uma conexão privada, exigiriam largura de banda significativa.

Quinto, pooling de recursos significa que um CSP combina seus recursos de forma que cada cliente compartilhe a mesma infraestrutura com outros clientes de maneira dinâmica, para ser repartido e reatribuído conforme necessário. Esse recurso é o que torna a computação em nuvem um modelo mais eficiente do que recursos de computação separados para cada empresa. Os CSPs podem aproveitar as economias de escala para construir infraestrutura e plataformas em grande escala – e compartilhar esses recursos entre vários clientes ao mesmo tempo para economizar custos e capacidade desnecessária.

TECNOLOGIAS SUBJACENTES

Enquanto os CSPs modernos dependem de sistemas altamente complexos para alocar, gerenciar e implantar recursos entre milhões de clientes, três tecnologias principais são essenciais para entender como os serviços de nuvem funcionam em escala: virtualização, hipervisores e contêinerização.

A virtualização permite abstração entre hardware físico e computadores individuais. Essencialmente, a virtualização permite que vários computadores, chamados de máquinas virtuais, existam no mesmo servidor físico. Além de tarefas computacionais e armazenamento, redes inteiras podem ser construídas por meio da virtualização.

Os hipervisores são programas que gerenciam máquinas virtuais, servidores, a conexão entre essas máquinas virtuais e servidores e a alocação de recursos para as máquinas virtuais. Assim, é possível ter um banco completo de servidores físicos, cada um executando um hipervisor, e então criar máquinas virtuais neste banco de servidores. Os CSPs se referem às máquinas virtuais que criam para seus clientes como instâncias, uma vez que duram apenas o tempo necessário e, quando não são mais necessárias, são reduzidas para liberar capacidade.

A conteinerização é um refinamento da virtualização que funciona executando contêineres discretos no mesmo sistema operacional, basicamente movendo a abstração fornecida pela virtualização em um nível. A conteinerização pegou em torno de 2014 com a introdução de uma nova ferramenta chamada Docker, que tornou muito mais conveniente e eficiente implementar a conteinerização para uso comercial. Enquanto uma máquina virtual inclui um sistema operacional totalmente virtual, um contêiner é um ambiente isolado dentro de um único sistema operacional. Em termos de camadas, enquanto um hipervisor fica entre o hardware e as máquinas virtuais, cada uma com seu próprio sistema operacional dentro delas, um contêiner fica em cima de um sistema operacional que fica em cima do mecanismo de contêiner e, em seguida, o hardware fica embaixo.

Na tabela 1, a infraestrutura para nuvem é visualizada de acordo com um modelo de camadas, semelhante ao modelo de Interconexão de Sistemas Abertos para a própria internet. ²² A tabela apresenta uma hierarquia de camadas desde os data centers físicos na parte inferior até a camada de aplicativo totalmente virtual na parte superior, permitindo que as várias partes da nuvem sejam simplificadas. As descrições de cada camada apresentam as principais tecnologias que operam nesse nível, junto com vários exemplos.

MODELOS DE IMPLANTAÇÃO DE NUVEM

Os CSPs também oferecem seus serviços em três modelos de implantação principais: a nuvem pública, uma nuvem privada ou uma nuvem híbrida.

Na nuvem pública , os clientes compartilham a mesma infraestrutura disponível para ser alugada ao público. Um CSP gerencia a infraestrutura e permite que clientes em potencial adquiram recursos. O cliente usa a mesma infraestrutura alocada por CSP que outros clientes.

Um arranjo de nuvem privada é projetado para um único cliente, essencialmente abrigando recursos no local ou fora dele, mas ainda isolado de outros clientes. Uma organização pode configurar sua própria nuvem privada ou pode contratar um CSP para fazer isso.

Algumas organizações escolhem uma nuvem híbrida , na qual combinam um serviço de nuvem pública de um CSP com uma configuração de nuvem privada ou um data center mais tradicional para que possam se comunicar e compartilhar dados e aplicativos. ²³ Algumas organizações optam por esse arranjo porque têm dados confidenciais que consideram muito arriscados para armazenar em um ambiente apenas de nuvem pública, mas ainda querem aproveitar o poder de computação da nuvem pública para executar aplicativos. ²⁴

Os clientes podem escolher um modelo de implantação com base em suas necessidades específicas, incluindo se os dados e serviços que estão migrando para a nuvem são especialmente críticos ou confidenciais. Por exemplo, um cliente com dados pessoais confidenciais para gerenciar (como um provedor de saúde) pode escolher uma nuvem privada para minimizar os riscos de que seus dados possam ser expostos a outros clientes de seus CSPs. Cada vez mais, as opções de nuvem híbrida estão predominando, à medida que os clientes percebem que diferentes tipos de dados exigem diferentes níveis de segurança.

CAPÍTULO 2: AS ORIGENS E EVOLUÇÃO DA NUVEM E SEU MERCADO

O conceito de serviços em nuvem é anterior à própria Internet. A história desses serviços ilustra como a computação mudou do núcleo para a extremidade de uma rede e voltou, conforme a tecnologia evolui. Um exemplo antigo é o modelo de computador mainframe produzido pela IBM nas décadas de 1950 e 1960, que eram as máquinas mais poderosas da época. A computação foi organizada em torno do núcleo desses computadores mainframe usados por grandes líderes do governo e da indústria. O acesso a esses computadores foi organizado em um modelo de “compartilhamento de tempo”, permitindo que vários usuários compartilhem os recursos de um computador. ²⁵

A partir da década de 1980, os computadores mainframe da IBM tornaram-se obsoletos à medida que os recursos de computação melhoraram drasticamente, tornando possível que os desktops realizem a maioria dos trabalhos comuns. A computação tornou-se descentralizada e mudou do núcleo – computadores mainframe IBM – para o perímetro, os dispositivos que fornecem aos usuários pontos de entrada na rede, que cada vez mais se tornam computadores desktop individuais. Na década de 2000, a tendência voltou para outra direção, com o poder da computação se centralizando novamente em torno do núcleo dos data centers, em parte devido ao desenvolvimento da virtualização e dos hipervisores. Vários anos antes, em 1996, executivos e acadêmicos cunharam o termo “computação em nuvem” para se referir à entrega de serviços de computação na Internet comercial em rápida expansão, mas ainda nascente. ²⁶

O desenvolvimento de serviços em nuvem foi possibilitado por uma série de avanços tecnológicos em hardware de computação – chips e equipamentos de rede – bem como pelo crescimento da Internet na década de 1990 (ver tabela 2 abaixo). Foi o nível crescente de interconexões possibilitado pela ligação de multidões de indivíduos e organizações que permitiu que a computação em nuvem se tornasse economicamente atrativa. A largura de banda também foi um fator crítico para permitir a entrega de aplicativos baseados em nuvem pela Internet. Posteriormente, inovações em software, como a conteinerização, aumentariam ainda mais as possibilidades de armazenamento e computação em nuvem.

A origem da nuvem como é conhecida hoje foi, se não acidental, um subproduto de uma estratégia de negócios muito focada em bens tangíveis em vez de virtuais: em 2003, a Amazon precisava de uma solução para escalar e gerenciar os recursos de computação de back-end necessários para seu mercado online de produtos em rápida expansão. A Amazon desenvolveu uma estratégia que foi “completamente padronizada, totalmente automatizada e amplamente dependente de serviços da web para coisas como armazenamento” para resolver esse problema. ^{27 A} Amazon então percebeu que isso não só resolveria seu próprio problema operacional, mas poderia ser um negócio viável: vender armazenamento virtual como serviço. ²⁸Outras empresas precisavam que sua infraestrutura de computação aumentasse ao longo do tempo à medida que sua base de clientes aumentava, mas o custo de aquisição e configuração de servidores era uma grande barreira.

Em 2006, a Amazon lançou dois serviços, Elastic Compute Cloud e Simple Storage Service, que fornecia recursos de computação e armazenamento na primeira grande oferta comercial de nuvem. Esses foram os dois primeiros componentes principais da AWS. Durante um discurso em 2006, logo após esses anúncios, o CEO da Amazon, Jeff Bezos, chamou os serviços de “as entranhas da Amazon”, chamando a atenção para seu papel no suporte à loja virtual da empresa. ²⁹ Dois anos depois, em 2008, o Google lançou seu App Engine, que se tornaria uma parte central de suas ofertas de serviços em nuvem. ³⁰ Em vez de fornecer uma oferta de IaaS como AWS, o Google App Engine era uma oferta de PaaS, essencialmente fornecendo aos desenvolvedores um ambiente integrado para desenvolver novos produtos e implantá-los.

TABELA 2. PRINCIPAIS DESENVOLVIMENTOS EM SERVIÇOS EM NUVEM
1959	O cientista da computação John McCarthy propõe um sistema de compartilhamento de tempo para um computador IBM a ser adquirido por cientistas do Massachusetts Institute of Technology, inspirando uma série de sistemas de compartilhamento de tempo na década de 1960. ³¹
1969	A Agência de Projetos de Pesquisa Avançada do Departamento de Defesa dos Estados Unidos conecta os dois primeiros computadores de sua rede, conhecidos como ARPANET, que viria a se tornar o predecessor da Internet. ³²
1996	O termo computação em nuvem é usado pela primeira vez pelos engenheiros da Compaq.
2003	Um documento interno da Amazon descreve um conceito de infraestrutura de computação padronizada e automatizada que depende de armazenamento na web.
2006	A AWS oferece os primeiros serviços de nuvem comercial em larga escala: Simple Storage Service e Elastic Compute Cloud.
2008	O App Engine do Google é o primeiro grande concorrente da Amazon no mercado de serviços em nuvem; inicialmente, o Google se concentra em um modelo PaaS.
2009	A gigante chinesa de comércio eletrônico Alibaba lança seu serviço de nuvem, Aliyun, mais tarde rebatizado como Alibaba Cloud.
2010	A Microsoft lança seu serviço de nuvem Azure.
2011	O NIST, parte do Departamento de Comércio dos Estados Unidos, publica a primeira definição governamental de computação em nuvem. Em seguida, a administração do presidente Barack Obama delineia uma estratégia de “nuvem primeiro” para o governo federal. ^{33 A} Microsoft lança seu serviço Office 365, uma oferta SaaS.
2014	Uma nova ferramenta chamada Docker permite a ampla adoção da conteinerização em muitas soluções em nuvem, aumentando a eficiência. A AWS e a Azure trazem seus serviços para a China em parceria com empresas locais.
2015	Uma guerra de redução de preços entre os principais CSPs obriga muitas outras empresas que tentaram construir ofertas de nuvem, como HP e Oracle, a deixar o mercado. De acordo com a pesquisa de mercado, o tamanho do mercado global de nuvem é de US $ 100 bilhões em receita. ³⁴
2018	AWS, Azure e Google Cloud continuam a expansão rápida de sua presença global, construindo regiões na Europa e Ásia e avançando para mercados emergentes no Oriente Médio e na África.

Conforme outras empresas começaram suas próprias ofertas de nuvem, a AWS estava se expandindo, conforme ilustrado pelo anúncio da Netflix em 2008 de que moveria todos os seus dados para a AWS. No final de 2008, o Elastic Compute Cloud e o Simple Storage Service estavam disponíveis na Europa e, em 2009, a AWS anunciou uma segunda região dos EUA na Costa Oeste. ^{35 A} IBM entrou no mercado de nuvem em 2009 com um serviço de nuvem privada para armazenamento corporativo e estreou seu primeiro serviço de nuvem pública em 2011. ^{36 A} Microsoft anunciou seu serviço de nuvem, Azure, em 2008 e lançou o serviço no início de 2010. ³⁷

Cada plataforma de nuvem cresceu a partir dos modelos de negócios e pontos fortes de várias empresas. Por exemplo, o Microsoft Azure se baseou em outro pacote de software Windows da empresa para oferecer uma solução PaaS inicialmente. ^{38 A} IBM aproveitou seus pontos fortes no fornecimento de empresas, inicialmente fornecendo um produto de nuvem privada. Enquanto isso, o App Engine do Google foi projetado para apelar aos desenvolvedores de aplicativos para construir aplicativos para operar em cima de outros produtos do Google.

O período de 2009 a 2011 foi de grande interesse público e governamental nos serviços em nuvem. Em 2009, o NIST publicou um rascunho de definição inicial de computação em nuvem, que passou por várias rodadas de comentários públicos antes de ser finalizado em 2011. ³⁹ No mesmo ano, o diretor de informações do governo dos EUA publicou uma estratégia de nuvem para o governo federal, descrevendo uma abordagem “primeiro na nuvem” que previa mover 25% de todo o orçamento federal de TI para soluções em nuvem. ⁴⁰

EXPANSÃO GLOBAL

As primeiras expansões globais realizadas pelos principais CSPs dos EUA (AWS, Microsoft Azure e Google Cloud) no início de 2010 foram todas focadas de forma semelhante em alguns locais importantes: Irlanda, Cingapura e Tóquio – cada um dos quais fornecia baixa latência para grandes, mercados desenvolvidos. Desde meados de 2015, os CSPs se engajaram em campanhas agressivas para expandir sua presença global, com AWS e Azure frequentemente entrando na mesma região ao mesmo tempo, tentando acompanhar um ao outro. Por exemplo, ambos lançaram novas regiões em Londres em 2016 e Paris em 2017. ⁴¹ Mas, em alguns casos, um CSP teve uma vantagem de pioneiro: a AWS abriu uma região em São Paulo, Brasil, em 2011, enquanto o Azure não seguiu até 2014. ⁴²

Cada CSP tem um modelo ligeiramente diferente para distribuir sua capacidade de computação e recursos – que normalmente dividem em regiões e zonas. Uma região, no jargão da computação em nuvem, é uma série de data centers em uma área geográfica independente, logicamente separada de outras regiões gerenciadas pelo mesmo CSP, consistindo em uma ou mais zonas. Uma zona é um conjunto isolado de um ou mais datacenters. ⁴³Normalmente, em cada região, uma rede de baixa latência conecta os data centers. A AWS tem um número menor de regiões, mas cada região tem pelo menos três zonas de disponibilidade (AZs). O Microsoft Azure tem um número maior de regiões do que AWS, mas menos AZs. Os modelos do Google Cloud e do Alibaba Cloud são mais próximos do AWS – cada uma de suas regiões também tem uma série de AZs. Uma questão em aberto é se alguns CSPs são globalmente mais resilientes do que outros, dependendo da localização e distribuição de suas zonas e centros de dados.

Ao expandir, AWS, Microsoft Azure e Google Cloud construíram suas respectivas presenças em quase todas as grandes economias, uma tendência que ocorreu muito rapidamente. A Figura 1 mostra a expansão dos principais CSPs em todo o mundo, e a figura 2 mostra a competição entre os CSPs dos Estados Unidos e da China pelos mercados da Ásia.

Na Ásia, o Alibaba Cloud se desenvolveu a partir de sua presença principal na China. Foi também o primeiro CSP no Oriente Médio, abrindo uma região em Dubai em 2016. Mas o Alibaba Cloud também fez incursões no Ocidente – ele abriu duas regiões nos Estados Unidos em 2015 e tem duas regiões na Europa também. ^{44 A} IBM expandiu sua rede global antes de alguns dos outros participantes, com um investimento de US $ 1,2 bilhão em 2014 para construir data centers em todo o mundo. ⁴⁵ Embora a IBM tenha aberto data centers em muitos dos mesmos locais que seus concorrentes, muitos deles são data centers únicos. Em contraste, uma região AWS, por exemplo, é composta de vários AZs, com vários data centers em cada AZ. A IBM pode ter uma presença global, mas não tem a capacidade mundial de alguns de seus pares maiores.

TENDÊNCIAS DE MERCADO (2011–2018)

A comparação das estimativas de receita para serviços em nuvem ao longo do tempo ilumina o crescimento surpreendente do mercado para esses serviços nos últimos oito anos. Com isso dito, comparar diferentes CSPs é mais difícil por causa de vários fatores, incluindo como as empresas não relatam suas receitas pelos vários tipos de serviços em nuvem (IaaS, PaaS e SaaS) e quantos desses serviços estão na mesma linha que eles três modelos diferentes.

Relatórios sobre a participação de mercado de um determinado CSP requer uma metodologia específica que toma decisões sobre o que conta como um serviço de nuvem e o que é considerado um serviço de virtualização, portanto, as inúmeras empresas privadas que fornecem análises de participação de mercado na nuvem muitas vezes diferem amplamente sobre suas estimativas. Esses relatórios, portanto, fornecem alguns insights, mas não são definitivos. Além disso, existem muitas empresas mais especializadas em nuvem que visam fornecer serviços baseados em nuvem para setores específicos. Dado o foco geral desta cartilha nos CSPs públicos gerais, esta seção enfoca a dinâmica entre os CSPs principais, não as empresas mais especializadas.

Em 2011, o mercado de nuvem tinha acabado de decolar e vários jogadores importantes (Amazon, Google e Microsoft) haviam entrado nele recentemente. De acordo com uma estimativa, o mercado global de nuvem pública cresceu quase seis vezes em tamanho, de US $ 25,5 bilhões em receita em 2011 para US $ 145,3 bilhões em 2017. ⁴⁶ Esses grandes totais devem ser considerados como um grão de sal. Eles são estimativas de todo o mercado de nuvem pública e incluem outros serviços, como processos de negócios e publicidade, com base em serviços e plataformas de nuvem subjacentes, incluindo IaaS ou PaaS. ⁴⁷

Em 2011, a competição de mercado entre os CSPs começou a se intensificar (veja as figuras 3 e 4). Como a primeira grande oferta de IaaS, a AWS dominou, mas havia outros jogadores importantes, incluindo a empresa de hospedagem Rackspace – que também construiu uma plataforma de computação em nuvem de código aberto chamada OpenStack em colaboração com a National Aeronautics and Space Administration (NASA) em 2010. ⁴⁸ Em 2012, um relatório de pesquisa de mercado colocou a participação da AWS no mercado global de IaaS em cerca de 35 por cento. ⁴⁹ Naquela época, outros concorrentes, como IBM e Telecom, tinham ações inferiores a 10 por cento. ⁵⁰ No mercado global de PaaS, em 2012, o mesmo relatório colocava a Salesforce na liderança, com uma participação de cerca de 20%, seguida de perto pela AWS e Microsoft Azure. ⁵¹

Em 2013, o mercado geral de nuvem estava crescendo rapidamente – as receitas mundiais da AWS no terceiro trimestre daquele ano foram 55 por cento mais do que no anterior, e outros concorrentes também estavam crescendo: o mercado geral de IaaS / PaaS cresceu 46 por cento em comparação com 2012. ⁵² Esse crescimento massivo apontou para uma transformação da TI de negócios – um relatório de 2015 descobriu que 88% das empresas americanas estavam usando computação em nuvem pública em alguma capacidade e 63% também estavam usando soluções de nuvem privada. ⁵³ Por mais impressionantes que sejam esses números, é difícil estimar o que isso significa – há uma grande diferença entre usar um serviço de nuvem para e-mail ou armazenamento de dados e migrar as funções de negócios principais.

Um desenvolvimento importante em 2014 foi a melhoria na conteinerização, discutida no capítulo 1. Antes deste ponto, quase todos os serviços de computação em nuvem faziam uso exclusivo de máquinas virtuais que emulam um computador inteiro – de aplicativos a hardware – na forma virtual. Em 2014, a nova ferramenta de containerization Docker permitiu um tipo diferente de emulação com contêineres, que fornecem ambientes de computação isolados, mas são executados em um sistema operacional compartilhado. O mecanismo Docker assenta em um sistema operacional compartilhado e, em seguida, gera ambientes isolados – contêineres – que fornecem a mesma separação de uma máquina virtual.

A eficiência vem do sistema operacional compartilhado, o que significa que, ao contrário das máquinas virtuais, os contêineres não precisam ocupar espaço e capacidade de computação para replicar um sistema operacional que será descartado quando a máquina virtual não for mais necessária. Isso permite uma computação muito mais eficiente. ⁵⁴ Muitos CSPs integraram rapidamente o Docker em seus produtos.

GUERRAS DE PREÇOS

Como a competição no mercado de infraestrutura e serviços de plataforma estava esquentando, os principais CSPs baixaram drasticamente seus preços. O ano de 2014, em particular, marcou um ponto de inflexão a partir do qual o aumento da concorrência coincidiu com quedas de preços mais agressivas. Por exemplo, as taxas de armazenamento de banco de dados da AWS diminuíram a uma taxa anual de 3,3 por cento entre 2010 e 2013, antes de cair 22,6 por cento entre 2014 e 2016. ⁵⁵ Este corte de preços continuou desde 2014, com os principais fornecedores mudando de taxas de corte para máquinas virtuais para cortar preços para armazenamento de objetos. ⁵⁶

A redução de preços levou à consolidação no mercado, à medida que outras empresas que esperavam construir braços de nuvem fora de seus negócios existentes começaram a falhar. Em agosto de 2014, a Rackspace disse que descontinuaria sua oferta de IaaS, mudando para um modelo de “nuvem gerenciada”. ⁵⁷ Em outubro de 2015, a HP anunciou que encerraria seu serviço de nuvem pública, um anúncio prenunciado pela explicação de um executivo de que “não faz sentido para nós irmos cara a cara” contra AWS, Microsoft Azure e Google Cloud. ⁵⁸ Nos dois anos seguintes, Verizon, AT&T e Cisco também se retiraram dos serviços em nuvem. ⁵⁹Um relatório do Gartner de 2017 descobriu que a AWS e o Microsoft Azure estavam hospedando 70% das cargas de trabalho IaaS e previu que, em 2019, seu duopólio forçaria 90% de outros provedores de IaaS a sair do mercado global. ⁶⁰

UM MERCADO GLOBAL E NUVENS EM HIPERESCALA

Em 2018, as estimativas colocam o tamanho do mercado geral de nuvem em US $ 160 bilhões. ⁶¹ Os grandes jogadores eram Google Cloud, Microsoft Azure e, o maior de todos, AWS – cada um desses titãs conhecido no jargão do setor como CSPs em hiperescala (consulte as tabelas 3 e 4). De acordo com uma definição amplamente citada da Cisco, para ser hiperescala, um CSP deve obter mais de US $ 1 bilhão em receitas anuais de IaaS, PaaS ou hospedagem de infraestrutura ou receber US $ 2 bilhões anualmente de SaaS. ⁶² Com base nas definições da Cisco, que se aplicam a data centers em hiperescala para empresas provedoras de serviços que não sejam da nuvem, há vinte e quatro empresas com operações de data center em hiperescala. ⁶³

TABELA 3. PARTICIPAÇÃO NO MERCADO MUNDIAL EM SERVIÇOS DE NUVEM PÚBLICA IAAS (2017–2018)
Companhia	Receita de 2018 (em bilhões de $)	Participação de mercado de 2018 (%)	Crescimento da receita de 2017–2018 (%)
Amazonas	$ 15,5 bilhões	47.8	26.8
Microsoft	$ 5,0 bilhões	15.5	60.9
Alibaba	$ 2,5 bilhões	7.7	92.6
Google	$ 1,3 bilhão	4.0	60.2
IBM	$ 0,6 bilhão	1.8	24.7
Outras	$ 7,5 bilhões	23.2	11.1
Total	$ 32,4 bilhões	100.0	31.3
Fonte: “Gartner Says Worldwide IaaS Public Cloud Services Market Grew 31.3% in 2018,” Gartner, comunicado à imprensa, 29 de julho de 2019, https://www.gartner.com/en/newsroom/press-releases/2019-07- 29-gartner-says-worldwide-iaas-public-cloud-services-market-growth-31-point3-percent-in-2018 .

Essas operadoras passaram a dominar os mercados globais em nuvem usando economias de escala para reduzir custos e ganhar participação de mercado às custas de provedores menores. ⁶⁴ Nos últimos três anos, o Microsoft Azure aumentou sua participação no mercado de IaaS e PaaS, embora a AWS tenha mantido sua posição dominante. Outros CSPs em hiperescala, em particular Google Cloud e Alibaba Cloud, também aumentaram seu crescimento muito mais rápido do que o crescimento geral do mercado de nuvem. ⁶⁵

TABELA 4. EMPRESAS DE HIPERESCALA EM SERVIÇOS EM NUVEM
	Hiperescala	Não hiperescala
CSPs principais	AWS, Google Cloud, Microsoft Azure, Alibaba Cloud, Rackspace, Salesforce, Oracle	IBM, NTT, OVH, SAP, Dropbox
Outras companhias	Yahoo, Apple, eBay, Baidu, Tencent, Facebook	Todas as outras empresas

A computação em nuvem em hiperescala tem várias implicações importantes não apenas para a computação em nuvem, mas também para o design e funcionamento da própria Internet. O primeiro é a escala absoluta da computação em nuvem em hiperescala. Apenas um punhado de empresas é agora responsável por gerenciar infraestrutura na escala de dezenas de centros de dados massivos, milhões de nós de computação, milhões de quilômetros de fibra de rede conectando centros de dados e um backbone que poderia ser considerado quase paralelo à Internet, mas que não está publicamente conectado (consulte a tabela 4 acima). ⁶⁶Em segundo lugar, a computação em nuvem em hiperescala muda a maneira como os dados trafegam entre usuários e servidores. Anteriormente, os usuários se comunicavam diretamente com os servidores para recuperar seus dados em comunicações simples ponto a ponto. Em hiperescala, com o acúmulo de recursos dentro da nuvem, uma solicitação do usuário solicitará comunicações internas e rede dentro do data center, pois a nuvem fornece não apenas dados brutos, mas serviços. Essa tendência implica que a computação complexa e as redes inteligentes se tornarão cada vez mais importantes para a entrega de serviços de internet – ao contrário de uma internet que é principalmente (ou meramente) uma rede dos chamados nós burros projetados para comunicação.

CHINA E A NUVEM

Cada vez mais, os concorrentes da China estão contestando os CSPs dos Estados Unidos pela participação no mercado. O maior desses concorrentes é a Alibaba, a empresa chinesa de comércio eletrônico. O Alibaba lançou um serviço em nuvem, Aliyun, em 2009 e o expandiu em 2015 com um investimento de bilhões de dólares que também o rebatizou como Alibaba Cloud. ⁶⁷ Um fator importante no crescimento dos CSPs chineses tem sido sua capacidade de dominar o mercado chinês devido às restrições aos CSPs estrangeiros. Por exemplo, um relatório da McKinsey de julho de 2018 descobriu que 64% dos gastos com nuvem pública na China foram para CSPs chineses e apenas 22% foram para fornecedores multinacionais, embora, no geral, as empresas chinesas tenham investido menos em serviços em nuvem como parte de seus orçamentos de TI em comparação com as empresas americanas. ⁶⁸Um relatório descobriu que o Alibaba Cloud tinha uma participação de mercado de 45,5 por cento na China em IaaS, seguido por Tencent Cloud com 10,3 por cento e China Telecom com 7,6 por cento – com Azure e AWS tendo apenas cerca de 5 por cento cada. ⁶⁹

Pequim impôs regulamentos rígidos aos CSPs estrangeiros que tornam difícil operar na China. Por exemplo, empresas estrangeiras não podem estabelecer centros de dados diretamente na China continental e devem, em vez disso, contratar empresas chinesas locais e fornecer serviços por meio delas. A Azure foi a primeira a desenvolver essa parceria, com uma empresa chamada 21Vianet, e colocou seus serviços online na China em 2014. A AWS veio logo em seguida, em parceria com a Beijing Sinnet. ⁷⁰ Em 2017, novos requisitos de licença do regulador de internet da China e uma nova lei de segurança cibernética tornaram ainda mais desafiador para CSPs estrangeiros na China, especialmente por causa dos requisitos de localização de dados da lei. ⁷¹Esses regulamentos forçaram a AWS a vender uma quantidade significativa de sua infraestrutura na China para seu parceiro local. ⁷²

A CRESCENTE NUVEM GLOBAL

No geral, o mercado de serviços em nuvem cresceu enormemente desde seu estágio inicial em 2011 em termos de receita, maturidade de negócios e pegada global. A AWS continuou a ser a líder global ao longo deste período, mantendo uma participação de mercado estável. A competição se consolidou para incluir apenas alguns outros grandes jogadores, como Azure, Google Cloud e IBM. Uma área onde esses CSPs não conseguiram crescer é a China – em vez disso, o aumento de CSPs chineses domésticos, mais notavelmente o Alibaba Cloud com sua participação de mercado quase majoritária, permitiu uma nova fonte de competição regional, especialmente para os mercados asiáticos e emergentes. As projeções indicam que o mercado global de nuvem, especialmente para IaaS e PaaS, continuará apresentando forte crescimento (veja a figura 4 acima), e o Gartner previu que todo o mercado de nuvem valerá $ 280 bilhões em 2021.⁷³ Como os serviços em nuvem representam uma proporção cada vez maior das margens de lucro de mega-multinacionais como Amazon e Microsoft, a competição por receitas crescentes só vai se intensificar.

A tendência geral de consolidação do mercado, especialmente para CSPs de público geral, como AWS e Microsoft Azure, é um desenvolvimento importante que os formuladores de políticas devem observar. É impressionante até que ponto as funções empresariais de grande parte da economia global moderna dependem das operações de um punhado de empresas. Como a eletricidade no início do século XX, a infraestrutura da nuvem está se tornando um importante pilar da vida moderna. À medida que os formuladores de políticas passam a avaliar o mercado de nuvem, como em qualquer consolidação do setor, esses desenvolvimentos podem provocar preocupações antitruste, conforme discutido brevemente no capítulo 4. No entanto, essa consolidação também tem implicações de segurança importantes, discutidas mais adiante no capítulo 3.

CAPÍTULO 3: SEGURANÇA NA NUVEM

Para discutir a segurança com relação à nuvem, é importante primeiro destacar o panorama mais amplo de segurança cibernética e os benefícios que a migração para o público ou um modelo de nuvem híbrida oferece. Para a maioria das organizações, a migração para a nuvem pode melhorar significativamente sua segurança.

O ESTADO DE (CONTINUAÇÃO) DA INSEGURANÇA CIBERNÉTICA

Apesar de anos de investimento e foco nos riscos cibernéticos, os custos dos incidentes cibernéticos estão aumentando. Os ataques cibernéticos agora estão entre os riscos globais com maior probabilidade e maior impacto, de acordo com o Relatório de Riscos Globais 2019 do Fórum Econômico Mundial (WEF). ⁷⁴ Uma pesquisa do WEF com especialistas em governo, empresas e sociedade civil descobriu que mais de 80% dos entrevistados esperavam que os riscos de ataques cibernéticos e roubos continuassem a aumentar em 2019. ⁷⁵ As violações de dados estão crescendo em tamanho e gravidade. Somente entre janeiro de 2017 e março de 2018, cerca de 1,9 bilhão de registros de dados pessoais ou outros dados confidenciais foram comprometidos em violações de dados. ⁷⁶Uma pesquisa da seguradora Lloyd’s de Londres descobriu que 92% das empresas europeias pesquisadas sofreram violação de dados, uma estatística que indica a onipresença das ameaças cibernéticas. ⁷⁷

Os custos médios de incidentes cibernéticos também estão crescendo. O relatório de 2019 da Accenture sobre o custo do crime cibernético descobriu que, para as organizações pesquisadas, o custo médio do crime cibernético em 2018 foi de US $ 13 milhões, um aumento de 12% em relação ao ano anterior e de 67% nos cinco anos anteriores. ⁷⁸ O mesmo relatório estimou que o valor em risco dos custos diretos e indiretos do crime cibernético de 2019 a 2023 poderia chegar a US $ 5,2 trilhões. ⁷⁹

Em resposta, as organizações estão aumentando seus gastos com segurança cibernética, mas ainda ficam aquém. Um relatório da Ernst and Young (agora conhecido como EY) descobriu que apenas 8% dos profissionais de negócios pesquisados disseram que a função de segurança da informação atendia totalmente às necessidades da organização, apesar do aumento dos orçamentos para segurança cibernética. ⁸⁰ Em particular, as empresas menores têm menos recursos para alocar para lidar com todas as vulnerabilidades que enfrentam. Os desafios de recursos que afetam organizações menores também têm consequências mais amplas, já que os invasores freqüentemente tentam comprometer o elo mais fraco e pular para outras organizações.

Como Alex Stamos, ex-diretor de segurança da informação do Yahoo e do Facebook, afirmou: “Para a maioria das organizações, você fica dez vezes mais seguro com seus dados armazenados e protegidos por um grande provedor de serviços em nuvem do que se tentasse protegê-los sozinho . ” ⁸¹ O CISO de uma grande instituição financeira repetiu essas observações em uma mesa redonda privada. ⁸² Essa regra se aplica à grande maioria das organizações que não têm o tamanho e os recursos de um CSP importante, como AWS ou Google Cloud, para reunir – e pagar os salários – dos maiores especialistas em segurança do mundo.

No entanto, os serviços em nuvem têm seus próprios problemas de segurança associados. Eles também não eliminam todos os riscos de segurança cibernética existentes para aqueles que operam com sistemas locais. Esta seção examina incidentes de segurança conhecidos e ameaças à disponibilidade, confidencialidade e integridade de dados na nuvem. Com base em uma série de estudos de caso de incidentes de segurança importantes, ele desenvolve indutivamente uma estrutura de risco para categorizar ameaças à segurança da nuvem e à segurança daqueles que operam na nuvem. Finalmente, ele discute como conectar esses riscos aos impactos potenciais.

A SEGURANÇA DA NUVEM

Conforme mencionado anteriormente, é um equívoco falar da nuvem como uma entidade única e coesa. Portanto, a segurança da nuvem é muito parecida com a segurança da internet em grande escala – uma ampla faixa de várias ameaças, vulnerabilidades e riscos potenciais que afetam milhares, senão milhões, de diferentes tipos de serviços fornecidos a atores que variam de indivíduos a indivíduos inteiros governos. Nunca haverá um incidente em que a nuvem desça, por assim dizer, como se pudesse ser desligada como uma lâmpada. Em vez disso, os problemas de segurança na nuvem cobrem um espectro que varia de falha completa e indisponibilidade a desempenho limitado ou efeitos limitados a subconjuntos de dados e serviços.

Os riscos de segurança em nuvem são diferentes de outros tipos de riscos de segurança cibernética porque a segurança em nuvem é conectada em rede, concentrada e compartilhada. Em primeiro lugar, a computação baseada em nuvem é inerentemente conectada em rede. Seja contando com uma conexão de internet para a nuvem pública ou rede especializada para uma nuvem privada, qualquer coisa na nuvem, até certo ponto, depende de rede. Isso significa que qualquer infraestrutura de nuvem envolverá segurança de rede e enfrentamento de ameaças potenciais que poderiam tirar proveito disso.

Em segundo lugar, a infraestrutura da nuvem está concentrada. Como a discussão da evolução do mercado de nuvem mostrou, há um conjunto notavelmente pequeno de CSPs principais e, embora haja um ecossistema diversificado especialmente para PaaS e SaaS, muitos desses serviços dependem dos Três Grandes CSPs – AWS, Azure, e Google Cloud. Um efeito positivo desse mercado concentrado é que cada CSP agora desenvolveu protocolos de segurança com recursos incríveis e alta concentração de pessoal qualificado. Dada a raridade de pessoal qualificado, esse efeito de concentração é bastante substancial na melhoria da segurança da nuvem. No entanto, uma desvantagem da concentração é que os incidentes que interrompem esses serviços CSP têm um efeito muito mais amplo do que interrupções potenciais mais restritas que afetam um de seus clientes. Se uma interrupção afetou um serviço importante da AWS, como aconteceu em 2017,

Terceiro, a responsabilidade pelo risco na nuvem é inerentemente compartilhada entre clientes e CSPs. A quantidade de responsabilidade e seu delineamento dependem de qual modelo de serviços em nuvem está sendo usado, como será discutido posteriormente nesta seção. Mas, em geral, não há como escapar que a segurança depende do esforço de duas ou mais partes.

Nenhuma dessas condições é nova na segurança cibernética. No entanto, é importante lembrar, ao avaliar os problemas de segurança da nuvem, que todos os três se aplicam a todos os arranjos de nuvem. Essas condições podem exacerbar os problemas de segurança existentes, como costuma acontecer quando as falhas dos clientes em colocar as proteções de segurança em vigor expõem dados na Internet pública. Ou eles podem se combinar para criar novos riscos potenciais, como o risco de um provedor de nuvem ser comprometido e, assim, expor os dados de seus clientes a roubo.

Dada a natureza de rápida evolução dos serviços em nuvem, é difícil mapear todos os problemas de segurança que podem afetar a nuvem no futuro ou qual pode ser o impacto dessas ameaças. Existem muitas questões não resolvidas sobre os impactos potenciais das ameaças à segurança da nuvem que são relevantes para as políticas públicas. Por exemplo, até que ponto a migração para a nuvem reduz as ameaças atuais à segurança cibernética? As ameaças à confidencialidade, disponibilidade e integridade dos dados são mitigadas ou exacerbadas na nuvem? As ameaças de segurança específicas da nuvem aumentam a magnitude potencial dos incidentes de segurança cibernética?

Uma abordagem indutiva baseada em incidentes de segurança anteriores pode começar a fornecer alguma forma de resposta a essas perguntas. A série de incidentes nos últimos cinco anos listados na tabela 5 e os estudos de caso detalhados no Apêndice A revelam que os CSPs experimentaram interrupções que afetam a confidencialidade, disponibilidade e integridade dos dados, bem como processos e sua confiabilidade. Embora, como grande parte deste documento, esses incidentes giram em torno dos principais CSPs, há, é claro, muitos outros problemas de segurança envolvendo variedades mais especializadas de serviços em nuvem.

Até agora, os incidentes envolvendo CSPs ainda não causaram interrupções generalizadas de longo prazo e, na medida em que afetaram um número significativo de pessoas, é por meio dos efeitos indiretos do tempo de inatividade do site resultante de interrupções na nuvem. A lista de incidentes na tabela 5 mostra que alguns problemas, como os ambientais que afetam os data centers, ocorrem repetidamente, enquanto outros riscos, como as ameaças potenciais associadas às vulnerabilidades Meltdown e Spectre, surgiram inesperadamente e ainda não levaram a qualquer forma de desastre.

Nesse sentido, a segurança da nuvem até agora é uma série de catástrofes potenciais evitadas por pouco, talvez um indicador positivo dos esforços de mitigação dos CSPs e da resiliência geral das arquiteturas de serviço da nuvem. Por outro lado, sem um incidente em que um CSP realmente falhou, digamos um que seja comparável aos ataques cibernéticos WannaCry ou NotPetya, o nível de risco associado a ameaças ambientais, operacionais e adversárias ainda não é quantificável.

TABELA 5. PRINCIPAIS INCIDENTES DE SEGURANÇA NA NUVEM (2014–2019)
Set 2014	Respondendo a uma vulnerabilidade no hipervisor Xen, a AWS e a Rackspace iniciaram reinicializações de suas instâncias de computação em todo o mundo para implementar patches de segurança. ⁸³
Novembro de 2014	Uma atualização do sistema implementada globalmente para os serviços de armazenamento do Microsoft Azure causou falhas em suas máquinas virtuais. Alguns clientes sofreram interrupções por até onze horas. ⁸⁴
Agosto de 2015	Os ataques de iluminação que atingiram a rede elétrica na Bélgica causaram uma falha nos serviços do Google Compute Engine para a região local. Alguns clientes perderam dados porque os sistemas de armazenamento passaram por repetidos drenos de energia. ⁸⁵
Set 2015	Uma falha no serviço de metadados internos da AWS causou um conjunto em cascata de interrupções que geraram interrupções para muitos clientes que dependiam dos serviços da AWS na região US-EAST-1, incluindo Airbnb, IMDb e Netflix. ⁸⁶
Janeiro de 2016	Uma atualização defeituosa impediu que os usuários do Microsoft Office 365 acessassem algumas mensagens de e-mail, um atraso de até cinco dias para alguns usuários. ⁸⁷
Maio de 2016	Um data center da Salesforce US caiu por cerca de um dia, devido a uma falha de disjuntor em outro data center que causou uma inundação de tráfego, levando a interrupções para muitos clientes. ⁸⁸
Fevereiro de 2017	Uma interrupção da AWS na região US-EAST-1 causou falhas em muitas plataformas e organizações online, incluindo Airbnb, Signal, Slack e a US Securities and Exchange Commission em um período de cinco horas. Posteriormente, uma empresa estimou que o tempo de inatividade causou uma perda de US $ 150 milhões para as empresas S&P 500 afetadas. ⁸⁹
Mar. 2017	Uma falha de energia que levou a erros de software causou problemas com o serviço de armazenamento do Azure, especialmente para clientes na região Leste dos EUA. O Azure restaurou o serviço completo em oito horas. ⁹⁰
Junho de 2017	Pesquisadores de segurança alertaram o fabricante de chips Intel e outros sobre as vulnerabilidades de exploração especulativa Specter / Meltdown. Eles foram mantidos em segredo por seis meses com os fabricantes de chips trabalhando com grandes empresas de tecnologia para implementar uma solução. ⁹¹
Janeiro de 2018	As vulnerabilidades Specter e Meltdown tornaram-se públicas, com CSPs trabalhando para implementar correções de software e hardware. ⁹²
Junho de 2018	Os clientes do Azure no norte da Europa tiveram uma interrupção de cinco horas devido às altas temperaturas do verão em um data center, levando a desligamentos automatizados da infraestrutura. ⁹³
Setembro de 2018	Os relâmpagos causaram falha em um data center do Azure no Texas, afetando clientes que usam armazenamento na região local, bem como alguns serviços do Azure globalmente. A região local ficou offline por cerca de quatro horas. ⁹⁴
Novembro de 2018	A configuração incorreta de um protocolo de roteamento de Internet por um provedor de serviços de Internet nigeriano causou falhas no tráfego para o Google Cloud depois que o tráfego foi enviado por engano pela China. ⁹⁵
Janeiro de 2019	Problemas com um provedor de serviços de nome de domínio externo causaram erros em sistemas internos do Microsoft Azure que levaram à queda acidental de bancos de dados de clientes, que foram recuperados posteriormente. ⁹⁶

ESTUDOS DE CASO DE GRANDES INCIDENTES

Os oito estudos de caso detalhados no Apêndice A fornecem avaliações detalhadas de vários fatores de risco que afetam a segurança na e da nuvem, conforme ilustrado por alguns dos mais significativos incidentes publicamente conhecidos. Eles iluminam não apenas ameaças específicas à segurança da nuvem, mas também como a segurança da nuvem afeta os clientes e o público em geral, bem como o desempenho dos CSPs para limitar seus efeitos.

Uma descoberta principal é que muitos incidentes de nuvem não são causados por adversários maliciosos, mas sim por erro humano e também por fenômenos naturais. No primeiro caso, uma entrada de comando equivocada – um erro de digitação – por um engenheiro da AWS desencadeou uma cadeia de alterações inadvertidas em um serviço principal da AWS em uma região com tráfego pesado, que resultou em uma interrupção de quase cinco horas das principais ferramentas da AWS. Essas ferramentas davam suporte a muitos sites, levando ao tempo de inatividade afetando não apenas a AWS, mas muitos de seus clientes em todo o mundo. ⁹⁷

Uma reação em cadeia semelhante afetando clientes distribuídos globalmente ocorreu no segundo caso, mas desta vez por causa de um raio que resultou em uma oscilação de energia em um data center do Microsoft Azure. Isso deixou o data center off-line e, consequentemente, causou uma falha no gerenciamento de dados legado e nos serviços de autenticação que tinham dados críticos para suas operações armazenados na região afetada. As complexidades no conjunto aninhado de serviços fornecidos pela nuvem tornaram os CSPs vulneráveis a interrupções em regiões críticas, apesar dos extensos esforços para construir redes globais e da insistência dos CSPs de que cada região é logicamente separada e independente de todas as outras.

A nuvem também é vulnerável a problemas de roteamento de internet. No terceiro caso, o Google Cloud sofreu interrupções porque um provedor de serviços de Internet externo na Nigéria listou erroneamente seu endereço, de modo que o tráfego do Google Cloud foi direcionado por esse provedor de serviços de Internet, sobrecarregando-o e causando problemas de conectividade em todo o mundo. Esse incidente ressalta que a nuvem continua vulnerável a problemas familiares de segurança na Internet, e talvez ainda mais devido à grande quantidade de dados que envia pela web pública.

Outra lição importante é que a estrutura complexa da nuvem pode causar efeitos em cascata. Por exemplo, no quarto caso, vários conjuntos de dados críticos em bancos de dados SQL do Azure foram excluídos acidentalmente devido a uma cascata complexa. Tudo começou com um erro de provedor de sistema de nome de domínio externo (DNS) afetando os sistemas de autenticação do Azure. Embora o Azure tenha sido capaz de fornecer aos clientes uma cópia dos dados recuperados cinco minutos antes da exclusão, este incidente ilustra como os incidentes de nuvem estruturais ocorrem: pequenos problemas técnicos podem expor vulnerabilidades nas operações internas de um CSP que podem ter efeitos imprevisíveis. Um processo semelhante ocorreu no quinto caso, quando um ajuste deliberado nos servidores do Facebook causou interrupções que duraram até quatorze horas em serviços essenciais como Instagram e WhatsApp. Embora menos informações públicas estejam disponíveis para este caso, parece semelhante ao primeiro caso. O Facebook não é um CSP que oferece serviços em nuvem para terceiros, mas opera de forma muito semelhante a um por causa de seu tamanho e rede global massiva.

A vulnerabilidade que é indiscutivelmente a mais significativa até agora para a segurança da nuvem é aquela que ainda não resultou em qualquer interrupção nos serviços da nuvem: a descoberta das vulnerabilidades de hardware do chip Meltdown e Spectre. Conforme detalhado no sexto caso, em 2017, os pesquisadores de segurança descobriram as principais vulnerabilidades que permitiriam aos invasores ler secretamente dados de muitos dos chips usados nos centros de dados dos CSPs. A correção dessas falhas exigiu um grande esforço não apenas para implementar patches de software, mas também para substituir o hardware afetado. Embora as respostas dos CSPs às vulnerabilidades Meltdown / Spectre tenham sido elogiadas como altamente colaborativas e proativas, essas vulnerabilidades ainda representam um cenário hipotético significativo.

Ataques adversários também afetaram a segurança da nuvem em incidentes de alto perfil, notavelmente a violação de dados Capital One. Conforme detalhado no sétimo caso, o invasor, um ex-funcionário da AWS, roubou números de previdência social e informações sobre pessoas que se inscreveram para créditos de crédito Capital One por meio de uma exploração acessando dados armazenados pela Capital One na nuvem pública da AWS. Como muitos ataques adversários, esse invasor fez uso de uma configuração incorreta de um cliente para obter acesso, enfatizando como a segurança na nuvem é gerenciada em conjunto por clientes e CSPs. Este evento parece ser um dos incidentes mais significativos desse tipo, especialmente porque a Capital One estava entre os líderes do setor financeiro em mover todos os seus serviços para a nuvem. No oitavo caso, hackers ligados ao estado conduziram uma das intrusões de maior alcance contra empresas de nuvem e seus clientes, roubando valiosas propriedades intelectuais e segredos comerciais de corporações em todo o mundo. A Operação Cloud Hopper ressalta que a segurança na nuvem reflete o problema do Fort Knox – embora possa ser muito mais seguro, hackers como os atores chineses suspeitos neste caso foram capazes de roubar as chaves de um armazenamento de dados muito maior do que se eles tinha apenas visado uma empresa diretamente.

Por último, até o momento, esses incidentes não parecem ter tido consequências físicas além de interrupções nos serviços conectados à Internet das coisas (IoT), como lâmpadas inteligentes. No entanto, é difícil prever os impactos potenciais de uma interrupção da nuvem para um serviço crítico em tempo real, como transações financeiras, ou um sistema IoT complicado, como uma rede de automóveis autônoma.

MAPEAMENTO DE VETORES DE RISCO DE FORMA MAIS SISTEMÁTICA

Esta lista de incidentes anteriores é o ponto de partida para a produção de um mapeamento mais sistemático do risco associado aos CSPs. Os incidentes anteriores de segurança na nuvem fornecem a base para o desenvolvimento de uma lista de vetores de risco, que podem ser classificados como acidentais, adversários, ambientais e estruturais. Enquanto os três primeiros são autoexplicativos, o quarto (estrutural) se refere a incidentes em que a complexidade da arquitetura da própria nuvem produz riscos. Por exemplo, como alguns dos casos mostram, um processo de erro automatizado pode levar a desligamentos inadvertidos de serviços em nuvem devido a uma complexa inter-relação entre os vários elementos internos de um CSP. Em alguns casos, os riscos estruturais se cruzam com o erro humano ou efeitos ambientais,

A estrutura descrita na figura 5 abaixo aplica a conhecida tríade de segurança cibernética de confidencialidade, integridade e disponibilidade a esses vetores de risco e inclui estimativas aproximadas das probabilidades de que vários incidentes ocorrerão, variando de incidentes mais comuns a eventos potenciais do cisne negro. Essas probabilidades não pretendem ser preditores, mas sim um ponto de partida para uma discussão de como os diferentes riscos podem ser classificados, que serão testados e melhorados com o feedback de outros especialistas ao longo do tempo. As probabilidades nocionais foram baseadas na avaliação dos autores da frequência de ocorrências passadas, com eventos que ainda não ocorreram sendo atribuídos a probabilidades mais baixas. ⁹⁸

Ao dividir os vetores de risco de acordo com seus efeitos potenciais sobre a confidencialidade, integridade e disponibilidade, essa estrutura conecta riscos a impactos específicos, ao mesmo tempo em que ressalta que riscos múltiplos podem se combinar para criar impactos simultâneos com efeitos imprevisíveis. Este método identifica ainda como cada risco impacta cada elemento da tríade. Por exemplo, uma configuração incorreta de dados do cliente pode levar ao vazamento de dados externos, enquanto uma vulnerabilidade de hardware semelhante a Meltdown / Spectre pode levar os clientes a acessarem maliciosamente os dados de outros clientes – dois resultados que são ambos efeitos em diferentes dimensões da confidencialidade. O roubo de dados maliciosos é a terceira maneira pela qual os vetores podem afetar a confidencialidade na nuvem.

Quanto à disponibilidade, os riscos podem ser divididos entre aqueles que causam perdas temporárias ou permanentes de disponibilidade, sendo os vetores ambientais responsáveis por uma fração significativa dos primeiros. Os riscos estruturais também podem levar a riscos de segunda ordem de disponibilidade, como interrupções em regiões importantes, causando falhas nos serviços globais que dependem da disponibilidade dessa região.

Por fim, ameaças à integridade dos dados no segmento de nuvem na exclusão de dados, manipulação de dados e assincronia de dados. O último desses termos se refere a uma situação potencial em que um conjunto de dados poderia existir em dois ou mais locais diferentes com valores diferentes para dados que deveriam ser idênticos. Essa assincronia pode resultar de acidentes em um incidente na nuvem que levam a alterações inadvertidas nos dados armazenados em diferentes regiões.

Essa estrutura de risco aponta para um escalonamento potencial dos vetores de ameaças com base em suas probabilidades, o que permite alguma avaliação dos tipos de impactos que podem ser mais ou menos comuns.

Na categoria mais provável estão os eventos ambientais que podem interromper temporariamente a disponibilidade de dados ou serviços em nuvem e exposições acidentais de dados do cliente ao público, devido à configuração incorreta. Os estudos de caso sugerem que, embora a indisponibilidade temporária possa resultar de falhas complexas e potencialmente afetar uma ampla faixa de clientes, os CSPs são relativamente hábeis em restaurar serviços rapidamente em resposta a incidentes ambientais ou acidentais. Para exposições de dados de clientes, esses são alguns dos incidentes de segurança em nuvem mais comumente relatados, mas podem ter um impacto baixo, porque mesmo que os dados tenham sido expostos, não costumam ser explorados por agentes mal-intencionados.

Na faixa mais média a baixa de probabilidades estão as ameaças adversas à confidencialidade dos dados dos clientes na nuvem. Isso inclui incidentes em que o próprio CSP pode ser comprometido, como na campanha Cloudhopper. As causas estruturais da indisponibilidade também se enquadram nesta faixa de probabilidades, sendo essas as causas do que é notado como efeitos de indisponibilidade de segunda ordem que podem exacerbar interrupções temporárias ou levar a outros efeitos. Podem ser incidentes em que incidentes acidentais ou ambientais em nível local acabam tendo efeitos globais. Como consequência, seu impacto é difícil de prever. Existem também várias ameaças acidentais de média probabilidade que podem levar à exclusão de dados. Notavelmente, todas as ameaças potenciais que afetam a integridade dos dados são de média ou baixa probabilidade. Em outras palavras, incidentes que resultem na exclusão ou alteração de dados na nuvem não serão comuns. Os estudos de caso apóiam essa descoberta provisória.

No conjunto menos provável de ameaças estão as tentativas adversárias por parte dos clientes de roubar dados uns dos outros: tais cenários incluem os riscos de que um cliente possa infringir a confidencialidade dos dados de outro, ameaças de interromper permanentemente a disponibilidade (seja adversário ou ambiental) e adversário tenta excluir ou manipular a integridade dos dados. Essa observação não sugere que a nuvem seja imune a ataques adversários. Em vez disso, esses ataques terão uma probabilidade baixa de sucesso – especialmente aqueles que visam a integridade dos dados em oposição à sua confidencialidade – por causa da segurança e resiliência altamente sofisticadas incorporadas à arquitetura da nuvem pelos principais CSPs para evitar exatamente esse cenário. Essa descoberta é paralela às tendências mais amplas do setor: nos círculos de segurança cibernética, o roubo de dados é muito mais comum do que ataques destrutivos.

As discussões sobre segurança na nuvem tendem a se concentrar em eventos comuns (como a exposição inadvertida de dados do cliente, principalmente) ou nos ataques destrutivos mais significativos. O foco no último geralmente leva a uma conversa mais ampla sobre o risco sistêmico e a nuvem. Ao discutir este tópico, é importante deixar claro a qual sistema está se referindo. Primeiro, pode haver risco sistêmico potencial para os principais CSPs se seus sistemas inteiros forem interrompidos em todo o mundo. Até agora, no entanto, nunca houve um caso disso acontecendo, e parece extremamente improvável. Em segundo lugar, também pode haver risco sistêmico para setores críticos se dados ou serviços críticos que usam a nuvem forem interrompidos ou destruídos. Como a estrutura da figura 5 ilustra, não seria necessário que um CSP inteiro fosse interrompido para que tal incidente ocorresse.

Em relação a uma segunda forma de risco sistêmico, traçar o caminho entre um vetor de ameaça específico e uma consequência e, em seguida, atribuir-lhe uma probabilidade – a definição de risco – não é possível sem referência à função de qualquer dado ou serviço em questão que está sendo mantido em a nuvem. Ou seja, embora as ameaças à nuvem possam ser independentes dos dados, seus impactos não são. Na verdade, uma ameaça semelhante pode ter consequências muito diferentes entre os incidentes, dependendo de quais clientes e quais dados ou serviços específicos são afetados.

Esse insight leva à conclusão potencial de que uma abordagem específica do setor seria melhor para avaliar o risco sistêmico da nuvem para setores críticos. Um exemplo disso é o Relatório do Banco de Compensações Internacionais de 2018 sobre riscos de nuvem para o setor de seguros, que discutiu os riscos em termos de sistemas e dados específicos, como a seguir: “A continuidade dos negócios e a resiliência operacional podem ser comprometidas se. . . as seguradoras e suas autoridades supervisoras estão impedidas de acessar, auditar e fazer exames no local para provedores de nuvem localizados em diferentes jurisdições. ” ⁹⁹

Com relação ao risco sistêmico para a nuvem, um ponto de partida para essa avaliação é examinar quais pontos de vulnerabilidade são compartilhados no ecossistema da nuvem e onde algumas das ameaças potenciais podem ter um impacto generalizado. As camadas de hardware (servidor) e hipervisor são candidatas óbvias. De fato, as vulnerabilidades Spectre e Meltdown são exemplos importantes desse tipo de risco, que felizmente foi evitado antes de ser explorado (pelo menos de acordo com relatos publicamente conhecidos). Dada a diversidade de abordagens no topo da pilha entre vários CSPs, diferentes clientes e vários aplicativos da nuvem, é muito mais difícil imaginar potenciais vulnerabilidades sistêmicas se manifestando de maneira semelhante. Como a nuvem em grande escala, essa diversidade de abordagens torna mais imperativo focar a defesa em hardware e hipervisores,

****

VULNERABILIDADES DE HIPERVISOR

Os hipervisores são especialmente importantes para a segurança dos CSPs. ¹⁰⁰ Enquanto outros vetores de impacto, como relâmpagos ou ransomware, afetam muitas outras infraestruturas também, os hipervisores são de importância crítica para a nuvem, gerenciando a conexão entre suas máquinas virtuais e a alocação de recursos para elas. Os CSPs devem ser capazes de confiar em seus hipervisores da mesma forma que confiam nas máquinas subjacentes, se não mais, já que os hipervisores gerenciam o isolamento das máquinas virtuais convidadas. Portanto, as vulnerabilidades nos hipervisores são um problema crucial para os CSPs abordarem. A má notícia é que, como todo software, os hipervisores têm vulnerabilidades. ¹⁰¹

Por exemplo, os vencedores de uma competição de hacking de chapéu branco de 2019 encontraram várias vulnerabilidades no software de virtualização da VMware e Oracle – incluindo uma que permitia a execução de código no hipervisor, o que poderia essencialmente permitir que um ator de ameaça escapasse dos limites de uma máquina virtual para ser executado o servidor geral. ¹⁰² Geralmente, tais técnicas são referidas como escape de máquina virtual. Uma possibilidade é que um invasor instale um hipervisor falso para assumir o controle de todo o sistema do servidor – uma prática chamada “hipervisor”. ¹⁰³

A boa notícia é que não há instâncias conhecidas de ataques que exploraram hipervisores. O que se sabe é que a vulnerabilidade Spectre e outra vulnerabilidade relatada, uma chamada manipulação de operações negligenciadas de ambiente virtualizado (VENOM), podem ter permitido tais explorações. ¹⁰⁴ E pelo menos um artigo de pesquisa ¹⁰⁵ discute vulnerabilidades de hipervisor em ambientes de serviço em nuvem, configurando um ambiente de demonstração e realizando vários tipos de ataques clássicos contra ele. ¹⁰⁶

Os maiores pontos cegos no debate atual são os riscos de probabilidade média a baixa. Isso inclui riscos estruturais que resultam de sistemas altamente complexos e fortemente acoplados que podem ser significativamente danificados por acidentes ou ameaças ambientais, bem como ameaças adversas altamente sofisticadas contra a confidencialidade de dados. A campanha Cloudhopper é um exemplo poderoso do impacto potencial e da significância que o comprometimento de um CSP pode ter sobre seus clientes. À medida que mais e mais dados importantes, mas talvez menos que críticos, estão localizados na nuvem, os agentes de ameaças terão maiores incentivos para se envolver em mais desses tipos de campanhas, especialmente organizações de hackers vinculadas ao governo.

Claro, mitigar esses riscos potenciais é altamente desafiador. Os estados são capazes de empregar abordagens persistentes avançadas para encontrar seus caminhos até mesmo nos alvos mais seguros. As organizações criminosas também demonstraram métodos sofisticados de roubo de dados. E, em muitos casos, a complexidade da nuvem atua contra sua segurança. Nem um CSP nem um cliente podem ter visibilidade total da arquitetura conjunta de seus sistemas e, portanto, nenhum deles pode ser capaz de retificar vulnerabilidades estruturais em potencial antes que causem falhas.

Além disso, o nível de risco depende do que está na nuvem. Identificar os impactos potenciais simplesmente não é possível em uma base geral. Em linhas gerais, à medida que os dados e serviços mais importantes estão localizados na nuvem e certas organizações tornam todas as suas operações baseadas na nuvem, esses riscos de baixa a média probabilidade aumentarão em consequência.

DE QUEM É O FARDO? MODELOS DE RESPONSABILIDADE COMPARTILHADA PARA SEGURANÇA

À medida que as organizações fazem a transição de partes de suas funções para CSPs, suas equipes de segurança precisam atualizar suas funções e responsabilidades e priorizar de acordo. Algumas responsabilidades irão migrar para CSPs para liberar a largura de banda das equipes de TI do cliente, enquanto outras responsabilidades surgirão com relação ao gerenciamento do relacionamento entre um determinado cliente e seu CSP. É por isso que os principais CSPs desenvolveram modelos de responsabilidade compartilhada como uma ferramenta educacional para fornecer orientação aos clientes (ver figura 6). É essa interface entre um determinado CSP e seu cliente que apresenta uma nova vulnerabilidade técnica e humana, em parte por causa da novidade da tecnologia. Por exemplo, o vazamento de dados da Capital One foi o resultado de uma configuração incorreta que caiu neste espaço cinza de responsabilidade compartilhada.

Existem muitos pontos em comum entre os vários modelos de responsabilidade compartilhada que os principais CSPs formularam para delinear como eles quebram os vários aspectos das responsabilidades de segurança entre eles e seus clientes. A Figura 6 mostra como eles traçam delineamentos semelhantes entre CSPs e clientes. As variações tendem a ser pequenas. Por exemplo, o modelo AWS não exibe o modelo de implantação diferente (IaaS, PaaS, SaaS) em comparação com a ilustração do Azure. O Azure adota uma abordagem em camadas, definindo responsabilidades em termos de funções em vez de sistemas. O modelo AWS rastreia mais de perto a coluna IaaS do Azure, embora não tenha as funções compartilhadas entre o CSP e seu cliente, como mostra o Azure. Na abordagem AWS, há alguma responsabilidade do CSP por funções semelhantes, mas elas são mostradas separadamente.

Essa responsabilidade compartilhada não pode ser evitada, visto que a migração para a nuvem exige que os clientes envolvam e confiem nos CSPs como terceiros. É por isso que uma compreensão clara das funções e responsabilidades de cada lado é fundamental para evitar acidentes e evitar que a interface se torne uma porta de entrada para atores nefastos. O incidente da Capital One ilustrou o custo de reputação para CSPs e seus clientes que acompanham qualquer deficiência nesta área. Portanto, é do próprio interesse dos CSPs fornecer assistência aos seus clientes para minimizar esses riscos. Esta também é uma área onde as agências governamentais podem estudar como garantir que essa assistência seja fornecida e que, na relação desigual entre a maioria dos clientes e seus gigantes CSPs,

ESTRUTURA DE GRAVIDADE DE INCIDENTE CIBERNÉTICO NA NUVEM

A estrutura abrangente descrita acima na figura 5 detalha uma variedade de incidentes que podem afetar os CSPs, bem como estimativas aproximadas para as probabilidades associadas a eles. No entanto, conforme discutido acima, é impossível conectar diretamente os vetores de ameaças potenciais aos impactos. Com a variedade de dados e serviços mantidos na nuvem, as ameaças podem ter quase nenhum impacto ou ser alguns dos incidentes de segurança cibernética mais prejudiciais que já ocorreram. Na verdade, semelhante a outros sistemas complexos, os formuladores de políticas podem apenas ser capazes de avaliar a origem de um incidente de nuvem sistêmica após o fato, uma realidade que ressalta a necessidade de se concentrar na resposta e recuperação, em vez de prevenção.

Com o objetivo de ser mais útil para os formuladores de políticas preocupados com o impacto dos incidentes, a tabela 6 vai além da estrutura tecnicamente informada descrita na figura 5, detalhando uma estrutura para avaliar a gravidade de um incidente baseado em nuvem. Esta estrutura é baseada no esquema geral de gravidade de incidente cibernético desenvolvido pela equipe da Casa Branca em 2016 para a Diretiva de Política Presidencial 41. ¹⁰⁷

Nas categorias inferiores (branco a amarelo), ocorrem apenas ameaças limitadas à confidencialidade ou disponibilidade da nuvem, semelhantes a incidentes públicos anteriores. A gravidade dos incidentes aumenta com seu impacto, dependendo de quais tipos específicos de dados e clientes de nuvem são afetados. Por exemplo, uma configuração incorreta hipotética que exporia os dados de uma gravadora pode ser embaraçosa e cara do ponto de vista da reputação, mas seria insignificante em comparação com um vazamento de dados envolvendo dados oficiais do governo para uma finalidade vital, como revisões de autorização de segurança. Claro, tudo isso depende da extensão em que tais serviços, especialmente aqueles críticos para as necessidades humanas imediatas, como provedores de saúde, dependem da nuvem. A maior dependência social da nuvem aumenta o potencial de riscos de aumentar essa escala de gravidade.

Por último, os incidentes de exemplo ressaltam que as ameaças à integridade dos dados, bem como as perdas permanentes de disponibilidade de dados, podem ter os maiores impactos potenciais. Esses riscos têm maior potencial para acionar os tipos de consequências físicas e perda de confiança que as análises mais terríveis de incidentes de nuvem alertam.

A utilidade dessa estrutura dependerá dos CSPs e de seus clientes. Se for usado por ambos para avaliar ameaças potenciais a dados e serviços críticos, pode ser uma maneira de ambas as partes entenderem os impactos de vários cenários de incidentes. Também pode ser um ponto de partida para esforços futuros para especificar melhor quais tipos de problemas de segurança em nuvem podem ter os impactos mais significativos e como mitigar essas ameaças.

CAPÍTULO 4: QUESTÕES DE POLÍTICA PÚBLICA ADICIONAIS A CONSIDERAR

O foco deste documento está nas implicações de políticas públicas da segurança na nuvem. Existem outras questões importantes e relevantes de política pública para as quais tratamentos extensivos estão além do escopo deste artigo, a saber, 1) governança de dados, 2) a conexão de indústrias de tecnologia e influência geopolítica, e 3) regulamentação antitruste. Algumas dessas questões têm relevância direta para o conjunto de questões de política de segurança que este documento discute, incluindo debates sobre políticas sobre localização de dados e infraestrutura crítica, enquanto outras, como considerações antitruste, estão indiretamente relacionadas.

GESTÃO DE DADOS

O campo de governança de dados abrange um grande conjunto de questões envolvendo o controle, acesso, proteção e regulamentação de dados pessoais e comerciais por empresas de tecnologia e governos. Como grandes quantidades de dados individuais e corporativos começaram a ser armazenados e processados na nuvem, essa transição levantou questões sobre o acesso que os governos podem exercer aos dados na nuvem, especialmente para CSPs que armazenam dados no exterior.

A natureza dos serviços em nuvem é tal que os dados pertencentes aos cidadãos ou ao governo de um país podem ser armazenados em diferentes países e jurisdições. Esse estado de coisas, então, apresenta problemas de governança de dados: quem faz as regras que regulam esses dados? Deve ser o país onde os dados estão armazenados (tendo em mente que os dados em nuvem podem de fato ser fragmentados, ou divididos e simultaneamente armazenados em diferentes centros de dados) ou o país onde os proprietários dos dados estão localizados? ¹⁰⁸A última opção levanta problemas devido à aplicação da lei extraterritorialmente, particularmente dadas as deficiências nos quadros de assistência jurídica mútua para informação digital. No entanto, se isso não fosse feito, haveria sérios desafios para legitimar as solicitações de acesso legais nos Estados Unidos e em outros países com um Estado de Direito forte. Por outro lado, a expansão do acesso legal pode permitir que os países com registros mais fracos de direitos humanos conduzam vigilância ilegítima e explorem a soberania de outros países onde os valores de privacidade podem ser diferentes.

Em março de 2018, os Estados Unidos aprovaram uma legislação para esclarecer que a Lei de Comunicações Armazenadas, que permite que os agentes da lei emitam mandados ou mandados para acessar dados mantidos por provedores de serviços, se aplica aos dados mantidos no exterior. Essa legislação, a Lei de Esclarecimento do Uso Legal de Dados no Exterior (CLOUD), também permitiu aos Estados Unidos celebrar acordos com países estrangeiros que atendam a um conjunto de proteções de privacidade para permitir que suas agências de aplicação da lei solicitassem dados de provedores de serviços dos EUA. ¹⁰⁹ Embora a Lei CLOUD não tenha resolvido todos os problemas associados ao acesso de dados transfronteiriços, ela forneceu mais clareza para os CSPs e corrigiu algumas situações potenciais onde, para cumprir a lei de uma jurisdição, eles poderiam violar a lei de outra jurisdição.

Da mesma forma, em fevereiro de 2019, o Reino Unido (RU) aprovou uma legislação autorizando a aplicação da lei a emitir “ordens de produção no exterior” para os fornecedores para obrigá-los a fornecer evidências eletrônicas, independentemente da localização. ¹¹⁰ Ambas as partes da legislação são significativas porque estendem o alcance das autoridades legais além das fronteiras nacionais e tentam adaptar a lei de evidências eletrônicas à nova realidade dos CSPs globais com dados distribuídos em muitas jurisdições.

O amplo alcance de governos estrangeiros tem sido uma questão importante de governança de dados e uma preocupação fundamental para muitos países. As revelações sobre as capacidades de vigilância das agências de inteligência dos EUA e sua estreita cooperação com empresas de tecnologia dos EUA, conforme divulgadas pelo ex-contratante de inteligência Edward Snowden em 2013, geraram profunda desconfiança nas empresas de tecnologia dos EUA no exterior. Como os principais CSPs (AWS, Google Cloud e Microsoft Azure) e outras empresas de tecnologia com as principais ofertas de nuvem (Salesforce, Dropbox e IBM) estão todos baseados nos Estados Unidos, outros países têm procurado colocar proteções para limitar como essas empresas usam os dados de seus cidadãos. As preocupações com a vigilância estrangeira contribuíram para o Regulamento Geral de Proteção de Dados (GDPR) da União Europeia (UE) em 2018, que aplicou as normas de proteção de dados da UE a quaisquer dados relativos a cidadãos da UE, mesmo se localizados fora da UE. Dependendo das especificações de seus acordos, muitos CSPs são qualificados como “processadores de dados” para seus clientes europeus, o que significa que eles devem cumprir as restrições do GDPR.¹¹¹

As preocupações com o acesso ao conteúdo e as implicações para os direitos humanos também afetam os CSPs que entram nos mercados em regiões que incluem governos autoritários. Alguns governos são amplamente conhecidos por realizarem a vigilância de ativistas de direitos humanos e dissidentes e por buscarem usar empresas de tecnologia para impor a censura e retirar conteúdo politicamente controverso. ¹¹² No entanto, as empresas de nuvem parecem estar avançando com a expansão de sua presença em países autoritários e com tendências autoritárias. ¹¹³ Em 2017, a AWS anunciou que abriria sua primeira região no Oriente Médio, no Bahrein, para entrar em operação no início de 2019, ao mesmo tempo que informava que teria uma localização de rede de ponta nos Emirados Árabes Unidos (Emirados Árabes Unidos). ¹¹⁴O Microsoft Azure fez o mesmo com as regiões de Abu Dhabi e Dubai. ¹¹⁵ Um mês depois, o relatório de lucros trimestrais do Google confirmou ¹¹⁶ que estaria construindo uma região na Arábia Saudita, elevando seu total global para vinte. No entanto, em junho de 2020, esta região ainda não estava online, embora tenha havido relatos de que o Google ainda está buscando isso. ¹¹⁷

Os relatórios sobre o investimento da AWS na Arábia Saudita também são datados. Não está claro até que ponto o assassinato do jornalista saudita Jamal Khashoggi e uma disputa de alto nível entre Bezos e o príncipe herdeiro da Arábia Saudita, Mohammed bin Salman, influenciaram este estado de coisas. As principais empresas de nuvem ocidentais parecem estar tentando equilibrar as preocupações de direitos humanos de fazer negócios no Oriente Médio com os lucros potenciais de parcerias com governos ricos em um mercado em crescimento.

Localização de dados

Os requisitos de localização de dados também têm aumentado em todo o mundo. De empresas nacionais a estrangeiras, alguns governos estão exigindo cada vez mais que os CSPs armazenem dados sobre cidadãos de uma jurisdição nessa mesma jurisdição. Por exemplo, a Índia aprovou ou propôs uma série de requisitos de localização de dados, incluindo uma regra de que todos os dados de pagamento sobre transações financeiras na Índia sejam armazenados no país, um desenvolvimento que gerou resistência por parte de grandes firmas financeiras e do governo dos EUA. ¹¹⁸ A Coreia do Sul e o Brasil também aprovaram medidas que exigem a localização de dados em circunstâncias específicas.

Os requisitos de localização mais significativos, no entanto, estão na China. O governo chinês exige que “dados importantes” sobre os cidadãos chineses estejam localizados na China, bem como dados relacionados à “infraestrutura de informação” crítica. ¹¹⁹ Esses termos vagos permitem que as autoridades chinesas imponham requisitos de localização a muitas grandes empresas estrangeiras, exigindo, por exemplo, que trabalhem com parceiros locais para usar centros de dados chineses. ^{Em geral, 120} CSPs ocidentais cumpriram com esses requisitos (como o AWS e o Microsoft Azure) ou deixaram o mercado chinês (como o Google fez).

A localização de dados impactou significativamente a forma como os CSPs fazem negócios na China, mas o impulso para localização de dados também levou a diferentes modelos de serviços em nuvem em outros lugares. Um desses modelos é a oferta de nuvem do Microsoft Azure na Alemanha, que emprega um modelo de trustee para atender às preocupações sobre espionagem nos Estados Unidos. Em 2015, logo após as revelações de Snowden, a Microsoft anunciou que abriria uma oferta de nuvem na Alemanha que seria executada por um administrador de dados, a T-Systems. A T-Systems, uma subsidiária da Deutsche Telekom, controlava os dados armazenados na Alemanha, e a Microsoft só poderia acessar os dados com a permissão do cliente e da T-Systems.

Esse arranjo parecia ser uma solução para algumas das preocupações europeias sobre os CSPs dos EUA, mas não durou. Em setembro de 2018, o Microsoft Azure anunciou que não aceitaria mais novos clientes para o Azure Alemanha e disse que abriria duas regiões que fariam parte de sua rede de nuvem global na Alemanha. ¹²¹ Segundo relatos, a Azure Germany não teve sucesso devido aos custos mais elevados e à segmentação dos negócios internacionais. ¹²² O fracasso desta oferta de nuvem com sede na Alemanha aponta para algumas das vantagens que tornaram os serviços de nuvem um negócio global: seus preços baixos e capacidade de conectar e atender clientes além das fronteiras, que são contrários aos requisitos de localização.

EMPRESAS DE TECNOLOGIA E INFLUÊNCIA GEOPOLÍTICA

A paisagem dos principais CSPs se divide em linhas geopolíticas. As empresas sediadas nos Estados Unidos (principalmente AWS, Microsoft Azure e Google Cloud) dominam o mercado global de nuvem. As únicas alternativas importantes são os CSPs chineses (Alibaba e Tencent). Essa divisão tem ramificações geopolíticas no contexto mais amplo da competição de tecnologia entre os EUA e a China, especialmente em outros países onde os CSPs dos EUA estão competindo com os CSPs da China por participação de mercado. Como a computação em nuvem pode fornecer serviços cruciais para o desenvolvimento de um setor de tecnologia, as decisões sobre onde os CSPs fazem investimentos e onde eles abrem data centers, AZs e regiões de serviço estão frequentemente ligadas a questões geopolíticas.

Os encargos que a China colocou sobre os CSPs estrangeiros efetivamente os proibiram de exercer o mesmo grau de domínio do mercado no início desta década, como fizeram em outros lugares – na Europa, por exemplo. Como um funcionário do Conselho da Indústria de Tecnologia da Informação dos EUA declarou em 2019, os CSPs baseados nos EUA “enfrentam requisitos escritos e não escritos que não permitem que empresas estrangeiras obtenham licenças para operar sem um parceiro chinês; forçar os CSPs dos EUA a renunciarem ao uso de suas marcas; e exigir que as empresas entreguem a operação e o controle de seus negócios para empresas chinesas para fazer negócios no mercado chinês. ” ¹²³Essas restrições provavelmente permitiram que os CSPs da China dominassem o mercado local e se tornassem grandes o suficiente para competir com os CSPs dos EUA, como estão fazendo em regiões como o Leste e Sudeste Asiático e o Oriente Médio. ¹²⁴

O papel influente da China também se estende ao ecossistema de cabos submarinos. A Huawei era anteriormente uma acionista de 51 por cento da Huawei Marine, uma das Quatro Grandes empresas de instalação de cabos (as outras sendo a SubCom, dos Estados Unidos, a Alcatel de propriedade finlandesa e a NEC Corporation de propriedade japonesa). ^{125 A} Huawei Marine aumentou sua participação nos principais projetos de cabo e está trabalhando em um cabo Europa – Oriente Médio – África, embora a Huawei não trabalhe em um projeto de cabo nos Estados Unidos desde 2013. Não é surpresa que as autoridades ocidentais tenham se preocupado com o crescimento da China influência nesta área. Em 2017, a Austrália interveio com sucesso para convencer as Ilhas Salomão a não permitir que a Huawei construísse um cabo da nação insular até Sydney. ¹²⁶Ainda assim, em 2018, Austrália, Japão e Estados Unidos não conseguiram convencer Papua-Nova Guiné a recuar de um acordo com a empresa. ¹²⁷ Em 2019, a Huawei vendeu sua participação na Huawei Marine para outra empresa chinesa, depois que o papel da Huawei na construção de cabos submarinos recebeu análise semelhante como esforços para banir a Huawei da infraestrutura 5G em vários países. ¹²⁸

Essa competição tem implicações mais amplas, pois os países enfrentam a escolha de 1) adotar CSPs baseados nos EUA e aceitar o acesso potencial do governo dos EUA aos dados, 2) adotar CSPs chineses e enfrentar o risco representado pelo governo chinês por ter acesso a esses dados ou 3) ficar sem os benefícios econômicos e de segurança dos serviços em nuvem. Essas questões geopolíticas relacionadas aos investimentos em nuvem, portanto, não se limitam à competição EUA-China e merecem pesquisas adicionais.

CONSIDERAÇÕES ANTITRUSTE

A regulamentação antitruste também surgiu como uma questão importante na política de tecnologia. A UE multou grandes empresas de tecnologia dos EUA por violarem regras para proteger a concorrência, incluindo multas pesadas contra o Google por suas práticas de publicidade. ¹²⁹Embora os reguladores europeus tenham sido ativos em multar grandes empresas de tecnologia por violarem as leis de concorrência, os reguladores dos EUA ainda não moveram nenhuma ação contra as grandes empresas de tecnologia. No entanto, há vários apelos para que o Departamento de Justiça e a Comissão de Comércio Federal sejam mais agressivos em sua supervisão antitruste das Quatro Grandes empresas de tecnologia – Apple, Amazon, Facebook e Google. A senadora norte-americana e ex-candidata à presidência Elizabeth Warren foi além, propondo “separar a Big Tech” ao designar grandes empresas de tecnologia como “utilitários de plataforma” e separar seus serviços básicos de seus outros negócios. ¹³⁰

A maioria das discussões antitruste concentra-se em atividades de grandes empresas de tecnologia não relacionadas a serviços em nuvem, como a estratégia da Amazon de reduzir a concorrência com a venda de produtos com prejuízo em seu mercado online. As atividades regulatórias da UE até agora também não visaram às empresas dos EUA para seus negócios em nuvem. No entanto, propostas para dividir grandes empresas afetariam seus negócios em nuvem, especialmente porque os serviços em nuvem contribuem com uma grande fração dos lucros da Amazon e da Microsoft. O próprio mercado de serviços em nuvem tem concorrência significativa entre os grandes CSPs, bem como entre empresas menores. Em muitos casos, uma preocupação potencial é que, como tantas empresas dependem de serviços em nuvem, os concorrentes das empresas CSP líderes em outras linhas de negócios são seus clientes de nuvem, criando um conflito de interesses. ¹³¹Assim, alguns pediram especificamente para separar a AWS do mercado online da Amazon e outras ofertas. ¹³²

No entanto, pode haver benefícios estratégicos em preservar os negócios em nuvem em conglomerados maiores, como Google e Amazon. Particularmente, uma vez que os governos agora procuram fazer parceria com provedores de nuvem comercial para desenvolver suas próprias nuvens, como o projeto JEDI do Departamento de Defesa dos EUA, apenas grandes corporações com recursos para desenvolver sua própria infraestrutura global podem ser capazes de atender aos requisitos de segurança nacional. Como alguns argumentaram, as demandas singulares do governo dos EUA podem exigir grandes parceiros corporativos. ¹³³

Em conclusão, embora este artigo se concentre na segurança, essas outras três questões não podem ser ignoradas e estão interligadas. Por exemplo, perguntas sobre a capacidade da comunidade de inteligência dos EUA de acessar dados de CSPs são uma grande preocupação de segurança para outros países. E a competição entre os CSPs dos EUA e da China é paralela às preocupações de segurança sobre a competição de tecnologia EUA-China. Os tomadores de decisão de políticas públicas que lutam com as implicações da migração para a nuvem por motivos de segurança devem, portanto, também ter em mente essas outras dimensões para tomar decisões informadas, abrangentes e baseadas em risco.

A NUVEM PRECISA DE PROTEÇÃO

A ascensão da computação em nuvem e do armazenamento em nuvem transformou o cenário da cibersegurança. A migração para a nuvem é uma solução para muitos problemas persistentes de insegurança cibernética para organizações que anteriormente gerenciavam seus sistemas de TI sozinhas, mas também apresenta simultaneamente um novo conjunto de problemas de segurança altamente complexos e globais. À medida que esse ecossistema evolui, os formuladores de políticas precisam melhorar sua própria compreensão das questões políticas críticas que afetam (e são afetadas pela) nuvem; a segurança é o principal entre eles.

Esta cartilha tenta delinear alguns conceitos-chave que conectam os mundos técnico e político. Apesar de todos os apelos de analogias, a nuvem como um termo obscurece mais do que explica. A nuvem não é unitária nem inacessível para agentes maliciosos. A diversidade de serviços em nuvem, modos de implantação e plataformas e sua onipresença na vida moderna devem enfatizar a importância de uma compreensão diferenciada desse ecossistema.

No lugar de uma evocação vaga de um lugar etéreo onde os dados vão e são dispensados do alto, é útil desagregar partes da nuvem e falar de sistemas mais granulares. A Figura 1 no capítulo 1 oferece uma abordagem, categorizando vários elementos de uma arquitetura em nuvem de acordo com um modelo baseado em camadas, para que se possa falar da camada física (data centers) em oposição ao hipervisor ou camadas de API em nuvem. Essa desagregação ajuda a separar os incidentes potenciais, bem como os impactos regulatórios.

Mas um conhecimento técnico não será suficiente para os formuladores de políticas que procuram avaliar os impactos dos serviços em nuvem. É necessária uma compreensão mais ampla da dinâmica do mercado descrita no capítulo 2. O fato mais saliente que os formuladores de políticas devem observar é que o mercado de infraestrutura em nuvem pública se concentrou notavelmente em um punhado de grandes empresas de tecnologia. Embora isso possa mudar no médio a longo prazo, como resultado da inovação tecnológica ou do aumento da concorrência entre os CSPs dos EUA e da China por mercados emergentes, para citar alguns exemplos, continuará sendo uma característica dominante do ecossistema e do cenário de risco pelo menos no curto prazo.

O mais claro entre as descobertas da seção dedicada à segurança não é uma deficiência na segurança dos serviços de nuvem, mas uma deficiência positiva para o ecossistema de TI mais amplo: uma migração para a nuvem ajudará a maioria das organizações a resolver o problema existente de insegurança cibernética. Com isso dito, certos fatores diferenciam os serviços em nuvem de outros desafios de segurança – eles são inerentemente conectados em rede, concentrados e compartilhados. Embora tenha havido muitos tipos diferentes de incidentes de segurança na nuvem, conceituar riscos de segurança na nuvem de forma mais abrangente continua sendo uma área de estudo subdesenvolvida.

À medida que os formuladores de políticas avaliam a segurança da nuvem, eles devem ser cautelosos com análises simplistas que desconsideram as ameaças de segurança aos CSPs e aquelas que alertam sobre desastres caso um CSP supostamente falhe. Como é o caso da maioria dos problemas de segurança cibernética, a verdade está em algum lugar no meio. Isso não significa que os problemas de segurança na nuvem não devam ser priorizados. Na verdade, o fato de que pouco se sabe sobre os impactos potenciais destaca a necessidade urgente de estudar esse problema e de identificar conjuntos de problemas específicos onde ações futuras, seja do setor privado ou público, melhorariam a segurança.

Para melhor conceituar a segurança na nuvem, a figura 5 no capítulo 3 apresenta uma abordagem técnica, centrada na estrutura da CIA, que destaca a confidencialidade, integridade e disponibilidade dos dados e serviços da nuvem. Ele destaca como os riscos podem ser diferenciados com base em suas probabilidades e seus prováveis impactos técnicos. Uma conclusão importante é que, embora existam ameaças relativamente comuns, como tentativas de violação da confidencialidade dos dados da nuvem, o que permanece pouco estudado e pouco discutido são os eventos de probabilidade média a baixa que podem causar custos significativos, mas não catastróficos. É necessário mais trabalho para entender o impacto potencial desses tipos de eventos e quais intervenções podem ter mais sucesso em evitá-los.

Para os formuladores de políticas que se concentram não apenas no ambiente de segurança em nuvem atual, mas considerando os cenários futuros em potencial, a escala de gravidade apresentada na tabela 6 do capítulo 3 é projetada para fornecer um ponto de partida para avaliar incidentes de nuvem com base em seus impactos. Uma maneira de conectar a abordagem técnica da figura 5 com a abordagem baseada em impacto da tabela 6 é avaliar como os incidentes podem afetar as várias camadas da arquitetura da nuvem, bem como os principais mercados e setores críticos. Novamente, pesquisas adicionais são necessárias, especialmente para avaliar os riscos sistêmicos por camada, mas o trabalho de conceituar os riscos da nuvem para setores específicos já começou. O relatório do Banco de Compensações Internacionais de 2018, mencionado anteriormente, que analisa a nuvem e o setor de seguros, é um exemplo notável. ¹³⁴

Em última análise, o principal desafio da política pública permanece: como os profissionais e formuladores de políticas maximizam os benefícios de segurança cibernética fornecidos pelos CSPs e como eles minimizam seus riscos? ¹³⁵A primeira consideração é claramente orientada por incentivos de mercado e segurança para migrar para a nuvem. O último é aquele em que provavelmente haverá regulamentação adicional. Este artigo permaneceu agnóstico sobre soluções regulatórias específicas para alguns dos problemas que ele delineou. Este é um tópico para estudo detalhado futuro, especialmente quando se trata de entender como as estruturas regulatórias existentes já se aplicam aos serviços em nuvem. É claro que qualquer regulamentação futura também teria que levar em consideração as outras questões de política pública que o capítulo 4 resumiu em breve. Será necessário encontrar um equilíbrio entre várias ações – como utilidade, flexibilidade, privacidade e segurança.

A discussão deste artigo sobre a segurança na nuvem destaca três compensações que os formuladores de políticas terão de abordar ao considerar a segurança na nuvem: risco diário versus risco sistêmico, benefícios e custos da concentração do setor e abordagens gerais versus específicas do setor.

Riscos diários versus riscos sistêmicos : as equipes de segurança das empresas de nuvem lidam com tentativas de invasão diariamente. Seus clientes também configuram seus dados e serviços baseados em nuvem para evitar que sejam inadvertidamente expostos a criminosos comuns. Lidar com esses e outros desafios diários provavelmente consome a maior parte do foco na segurança dos CSPs. No entanto, ainda existe a possibilidade de um futuro incidente de segurança ter um impacto catastrófico em todo o ecossistema baseado em nuvem. O planejamento de como lidar com esses diferentes tipos de riscos exigirá estratégias diferentes e priorização competitiva de recursos, tempo e foco.
Benefícios e custos da concentração : A concentração do poder de mercado entre os principais CSPs confere importantes benefícios de segurança semelhantes à lógica por trás do Fort Knox. Um benefício particular que vale a pena destacar é sua capacidade incomparável de atrair pessoal de segurança talentoso com conhecimento sobre como proteger dados e processos em vetores de ameaças e em um suprimento muito raro. Por outro lado, falhas ou incidentes de segurança que afetam um provedor de nuvem podem criar consequências sistêmicas. É importante ressaltar que os benefícios do tamanho dos CSPs são sentidos todos os dias, enquanto os riscos potenciais ainda não se manifestaram.
Abordagens gerais versus abordagens específicas do setor : como esta cartilha mostrou, o impacto de um incidente de segurança na nuvem geralmente depende de que tipo de dados ou serviço é afetado. Assim, os requisitos regulatórios potenciais mais adequados com relação à segurança podem diferir entre os setores que lidam com diferentes tipos de dados – desde dados altamente sensíveis e rápidos, comuns no setor financeiro, até dados pessoais mais sensíveis à privacidade usados por serviços médicos provedores. No entanto, a formulação de regulamentação setor a setor provavelmente criaria requisitos conflitantes e padrões incompletos.

Essas não são as únicas compensações que os formuladores de políticas enfrentam em relação à nuvem. Como essa conclusão enfatizou, mais pesquisas são necessárias para responder a muitas perguntas críticas sobre segurança em nuvem. Para tanto, segue esta seção uma lista de vários tópicos de pesquisa que devem ser explorados em pesquisas futuras. Estes são um ponto de partida para esforços futuros para construir sobre as estruturas esboçadas no capítulo 3.

À medida que a tarefa de proteger a nuvem se torna cada vez mais sinônimo de segurança cibernética em grande escala, os formuladores de políticas devem entender e considerar melhor o impacto da nuvem. A falta de atenção pode levar a uma repetição do problema da insegurança cibernética em uma escala ainda maior, com consequências mais graves do que as vistas até agora.

ÁREAS PROMISSORAS PARA PESQUISAS FUTURAS RELACIONADAS À SEGURANÇA

Nesse espírito, existem algumas áreas para futuras pesquisas relacionadas à segurança que devem ser destacadas.

Transparência no uso de CSPs: Um desafio importante para os formuladores de políticas continua sendo a falta de transparência sobre quais empresas estão contando com CSPs e com que propósito. Como um artigo da Reuters aponta, “as empresas geralmente não são obrigadas a divulgar seus fornecedores de nuvem”. ¹³⁶O artigo aponta que os motivos para divulgar o uso de um CSP costumam ser uma “menção passageira” seguida de “risco corporativo”. Se os governos devem ou não exigir maior transparência sobre o uso de CSPs pelas empresas é uma questão que requer mais pesquisas. Por exemplo, um risco associado a esse requisito de transparência é que aumentaria o risco de segurança em um cenário em que um CSP é intencionalmente direcionado para chegar a um cliente. No entanto, um requisito de transparência provavelmente também melhorará as políticas de mitigação de riscos.

Protegendo cabos submarinos: os cabos submarinos se tornaram essenciais para garantir o acesso aos dados de forma contínua. ¹³⁷ No entanto, a infraestrutura de cabo submarino da qual os CSPs dependem e suas vulnerabilidades são um desafio de política internacional negligenciado. ¹³⁸ Esta série de questões inter-relacionadas inclui a confiança em um único cabo ou alguns cabos para fornecer acesso a países individuais e a concentração de locais de aterramento de cabos dentro de um único país. ¹³⁹ Embora as empresas que operam cabos submarinos frequentemente concluam acordos entre si para redirecionar dados em caso de falhas, não está claro se este sistema seria eficaz para uma fração significativa de cabos.

Várias idéias foram propostas para aumentar a segurança dos cabos submarinos, incluindo um modelo de seguro subsidiado para CSPs que atendem a certas diretrizes de segurança definidas pelo governo. ¹⁴⁰Se atenderem a essas diretrizes, com base na ideia de redundância e modelos de ameaças a cabos submarinos, os CSPs podem obter uma certificação como CSP recomendado. Em troca, as empresas poderiam pagar um seguro contra interrupções subsidiado pelo governo. O governo cobriria os danos resultantes de interrupções catastróficas como desastres naturais e ataques terroristas, mas os CSPs ainda teriam que pagar por danos de causas comuns, como erro humano. Mais pesquisas sobre as desvantagens potenciais de tal arranjo são necessárias, como seus efeitos potenciais no mercado de nuvem. Outras ideias incluem governos identificando um único ponto de contato para questões de cabos submarinos e para os Estados Unidos ratificarem a Convenção das Nações Unidas para o Direito do Mar (UNCLOS) para alinhar sua posição legal com a de seus aliados.

Governo na nuvem: outra área que merece mais pesquisas dedicadas é como os governos usam CSPs comerciais. Um número crescente de governos empreendeu esforços para mover as operações de algumas agências governamentais para a nuvem. O governo dos EUA, por exemplo, adotou sua primeira política de nuvem em 2010, e o governo do Reino Unido o fez em 2013. ¹⁴¹ Em 2019, o governo dos EUA renovou seu compromisso com sua política atualizada de “nuvem inteligente”. ¹⁴² Um relatório de 2019 do Government Accountability Office (GAO) concluiu que as agências federais fizeram progresso na adoção da nuvem e que quinze das dezesseis agências examinadas identificaram benefícios significativos na aquisição de serviços em nuvem. ¹⁴³ Essa transição levanta algumas questões exclusivas para dados e operações do governo, como como proteger dados confidenciais ou classificados ou como melhor cumprir os requisitos legislativos de aquisição.

O Plano de Gerenciamento de Autorização e Risco Federal dos Estados Unidos (FedRAMP) é um programa de certificação de CSPs para servir a agências federais. ¹⁴⁴ Ele define os requisitos básicos de autorização de segurança para que os CSPs sejam certificados por uma Junta de Autorização Conjunta (composta por especialistas dos Departamentos de Defesa e Segurança Interna e da Administração de Serviços Gerais) ou agências específicas. O governo do Reino Unido desenvolveu um fórum semelhante denominado estrutura G-Cloud. ¹⁴⁵ Outros países, como Austrália, Alemanha e Cingapura, todos migraram algumas operações para serviços em nuvem. ¹⁴⁶

Nos Estados Unidos, o Congresso também incentivou a adoção da nuvem por agências federais por meio de legislação, como a Lei de Reforma da Aquisição de Tecnologia da Informação Federal de 2014, que visava explicitamente a migração para a nuvem. Agora há mais foco na supervisão da adoção federal da nuvem, incluindo um relatório do Serviço de Pesquisa do Congresso de março de 2020 que identificou várias outras opções para o Congresso. ¹⁴⁷ Estas incluíram a realização de audiências centradas no Gabinete de Gestão e Orçamento, que supervisiona a gestão da política Cloud Smart; revisar planos de nuvem de agências individuais e avaliações de implementação; e incumbir o GAO de avaliar o progresso das agências.

Os CSPs responderam ao interesse do governo oferecendo serviços especializados adequados às necessidades específicas do governo. Nos Estados Unidos, a AWS e o Microsoft Azure oferecem a nuvem do governo para agências federais, estaduais e locais, separadamente de seus serviços comerciais. Essas ofertas até mesmo se adaptaram para atender aos requisitos de dados e operações relacionados à segurança nacional. Por exemplo, em 2013, a Central Intelligence Agency (CIA) contratou a AWS para fornecer serviços à comunidade de inteligência dos EUA por meio de uma nuvem privada construída pela AWS. ¹⁴⁸

Mais pesquisas são necessárias para avaliar as vantagens e desvantagens da política de emprego de serviços em nuvem para agências governamentais e dados. Para os Estados Unidos, avaliar a eficácia do programa FedRAMP e quaisquer requisitos legislativos adicionais em potencial para segurança em nuvem é uma área importante para estudos futuros.

O contrato JEDI: Uma grande tendência em segurança em nuvem nos últimos anos tem sido uma mudança em direção a vários fornecedores de nuvem para funções diferentes, em vez de um único fornecedor cumprindo todos os serviços de nuvem de uma organização. Em uma pesquisa de maio de 2019 com profissionais de tecnologia de negócios, quase 70% disseram que já estão ou planejam usar vários provedores de nuvem. ¹⁴⁹ Outra pesquisa, o relatório Flexera 2020 State of the Cloud , descobriu que 93 por cento dos entrevistados tinham uma estratégia multicloud. ¹⁵⁰ Os proponentes argumentam que essa abordagem traz benefícios, como evitar o aprisionamento do fornecedor, aumentar a resiliência a interrupções e tirar proveito de preços competitivos. ¹⁵¹No entanto, cada um desses pontos é contestado – por exemplo, alguns podem argumentar que garantir que a arquitetura de infraestrutura de um CSP seja segura é uma maneira muito melhor de aumentar a resiliência do que replicar cargas de trabalho em vários CSPs. No entanto, o apelo de arranjos multicloud está claramente crescendo.

No entanto, o uso de vários provedores de nuvem pode criar maior complexidade para as organizações em termos de gerenciamento do uso da nuvem e criação de mais pontos potenciais de vulnerabilidade, como a Cloud Security Alliance discutiu em um relatório de maio de 2019. ¹⁵² Este relatório também observou que, além de usar vários provedores de nuvem, muitas organizações também estão usando uma combinação de ofertas de nuvem privada e pública, aumentando a complexidade de seus respectivos ambientes de nuvem.

A controvérsia sobre o contrato de nuvem do Pentágono para JEDI fornece um estudo de caso ilustrativo sobre os benefícios e as desvantagens potenciais de estratégias de nuvem única versus multicloud. Este projeto pretendia dar o pontapé inicial na migração do Pentágono para serviços de nuvem pública para conectar e dar suporte aos ambientes de TI das forças armadas dos EUA. O contrato para este projeto foi amplamente antecipado devido ao enorme tamanho do Departamento de Defesa. Em julho de 2018, o Pentágono anunciou que o contrato teria um teto de US $ 10 bilhões em dez anos e seria oferecido a apenas um único fornecedor. ¹⁵³

Um funcionário do Pentágono mencionou o seguinte como um dos principais motivos pelos quais o contrato foi escrito para um único fornecedor: “A falta de padronização e interoperabilidade hoje cria barreiras muito significativas para acessar nossos dados onde e quando for necessário, especialmente no limite tático do campo de batalha. . . . Acreditamos que a nuvem de vários prêmios aumentaria exponencialmente a complexidade geral. ” ¹⁵⁴

Em meio a disputas entre os CSPs sobre o contrato, os concorrentes do suposto favorito, AWS, argumentaram contra uma única decisão de nuvem. A Oracle chegou a entrar com uma ação judicial que em parte se apoiava no argumento de que uma única nuvem não atenderia aos melhores interesses do Departamento de Defesa. ¹⁵⁵ Especialistas intimamente ligados a empreiteiros de defesa e liderança do Pentágono argumentaram em resposta que adotar uma estratégia multicloud para JEDI seria simplesmente muito complexo para uma burocracia tão grande como a do Pentágono lidar. ¹⁵⁶No futuro, os contratos de nuvem do governo dos EUA provavelmente tenderão para multicloud, já que esta é a direção em que muitas organizações maiores estão se movendo. A CIA disse em abril de 2019 que está planejando dar continuidade ao seu contrato inicial de nuvem de inteligência com uma nova aquisição para multicloud serviços que serão da ordem de “dezenas de bilhões de dólares”. ¹⁵⁷

O status do contrato JEDI está atualmente em dúvida devido a ações judiciais e preocupações com motivações políticas, em meio à percepção de que o presidente dos EUA, Donald Trump, pode ter impactado a decisão do governo sobre qual fornecedor usar: Microsoft Azure ou AWS. Embora esse atraso possa ter um impacto adverso na segurança nacional, ele fornece mais tempo para avaliar os custos e benefícios das abordagens de uma única contra várias nuvens. Essa questão é particularmente aguda para os governos que estão considerando mover agências e dados importantes para a nuvem, pois ela toca em muitas das questões sobre segurança e resiliência levantadas pelo exemplo JEDI. Um estudo mais aprofundado pode abordar formas potenciais para os processos de compras governamentais serem modificados para melhor capturar os riscos e benefícios de decidir por uma abordagem única versus uma abordagem multicloud,

APÊNDICE A: INCIDENTES NOTÁVEIS RELACIONADOS À NUVEM

O apêndice a seguir contém breves relatos de oito incidentes principais relacionados à nuvem e suas implicações de segurança.

CASO 1: INTERRUPÇÃO DA COSTA LESTE DA AMAZON WEB SERVICES EM FEVEREIRO DE 2017

Na manhã de 28 de fevereiro de 2017, um engenheiro da Amazon Web Services (AWS) inseriu um comando para remover parte da capacidade de armazenamento do sistema de faturamento do Simple Storage Service da AWS. Um erro de digitação removeu inadvertidamente mais capacidade de armazenamento do que o pretendido. ¹⁵⁸ Os servidores removidos forneciam suporte a dois sistemas internos críticos do Simple Storage Service: um sistema de indexação e um sistema que alocava novo armazenamento quando os clientes executavam uma solicitação para armazenar um novo objeto. Esse erro fez com que todo o sistema do Simple Storage Service nesta região, US-EAST-1 – uma das maiores e mais importantes regiões da AWS – ficasse indisponível para processar solicitações. ¹⁵⁹

Por sua vez, a interrupção do Simple Storage Service afetou outros serviços da AWS, como novas instâncias em seu serviço de computação, Elastic Compute Cloud, volumes de Elastic Block Store e AWS Lambda. Os engenheiros da AWS levaram mais de quatro horas para restaurar o Simple Storage Service para o serviço completo. No entanto, durante esse ínterim, outro serviço da Amazon que caiu foi o AWS Service Health Dashboard, que é como as atualizações de status do serviço geralmente são fornecidas. ¹⁶⁰

Os clientes afetados incluíam uma longa lista de empresas e organizações, incluindo Adobe, Airbnb, Coursera, Docker, Expedia, GitHub, Imgur, Medium, Pinterest, Quora, Signal, Slack, Trello e US Securities and Exchange Commission (SEC). ¹⁶¹ Portanto, pode-se inferir que todas essas empresas e organizações tinham alguns de seus sistemas contando com serviços da AWS baseados exclusivamente na região US-EAST-1 (localizada no norte da Virgínia). Em contraste, o Guardian observou que não sofreu uma interrupção porque depende da região da AWS com base na Irlanda. ¹⁶²Mesmo as empresas que mantêm dispositivos IoT (como sistemas de iluminação doméstica) sofreram interrupções, o que significa que alguns clientes não conseguiram ligar as luzes em suas casas por causa das interrupções. Cyence, uma empresa que modela o risco cibernético, divulgou uma estimativa de que as empresas S&P 500 perderam US $ 150 milhões, um valor que não inclui os impactos de segunda ordem da interrupção. ¹⁶³

O Simple Storage Service é um serviço central da AWS do qual muitos clientes dependem – uma empresa estima que mais de 250.000 (em agosto de 2020) domínios exclusivos dependem dele. ¹⁶⁴ AWS promete uma disponibilidade de 99,99 por cento para Simple Storage Service, o que se traduz em cinquenta e três minutos de tempo de inatividade todos os anos (cálculos dos autores) e que só essa interrupção excedeu em cerca de três horas. ¹⁶⁵

CASO 2: INTERRUPÇÃO DO MICROSOFT AZURE EM SETEMBRO DE 2018

Em 4 de setembro de 2018, tempestades matinais em San Antonio, Texas, levaram a quedas de raios que causaram quedas de tensão e picos em suprimentos de serviços públicos para um data center Microsoft Azure em sua região centro-sul dos EUA. O data center mudou sua fonte de alimentação para um gerador. Os picos de tensão também causaram o desligamento dos sistemas de resfriamento do data center. Pouco tempo depois, um desligamento automático dos dispositivos no data center foi iniciado em resposta ao aumento da temperatura. Embora esse mecanismo de desligamento seja projetado para preservar a integridade dos servidores Microsoft Azure e dos dados neles contidos, algumas máquinas foram danificadas porque as temperaturas aumentaram tão rapidamente que não puderam ser desligadas a tempo. ¹⁶⁶

Conforme descrito no relatório pós-incidente do Azure, os engenheiros da Microsoft primeiro procuraram recuperar um componente crítico: os balanceadores de carga de software do Azure para suas unidades de escala de armazenamento. Esses componentes gerenciam a alocação de novo armazenamento e rede interna, bem como o roteamento de dados do cliente. A próxima parte da recuperação envolveu a substituição de componentes com falha no data center. Os engenheiros da Microsoft decidiram tentar recuperar todos os dados do cliente no data center afetado e não “fazer failover”, o que envolve o recurso a backup de dados em outro data center; eles evitaram essa opção porque, ao fazer isso, alguns dados seriam perdidos porque os dados foram replicados de forma assíncrona, de acordo com o relatório. ¹⁶⁷ Como a replicação de dados em diferentes áreas geográficas ocorre em intervalos de tempo definidos, os dados acumulados no datacenter South Central após a replicação anterior teriam sido perdidos.

A falha neste data center afetou os serviços do Microsoft Azure primeiro na região Centro-Sul dos EUA – e quase todos os serviços do Azure para clientes que localizaram dados estavam offline. No entanto, a falha teve um impacto global por causa de seus efeitos em um sistema de gerenciamento herdado para tipos mais antigos de recursos do Azure, chamado de Azure Service Manager. Esse sistema armazenava seus metadados principalmente na região Centro-Sul dos EUA, e a falha ali causou atrasos até que os servidores Centro-Sul voltassem a ficar online no início da tarde de 5 de setembro.

Em resposta, a Microsoft disse que revisaria as dependências associadas ao Azure Service Manager e moveria esses serviços para um sistema mais recente, o Azure Resource Manager, que armazena dados em todas as regiões do Azure para resiliência global. Outro sistema importante afetado foi o Azure Active Directory, que é um serviço de autenticação essencial para muitos outros serviços do Azure. Os relatos da imprensa indicaram que, apesar das afirmações da Microsoft, havia problemas com os serviços de nuvem da empresa em todo o mundo. ^{168 A} Microsoft disse em uma postagem de blog que um dos motivos pelos quais o incidente teve impactos globais foi porque afetou serviços “globais” como o Azure Active Directory que, por sua vez, afetou outros sistemas. ¹⁶⁹

Um dos principais problemas que esse incidente destacou foi a distribuição de dados dentro das regiões. No momento do incidente, o Microsoft Azure introduziu apenas zonas de disponibilidade (AZs) em três de suas 54 regiões e não introduziu nenhuma na região Centro-Sul dos EUA. ¹⁷⁰ AZs são data centers diferentes dentro da mesma região que fornecem resiliência para dados na região. O Microsoft Azure sofreu falhas devido a fatores ambientais em vários outros incidentes, principalmente por causa da umidade na Irlanda e, relacionado, a liberação acidental de sistemas de supressão de incêndio em um data center no Norte da Europa em 2017. ¹⁷¹

CASO 3: INTERRUPÇÃO DO GOOGLE CLOUD EM NOVEMBRO DE 2018

Na noite de 12 de novembro de 2018, o tráfego do Google Cloud sofreu problemas de conectividade e seus serviços não estavam disponíveis para muitos clientes. ¹⁷² A análise da rede apontou para um provedor de serviços de Internet na Nigéria que, no momento em que o incidente começou, atualizou seus endereços de rede para o protocolo que determina como o tráfego da Internet é roteado, o Border Gateway Protocol (BGP), para dizer que sua rede era a melhor caminho para chegar a um conjunto de endereços IP de propriedade do Google. Então, a China Telecom, um grande provedor de serviços de Internet na China que recentemente havia sido dito que redirecionava o tráfego de Internet dos EUA através da China, aceitou indevidamente a rota, fazendo com que outros provedores de rede listassem a rota como correta. ¹⁷³O erro foi supostamente devido a um erro de configuração com a filtragem BGP do provedor de serviços de Internet da Nigéria. ^{174 O} Google também disse que a “causa raiz do problema era externa ao Google”. ¹⁷⁵

Este incidente destacou que os principais CSPs dependem da ampla disponibilidade de roteamento da Internet, assim como outros grandes serviços da Internet, e essas falhas podem acontecer como parte de problemas de rede mais amplos. No entanto, como os principais CSPs têm uma concentração de serviços e infraestrutura localizada em um conjunto específico de endereços IP, as falhas que afetam esse conjunto de endereços têm um impacto exagerado na resiliência mais ampla da Internet. O BGP, em particular, é um ponto de vulnerabilidade de longa data na arquitetura da Internet e que outros CSPs sofreram. Em abril de 2018, os invasores sequestraram o roteamento BGP para redirecionar os endereços do Sistema de Nomes de Domínio (DNS) que faziam parte da Route 53 da Amazon (sua oferta de DNS em nuvem) para roubar criptomoedas. ¹⁷⁶

CASO 4: EXCLUSÃO DO MICROSOFT AZURE SQL EM JANEIRO DE 2019

Em 29 de janeiro de 2019, de acordo com relatos da mídia, o incidente começou com um problema aparentemente global para clientes que tentavam autenticar e acessar suas contas do Microsoft Azure e Office 365, um problema que parecia atingir a Austrália e a Nova Zelândia de maneira particularmente difícil. ¹⁷⁷ De acordo com relatos de jornalistas sobre o relatório de status do Microsoft Azure, “Um provedor de serviços DNS externo [relata a CenturyLink] experimentou uma interrupção global após lançar uma atualização de software que expôs um problema de corrupção de dados em seus servidores primários e afetou seus servidores secundários, afetando tráfego de rede.” ¹⁷⁸Isso, por sua vez, afetou o Azure Active Directory, que permite que os usuários se autentiquem no DNS do Azure e em outros serviços do Azure. A partir disso, os bancos de dados SQL que usaram uma configuração específica para Transparent Data Encryption (TDE), ou seja, Key Vaults do cliente, foram afetados. De acordo com contas de mídia de declarações fornecidas aos clientes do Azure, “um processo automatizado, projetado para ser acionado quando as chaves personalizadas são removidas do KeyVault, inadvertidamente fez com que esses bancos de dados TDE fossem descartados”. ¹⁷⁹ Basicamente, determinados bancos de dados SQL foram excluídos devido a um processo iniciado pela falha de autenticação.

Em resposta, o Microsoft Azure teria dito: “Estamos restaurando uma cópia desses bancos de dados SQL a partir de um ponto de recuperação em menos de 5 minutos antes do banco de dados ser descartado. Esses bancos de dados restaurados. . . estão localizados no mesmo servidor que o banco de dados original. ” ¹⁸⁰ De acordo com relatos de jornalistas, a empresa também perguntou aos clientes, “para cada banco de dados, [para] identificar se as transações perdidas, durante este período de 5 minutos, poderiam afetar os processos de negócios ou aplicativos fora do banco de dados”. ¹⁸¹Pedir aos clientes que verifiquem se a perda de dados pode ter um efeito significativo em seus negócios é um verdadeiro pesadelo para um CSP. De acordo com as contas de mídia da resposta do Azure, ele mudou para um provedor DNS diferente. Segundo consta, seus engenheiros também recuperaram todos os bancos de dados SQL relevantes que foram excluídos. ¹⁸²

CASO 5: MARÇO DE 2019 AJUSTE DO SERVIDOR DO FACEBOOK

Em 13 de março de 2019, o Facebook e vários de seus aplicativos principais – Instagram, Messenger e WhatsApp – começaram a ter problemas no meio da manhã para usuários em todo o mundo. ^{183 Os} serviços do Facebook ficaram inativos para uma grande quantidade de usuários ao redor do globo, com interrupções concentradas na costa leste dos Estados Unidos e no Reino Unido, por quatorze horas, uma das interrupções mais longas da história da empresa. A empresa não emitiu um comunicado completo, mas disse no Twitter que a interrupção foi devido a uma “mudança na configuração do servidor”. ¹⁸⁴Ele também esclareceu que a interrupção não foi causada por um ataque distribuído de negação de serviço (DDoS). O Facebook depende de sua própria infraestrutura privada em vez de um CSP, e um ponto interessante é que os serviços do WhatsApp, que antes dependiam do IBM Cloud, também foram interrompidos, sugerindo que o Facebook havia concluído a migração do aplicativo para sua própria infraestrutura. ¹⁸⁵

Uma mudança na configuração do servidor aponta para o que é provavelmente um cenário semelhante à interrupção do AWS US-EAST-1 de 2017: um erro interno que causou uma onda de problemas em cascata levando a uma interrupção conforme os sistemas eram depurados e reiniciados. A localização inicial dos problemas, a costa leste dos EUA, também sugere um problema relacionado à infraestrutura, pois é onde muitos dos principais data centers estão localizados. E a análise de rede sugeriu que não era um problema de rede. ¹⁸⁶

Embora a interrupção da AWS possa ser um exemplo melhor desse tipo de interrupção porque há mais detalhes técnicos disponíveis sobre ela, a do Facebook também fornece um estudo de caso de impacto. Uma vez que o Facebook agora integra uma série de serviços (o aplicativo principal, WhatsApp, Instagram e outros) em uma plataforma, a interrupção interrompeu as experiências do usuário em toda a linha – um fenômeno semelhante ao que uma falha de infraestrutura em um CSP importante faria, ou mesmo apenas uma falha para um grande cliente semelhante ao Facebook.

CASO 6: A RESPOSTA ÀS VULNERABILIDADES DE FUSÃO E ESPECTRO

Em janeiro de 2018, duas vulnerabilidades importantes em chips de computação chamados Meltdown e Spectre tornaram-se publicamente conhecidas. Essa descoberta teve implicações importantes para os CSPs porque seus data centers estavam entre os mais vulneráveis a essas falhas. Várias equipes independentes de pesquisadores, incluindo uma da equipe de pesquisa de vulnerabilidade do Google, Project Zero, descobriram as vulnerabilidades na mesma época ou logo após a outra, em meados de 2017. ¹⁸⁷ Esforços coordenados para erradicar e corrigir as várias maneiras pelas quais essas vulnerabilidades se manifestaram estão em andamento.

A primeira vulnerabilidade, Meltdown, afeta as unidades de processamento central (CPUs) – os chips de hardware que executam os computadores – para permitir que um invasor leia informações privilegiadas que deveriam ser visíveis apenas para o sistema operacional da CPU. ¹⁸⁸ Ele faz isso explorando a maneira como os chips modernos processam as instruções, executando operações futuras com antecedência. A vulnerabilidade é que as informações sobre essas etapas são armazenadas no cache de memória do chip, acessível a um invasor. Os invasores podem então ler os segredos de outros programas e usuários no mesmo chip, permitindo-lhes roubar informações como senhas e informações protegidas. De acordo com uma página oficial de recursos, o Meltdown afeta “potencialmente” os chips da Intel desde 1995. ¹⁸⁹

A segunda vulnerabilidade, Spectre, afeta quase todos os chips fabricados nos últimos vinte anos, não apenas os da Intel, mas também os da ARM (uma empresa anteriormente conhecida como Advanced RISC Machine) e Advanced Micro Devices (AMD). ¹⁹⁰ Como o Meltdown, o Spectre também explora o processo de execução especulativa para descobrir segredos dentro do mesmo programa, e é mais complexo de executar. ¹⁹¹ No entanto, isso envolve uma falha fundamental na arquitetura de segurança, o que significa que os invasores podem ler informações confidenciais sobre as ofertas de software como serviço (SaaS) dos CSPs e pular de aplicativo em aplicativo. Outra varianteof Spectre permite que os invasores leiam informações em quase todas as barreiras de isolamento, até mesmo permitindo que eles leiam informações em máquinas virtuais e de hipervisores, outra grande vulnerabilidade da arquitetura CSP. ¹⁹²

Como consequência, essas duas vulnerabilidades tiveram grandes implicações para os CSPs, bem como para a infraestrutura de TI em grande escala. Ambos envolvem vulnerabilidades de hardware e, embora tenha havido atualizações de software que podem ajudar a resolver o Meltdown, consertar a vulnerabilidade Spectre envolveu substituir e rearquitetar o hardware do computador em muitos casos. Essas vulnerabilidades criaram sérias preocupações para a segurança dos CSPs, já que essas deficiências podem ter permitido que os clientes compartilhando o mesmo hardware físico roubassem os segredos uns dos outros. ¹⁹³ Mas ainda não há nenhuma instância documentada de exploração de Meltdown e Spectre em estado selvagem, e os CSPs tomaram medidas para responder e mitigar quaisquer ameaças potenciais.

A forma como os pesquisadores, fabricantes de chips e os principais CSPs se coordenam para lidar com essas vulnerabilidades é um exemplo importante de algumas das barreiras para uma cooperação de segurança bem-sucedida para lidar com grandes incidentes no espaço da nuvem. Os pesquisadores do Projeto Zero alertaram a fabricante de chips Intel e outras sobre as vulnerabilidades em 1º de junho de 2017 – cerca de seis meses antes de se tornarem públicas em janeiro de 2018. ¹⁹⁴Reportagens da imprensa disseram que a Intel trabalhou com outros fabricantes de chips, bem como um consórcio de empresas de tecnologia, incluindo Amazon, Google (que hospedava o Project Zero) e Microsoft, mas não forneceu um aviso para empresas menores de serviços em nuvem, que disseram ter sido pego de surpresa por o lançamento de janeiro. Além disso, outros relatos da imprensa indicaram que a Intel notificou não apenas os principais CSPs dos EUA, mas também empresas de tecnologia chinesas, incluindo Alibaba e Lenovo. ¹⁹⁵Isso é notável porque não havia notificado as principais agências governamentais dos EUA, incluindo o Departamento de Segurança Interna, quando as vulnerabilidades se tornaram públicas. Outro relatório disse que a Intel não notificou nem mesmo a Equipe de Prontidão de Emergência de Computadores (CERT) dos EUA, que emitiu um comunicado aconselhando a remoção completa dos processadores afetados e que mais tarde teve que revisar para aconselhar apenas consertar o equipamento. ¹⁹⁶ A NSA negou ter explorado as vulnerabilidades. ¹⁹⁷

Uma audiência convocada pelo Comitê de Comércio, Ciência e Transporte do Senado dos Estados Unidos abordou essas questões em julho de 2018, quando analisou a resposta à divulgação de Meltdown e Specter. ¹⁹⁸ Em sua declaração majoritária, o senador John Thune disse que os investigadores do Congresso confirmaram que “alguns fabricantes chineses, incluindo a Huawei, foram informados da vulnerabilidade antes da divulgação pública”. ¹⁹⁹Ele também observou que, “apenas uma empresa – IBM – informou que entrou em contato com o governo dos Estados Unidos antes de 3 de janeiro de 2018, divulgação pública.” As testemunhas não forneceram mais informações, mas uma testemunha (Art Manion) da US-CERT delineou um processo de notificação de vulnerabilidade em três etapas que idealmente deve ser implementado: os primeiros a serem notificados seriam os fabricantes de chips, seguidos pelos fornecedores de sistemas operacionais, e então os provedores de infraestrutura de internet e CSPs seriam informados em terceiro lugar, junto com os defensores da segurança cibernética como o US-CERT.

Outro grande problema é que as correções para as vulnerabilidades podem ter efeitos negativos no desempenho. Alguns dos patches iniciais causaram instabilidade nos sistemas operacionais, fazendo com que a Microsoft interrompesse o lançamento de patches para alguns chips AMD. ²⁰⁰ Considerando que a vulnerabilidade do Spectre era uma falha no design fundamental e no processo operacional, alguns patches para chips mais antigos vieram com o que os observadores iniciais disseram ser uma redução notável no desempenho. ²⁰¹ No entanto, relatórios posteriores contestaram que os patches trouxeram qualquer mudança significativa no desempenho dos chips afetados. ²⁰² Responder a Meltdown e Spectre tem sido um esforço de longo prazo. Em novembro de 2018, os pesquisadores lançaram sete novas variantes dos exploits que descobriram.^{203 A} Intel montou uma equipe de especialistas técnicos para gerenciar essa resposta contínua, ²⁰⁴ que ainda parece estar em operação.

CASO 7: VIOLAÇÃO DE DADOS CAPITAL ONE DE JULHO DE 2019

Em 19 de julho de 2019, a Capital One descobriu que um hacker havia violado seus dados de clientes e indivíduos que haviam solicitado cartões de crédito da Capital One. ²⁰⁵ Isso envolveu a informação de aproximadamente 100 milhões de pessoas nos Estados Unidos, embora apenas uma pequena fração (menos de 1 por cento) das pessoas tiveram seus números do Seguro Social roubados. A Capital One disse que descobriu a violação depois que um pesquisador externo a contatou por meio de seu programa de divulgação responsável. ²⁰⁶ Os dados roubados foram aparentemente armazenados em servidores de nuvem pública AWS usados pela Capital One.

Logo depois disso, promotores federais em Seattle anunciaram a prisão de Paige Thompson, ex-engenheira de uma empresa de tecnologia de Seattle (presumivelmente AWS), que foi acusada de hackear o Capital One. ²⁰⁷ De acordo com a queixa criminal registrada, Thompson postou no GitHub sobre o hack do Capital One, bem como dados que ela roubou, que a queixa detalha como “por meio de um firewall de aplicativo da web mal configurado” (palavras do promotor). ²⁰⁸O pesquisador que notificou a Capital One viu esta postagem e notificou a empresa, enquanto a Capital One notificou as autoridades. De acordo com a queixa criminal, uma investigação policial em colaboração com a Capital One descobriu que a violação datava de março de 2019 e também descobriu que pode ter havido alvos adicionais “de tentativas ou invasões de rede reais”. ²⁰⁹

Vários analistas levantaram a questão de que, como ex-funcionária da AWS, Thompson provavelmente usou seu conhecimento dos serviços e segurança da AWS para obter acesso por meio do aplicativo da Web da Capital One. ²¹⁰ No entanto, a intrusão de Thompson não foi especialmente tecnicamente complexa e não teria exigido conhecimento interno especializado para ser executada.

Capital One fez uma mudança altamente pública para a nuvem, como a primeira instituição financeira a anunciar sua intenção de mover todos os serviços para a nuvem até 2020 e como uma das primeiras grandes empresas, ponto, a se comprometer totalmente com um modelo baseado em nuvem . Seu próprio CEO disse que ela era uma das empresas “mais avançadas na nuvem” do mundo no início de 2019. ²¹¹ Após a violação, muitos investidores, seguradoras e especialistas em negócios questionaram a sabedoria dessa decisão e destacaram a segurança problemas com AWS. ²¹²E legisladores também se envolveram, já que os republicanos do Comitê de Supervisão da Câmara enviaram cartas pedindo mais informações tanto da Capital One quanto da Amazon, levantando a possibilidade de que o incidente pudesse lançar dúvidas sobre a conveniência de conceder à AWS o contrato principal de nuvem do Pentágono. ²¹³ Os senadores democratas Elizabeth Warren e Ron Wyden também enviaram cartas à Capital One e à AWS, respectivamente, pedindo mais informações sobre a responsabilidade das empresas pela violação. ²¹⁴

Um porta-voz da AWS tentou rebater a narrativa de que sua mudança para a nuvem o tornou vulnerável, parafraseando a declaração da Capital One para dizer: “este tipo de vulnerabilidade não é específico para a nuvem”. A AWS também disse que “não foi comprometido de forma alguma”. ²¹⁵

A AWS afirmou que a segurança do sistema que permitiu a violação (um aplicativo da Web da Capital One) era de responsabilidade total da Capital One, assim como o gerenciamento de identidade e acesso para os dados armazenados em sua nuvem. A Capital One não contestou isso publicamente até julho de 2020. Especialistas em segurança disseram que é provável que a configuração incorreta do firewall seja na verdade um tipo de vulnerabilidade chamada de falsificação de solicitação do lado do servidor (SSRF). Um SSRF permite que um invasor se comunique com um servidor e obtenha metadados ou credenciais para acessar bancos de dados internos. O jornalista Brian Krebs discutiu como essa vulnerabilidade foi usada para manipular primeiro o serviço de metadados da AWS e, em seguida, obter acesso à instância da AWS onde os dados do Capital One foram armazenados. ²¹⁶

Esta vulnerabilidade é bem conhecida e, embora não seja específica da nuvem, foi citada como uma ameaça particular para clientes de nuvem pública, e alguns analistas já haviam solicitado que a AWS implementasse um cabeçalho de segurança ou fizesse outras modificações para se defender contra ele . ²¹⁷ Em novembro de 2019, a AWS disse que atualizou seu serviço de acesso a metadados para fornecer “defesa em profundidade contra acesso não autorizado a metadados”. ²¹⁸

CASO 8: OPERAÇÃO CLOUD HOPPER

Em dezembro de 2018, o Departamento de Justiça dos Estados Unidos revelou uma acusação que acusava dois hackers chineses de conduzirem uma campanha de furto cibernético de propriedade intelectual e segredos comerciais confidenciais de dezenas de empresas e governos em todo o mundo. Os dois hackers, Zhu Hua e Zhang Shilong, foram acusados de trabalhar em nome de uma filial provincial do Ministério de Segurança do Estado da China. ²¹⁹Sua organização de hackers, conhecida na comunidade de segurança como Advanced Persistent Threat 10 (APT10), foi capaz de comprometer muitas corporações porque visou um conjunto de empresas de TI que forneciam serviços de nuvem gerenciados para as empresas. Essa abordagem permitiu que os hackers roubassem segredos dos clientes por meio dos CSPs comprometidos. Esta campanha decorreu aproximadamente de 2014 a 2018 e foi denominada Operação Cloud Hopper. ²²⁰

Outras reportagens da imprensa, bem como um estudo conjunto de abril de 2017 pela PwC e BAE Systems que foi divulgado antes da acusação, forneceram mais informações sobre a extensão das intrusões, bem como os detalhes técnicos dos compromissos. De acordo com um relatório da Reuters de junho de 2019, os hackers chineses comprometeram oito dos maiores provedores de serviços de tecnologia do mundo, incluindo Computer Sciences Corporation, Dimension Data, Fujitsu, Hewlett Packard Enterprise, IBM, NTT Data, Tata Consultancy Services e DXC Technology – Hewlett Packard O braço de serviços da Enterprise que se tornou uma entidade corporativa separada em 2017. ²²¹ Esses provedores oferecem serviços a uma vasta gama de clientes em todo o mundo, incluindo Allianz SE; Banco alemão; GlaxoSmithKline; Philipps, o gigante da saúde; e Rio Tinto, a empresa de mineração.²²² A acusação de 2018 se referia a pelo menos quinze grandes empresas comprometidas nesta campanha. É concebível que o APT10 possa ter tido a oportunidade de se infiltrar nos sistemas de outras empresas (incluindo algumas das empresas mencionadas), embora poucos detalhes concretos sejam conhecidos publicamente com certeza. Vários clientes foram comprometidos, incluindo Ericsson, a gigante sueca de telecomunicações; Huntington Ingalls, o principal construtor de navios da Marinha dos Estados Unidos; e Sabre, um serviço de reservas de viagens nos EUA. ²²³

As empresas de TI comprometidas forneceram algo chamado de serviço de nuvem gerenciado e são conhecidas como provedores de serviços gerenciados (MSPs). Essas empresas operam tanto a infraestrutura de computação em nuvem quanto os aplicativos e ferramentas de sobreposição executados na infraestrutura e, em seguida, vendem aos clientes um serviço de TI completo baseado em nuvem. ²²⁴Isso permite que grandes corporações não tenham que construir seus próprios aplicativos para rodar em serviços em nuvem. Na Operação Cloud Hopper, o APT10 obteve acesso aos sistemas dos MSPs por meio de um padrão de ataque comum, primeiro enviando e-mails de spear phishing que entregam malware e se estabelecendo em seus sistemas e, em seguida, avançando para obter mais acesso e se infiltrar nas redes dos clientes. O relatório PwC / BAE observou que o APT10 se concentrava especialmente na infraestrutura compartilhada entre MSPs e seus clientes; o comprometimento desses sistemas facilitou a movimentação de dados direcionados de clientes por meio dos MSPs e de volta para os hackers. ²²⁵ Como um relatório posterior revelou, como essa infraestrutura também costumava atender a vários clientes simultaneamente, essas táticas facilitaram a natureza abrangente da campanha de intrusão.²²⁶

Este relatório também expôs as dificuldades de responder a uma campanha dedicada e persistente de um grupo de hackers vinculado ao estado. De acordo com o relatório da Reuters de 2019, a administração da Hewlett Packard Enterprise foi reticente em permitir que sua equipe de segurança tenha acesso total para combater os hackers e supostamente procurou limitar o conhecimento fornecido a clientes comprometidos como o Sabre. ²²⁷ Um motivo para isso poderia ser a tentativa de evitar perdas de confiança na segurança dos MSPs em todo o setor. No entanto, mesmo as autoridades federais que investigam as violações notaram essa reticência em compartilhar informações, sugerindo que esse problema não se limita à divulgação pública de compromissos.

SOBRE OS AUTORES

Tim Maurer é codiretor da Cyber Policy Initiative e membro sênior da Carnegie Endowment for International Peace. Em 2018, a Cambridge University Press publicou seu livro Cyber Mercenaries: the State, Hackers and Power .

Garrett Hinck é um estudante de doutorado na Columbia University. Anteriormente, ele foi assistente de pesquisa da Cyber Policy Initiative no Carnegie Endowment for International Peace.

AGRADECIMENTOS

Os autores desejam agradecer as contribuições inestimáveis de seus atuais e ex-colegas da Carnegie’s Cyber Policy Initiative, incluindo Ariel Levite, Arthur Nelson, Evan Burke, George Perkovich, Jon Bateman, Natalie Thompson, Ronit Langer e Wyatt Hoffman. Além disso, minha gratidão vai para Trey Herr e vários outros especialistas do setor, bem como agências governamentais e regulatórias, que desejam permanecer anônimos por suas percepções, sugestões e comentários pendentes sobre os rascunhos deste documento. O conteúdo do artigo é de responsabilidade exclusiva dos autores e não representa necessariamente a opinião de quaisquer outros indivíduos ou instituições.

ABREVIAÇÕES

AMD: Micro Dispositivos Avançados

ARM: uma empresa de fabricação de chips anteriormente conhecida como Advanced RISC Machine

API (s): interface (s) de programação de aplicativo

AWS: Amazon Web Services

AZ (s): zona (s) de disponibilidade

BGP: protocolo de gateway de fronteira

BPaaS: processo de negócios como serviço

CERT: (EUA) Equipe de Preparação para Emergências em Computadores

CIA: (U.S.) Central Intelligence Agency

CIA framewor: a estrutura de confidencialidade, integridade e disponibilidade

CISO: diretor de segurança da informação

Lei CLOUD: Lei para esclarecimento do uso legal de dados no exterior

CPU (s): unidade (s) central (is) de processamento

CSP (s): provedor (es) de serviços em nuvem

DDOS: negação de serviço distribuída (ataques cibernéticos)

DNS: sistema de nomes de domínio

EU: European Union

FedRAMP: Plano Federal de Gestão de Risco e Autorização

GAO: (US) Government Accountability Office

GDPR: (EU) General Data Protection Regulation

IaaS: infraestrutura como serviço

IoT: Internet das coisas

TI: tecnologia da informação

JEDI: (EUA) Joint Enterprise Defense Infrastructure

MSP (s): provedor (es) de serviços gerenciados

NASA: (EUA) Administração Nacional de Aeronáutica e Espaço

NIST: Instituto Nacional de Padrões e Tecnologia (EUA)

OPEP: Organização dos Países Exportadores de Petróleo

PaaS: plataforma como serviço

SaaS: software como serviço

SSRF: falsificação de solicitação do lado do servidor

TDE: criptografia transparente de dados

Emirados Árabes Unidos: Emirados Árabes Unidos

RU: Reino Unido

UNCLOS: Convenção das Nações Unidas para o Direito do Mar

VENOM: manipulação de operações negligenciada de ambiente virtualizado (uma vulnerabilidade cibernética)

WEF: Fórum Econômico Mundial

NOTAS

¹ Heidi M. Peters, “The Department of Defense’s JEDI Cloud Program,” Congressional Research Service, atualizado em 2 de agosto de 2019, https://fas.org/sgp/crs/natsec/R45847.pdf .

² “Gartner Forecasts Worldwide Public Cloud Revenue to Grow 17% in 2020”, Gartner, comunicado à imprensa, 13 de novembro de 2019, https://www.gartner.com/en/newsroom/press-releases/2019-11-13- gartner-previsões-no-mundo-público-nuvem-receita-para-crescer-17-por cento-em-2020 .

³ Carmen Reinicke, “3 Reasons One Wall Street Firm Says to Stick With Cloud Stocks Amid the Coronavirus-Induced Market Rout”, Business Insider , 30 de março de 2020, https://markets.businessinsider.com/news/stocks/wedbush- reason-own-cloud-stocks-coronavirus-pandemic-tech-buy-2020-3-1029045273 # 2-the-move-to-cloud-will-accelerate-mais-rapidamente-no-meio-da-pandemia de coronavírus2 .

⁴ “Cloud Down: Impacts on the US Economy,” Lloyd’s e AIR Worldwide, 2018, https://www.lloyds.com/news-and-risk-insight/risk-reports/library/technology/cloud-down .

⁵ Este documento enfoca principalmente a nuvem pública e suas implicações de política. No entanto, para ajudar a desenvolver uma compreensão mais sutil da nuvem, este manual também detalha outros modelos de implantação de nuvem.

⁶ Rob Joyce, “Disrupting Nation State Hackers,” apresentação no USENIX Enigma 2016, https://www.usenix.org/sites/default/files/conference/protected-files/engima2016_transcript_joyce_v2.pdf .

⁷ Arun Sundararajan, “Network Effects,” NYU Stern School of Business, http://oz.stern.nyu.edu/io/network.html .

⁸ Rich Miller, “Who Are the Data Center’s Industry’s Hyperscale Players?” Data Center Frontier, 10 de setembro de 2019, https://datacenterfrontier.com/data-centers-industry-hyperscale-players .

⁹ Lloyd’s and AIR Worldwide, “Cloud Down: Impacts on the US Economy.”

¹⁰ “The Economic Impact of Cybercrime: Not Slow Down,” McAfee, 2017, https://www.mcafee.com/enterprise/en-us/solutions/lp/economics-cybercrime.html .

¹¹ “Ninth Annual Cost of Cybercrime Study,” Accenture, 6 de março de 2019, https://www.accenture.com/us-en/insights/security/cost-cybercrime-study .

¹² Dan Lohrmann, “Cloud First Policy: What Sign It Really Mean?” Government Technology, postagem do blog, 19 de dezembro de 2010, https://www.govtech.com/blogs/lohrmann-on-cybersecurity/Cloud-First-Policy–121910.html .

¹³ Jonathan Zittrain, “The Internet’s Fort Knox Problem,” Harvard University Future of the Internet , postagem no blog, 3 de junho de 2010, http://blogs.harvard.edu/futureoftheinternet/2010/06/03/fort-knox-problem .

¹⁴ Zittrain argumentou em 2010 contra essa abordagem centralizada por preocupação de que ela exacerba outros riscos de política pública, como acesso governamental ilegítimo e controle de dados privados. No entanto, ele não negou os benefícios de segurança da abordagem centralizada, que (dados os custos crescentes da deterioração do cenário da segurança cibernética na última década) merecem ser revisitados, provavelmente a favor dessa abordagem mais centralizada.

¹⁵ O CISO do grande banco afirmou que a segurança na nuvem é “dez vezes” melhor do que a segurança que ele poderia alcançar com sua equipe no banco. Entrevista do autor por telefone com Alex Stamos em 23 de outubro de 2018.

¹⁶ “Capital One on AWS,” Amazon Web Services (AWS), acessado em 7 de maio de 2019, https://aws.amazon.com/solutions/case-studies/innovators/capital-one .

¹⁷ Outras informações úteis sobre a nuvem incluem: Patricia Moloney Figiola, “Cloud Computing: Background, Status of Adoption by Federal Agencies, and Congressional Action,” US Congressional Research Service, atualizado em 25 de março de 2020, https: //crsreports.congress. gov / product / pdf / R / R46119 ; “IaaS, PaaS e SaaS: IBM Cloud Service Models,” IBM Cloud, https://www.ibm.com/cloud/learn/iaas-paas-saas ; e Trey Herr, “Introduction to Cloud Computing,” canal do YouTube do Cybersecurity Tech Accord, 5 de novembro de 2018, https://www.youtube.com/watch?v=pG-b_jbF4pc .

¹⁸ IBM Cloud, “IaaS, PaaS e SaaS: IBM Cloud Service Models.”

¹⁹ Peter Mell e Timothy Grance, “The NIST Definition of Cloud Computing”, Instituto Nacional de Padrões e Tecnologia do Departamento de Comércio dos EUA (NIST), publicação especial 800-145, setembro de 2011, https://nvlpubs.nist.gov/nistpubs /Legacy/SP/nistspecialpublication800-145.pdf .

^{20 As} revisões desta definição não são triviais. Por exemplo, os principais CSPs têm um incentivo para garantir que qualquer definição atualizada favoreça os titulares e se torne uma barreira potencial de entrada para os recém-chegados.

²¹ “Amazon EC2 FAQs,” AWS, https://aws.amazon.com/ec2/faqs/#What_is_an_EC2_Compute_Unit_and_why_did_you_introduce_it .

²² “Qual é o modelo OSI?” CloudFlare, https://www.cloudflare.com/learning/ddos/glossary/open-systems-interconnection-model-osi .

²³ James Sanders e Conner Forrest, “Hybrid Cloud: What It Is, Why It Matters”, ZDNet, 1 de julho de 2014, https://www.zdnet.com/article/hybrid-cloud-what-it-is-why -Isso importa .

²⁴ A definição do NIST inclui mais uma categoria: nuvem da comunidade. Isso se refere à infraestrutura em nuvem compartilhada entre vários clientes com interesses comuns. Por exemplo, várias empresas no mesmo setor podem compartilhar a mesma infraestrutura em nuvem configurada para atender a seus requisitos regulatórios e de segurança exclusivos. Na prática, essa abordagem parece ter ganhado menos sustentação do que outros modelos de implementação para computação em nuvem, mas dados confiáveis sobre as taxas de adoção da comunidade são difíceis de encontrar. Consulte Bill Kleyman, “Explaining the Community Cloud,” Data Center Knowledge, 13 de outubro de 2014, https://www.datacenterknowledge.com/archives/2014/10/13/explaining-community-cloud .

²⁵ John Patrick Pullen, “Where Did Cloud Computing Come From, Anyway?” Time , 19 de março de 2015, http://time.com/collection-post/3750915/cloud-computing-origin-story .

²⁶ Antonio Regalado, “Who Coined ‘Cloud Computing’?” MIT Technology Review, 31 de outubro de 2011, https://www.technologyreview.com/s/425970/who-coined-cloud-computing ; e

Symantec Security Response, “A Brief History of Cloud Computing,” Medium, 18 de janeiro de 2018, https://medium.com/threat-intel/cloud-computing-e5e746b282f5 .

²⁷ Benjamin Black, “EC2 Origins”, postagem no blog, 25 de janeiro de 2009, http://blog.b3k.us/2009/01/25/ec2-origins.html .

²⁸ Em 2019, a AWS havia fornecido a maior parte da receita operacional da Amazon nos quatro anos anteriores. Consulte “Amazon’s Cloud Business Reports 35% Growth in the Third Quarter, Trailing Estimates,” CNBC, 24 de outubro de 2019,

https://www.cnbc.com/2019/10/24/aws-earnings-q3-2019.html.

²⁹ Jack Clark, “How Amazon Exposed Its Guts: The History of AWS’s EC2,” ZDNet, 7 de junho de 2012, https://www.zdnet.com/article/how-amazon-exposed-its-guts-the-history -of-awss-ec2 .

³⁰ Michael Arrington, “Google Jumps Head First Into Web Services With Its Google App Engine,” TechCrunch , 7 de abril de 2008, https://techcrunch.com/2008/04/07/google-jumps-head-first-into- web-services-with-google-app-engine .

³¹ Les Earnest, “Who Invented Timesharing?” Stanford University, 26 de março de 2016, https://web.stanford.edu/~learnest/nets/timesharing.htm .

³² “Why ARPAnet Wasn’t the Beginning: A Brief History of the Internet — Part 1,” Paessler, postagem no blog, 11 de setembro de 2017, https://blog.paessler.com/history-of-the-internet-part -1 .

³³ US Department of the Interior, “Cloud Smart Strategy,” https://www.doi.gov/cloud/strategy#:~:text=The%20Cloud%20First%20Policy%20was,before%20making%20any%20new% 20investimentos.

³⁴ Douglas McIntyre, “Cloud Computing Reaches $ 100 Billion, But Who Makes Money?” 24/7 Wall St., 14 de outubro de 2015, https://247wallst.com/technology-3/2015/10/14/cloud-computing-reachs-100-billion-but-who-makes-money .

³⁵ Yury Izrailevsky, “Completing the Netflix Cloud Migration,” Netflix, postagem do blog, 11 de fevereiro de 2016, https://media.netflix.com/en/company-blog/completing-the-netflix-cloud-migration ;

“Amazon EC2 Crosses the Atlantic,” AWS, 10 de dezembro de 2008, https://aws.amazon.com/about-aws/whats-new/2008/12/10/amazon-ec2-crosses-the-atlantic ; e “AWS Launches the Northern California Region,” AWS, 3 de dezembro de 2009, https://aws.amazon.com/about-aws/whats-new/2009/12/03/aws-launches-the-n Northern-california -region .

³⁶ K. Sreenand, Rijo Rajan e P. Indumathi, “IBM Cloud Computing,” International Research Journal of Advanced Engineering and Science 1, no. 4 (2016): 89–90, http://www.irjaes.com/pdf/IRJAES-V1N4Y16/IRJAES-V1N4P181Y16.pdf .

³⁷ Sholto Macpherson, “Microsoft Announces Azure Launch Date,” IT News, 8 de fevereiro de 2010, https://www.itnews.com.au/news/microsoft-announces-azure-launch-date-166664 .

³⁸ James Sanders, “Micorsoft Azure: A Cheat Sheet,” TechCrunch , 18 de junho de 2018, https://www.techrepublic.com/article/microsoft-azure-the-smart-persons-guide .

³⁹ US Department of Commerce NIST, “Final Version of NIST Cloud Computing Definition Published,” 25 de outubro de 2011, https://www.nist.gov/news-events/news/2011/10/final-version-nist-cloud -definição de computação publicada .

⁴⁰ Vivek Kundra, “Federal Cloud Computing Strategy,” White House, 8 de fevereiro de 2011, https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/egov_docs/federal-cloud-computing-strategy.pdf .

⁴¹ “Amazon Web Services agora disponíveis para clientes de data centers no Reino Unido”, Amazon, comunicado à imprensa, 13 de dezembro de 2016, https://press.aboutamazon.com/news-releases/news-release-details/amazon-web -services-now-available-customers-data-centers-uk-0 ; “Amazon Web Services lança nova região na França”, Amazon, comunicado à imprensa, 18 de dezembro de 2017, https://press.aboutamazon.com/news-releases/news-release-details/amazon-web-services-launches-new -region-france ; Sebastian Moss, “Microsoft Opens Three UK Data Centers, Azure Cloud Now Local,” Data Center Dynamics, 7 de setembro de 2016, https://www.datacenterdynamics.com/news/microsoft-opens-three-uk-data-centers- azure-cloud-now-local; e Tom Keane, “Microsoft Azure Preview com Azure Availability Zones Now Open in France”, Microsoft Azure, postagem no blog, 12 de dezembro de 2017, https://azure.microsoft.com/en-us/blog/microsoft-azure-preview -with-azure-availability-zones-now-open-in-france .

⁴² “Amazon Web Services lança datacenters no Brasil para sua plataforma de computação em nuvem”, Amazon, comunicado à imprensa, 14 de dezembro de 2011, https://press.aboutamazon.com/news-releases/news-release-details/amazon-web-services -launches-brazil-datacenters-its-cloud ; e

“Azure Brazil South Region Now in Public Preview,” Microsoft Azure, 17 de abril de 2014, https://azure.microsoft.com/en-us/updates/azure-brazil-south-region-now-in-public-preview .

⁴³ “Geografia e Regiões”, Google Cloud, https://cloud.google.com/docs/geography-and-regions ; “Regiões, zonas de disponibilidade e zonas locais,” AWS,

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RegionsAndAvailabilityZones.html ; e “Azure Regions,” Microsoft Azure, https://azure.microsoft.com/en-us/global-infrastructure/regions .

⁴⁴ “Alibaba Cloud’s Global Infrastructure,” Alibaba Cloud, https://www.alibabacloud.com/global-locations .

⁴⁵ “IBM compromete $ 1,2 bilhão para expandir a pegada global da nuvem,” IBM, comunicado à imprensa, 17 de janeiro de 2014, https://www-03.ibm.com/press/us/en/pressrelease/42956.wss .

⁴⁶ Em 2011, a empresa de pesquisa de mercado Gartner estimou que o mercado global de IaaS era de US $ 3,7 bilhões. Veja Rachel Wheeler, “IaaS Market to Record ‘Strong Growth,’” Experian, postagem do blog, 7 de abril de 2011, https://www.edq.com/blog/iaas-market-to-record-strong-growth ; Louis Columbus, “Roundup of Cloud Computing Forecasts and Market Estimates,” A Passion for Research , postagem no blog, 17 de janeiro de 2012, https://softwarestrategiesblog.com/2012/01/17/roundup-of-cloud-computing-forecasts -e-estimativas-de-mercado-2012 ; e “Gartner Forecasts Worldwide Public Cloud Revenue to Grow 17,3 Percent in 2019”, Gartner, comunicado à imprensa, 12 de setembro de 2018,https://www.gartner.com/en/newsroom/press-releases/2018-09-12-gartner-forecasts-worldwide-public-cloud-revenue-to-grow-17-percent-in-2019.

⁴⁷ Paddy Srinivasan, “The Real Market Size of Public Cloud Services,” Wired , março de 2013, https://www.wired.com/insights/2013/03/the-real-market-size-of-public-cloud- serviços .

⁴⁸ “Introdução: Um pouco de história do OpenStack,” OpenStack, última atualização em 25 de maio de 2018, https://docs.openstack.org/project-team-guide/introduction.html .

⁴⁹ Jack Clark, “Relatório: Amazon Dominates Global Cloud Spend,” Register , 13 de março de 2013, https://www.theregister.co.uk/2013/03/13/amazon_has_a_third_of_global_iaas_spend .

⁵⁰ Ibid.

⁵¹ Ibid.

⁵² Julie Bort, “Amazon Is Crushing IBM, Microsoft, and Google in Cloud Computing, Says Report,” Business Insider , 26 de novembro de 2013, https://www.businessinsider.com/amazon-cloud-beats-ibm-microsoft- google-2013-11 .

⁵³ Kim Weins, “Cloud Computing Trends: 2015 State of the Cloud Survey”, Flexera, IT Industry Trends , postagem no blog, 18 de fevereiro de 2015, https://www.rightscale.com/blog/cloud-industry-insights/cloud -computing-trends-2015-state-cloud-survey .

⁵⁴ Steven Vaughan-Nichols, “What Is Docker and Why Is It So Darn Popular?” ZDNet, 21 de março de 2018, https://www.zdnet.com/article/what-is-docker-and-why-is-it-so-darn-popular .

⁵⁵ David Byrne, Carol Corrado e Daniel E. Sichel, “The Rise of Cloud Computing: Minding Your P’s, Q’s e K’s,” National Bureau of Economic Research, Working Paper 25188, outubro de 2018, https: //www.nber .org / papers / w25188.pdf .

⁵⁶ “Na guerra dos preços da nuvem, o armazenamento em nuvem se tornou o novo campo de batalha”, 451 Research, comunicado à imprensa, 20 de abril de 2017, https://451research.com/images/Marketing/press_releases/CPI_PR_04_20_2017_vf.pdf?&utm_campaign=2017_press&utm_source= twitter & utm_medium = social & utm_content = press_release & utm_term = q2_2017_cpi_pr .

⁵⁷ Brandon Butler, “Rackspace Bows Out of Commodity IaaS Market in Favor of ‘Managed Cloud,’” Network World, 5 de agosto de 2014, https://www.networkworld.com/article/2461361/iaas/rackspace-bows-out -of-iaas-market.html .

⁵⁸ Brandon Butler, “HP acabou de sair da nuvem pública – e agora?” Network World, 22 de outubro de 2015, https://www.networkworld.com/article/2996536/cloud-computing/hp-just-dropped-out-of-the-public-cloud-now-what.html ; e Quentin Hardy, “HP Comes to Terms With the Cloud”, New York Times , Bits (postagem no blog), 7 de abril de 2015, https://bits.blogs.nytimes.com/2015/04/07/hp-comes -to-terms-with-the-cloud / .

⁵⁹ Steven Vaugh-Nichols, “Verizon to Shut Down Its Public Cloud”, ZDNet, 17 de fevereiro de 2016, https://www.zdnet.com/article/verizon-closes-down-public-cloud ; Shoshanna Delventhal, “Cisco to Terminate $ 1B Public Cloud Unit,” Investopedia, 14 de dezembro de 2016, https://www.investopedia.com/news/cisco-terminate-1b-public-cloud-unit ; e Dan Meyer, “Verizon and AT&T Exit From Cloud Business Applauded by Analysts”, SDX Central, 5 de maio de 2017, https://www.sdxcentral.com/articles/news/verizon-and-att-exit-from-cloud -empresa-aplaudida-por-analistas / 2017/05 .

⁶⁰ “Gartner Says a Massive Shift to Hybrid Infrastructure Is Underway,” Gartner, comunicado à imprensa, 5 de abril de 2017, https://www.gartner.com/en/newsroom/press-releases/2017-04-05-gartner- diz que uma mudança massiva para serviços de infraestrutura híbrida está em andamento ; Marty Chilberg, “Gartner: The IaaS Cloud Will Be a Duopoly by 2019”, Marty Chilberg’s Blog , postagem no blog, 19 de agosto de 2017, https: // seek ingalpha.com/instablog/400846-marty-chilberg/5029588-gartner- iaas-cloud-will-duopoly-2019 .

⁶¹ Seth Fiegerman, “Microsoft’s Cloud Bet Pushes Annual Sales Over $ 100 bilhões,” CNN, 19 de julho de 2018, https://money.cnn.com/2018/07/19/technology/microsoft-earnings/index.html .

⁶² Cisco, “Cisco Global Cloud Index: Forecast and Methodology: 2016–2021,” 2018, https://www.cisco.com/c/en/us/solutions/collateral/service-provider/global-cloud-index- gci / white-paper-c11-738085.pdf .

⁶³ Embora a Cisco não cite todas as 24 empresas com centros de operações de dados em hiperescala, uma lista parcial inclui ADP, Alibaba, Amazon, Apple, Baidu, eBay, Facebook, Google, Microsoft, Oracle, Rackspace, Salesforce, Tencent e Yahoo . Consulte Yevgeniy Sverdlik, “Research: There Are Now Close to 400 Hyper-Scale Data Centers in the World,” Data Center Knowledge, 22 de dezembro de 2017, https://www.datacenterknowledge.com/cloud/research-there-are- now-close-400-hyper-scale-data-centers-world .

⁶⁴ “Hyperscale Cloud Market Overview,” Synergy Research Group, abril de 2017, https://srgresearch.s3.amazonaws.com/public-reports/hyperscale-market-overview-primer-april-2017.pdf .

⁶⁵ “The Leading Cloud Providers Aumentam sua participação no mercado novamente no terceiro trimestre,” Synergy Research Group, 25 de outubro de 2018, https://www.srgresearch.com/articles/leading-cloud-providers-increase-their-market- share-again-terceiro trimestre .

⁶⁶ Para obter mais informações sobre hiperescala, consulte Trey Herr, “Hyperscaling: The Structure of the Internet in the Second Age of Cloud,” NATO Cooperative Cyber Defense Center of Excellence (CCDCE) 2018 International Conference on Cyber Conflict, canal NATO CCDCE no YouTube, https: //www.youtube.com/watch?v=pXQ4sl-3J-g&feature=youtu.be&t=1244 .

⁶⁷ Ron Miller, “Alibaba Cloud Growing Like Gangbusters, But Still Far Behind AWS and Other Market Leaders,” TechCrunch , 6 de fevereiro de 2018, https://techcrunch.com/2018/02/06/alibaba-cloud-growing-like -gangbusters-but-ainda-muito-atrás-de-aws-e-outros-líderes de mercado .

⁶⁸ Hari Kannan e Christopher Thomas, “Public Cloud in China: Big Challenges, Big Upside”, McKinsey, julho de 2018, https://www.mckinsey.com/industries/high-tech/our-insights/public-cloud-in -china-big-challenge-big-upside .

⁶⁹ “China Public Cloud (IaaS) alcançará US $ 6,21 bilhões em 2018; Amazon Fastest Growth ”, China Internet Watch, 10 de outubro de 2018, https://www.chinainternetwatch.com/26900/public-cloud-iaas-2018 .

⁷⁰ Yevgeniy Sverdlik, “Microsoft Launches Mainland-China Azure Cloud Data Center,” Data Center Dynamics, 27 de março de 2014, https://www.datacenterdynamics.com/news/microsoft-launches-mainland-china-azure-cloud-data -center ; Doug Haugher, “Windows Azure, Operated by 21Vianet, Now Generally Available in China,” Microsoft Azure, postagem no blog, 26 de março de 2014, https://azure.microsoft.com/en-us/blog/windows-azure-services -agora-geralmente-disponível-na-china / ; e “Overview of Cloud Computing in China,” Export.gov, 16 de março de 2016, https://www.export.gov/article?id=Overview-of-Cloud-Computing-in-China .

⁷¹ Mo Chen, Andrew McGinty, Mark Parsons, Liang Xu e Roy Zou, “Evolving Landscape for International Cloud Providers in China: Why US Technology Giants Are Pairing Up With Local Partners”, JDSupra, 25 de julho de 2018, https: // www.jdsupra.com/legalnews/evolving-landscape-for-international-16682 .

⁷² Jon Russell, “AWS Isn’t Exiting China, But Amazon Did Sell Physical Assets to Conform With Chinese Law,” TechCrunch , 13 de novembro de 2017, https://techcrunch.com/2017/11/13/aws-exits- china .

⁷³ Gartner, “Gartner Forecasts Worldwide Public Cloud Revenue to Grow 17.3 Percent in 2019.”

⁷⁴ Consulte a figura 2 na página 6 no seguinte relatório: Fórum Econômico Mundial, “The Global Risk Report 2019,” 2019, http://www3.weforum.org/docs/WEF_Global_Risks_Report_2019.pdf .

⁷⁵ Fórum Econômico Mundial, “The Global Risk Report 2019”.

⁷⁶ EY, “EY Global Information Security Survey,” 2019, 5, https://assets.ey.com/content/dam/ey-sites/ey-com/en_ca/topics/advisory/ey-global-information-security -survey-2018-19.pdf .

⁷⁷ Justina Crabtree, “Lloyd’s of London CEO Says 92 Percent of European Businesses Have Experienced Cyber Breaches,” CNBC, 19 de dezembro de 2016, https://www.cnbc.com/2016/12/19/lloyds-of-london- ceo-diz-92-por cento-das-empresas-europeias-experimentaram-violações-cibernéticas.html .

⁷⁸ Accenture, “Ninth Annual Cost of Cybercrime Study.”

⁷⁹ Ibid.

⁸⁰ EY, “EY Global Information Security Survey,” 2019, 16.

⁸¹ Entrevista do autor por telefone com Alex Stamos em 23 de outubro de 2018.

⁸² Com base em comentários feitos pelo CISO de uma grande instituição financeira em uma mesa redonda privada, janeiro de 2019.

⁸³ Liam Tung, “AWS Users Fret Over Downtime Ahead of Amazon’s Massive EC2 Reboot,” ZDNet, 25 de setembro de 2014, https://www.zdnet.com/article/aws-users-fret-over-downtime-ahead-of -amazons-massivo-ec2-reboot .

⁸⁴ Jason Zander, “Análise da causa raiz final e áreas de melhoria: 18 de novembro Azure Storage Service Interruption,” Microsoft Azure, postagem no blog, 17 de dezembro de 2014, https://azure.microsoft.com/en-us/blog/final- análise de causa-raiz e áreas de melhoria-nov-18-azure-storage-service-interruption .

⁸⁵ Ben Sullivan, “Lighting Strikes Cause of Google Cloud Outage,” Silicon.co.uk, 19 de agosto de 2015, https://www.silicon.co.uk/cloud/google-cloud-outage-lightning-strikes-175135 ; e Google Cloud Platform, “Google Compute Engine Incident # 15056,” Google Cloud Status Dashboard, 18 de agosto de 2015, https://status.cloud.google.com/incident/compute/15056 .

⁸⁶ Charles Babcock, “Amazon Disruption Produces Cloud Outage Spiral,” Information Week, 22 de setembro de 2015, https://www.informationweek.com/cloud/infrastructure-as-a-service/amazon-disruption-produces-cloud-outage -spiral / d / d-id / 1322279 .

⁸⁷ Gavin Clarke, “Microsoft Struggles Against Self-Inflicted Office 365 IMAP Outage,” Register , 25 de janeiro de 2016, https://www.theregister.com/2016/01/25/office_365_imap_outage/ .

⁸⁸ Dom Nicastro, “Salesforce Customers Lose CRM Data in 20 Hour Outage”, CMS Wire, 13 de maio de 2016, https://www.cmswire.com/customer-experience/salesforce-customers-lose-crm-data-in- Interrupção de 20 horas ; e Salesforce, “RCM for NA14 Disruptions of Service – May 2016,” 16 de maio de 2016, https://help.salesforce.com/articleView?language=en_US&type=1&mode=1&id=000315819 .

⁸⁹ “Resumo da interrupção do serviço Amazon S3 na região da Virgínia do Norte (US-EAST-1),” AWS, https://aws.amazon.com/message/41926 ; Jordan Novet, “AWS Is Investigating S3 Issues, Affecting Quora, Slack, Trello (Updated),” VentureBeat, 28 de fevereiro de 2017, https://venturebeat.com/2017/02/28/aws-is-investigating-s3- questões-afetando-quora-folga-trello ; e Yevgeniy Sverdlik, “AWS Outage That Broke the Internet Caused by Mistyped Command,” Data Center Knowledge, 2 de março de 2017, https://www.datacenterknowledge.com/archives/2017/03/02/aws-outage-that- quebrou a internet causado por comando incorreto .

⁹⁰ Simon Sharwood, “Azure Storage Browns Out for Eight Hours, Nobody Notices,” Register , 17 de março de 2017, https://www.theregister.com/2017/03/17/azure_storage_brownout ; e Jordan Novet, “Microsoft Confirms Azure Storage Issues Around the World (Updated),” VentureBeat, 15 de março de 2017, https://venturebeat.com/2017/03/15/microsoft-confirms-azure-storage-issues-around -o-mundo .

⁹¹ Ted Greenwald e Jack Nicas, “Intel Wrestled With Chip Flaws for months,” Wall Street Journal, 5 de janeiro de 2018, https://www.wsj.com/articles/intel-wrestled-with-chip-flaws-for- meses-1515110151? mod = article_inline .

⁹² Jann Horn, “Reading Privileged Memory With a Side-Channel”, Google, postagem do blog Project Zero , 3 de janeiro de 2018, https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side .html .

⁹³ Thomas Claburn, “Azure North Europe Downed by the Curse of the Irish – Sunshine,” Register , 22 de junho de 2018, https://www.theregister.com/2018/06/22/azure_north_europe_downed_by_pleasant_weather ; e Sead Fadilpašić, “Microsoft Azure Suffers Major Outage,” ITProPortal, 20 de junho de 2018, https://www.itproportal.com/news/microsoft-azure-suffers-major-outage .

⁹⁴ “Postmortem: VSTS 4 September 2018,” Microsoft Azure, postagem no blog DevOps , 10 de setembro de 2018, https://devblogs.microsoft.com/devopsservice/?p=17485 ; e Richard Speed, “Microsoft Azure: It’s Getting Hot in Here, So Shut Down All Your Cores,” Register , 4 de setembro de 2018, https://www.theregister.co.uk/2018/09/04/azure_its_getting_hot_in_here .

⁹⁵ Dan Goodin, “Google Goes Down After Major BGP Mishap Routes Traffic Through China”, Ars Technica, 13 de novembro de 2018, https://arstechnica.com/information-technology/2018/11/major-bgp-mishap-takes- baixo-google-como-tráfego-indevidamente-viaja-para-a-china .

⁹⁶ “Azure Active Directory Outage and RCA for Azure Cloud Hiccups,” Born’s Tech and Windows World, 2 de fevereiro de 2019, https://borncity.com/win/2019/02/02/azure-active-directory-outage-rca -for-azure-cloud-hicups ; e Danny Bradbury, “Microsoft Azure Data Deleted because of DNS Outage,” Naked Security, 1 de fevereiro de 2019, https://nakedsecurity.sophos.com/2019/02/01/dns-outage-turns-tables-on-azure -usuários de banco de dados .

⁹⁷ Alex Hern, “How Did an Amazon Glitch Leave People Literally in the Dark?” Guardian, 1º de março de 2017, https://www.theguardian.com/technology/2017/mar/01/amazon-web-services-outage-smart-homes .

⁹⁸ Essa abordagem tem limitações óbvias, pois o passado não prediz necessariamente o futuro.

⁹⁹ Juan Carlos Crisanto, Conor Donaldson, Denise Garcia Ocampo e Jermy Prenio, “Regulating and Supervising the Clouds: Emerging Prudential Approaches for Insurance Companies,” Financial Stability Institute (FSI) Insights no. 13 de dezembro de 2018, https://www.bis.org/fsi/publ/insights13.pdf .

¹⁰⁰ Os autores agradecem a Trey Herr por seus comentários e por chamar sua atenção especificamente para as vulnerabilidades do hipervisor.

¹⁰¹ Os autores agradecem a Trey Herr por chamar a atenção para o papel específico que os hipervisores desempenham em relação à arquitetura geral e à segurança da nuvem.

¹⁰² Joe Warminsky, “Apple, Oracle, VMware Products Successfully Hacked at Pwn2Own,” Cyberscoop, 21 de março de 2019, https://www.cyberscoop.com/pwn2own-2019-day-one-apple-oracle-vmware .

¹⁰³ Daniel Gray, “Hyperjacking — Future Computer Server Threat,” SysChat, 2 de setembro de 2009, http://www.syschat.com/hyperjacking-future-computer-server-threat-4917.html .

¹⁰⁴ “Virtualized Environment Neglected Operations Manipulation (VENOM),” Crowdstrike, atualizado em 21 de maio de 2015, https://venom.crowdstrike.com .

¹⁰⁵ John Patrick Barrowclough e Rameez Asif, “Securing Cloud Hypervisors: A Survey of Threats, Vulnerabilities, and Countermeasures”, Security and Communication Networks 18 (11 de junho de 2018), https://www.hindawi.com/journals/scn/ 2018/1681908 / .

¹⁰⁶ Em 2018, o NIST publicou orientações de segurança para “plataformas de hipervisor baseadas em servidor”, que basicamente significa CSPs, embora isso possa incluir outras configurações de gerenciamento de data center. O documento discute algumas das principais ramificações de segurança dos hipervisores. Ele descreve três classes de ameaças: violação do isolamento do processo, violação do isolamento da rede e negação de serviço. Consulte Ramaswamy Chandramouli, “Security Recommendations for Server-Based Hypervisor Platforms,” US Department of Commerce NIST, Special Publication 800-125A review 1, June 2018, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP. 800-125Ar1.pdf .

¹⁰⁷ “Cyber Incident Serverity Schema,” Casa Branca, 26 de julho de 2016, https://obamawhitehouse.archives.gov/sites/whitehouse.gov/files/documents/Cyber%2BIncident%2BSeverity%2BSchema.pdf .

¹⁰⁸ Paul Schwartz, “Legal Access to the Global Cloud,” Columbia Law Review 118, no. 6 (2018): 1681–1762, https://columbialawreview.org/content/legal-access-to-the-global-cloud ; e Jennifer Daskal, “The Un-Territoriality of Data,” Yale Law Review 125 (2015): 326–398, https://www.yalelawjournal.org/pdf/a.326.Daskal.398_qrhgeoar.pdf .

¹⁰⁹ Andrew Keane Woods e Peter Swire, “The CLOUD Act: A Welcome Legislative Fix for Cross-Border Data Problems,” Lawfare , postagem no blog, 6 de fevereiro de 2018, https://www.lawfareblog.com/cloud-act-welcome -legislative-fix-cross-border-data-problems .

¹¹⁰ Shaul Brazil and Jonthan Flynn, “Overseas Production Orders – A New Tool for UK Law Enforcement,” BCL Solicitors, fevereiro de 2019, https://www.bcl.com/overseas-production-orders-a-new-tool-for -uk-law-enforcement .

¹¹¹ Kati Suominen, “Sem escolha? GDPR’s Impact on the US, UK, and the EU, ”Center for Strategic and International Studies (CSIS), postagem do blog, 31 de janeiro de 2018, https://www.csis.org/blogs/future-digital-trade-policy -and-role-us-and-uk / no-choice-gdprs-impact-us-uk-and-eu .

¹¹² “Freedom on the Net 2019: The Crisis of Social Media,” Freedom House, 2019, https://freedomhouse.org/report/freedom-net .

¹¹³ Freedom House, “Bahrain”, em Freedom in the World 2020: A Leaderless Struggle for Democracy , 2020, https://freedomhouse.org/country/bahrain/freedom-world/2020 ; e Freedom House, “United Arab Emirates”, em Freedom in the World 2020: A Leaderless Struggle for Democracy , 2020, https://freedomhouse.org/country/united-arab-emirates/freedom-world/2020 .

¹¹⁴ Werner Vogels, “As-Salaam-Alaikum: The Cloud Arrives in the Middle East!” All Things Distributed , postagem no blog, 25 de setembro de 2017, https://www.allthingsdistributed.com/2017/09/aws-region-middle-east.html .

¹¹⁵ Jason Zander, “Microsoft Expands Cloud Services in Europe and Into Middle East to Meet Growing Customer Demand,” Microsoft, blog post, 14 de março de 2018, https://blogs.microsoft.com/blog/2018/03/14/ microsoft-expande-cloud-services-in-europe-and-into-middle-east-to-atender-a-crescente-demanda do cliente .

¹¹⁶ Sebastian Moss, “Google Cloud Continues to Grow, Is Coming to Saudi Arabia,” DataCenter Dynamics, 24 de abril de 2018, https://www.datacenterdynamics.com/news/google-cloud-continues-to-grow-is- chegando à Arábia Saudita .

¹¹⁷ Sebastian Moss, “Google Still Pursuing Saudi Arabian Data Centers, After Khashoggi’s Murder”, Data Center Dynamics, 18 de abril de 2019, https://www.datacenterdynamics.com/en/news/google-still-pursuing-saudi-arabian -data-centers-after-khashoggis-kill .

¹¹⁸ Aditya Kalra, “Exclusive: US Senators Urge India to Soften Data Localization Stance”, Reuters, 13 de outubro de 2018, https://www.reuters.com/article/us-india-data-localisation-exclusive/exclusive-us -senators-urge-india-to-soften-data-localization-stance-idUSKCN1MN0CN .

¹¹⁹ Yuxi Wei, “Chinese Data Localization Law: Comprehensive But Ambiguous,” University of Washington Henry M. Jackson School of International Relations, 7 de fevereiro de 2018, https://jsis.washington.edu/news/chinese-data-localization- lei-abrangente-ambígua .

¹²⁰ Wei, “Chinese Data Localization Law: Comprehensive but Ambiguous.”

¹²¹ Eset Dedezade, “Microsoft to Deliver Cloud Services From New Datacentres in Germany in 2019 to Meet Evolving Customer Needs”, Microsoft News Center Europe, 31 de agosto de 2018, https://news.microsoft.com/europe/2018/08/ 31 / microsoft-to-deliver-cloud-services-from-new-datacentres-in-germany-in-2019-to-meet-evolating-customer-needs .

¹²² Aidan Finn, “Changes to Azure Germany Operations,” Petri, 5 de outubro de 2018, https://www.petri.com/changes-to-azure-germany-operations .

¹²³ Josh Kallmer, “China: Challenge to US Commerce”, testemunho, Comitê do Senado dos EUA sobre Comércio, Ciência e Transporte, Subcomitê de Segurança, 7 de março de 2019, https://www.itic.org/dotAsset/7267b522-28c6 -4bb7-9719-c9f1f20fd9a3.pdf .

¹²⁴ Yifan Yu, “Amazon Prepares to Battle With Alibaba in Asia’s Cloud”, Nikkei Asian Review, 4 de maio de 2019, https://asia.nikkei.com/Business/Companies/Amazon-prepares-to-battle-with-Alibaba -in-Asia-s-cloud ; e Mercedes Ruehl, “US and Chinese Cloud Companies Vie for Dominance in South-East Asia,” Financial Times, 19 de maio de 2020, https://www.ft.com/content/1e2b9cd9-f82e-4d3b-a2d8-f20c08bdc3aa .

¹²⁵ Escritório do Diretor de Inteligência Nacional dos EUA, “Threats to Undersea Cable Communications,” 28 de setembro de 2017, https://www.dni.gov/files/PE/Documents/1—2017-AEP-Threats-to -Undersea-Cable-Communications.pdf ; https://www.reuters.com/article/us-huawei-tech-usa-cable/chinas-huawei-to-sell-undersea-cable-business-buyers-exchange-filing-shows-idUSKCN1T40BS .

¹²⁶ Agence France-Presse, “Solomon Islands Drops Chinese Tech Giant Huawei for Billion-Dollar Undersea Cable, Signs Australia”, South China Morning Post , 13 de junho de 2018, https://www.scmp.com/news/asia/diplomacy / article / 2150616 / solomon-islands-drops-chinese-tech-giant-huawei-bilhão-dólares .

¹²⁷ Tom Westbrook, “PNG Upholds Deal With Huawei to Lay Internet Cable, Derides Counter-Offer,” Reuters, 26 de novembro de 2018, https://www.reuters.com/article/us-papua-huawei-tech/png- mantém o acordo-com-huawei-para-lay-internet-cabo-zomba-contra-oferta-idUSKCN1NV0DR .

¹²⁸ Jeremy Page, “Huawei Selling Stake in Undersea-Cable Firm as US Pressure Mounts,” Wall Street Journal, 3 de junho de 2019, https://www.wsj.com/articles/huawei-selling-stake-in-undersea- cabo-firme-como-nós-pressão-montagens-11559562892 ; e Jeremy Page, Kate O’Keeffe e Rob Taylor, “America’s Undersea Battle with China for Control of the Global Internet Grid”, Wall Street Journal, 12 de março de 2019, https://www.wsj.com/articles/us -takes-on-chinas-huawei-in-under-sea-battle-over-the-global-internet-grid-11552407466 .

¹²⁹ Tony Romm, “Google Fined Nearly $ 1,7 Billion for Ad Practices That EU Says Violated Antitrust Laws”, Washington Post, 20 de março de 2019, https://www.washingtonpost.com/technology/2019/03/20/google-fined -quase-bilhão-de-práticas-de-anúncio-que-violou-as-leis-antitruste-europeias /? utm_term = .57f8971cd3f1 .

¹³⁰ Elizabeth Warren, “Here How We Can Break Up Big Tech”, Medium, 8 de março de 2019, https://medium.com/@teamwarren/heres-how-we-can-break-up-big-tech-9ad9e0da324c .

¹³¹ Lina M. Khan, “Amazon’s Antitrust Paradox,” Yale Law Journal 126 (2017): 754, https://digitalcommons.law.yale.edu/cgi/viewcontent.cgi?article=5785&context=ylj .

¹³² Tae Kim, “Amazon Should Split Into Two Companies to Avoid Antitrust Scrutiny From Trump Administration: Citi,” CNBC, 17 de setembro de 2018, https://www.cnbc.com/2018/09/17/amazon-should-split -its-retail-and-cloud-computing-business-citi.html .

¹³³ Jon Bateman, “The Antitrust Threat to National Security,” Wall Street Journal, 22 de outubro de 2019, https://www.wsj.com/articles/the-antitrust-threat-to-national-security-11571784197 .

¹³⁴ Crisanto, Donaldson, Ocampo e Prenio, “Regulating and Supervising the Clouds: Emerging Prudential Approaches for Insurance Companies.”

¹³⁵ Trey Herr’s argumenta que “A estratégia dos Estados Unidos para proteger a computação em nuvem está incompleta e, a menos que haja uma mudança no pensamento regulatório, o impulso para a computação em nuvem como uma solução para as deficiências de segurança em organizações de pequeno e médio porte só produzirá mais riscos. ” Veja Trey Herr, “Better to Be Realistic About the Security Opportunities of Cloud Computing” , Lawfare , postagem no blog, 17 de março de 2020, https://www.lawfareblog.com/better-be-realistic-about-security-opportunities- computação em nuvem .

¹³⁶ Paresh Dave, “Google’s New Cloud Boss Has Big Task to Catch Rivals, Reuters Data Show”, Reuters, 21 de fevereiro de 2019, https://www.reuters.com/article/us-alphabet-google-cloud-focus/ googles-new-cloud-boss-has-big-task-to-catch-rivals-reuters-data-show-idUSKCN1QA0HB .

¹³⁷ Lixian Loong Hantover, “The Cloud and The Deep Sea: How Cloud Storage Raises the Stakes for Undersea Cable Security and Liability,” Ocean and Coastal Law Journal 19, no. 1 (2014): 1-28, https://digitalcommons.mainelaw.maine.edu/cgi/viewcontent.cgi?article=1028&context=oclj .

¹³⁸ O grupo de trabalho da Federal Communications Commission dos Estados Unidos escreveu um relatório em 2014 sobre a proteção de cabos por meio da separação espacial. Consulte “Relatório final – Proteção de cabos submarinos por meio da separação espacial”, Comissão Federal de Comunicações, Conselho de Comunicações, Segurança, Confiabilidade e Interoperabilidade, Grupo de Trabalho 8 Roteamento e Aterragem de Cabos Submarinos, dezembro de 2014, https://transition.fcc.gov/pshs /advisory/csric4/CSRIC_IV_WG8_Report1_3Dec2014.pdf . Em 2017, o Escritório do Diretor de Inteligência Nacional dos Estados Unidos publicou um relatório sobre ameaças aos cabos submarinos, fornecendo uma análise aprofundada da indústria de cabos submarinos. Veja “Ameaças às Comunicações Submarinas por Cabo”, Escritório do Diretor de Inteligência Nacional dos EUA, 28 de setembro de 2017,https://www.dni.gov/files/PE/Documents/1—2017-AEP-Threats-to-Undersea-Cable-Communications.pdf . Um parlamentar britânico também escreveu um importante relatório sobre as vulnerabilidades de cabos em 2017. Veja Rishi Sunak, “Undersea Cables: Indispensible, Insecure,” Policy Exchange, novembro de 2017, https://policyexchange.org.uk/wp-content/uploads /2017/11/Undersea-Cables.pdf .

¹³⁹ John K. Crain, “Assessing Resilience in the Global Undersea Cable Infrastructure,” Naval Postgraduate School, tese, junho de 2012, https://apps.dtic.mil/dtic/tr/fulltext/u2/a562772.pdf .

¹⁴⁰ Hantover, “The Cloud and the Deep Sea.”

¹⁴¹ “Government Cloud First Policy,” UK Government, 3 de fevereiro de 2017, https://www.gov.uk/guidance/government-cloud-first-policy .

¹⁴² Aaron Boyd, “White House Outlines Move From ‘Cloud First’ to ‘Cloud Smart’,” NextGov, 12 de setembro de 2018, https://www.nextgov.com/it-modernization/2018/09/white-house- outlines-move-cloud-first-cloud-smart / 151498 / ; e US Chief Information Officer (CIO), “Federal Cloud Computing Strategy,” acessado em 16 de agosto de 2020, https://cloud.cio.gov/ .

¹⁴³ US Government Accountability Office, “Agencies Have Aumented Usage and Realized Benefits, but Cost and Savings Data Need to Be Better Tracked”, GAO-19-58, 2019, https://www.gao.gov/products/GAO-19 -58 .

¹⁴⁴ US CIO, “From Cloud First to Cloud Smart”, https://cloud.cio.gov/strategy/#security ; e “FedRAMP,” FedRAMP, https://www.fedramp.gov/ .

¹⁴⁵ “Buying and Selling on the Digital Marketplace,” Governo do Reino Unido, 27 de junho de 2019, https://www.gov.uk/guidance/the-g-cloud-framework-on-the-digital-marketplace .

¹⁴⁶ David Braue, “Australian Government Signs Up with AWS,” Information Age, 2 de julho de 2019, https://ia.acs.org.au/article/2019/australian-government-signs-up-with-aws.html ; Aaron Tan, “Singapore Government Makes Bold Cloud Move”, Computer Weekly , 2 de outubro de 2018, https://www.computerweekly.com/news/252449829/Singapore-government-makes-bold-cloud-move ; e Chris Thornett, “German Government Goes Open Source With Cloud Firm Nextcloud”, Techradar.pro, 17 de abril de 2018, https://www.techradar.com/news/german-government-goes-open-source-with-open -source-cloud-firm-nextcloud .

¹⁴⁷ Figiola, “Cloud Computing: Background, Status of Adoption by Federal Agencies, and Congressional Action.”

¹⁴⁸ Frank Konkel, “The Details About the CIA’s Deal With Amazon,” Atlantic, 17 de julho de 2014, https://www.theatlantic.com/technology/archive/2014/07/the-details-about-the-cias- lidar-com-amazon / 374632 .

¹⁴⁹ Charles McLellan, “Multicloud: Everything You Need to Know About the Biggest Trend in Cloud Computing”, ZDNet, 1 de julho de 2019, https://www.zdnet.com/article/multicloud-everything-you-need-to- know-about-the-maior-tendência-em-computação em nuvem .

¹⁵⁰ “Relatório do Estado da Nuvem Flexera 2020,” Flexera, 2020, https://info.flexera.com/SLO-CM-REPORT-State-of-the-Cloud-2020 .

¹⁵¹ McLellan, “Multicloud: Everything You Need to Know about the Biggest Trend in Cloud Computing.”

¹⁵² “Cloud Security Complexity,” Cloud Security Alliance, maio de 2019, https://cloudsecurityalliance.org/artifacts/cloud-security-complexity .

¹⁵³ Aaron Gregg, “Pentagon Doubles Down on ‘Single-Cloud’ Strategy for $ 10 Billion Contract”, Washington Post, 5 de agosto de 2018, https://www.washingtonpost.com/business/capitalbusiness/pentagon-doubles-down-on -single-cloud-strategy-for-10-bilhões-contract / 2018/08/05 / 352cfee8-972b-11e8-810c-5fa705927d54_story.html .

¹⁵⁴ Billy Mitchell, “DOD Defends Its Decision to Move to Commercial Cloud With a Single Award”, FedScoop, 8 de março de 2018, https://www.fedscoop.com/dod-pentagon-jedi-cloud-contract-single-award .

¹⁵⁵ Barry Rosenberg, “Oracle Vs. Pentagon: Why Judge Approved a Single Vendor for JEDI Cloud, ”Breaking Defense, 29 de julho de 2019, https://breakingdefense.com/2019/07/oracle-vs-pentagon-why-judge-approved-a-single-vendor -para-jedi-cloud .

¹⁵⁶ Daniel Gouré, “The Critics Are Wrong: A Single Award for the JEDI Contract Is the Right Approach,” Lexington Institute, blog post, 16 de outubro de 2018, https://www.lexingtoninstitute.org/the-critics-are- abordagem errada-um-único-prêmio-para-o-contrato-jedi-é-o-certo .

¹⁵⁷ Adam Mazmanian, “CIA Plans Multibillion Cloud Buy for Intelligence Community,” FCW, 1 de abril de 2019, https://fcw.com/articles/2019/04/01/cia-cloud-c2e-multivendor.aspx .

¹⁵⁸ “Resumo da interrupção do serviço Amazon S3 na região da Virgínia do Norte (US-EAST-1),” AWS, https://aws.amazon.com/message/41926/ .

¹⁵⁹ Kenneth Hui, “AWS 101: Regions and Availability Zones,” Rackspace Technology, postagem do blog, 16 de fevereiro de 2017, https://www.rackspace.com/blog/aws-101-regions-availability-zones .

¹⁶⁰ AWS, “Resumo da interrupção do serviço Amazon S3 na região da Virgínia do Norte (US-EAST-1).”

¹⁶¹ Jordan Novet, “AWS Is Investigating S3 Issues, Affecting Quora, Slack, Trello (Updated),” VentureBeat , 28 de fevereiro de 2017, https://venturebeat.com/2017/02/28/aws-is-investigating-s3 -issues-relevant-quora-slack-trello .

¹⁶² Alex Hern, “How Did an Amazon Glitch Leave People Literally in the Dark?”

¹⁶³ Yevgeniy Sverdlik, “AWS Outage That Broke the Internet Caused by Mistyped Command,” Data Center Knowledge, 2 de março de 2017, https://www.datacenterknowledge.com/archives/2017/03/02/aws-outage-that- quebrou a internet causado por comando incorreto .

¹⁶⁴ “Amazon S3,” tecnologia semelhante, https://www.similartech.com/technologies/amazon-s3 .

¹⁶⁵ “Amazon S3 Storage Classes,” AWS, https://aws.amazon.com/s3/storage-classes .

¹⁶⁶ “Postmortem: VSTS 4 September 2018,” Microsoft Azure, DevOps blog post, 10 de setembro de 2018, https://devblogs.microsoft.com/devopsservice/?p=17485

¹⁶⁷ Ibid.

¹⁶⁸ Richard Speed, “Microsoft Azure: It’s Getting Hot in Here, So Shut Down All Your Cores,” Register , 4 de setembro de 2018, https://www.theregister.co.uk/2018/09/04/azure_its_getting_hot_in_here .

¹⁶⁹ “Postmortem: VSTS 4 September 2018.”

¹⁷⁰ Tom Krazit, “Some Microsoft Azure Issues Stretch Into a Second Day, as Active Directory and Office 365 Stabilize,” GeekWire, 5 de setembro de 2018, https://www.geekwire.com/2018/microsoft-azure-issues-stretch -segundo-dia-diretório-ativo-escritório-365-estabilizar .

¹⁷¹ Thomas Claburn, “Azure North Europe Downed by the Curse of the Irish — Sunshine,” Register , 22 de junho de 2018, https://www.theregister.co.uk/2018/06/22/azure_north_europe_downed_by_pleasant_weather/ ; e Yevgeniy Sverdlik, “Microsoft Says Azure Outage Cause by Accidental Fire-Suppression Gas Release”, DataCenter Knowledge, 4 de outubro de 2017, https://www.datacenterknowledge.com/uptime/microsoft-says-azure-outage-caused-accidental – liberação de gás de supressão de fogo .

¹⁷² Aftab Siddiqui, “Route Leak Causes Major Google Outage,” Internet Society, 15 de novembro de 2018, https://www.internetsociety.org/blog/2018/11/route-leak-caused-a-major-google-outage .

¹⁷³ Dan Goodin, “Strange Snafu Misroutes Domestic US Internet Traffic Through China Telecom,” Ars Technica, 6 de novembro de 2018, https://arstechnica.com/information-technology/2018/11/strange-snafu-misroutes-domestic-us -internet-traffic-through-china-telecom .

¹⁷⁴ Dan Goodin, “Google Goes Down After Major BGP Mishap Routes Traffic Through China”, Ars Technica, 13 de novembro de 2018, https://arstechnica.com/information-technology/2018/11/major-bgp-mishap-takes- baixo-google-como-tráfego-indevidamente-viaja-para-a-china .

¹⁷⁵ Google, “Google Cloud Networking Incident # 18018,” Google Cloud Platform, https://status.cloud.google.com/incident/cloud-networking/18018 .

¹⁷⁶ Dan Goodin, “Suspicious Event Hijacks Amazon Traffic for 2 Hours, Steals Cryptocurrency”, Ars Technica, 24 de abril de 2018, https://arstechnica.com/information-technology/2018/04/suspicious-event-hijacks-amazon- tráfego por 2 horas-rouba criptomoeda.

¹⁷⁷ Chris Williams, “Tentando fazer logon no Office 365 agora mesmo? É uma moeda virada, diz a Microsoft: o serviço passa a TITSUP como Azure Portal Wobbles, ” Register , 29 de janeiro de 2019, https://www.theregister.co.uk/2019/01/29/office_365_outage .

¹⁷⁸ “Azure Active Directory Outage and RCA for Azure Cloud Hiccups,” Born’s Tech and Windows World, 2 de fevereiro de 2019, https://borncity.com/win/2019/02/02/azure-active-directory-outage-rca -for-azure-cloud-hicups ; e Danny Bradbury, “Microsoft Azure Data Deleted because of DNS Outage,” Naked Security, 1 de fevereiro de 2019, https://nakedsecurity.sophos.com/2019/02/01/dns-outage-turns-tables-on-azure -usuários de banco de dados .

¹⁷⁹ Richard Speed, “Forget Snowmageddon, It’s Dropageddon in Azure SQL World: Microsoft Accidentally Deletes Customer DBs,” Register , 30 de janeiro de 2019, https://www.theregister.co.uk/2019/01/30/azure_sql_delete .

¹⁸⁰ Ibid.

¹⁸¹ Ibid.

¹⁸² “Born’s Tech and Windows World,“ Azure Active Directory Outage and RCA for Azure Cloud Hiccups. ”

¹⁸³ Thomas Ricker, “Facebook Returns After Its Worst Outage Ever” , Verge , 14 de março de 2019, https://www.theverge.com/2019/3/14/18265185/facebook-instagram-whatsapp-outage-2019-return -back ; e Hamza Shaban, “Facebook, Instagram e WhatsApp Suffered a Global Outage. What Happened ?, ” Washington Post , 14 de março de 2019, https://www.washingtonpost.com/technology/2019/03/14/facebook-instagram-whatsapp-suffered-global-outage-what-happened .

¹⁸⁴ Ibid.

¹⁸⁵ Peter Judge e Will Calvert, “Facebook, Instagram, WhatsApp Suffer Global Outage,” DataCenter Dynamics, 14 de março de 2019, https://www.datacenterdynamics.com/en/news/facebook-instagram-whatsapp-suffer-global- interrupção .

¹⁸⁶ “Network Measurements Provide Insight Into Global Facebook Outages,” NetBlocks, 14 de março de 2019, https://netblocks.org/reports/global-facebook-outage-analysis-Prybp2A7 .

¹⁸⁷ Jann Horn, “Reading Privileged Memory With a Side-Channel”, Google, postagem do blog Project Zero , 3 de janeiro de 2018, https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side .html .

¹⁸⁸ Brad Robinson, “A Simplified Explanation of the“ Meltdown ”CPU Vulnerability,” Hackernoon, 11 de janeiro de 2018, https://hackernoon.com/a-simplified-explanation-of-the-meltdown-cpu-vulnerability-ad316cd0f0de .

¹⁸⁹ “Meltdown and Spectre,” página de recursos MeltdownAttack.com, https://meltdownattack.com/#faq-systems-meltdown ; e Zach Whittaker, “Critical Flaws Revealed to Affect Most Intel Chips Since 1995”, ZDNet, 3 de janeiro de 2018, https://www.zdnet.com/article/security-flaws-affect-every-intel-chip-since- Vulnerável a processadores de braço de 1995 .

¹⁹⁰ Laura Hautala, “Specter and Meltdown: Details You Need on Aqueles Big Chip Flaws”, CNet, 8 de janeiro de 2018, https://www.cnet.com/news/spectre-meltdown-intel-arm-amd-processor- cpu-chip-flaw-vulnerability-faq .

¹⁹¹ Paul Miller, “Explaining Meltdown With Parallel Worlds, Libraries, and a Bank Heist” , Verge , 6 de janeiro de 2018, https://www.theverge.com/2018/1/6/16854668/meltdown-spectre-hack- explicado-banco-heist-analogia .

¹⁹² Artem Dinaburg, “An Accessible Overview of Meltdown and Spectre, Part 2,” Trail of Bits blog post, 22 de março de 2018, https://blog.trailofbits.com/2018/03/22/an-accessible-overview- of-meltdown-and-specter-part-2 .

¹⁹³ Russell Brandom, “The CPU Catastrophe Will Hit Hardest in the Cloud” , Verge , 4 de janeiro de 2018, https://www.theverge.com/2018/1/4/16850120/meltdown-spectre-vulnerability-cloud-aws -google-cpu .

¹⁹⁴ Ted Greenwald e Jack Nicas, “Intel Wrestled With Chip Flaws for months,” Wall Street Journal, 5 de janeiro de 2018, https://www.wsj.com/articles/intel-wrestled-with-chip-flaws-for- meses-1515110151? mod = article_inline .

¹⁹⁵ Robert McMillan e Liza Lin, “Intel Warned Chinese Companies of Chip Flaws Before US Government”, Wall Street Journal, 28 de janeiro de 2018, https://www.wsj.com/articles/intel-warned-chinese-companies-of -chip-flaws-before-us-government-1517157430 .

¹⁹⁶ Stephen Nellis, “Intel Did Not Tell US Cyber Officials About Chip Flaws Até Tornou-se Pública”, Reuters, 22 de fevereiro de 2018, https://www.reuters.com/article/us-cyber-intel/intel-did-not -diga-nos-oficiais-cibernéticos-sobre-falhas-de-chip-até-tornado-público-idUSKCN1G62PS ; e Tom Warren, “Intel Didn’t Warn US Government About CPU Security Flaws Até They Were Public” , Verge , 23 de fevereiro de 2018, https://www.theverge.com/2018/2/23/17043768/intel-meltdown -spectre-no-us-goverment-warning .

¹⁹⁷ Patrick Tucker, “How Long Did the US Government Know About Specter and Meltdown?” Defense One, 6 de fevereiro de 2018, https://www.defenseone.com/technology/2018/02/how-long-did-us-government-know-about-spectre-and-meltdown/145776/ .

¹⁹⁸ US Senate, “Complex Cybersecurity Vulnerabilities: Lessons Learned From Specter and Meltdown,” US Senate Committee on Commerce, Science, and Transportation Audition, 11 de julho de 2018, https://www.commerce.senate.gov/2018/7/ complex-cyber-segurança-vulnerabilidades-lições-aprendidas-com-espectro-e-derretimento ; e Sean Lyngaas, “Senators Question Vulnerability Disclosure Process After Specter and Meltdown Stumbles,” Cyberscoop, 11 de julho de 2018, https://www.cyberscoop.com/senators-question-vulnerability-disclosure-process-spectre-meltdown-stumbles .

¹⁹⁹ John Thune, “Majority Statement,” em “Complex Cybersecurity Vulnerabilities: Lessons Learned From Specter and Meltdown,” US Senate Committee on Commerce, Science, and Transportation Audition, 11 de julho de 2018, https: //www.commerce.senate. gov / 2018/7 / complex-cybersecurity-vulnerabilities-lições aprendidas com o espectro e o colapso .

²⁰⁰ Tom Warren, “Microsoft Halts AMD Meltdown and Specter Patches After Reports of Unbootable PCs,” Verge , 9 de janeiro de 2018, https://www.theverge.com/2018/1/9/16867068/microsoft-meltdown-spectre- security-updates-amd-pcs-issues .

²⁰¹ Tom Warren, “Epic Games Blames Meltdown CPU Performance Issues for Fortnite Downtime,” Verge , 6 de janeiro de 2018, https://www.theverge.com/2018/1/6/16857878/meltdown-cpu-performance-issues- épico-jogos-fortnite .

²⁰² John Leyden, “Meltdown and Spectre, One Year On: Feared CPU Slowdown Never Really Materialized”, Daily Swig, 31 de janeiro de 2019, https://portswigger.net/daily-swig/meltdown-and-spectre-one-year -on-temido-cpu-desaceleração-nunca-realmente-materializado .

²⁰³ Catalin Cimpanu, “Researchers Discover Seven New Meltdown and Specter Attacks,” ZDNet, 14 de novembro de 2018, https://www.zdnet.com/article/researchers-discover-seven-new-meltdown-and-spectre-attacks .

²⁰⁴ Lily Hay Newman, “The Elite Intel Team Still Fighting Meltdown and Spectre,” Wired , 3 de janeiro de 2019, https://www.wired.com/story/intel-meltdown-spectre-storm .

²⁰⁵ “Information on Capital One Cyber Incident,” Capital One, atualizado em 23 de setembro de 2019, https://www.capitalone.com/facts2019 .

²⁰⁶ Riyaz Walikar, “An SSRF, Privileged AWS Keys and the Capital One Breach”, Appsecco, 4 de agosto de 2019, https://blog.appsecco.com/an-ssrf-privileged-aws-keys-and-the-capital -one-breach-4c3c2cded3af .

²⁰⁷ “Seattle Tech Worker Arrested for Data Theft Involving Large Financial Services Company,” Departamento de Justiça dos EUA, comunicado à imprensa, 29 de julho de 2019, https://www.justice.gov/usao-wdwa/pr/seattle-tech-worker -arrested-data-theft-envolvendo-large-financial-services-company .

²⁰⁸ Departamento de Justiça dos EUA, “Seattle Tech Worker Arrested for Data Theft Involving Large Financial Services Company.”

²⁰⁹U.S. v. Paige Thompson , Tribunal Distrital dos Estados Unidos para o Distrito Ocidental de Washington em Seattle, Reclamação Criminal, 29 de julho de 2019, https://www.justice.gov/usao-wdwa/press-release/file/1188626/ download .

²¹⁰ James Rundle e Catherine Stupp, “Capital One Breach Highlights Dangers of Insider Threats,” Wall Street Journal, 31 de julho de 2019, https://www.wsj.com/articles/capital-one-breach-highlights-dangers-of -insider-ameaças-11564565402 .

²¹¹ Jenny Surane e Lananh Nguyen, “Capital One Touted the Data Cloud’s Safety. Then a Hacker Breached It ”, Los Angeles Times, 31 de julho de 2019, https://www.latimes.com/business/story/2019-07-30/capital-one-cloud-safety-hacker-breach .

²¹² Robert McMillan, “Capital One Breach Casts Shadow Over Cloud Security”, Wall Street Journal, 30 de julho de 2019, https://www.wsj.com/articles/capital-one-breach-casts-shadow-over-cloud- security-11564516541 ; e David Henry, “Capital One Customer Data Breach Rattles Investors”, Reuters, 30 de julho de 2019,

https://www.reuters.com/article/us-capital-one-fin-cyber-amazon-com/capital-one-customer-data-breach-rattles-investors-idUSKCN1UP1LD.

²¹³ Jim Jordan, Michael Cloud e Mark Meadows, carta para Richard D. Fairbank, US House of Representatives, Committee on Oversight and Reform, 1 de agosto de 2019, https://republicans-oversight.house.gov/wp-content/ uploads / 2019/08 / 2019-08-01-JDJ-MC-MM-to-Fairbank-Cap-One-re-Capital-One-Breach.pdf ; e Jim Jordan, Michael Cloud e Mark Meadows, carta para Jeff Bezos, US House of Representatives, Committee on Oversight and Reform, 1 de agosto de 2019, https://republicans-oversight.house.gov/wp-content/uploads/ 2019/08 / 2019-08-01-JDJ-MC-MM-to-Bezos-AWS-re-Capital-One-Breach.pdf .

²¹⁴ Ron Wyden, carta para Jeff Bezos, Senado dos EUA, 5 de agosto de 2019, https://online.wsj.com/public/resources/documents/AmazonLetter080519.pdf?mod=article_inline ; e Elizabeth Warren, carta para Richard D. Fairbank, Senado dos EUA, 8 de agosto de 2019,

https://www.warren.senate.gov/imo/media/doc/2019.08.08%20Letter%20to%20Capital%20One%20re%20recent%20massive%20data%20breach.pdf.

²¹⁵ Jason Murdock, “Amazon Refuses Blame for Capital One Data Breach, Says Its Cloud Services Were ‘Not Compromised in Any Way’” , Newsweek , 30 de julho de 2019, https://www.newsweek.com/amazon-capital-one -hack-data-vazamento-violação-paige-thompson-cybercrime-1451665 .

²¹⁶ Brian Krebs, “What We Can Learn From the Capital One Hack”, Krebs on Security , postagem no blog, 19 de agosto de 2019, https://krebsonsecurity.com/2019/08/what-we-can-learn-from- the-capital-one-hack .

²¹⁷ Rob Wright e Chris Kanaracus, “Capital One Hack Highlights SSRF Concerns for AWS”, Tech Target, 5 de agosto de 2019, https://searchsecurity.techtarget.com/news/252467901/Capital-One-hack-highlights-SSRF- preocupações-para-AWS .

²¹⁸ “Anunciando atualizações para Amazon EC2 Instance Metadata Service,” AWS, 19 de novembro de 2019, https://aws.amazon.com/about-aws/whats-new/2019/11/announcing-updates-amazon-ec2-instance -metadata-service .

²¹⁹ “Dois hackers chineses associados ao Ministério de Segurança do Estado acusados de campanhas globais de invasão de computadores que visam à propriedade intelectual e informações comerciais confidenciais”, Departamento de Justiça dos EUA, comunicado à imprensa, 20 de dezembro de 2018, https://www.justice.gov/ opa / pr / two-chinese-hackers-associated-minister-state-security-charge-global-computer-intrusion .

²²⁰ Jack Stubbs, Joseph Menn e Christopher Bing, “Inside the West’s Failed Fight Against China’s ‘Cloud Hopper’ Hackers”, Reuters, 26 de junho de 2019, https://www.reuters.com/investigates/special-report/china -cyber-cloudhopper .

²²¹ Ibid.

²²² Rob Barry e Dustin Volz, “Ghosts in the Clouds: Inside China’s Major Corporate Hack”, Wall Street Journal , 30 de dezembro de 2019, https://www.wsj.com/articles/ghosts-in-the-clouds-inside -chinas-major-corporate-hack-11577729061 .

²²³ Jack Stubbs, Joseph Menn e Christopher Bing, “Inside the West’s Failed Fight Against China’s ‘Cloud Hopper’ Hackers.”

²²⁴ Prashanth Chandrasekar, “What Is Managed Cloud?” Rackspace, postagem do blog, 4 de maio de 2019, https://www.rackspace.com/blog/what-is-managed-cloud#:~:text=What%20is%20a%20managed%20cloud%20services%20provider%3F , infraestrutura% 20e% 20application% 20level% 20support ; e “Managed Service Provider Partners” AWS, acessado em 16 de agosto de 2020, https://aws.amazon.com/partners/msp .

²²⁵ “Operation Cloud Hopper,” PwC and BAE Systems, abril de 2017, https://www.pwc.co.uk/cyber-security/pdf/cloud-hopper-report-final-v4.pdf .

²²⁶ Stubbs, Menn e Bing, “Inside the West’s Failed Fight against China’s ‘Cloud Hopper’ Hackers.”

²²⁷ Stubbs, Menn e Bing, “Inside the West’s Failed Fight against China’s ‘Cloud Hopper’ Hackers.”

Fonte: https://carnegieendowment.org/2020/08/31/cloud-security-primer-for-policymakers-pub-82597

Tags: cloudreport

INTRODUÇÃO

CAPÍTULO 1: O QUE É A NUVEM?

DEFININDO COMPUTAÇÃO EM NUVEM

TECNOLOGIAS SUBJACENTES

MODELOS DE IMPLANTAÇÃO DE NUVEM

CAPÍTULO 2: AS ORIGENS E EVOLUÇÃO DA NUVEM E SEU MERCADO

EXPANSÃO GLOBAL

TENDÊNCIAS DE MERCADO (2011–2018)

GUERRAS DE PREÇOS

UM MERCADO GLOBAL E NUVENS EM HIPERESCALA

CHINA E A NUVEM

A CRESCENTE NUVEM GLOBAL

CAPÍTULO 3: SEGURANÇA NA NUVEM

O ESTADO DE (CONTINUAÇÃO) DA INSEGURANÇA CIBERNÉTICA

A SEGURANÇA DA NUVEM

ESTUDOS DE CASO DE GRANDES INCIDENTES

MAPEAMENTO DE VETORES DE RISCO DE FORMA MAIS SISTEMÁTICA

VULNERABILIDADES DE HIPERVISOR

DE QUEM É O FARDO? MODELOS DE RESPONSABILIDADE COMPARTILHADA PARA SEGURANÇA

ESTRUTURA DE GRAVIDADE DE INCIDENTE CIBERNÉTICO NA NUVEM

CAPÍTULO 4: QUESTÕES DE POLÍTICA PÚBLICA ADICIONAIS A CONSIDERAR

GESTÃO DE DADOS

Localização de dados

EMPRESAS DE TECNOLOGIA E INFLUÊNCIA GEOPOLÍTICA

CONSIDERAÇÕES ANTITRUSTE

A NUVEM PRECISA DE PROTEÇÃO

ÁREAS PROMISSORAS PARA PESQUISAS FUTURAS RELACIONADAS À SEGURANÇA

APÊNDICE A: INCIDENTES NOTÁVEIS ​​RELACIONADOS À NUVEM

CASO 1: INTERRUPÇÃO DA COSTA LESTE DA AMAZON WEB SERVICES EM FEVEREIRO DE 2017

CASO 2: INTERRUPÇÃO DO MICROSOFT AZURE EM SETEMBRO DE 2018

CASO 3: INTERRUPÇÃO DO GOOGLE CLOUD EM NOVEMBRO DE 2018

CASO 4: EXCLUSÃO DO MICROSOFT AZURE SQL EM JANEIRO DE 2019

CASO 5: MARÇO DE 2019 AJUSTE DO SERVIDOR DO FACEBOOK

CASO 6: A RESPOSTA ÀS VULNERABILIDADES DE FUSÃO E ESPECTRO

CASO 7: VIOLAÇÃO DE DADOS CAPITAL ONE DE JULHO DE 2019

CASO 8: OPERAÇÃO CLOUD HOPPER

SOBRE OS AUTORES

AGRADECIMENTOS

ABREVIAÇÕES

NOTAS

Matérias Relacionadas

Veja mais..

APÊNDICE A: INCIDENTES NOTÁVEIS RELACIONADOS À NUVEM