Meilleures pratiques pour les API de sécurité

Pour aider à développer des logiciels sécurisés, nous recommandons d’utiliser les bonnes pratiques suivantes lors du développement d’applications. Pour plus d’informations, consultez la rubrique Cycle de vie du développement de la sécurité Microsoft.

Cycle de vie du développement de la sécurité

Le Cycle de vie du développement de la sécurité (SDL) est un processus qui aligne une série d’activités et de livrables axés sur la sécurité à chaque phase du développement logiciel. Ces activités et livrables incluent :

• Développer des modèles de menace
• Utiliser des outils d’analyse de code
• Effectuer des revues de code et des tests de sécurité

Pour plus d’informations sur SDL, consultez la Microsoft Security Development Lifecycle.

Modèles de menace

Effectuer une analyse des modèles de menace peut vous aider à découvrir des points potentiels d’attaque dans votre code. Pour plus d’informations sur l’analyse du modèle de menace, consultez Howard, Michael et LeBlanc, David [2003], Writing Secure Code, 2d ed., ISBN 0-7356-1722-8, Microsoft Press, Redmond, Washington. (Il est possible que cette ressource ne soit pas disponible dans certaines langues et dans certains pays).

Packs de service et mises à jour de sécurité

Les environnements de build et de test doivent refléter les mêmes niveaux de packs de service et de mises à jour de sécurité que la base d’utilisateurs ciblée. Nous vous recommandons d’installer les derniers Service Packs et mises à jour de sécurité pour toute plateforme ou application Microsoft qui fait partie de votre environnement de génération et de test et encourage vos utilisateurs à effectuer les mêmes opérations pour l’environnement d’application terminé. Pour plus d’informations sur les Service Packs et les mises à jour de sécurité, consultez Update Windows et Sécurité Microsoft.

Autorisation

Vous devez créer des applications nécessitant le moins de privilèges possible. Utiliser le moins de privilèges possible réduit le risque de compromission de votre système informatique par du code malveillant. Pour plus d’informations sur l’exécution de code avec le niveau de privilège le plus bas possible, veuillez consulter la section Exécution avec des privilèges spéciaux.

Meilleures pratiques de chiffrement

Lors de l’implémentation du chiffrement dans les applications Windows :

• Utilisez l’API de chiffrement : CNG (Next Generation) pour tout nouveau développement. CryptoAPI n’est maintenu que pour la rétrocompatibilité.
• Concevez pour l’agilité cryptographique et préparez-vous à l’ère post-quantique. N’éparpillez pas d’identifiants d’algorithme codés en dur ou de tailles de clés dans l’ensemble de votre code — isolez-les afin que les algorithmes puissent être remplacés sans devoir tout réécrire. La plateforme passe aux normes post-quantiques NIST, ML-KEM (FIPS 203) pour l’établissement de clés et les ML-DSA (FIPS 204) pour les signatures, donc privilégiez les conceptions agiles maintenant, en particulier pour les données avec une longue durée de vie de confidentialité, pour résister aux attaques « harvest-now, decrypt-later ».
• Préférer le chiffrement authentifié (AEAD). Utilisez AES-GCM afin que le chiffrement détecte également la falsification. Si vous devez utiliser un mode non authentifié tel que CBC, associez-le à un contrôle d’intégrité distinct (encrypt-then-MAC) : la confidentialité seule ne protège pas contre la modification.
• Ne réutilisez jamais un nonce (IV) avec la même clé dans AES-GCM. La réutilisation d'un nonce dans GCM est catastrophique : elle peut exposer la clé d'authentification et permettre la falsification de messages. Générez un nonce unique pour chaque opération de chiffrement, par exemple un compteur incrémentiel ou une nouvelle valeur aléatoire de 96 bits.
• N’utilisez jamais le mode de chiffrement de bloc BCE. ECB chiffre les blocs indépendamment, ce qui révèle des modèles dans les données en texte clair.
• Ne codez jamais en dur les clés de chiffrement dans le code source. Utilisez DPAPI pour la protection des clés locales ou le fournisseur de stockage de clés CNG pour les clés persistantes.
• Supprimez les secrets de la mémoire une fois que vous n’en avez plus besoin. Remplacez le contenu des clés, mots de passe et autres mémoires tampons sensibles par des zéros à l'aide de SecureZeroMemory. Contrairement à memset, il n’est pas éliminé par le compilateur.
• Utilisez des longueurs de clé de 256 bits pour AES, 2048 bits + pour RSA (3072+ préférés) et 256 bits pour ECDSA.
• Utilisez SHA-256 ou plus fort pour le hachage. N’utilisez pas MD5 ou SHA-1 à des fins de sécurité.
• Vérifiez toujours les valeurs de retour des fonctions de chiffrement. Une opération de chiffrement qui échoue silencieusement peut laisser des données stockées en texte clair.
• Générez des nombres aléatoires à l’aide de BCryptGenRandom (CNG) ( non rand() ou d’autres PRNG non chiffrés). Passez BCRYPT_USE_SYSTEM_PREFERRED_RNG pour utiliser le générateur préféré du système sans avoir à gérer un descripteur d’algorithme.

Informations supplémentaires

Pour plus d’informations sur les bonnes pratiques, veuillez consulter les rubriques suivantes.

Sujet	Description
Exécution avec des privilèges spéciaux	Traite les implications de sécurité des privilèges.
Éviter les dépassements de tampon (buffer)	Fournit des informations sur la manière d’éviter les dépassements de tampon.
Control Flow Guard (CFG)	Traite les vulnérabilités de corruption de mémoire.
Création d'une DACL	Montre comment créer une liste de contrôle d’accès discrétionnaire (DACL) en utilisant le Security Descriptor Definition Language (SDDL).
Gestion des mots de passe	Traite les implications de sécurité de l’utilisation des mots de passe.
extensibilité pour développeurs Dynamic Access Control	Orientation de base sur certains des points d’extensibilité pour les développeurs des nouvelles solutions de contrôle d’accès dynamique.