Notícias para administradores do Google Cloud

Desvendando o mistério do gerenciamento de chaves de segurança mais forte

Um dos erros “clássicos” de segurança de dados que implica a criptografia é a criptografia das informações e não proteger a chave de criptografia da maneira adequada. Para piorar a situação, um problema infelizmente comum é deixar a chave “próxima” das informações, como no mesmo banco de dados ou no mesmo sistema dos arquivos criptografados. Essas práticas foram supostamente um fator que contribuiu para várias violações de segurança importantes. Uma investigação revelou que, em alguns casos, a criptografia foi aplicada para atender aos critérios de segurança, mas sem um modelo de ameaça claro, o gerenciamento de chaves foi uma reflexão tardia ou nem mesmo considerado.

Pode-se argumentar que a chave deve ser melhor protegida do que os dados que criptografa (ou, de modo mais geral, que a chave deve ter controles mais fortes sobre ela do que os dados que ela protege). Se a chave for armazenada perto dos dados, a implicação é que os controles que protegem a chave não são, de fato, melhores.

Os regulamentos oferecem orientação sobre o gerenciamento de chaves, mas poucos fornecem conselhos precisos sobre onde armazenar as chaves de criptografia em relação aos dados criptografados. Manter as senhas “longe” dos dados é obviamente uma boa prática de segurança, mas infelizmente mal compreendida por muitas organizações. Como você mede “longe” no campo da informática? 

Agora, vamos adicionar a computação em nuvem à equação. Uma linha de pensamento particular que surgiu nos últimos anos foi: “assim como você não pode manter a chave no mesmo banco de dados, não pode mantê-la na mesma nuvem.”

A reação esperada aqui é que metade dos leitores dirá “Obviamente!” enquanto a outra metade pode dizer “O quê? Isso é loucura!” É exatamente por isso que é um grande tópico de análise!

Por enquanto, primeiro, vamos apontar o óbvio: não existe algo como “a nuvem”. E, não, este não é um ditado popular sobre o que é “o computador de outra pessoa”. Aqui estamos falando sobre a falta de algo monolítico chamado “a nuvem”.

Por exemplo, quando o Google criptografa dados em repouso, há várias opções de gerenciamento de chaves. Na verdade, eles sempre usam a criptografia padrão e armazenam as chaves com segurança (contra modelos e requisitos de ameaças específicos) e de forma transparente. Você pode ler sobre isso em detalhes neste documento. O que você notará, no entanto, é que as chaves estão sempre separadas dos dados criptografados com muitas, muitas barreiras de muitos tipos diferentes. Por exemplo, no desenvolvimento de aplicativos, uma boa prática comum é manter as chaves em um projeto separadas das cargas de trabalho. Portanto, isso introduziria limites adicionais, como rede, identidade, configuração, serviço e provavelmente outros limites também. A questão é que manter as chaves “na mesma nuvem” não significa necessariamente que o mesmo erro está sendo cometido ao manter as chaves no mesmo banco de dados…, exceto em alguns casos especiais em que essa prática seria um erro ( discutido abaixo). 

Além disso, a nuvem introduz uma nova dimensão no risco de manter a chave “perto” dos dados: onde a chave é armazenada fisicamente na frente de quem controla a chave. Por exemplo, a chave está próxima dos dados se estiver dentro de um dispositivo de hardware seguro (por exemplo, um HSM) localizado na mesma rede (ou: no mesmo datacenter em nuvem) que os dados? Ou a chave está próxima dos dados se estiver localizada em um sistema em outro país, mas as pessoas com credenciais para acessar os dados também podem acessar a chave com elas? Isso também levanta a questão de quem é o responsável final se a chave for comprometida, complicando ainda mais as coisas. Tudo isso levanta dimensões interessantes a serem exploradas.

Por fim, lembre-se de que a maior parte da discussão aqui se concentra nos dados em repouso (e talvez um pouco nos dados em trânsito, mas não nos dados em uso).

Riscos

Agora que entendemos que o conceito de “na mesma nuvem” tem nuances, vamos examinar os riscos e requisitos que estão conduzindo o comportamento em torno do armazenamento de chaves de criptografia.

Antes de começarmos, lembre-se de que se você tiver um aplicativo local com uma arquitetura mal projetada que armazena as chaves no mesmo banco de dados ou no mesmo disco que seus dados criptografados e esse aplicativo for migrado para a nuvem, o problema, é claro, também migra para a nuvem. A solução para esse desafio pode ser usar mecanismos de gerenciamento de chaves nativos da nuvem (e, sim, isso significa mudar o aplicativo).   

Dito isso, aqui estão alguns dos principais riscos e problemas:

Erro humano

Primeiro, um risco altamente visível é, obviamente, o erro humano não malicioso que leva à divulgação de chaves, perda, roubo, etc. . Pense nos erros dos desenvolvedores, o uso de uma fonte de entropia deficiente, a configuração errada ou permissões relaxadas, etc. Não há nada específico para a nuvem sobre eles, mas seu impacto tende a ser mais prejudicial na nuvem pública. Em teoria, os erros do provedor de nuvem que levam a uma possível revelação da chave também estão neste ponto.

Atacante externo

Em segundo lugar, o roubo de chaves por um invasor externo também é um desafio que remonta à era pré-nuvem. Jogadores de primeira linha são conhecidos por terem atacado sistemas de gerenciamento de chaves (KMS) para obter maior acesso aos dados. Eles também sabem como acessar e ler logs de aplicativos, bem como observar o tráfego de rede de aplicativos, o que pode fornecer pistas sobre a localização das chaves. Instintivamente, muitos profissionais de segurança que ganharam a maior parte de sua experiência pré-nuvem se sentem melhor com um KMS se ele estiver atrás de várias camadas de firewalls. Os invasores externos tendem a encontrar os erros humanos mencionados acima e, como resultado, transformar essas fraquezas em pontos fracos.

Ameaça interna

Terceiro, e é aqui que as coisas ficam interessantes: e quanto às ameaças internas? Os modelos de computação em nuvem envolvem dois modelos diferentes de ameaça interna: internos no lado da organização do usuário e aqueles no lado do provedor de serviços em nuvem. Embora parte da atenção do público esteja voltada para provedores de serviços em nuvem, ou CSPs (Provedores de Serviços em Nuvem), é o lado do cliente que geralmente possui as credenciais válidas para acessar os dados. Embora alguns funcionários de provedores de CSP possam (teoricamente e sujeitos a muitas verificações de segurança com os níveis necessários de conluio maciço) acessar os dados, é no lado do cliente na nuvem que eles realmente têm acesso direto a seus dados na nuvem usando credenciais válidas. Do ponto de vista da modelagem de ameaças, a maioria dos criminosos encontrará o elo mais fraco – provavelmente na organização do usuário da nuvem – para explorar primeiro, sem exigir mais esforço depois.

Conformidade

Em quarto lugar, pode haver mandatos e regulamentos que prescrevem o manuseio das chaves de uma maneira particular. Muitos deles são anteriores à computação em nuvem, portanto, não oferecem orientação explícita para a nuvem. É útil diferenciar entre requisitos explícitos, requisitos implícitos e o que pode ser chamado de requisitos “interpretados” ou internos. Por exemplo, uma organização pode ter uma política de sempre manter as chaves de criptografia em um determinado sistema, protegidas de uma maneira particular. Essas políticas internas podem estar em vigor há anos e sua origem exata com base no risco costuma ser difícil de rastrear porque essa origem pode ter décadas. Na verdade, sistemas e práticas de segurança complexos, muitas vezes legados, poderiam ser simplificados (e mais compreensíveis) com técnicas mais modernas oferecidas por meio de recursos e práticas de computação em nuvem.

Além disso, algumas empresas multinacionais podem ter sido objeto de algum tipo de questão legal resolvida e selada com um estado ou entidade governamental separada de qualquer tipo de atividade de conformidade regulatória. Nesses casos, as obrigações podem exigir a aplicação de algumas salvaguardas técnicas que não podem ser amplamente compartilhadas dentro da organização.

Soberania de dados

Por último, e é aqui que as coisas rapidamente mudam para fora do domínio digital, existem riscos que estão fora do âmbito da cibersegurança. Isso pode estar relacionado a várias questões de soberania de dados e soberania digital, e até mesmo riscos geopolíticos. Em suma, não importa se esses riscos são reais ou percebidos (ou se o mero fato de ter a chave acabaria por impedir sua divulgação). O importante é que os requisitos para controle direto das chaves de criptografia sejam atendidos. Por exemplo, foi relatado que temores a “intimações cegas ou a terceiros” motivaram algumas das decisões das organizações sobre segurança de dados. 

Esses cinco riscos estão acima da coisa “real”? Faz diferença que os riscos não sejam reais, mas que uma organização planeje agir como se eles fossem? E se uma organização os leva a sério, quais opções de arquitetura eles têm?

Arquiteturas e abordagens

Em primeiro lugar, uma afirmação forte: as arquiteturas de nuvem modernas tornam alguns dos erros de criptografia menos prováveis ​​de serem cometidos. Se uma determinada função de usuário não tiver acesso ao KMS em nuvem, não haverá como obter as chaves “acidentalmente” (o que equivale a encontrá-las em um disco em um diretório compartilhado, por exemplo). Na verdade, a identidade serve como um forte limite na nuvem. 

É notável que contar com, por exemplo, um firewall (barreira de rede) em vez de um sistema de autenticação bem projetado (barreira de identidade) é uma relíquia dos tempos pré-nuvem. Além disso, o controle de acesso à nuvem ou os logs da nuvem sempre que uma chave é usada, como e por quem, pode ser uma segurança melhor do que a maioria no local poderia aspirar.

Chaves de criptografia em nuvem armazenadas em sistemas baseados em software

Por exemplo, se práticas específicas de gerenciamento de chaves precisam ser aplicadas (conformidade interna, risco, localização, revogação, etc.), pode ser usado Google Cloud KMS com CMEK. Agora, tomando a definição ampla, a chave está na mesma nuvem (Google Cloud), mas a chave definitivamente não está no mesmo lugar que os dados (detalha como as chaves são armazenadas). Pessoas que podem acessar os dados (por exemplo, por meio de credenciais válidas para acesso aos dados, ou seja, clientes internos) não podem acessar a chave, a menos que tenham permissões de acesso específicas para acessar KMS (a identidade serve como uma barreira forte). Portanto, nenhum desenvolvedor de aplicativo pode obter acidentalmente as chaves ou projetar o aplicativo com chaves incorporadas.

Isso aborda a maioria dos riscos mencionados, mas obviamente não aborda alguns deles. Observe que, embora o cliente na nuvem não controle as proteções que separam as chaves dos dados, eles podem ler sobre eles.

Chaves de criptografia em nuvem armazenadas em sistemas baseados em hardware

Em seguida, se houver necessidade de garantir que uma pessoa não consiga acessar a chave, independentemente de suas permissões de conta, um HSM em nuvem é uma maneira de armazenar as chaves em um dispositivo de hardware. Nesse caso, a barreira que separa as chaves dos dados não é apenas a identidade, mas as características de segurança de um dispositivo de hardware e todos os controles de segurança validados que se aplicam ao local do dispositivo e em torno dele. Isso aborda quase todos os riscos acima, mas não aborda todos eles. Também incorre em alguns custos e possíveis atritos. 

Também neste caso, embora o cliente da nuvem possa solicitar garantias sobre o uso de um dispositivo de segurança de hardware e outros controles, o cliente da nuvem não controla as proteções que separam as chaves dos dados, mas continua a contar com a confiança do provedor de serviços em nuvem no manuseio do hardware. Portanto, embora o acesso ao material das chaves seja mais restrito com as chaves HSM do que com as chaves do software, o acesso ao uso das chaves não é inerentemente mais seguro. Além disso, a chave em um HSM hospedado pelo provedor é considerada sob o controle lógico ou físico do provedor na nuvem, portanto, não está em conformidade com o verdadeiro significado ou filosofia do requisito “Hold Your Own Key” (HYOK )

Chaves de criptografia em nuvem armazenadas fora da infraestrutura do provedor

Por último, existe uma maneira de realmente lidar com os riscos mencionados, incluindo o último ponto sobre questões geopolíticas. E a decisão é simplesmente praticar Hold Your Own Key (HYOK) implementado com tecnologias como Google Cloud External Key Manager (EKM). Neste cenário, bugs do provedor, erros, ataques externos às redes do provedor, os internos do provedor de serviços em nuvem não importam, pois a chave nunca aparece lá. Um provedor de nuvem não pode revelar a chave de criptografia para ninguém porque eles não a possuem. Isso aborda todos os riscos acima, mas incorre em alguns custos e possíveis atritos. Aqui, o cliente da nuvem controla as proteções que separam as chaves dos dados e pode solicitar garantias de como a tecnologia EKM é implementada. 

Naturalmente, essa abordagem é criticamente diferente de qualquer outra abordagem, já que até mesmo os dispositivos HSM gerenciados pelo cliente localizados no data center do provedor na nuvem não oferecem o mesmo nível de garantia.

Pontos principais

• Não há proibição total de salvar chaves com o mesmo provedor de nuvem que seus dados ou “na mesma nuvem”. O próprio conceito de “chave na mesma nuvem” é matizado e deve ser revisado à luz de seus regulamentos e modelos de ameaça – alguns riscos podem ser novos, mas outros serão totalmente mitigados pela mudança para a nuvem. Revise seus riscos, tolerâncias a riscos e motivações que orientam suas principais decisões de gerenciamento.
• Considere fazer um inventário de suas chaves e observe a que distância ou proximidade estão de seus dados. Em geral, estão melhor protegidos que os dados? As proteções correspondem ao modelo de ameaça que você tem em mente? Se novas ameaças potenciais forem descobertas, implante os controles necessários no ambiente.
• As vantagens para o gerenciamento de chaves usando o Google Cloud KMS incluem IAM completo e consistente, políticas, justificativa de acesso, registro, bem como provavelmente maior agilidade para projetos que usam tecnologias nativas na nuvem. Portanto, use seu provedor de nuvem KMS para a maioria das situações que não exigem confiança terceirizada ou outras situações.
• Os casos em que é necessário manter as chaves fora da nuvem são claramente especificados por regulamentos ou requisitos de negócios; um conjunto de situações comuns para isso será discutido no próximo blog. Fique informado!

---

Apresentação do novo Painel Público de Status da Plataforma Google Maps

A equipe da plataforma de Google Maps se esforça para fornecer o mais alto nível de serviço possível aos nossos usuários. Ainda assim, de vez em quando, ocorrem interrupções inesperadas de serviço. Quando sua equipe passa por uma interrupção ou outro desafio técnico, uma das primeiras avaliações a fazer é se o problema é com um provedor de serviços externo ou interno. Como parte de nosso compromisso com a transparência e velocidade na comunicação do status de nossos produtos e incidentes quando eles ocorrem, implementamos o Painel Público de Status da Plataforma Google Maps. 

O Painel Público de Status fornece informações sobre o status dos produtos geralmente disponíveis e cobertos pelo SLA da plataforma Google Maps. Você pode verificar o painel para ver o status atual de qualquer um desses serviços. Você pode até clicar em “Exibir histórico” para ver os incidentes ocorridos nos últimos 365 dias. Os incidentes exibidos no painel são classificados como interrupções (laranja) ou cortes (vermelho), dependendo de sua gravidade. Todos os incidentes são verificados primeiro por nossos engenheiros de suporte, portanto, pode haver um pequeno atraso em relação ao momento em que realmente ocorreram. 

Para acesso rápido ao painel, você pode marcar o site em sua barra de favoritos. E em um futuro próximo, você poderá acessar as atualizações por meio de notificações push. Se você tiver um problema que não está listado no painel, entre em contato com o Suporte. E para saber mais sobre o que é postado no painel, verifique as Perguntas frequentes (FAQ). 

O Painel Público de Status é o primeiro lugar para verificar quando você descobrir um problema que o afeta. Mas não é a única maneira de relatar problemas conhecidos ou informados e fornecer suporte. Dependendo de sua situação e necessidades específicas, você também pode usar um de nossos outros recursos. Aqui está um resumo de alguns outros que você deve conhecer: 

Rastreador de problemas

Nosso Rastreador de problemas público é onde mantemos ativamente uma lista de problemas conhecidos e relatados. O rastreador de problemas inclui problemas técnicos que não são sérios o suficiente para aparecer no Painel de Status. É aqui que você pode visualizar facilmente os bugs já relatados e adicionar seus próprios comentários para ajudar nossas equipes a investigar problemas ou identificar soluções. No caso de ocorrer uma falha, uma mensagem de banner aparecerá na seção de suporte do Google Maps do console do Google Cloud, com um link ao rastreador de problemas para obter mais informações que permitam que você saiba o status do problema em tempo real. Se você deseja relatar um bug ou solicitar um novo recurso, comece enviando uma solicitação. Incluir um código de amostra ou captura de tela nos ajudará a identificar o problema e responder mais rapidamente.

Grupos de notificação por e-mail

Para obter atualizações técnicas sobre os produtos da plataforma do Google Maps, notificações de interrupções e anúncios de recursos, você pode se inscrever no grupo de notificação por email do Google para receber atualizações diretamente em sua caixa de entrada. 

Contatos Essenciais 

Em breve, o Google começará a enviar notificações importantes para seus Contatos Essenciais. Para personalizar quais membros da equipe receberão essas notificações da plataforma do Google Maps em um futuro próximo, você pode definir seus Contatos Essenciais no console do Google Cloud, fornecendo sua própria lista de contatos. Você pode adicionar aliases individuais e de grupo para garantir que está reduzindo proativamente o impacto das mudanças de pessoal. Você pode aprender mais sobre as categorias de notificação e como habilitar os Contatos essenciais aqui. 

Visite a documentação do Google sobre gerenciamento de incidentes para obter mais informações. E para saber mais sobre a plataforma do Google Maps, visite o site.