Procedimientos recomendados para las API de seguridad

Para poder desarrollar software seguro, se aconseja aplicar los procedimientos recomendados siguientes al desarrollar aplicaciones. Obtenga más información en Ciclo de vida del desarrollo de seguridad de Microsoft.

Ciclo de vida de desarrollo de seguridad

El Ciclo de Vida del Desarrollo de la Seguridad (SDL) es un proceso que integra una serie de actividades centradas en la seguridad y entregables a cada fase del desarrollo de software. Entre estas actividades y recursos, se incluyen:

• Desarrollo de modelos de amenazas
• Uso de herramientas de análisis de código
• Aplicación de revisiones de código y pruebas de seguridad

Para obtener más información sobre el SDL, consulte el Ciclo de vida de desarrollo de seguridad de Microsoft.

Modelos de amenazas

Realizar un análisis del modelo de amenazas puede ayudarle a detectar posibles zonas de ataque en el código. Para obtener más información sobre el análisis de modelos de amenazas, vea Howard, Michael y LeBlanc, David [2003], Writing Secure Code, 2d ed., ISBN 0-7356-1722-8, Microsoft Press, Redmond, Washington. (Es posible que este recurso no esté disponible en algunos idiomas y países).

Paquetes de servicio y actualizaciones de seguridad

Los entornos de compilación y prueba deben reflejar los mismos niveles de Service Packs y actualizaciones de seguridad de la base de usuarios correspondiente. Se recomienda instalar los service packs y las actualizaciones de seguridad más recientes para cualquier plataforma o aplicación de Microsoft que forme parte de su entorno de compilación y prueba y anime a los usuarios a hacer lo mismo para el entorno de aplicación terminado. Para obtener más información sobre service packs y actualizaciones de seguridad, consulte Update Windows y Seguridad de Microsoft.

Autorización

Debe crear aplicaciones que requieran los menos privilegios posibles. El uso de los privilegios mínimos posibles reduce el riesgo de que el código malintencionado ponga en peligro el sistema informático. Para obtener más información sobre cómo ejecutar código con el menor nivel de privilegios posible, consulte Ejecución con privilegios especiales.

Procedimientos recomendados criptográficos

Al implementar criptografía en aplicaciones de Windows:

• Use Cryptography API: Next Generation (CNG) para cualquier desarrollo nuevo. CryptoAPI solo se mantiene por compatibilidad con versiones anteriores.
• Diseñe con agilidad criptográfica y planifique para un futuro poscuántico. No disperse identificadores de algoritmo codificados de forma rígida ni tamaños de clave en todo el código, aíslelos para que los algoritmos se puedan intercambiar sin reescritura. La plataforma está adoptando los estándares poscuánticos del NIST, ML-KEM (FIPS 203) para el establecimiento de claves y ML-DSA (FIPS 204) para las firmas, por lo que conviene optar ya por diseños ágiles, especialmente para los datos que deban mantenerse confidenciales durante mucho tiempo, a fin de resistir ataques de «recoger ahora y descifrar después».
• Prefiere el cifrado autenticado (AEAD). Use AES-GCM para que el cifrado también detecte alteraciones. Si debe usar un modo no autenticado, como CBC, adéptelo con una comprobación de integridad independiente (encrypt-then-MAC), la confidencialidad por sí sola no protege contra la modificación.
• Nunca vuelva a usar un nonce (IV) con la misma clave en AES-GCM. La reutilización de nonce en GCM es grave: puede exponer la clave de autenticación y habilitar la falsificación de mensajes. Genera un nonce único para cada operación de cifrado — por ejemplo, un contador incremental o un nuevo valor aleatorio de 96 bits.
• Nunca use el modo de cifrado de bloques ECB. ECB cifra los bloques de forma independiente, lo que revela patrones en los datos en texto plano.
• Nunca codifique de forma rígida las claves criptográficas en el código fuente. Use DPAPI para la protección de claves local o el proveedor de almacenamiento de claves CNG para las claves persistentes.
• Borre los secretos de la memoria cuando haya terminado con ellos. Sobrescriba el material de claves, las contraseñas y otros búferes sensibles con SecureZeroMemory. A diferencia de memset, el compilador no lo optimiza.
• Utilice longitudes de clave de 256 bits para AES, 2048 bits o más para RSA (se prefieren 3072 bits o más) y 256 bits o más para ECDSA.
• Use SHA-256 o más seguro para el hash. No use MD5 o SHA-1 para fines de seguridad.
• Compruebe siempre los valores devueltos de las funciones criptográficas. Una llamada de cifrado que falla silenciosamente puede dejar los datos almacenados en texto plano.
• Genere números aleatorios mediante BCryptGenRandom (CNG), no rand() u otros PRNG no criptográficos. Pase BCRYPT_USE_SYSTEM_PREFERRED_RNG para usar el generador preferido por el sistema sin administrar un identificador de algoritmo.

Más información

Para obtener más información sobre los procedimientos recomendados, consulte los temas siguientes.

Tema	Descripción
Ejecución con privilegios especiales	Aborda las cuestiones sobre seguridad de los privilegios.
Evitar saturaciones del búfer	Da información sobre cómo evitar saturaciones de búfer.
Protección de flujo de control (CFG)	Discute las vulnerabilidades de corrupción de la memoria.
Creación de un DACL	Indica cómo crear una lista de control de acceso discrecional (DACL) mediante el Lenguaje de definición de descriptores de seguridad (SDDL).
Control y gestión de contraseñas	Aborda las cuestiones sobre seguridad al usar contraseñas.
Extensibilidad del desarrollador para el Control de Acceso Dinámico	Orientación básica a algunos de los puntos de extensibilidad para desarrolladores en las nuevas soluciones dinámicas de Control de Acceso.