Infrastructure de sécurité : Chiffrement | Atténuation
Intitulé | Détails |
---|---|
Composant | Application Web |
Phase SDL | Build |
Technologies applicables | Générique |
Attributs | N/A |
Informations de référence | N/A |
Étapes | Les produits doivent uniquement utiliser les chiffrements par bloc symétriques et les longueurs de clé associées qui ont été explicitement approuvés par le conseiller en matière de chiffrement de votre organisation. Les algorithmes symétriques approuvés par Microsoft incluent les chiffrements par bloc suivants :
Notez que tous les chiffrements par bloc symétriques doivent être utilisés avec un mode de chiffrement approuvé, ce qui nécessite l’utilisation d’un vecteur d’initialisation approprié. Un vecteur d’initialisation approprié est généralement un nombre aléatoire et jamais une valeur constante. L’utilisation d’algorithmes de chiffrement hérités ou d’autres algorithmes de chiffrement non approuvés et de longueurs de clé plus petites pour la lecture des données existantes (par opposition à l’écriture de nouvelles données) peut être autorisée après examen du comité responsable du chiffrement de votre organisation. Toutefois, vous devez demander une exception à cette exigence. En outre, dans les déploiements d’entreprise, les produits doivent envisager d’avertir les administrateurs lorsqu’un chiffrement faible est utilisé pour lire des données. Ces avertissements doivent être explicatifs et exploitables. Dans certains cas, il peut être approprié d’avoir une stratégie de groupe pour contrôler l’utilisation d’un chiffrement faible. Algorithmes .NET autorisés pour l’agilité de chiffrement géré (par ordre de préférence)
Notez qu’aucun de ces algorithmes ne peut être spécifié via les méthodes |
Utiliser les modes de chiffrement par bloc et les vecteurs d’initialisation pour les chiffrements symétriques approuvés
Intitulé | Détails |
---|---|
Composant | Application Web |
Phase SDL | Build |
Technologies applicables | Générique |
Attributs | N/A |
Informations de référence | N/A |
Étapes | Tous les chiffrements par bloc symétriques doivent être utilisés avec un mode de chiffrement symétrique approuvé. Les seuls modes approuvés sont CBC et CTS. En particulier, le mode ECB d’opération doit être évité ; l’utilisation d’ECB requiert l’examen du comité responsable du chiffrement de votre organisation. Toute utilisation d’OFB, de CFB, de CTR, de CCM et de GCM ou de tout autre mode de chiffrement doit être examiné par le comité responsable du chiffrement de votre organisation. Réutiliser le même vecteur d’initialisation avec les chiffrements par bloc dans les « modes de chiffrements de flux », tels que CTR, peut entraîner la divulgation des données chiffrées. Tous les chiffrements par bloc symétriques doivent également être utilisés avec un vecteur d’initialisation approprié. Un vecteur d’initialisation approprié est généralement un nombre aléatoire fort et jamais une valeur constante. |
Intitulé | Détails |
---|---|
Composant | Application Web |
Phase SDL | Build |
Technologies applicables | Générique |
Attributs | N/A |
Informations de référence | N/A |
Étapes | L’utilisation des algorithmes de chiffrement interdits introduit un risque significatif pour la sécurité des produits et doit être évitée. Les produits doivent utiliser uniquement ces algorithmes de chiffrement ainsi que les longueurs de clé et le remplissage associés qui ont été approuvés explicitement par le comité responsable du chiffrement de votre organisation.
|
Intitulé | Détails |
---|---|
Composant | Application Web |
Phase SDL | Build |
Technologies applicables | Générique |
Attributs | N/A |
Informations de référence | N/A |
Étapes | Les produits doivent utiliser les générateurs de nombres aléatoires approuvés. Les fonctions pseudoaléatoires telles que C runtime function rand, .NET Framework class System.Random ou les fonctions système comme GetTickCount doivent par conséquent ne jamais être utilisé dans du code de ce type. L’utilisation de l’algorithme du générateur de nombres aléatoires à courbe elliptique double (DUAL_EC_DRBG) est interdite.
|
Intitulé | Détails |
---|---|
Composant | Application Web |
Phase SDL | Build |
Technologies applicables | Générique |
Attributs | N/A |
Informations de référence | N/A |
Étapes | Les chiffrements de flux symétriques, tels que RC4, ne doivent pas être utilisés. Au lieu des chiffrements de flux symétriques, les produits doivent utiliser un chiffrement par bloc, en particulier AES avec une longueur de clé d’au moins 128 bits. |
Intitulé | Détails |
---|---|
Composant | Application Web |
Phase SDL | Build |
Technologies applicables | Générique |
Attributs | N/A |
Informations de référence | N/A |
Étapes | Les produits doivent utiliser uniquement le code d’authentification de message (MAC) approuvé ou des algorithmes de code d’authentification de message basé sur le hachage (HMAC). Un code d’authentification de message (MAC) est un élément d’information associé à un message qui permet à son destinataire de vérifier à la fois l’authenticité de l’expéditeur et l’intégrité du message à l’aide d’une clé secrète. L’utilisation d’un MAC basé sur le hachage (HMAC) ou d’un MAC basé sur le chiffrement par bloc est autorisée tant que tous les algorithmes de chiffrement symétrique ou de hachage sous-jacents sont également approuvés pour une utilisation ; actuellement, cela inclut les fonctions HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 et HMAC-SHA512) et les MAC basés sur le chiffrement par bloc CMAC/OMAC1 et OMAC2 (ces derniers sont basés sur AES). L’utilisation de HMAC-SHA1 peut être autorisée pour la compatibilité de la plateforme, mais vous devrez demander une exception pour cette procédure et la soumettre à un examen du comité responsable du chiffrement de votre organisation. La troncation des HMAC à moins de 128 bits n’est pas autorisée. L’utilisation des méthodes du client pour hacher une clé et des données n’est pas approuvée et doit être soumise à un examen du comité responsable du chiffrement de votre organisation avant toute mise en œuvre. |
Intitulé | Détails |
---|---|
Composant | Application Web |
Phase SDL | Build |
Technologies applicables | Générique |
Attributs | N/A |
Informations de référence | N/A |
Étapes | Les produits doivent utiliser la famille d’algorithmes de hachage SHA-2 (SHA256, SHA384 et SHA512). Si un hachage plus court est nécessaire, par exemple une longueur de sortie de 128 bits pour s’adapter à une structure de données conçue avec le hachage MD5 plus court à l’esprit, les équipes produit peuvent tronquer l’un des hachages SHA2 (généralement SHA256). Notez que SHA384 est une version tronquée de SHA512. La troncation des hachages de chiffrement pour des raisons de sécurité à moins de 128 bits n’est pas autorisée. Le nouveau code ne doit pas utiliser les algorithmes de hachage MD2, MD4, MD5, SHA-0, SHA-1 ou RIPEMD. Les conflits de hachage sont possibles en termes de calculs pour ces algorithmes, qui les brisent efficacement. Algorithmes de hachage .NET autorisés pour l’agilité de chiffrement géré (par ordre de préférence) :
|
Intitulé | Détails |
---|---|
Composant | Base de données |
Phase SDL | Build |
Technologies applicables | Générique |
Attributs | N/A |
Informations de référence | Choisir un algorithme de chiffrement |
Étapes | Les algorithmes de chiffrement définissent les transformations de données qui ne peuvent pas être facilement inversées par les utilisateurs non autorisés. SQL Server permet aux administrateurs et aux développeurs de choisir parmi plusieurs algorithmes, notamment DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, RC4 128 bits, DESX, AES 128 bits, AES 192 bits et AES 256 bits. |
Intitulé | Détails |
---|---|
Composant | Base de données |
Phase SDL | Build |
Technologies applicables | Générique |
Attributs | N/A |
Informations de référence | Identifier la source de packages à l’aide de signatures numériques, Limitation des menaces et des risques de vulnérabilité (Integration Services) |
Étapes | La source d'un package correspond à l'individu ou à l'organisation qui a créé le package. L'exécution d'un package à partir d'une source inconnue ou non approuvée peut être risquée. Pour empêcher la falsification non autorisée des packages SSIS, les signatures numériques doivent être utilisées. En outre, pour garantir la confidentialité des packages lors du stockage/transit, les packages SSIS doivent être chiffrés. |
Intitulé | Détails |
---|---|
Composant | Base de données |
Phase SDL | Build |
Technologies applicables | Générique |
Attributs | N/A |
Informations de référence | ADD SIGNATURE (Transact-SQL) |
Étapes | Dans les cas où l’intégrité d’un élément sécurisable de base de données critique doit être vérifiée, les signatures numériques doivent être utilisées. Les éléments sécurisables de base de données tels qu’une procédure stockée, une fonction, un assembly ou un déclencheur sont signés numériquement. Vous trouverez ci-dessous un exemple pour lequel cela peut être utile : supposons qu’un éditeur de logiciels indépendant a fourni la prise en charge pour un logiciel fourni à l’un de ses clients. Avant de fournir la prise en charge, l’éditeur de logiciels indépendant souhaitera garantir qu’un élément sécurisable de base de données inclus dans le logiciel n’a pas été falsifié par inadvertance ou par une tentative malveillante. Si l’élément sécurisable est signé numériquement, l’éditeur de logiciels indépendant peut vérifier sa signature numérique et valider son intégrité. |
Intitulé | Détails |
---|---|
Composant | Base de données |
Phase SDL | Build |
Technologies applicables | Générique |
Attributs | N/A |
Informations de référence | Gestion de clés extensible (EKM), Gestion de clés extensible à l’aide d’Azure Key Vault (SQL Server) |
Étapes | La gestion de clés extensible SQL Server active les clés de chiffrement qui protègent les fichiers de base de données à stocker dans un appareil distant comme une carte à puce, un périphérique USB ou un module EKM/HSM. Elle permet aussi la protection des données pour les administrateurs de base de données (sauf les membres du groupe sysadmin). Les données peuvent être chiffrées à l'aide des clés de chiffrement auxquelles seul l'utilisateur de base de données peut accéder sur le module EKM/HSM externe. |
Utiliser la fonction AlwaysEncrypted si les clés de chiffrement ne doivent pas être révélées au moteur de base de données
Intitulé | Détails |
---|---|
Composant | Base de données |
Phase SDL | Build |
Technologies applicables | SQL Azure, OnPrem |
Attributs | Version SQL - V12, MsSQL2016 |
Informations de référence | Always Encrypted (moteur de base de données) |
Étapes | Always Encrypted est une fonctionnalité conçue pour protéger les données sensibles, telles que les numéros de carte de crédit ou les numéros d’identification nationaux/régionaux (par exemple, les numéros de sécurité sociale américains), stockées dans Azure SQL Database ou les bases de données SQL Server. Always Encrypted permet aux clients de chiffrer les données sensibles des applications clientes et de ne jamais divulguer les clés de chiffrement au moteur de base de données (SQL Database ou SQL Server). Always Encrypted sépare ainsi les utilisateurs qui sont propriétaires des données (et peuvent les afficher) des utilisateurs qui gèrent les données (mais n’y ont pas accès). |
Intitulé | Détails |
---|---|
Composant | Appareil IoT |
Phase SDL | Build |
Technologies applicables | Générique |
Attributs | Système d’exploitation d’appareil - Windows IoT Standard, connectivité des appareils - Azure IoT device SDK |
Informations de référence | TPM on Windows IoT Core (Module de plateforme sécurisée sur Windows IoT Standard), TPM on Windows IoT Core (Module de plateforme sécurisée sur Windows IoT Standard), Azure IoT Device SDK TPM (Module de plateforme sécurisée Azure IoT Device SDK) |
Étapes | Clés privées de certificat ou symétriques dans un stockage matériel protégé tel qu’un module de plateforme sécurisée ou des cartes à puce. Windows 10 IoT Standard prend en charge l’utilisateur d’un TPM, dont plusieurs types compatibles peuvent être utilisés : TPM discret (dTPM). Il est recommandé d’utiliser un module de plateforme sécurisée de type discret ou micrologiciel. Un module de plateforme sécurisée de type logiciel doit uniquement être utilisé à des fins de développement et de test. Une fois qu’un module de plateforme sécurisée est disponible et que les clés sont approvisionnées dans celui-ci, le code qui génère le jeton doit être écrit sans coder en dur les informations sensibles qu’il contient. |
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);
Comme vous pouvez le constater, la clé primaire de l’appareil n’est pas présente dans le code. Au lieu de cela, elle est stockée dans le module de plateforme sécurisée à l’emplacement 0. L’appareil de module de plateforme sécurisée génère un jeton SAP temporaire qui est ensuite utilisé pour se connecter à IoT Hub.
Intitulé | Détails |
---|---|
Composant | Passerelle cloud IoT |
Phase SDL | Build |
Technologies applicables | Générique |
Attributs | Choix de passerelle - Azure IoT Hub |
Informations de référence | N/A |
Étapes | IoT Hub contient un registre des identités de l’appareil et, lors de l’approvisionnement d’un appareil, il génère automatiquement une clé symétrique aléatoire. Il est recommandé d’utiliser cette fonctionnalité du registre des identités Azure IoT Hub pour générer la clé utilisée pour l’authentification. IoT Hub permet également de spécifier une clé lors de la création de l’appareil. Si une clé est générée en dehors d’IoT Hub pendant l’approvisionnement de l’appareil, il est recommandé de créer une clé symétrique aléatoire ou d’au moins 256 bits. |
Garantissez qu’une stratégie de gestion des appareils, demandant un code confidentiel utilisateur et permettant la réinitialisation à distance, est en place.
Intitulé | Détails |
---|---|
Composant | Client mobile Dynamics CRM |
Phase SDL | Déploiement |
Technologies applicables | Générique |
Attributs | N/A |
Informations de référence | N/A |
Étapes | Garantissez qu’une stratégie de gestion des appareils, demandant un code confidentiel utilisateur et permettant la réinitialisation à distance, est en place. |
Garantir qu’une stratégie de gestion des appareils, demandant un code confidentiel/mot de passe/verrouillage auto et chiffrant toutes les données (p. ex. BitLocker), est en place
Intitulé | Détails |
---|---|
Composant | Client Outlook Dynamics CRM |
Phase SDL | Build |
Technologies applicables | Générique |
Attributs | N/A |
Informations de référence | N/A |
Étapes | Garantir qu’une stratégie de gestion des appareils, demandant un code confidentiel/mot de passe/verrouillage auto et chiffrant toutes les données (p. ex. BitLocker), est en place |
Intitulé | Détails |
---|---|
Composant | IdentityServer |
Phase SDL | Déploiement |
Technologies applicables | Générique |
Attributs | N/A |
Informations de référence | IdentityServer - Clés, signatures et chiffrement |
Étapes | Garantissez que les clés de signature sont annulées lors de l’utilisation d’IdentityServer. Le lien dans la section Références explique comment cela doit être planifié sans entraîner de pannes pour les applications reposant sur IdentityServer. |
Garantir qu’un ID de client et une clé secrète client forts en termes de chiffrement sont utilisés dans IdentityServer
Intitulé | Détails |
---|---|
Composant | IdentityServer |
Phase SDL | Build |
Technologies applicables | Générique |
Attributs | N/A |
Informations de référence | N/A |
Étapes | Garantir qu’un ID de client et une clé secrète client forts en termes de chiffrement sont utilisés dans IdentityServer. Les instructions ci-après doivent être suivies lors de la génération d’un ID de client et d’une clé secrète :
|