Marco de seguridad: criptografía | Mitigación

2025-05-01

Producto o servicio	Artículo
Aplicación web	Usar solo cifrados de bloques simétricos aprobados y longitudes de clave Uso de modos de cifrado de bloques aprobados e vectores de inicialización para cifrados simétricos Uso de algoritmos asimétricos aprobados, longitudes de clave y relleno Uso de generadores de números aleatorios aprobados No usar cifrados de flujos simétricos Utilice algoritmos de hash MAC/HMAC/con clave aprobados Usar solo funciones hash criptográficas aprobadas
Base de datos	Uso de algoritmos de cifrado seguros para cifrar datos en la base de datos Los paquetes SSIS deben cifrarse y firmarse digitalmente Adición de firmas digitales a elementos protegibles críticos de la base de datos Uso de EKM de SQL Server para proteger las claves de cifrado Usar la característica AlwaysEncrypted si no se deben revelar claves de cifrado en el motor de base de datos
Dispositivo IoT	Almacenamiento de claves criptográficas de forma segura en el dispositivo IoT
Puerta de enlace de nube de IoT	Generación de una clave simétrica aleatoria de longitud suficiente para la autenticación en IoT Hub
Cliente móvil de Dynamics CRM	Asegúrese de que hay una directiva de administración de dispositivos que requiere un PIN de uso y permite el borrado remoto.
Cliente de Outlook de Dynamics CRM	Asegúrese de que hay una directiva de administración de dispositivos que requiere un PIN, una contraseña o un bloqueo automático y cifra todos los datos (por ejemplo, BitLocker).
Identity Server	Asegúrese de que las claves de firma se sustituyen cuando se usa Identity Server Asegúrese de que se utilicen identificador de cliente y secreto de cliente seguros criptográficamente en Identity Server.

Usar solo cifrados de bloques simétricos aprobados y longitudes de clave

Título	Detalles
Componente	Aplicación web
Fase de SDL	Construir
Tecnologías aplicables	Genérico
Atributos	No disponible
Referencias	No disponible
Pasos	Los productos solo deben usar los cifrados de bloques simétricos y las longitudes de clave asociadas aprobadas explícitamente por Crypto Advisor en su organización. Los algoritmos simétricos aprobados en Microsoft incluyen los siguientes cifrados de bloques: Para el nuevo código AES-128, AES-192 y AES-256 son aceptables Para mantener la compatibilidad con versiones anteriores y el código existente, es aceptable usar 3DES con tres claves. Para productos que usan cifrados de bloques simétricos: Se requiere Advanced Encryption Standard (AES) para el nuevo código El estándar de cifrado de datos triple de tres claves (3DES) está permitido en el código existente para la compatibilidad con versiones anteriores Todos los demás cifrados de bloques, incluidos RC2, DES, 2 claves 3DES, DESX y Skipjack, solo se pueden usar para descifrar los datos antiguos y deben reemplazarse si se usan para el cifrado. Para los algoritmos de cifrado de bloques simétricos, se requiere una longitud mínima de clave de 128 bits. El único algoritmo de cifrado de bloques recomendado para el nuevo código es AES (AES-128, AES-192 y AES-256 son aceptables). Actualmente, 3DES de tres claves es aceptable si ya está en uso en el código existente; se recomienda realizar la transición a AES. DES, DESX, RC2 y Skipjack ya no se consideran seguros. Estos algoritmos solo se pueden usar para descifrar los datos existentes por motivos de compatibilidad con versiones anteriores y los datos se deben volver a cifrar mediante un cifrado de bloques recomendado. Tenga en cuenta que todos los cifrados de bloques simétricos deben usarse con un modo de cifrado aprobado, que requiere el uso de un vector de inicialización adecuado (IV). Un IV adecuado suele ser un número aleatorio y nunca un valor constante. El uso de algoritmos criptográficos heredados o no aprobados y longitudes de claves más pequeñas para leer los datos existentes (en lugar de escribir nuevos datos) puede permitirse después de la revisión del Comité de Criptografía de su organización. Sin embargo, debe presentar una excepción contra este requisito. Además, en las implementaciones empresariales, los productos deben considerar la posibilidad de advertir a los administradores cuando se usa criptografía débil para leer datos. Estas advertencias deben ser explicativas y accionables. En algunos casos, puede ser adecuado que la directiva de grupo controle el uso de criptografía débil. Algoritmos de .NET permitidos para la agilidad criptográfica administrada (en orden de preferencia) AesCng (compatible con FIPS) AuthenticatedAesCng (compatible con FIPS) AESCryptoServiceProvider (compatible con FIPS) AESManaged (no compatible con FIPS) Tenga en cuenta que ninguno de estos algoritmos se puede especificar a través de los `SymmetricAlgorithm.Create` métodos o `CryptoConfig.CreateFromName` sin realizar cambios en el archivo machine.config. Además, tenga en cuenta que AES en versiones de .NET anteriores a .NET 3.5 se denomina `RijndaelManaged`, y `AesCng` y `AuthenticatedAesCng` están > disponibles a través de CodePlex y requieren CNG en el sistema operativo subyacente.

Uso de modos de cifrado de bloques aprobados e vectores de inicialización para cifrados simétricos

Título	Detalles
Componente	Aplicación web
Fase de SDL	Construir
Tecnologías aplicables	Genérico
Atributos	No disponible
Referencias	No disponible
Pasos	Todos los cifrados de bloques simétricos deben usarse con un modo de cifrado simétrico aprobado. Los únicos modos aprobados son CBC y CTS. En concreto, debe evitarse el modo de operación de libro de códigos electrónico (ECB); el uso de ECB requiere revisión por parte de la junta de criptografía de su organización. Todo el uso de OFB, CFB, CTR, CCM, GCM o cualquier otro modo de cifrado debe ser revisado por la Junta de Criptografía de su organización. La reutilización del mismo vector de inicialización (IV) con cifrados de bloques en "modos de cifrado de streaming", como CTR, puede provocar que se muestren los datos cifrados. Todos los cifrados de bloques simétricos también deben usarse con un vector de inicialización adecuado (IV). Un IV adecuado es un número criptográficomente seguro, aleatorio y nunca un valor constante.

Use algoritmos asimétricos, longitudes de clave y rellenos aprobados

Título	Detalles
Componente	Aplicación web
Fase de SDL	Construir
Tecnologías aplicables	Genérico
Atributos	No disponible
Referencias	No disponible
Pasos	El uso de algoritmos criptográficos prohibidos presenta un riesgo significativo para la seguridad del producto y debe evitarse. Los productos deben usar únicamente aquellos algoritmos criptográficos, las longitudes de clave asociadas y el relleno que haya sido aprobado explícitamente por el Consejo Criptográfico de su organización. RSA: se puede usar para el cifrado, el intercambio de claves y la firma. El cifrado RSA tiene que usar solo los modos de relleno OAEP o RSA-KEM. El código existente puede utilizar el modo de relleno PKCS #1 v1.5 solo si es necesario para garantizar la compatibilidad. El uso de relleno nulo está prohibido explícitamente. Las claves >= 2048 bits son necesarias para el nuevo código. El código existente puede admitir claves < de 2048 bits solo para la compatibilidad con versiones anteriores, después de una revisión por parte del Consejo de Criptografía de su organización. Las claves < de 1024 bits solo se pueden usar para descifrar o comprobar los datos antiguos y deben reemplazarse si se usan para las operaciones de cifrado o firma. ECDSA: solo se puede usar para la firma. Elliptic Curve Digital Signature Algorithm con >=claves de 256 bits es necesaria para el nuevo código. Las firmas basadas en ECDSA deben usar una de las tres curvas aprobadas por NIST (P-256, P-384 o P521). Las curvas que se han analizado exhaustivamente solo se pueden usar después de una revisión con el Consejo de Criptografía de su organización. ECDH: solo se puede usar para el intercambio de claves. Diffie-Hellman de curva elíptica con claves de >=256 bits es necesaria para el nuevo código. El intercambio de claves basado en ECDH debe usar una de las tres curvas aprobadas por NIST (P-256, P-384 o P521). Las curvas que se han analizado exhaustivamente solo se pueden usar después de una revisión con el Consejo de Criptografía de su organización. DSA- puede ser aceptable después de la revisión y aprobación del Consejo de Criptografía de su organización. Póngase en contacto con su asesor de seguridad para programar la revisión de la Junta de Criptografía de su organización. Si se aprueba el uso de DSA, tenga en cuenta que deberá prohibir el uso de claves de menos de 2048 bits de longitud. CNG admite longitudes de clave de 2048 bits y mayores a partir de Windows 8. Diffie-Hellman: solo se puede usar para la administración de claves de sesión. La longitud >de la clave = 2048 bits es necesaria para el nuevo código. El código existente puede admitir longitudes de clave < de 2048 bits solo para la compatibilidad retroactiva después de una revisión por parte de la Junta Criptográfica de su organización. Es posible que no se usen claves < de 1024 bits.

Uso de generadores de números aleatorios aprobados

Título	Detalles
Componente	Aplicación web
Fase de SDL	Construir
Tecnologías aplicables	Genérico
Atributos	No disponible
Referencias	No disponible
Pasos	Los productos deben usar generadores de números aleatorios aprobados. Las funciones pseudoaleatorias, como la función en tiempo de ejecución de C rand, la clase System.Random de .NET Framework o las funciones del sistema como GetTickCount, por lo tanto, nunca se deben usar en este código. Se prohíbe el uso del algoritmo de generador de número aleatorio de curva elíptica dual (DUAL_EC_DRBG) CNG: BCryptGenRandom (uso de la marca BCRYPT_USE_SYSTEM_PREFERRED_RNG recomendado a menos que el llamador pueda ejecutarse en cualquier IRQL mayor que 0 [es decir, PASSIVE_LEVEL]) CAPI- cryptGenRandom Win32/64- RtlGenRandom (las nuevas implementaciones deben usar BCryptGenRandom o CryptGenRandom) * rand_s * SystemPrng (para el modo kernel) . NET- RNGCryptoServiceProvider o RNGCng Aplicaciones de la Tienda Windows: Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom o .GenerateRandomNumber Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef aleatorio, recuento de size_t, uint8_t bytes ) Apple OS X (<10.7):* use /dev/random para recuperar números aleatorios. Java (incluido el código Java de Google Android)- clase java.security.SecureRandom. Tenga en cuenta que para Android 4.3 (Jelly Bean), los desarrolladores deben seguir la solución alternativa recomendada para Android y actualizar sus aplicaciones para inicializar explícitamente el PRNG con entropía de /dev/urandom o /dev/random

No usar cifrados de flujos simétricos

Título	Detalles
Componente	Aplicación web
Fase de SDL	Construir
Tecnologías aplicables	Genérico
Atributos	No disponible
Referencias	No disponible
Pasos	No se deben usar cifrados de flujo simétricos, como RC4. En lugar de los cifrados de flujos simétricos, los productos deben usar un cifrado de bloques, específicamente AES con una longitud de clave de al menos 128 bits.

Utilice algoritmos MAC/HMAC/hash con claves aprobados

Título	Detalles
Componente	Aplicación web
Fase de SDL	Construir
Tecnologías aplicables	Genérico
Atributos	No disponible
Referencias	No disponible
Pasos	Los productos solo deben usar algoritmos de código de autenticación de mensajes (MAC) aprobados o de código de autenticación de mensajes basado en hash (HMAC). Un código de autenticación de mensajes (MAC) es una parte de la información adjunta a un mensaje que permite a su destinatario comprobar tanto la autenticidad del remitente como la integridad del mensaje mediante una clave secreta. El uso de un MAC basado en hash (HMAC) o mac basado en cifrado de bloques está permitido siempre que todos los algoritmos de cifrado hash subyacentes o simétricos también se aprueben para su uso; actualmente esto incluye las funciones de HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 y HMAC-SHA512) y los MAC basados en cifrado de bloques CMAC/OMAC1 y OMAC2 (estos se basan en AES). El uso de HMAC-SHA1 puede estar permitido para la compatibilidad con la plataforma, pero se le pedirá que presente una excepción a este procedimiento y se someta a la revisión criptográfica de su organización. No se permite el truncamiento de HMAC a menos de 128 bits. El uso de métodos de cliente para producir valores hash de una clave y datos no está aprobado, y tiene que someterse a la revisión de la junta de criptografía de su organización antes de su uso.

Usar solo funciones hash criptográficas aprobadas

Título	Detalles
Componente	Aplicación web
Fase de SDL	Construir
Tecnologías aplicables	Genérico
Atributos	No disponible
Referencias	No disponible
Pasos	Los productos deben usar la familia SHA-2 de algoritmos hash (SHA256, SHA384 y SHA512). Si se necesita un hash más corto, como una longitud de salida de 128 bits para ajustarse a una estructura de datos diseñada con el hash MD5 más corto en mente, los equipos de productos pueden truncar uno de los hash SHA2 (normalmente SHA256). Tenga en cuenta que SHA384 es una versión truncada de SHA512. No se permite el truncamiento de hash criptográficos con fines de seguridad a menos de 128 bits. El nuevo código no debe usar los algoritmos hash MD2, MD4, MD5, SHA-0, SHA-1 o RIPEMD. Las colisiones hash son computacionalmente factibles para estos algoritmos, lo que los rompe de forma eficaz. Algoritmos hash de .NET permitidos para la agilidad criptográfica administrada (en orden de preferencia): SHA512Cng (compatible con FIPS) SHA384Cng (compatible con FIPS) SHA256Cng (compatible con FIPS) SHA512Managed (no compatible con FIPS) (use SHA512 como nombre de algoritmo en llamadas a HashAlgorithm.Create o CryptoConfig.CreateFromName) SHA384Managed (no compatible con FIPS) (use SHA384 como nombre de algoritmo en llamadas a HashAlgorithm.Create o CryptoConfig.CreateFromName) SHA256Managed (no compatible con FIPS) (use SHA256 como nombre de algoritmo en llamadas a HashAlgorithm.Create o CryptoConfig.CreateFromName) SHA512CryptoServiceProvider (compatible con FIPS) SHA256CryptoServiceProvider (compatible con FIPS) SHA384CryptoServiceProvider (compatible con FIPS)

Uso de algoritmos de cifrado seguros para cifrar datos en la base de datos

Título	Detalles
Componente	Base de datos
Fase de SDL	Construir
Tecnologías aplicables	Genérico
Atributos	No disponible
Referencias	Elección de un algoritmo de cifrado
Pasos	Los algoritmos de cifrado definen transformaciones de datos que los usuarios no autorizados no pueden invertir fácilmente. SQL Server permite a los administradores y desarrolladores elegir entre varios algoritmos, como DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, DESX, AES de 128 bits, AES de 192 bits y AES de 256 bits

Los paquetes SSIS deben cifrarse y firmarse digitalmente

Título	Detalles
Componente	Base de datos
Fase de SDL	Construir
Tecnologías aplicables	Genérico
Atributos	No disponible
Referencias	Identificar el origen de paquetes con firmas digitales, mitigación de amenazas y vulnerabilidades (Integration Services)
Pasos	El origen de un paquete es el individuo o la organización que creó el paquete. La ejecución de un paquete desde un origen desconocido o que no sea de confianza puede ser arriesgado. Para evitar la manipulación no autorizada de paquetes SSIS, se deben usar firmas digitales. Además, para garantizar la confidencialidad de los paquetes durante el almacenamiento o tránsito, los paquetes SSIS deben cifrarse.

Adición de firmas digitales a elementos protegibles críticos de la base de datos

Título	Detalles
Componente	Base de datos
Fase de SDL	Construir
Tecnologías aplicables	Genérico
Atributos	No disponible
Referencias	AÑADIR FIRMA (Transact-SQL)
Pasos	En los casos en los que se debe comprobar la integridad de una base de datos crítica protegible, se deben usar firmas digitales. Los elementos protegibles de la base de datos, como un procedimiento almacenado, una función, un ensamblado o un desencadenador se pueden firmar digitalmente. A continuación se muestra un ejemplo de cuándo esto puede ser útil: Supongamos que un ISV (proveedor de software independiente) ha proporcionado soporte técnico a un software entregado a uno de sus clientes. Antes de proporcionar soporte técnico, el ISV querría asegurarse de que una base de datos protegible en el software no se alteró por error o por un intento malintencionado. Si el elemento protegible está firmado digitalmente, el ISV puede comprobar su firma digital y validar su integridad.

Uso de EKM de SQL Server para proteger las claves de cifrado

Título	Detalles
Componente	Base de datos
Fase de SDL	Construir
Tecnologías aplicables	Genérico
Atributos	No disponible
Referencias	Administración extensible de claves (EKM) de SQL Server, administración extensible de claves mediante Azure Key Vault (SQL Server)
Pasos	Administración extensible de claves de SQL Server permite almacenar las claves de cifrado que protegen los archivos de base de datos en un dispositivo listo para usar, como una tarjeta inteligente, un dispositivo USB o un módulo EKM/HSM. Esto también permite la protección de datos de los administradores de bases de datos (excepto los miembros del grupo sysadmin). Los datos se pueden cifrar mediante claves de cifrado a las que solo el usuario de la base de datos tiene acceso en el módulo externo EKM/HSM.

Usar la característica AlwaysEncrypted si no se deben revelar claves de cifrado en el motor de base de datos

Título	Detalles
Componente	Base de datos
Fase de SDL	Construir
Tecnologías aplicables	SQL Azure, OnPrem
Atributos	Versión de SQL: V12, MsSQL2016
Referencias	Always Encrypted (motor de base de datos)
Pasos	Always Encrypted es una característica diseñada para proteger datos confidenciales, como números de tarjeta de crédito o números de identificación nacionales o regionales (por ejemplo, números de seguridad social de EE. UU.), almacenados en bases de datos de Azure SQL Database o SQL Server. Always Encrypted permite a los clientes cifrar datos confidenciales dentro de las aplicaciones cliente y nunca revelar las claves de cifrado al motor de base de datos (SQL Database o SQL Server). Como resultado, Always Encrypted proporciona una separación entre aquellos que poseen los datos (y pueden verlos) y aquellos que administran los datos (pero no deben tener acceso)

Almacenamiento de claves criptográficas de forma segura en el dispositivo IoT

Título	Detalles
Componente	Dispositivo de IoT
Fase de SDL	Construir
Tecnologías aplicables	Genérico
Atributos	Sistema operativo del dispositivo: Windows IoT Core, conectividad de dispositivos: SDK de dispositivo IoT de Azure
Referencias	TPM en Windows IoT Core, Configuración de TPM en Windows IoT Core, TPM del SDK de dispositivo IoT de Azure
Pasos	Claves privadas de certificado o simétricas en un almacenamiento protegido de hardware como chips TPM o de tarjeta inteligente. Windows 10 IoT Core admite el uso de un TPM y hay varios TPM compatibles que se pueden utilizar: TPM discreto (dTPM). Se recomienda usar un firmware o un TPM discreto. Un TPM de software solo debe usarse con fines de desarrollo y pruebas. Una vez que un TPM está disponible y las claves se aprovisionan en él, el código que genera el token debe escribirse sin codificar de forma rígida información confidencial.

Ejemplo

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 se puede ver, la clave principal del dispositivo no está presente en el código. En su lugar, se almacena en el TPM en la ranura 0. El dispositivo TPM genera un token de SAS de corta duración que, a continuación, se usa para conectarse a IoT Hub.

Generación de una clave simétrica aleatoria de longitud suficiente para la autenticación en IoT Hub

Título	Detalles
Componente	Puerta de enlace de la nube de IoT
Fase de SDL	Construir
Tecnologías aplicables	Genérico
Atributos	Elección de puerta de enlace: Azure IoT Hub
Referencias	No disponible
Pasos	IoT Hub contiene un registro de identidad de dispositivo y, al aprovisionar un dispositivo, genera automáticamente una clave simétrica aleatoria. Se recomienda usar esta característica del Registro de identidades de Azure IoT Hub para generar la clave usada para la autenticación. IoT Hub también permite especificar una clave al crear el dispositivo. Si se genera una clave fuera de IoT Hub durante el aprovisionamiento de dispositivos, se recomienda crear una clave simétrica aleatoria o al menos 256 bits.

Asegúrese de que hay una directiva de administración de dispositivos que requiere un PIN de uso y permite el borrado remoto.

Título	Detalles
Componente	Cliente móvil de Dynamics CRM
Fase de SDL	Despliegue
Tecnologías aplicables	Genérico
Atributos	No disponible
Referencias	No disponible
Pasos	Asegúrese de que hay una directiva de administración de dispositivos que requiere un PIN de uso y permite el borrado remoto.

Asegúrese de que hay una directiva de administración de dispositivos que requiere un PIN, una contraseña o un bloqueo automático y cifra todos los datos (por ejemplo, BitLocker).

Título	Detalles
Componente	Cliente de Outlook de Dynamics CRM
Fase de SDL	Construir
Tecnologías aplicables	Genérico
Atributos	No disponible
Referencias	No disponible
Pasos	Asegúrese de que hay una directiva de administración de dispositivos que requiere un PIN, una contraseña o un bloqueo automático y cifra todos los datos (por ejemplo, BitLocker).

Asegúrese de que las claves de firma se sustituyen cuando se usa Identity Server

Título	Detalles
Componente	Servidor de Identidad
Fase de SDL	Despliegue
Tecnologías aplicables	Genérico
Atributos	No disponible
Referencias	No disponible
Pasos	Asegúrese de las claves de firma se sustituyen cuando se usa Identity Server. En el vínculo de la sección de referencias se explica cómo se debe planear sin provocar interrupciones en las aplicaciones que dependen de Identity Server.

Asegúrese de que se usan identificadores de cliente y secretos de cliente de alta seguridad criptográfica en Identity Server

Título	Detalles
Componente	Servidor de Identidad
Fase de SDL	Construir
Tecnologías aplicables	Genérico
Atributos	No disponible
Referencias	No disponible
Pasos	Asegúrese de que se utilicen un identificador de cliente y un secreto de cliente seguros criptográficamente en Identity Server. Se deben usar las instrucciones siguientes al generar un identificador de cliente y un secreto: Generación de un GUID aleatorio como identificador de cliente Generar una clave criptográficamente aleatoria de 256 bits como secreto.