Segurança do Azure para aplicativos nativos de nuvem

Dica

Esse conteúdo é um trecho do eBook, Architecting Cloud Native .NET Applications for Azure, disponível no .NET Docs ou como um PDF para download gratuito que pode ser lido offline.

Baixar PDF

Aplicativos nativos de nuvem podem ser mais fáceis e difíceis de proteger do que os aplicativos tradicionais. No lado negativo, você precisa proteger mais aplicativos menores e dedicar mais energia para criar a infraestrutura de segurança. A natureza heterogênea de linguagens de programação e estilos na maioria das implantações de serviço também significa que você precisa prestar mais atenção aos boletins de segurança de muitos provedores diferentes.

Por outro lado, serviços menores, cada um com seu próprio armazenamento de dados, limitam o escopo de um ataque. Se um invasor comprometer um sistema, provavelmente será mais difícil para o invasor fazer o salto para outro sistema do que em um aplicativo monolítico. Os limites do processo são limites fortes. Além disso, se um backup de banco de dados for exposto, o dano será mais limitado, pois esse banco de dados contém apenas um subconjunto de dados e é improvável que contenha dados pessoais.

Modelagem de ameaças

Não importa se as vantagens superam as desvantagens dos aplicativos nativos de nuvem, a mesma mentalidade de segurança holística deve ser seguida. A segurança e o pensamento seguro devem fazer parte de cada etapa da história de desenvolvimento e operações. Ao planejar um aplicativo, faça perguntas como:

• Qual seria o impacto desses dados sendo perdidos?
• Como podemos limitar os danos causados por dados inválidos que estão sendo injetados nesse serviço?
• Quem deve ter acesso a esses dados?
• Há políticas de auditoria em vigor em torno do processo de desenvolvimento e lançamento?

Todas essas perguntas fazem parte de um processo chamado modelagem de ameaças. Esse processo tenta responder à pergunta de quais ameaças existem ao sistema, qual é a probabilidade das ameaças e os possíveis danos causados por elas.

Depois que a lista de ameaças for estabelecida, você precisará decidir se elas valem a pena ser atenuadas. Às vezes, uma ameaça é tão improvável e cara de se planejar para que não valha a pena gastar energia com ela. Por exemplo, algum ator de nível de estado pode injetar alterações no design de um processo que é usado por milhões de dispositivos. Agora, em vez de executar um determinado código no Anel 3, esse código é executado no Anel 0. Esse processo permite um exploit que pode burlar o hipervisor e executar o código de ataque nas máquinas bare metal, permitindo ataques a todas as máquinas virtuais em execução nesse hardware.

Os processadores alterados são difíceis de detectar sem um microscópio e conhecimento avançado sobre o design de silício desse processador. É improvável que esse cenário aconteça e seja caro para atenuar, portanto, provavelmente nenhum modelo de ameaça recomendaria criar proteção contra exploração para ele.

Ameaças mais comuns, como controles de acesso interrompidos permitindo Id ataques de incrementação (substituindo Id=2 por Id=3 na URL) ou injeção de SQL, são mais relevantes para se criar proteções contra. As mitigações para essas ameaças são bastante razoáveis para desenvolver soluções e prevenir falhas de segurança constrangedoras que mancham a reputação da empresa.

Princípio de privilégio mínimo

Uma das ideias fundadoras na segurança do computador é o PRINCÍPIO do Privilégio Mínimo (POLP). Na verdade, é uma ideia fundamental em qualquer forma de segurança, seja digital ou física. Em suma, o princípio é que qualquer usuário ou processo deve ter o menor número de direitos possíveis para executar sua tarefa.

Por exemplo, pense nos caixas de um banco: acessar o cofre é uma atividade incomum. Então, o caixa médio não pode abrir o cofre por conta própria. Para obter acesso, eles precisam escalonar sua solicitação por meio de um gerente de banco, que executa verificações de segurança adicionais.

Em um sistema de computador, um exemplo fantástico são os direitos de um usuário que se conecta a um banco de dados. Em muitos casos, há uma única conta de usuário usada para criar a estrutura do banco de dados e executar o aplicativo. Exceto em casos extremos, a conta que executa o aplicativo não precisa da capacidade de atualizar informações de esquema. Deve haver várias contas que forneçam diferentes níveis de privilégio. O aplicativo deve usar apenas o nível de permissão que concede acesso de leitura e gravação aos dados nas tabelas. Esse tipo de proteção eliminaria os ataques que visavam remover tabelas de banco de dados ou introduzir gatilhos mal-intencionados.

Quase todas as partes da criação de um aplicativo nativo de nuvem podem se beneficiar de lembrar o princípio de privilégios mínimos. Você pode encontrá-lo em ação ao configurar firewalls, grupos de segurança de rede, papéis e escopos no controle de acesso baseado em função (RBAC).

Teste de penetração

À medida que os aplicativos se tornam mais complicados, o número de vetores de ataque aumenta a uma taxa alarmante. A modelagem de ameaças é falha porque tende a ser executada pelas mesmas pessoas que criam o sistema. Da mesma forma que muitos desenvolvedores têm problemas para imaginar interações do usuário e, em seguida, criar interfaces de usuário inutilizáveis, a maioria dos desenvolvedores tem dificuldade em ver cada vetor de ataque. Também é possível que os desenvolvedores que criam o sistema não sejam bem versados em metodologias de ataque e percam algo crucial.

O teste de penetração ou o "teste de caneta" envolve trazer atores externos para tentar atacar o sistema. Esses invasores podem ser uma empresa de consultoria externa ou outros desenvolvedores com bom conhecimento de segurança de outra parte do negócio. Eles recebem carta branca para tentar subverter o sistema. Com frequência, eles encontrarão grandes falhas de segurança que precisam ser corrigidas. Às vezes, o vetor de ataque será algo totalmente inesperado, como explorar um ataque de phishing contra o CEO.

O próprio Azure está constantemente sofrendo ataques de uma equipe de hackers dentro da Microsoft. Ao longo dos anos, eles foram os primeiros a encontrar dezenas de vetores de ataque potencialmente catastróficos, fechando-os antes que possam ser explorados externamente. Quanto mais tentador um alvo, maior a probabilidade de que atores externos tentem explorá-lo, e há poucos alvos no mundo mais tentadores do que o Azure.

Monitorização

Se um invasor tentar penetrar em um aplicativo, deve haver algum aviso sobre ele. Com frequência, os ataques podem ser detectados examinando os logs dos serviços. Os ataques deixam traços característicos que podem ser identificados antes de terem sucesso. Por exemplo, um invasor que tenta adivinhar uma senha fará muitas solicitações para um sistema de logon. O monitoramento em torno do sistema de logon pode detectar padrões estranhos que estão fora de linha com o padrão de acesso típico. Esse monitoramento pode ser transformado em um alerta que pode, por sua vez, alertar uma pessoa de operações para ativar algum tipo de contramedida. Um sistema de monitoramento altamente maduro pode até mesmo tomar medidas com base nesses desvios adicionando proativamente regras para bloquear solicitações ou limitar respostas.

Protegendo a compilação

Um lugar em que a segurança geralmente é ignorada é em torno do processo de build. Não só o build deve executar verificações de segurança, como a verificação de código inseguro ou credenciais de check-in, mas o build em si deve ser seguro. Se o servidor de build estiver comprometido, ele fornecerá um vetor fantástico para introduzir código arbitrário no produto.

Imagine que um invasor está procurando roubar as senhas de pessoas que entram em um aplicativo Web. Eles podem introduzir uma etapa de construção que modifica o código baixado para espelhar qualquer solicitação de login em outro servidor. Na próxima vez que o código passar pelo build, ele será atualizado silenciosamente. A verificação de vulnerabilidade do código-fonte não capturará essa vulnerabilidade, pois ela é executada antes do build. Da mesma forma, ninguém vai identificá-lo em uma revisão de código porque os passos do build residem no servidor de build. O código explorado irá para produção, onde poderá coletar senhas. Provavelmente não há nenhum log de auditoria das alterações do processo de construção, ou pelo menos ninguém monitorando a auditoria.

Esse cenário é um exemplo perfeito de um alvo aparentemente de baixo valor que pode ser usado para comprometer o sistema. Depois que um invasor viola o perímetro do sistema, ele pode começar a trabalhar para encontrar maneiras de elevar suas permissões a ponto de causar danos reais em qualquer lugar que quiser.

Criando código seguro

O .NET Framework já é uma estrutura bastante segura. Ele evita algumas das armadilhas do código não gerenciado, como sair das extremidades das matrizes. O trabalho é feito ativamente para corrigir falhas de segurança conforme elas são descobertas. Há até um programa de recompensa por bugs que paga aos pesquisadores para encontrar problemas na estrutura e denunciá-los em vez de explorá-los.

Há muitas maneiras de tornar o código .NET mais seguro. Seguir diretrizes como as diretrizes de codificação segura para o artigo do .NET é uma etapa razoável a ser tomada para garantir que o código esteja seguro desde o início. O OWASP top 10 é outro guia inestimável para criar código seguro.

O processo de build é um bom lugar para colocar ferramentas de verificação para detectar problemas no código-fonte antes que elas entrem em produção. A maioria de cada projeto tem dependências em alguns outros pacotes. Uma ferramenta que pode verificar se há pacotes desatualizados detectará problemas em um build noturno. Mesmo ao criar imagens Docker, é útil verificar e garantir que a imagem base não tenha vulnerabilidades conhecidas. Outra coisa a verificar é que ninguém cometeu o engano de incluir acidentalmente credenciais.

Segurança interna

O Azure foi projetado para equilibrar a usabilidade e a segurança para a maioria dos usuários. Usuários diferentes terão requisitos de segurança diferentes, portanto, eles precisam ajustar sua abordagem à segurança na nuvem. A Microsoft publica uma grande quantidade de informações de segurança na Central de Confiabilidade. Esse recurso deve ser a primeira parada para os profissionais interessados em entender como funcionam as tecnologias internas de mitigação de ataque.

No portal do Azure, o Assistente do Azure é um sistema que está constantemente verificando um ambiente e fazendo recomendações. Algumas dessas recomendações foram projetadas para economizar dinheiro aos usuários, mas outras foram projetadas para identificar configurações potencialmente inseguras, como ter um contêiner de armazenamento aberto ao mundo e não protegido por uma Rede Virtual.

Infraestrutura de rede do Azure

Em um ambiente de implantação local, grande parte da energia é dedicada à configuração da rede. Configurar roteadores, switches e equipamentos semelhantes é um trabalho complicado. As redes permitem que determinados recursos conversem com outros recursos e impeçam o acesso em alguns casos. Uma regra comum de rede é restringir o acesso ao ambiente de produção a partir do ambiente de desenvolvimento na remota possibilidade de que uma parte de código parcialmente desenvolvida seja executada de forma equivocada e exclua um conjunto de dados.

Pronto para uso, a maioria dos recursos do Azure de PaaS tem apenas a configuração de rede mais básica e permissiva. Por exemplo, qualquer pessoa na Internet pode acessar um serviço de aplicativo. As novas instâncias do SQL Server geralmente são restritas, para que partes externas não possam acessá-las, mas são permitidos os intervalos de endereços IP usados pelo próprio Azure. Portanto, enquanto o SQL Server está protegido contra ameaças externas, um invasor só precisa configurar uma ponte do Azure de onde pode iniciar ataques contra todas as instâncias do SQL no Azure.

Felizmente, a maioria dos recursos do Azure pode ser colocada em uma Rede Virtual do Azure que permite um controle de acesso refinado. Semelhante à maneira como as redes locais estabelecem redes privadas protegidas do mundo inteiro, as redes virtuais são ilhas de endereços IP privados que estão localizadas dentro da rede do Azure.

Figura 9-1. Uma rede virtual no Azure.

Da mesma forma que as redes locais têm um firewall que rege o acesso à rede, você pode estabelecer um firewall semelhante no limite da rede virtual. Por padrão, todos os recursos em uma rede virtual ainda podem falar com a Internet. São apenas conexões de entrada que exigem alguma forma de exceção de firewall explícita.

Com a rede estabelecida, recursos internos, como contas de armazenamento, podem ser configurados para permitir apenas o acesso por recursos que também estão na Rede Virtual. Esse firewall fornece um nível extra de segurança, caso as chaves dessa conta de armazenamento sejam vazadas, os invasores não poderão se conectar a ele para explorar as chaves vazadas. Este cenário é outro exemplo do princípio do privilégio mínimo.

Os nós em um cluster do Kubernetes do Azure podem participar de uma rede virtual, assim como outros recursos que são mais nativos do Azure. Essa funcionalidade é chamada de Interface de Rede de Contêiner do Azure. Na verdade, ele aloca uma sub-rede dentro da rede virtual na qual máquinas virtuais e imagens de contêiner são alocadas.

Continuar pelo caminho de ilustrar o princípio de privilégios mínimos, nem todos os recursos dentro de uma Rede Virtual precisam conversar com todos os outros recursos. Por exemplo, em um aplicativo que fornece uma API Web em uma conta de armazenamento e um banco de dados SQL, é improvável que o banco de dados e a conta de armazenamento precisem conversar entre si. Qualquer compartilhamento de dados entre eles passaria pelo aplicativo Web. Portanto, um NSG (grupo de segurança de rede) pode ser usado para negar o tráfego entre os dois serviços.

Uma política de negação de comunicação entre recursos pode ser irritante de implementar, especialmente para quem vem de uma experiência anterior de uso do Azure sem restrições de tráfego. Em algumas outras nuvens, o conceito de grupos de segurança de rede é muito mais prevalente. Por exemplo, a política padrão no AWS é que os recursos não podem se comunicar entre si até que sejam habilitados por regras em um NSG. Embora mais lento para desenvolver isso, um ambiente mais restritivo fornece um padrão mais seguro. Usar práticas de DevOps adequadas, especialmente usando o Azure Resource Manager ou o Terraform para gerenciar permissões, pode facilitar o controle das regras.

Redes virtuais também podem ser úteis ao configurar a comunicação entre recursos locais e de nuvem. Uma rede virtual privada pode ser usada para anexar perfeitamente as duas redes. Essa abordagem permite a execução de uma rede virtual sem qualquer tipo de gateway para cenários em que todos os usuários estão no local. Há várias tecnologias que podem ser usadas para estabelecer essa rede. O mais simples é usar uma VPN site a site que pode ser estabelecida entre muitos roteadores e o Azure. O tráfego é criptografado e tunnelizado pela Internet ao mesmo custo por byte que qualquer outro tráfego. Para cenários em que mais largura de banda ou mais segurança é desejável, o Azure oferece um serviço chamado Express Route que usa um circuito privado entre uma rede local e o Azure. É mais caro e difícil de estabelecer, mas também mais seguro.

Controle de acesso baseado em função para restringir o acesso aos recursos do Azure

O RBAC é um sistema que fornece uma identidade para aplicativos em execução no Azure. Os aplicativos podem acessar recursos usando essa identidade em vez de ou além de usar chaves ou senhas.

Entidades de segurança

O primeiro componente no RBAC é um princípio de segurança. Um principal de segurança pode ser um usuário, grupo, principal de serviço ou identidade gerenciada.

Figura 9-2. Diferentes tipos de entidades de segurança.

• Usuário – Qualquer usuário que tenha uma conta no Azure Active Directory é um usuário.
• Grupo – Uma coleção de usuários do Azure Active Directory. Como membro de um grupo, um usuário assume as funções desse grupo além das próprias.
• Entidade de serviço – Uma identidade de segurança sob a qual os serviços ou aplicativos são executados.
• Identidade gerenciada – uma identidade do Azure Active Directory gerenciada pelo Azure. As identidades gerenciadas normalmente são usadas ao desenvolver aplicativos de nuvem que gerenciam as credenciais para autenticação nos serviços do Azure.

A entidade de segurança pode ser aplicada à maioria dos recursos. Esse aspecto significa que é possível atribuir uma entidade de segurança a um contêiner em execução no Kubernetes do Azure, permitindo que ele acesse segredos armazenados no Key Vault. Uma função do Azure pode assumir uma permissão permitindo que ele fale com uma instância do Active Directory para validar um JWT para um usuário chamador. Depois que os serviços são habilitados com um principal de serviço, suas permissões podem ser gerenciadas granularmente usando funções e escopos.

Funções

Uma entidade de segurança pode assumir muitas funções ou, usando uma analogia mais sartorial, usar muitos chapéus. Cada função define uma série de permissões, como "Ler mensagens do endpoint do Azure Service Bus". O conjunto efetivo de permissões de um principal de segurança é a combinação de todas as permissões atribuídas a todas as funções que um principal de segurança possui. O Azure tem um grande número de funções internas e os usuários podem definir suas próprias funções.

Figura 9-3. Definições de função RBAC.

Integradas ao Azure, também existem várias funções de alto nível, como Proprietário, Colaborador, Leitor e Administrador de Conta de Usuário. Com a função de Proprietário, um principal de segurança pode acessar todos os recursos e atribuir permissões aos outros. Um colaborador tem o mesmo nível de acesso a todos os recursos, mas não pode atribuir permissões. Um Leitor só pode exibir recursos existentes do Azure e um Administrador de Conta de Usuário pode gerenciar o acesso aos recursos do Azure.

Funções internas mais granulares, como Colaborador de Zona DNS , têm direitos limitados a um único serviço. As entidades de segurança podem assumir qualquer número de funções.

Escopos

As funções podem ser aplicadas a um conjunto restrito de recursos no Azure. Por exemplo, ao aplicar o escopo ao exemplo anterior de leitura de uma fila do Barramento de Serviço, você pode restringir a permissão a uma única fila: "Ler mensagens do ponto de extremidade do Azure Service Bus blah.servicebus.windows.net/queue1".

O escopo pode ser tão estreito quanto um único recurso ou pode ser aplicado a um grupo de recursos inteiro, assinatura ou até mesmo grupo de gerenciamento.

Ao testar se uma entidade de segurança tem determinada permissão, a combinação de função e escopo é levada em conta. Essa combinação fornece um poderoso mecanismo de autorização.

Negar

Anteriormente, somente as regras de "permitir" eram aceitas para o RBAC. Esse comportamento tornou alguns escopos difíceis de criar. Por exemplo, permitir que uma entidade de segurança acesse todas as contas de armazenamento, exceto uma necessária para conceder permissão explícita a uma lista potencialmente interminável de contas de armazenamento. Sempre que uma nova conta de armazenamento fosse criada, ela teria que ser adicionada a essa lista de contas. Isso aumentou a sobrecarga de gerenciamento que certamente não era desejável.

As regras de negação têm precedência sobre as regras de permissão. Agora, representar o mesmo escopo "permitir todos menos um" poderia ser representado por duas regras: "permitir todos" e "negar um específico". Negar regras não só facilita o gerenciamento, mas permite recursos que são mais seguros negando o acesso a todos.

Verificando o acesso

Como você pode imaginar, ter um grande número de funções e escopos pode tornar bastante difícil descobrir a permissão efetiva de uma entidade de serviço. Empilhar regras de negação em cima disso só serve para aumentar a complexidade. Felizmente, há uma calculadora de permissões que pode mostrar as permissões efetivas para qualquer principal de serviço. Normalmente, ele é encontrado na guia IAM no portal, conforme mostrado na Figura 9-3.

Figura 9-4. Calculadora de permissões para um serviço de aplicativo.

Protegendo segredos

Senhas e certificados são um vetor de ataque comum para invasores. O hardware de quebra de senha pode fazer um ataque de força bruta e tentar adivinhar bilhões de senhas por segundo. Portanto, é importante que as senhas usadas para acessar recursos sejam fortes, com uma grande variedade de caracteres. Essas senhas são exatamente o tipo de senha quase impossível de lembrar. Felizmente, as senhas no Azure não precisam ser conhecidas por nenhum humano.

Muitos especialistas em segurança sugerem que usar um gerenciador de senhas para manter suas próprias senhas é a melhor abordagem. Embora centralize suas senhas em um local, ela também permite usar senhas altamente complexas e garantir que elas sejam exclusivas para cada conta. O mesmo sistema existe no Azure: um repositório central para segredos.

Azure Key Vault

O Azure Key Vault fornece um local centralizado para armazenar senhas para itens como bancos de dados, chaves de API e certificados. Depois que um segredo é inserido no Cofre, ele nunca é mostrado novamente e os comandos para extraí-lo e exibi-lo são propositalmente complicados. As informações no cofre são protegidas usando criptografia de software ou módulos de segurança de hardware validados fips 140-2 nível 2.

O acesso ao cofre de chaves é fornecido por meio de RBACs, o que significa que não apenas qualquer usuário pode acessar as informações no cofre. Digamos que um aplicativo Web deseja acessar a cadeia de conexão de banco de dados armazenada no Azure Key Vault. Para obter acesso, os aplicativos precisam ser executados usando um principal de serviço. Sob essa função assumida, eles podem ler os segredos do cofre. Há várias configurações de segurança diferentes que podem limitar ainda mais o acesso de um aplicativo ao cofre, permitindo que ele apenas leia os segredos e não possa atualizá-los.

O acesso ao cofre de chaves pode ser monitorado para garantir que apenas os aplicativos esperados estejam acessando o cofre. Os logs podem ser integrados novamente ao Azure Monitor, desbloqueando a capacidade de configurar alertas quando condições inesperadas são encontradas.

Kubernetes

No Kubernetes, há um serviço semelhante para manter pequenas partes de informações secretas. Os Segredos do Kubernetes podem ser definidos por meio do executável típico kubectl .

Criar um segredo é tão simples quanto localizar a versão base64 dos valores a serem armazenados:

echo -n 'admin' | base64
YWRtaW4=
echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm

Em seguida, adicione-o a um arquivo de segredos nomeado secret.yml , por exemplo, semelhante ao exemplo a seguir:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

Por fim, esse arquivo pode ser carregado no Kubernetes executando o seguinte comando:

kubectl apply -f ./secret.yaml

Esses segredos podem ser montados em volumes ou expostos a processos de contêiner por meio de variáveis de ambiente. A abordagem de aplicativo de doze fatores para a criação de aplicativos sugere o uso do menor denominador comum para transmitir configurações para um aplicativo. As variáveis de ambiente são o menor denominador comum, pois têm suporte, não importa o sistema operacional ou o aplicativo.

Uma alternativa para usar os segredos internos do Kubernetes é acessar os segredos no Azure Key Vault de dentro do Kubernetes. A maneira mais simples de fazer isso é atribuir uma função RBAC ao contêiner que procura carregar segredos. Em seguida, o aplicativo pode usar as APIs do Azure Key Vault para acessar os segredos. No entanto, essa abordagem requer modificações no código e não segue o padrão de uso de variáveis de ambiente. Em vez disso, é possível injetar valores em um contêiner. Na verdade, essa abordagem é mais segura do que usar os segredos do Kubernetes diretamente, pois eles podem ser acessados pelos usuários no cluster.

Criptografia em trânsito e em repouso

Manter os dados seguros é importante, seja em disco ou em trânsito entre vários serviços diferentes. A maneira mais eficaz de impedir o vazamento de dados é criptografá-los em um formato que não pode ser facilmente lido por outras pessoas. O Azure dá suporte a uma ampla gama de opções de criptografia.

Em trânsito

Há várias maneiras de criptografar o tráfego na rede no Azure. O acesso aos serviços do Azure normalmente é feito por meio de conexões que usam TLS (Transport Layer Security). Por exemplo, todas as conexões com as APIs do Azure exigem conexões TLS. Da mesma forma, as conexões com pontos de extremidade no armazenamento do Azure podem ser restritas para operarem apenas através de conexões criptografadas por TLS.

O TLS é um protocolo complicado e simplesmente saber que a conexão está usando o TLS não é suficiente para garantir a segurança. Por exemplo, o TLS 1.0 é cronicamente inseguro e o TLS 1.1 não é muito melhor. Mesmo nas versões do TLS, há várias configurações que podem facilitar a descriptografia das conexões. O melhor curso de ação é verificar e ver se a conexão do servidor está usando protocolos up-to-date e bem configurados.

Essa verificação pode ser feita por um serviço externo, como o Teste do Servidor SSL dos laboratórios SSL. Uma execução de teste em um ponto de extremidade típico do Azure, nesse caso um ponto de extremidade do barramento de serviço, gera uma pontuação quase perfeita de A.

Mesmo serviços como bancos de dados SQL do Azure usam criptografia TLS para manter os dados ocultos. A parte interessante sobre como criptografar os dados em trânsito usando o TLS é que não é possível, mesmo para a Microsoft, escutar na conexão entre computadores que executam o TLS. Isso deve proporcionar conforto para as empresas preocupadas que seus dados possam estar em risco devido à Microsoft ou até mesmo a um ator de estado com mais recursos do que o invasor padrão.

Figura 9-5. Relatório dos laboratórios SSL mostrando uma pontuação de A para um endpoint do Barramento de Serviço.

Embora esse nível de criptografia não seja suficiente para todos os tempos, ele deve inspirar confiança de que as conexões TLS do Azure são bastante seguras. O Azure continuará evoluindo seus padrões de segurança à medida que a criptografia melhorar. É bom saber que há alguém observando os padrões de segurança e atualizando o Azure à medida que eles melhoram.

Em repouso

Em qualquer aplicativo, há vários locais em que os dados restam no disco. O próprio código do aplicativo é carregado de algum mecanismo de armazenamento. A maioria dos aplicativos também usa algum tipo de banco de dados, como SQL Server, Cosmos DB ou até mesmo o Armazenamento de Tabelas incrivelmente eficiente em termos de preço. Todos esses bancos de dados usam armazenamento altamente criptografado para garantir que ninguém além dos aplicativos com permissões adequadas possa ler seus dados. Nem mesmo os operadores do sistema podem ler dados criptografados. Assim, os clientes podem permanecer confiantes de que suas informações secretas permanecem em segredo.

Armazenamento

A base de grande parte do Azure é o mecanismo de Armazenamento do Azure. Os discos de máquina virtual são montados sobre o Armazenamento do Azure. O Serviço de Kubernetes do Azure é executado em máquinas virtuais que, por si só, são hospedadas no Armazenamento do Azure. Mesmo as tecnologias serverless, como Azure Functions Apps e Instâncias de Contêiner do Azure, utilizam disco que faz parte do Armazenamento do Azure.

Se o Armazenamento do Azure estiver bem criptografado, ele fornecerá uma base para que a maioria das outras coisas também seja criptografada. O Armazenamento do Azure é criptografado com AES de 256 bits compatível com FIPS 140-2. Esta é uma tecnologia de criptografia bem conceituada tendo sido objeto de amplo escrutínio acadêmico nos últimos 20 anos. No momento, não há nenhum ataque prático conhecido que permita que alguém sem conhecimento da chave leia dados criptografados pelo AES.

Por padrão, as chaves usadas para criptografar o Armazenamento do Azure são gerenciadas pela Microsoft. Há amplas proteções em vigor para garantir a prevenção do acesso mal-intencionado a essas chaves. No entanto, os usuários com requisitos de criptografia específicos também podem fornecer suas próprias chaves de armazenamento gerenciadas no Azure Key Vault. Essas chaves podem ser revogadas a qualquer momento, o que tornaria o conteúdo da conta de Armazenamento que as utiliza inacessível.

As máquinas virtuais usam armazenamento criptografado, mas é possível fornecer outra camada de criptografia usando tecnologias como o BitLocker no Windows ou DM-Crypt no Linux. Essas tecnologias significam que, mesmo que a imagem de disco tenha sido vazada do armazenamento, ela permanecerá quase impossível lê-la.

Azure SQL

Os bancos de dados hospedados no SQL do Azure usam uma tecnologia chamada TDE (Transparent Data Encryption) para garantir que os dados permaneçam criptografados. Ele é habilitado por padrão em todos os bancos de dados SQL recém-criados, mas deve ser habilitado manualmente para bancos de dados herdados. O TDE executa criptografia e descriptografia em tempo real não apenas do banco de dados, mas também dos backups e logs de transações.

Os parâmetros de criptografia são armazenados no master banco de dados e, na inicialização, são lidos na memória para as operações restantes. Isso significa que o master banco de dados deve permanecer não criptografado. A chave real é gerenciada pela Microsoft. No entanto, os usuários com requisitos de segurança exatos podem fornecer sua própria chave no Key Vault da mesma maneira que é feito para o Armazenamento do Azure. O Key Vault fornece serviços como rotação e revogação de chaves.

A parte "Transparente" do TDS vem do fato de que não há alterações de cliente necessárias para usar um banco de dados criptografado. Embora essa abordagem forneça uma boa segurança, o vazamento da senha do banco de dados é suficiente para que os usuários possam descriptografar os dados. Há outra abordagem que criptografa colunas ou tabelas individuais em um banco de dados. O Always Encrypted garante que, em nenhum momento, os dados criptografados sejam exibidos em texto sem formatação dentro do banco de dados.

Configurar essa camada de criptografia requer a execução por meio de um assistente no SQL Server Management Studio para selecionar o tipo de criptografia e onde no Key Vault armazenar as chaves associadas.

Figura 9-6. Selecionando colunas em uma tabela a serem criptografadas usando o Always Encrypted.

Os aplicativos cliente que leem informações dessas colunas criptografadas precisam fazer concessões especiais para ler dados criptografados. As cadeias de conexão precisam ser atualizadas com Column Encryption Setting=Enabled e as credenciais do cliente devem ser recuperadas do Key Vault. Em seguida, o cliente do SQL Server deve ser configurado com as chaves de criptografia de coluna. Depois que isso for feito, as ações restantes usarão as interfaces padrão para o SQL Client. Ou seja, ferramentas como o Dapper e o Entity Framework, que são criadas sobre o SQL Client, continuarão funcionando sem alterações. O Always Encrypted ainda pode não estar disponível para cada driver do SQL Server em cada idioma.

A combinação de TDE e Always Encrypted, que podem ser usadas com chaves específicas do cliente, garante que até mesmo os requisitos de criptografia mais exigentes sejam suportados.

Cosmos DB

O Cosmos DB é o banco de dados mais recente fornecido pela Microsoft no Azure. Ele foi criado desde o início com segurança e criptografia em mente. A criptografia AES-256bit é padrão para todos os bancos de dados do Cosmos DB e não pode ser desabilitada. Juntamente com o requisito TLS 1.2 para comunicação, toda a solução de armazenamento é criptografada.

Figura 9-7. O fluxo de criptografia de dados no Cosmos DB.

Embora o Cosmos DB não permita fornecer chaves de criptografia do cliente, houve um trabalho significativo feito pela equipe para garantir que ele mantenha a conformidade com o padrão PCI-DSS sem isso. O Cosmos DB também não dá suporte a nenhum tipo de criptografia de coluna única semelhante ao Always Encrypted do SQL do Azure ainda.

Mantendo-se seguro

O Azure tem todas as ferramentas necessárias para lançar um produto altamente seguro. No entanto, uma cadeia é tão forte quanto seu elo mais fraco. Se os aplicativos implantados em cima do Azure não forem desenvolvidos com uma mentalidade de segurança adequada e boas auditorias de segurança, eles se tornarão o link fraco na cadeia. Há muitas ótimas ferramentas de análise estática, bibliotecas de criptografia e práticas de segurança que podem ser usadas para garantir que o software instalado no Azure seja tão seguro quanto o próprio Azure. Exemplos incluem ferramentas de análise estática e bibliotecas de criptografia.

AnteriorPróximo