Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Use apenas cifras de bloco simétrico aprovadas e comprimentos de chave
| Título | Detalhes |
|---|---|
| Componente | Aplicação Web |
| Fase SDL | Construir |
| Tecnologias aplicáveis | Genérico |
| Atributos | N/A |
| Referências | N/A |
| Passos | Os produtos devem usar apenas as cifras de bloco simétricas e 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:
Observe que todas as cifras de bloco simétrico devem ser usadas com um modo de codificação aprovado, que requer o uso de um vetor de inicialização apropriado (IV). Um IV apropriado, é tipicamente um número aleatório e nunca um valor constante O uso de algoritmos de criptografia herdados ou não aprovados e comprimentos de chave menores para ler dados existentes (em oposição à gravação de novos dados) pode ser permitido após a revisão do Crypto Board da sua organização. No entanto, você deve entrar com um pedido de exceção contra esse requisito. Além disso, em implantações corporativas, os produtos devem considerar avisar os administradores quando a criptografia fraca é usada para ler dados. Essas advertências devem ser explicativas e acionáveis. Em alguns casos, pode ser apropriado que a Diretiva de Grupo controle o uso de criptografia fraca Algoritmos .NET permitidos para agilidade de criptografia gerenciada (em ordem de preferência)
Por favor, note que nenhum desses algoritmos pode ser especificado através dos |
Usar modos de codificação de bloco aprovados e vetores de inicialização para cifras simétricas
| Título | Detalhes |
|---|---|
| Componente | Aplicação Web |
| Fase SDL | Construir |
| Tecnologias aplicáveis | Genérico |
| Atributos | N/A |
| Referências | N/A |
| Passos | 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, deve ser evitado o modo de funcionamento do livro eletrónico de códigos (ECB); o uso do BCE 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 codificação de streaming", como CTR, pode fazer com que dados criptografados sejam revelados. Todas as cifras de bloco simétrico também devem ser usadas com um vetor de inicialização apropriado (IV). Um IV apropriado é um número criptograficamente forte, aleatório e nunca um valor constante. |
Use algoritmos assimétricos, comprimentos de chave e preenchimento aprovados
| Título | Detalhes |
|---|---|
| Componente | Aplicação Web |
| Fase SDL | Construir |
| Tecnologias aplicáveis | Genérico |
| Atributos | N/A |
| Referências | N/A |
| Passos | A utilização de algoritmos criptográficos proibidos introduz riscos significativos para a segurança dos produtos e deve ser evitada. Os produtos devem usar apenas os algoritmos criptográficos e comprimentos de chave e preenchimento associados que foram explicitamente aprovados pelo Conselho de Criptografia da sua organização.
|
Use geradores de números aleatórios aprovados
| Título | Detalhes |
|---|---|
| Componente | Aplicação Web |
| Fase SDL | Construir |
| Tecnologias aplicáveis | Genérico |
| Atributos | N/A |
| Referências | N/A |
| Passos | Os produtos devem utilizar geradores de números aleatórios aprovados. Funções pseudoaleatórias, como a função de tempo de execução C rand, a classe System.Random do .NET Framework ou funções do sistema, como GetTickCount, nunca devem, portanto, ser usadas em tal código. É proibido o uso do algoritmo gerador de números aleatórios de curva elíptica dupla (DUAL_EC_DRBG)
|
Não use cifras de fluxo simétricas
| Título | Detalhes |
|---|---|
| Componente | Aplicação Web |
| Fase SDL | Construir |
| Tecnologias aplicáveis | Genérico |
| Atributos | N/A |
| Referências | N/A |
| Passos | Não devem ser utilizadas cifras de fluxo simétricas, como RC4. 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 aprovados de hash MAC/HMAC/com chave
| Título | Detalhes |
|---|---|
| Componente | Aplicação Web |
| Fase SDL | Construir |
| Tecnologias aplicáveis | Genérico |
| Atributos | N/A |
| Referências | N/A |
| Passos | 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 código de autenticação de mensagem (MAC) é uma informação anexada a uma mensagem que permite ao seu 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 criptografia simétrica ou hash 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 com a plataforma, mas você será obrigado a registrar uma exceção a este procedimento e passar pela revisão de criptografia da sua organização. Não é permitido o truncamento de HMACs para menos de 128 bits. O uso de métodos de cliente para hash de uma chave e dados não é aprovado e deve passar pela revisão do Crypto Board da sua organização antes de usá-lo. |
Usar apenas funções hash criptográficas aprovadas
| Título | Detalhes |
|---|---|
| Componente | Aplicação Web |
| Fase SDL | Construir |
| Tecnologias aplicáveis | Genérico |
| Atributos | N/A |
| Referências | N/A |
| Passos | 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 ajustar uma estrutura de dados projetada com o hash MD5 mais curto em mente, as equipes de produto podem truncar um dos hashes SHA2 (normalmente SHA256). Observe que SHA384 é uma versão truncada do SHA512. Não é permitido o truncamento de hashes criptográficos para fins de segurança para menos de 128 bits. O novo código não deve usar os algoritmos de hash MD2, MD4, MD5, SHA-0, SHA-1 ou RIPEDD. 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):
|
Use algoritmos de criptografia fortes para criptografar dados no banco de dados
| Título | Detalhes |
|---|---|
| Componente | Base de dados |
| Fase SDL | Construir |
| Tecnologias aplicáveis | Genérico |
| Atributos | N/A |
| Referências | Escolher um algoritmo de encriptação |
| Passos | Os algoritmos de encriptação definem transformações de dados que não podem ser facilmente revertidas por utilizadores 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 SDL | Construir |
| Tecnologias aplicáveis | Genérico |
| Atributos | N/A |
| Referências | Identificar a origem dos pacotes com assinaturas digitais, mitigação de ameaças e vulnerabilidades (Integration Services) |
| Passos | A origem de um pacote é o indivíduo ou organização que criou o pacote. Executar um pacote de uma fonte desconhecida ou não confiável pode ser arriscado. Para evitar a adulteração não autorizada 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 às entidades protegidas de bancos de dados críticos.
| Título | Detalhes |
|---|---|
| Componente | Base de dados |
| Fase SDL | Construir |
| Tecnologias aplicáveis | Genérico |
| Atributos | N/A |
| Referências | ADICIONAR ASSINATURA (Transact-SQL) |
| Passos | 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, montagem ou gatilho, podem ser assinados digitalmente. Abaixo está um exemplo de quando isso pode ser útil: Digamos que um ISV (Fornecedor Independente de Software) forneceu 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 fosse adulterado por engano ou por uma tentativa maliciosa. Se o protegível for assinado digitalmente, o ISV pode 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 SDL | Construir |
| Tecnologias aplicáveis | Genérico |
| Atributos | N/A |
| Referências | Gerenciamento extensível de chaves (EKM) do SQL Server, Gerenciamento extensível de chaves usando o Cofre de Chaves do Azure (SQL Server) |
| Passos | 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 off-box, 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 apenas 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 puderem ser reveladas ao mecanismo de banco de dados
| Título | Detalhes |
|---|---|
| Componente | Base de dados |
| Fase SDL | Construir |
| Tecnologias aplicáveis | SQL Azure, OnPrem |
| Atributos | Versão SQL - V12, MsSQL2016 |
| Referências | Sempre criptografado (Mecanismo de Banco de Dados) |
| Passos | 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 nacionais/regionais (por exemplo, números de segurança social dos EUA), armazenados no Banco de Dados SQL do Azure ou 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 SDL | Construir |
| Tecnologias aplicáveis | Genérico |
| Atributos | SO do dispositivo - Windows IoT Core, conectividade de dispositivo - SDKs de dispositivo IoT do Azure |
| Referências | TPM no Windows IoT Core, Configurar TPM no Windows IoT Core, Azure IoT Device SDK TPM |
| Passos | Chaves privadas simétricas ou de certificado de forma segura em um armazenamento protegido por hardware, como TPM ou chips de cartão inteligente. O Windows 10 IoT Core suporta o usuário de um TPM e há vários TPMs compatíveis que podem ser usados: TPM discreto (dTPM). Recomenda-se a utilização de um Firmware ou de um TPM Discreto. Um TPM de software só deve ser usado para fins de desenvolvimento e teste. Uma vez que um TPM esteja disponível e as chaves sejam provisionadas nele, o código que gera o token deve 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.
Gere uma chave simétrica aleatória de comprimento suficiente para autenticação no Hub IoT
| Título | Detalhes |
|---|---|
| Componente | Gateway de nuvem IoT |
| Fase SDL | Construir |
| Tecnologias aplicáveis | Genérico |
| Atributos | Escolha de gateway - Hub IoT do Azure |
| Referências | N/A |
| Passos | O Hub IoT contém um Registro de Identidade de 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 em vigor que exija um PIN de uso e permita o apagamento remoto
| Título | Detalhes |
|---|---|
| Componente | Cliente do Dynamics CRM Mobile |
| Fase SDL | Implantação |
| Tecnologias aplicáveis | Genérico |
| Atributos | N/A |
| Referências | N/A |
| Passos | Verifique se há uma política de gerenciamento de dispositivos em vigor que exija um PIN de uso e permita o apagamento remoto |
Verifique se existe 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 Outlook do Dynamics CRM |
| Fase SDL | Construir |
| Tecnologias aplicáveis | Genérico |
| Atributos | N/A |
| Referências | N/A |
| Passos | Verifique se existe uma política de gerenciamento de dispositivos que exija um PIN/senha/bloqueio automático e criptografe todos os dados (por exemplo, BitLocker) |
Verifique se as chaves de assinatura são substituídas ao usar o Identity Server
| Título | Detalhes |
|---|---|
| Componente | Servidor de identidade |
| Fase SDL | Implantação |
| Tecnologias aplicáveis | Genérico |
| Atributos | N/A |
| Referências | N/A |
| Passos | 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 SDL | Construir |
| Tecnologias aplicáveis | Genérico |
| Atributos | N/A |
| Referências | N/A |
| Passos | Certifique-se de que o ID do cliente criptograficamente forte, o segredo do cliente sejam usados no Servidor de Identidade. As seguintes diretrizes devem ser usadas ao gerar um ID de cliente e segredo:
|