Segurança do Azure para os aplicativos nativos de nuvem

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 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. Limites de 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 holística de segurança 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 liberação?

Todas essas perguntas fazem parte de um processo chamado modelagem de ameaças. Esse processo tenta responder à pergunta sobre quais ameaças existem ao sistema, qual é a probabilidade das ameaças e os danos potenciais delas.

Depois que a lista de ameaças for estabelecida, você precisará decidir se elas valem a pena atenuar. Às vezes, uma ameaça é tão improvável e cara de planejar que não vale 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 uma exploração que pode ignorar o hipervisor e executar o código de ataque nas máquinas bare-metal, permitindo ataques a todas as máquinas virtuais que estão 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 de exploração para ele.

Ameaças mais prováveis, como controles de acesso quebrados que permitem Id ataques incrementais (substituindo Id=2 com Id=3 no URL) ou injeção de SQL, são mais atraentes para criar proteções. As mitigações para essas ameaças são bastante razoáveis para construir e evitar falhas de segurança embaraçosas que mancham a reputação da empresa.

Princípio de privilégios mínimos

Uma das ideias fundadoras na segurança do computador é o POLP (Princípio do Privilégio Mínimo). 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 escalar 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 se conectar 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 habilidade de atualizar informações de esquema. Deve haver várias contas que fornecem 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 ataques que visavam descartar tabelas de banco de dados ou introduzir gatilhos mal-intencionados.

Quase todas as partes da compilação de um aplicativo nativo de nuvem podem se beneficiar de lembrar o princípio do privilégio mínimo. É possível encontrá-lo em jogo ao configurar firewalls, grupos de segurança de rede, funções e escopos no RBAC (controle de acesso baseado em função).

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, pois 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, compilar 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 receberam 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 fraude eletrônica 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 eles possam ser explorados externamente. Quanto mais tentador um alvo, mais provável é que os atores eternos tentem explorá-lo e há alguns alvos no mundo mais tentadores do que o Azure.

Monitoramento

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 sinais que podem ser vistos antes de serem bem-sucedidos. 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 restringir respostas.

Protegendo a compilação

Um lugar em que a segurança geralmente é negligenciada é em torno do processo de compilação. Não só a compilação deve executar verificações de segurança, como a verificação de código inseguro ou credenciais de check-in, mas a compilação em si deve ser segura. Se o servidor de compilação 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 compilação que modifica o código de check-out para espelhar qualquer solicitação de logon em outro servidor. Na próxima vez que o código passar pela compilação, ele será atualizado silenciosamente. A verificação de vulnerabilidade do código-fonte não capturará essa vulnerabilidade enquanto ela é executada antes da compilação. Da mesma forma, ninguém o capturará em uma revisão de código porque as etapas de compilação ficam no servidor de compilação. 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 compilação ou pelo menos ninguém monitorando a auditoria.

Esse cenário é um exemplo perfeito de um destino aparentemente de baixo valor que pode ser usado para invadir 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 de 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 o artigo Diretrizes de codificação segura para o .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 um código seguro.

O processo de compilação é um bom lugar para colocar ferramentas de verificação para detectar problemas no código-fonte antes de entrar em produção. A maioria dos projetos tem dependências em alguns outros pacotes. Uma ferramenta que pode verificar pacotes desatualizados detectará problemas em uma compilação noturna. Mesmo ao compilar imagens do Docker, é útil verificar e certificar-se de que a imagem base não tem vulnerabilidades conhecidas. Outra coisa a verificar é que ninguém fez check-in acidentalmente nas credenciais.

Segurança interna

O Azure foi projetado para equilibrar a usabilidade e a segurança para a maioria dos usuários. Diferentes usuários 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 dos 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 um Rede Virtual.

Infraestrutura de rede do Azure

Em um ambiente de implantação local, uma grande quantidade de energia é dedicada à configuração da rede. Configurar roteadores, comutadores e isso é um trabalho complicado. As redes permitem que determinados recursos conversem com outros recursos e impeçam o acesso em alguns casos. Uma regra de rede frequente é restringir o acesso ao ambiente de produção a partir do ambiente de desenvolvimento, na possibilidade de que uma parte de código semi-desenvolvido seja executado de forma desregulada e exclua uma faixa de dados.

Fora de caixa, a maioria dos recursos do PaaS do Azure 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 normalmente são restritas, para que as partes externas não possam acessá-las, mas os intervalos de endereços IP usados pelo próprio Azure são permitidos. Portanto, enquanto o SQL Server está protegido contra ameaças externas, um invasor só precisa configurar uma plataforma 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 um Rede Virtual do Azure que permite o controle de acesso refinado. Semelhante à forma como as redes locais estabelecem redes privadas protegidas do mundo inteiro, as redes virtuais são ilhas de endereços IP privados localizados na 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 explícita de firewall.

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 no Rede Virtual. Esse firewall fornece um nível extra de segurança, se as chaves dessa conta de armazenamento forem vazadas, os invasores não poderão se conectar a ele para explorar as chaves vazadas. Esse 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.

Continuando no 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 proveniente de um plano de fundo do 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é habilitados por regras em um NSG. Embora mais lento para desenvolver isso, um ambiente mais restritivo fornece um padrão mais seguro. Usar as práticas adequadas do DevOps, especialmente usando o Azure Resource Manager ou o Terraform para gerenciar permissões, pode facilitar o controle das regras.

As 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 nenhum 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 tunelizado 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 Rota Expressa 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 é uma entidade de segurança. Uma entidade de segurança pode ser um usuário, um grupo, uma entidade de serviço ou uma identidade gerenciada.

Figura 9-2. Tipos diferentes 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 na qual os serviços ou aplicativos são executados.
• Identidade gerenciada – uma identidade de Azure Active Directory gerenciada pelo Azure. As identidades gerenciadas geralmente são usadas ao desenvolver aplicativos de nuvem que gerenciam as de 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 ela acesse segredos armazenados em Key Vault. Uma Função do Azure pode assumir uma permissão possibilitando que ele fale com uma instância do Active Directory para validar um JWT para um usuário de chamada. Depois que os serviços são habilitados com uma entidade 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 indumentária, usar varias funções. Cada função define uma série de permissões, como “Ler mensagens do ponto de extremidade do Barramento de Serviço do Azure”. O conjunto de permissões efetivo de uma entidade de segurança é a combinação de todas as permissões atribuídas a todas as funções que uma entidade de segurança tem. 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

Integrado ao Azure, também há uma série de 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, uma entidade de segurança pode acessar todos os recursos e atribuir permissões a outras pessoas. 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 do 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, aplicando 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 Barramento de Serviço do Azureblah.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 “permissão” eram autorizadas para o RBAC. Esse comportamento tornou alguns escopos complicados de compilar. Por exemplo, permitir que uma entidade de segurança acesse todas as contas de armazenamento, exceto uma, exigia a concessão de permissão explícita para uma lista potencialmente infinita de contas de armazenamento. Sempre que uma nova conta de armazenamento era criada, ela precisava que ser adicionada a essa lista de contas. Essa sobrecarga de gerenciamento adicionada 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” pode ser representado como duas regras “permitir todos” e “negar essa específica”. Negar regras não apenas facilita o gerenciamento, mas permite recursos que são extra 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. Acumular 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 entidade 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 único 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.

Cofre de Chave do Azure

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 mais é mostrado 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 por FIPS 140-2 nível 2.

O acesso ao cofre de chaves é fornecido por meio de RBACs, o que significa que nenhum usuário pode acessar as informações no cofre. Digamos que um aplicativo Web deseje acessar a cadeia de conexão de banco de dados armazenada no Azure Key Vault. Para obter acesso, os aplicativos precisam ser executados usando uma entidade 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 que um aplicativo tem ao cofre, para que ele não possa atualizar segredos, mas apenas lê-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 encontrar 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 compilação de aplicativos sugere o uso do denominador comum mais baixo para transmitir configurações para um aplicativo. As variáveis de ambiente são o menor denominador comum, pois têm suporte, independentemente do sistema operacional ou 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. Essa abordagem é, na verdade, 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 transitando entre vários serviços diferentes. A maneira mais eficaz de impedir que os dados vazem é criptografá-los em um formato que não pode ser lido facilmente por outras pessoas. O Azure dá suporte a uma ampla variedade 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 o 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 a funcionar somente em conexões criptografadas do 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 tornar as conexões mais fáceis de descriptografar. O melhor plano de ação é verificar e observar se a conexão do servidor está usando protocolos atualizados 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 do 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 a conexão entre computadores que executam o TLS. Isso deve proporcionar conforto para as empresas preocupadas que seus dados possam estar em risco por parte da Microsoft ou até mesmo a um ator de estado com mais recursos do que o invasor padrão.

Figura 9-5. Relatório de laboratórios SSL mostrando uma pontuação de A para um ponto de extremidade 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 de TLS do Azure são bastante seguras. O Azure continuará a evoluir 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 usam algum tipo de banco de dados, como SQL Server, Cosmos DB ou até mesmo o Armazenamento de Tabelas incrivelmente econômico. 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 Microsoft Azure. Os discos de máquina virtual são montados sobre o Armazenamento do Microsoft Azure. Serviço de Kubernetes do Azure é executado em máquinas virtuais que, por si só, são hospedadas no Armazenamento do Microsoft Azure. Mesmo as tecnologias sem servidor, como aplicativos do Azure Functions e Instâncias de Contêiner do Azure, estão sem disco que faz parte do Armazenamento do Microsoft Azure.

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

Por padrão, as chaves usadas para criptografar o Armazenamento do Microsoft Azure são gerenciadas pela Microsoft. Há amplas proteções em vigor para evitar o acesso mal-intencionado a essas chaves. No entanto, 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 renderizaria efetivamente o conteúdo da conta de Armazenamento usando-as 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 vazado do armazenamento, ela permanecerá quase impossível de lê-la.

SQL do Azure

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 banco de dados master e, na inicialização, são lidos na memória para as operações restantes. Isso significa que o banco de dados master deve permanecer não criptografado. A chave real é gerenciada pela Microsoft. No entanto, os usuários com requisitos de segurança exigentes podem fornecer sua própria chave em Key Vault da mesma maneira que é feito para o Armazenamento do Microsoft Azure. O Key Vault fornece serviços como rotação de chaves e revogação.

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.

A configuração dessa 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, em Key Vault, armazenar as chaves associadas.

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

Aplicativos cliente que leem informações dessas colunas criptografadas precisam fazer subsídios 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. O cliente SQL Server deve ser preparado 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 Dapper e 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 de 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 com suporte.

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 de 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 forneça chaves de criptografia do cliente, houve um trabalho significativo feito pela equipe para garantir que ele permaneça em conformidade com 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 vínculo mais fraco. Se os aplicativos implantados na parte superior 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. Os exemplos incluem as ferramentas de análise estática, as bibliotecas de criptografia e as práticas de segurança.