Compartilhar via

Quadro de Segurança: Criptografia | Mitigação

Produto/Serviço Artigo
Aplicativo Web
Banco de dados
Dispositivo IoT
Gateway de Nuvem IoT
Cliente Móvel do Dynamics CRM
Cliente do Dynamics CRM Outlook
Servidor de identidade

Use apenas cifras de bloco simétricas aprovadas e comprimentos de chave

Título Detalhes
Componente Aplicativo Web
Fase do SDL Construir
Tecnologias aplicáveis Genérico
Atributos Não aplicável
Referências Não aplicável
Etapas

Os produtos devem usar apenas as criptografias de bloco simétricas e os comprimentos de chave associados que foram explicitamente aprovados pelo Crypto Advisor em sua organização. Os algoritmos simétricos aprovados na Microsoft incluem as seguintes cifras de bloco:

  • Para o novo código AES-128, AES-192 e AES-256 são aceitáveis
  • Para compatibilidade com versões anteriores do código existente, o 3DES de três teclas é aceitável
  • Para produtos que usam criptografias de bloco simétrico:
    • O AES (Advanced Encryption Standard) é necessário para o novo código
    • O 3DES (Padrão de Criptografia de Dados triplo) de três chaves é permitido no código existente para compatibilidade com versões anteriores
    • Todas as outras cifras de bloco, incluindo RC2, DES, 2 Key 3DES, DESX e Skipjack, só podem ser usadas para descriptografar dados antigos e devem ser substituídas se usadas para criptografia
  • Para algoritmos de criptografia de bloco simétrico, é necessário um comprimento mínimo de chave de 128 bits. O único algoritmo de criptografia de bloco recomendado para o novo código é o AES (AES-128, AES-192 e AES-256 são todos aceitáveis)
  • O 3DES de três teclas é atualmente aceitável se já estiver em uso no código existente; recomenda-se a transição para AES. DES, DESX, RC2 e Skipjack não são mais considerados seguros. Esses algoritmos só podem ser usados para descriptografar dados existentes por uma questão de compatibilidade com versões anteriores, e os dados devem ser criptografados novamente usando uma cifra de bloco recomendada

Observe que todas as cifras de bloco simétrico devem ser usadas com um modo de cifra aprovado, o que requer o uso de um vetor de inicialização apropriado (IV). Um IV apropriado é normalmente um número aleatório e nunca um valor constante

O uso de algoritmos de criptografia legados ou não aprovados e comprimentos de chave menores para ler dados existentes (em vez de gravar novos dados) pode ser permitido após a revisão do Crypto Board da sua organização. No entanto, você deve solicitar uma exceção contra esse requisito. Além disso, em implantações corporativas, os produtos devem considerar avisar os administradores quando criptografia fraca for usada para ler dados. Tais advertências devem ser explicativas e acionáveis. Em alguns casos, pode ser apropriado que a Política de Grupo controle o uso de criptografia fraca

Algoritmos .NET permitidos para agilidade de criptografia gerenciada (em ordem de preferência)

  • AesCng (compatível com FIPS)
  • AuthenticatedAesCng (compatível com FIPS)
  • AESCryptoServiceProvider (compatível com FIPS)
  • AESManaged (não compatível com FIPS)

Observe que nenhum desses algoritmos pode ser especificado por meio dos SymmetricAlgorithm.Create métodos or CryptoConfig.CreateFromName sem fazer alterações no arquivo machine.config. Além disso, observe que o AES em versões do .NET anteriores ao .NET 3.5 é denominado RijndaelManaged, e AuthenticatedAesCngAesCng está >disponível por meio do CodePlex e requer CNG no sistema operacional subjacente

Usar modos de codificação de bloco aprovados e vetores de inicialização para cifras simétricas

Título Detalhes
Componente Aplicativo Web
Fase do SDL Construir
Tecnologias aplicáveis Genérico
Atributos Não aplicável
Referências Não aplicável
Etapas Todas as cifras de bloco simétrico devem ser usadas com um modo de cifra simétrica aprovado. Os únicos modos aprovados são CBC e CTS. Em particular, o modo de funcionamento do livro de códigos eletrónicos (BCE) deve ser evitado; o uso do ECB requer a revisão do Crypto Board da sua organização. Todo o uso de OFB, CFB, CTR, CCM e GCM ou qualquer outro modo de criptografia deve ser revisado pelo Crypto Board da sua organização. Reutilizar o mesmo vetor de inicialização (IV) com cifras de bloco em "modos de cifras de streaming", como CTR, pode fazer com que os dados criptografados sejam revelados. Todas as cifras de bloco simétricas também devem ser usadas com um vetor de inicialização apropriado (IV). Um IV apropriado é um número aleatório criptograficamente forte e nunca um valor constante.

Use algoritmos assimétricos aprovados, comprimentos de chave e preenchimento

Título Detalhes
Componente Aplicativo Web
Fase do SDL Construir
Tecnologias aplicáveis Genérico
Atributos Não aplicável
Referências Não aplicável
Etapas

O uso de algoritmos criptográficos proibidos apresenta riscos significativos à segurança do produto e deve ser evitado. Os produtos devem usar apenas os algoritmos criptográficos e os comprimentos de chave e preenchimento associados que foram explicitamente aprovados pelo Crypto Board da sua organização.

  • RSA- pode ser usado para criptografia, troca de chaves e assinatura. A criptografia RSA deve usar apenas os modos de preenchimento OAEP ou RSA-KEM. O código existente pode usar o modo de preenchimento PKCS #1 v1.5 apenas para compatibilidade. O uso de preenchimento nulo é explicitamente proibido. Keys >= 2048 bits é necessário para o novo código. O código existente pode suportar chaves < de 2048 bits apenas para compatibilidade com versões anteriores após uma revisão pelo Crypto Board da sua organização. As chaves < de 1024 bits só podem ser usadas para descriptografar/verificar dados antigos e devem ser substituídas se usadas para operações de criptografia ou assinatura
  • ECDSA- pode ser usado apenas para assinatura. ECDSA com >chaves =256 bits é necessário para o novo código. As assinaturas baseadas em ECDSA devem usar uma das três curvas aprovadas pelo NIST (P-256, P-384 ou P521). As curvas que foram minuciosamente analisadas podem ser usadas somente após uma revisão com o Crypto Board da sua organização.
  • ECDH- pode ser usado apenas para troca de chaves. ECDH com >chaves =256 bits é necessário para o novo código. A troca de chaves baseada em ECDH deve usar uma das três curvas aprovadas pelo NIST (P-256, P-384 ou P521). As curvas que foram minuciosamente analisadas podem ser usadas somente após uma revisão com o Crypto Board da sua organização.
  • DSA- pode ser aceitável após análise e aprovação do Crypto Board da sua organização. Entre em contato com seu consultor de segurança para agendar a revisão do Crypto Board da sua organização. Se o uso do DSA for aprovado, observe que você precisará proibir o uso de chaves com menos de 2048 bits de comprimento. O CNG dá suporte a comprimentos de chave de 2048 bits e maiores a partir do Windows 8.
  • Diffie-Hellman- pode ser usado apenas para gerenciamento de chaves de sessão. Comprimento da >chave = 2048 bits é necessário para o novo código. O código existente pode suportar comprimentos de < chave de 2048 bits apenas para compatibilidade com versões anteriores após uma revisão pelo Crypto Board da sua organização. Chaves < 1024 bits não podem ser usadas.

    Use geradores de números aleatórios aprovados

    Título Detalhes
    Componente Aplicativo Web
    Fase do SDL Construir
    Tecnologias aplicáveis Genérico
    Atributos Não aplicável
    Referências Não aplicável
    Etapas

    Os produtos devem usar geradores de números aleatórios aprovados. Funções pseudoaleatórias, como a função de runtime C rand, a classe System.Random do .NET Framework ou funções do sistema, como GetTickCount, nunca devem ser usadas nesse código. É proibida a utilização do algoritmo gerador de números aleatórios (DUAL_EC_DRBG) de curva elíptica dupla

    • GNV- BCryptGenRandom(uso do sinalizador BCRYPT_USE_SYSTEM_PREFERRED_RNG recomendado, a menos que o chamador possa ser executado em qualquer IRQL maior que 0 [ou seja, PASSIVE_LEVEL])
    • CAPI- cryptGenRandom
    • Win32/64- RtlGenRandom (novas implementações devem usar BCryptGenRandom ou CryptGenRandom) * rand_s * SystemPrng (para o modo kernel)
    • . NET- RNGCryptoServiceProvider ou RNGCng
    • Aplicativos da Windows Store- Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom ou . GenerateRandomNumber
    • Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef aleatório, contagem de size_t, uint8_t *bytes)
    • Apple OS X (<10.7)- Use /dev/random para recuperar números aleatórios
    • Java (incluindo o código Java do Google Android) - classe java.security.SecureRandom. Observe que, para o Android 4.3 (Jelly Bean), os desenvolvedores devem seguir a solução alternativa recomendada pelo Android e atualizar seus aplicativos para inicializar explicitamente o PRNG com entropia de /dev/urandom ou /dev/random

    Não use cifras de fluxo simétricas

    Título Detalhes
    Componente Aplicativo Web
    Fase do SDL Construir
    Tecnologias aplicáveis Genérico
    Atributos Não aplicável
    Referências Não aplicável
    Etapas Cifras de fluxo simétricas, como RC4, não devem ser usadas. Em vez de cifras de fluxo simétricas, os produtos devem usar uma cifra de bloco, especificamente AES com um comprimento de chave de pelo menos 128 bits.

    Use algoritmos de hash MAC/HMAC/chaveados aprovados

    Título Detalhes
    Componente Aplicativo Web
    Fase do SDL Construir
    Tecnologias aplicáveis Genérico
    Atributos Não aplicável
    Referências Não aplicável
    Etapas

    Os produtos devem usar apenas algoritmos de código de autenticação de mensagem (MAC) aprovado ou código de autenticação de mensagem baseado em hash (HMAC).

    Um MAC (código de autenticação de mensagem) é uma parte das informações anexadas a uma mensagem que permite ao destinatário verificar a autenticidade do remetente e a integridade da mensagem usando uma chave secreta. O uso de um MAC baseado em hash (HMAC) ou MAC baseado em cifra de bloco é permitido, desde que todos os algoritmos subjacentes de hash ou criptografia simétrica também sejam aprovados para uso; atualmente, isso inclui as funções HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 e HMAC-SHA512) e os MACs baseados em cifra de bloco CMAC/OMAC1 e OMAC2 (estes são baseados em AES).

    O uso de HMAC-SHA1 pode ser permitido para compatibilidade de plataforma, mas você precisará registrar uma exceção a este procedimento e passar pela revisão de criptografia da sua organização. O truncamento de HMACs para menos de 128 bits não é permitido. O uso de métodos do cliente para fazer hash de uma chave e dados não é aprovado e deve passar pela revisão do Crypto Board da sua organização antes do uso.

    Usar apenas funções de hash criptográficas aprovadas

    Título Detalhes
    Componente Aplicativo Web
    Fase do SDL Construir
    Tecnologias aplicáveis Genérico
    Atributos Não aplicável
    Referências Não aplicável
    Etapas

    Os produtos devem usar a família SHA-2 de algoritmos de hash (SHA256, SHA384 e SHA512). Se um hash mais curto for necessário, como um comprimento de saída de 128 bits, para se ajustar a uma estrutura de dados projetada com o hash MD5 mais curto em mente, as equipes de produto poderão truncar um dos hashes SHA2 (normalmente SHA256). Observe que o SHA384 é uma versão truncada do SHA512. O truncamento de hashes criptográficos para fins de segurança para menos de 128 bits não é permitido. O novo código não deve usar os algoritmos de hash MD2, MD4, MD5, SHA-0, SHA-1 ou RIPEMD. As colisões de hash são computacionalmente viáveis para esses algoritmos, o que efetivamente os quebra.

    Algoritmos de hash .NET permitidos para agilidade de criptografia gerenciada (em ordem de preferência):

    • SHA512Cng (compatível com FIPS)
    • SHA384Cng (compatível com FIPS)
    • SHA256Cng (compatível com FIPS)
    • SHA512Managed (não compatível com FIPS) (use SHA512 como nome do algoritmo em chamadas para HashAlgorithm.Create ou CryptoConfig.CreateFromName)
    • SHA384Managed (não compatível com FIPS) (use SHA384 como nome do algoritmo em chamadas para HashAlgorithm.Create ou CryptoConfig.CreateFromName)
    • SHA256Managed (não compatível com FIPS) (use SHA256 como nome do algoritmo em chamadas para HashAlgorithm.Create ou CryptoConfig.CreateFromName)
    • SHA512CryptoServiceProvider (compatível com FIPS)
    • SHA256CryptoServiceProvider (compatível com FIPS)
    • SHA384CryptoServiceProvider (compatível com FIPS)

    Use algoritmos de criptografia fortes para criptografar dados no banco de dados

    Título Detalhes
    Componente Base de dados
    Fase do SDL Construir
    Tecnologias aplicáveis Genérico
    Atributos Não aplicável
    Referências Escolhendo um algoritmo de criptografia
    Etapas Algoritmos de criptografia definem transformações de dados que não podem ser facilmente revertidas por usuários não autorizados. O SQL Server permite que administradores e desenvolvedores escolham entre vários algoritmos, incluindo DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, RC4 de 128 bits, DESX, AES de 128 bits, AES de 192 bits e AES de 256 bits

    Os pacotes SSIS devem ser criptografados e assinados digitalmente

    Título Detalhes
    Componente Base de dados
    Fase do SDL Construir
    Tecnologias aplicáveis Genérico
    Atributos Não aplicável
    Referências Identificar a origem dos pacotes com assinaturas digitais, mitigação de ameaças e vulnerabilidades (Integration Services)
    Etapas A origem de um pacote é a pessoa ou organização que criou o pacote. Pode ser arriscado executar um pacote de origem desconhecida ou não confiável. Para evitar adulterações não autorizadas de pacotes SSIS, assinaturas digitais devem ser usadas. Além disso, para garantir a confidencialidade dos pacotes durante o armazenamento/trânsito, os pacotes SSIS devem ser criptografados

    Adicionar assinatura digital a protegíveis de banco de dados críticos

    Título Detalhes
    Componente Base de dados
    Fase do SDL Construir
    Tecnologias aplicáveis Genérico
    Atributos Não aplicável
    Referências ADICIONAR ASSINATURA (Transact-SQL)
    Etapas Nos casos em que a integridade de uma base de dados crítica protegível tenha de ser verificada, devem ser utilizadas assinaturas digitais. Os protegíveis de banco de dados, como um procedimento armazenado, função, assembly ou gatilho, podem ser assinados digitalmente. Abaixo está um exemplo de quando isso pode ser útil: Digamos que um ISV (Fornecedor Independente de Software) tenha fornecido suporte a um software entregue a um de seus clientes. Antes de fornecer suporte, o ISV gostaria de garantir que um banco de dados protegível no software não tenha sido adulterado por engano ou por uma tentativa mal-intencionada. Se o protegível for assinado digitalmente, o ISV poderá verificar sua assinatura digital e validar sua integridade.

    Usar o SQL Server EKM para proteger chaves de criptografia

    Título Detalhes
    Componente Base de dados
    Fase do SDL Construir
    Tecnologias aplicáveis Genérico
    Atributos Não aplicável
    Referências SQL Server EKM (Gerenciamento Extensível de Chaves),Gerenciamento Extensível de Chaves Usando o Azure Key Vault (SQL Server)
    Etapas O Gerenciamento Extensível de Chaves do SQL Server permite que as chaves de criptografia que protegem os arquivos de banco de dados sejam armazenadas em um dispositivo pronto para uso, como um cartão inteligente, dispositivo USB ou módulo EKM/HSM. Isso também permite a proteção de dados de administradores de banco de dados (exceto membros do grupo sysadmin). Os dados podem ser criptografados usando chaves de criptografia às quais somente o usuário do banco de dados tem acesso no módulo EKM/HSM externo.

    Use o recurso AlwaysEncrypted se as chaves de criptografia não precisarem ser reveladas ao mecanismo de banco de dados

    Título Detalhes
    Componente Base de dados
    Fase do SDL Construir
    Tecnologias aplicáveis SQL Azure, OnPrem
    Atributos Versão SQL - V12, MsSQL2016
    Referências Always Encrypted (mecanismo de banco de dados)
    Etapas O Always Encrypted é um recurso projetado para proteger dados confidenciais, como números de cartão de crédito ou números de identificação nacional/regional (por exemplo, números de previdência social dos EUA), armazenados no Banco de Dados SQL do Azure ou em bancos de dados do SQL Server. O Always Encrypted permite que os clientes criptografem dados confidenciais dentro de aplicativos cliente e nunca revelem as chaves de criptografia para o Mecanismo de Banco de Dados (Banco de Dados SQL ou SQL Server). Como resultado, o Always Encrypted fornece uma separação entre aqueles que possuem os dados (e podem visualizá-los) e aqueles que gerenciam os dados (mas não devem ter acesso)

    Armazene chaves criptográficas com segurança no dispositivo IoT

    Título Detalhes
    Componente Dispositivo IoT
    Fase do SDL Construir
    Tecnologias aplicáveis Genérico
    Atributos Sistema operacional do dispositivo – Windows IoT Core, conectividade do dispositivo – SDKs do dispositivo IoT do Azure
    Referências TPM no Windows IoT Core, Configurar o TPM no Windows IoT Core, TPM do SDK do Dispositivo IoT do Azure
    Etapas Chaves privadas simétricas ou de certificado com segurança em um armazenamento protegido por hardware, como TPM ou chips de cartão inteligente. Windows 10 IoT Core dá suporte ao usuário de um TPM e há vários TPMs compatíveis que podem ser usados: TPM discreto (dTPM). Recomenda-se usar um Firmware ou TPM discreto. Um TPM de software só deve ser usado para fins de desenvolvimento e teste. Depois que um TPM estiver disponível e as chaves forem provisionadas nele, o código que gera o token deverá ser escrito sem codificar nenhuma informação confidencial nele.

    Exemplo

    TpmDevice myDevice = new TpmDevice(0);
// Use logical device 0 on the TPM 
string hubUri = myDevice.GetHostName(); 
string deviceId = myDevice.GetDeviceId(); 
string sasToken = myDevice.GetSASToken(); 

var deviceClient = DeviceClient.Create( hubUri, AuthenticationMethodFactory. CreateAuthenticationWithToken(deviceId, sasToken), TransportType.Amqp);

    Como pode ser visto, a chave primária do dispositivo não está presente no código. Em vez disso, ele é armazenado no TPM no slot 0. O dispositivo TPM gera um token SAS de curta duração que é usado para se conectar ao Hub IoT.

    Gerar uma chave simétrica aleatória de comprimento suficiente para autenticação no Hub IoT

    Título Detalhes
    Componente Gateway de Nuvem IoT
    Fase do SDL Construir
    Tecnologias aplicáveis Genérico
    Atributos Opção de gateway - Hub IoT do Azure
    Referências Não aplicável
    Etapas O Hub IoT contém um Registro de Identidade do dispositivo e, ao provisionar um dispositivo, gera automaticamente uma chave simétrica aleatória. É recomendável usar esse recurso do Registro de Identidade do Hub IoT do Azure para gerar a chave usada para autenticação. O Hub IoT também permite que uma chave seja especificada durante a criação do dispositivo. Se uma chave for gerada fora do Hub IoT durante o provisionamento do dispositivo, é recomendável criar uma chave simétrica aleatória ou pelo menos 256 bits.

    Verifique se há uma política de gerenciamento de dispositivos que exija um PIN de uso e permita o apagamento remoto

    Título Detalhes
    Componente Cliente Móvel do Dynamics CRM
    Fase do SDL Implantação
    Tecnologias aplicáveis Genérico
    Atributos Não aplicável
    Referências Não aplicável
    Etapas Verifique se há uma política de gerenciamento de dispositivos que exija um PIN de uso e permita o apagamento remoto

    Verifique se há uma política de gerenciamento de dispositivos que exija um PIN/senha/bloqueio automático e criptografe todos os dados (por exemplo, BitLocker)

    Título Detalhes
    Componente Cliente do Dynamics CRM Outlook
    Fase do SDL Construir
    Tecnologias aplicáveis Genérico
    Atributos Não aplicável
    Referências Não aplicável
    Etapas Verifique se há uma política de gerenciamento de dispositivos que exija um PIN/senha/bloqueio automático e criptografe todos os dados (por exemplo, BitLocker)

    Certifique-se de que as chaves de assinatura sejam substituídas ao usar o Identity Server

    Título Detalhes
    Componente Servidor de identidade
    Fase do SDL Implantação
    Tecnologias aplicáveis Genérico
    Atributos Não aplicável
    Referências Não aplicável
    Etapas Certifique-se de que as chaves de assinatura sejam substituídas ao usar o Identity Server. O link na seção de referências explica como isso deve ser planejado sem causar interrupções nos aplicativos que dependem do Identity Server.

    Certifique-se de que o ID do cliente criptograficamente forte e o segredo do cliente sejam usados no Identity Server

    Título Detalhes
    Componente Servidor de identidade
    Fase do SDL Construir
    Tecnologias aplicáveis Genérico
    Atributos Não aplicável
    Referências Não aplicável
    Etapas

    Certifique-se de que a ID do cliente criptograficamente forte e o segredo do cliente sejam usados no Identity Server. As diretrizes a seguir devem ser usadas ao gerar um ID e um segredo do cliente:

    • Gerar um GUID aleatório como a ID do cliente
    • Gerar uma chave de 256 bits criptograficamente aleatória como o segredo