Segurança do Azure para aplicativos nativos da nuvem

Gorjeta

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

Descarregar PDF

As aplicações nativas da nuvem podem ser mais fáceis e mais difíceis de proteger do que as aplicações tradicionais. No lado negativo, você precisa proteger mais aplicativos menores e dedicar mais energia para construir a infraestrutura de segurança. A natureza heterogênea das linguagens e estilos de programação na maioria das implantações de serviços 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 ele dar 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, os danos serão mais limitados, pois esse banco de dados contém apenas um subconjunto de dados e é improvável que contenha dados pessoais.

Modelação de ameaças

Não importa se as vantagens superam as desvantagens dos aplicativos nativos da nuvem, a mesma mentalidade holística de segurança deve ser seguida. Segurança e 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 da perda desses dados?
• Como podemos limitar os danos causados pela injeção de dados incorretos neste serviço?
• Quem deve ter acesso a estes dados?
• Existem 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. Este processo tenta responder à questão de quais são as ameaças ao sistema, qual a probabilidade das ameaças e os danos potenciais causados por elas.

Uma vez estabelecida a lista de ameaças, você precisa decidir se vale a pena atenuá-las. À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 estadual poderia injetar mudanças no design de um processo que é usado por milhões de dispositivos. Agora, em vez de executar um determinado pedaço de 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 sendo executadas nesse hardware.

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

Ameaças mais prováveis, como controles de acesso quebrados que Id permitem incrementar ataques (substituindo Id=2 por Id=3 na URL) ou injeção de SQL, são mais atraentes para criar proteções contra. 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 do menor privilégio

Uma das ideias fundadoras da segurança informática é o Princípio do Menor Privilégio (POLP). Na verdade, é uma ideia fundamental na maioria das formas de segurança, seja ela digital ou física. Em suma, o princípio é que qualquer utilizador ou processo deve ter o menor número de direitos possível para executar a sua tarefa.

Como exemplo, pense nos caixas de um banco: acessar o cofre é uma atividade incomum. Assim, o caixa médio não pode abrir o cofre sozinho. Para obter acesso, eles precisam escalar sua solicitação por meio de um gerente bancário, que realiza 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 capacidade de atualizar as informações do esquema. Deve haver várias contas que forneçam diferentes níveis de privilégio. O aplicativo só deve usar 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 derrubar tabelas de banco de dados ou introduzir gatilhos maliciosos.

Quase todas as partes da criação de um aplicativo nativo da nuvem podem se beneficiar ao lembrar o princípio do menor privilégio. Você pode 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).

Testes de penetração

À medida que as aplicações se tornam mais complicadas, 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 constroem o sistema. Da mesma forma que muitos desenvolvedores têm problemas para visualizar as interações do usuário e, em seguida, criar interfaces de usuário inutilizáveis, a maioria dos desenvolvedores tem dificuldade em ver todos os vetores de ataque. Também é possível que os desenvolvedores que constroem o sistema não sejam bem versados em metodologias de ataque e percam algo crucial.

O teste de penetração ou "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 bons conhecimentos de segurança de outra parte do negócio. Eles recebem carta branca para tentar subverter o sistema. Frequentemente, eles encontrarão extensas 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 eternos tentem explorá-lo e há alguns alvos no mundo mais tentadores do que Azure.

Monitorização

Se um invasor tentar penetrar em um aplicativo, deve haver algum aviso sobre isso. Frequentemente, os ataques podem ser detetados examinando os logs dos serviços. Os ataques deixam sinais reveladores que podem ser detetados antes de serem bem-sucedidos. Por exemplo, um invasor que tente adivinhar uma senha fará muitas solicitações para um sistema de login. O monitoramento em torno do sistema de login pode detetar 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 agir com base nesses desvios, adicionando proativamente regras para bloquear solicitações ou limitar respostas.

Protegendo a compilação

Um lugar onde a segurança é muitas vezes negligenciada é em torno do processo de construçã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 própria compilação deve ser segura. Se o servidor de compilação estiver comprometido, ele fornece 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 poderiam introduzir uma etapa de compilação que modifica o código de check-out para espelhar qualquer solicitação de login para 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 detetará essa vulnerabilidade, pois ela é executada antes da compilação. Da mesma forma, ninguém irá pegá-lo em uma revisão de código porque as etapas de compilação vivem no servidor de compilação. O código explorado irá para a produção, onde poderá colher 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.

Este cenário é um exemplo perfeito de um alvo aparentemente de baixo valor que pode ser usado para invadir o sistema. Quando 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 desejar.

Criação de 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 à medida que são descobertas. Há até mesmo um programa de recompensa por bugs que paga aos pesquisadores para encontrar problemas na estrutura e relatá-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 .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 compilação é um bom lugar para colocar ferramentas de digitalização para detetar problemas no código-fonte antes que eles entrem em produção. A maioria dos projetos tem dependências em alguns outros pacotes. Uma ferramenta que pode verificar pacotes desatualizados detetará problemas em uma compilação noturna. Mesmo ao criar 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 acidentalmente fez check-in de credenciais.

Segurança incorporada

O Azure foi concebido para equilibrar a usabilidade e a segurança para a maioria dos utilizadores. Diferentes usuários terão requisitos de segurança diferentes, então 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. Este recurso deve ser a primeira parada para os profissionais interessados em entender como funcionam as tecnologias integradas de mitigação de ataques.

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

Infraestrutura de rede do Azure

Em um ambiente de implantação local, uma grande quantidade de energia é dedicada à configuração de rede. Configurar roteadores, switches, e tal é um trabalho complicado. As redes permitem que certos recursos conversem com outros recursos e impedem 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 hipótese de um pedaço de código semi-desenvolvido correr mal e excluir uma faixa de dados.

Pronto para uso, a maioria dos recursos do Azure PaaS tem apenas a configuração de rede mais básica e permissiva. Por exemplo, qualquer pessoa na Internet pode aceder a um serviço de aplicação. As novas instâncias do SQL Server normalmente vêm restritas, de modo que terceiros não podem acessá-las, mas os intervalos de endereços IP usados pelo próprio Azure são permitidos. Portanto, enquanto o servidor SQL está protegido contra ameaças externas, um invasor só precisa configurar uma cabeça de ponte do Azure a partir da qual pode iniciar ataques contra todas as instâncias 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 em geral, 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 as 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 o acesso apenas por recursos que também estão na Rede Virtual. Este firewall fornece um nível extra de segurança, caso as chaves dessa conta de armazenamento sejam vazadas, os invasores não seriam capazes de se conectar a ele para explorar as chaves vazadas. Este cenário é mais um exemplo do princípio do menor privilégio.

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 do menor privilégio, nem todos os recursos dentro de uma Rede Virtual precisam falar com todos os outros recursos. Por exemplo, em um aplicativo que fornece uma API da Web sobre 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. Assim, um grupo de segurança de rede (NSG) poderia ser usado para negar o tráfego entre os dois serviços.

Uma política de negar a comunicação entre recursos pode ser irritante de implementar, especialmente vindo de um plano de fundo 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 na AWS é que os recursos não podem se comunicar entre si até que sejam ativados por regras em um NSG. Embora mais lento para desenvolver isso, um ambiente mais restritivo fornece um padrão mais seguro. Fazer uso de práticas adequadas de 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 na nuvem. Uma rede virtual privada pode ser usada para conectar perfeitamente as duas redes. Essa abordagem permite executar uma rede virtual sem qualquer tipo de gateway para cenários onde todos os usuários estão no local. Há uma série de 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 é encriptado e encapsulado através da 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 do RBAC é uma entidade de segurança. Uma entidade de segurança pode ser um usuário, grupo, entidade 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 Ative Directory do Azure é um usuário.
• Grupo - Uma coleção de usuários do Azure Ative Directory. Como membro de um grupo, um usuário assume as funções desse grupo, além das suas.
• 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 Ative Directory do Azure gerenciada pelo Azure. As identidades gerenciadas geralmente 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 aspeto 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 Cofre da Chave. Uma Função do Azure pode assumir uma permissão que lhe permite falar com uma instância do Ative Directory para validar um JWT para um usuário chamador. 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

Um diretor 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 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.

Incorporadas no Azure também estão várias funções de alto nível, como Proprietário, Colaborador, Leitor e Administrador de Conta de Usuário. Com a função 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 ver recursos existentes do Azure e um Administrador de Conta de Utilizador pode gerir o acesso aos recursos do Azure.

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

Âmbitos

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 Service Bus, você pode restringir a permissão a uma única fila: "Ler mensagens do ponto de extremidade blah.servicebus.windows.net/queue1do Barramento de Serviço do Azure"

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 consideração. Essa combinação fornece um poderoso mecanismo de autorização.

Negar

Anteriormente, apenas as regras de "permissão" eram permitidas para o RBAC. Esse comportamento tornou alguns escopos complicados de criar. Por exemplo, permitir que uma entidade de segurança tenha acesso a todas as contas de armazenamento, exceto uma, é necessário conceder permissão explícita a uma lista potencialmente interminável de contas de armazenamento. Toda vez que uma nova conta de armazenamento fosse criada, ela teria que ser adicionada a essa lista de contas. Isso acrescentou despesas gerais de gerenciamento que certamente não eram desejáveis.

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

Verificar 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 entidade de serviço. Normalmente é encontrado na guia IAM no portal, como mostra a Figura 9-3.

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

Proteger 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. Por isso, é importante que as senhas usadas para acessar recursos sejam fortes, com uma grande variedade de caracteres. Essas senhas são exatamente o tipo de senhas que são quase impossíveis de lembrar. Felizmente, as senhas no Azure não precisam ser conhecidas por nenhum ser 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, ele também permite usar senhas altamente complexas e garantir que elas sejam exclusivas para cada conta. O mesmo sistema existe no Azure: um armazenamento central de 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. Uma vez que um segredo é inserido no Vault, ele nunca mais é mostrado e os comandos para extraí-lo e visualizá-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 pelo FIPS 140-2 Nível 2.

O acesso ao cofre de chaves é fornecido através de RBACs, o que significa que não é qualquer usuário que 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 Cofre da Chave do Azure. Para obter acesso, os aplicativos precisam ser executados usando uma entidade de serviço. Sob este papel assumido, 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

Dentro do Kubernetes, há um serviço semelhante para manter pequenos pedaços de informações secretas. Os segredos do Kubernetes podem ser definidos através 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, adicioná-lo a um arquivo secretos nomeado secret.yml , por exemplo, que se parece com o exemplo a seguir:

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

Finalmente, 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 criar aplicativos sugere usar o menor denominador comum para transmitir configurações para um aplicativo. As variáveis de ambiente são o menor denominador comum, porque são suportadas independentemente do sistema operativo ou da aplicação.

Uma alternativa para usar os segredos internos do Kubernetes é acessar os segredos no Cofre da Chave do Azure de dentro do Kubernetes. A maneira mais simples de fazer isso é atribuir uma função RBAC ao contêiner que procura carregar segredos. 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 recipiente. Essa abordagem é, na verdade, mais segura do que usar os segredos do Kubernetes diretamente, pois eles podem ser acessados pelos usuários no cluster.

Encriptação 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 evitar que os dados vazem é criptografá-los em um formato que não possa ser facilmente lido 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 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 funcionar apenas em conexões criptografadas TLS.

TLS é um protocolo complicado e simplesmente saber que a conexão está usando 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 dentro das versões do TLS, existem várias configurações que podem tornar as conexões mais fáceis de desencriptar. O melhor curso de ação é verificar e ver 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 SSL Labs SSL Server Test. Uma execução de teste em um ponto de extremidade típico do Azure, neste caso um ponto de extremidade do barramento de serviço, produz uma pontuação quase perfeita de A.

Até mesmo serviços como bancos de dados SQL do Azure usam criptografia TLS para manter os dados ocultos. A parte interessante sobre criptografar os dados em trânsito usando TLS é que não é possível, mesmo para a Microsoft, ouvir a conexão entre computadores que executam TLS. Isso deve proporcionar conforto para as empresas preocupadas que seus dados podem estar em risco da própria Microsoft ou até mesmo de um ator estatal 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 Service Bus.

Embora esse nível de criptografia não seja suficiente para sempre, ele deve inspirar confiança de que as conexões TLS do Azure são bastante seguras. O Azure continuará a evoluir seus padrões de segurança à medida que a criptografia melhora. É 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 lugares onde os dados estão no disco. O próprio código do aplicativo é carregado a partir 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 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. Mesmo os operadores de sistema não podem ler dados que foram criptografados. Assim, os clientes podem permanecer confiantes de que suas informações secretas permanecem secretas.

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 Kubernetes do Azure é executado em máquinas virtuais que, elas próprias, estão hospedadas no Armazenamento do Azure. Mesmo as tecnologias sem servidor, como os Aplicativos do Azure Functions e as Instâncias de Contêiner do Azure, ficam sem disco que faz parte do Armazenamento do Azure.

Se o Armazenamento do Azure estiver bem criptografado, ele fornecerá uma base para que quase todo o resto também seja criptografado. O Armazenamento do Azure é criptografado com AES de 256 bits compatível com FIPS 140-2. Trata-se de uma tecnologia de encriptação bem conceituada, tendo sido objeto de um extenso escrutínio académico ao longo dos ú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. Existem proteções abrangentes em vigor para garantir o 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 que são gerenciadas no Cofre de Chaves do Azure. Essas chaves podem ser revogadas a qualquer momento, o que efetivamente 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 BitLocker no Windows ou DM-Crypt no Linux. Essas tecnologias significam que, mesmo que a imagem de disco fosse vazada do armazenamento, permaneceria quase impossível lê-la.

SQL do Azure

Os bancos de dados hospedados no SQL do Azure usam uma tecnologia chamada TDE (Criptografia de Dados Transparente) 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. A 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 exigentes podem fornecer sua própria chave no Cofre da Chave da mesma forma que é feito para o Armazenamento do Azure. O Cofre de Chaves 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, vazar a 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. Always Encrypted garante que em nenhum momento os dados criptografados apareçam em texto sem formatação dentro do banco de dados.

A configuração dessa camada de criptografia requer a execução de um assistente no SQL Server Management Studio para selecionar o tipo de criptografia e onde no Cofre da Chave armazenar as chaves associadas.

Figura 9-6. Seleção de colunas em uma tabela a ser criptografada usando 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 e Column Encryption Setting=Enabled as credenciais do cliente devem ser recuperadas do Cofre da Chave. O cliente SQL Server deve então ser preparado com as chaves de criptografia de coluna. Feito isso, as ações restantes usam as interfaces padrão para o SQL Client. Ou seja, ferramentas como Dapper e Entity Framework, que são construídas sobre o SQL Client, continuarão a funcionar sem alterações. Always Encrypted pode ainda não estar disponível para todos os drivers do SQL Server em todos os idiomas.

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

Cosmos DB

O Cosmos DB é o mais novo banco de dados fornecido pela Microsoft no Azure. Ele foi construído desde o início com segurança e criptografia em mente. A criptografia AES-256 bits é 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 dentro do Cosmos DB.

Embora o Cosmos DB não forneça chaves de criptografia para clientes, houve um trabalho significativo feito pela equipe para garantir que ele permaneça compatível com PCI-DSS sem isso. O Cosmos DB também ainda não oferece suporte a nenhum tipo de criptografia de coluna única semelhante ao Always Encrypted do Azure SQL.

Manter a segurança

O Azure tem todas as ferramentas necessárias para lançar um produto altamente seguro. No entanto, uma cadeia é tão forte quanto o seu elo mais fraco. Se os aplicativos implantados sobre o Azure não forem desenvolvidos com uma mentalidade de segurança adequada e boas auditorias de segurança, eles se tornarão o elo fraco da cadeia. Há muitas ferramentas de análise estática excelentes, 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 ferramentas de análise estática, bibliotecas de criptografia e práticas de segurança.

AnteriorSeguinte