Artigo
02/29/2016

Este artigo foi traduzido por máquina.

Segurança na nuvem

Serviços de criptografia e segurança dos dados no Windows Azure

Jonathan Wiggs

Muitos pioneiros da plataforma Windows Azure ainda tem muitas perguntas sobre segurança de plataforma e o suporte de criptografia. Minha esperança aqui é apresentar alguns conceitos básicos de criptografia e segurança relacionada dentro da plataforma Windows Azure. Detalhes sobre este tópico pode preencher livros inteiros, portanto, eu só estou pretende demonstrar e analisar alguns dos serviços de criptografia e provedores no Windows Azure. Também há algumas implicações de segurança para qualquer transição para o Windows Azure.

Com qualquer nova plataforma ou o método de entrega de serviço, você vai ser enfrentar novos desafios. Você também vai ser lembrado que ainda existem alguns problemas clássicos e até mesmo que algumas das mesmas soluções você usou no passado ainda funcionará muito bem. Qualquer engenheiro de aplicativo ou o designer deve considerar sobre esse tópico se relaciona com o tipo de dados, que você pode estar armazenando, bem como o que você precisa manter. Combine isso em uma abordagem metódica e você e seus clientes estarão well-served.

Então por que seria acho isso forem necessárias informações dentro da comunidade de desenvolvedores? Última vários meses que já vi um número crescente de postagens nos sites da comunidade sobre segurança em geral com Azure. Microsoft sugeriu criptografia como parte da proteção de dados de camada de aplicativo com projetos Azure. No entanto, será necessário compreensão adequada dos criptografia e o modelo de segurança do .NET por produto designers e desenvolvedores criam na plataforma Windows Azure.

Uma coisa que percebi era uma porcentagem crescente das postagens específicas de serviços de criptografia e armazenamento de chaves. Isso era especialmente verdadeiro em relação aos serviços Windows Azure Storage. Ele tem minha própria curiosidade indo e descobri que era um valioso tópico para discutir alguns detalhes.

Durante o curso desse artigo, eu vai fazendo uso pesado do Cryptographic Service Providers (CSPs), que são implementações dos padrões de criptografia, algoritmos e funções apresentadas em uma interface de programa do sistema. Para fins deste artigo, eu usará o algoritmo de criptografia simétrica fornecido pela classe de criptografia Rijndael.

Noções básicas sobre criptografia

O SDK do Windows Azure estende o núcleo bibliotecas .NET para permitir que o desenvolvedor integrar e fazer uso dos serviços fornecidos pelo Windows Azure. Acesso para os provedores de serviços de criptografia não foi restrito em projetos Windows Azure e serviços. Isso significa que grande parte do seu desenvolvimento em relação ao criptografar e descriptografar dados permanecerá o mesmo com relação aos assemblies que estiver acostumados a usar. No entanto, há alterações na arquitetura subjacente, problemas quando ou onde criptografar dados e onde e como manter as chaves. Discutirei chave e persistência de dados secretos posteriormente neste artigo.

Você também tem acesso ao array completo de funcionalidade de hash criptográfico em Azure do Windows, como o MD5 e SHA. Esses são essenciais para aumentar a segurança de qualquer sistema de coisas como detectar dados duplicados, índices da tabela de hash, assinaturas de mensagem e verificação de senha.

Uma recomendação consistente é nunca criar sua própria ou usar um algoritmo de criptografia proprietário. Os algoritmos fornecidos no .NET CSPs são comprovados, testadas e têm muitos anos de exposição para mantê-los. Usando o XOR para criar seu próprio processo de codificação não é o mesmo e não fornece o mesmo nível de segurança de dados.

Uma segunda recomendação é usar a classe RNGCryptoServiceProvider para gerar números aleatórios. Isso garante números aleatórios gerados pelo seu aplicativo sempre terá um alto nível de entropia, tornando difícil de adivinhar em padrões.

O código a seguir implementa um único membro estático que retorna um valor de 32 bits int que é aleatória e atende aos requisitos para ser criptograficamente seguro. Isso é possibilitado pela usando o gerador de byte em RNGCryptoServiceProvider encontrada no namespace criptografia:

public static int GenerateRandomNumber() {
  byte[] GeneratedBytes = new byte[4];
  RNGCryptoServiceProvider CSP = new RNGCryptoServiceProvider();
  CSP.GetBytes(GeneratedBytes);
  return BitConverter.ToInt32(GeneratedBytes, 0);
}

Figura 1 mostra um exemplo simples de usar os CSPs dentro da plataforma Windows Azure. Três membros públicos são expostos para uso em qualquer aplicativo Windows Azure. A primeira aceita um binário chave e inicialização do vetor (IV), bem como um buffer binário de dados não criptografados e retorna seu equivalente criptografado. O segundo membro faz o inverso descriptografar os dados. O terceiro membro retorna o valor de hash calculado para que os dados. Observe aqui que estou usando o provedor de serviços de criptografia Rijndael para acessar um provedor gerenciado. Eu também sou armazenamento de dados e chaves nos buffers de binários e escrevendo sobre eles logo que estou terminado com eles. Eu vai toque sobre esse tópico posteriormente quando eu discutir imutabilidade.

Figura 1 Simple criptografia

public static byte[] SampleEncrypt(byte[] dataBuffer, 
  byte[] Key, byte[] IV) {

  MemoryStream InMemory = new MemoryStream();
  Rijndael SymetricAlgorithm = Rijndael.Create();
  SymetricAlgorithm.Key = Key;
  SymetricAlgorithm.IV = IV;
  CryptoStream EncryptionStream = new CryptoStream(InMemory,
    SymetricAlgorithm.CreateEncryptor(), CryptoStreamMode.Write);
  EncryptionStream.Write(dataBuffer, 0, dataBuffer.Length);
  EncryptionStream.Close();
  byte[] ReturnBuffer = InMemory.ToArray();
  return ReturnBuffer;
}

Este é o exemplo mais simples de criptografia de dados e retornar os resultados criptografados como uma matriz de bytes. Não é código que deve ser usado em um ambiente seguro sem todas as adequadas análise de segurança, apenas um exemplo.

O exemplo em do Figura 2 tem estrutura quase idêntica da 1 Figura . Nesse caso, eu sou descriptografando dados com base na mesma chave e IV, somente com um buffer de bytes criptografados como um parâmetro. A única diferença aqui é que, ao criar o fluxo de criptografia, eu especificar que estou criando um descriptografador simétrica e não um criptografador como fiz anteriormente.

Figura 2 descriptografia Simple

public static byte[] SampleDecrypt(byte[] dataBuffer, 
  byte[] Key, byte[] IV) {

  MemoryStream InMemory = new MemoryStream();
  Rijndael SymetricAlgorithm = Rijndael.Create();
  SymetricAlgorithm.Key = Key;
  SymetricAlgorithm.IV = IV;
  CryptoStream EncryptionStream = new CryptoStream(InMemory,
    SymetricAlgorithm.CreateDecryptor(), CryptoStreamMode.Write);
  EncryptionStream.Write(dataBuffer, 0, dataBuffer.Length);
  EncryptionStream.Close();
  byte[] ReturnBuffer = InMemory.ToArray();
  return ReturnBuffer;
}

Chave de armazenamento e persistência

Como com qualquer estratégia de criptografia no aplicativo ou camada corporativa, a infra-estrutura de criptografia e descriptografia é menor do que metade da batalha. O verdadeiro problema vem com armazenamento de chaves e persistência de chave. A segurança de dados fornecida por meio da criptografia de dados é apenas tão segura quanto as chaves usadas e esse problema é muito mais difícil que pessoas podem imaginar à primeira. Sistemas que revisei armazenou crypto chaves em qualquer lugar, de diretamente no código fonte, arquivos de texto chamado inteligente arquivos simples armazenados em diretórios de disco rígido-para-encontrar algo.

Uma pergunta importante de persistência chave vem ao considerar onde armazenar e manter as chaves em um ambiente em nuvem. Algumas pessoas têm expressa preocupação que por chaves persistentes na nuvem você estiver expondo-se a uma ameaça à segurança da nuvem propriamente dito. Ou seja, se alguém puder obter acesso físico aos dados, dados armazenados em disco podem não ser criptografados por padrão (como acontece com o Windows Azure). Considerando que SQL Azure ainda não há suporte para criptografia ou, se torna uma decisão de segurança a serem considerados no planejamento e design de sua solução. Como com qualquer implementação de segurança, os riscos devem ser medidos, avaliados e atenuados.

Mas isso não quer dizer que plataformas de nuvem em geral — e Azure Windows em particular — inerentemente não são seguras. Quais são as outras opções podem estar disponíveis para você?

Uma coisa a observar imediatamente é que nenhum aplicativo nunca deve usar qualquer uma das chaves fornecidas pelo Windows Azure como chaves para criptografar dados. Um exemplo seria chaves fornecidas pelo Windows Azure para o serviço de armazenamento. Essas chaves são configuradas para permitir para fácil rotação para fins de segurança ou se eles forem comprometidos por qualquer motivo. Em outras palavras, eles podem não estar lá no futuro e podem ser muito amplamente distribuídos.

Armazenar sua própria biblioteca chave dentro de serviços Windows Azure Storage é uma boa maneira de manter algumas informações secretas, pois você pode contar com esses dados sendo protegido por seu próprio chaves de armazenamento e seguro no ambiente de diversos clientes. Isso é diferente de usar chaves de armazenamento como suas chaves de criptografia. Em vez disso, você pode usar as teclas de serviço de armazenamento para acessar uma biblioteca de chave como faria com qualquer outro arquivo armazenado. Isso é bastante simples de implementar. Por exemplo, digamos que você quisesse implementar sua própria chave biblioteca como um arquivo de texto simples para manter algumas informações secretas. Isso poderia ser melhor armazenado como dados da API do serviço de blob em oposição a serviço de armazenamento a fila ou tabela. A área de blob do serviço de armazenamento é o melhor lugar para dados como binário de áudio e imagens ou até mesmo arquivos de texto. A parte de fila do serviço se concentra em mensagens seguras para objetos de dados pequeno que não persistem por longos períodos de tempo. O sistema de armazenamento de tabela é ótimo para dados estruturados e informações de que precisa ser mantida e acessados em partes específicas, idênticos aos dados relacionais em um banco de dados.

Inicie uma chave em um recipiente de chave de CSP de persistência. Isso é uma ótima opção para armazenar uma chave pública que é difícil recuperar sem acesso físico ao servidor. Com o Windows Azure, onde a localização de aplicativos e dados é abstraída, isso tornaria o mesmo uma chave pública armazenada dessa maneira extremamente difíceis de localizar e recuperar. A criação de um recipiente de armazenamento de chave é muito simples; aqui está um exemplo usando o provedor RSA que cria a chave de nosso. Se o recipiente de chave já existir, a chave é carregada automaticamente no provedor de:

CspParameters CspParam = new CspParameters();
CspParam.KeyContainerName = "SampleContainerName";
RSACryptoServiceProvider RSAProvider = new 
  RSACryptoServiceProvider(CspParam);

Também existem outras opções que você pode considerar com base em suas necessidades. Por exemplo, você pode usar sinalizadores específicos para proteger a chave para o usuário que criou o recipiente. Isso pode ser feito com o uso de CspParameters sinalizadores de membro:

CspParam.Flags = CspProviderFlags.UseUserProtectedKey;

Agora, crie uma solicitação para o API usando sua chave de armazenamento Windows Azure blob. A solicitação si exige uma seqüência de caracteres de assinatura, assim como um cabeçalho de solicitação adequada. O formato de cabeçalho correta é:

Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"

Nesse caso, quero maximize a segurança de Meus dados de  secret persistentes, para que eu use o método de autorização SharedKey. Parte do cabeçalho da assinatura é um código de autenticação baseada em hash gerado pelo algoritmo SHA256 e sua chave de armazenamento com os dados na assinatura. Em seguida, esse hash é codificado em uma seqüência de caracteres base64. Uma assinatura de exemplo teria esta aparência:

"PUT\n\ntext/plain; charset=UTF-8\n\nx-ms-Date:Fri, 12 Sep 2009 22:33:41 GMT\nx-ms-meta-m1:v1\nx-ms-meta-m2:v2\n/exampleaccount/storageclientcontainer/keys.txt"

Conforme descrito anteriormente, em seguida, eu seria gerar hash codificada em base64 e use que no cabeçalho como a assinatura. Este arquivo de chave, em seguida, só possa ser acessado por pessoas com um aplicativo executado no seu espaço de aplicativo na nuvem Windows Azure com acesso a chaves de armazenamento. Modo que com persistência chave, você pode tanto gerenciar as chaves de fora a estrutura do Windows Azure ou dentro da nuvem propriamente dito.

Ameaças à segurança e chave

Um item que vale a pena que cobre pelo menos uma breve é segurança. Este é um tópico um pouco diferente de como persistir e armazene chaves. As próprias chaves são essencialmente seqüências de caracteres que têm um alto nível de entropia, ou seja, um nível extremamente alto de aleatoriedade. Na verdade, isso pode levar a um processo comum de ataque para encontrar chaves dentro de um sistema. Por exemplo, se você participar de um despejo de memória ou em uma área de dados em um disco rígido, áreas de entropia extremamente alta são excelente lugar para iniciar mineração para chaves.

Além de Escolhendo boas práticas de segurança com base nas necessidades de seu aplicativo e proteger seus dados, outra forma você pode proteger-se? Para iniciar, sempre assumir que os processos que você está usando para descriptografar, criptografar e proteger os dados são bem conhecidos para qualquer invasor. Com isso em mente, certifique-se de suas chaves de ciclo regular e mantê-los protegidos. Lhes somente às pessoas que devem fazer uso delas e restringir sua exposição a chaves obtendo fora do seu controle.

Por fim, investir tempo diagramação o fluxo de dados, seguros e inseguras. Dê uma olhada em que vai de seus dados e como, onde você armazena segredos e especialmente onde seus dados cruza limites como redes públicas e particulares. Isso dar uma boa idéia de onde os dados são expostos e permitem que você esses riscos com planos para mitigá-los de maneira simples de destino.

Uma questão relacionada que pediu que é Windows Azure oferece suporte a SSL. A resposta curta a isso é Sim! Windows Azure não seria uma plataforma de nuvem muito com capacidade para serviços baseados na Web e aplicativos sem suportam para SSL.

Criptografia com Azure SQL

O lançamento do SQL Server 2008 introduziu um novo recurso: criptografia de dados transparente (TDE). Pela primeira vez, SQL Server pode criptografar seus dados totalmente com muito pouco esforço necessário além do que era necessário para a criptografia limitada disponível no SQL Server 2005. No entanto, a versão inicial do armazenamento SQL Azure ainda não há suporte para criptografia de nível de banco de dados, embora seja um recurso que está sendo considerando para uma versão futura. É preciso observar que SQL Azure só está disponível através da porta 1433 e apenas por meio de conexões TCP; ele atualmente não ficam exposto em outras portas.

Embora este recurso ainda não está integrado ao Windows Azure, há vários recursos de segurança do SQL Azure que o desenvolvedor ou designer deve ter em mente. Em primeiro lugar, SQL Azure suporta o fluxo de dados tabulares (TDS). Isso significa que a maioria pode conectar-se e interagir com o banco de dados da mesma forma que você sempre feitas. Tirando proveito do ADO.NET criptografia e certificados de servidor confiável vale a pena considerar, especialmente ao acessar o banco de dados SQL Azure de fora da nuvem.

As propriedades de conexão Encrypt = True e TrustServerCertificate = False, em combinação correta, irá garantir a transmissão de dados é seguro e pode ajudar a impedir ataques man-in-the-middle. Isso também é um requisito para conectar-se ao SQL Azure — não é possível se conectar ao SQL Azure a menos que a criptografia em nível de conexão foi ativada.

O segundo recurso de segurança do SQL Azure você deve se familiarizar com é o firewall SQL Azure. Essa ferramenta será bastante familiar àqueles que usou os firewalls de software local ou conjuntos de ferramentas Área de superfície de segurança de mesmo SQL Server. Ele permite que você permitir ou impedir conexões a partir de várias fontes, totalmente para baixo para endereços IP específicos ou intervalos. O firewall SQL Azure pode ser gerenciado via portal SQL Azure ou diretamente no banco de dados mestre com os procedimentos armazenados fornecidos como sp_set_firewall_rule e sp_delete_firewall_rule.

Como ocorre com qualquer implementação do SQL Server, gerenciamento de contas de usuário é outro aspecto deve ser bem controlado. O firewall do SQL Azure é realmente uma ferramenta excelente, mas ele não deve ser considerado por si só. Usuário de contas com senhas fortes e configurado com específicas direitos devem ser usados também para complementar o modelo de segurança de dados.

Essas novas ferramentas percorrem um longo caminho em direção ao fazer SQL Azure uma plataforma gerenciada rigidamente protegida para aplicativos baseados em nuvem. Se você estiver experimentando esse serviço pela primeira vez, lembre-se de que, antes de se conectar, você deve inicialmente configurar o firewall SQL Azure. Isso primeiro deve ser feito através do portal da Web Azure do SQL, mas pode ser feito mais tarde diretamente no banco de dados mestre conforme descrito anteriormente.

Recursos de imutabilidade e na memória

Immuta what? Imutabilidade na programação orientada a objeto significa simplesmente que o estado do objeto não pode ser modificado após sua criação inicial. Um exemplo concreto do Microsoft .NET Framework é a classe de seqüência de caracteres. Quando o valor de uma seqüência de caracteres é alterado no código, a seqüência de caracteres original na memória é simplesmente abandonada e um novo objeto de seqüência é criado para armazenar o novo valor.

Por que isso é importante de uma perspectiva de segurança? Bem, seqüência de caracteres pode permanecer na memória enquanto estiver on-line sem precisar reinicializar o servidor. Você realmente não tem nenhuma maneira de saber com certeza quanto uma seqüência de caracteres permanecerá na memória. Isso é importante ao considerar como armazenar informações no código, como chaves de criptografia ou cópias dos dados criptografados e descriptografados. Deixando uma trilha desses dados atrás de você na memória, deixar as informações que expõe seus segredos para o ladrão de dados inteligente.

Por causa desta vulnerabilidade, é sempre recomendável que esses dados ser armazenado em buffers, como matrizes de bytes. Dessa maneira, assim que terminar com as informações, você pode substituir o buffer com zeros ou outros dados que garante que os dados não estão mais na memória.

Porque Windows Azure é um ambiente em nuvem tiver sido perguntei se este é uma ainda uma preocupação, e é uma boa pergunta. É verdade, no Windows Azure aplicativos individuais do sistema são isolados uns dos outros. Isso torna exposição de dados na memória muito menos de um problema em geral. Seria muito difícil associar aplicativos e espaço de memória na nuvem. No entanto, é ainda recomendável abordagem cuidadosa e limpeza após a mesmo. Você não pode executar sempre esta parte do código na nuvem e outras vulnerabilidades pode ser expostas no futuro. Ao menos uma preocupação, mantenha esse hábito e manter essa abordagem.

Do Figura 3 tenha modifiquei o exemplo anterior que gerou inteiros aleatórios. Aqui eu adicionei um pouco de tratamento de erros para garantir que eu tenha um bloco finally que sempre é executado, não importa. Dentro desse bloco estou fazendo uma iteração muito simples através de valores da matriz de bytes, substituindo cada posição com um zero. Isso substitui esses dados na memória como matrizes de bytes são mutáveis. Sei que esse número não está mais na memória pertencente a execução desse membro. Isso pode ser feito para qualquer array de byte usado como um buffer de dados para os itens, como chaves, vetores de inicialização e dados criptografados ou descriptografados.

Figura 3 de eliminação de dados de memória

public static int GenerateRandomNumber() {
  byte[] GeneratedBytes = null;

  try {
    GeneratedBytes = new byte[4];
    RNGCryptoServiceProvider CSP = 
      new RNGCryptoServiceProvider();
    CSP.GetBytes(GeneratedBytes);
    return BitConverter.ToInt32(GeneratedBytes, 0);
  }
  finally {
    for (int x = 0; x < GeneratedBytes.Length; x++) { 
      GeneratedBytes[x] = 0;
    }
  }
}

Filas de mensagens

Filas Windows Azure fornecem um conjunto semelhante de funcionalidade para os serviços Microsoft Message Queuing (MSMQ) que são comuns a aplicativos do Windows empresarial. O serviço de fila de mensagem no Windows Azure armazena as mensagens com base em texto não maiores que 8 KB de uma maneira de fila (FIFO) primeiro a entrar. Isso permite que os serviços e aplicativos executados em servidores diferentes — ou no caso em nuvem — interagir e enviar mensagens acionáveis entre si de maneira segura e distribuída.

Há cinco funções básicas que permitem que você enviar uma mensagem para a fila, exibir uma mensagem, uma mensagem de recepção e assim por diante. A questão chegou até mais freqüentemente é: nível de segurança são essas mensagens?

Muitos dos recursos suportados no momento pelo MSMQ não são ainda suportados dentro do Azure Windows APIs de mensagens. No entanto, há semelhanças. Como com o serviço de dados blob, os serviços de mensagens faz uso do mesmo get REST e colocar interfaces. Gravar e ler mensagens podem ser feitas no código ou com um URI e chamadas de solicitação da Web que podem ser criptografados por meio de SSL para solicitações em redes não seguras. Isso significa que a transmissão de solicitações é criptografado.

Além disso, como com o outro armazenamento serviços no Windows Azure, nenhum acesso a uma fila de mensagens deve fazer usa a mesma chave de serviço de armazenamento. Somente aplicativos com acesso à chave podem exiba ou adicione as mensagens para essas filas. Isso faz com qualquer criptografia adicional de  unless de um exagero essas mensagens de corpo dessas mensagens vai ser saem da rede protegida ou protegidas de espaço de aplicativo.

Conclusão all para cima

Na unidade de hoje em direção a arquitetura orientada a serviços e soluções, poucos podem considerar fazer negócios sem aplicativos de nuvem. O isolamento de dados e serviços em um ambiente de diversos clientes, como Windows Azure é uma das principais preocupações de qualquer pessoa que tenha um olho em direção usando dados particulares.

Como com qualquer nova plataforma, recursos de criptografia e segurança continuarão a evoluir em plataforma Windows Azure. Microsoft tomou grande problemas não apenas fornecem um ambiente seguro e isolado, mas também para expor o que tem feito para permitir a certificação pública dessas medidas. Isso deve dar engenheiros que a Microsoft quer ser um parceiro mais detalhadamente sobre segurança e manter sistemas e aplicativos de confiança é bloqueada.

O ponto inteiro de segurança e criptografia especialmente é tornar muito difícil obter acesso a suas informações e processos. Podemos definir “ duro ” como significado é além da capacidade de qualquer adversário invadir um sistema desse tipo durante a vida útil desses dados ou processo. Essa é, no entanto, uma definição relativa com base nos requisitos do aplicativo ou dados que está sendo usados. É por isso que eu tenha continuou a Enfatize a necessidade de constante avaliação de segurança e requisitos de criptografia por meio deste artigo. É essencial para garantir que essas ferramentas podem ser usadas com eficiência para tornar seu sistema nuvem seguro e proteger seus dados.

Jonathan Wiggs é atualmente um principal engenheiro e gerente de desenvolvimento em Nuance Communications Inc. ler seu blog em jonwiggs.com ou o contato Wiggs diretamente na Jon_Wiggs@yahoo.com.