S’assurer que les fichiers binaires sont masqués s’ils contiennent des informations sensibles
Intitulé
Détails
Composant
Délimitation d’approbation machine
Phase SDL
Déploiement
Technologies applicables
Générique
Attributs
N/A
Informations de référence
N/A
Étapes
Assurez-vous que les fichiers binaires sont masqués s’ils contiennent des informations sensibles, comme des secrets industriels ou une logique métier sensible et irréversible. Cela permet d’arrêter l’ingénierie à rebours des assemblys. Les outils du type CryptoObfuscator peuvent être utilisés à cet effet.
Utiliser le système de fichiers EFS pour protéger les données confidentielles spécifiques de l’utilisateur
Intitulé
Détails
Composant
Délimitation d’approbation machine
Phase SDL
Build
Technologies applicables
Générique
Attributs
N/A
Informations de référence
N/A
Étapes
Utilisez le système de fichiers EFS pour protéger les données confidentielles spécifiques de l’utilisateur des pirates disposant d’un accès physique à l’ordinateur.
S’assurer que les données sensibles stockées par l’application sur le système de fichiers sont chiffrées
Intitulé
Détails
Composant
Délimitation d’approbation machine
Phase SDL
Déploiement
Technologies applicables
Générique
Attributs
N/A
Informations de référence
N/A
Étapes
Assurez-vous que les données sensibles stockées par l’application sur le système de fichiers sont chiffrées (par exemple, en vous servant de DPAPI), si le système EFS ne peut pas être appliqué
S’assurer que le contenu sensible n’est pas mis en cache dans le navigateur
Intitulé
Détails
Composant
Application Web
Phase SDL
Build
Technologies applicables
Générique, Web Forms, MVC5, MVC6
Attributs
N/A
Informations de référence
N/A
Étapes
Les navigateurs peuvent stocker des informations à des fins de mise en cache et d’historique. Ces fichiers mis en cache sont stockés dans un dossier, comme le dossier Fichiers Internet temporaires d’Internet Explorer. Lorsque ces pages sont de nouveau consultées, le navigateur les affiche à partir du cache. Si l’utilisateur peut voir des informations sensibles (par exemple, adresse, numéro de carte de crédit, numéro de sécurité sociale ou nom d’utilisateur), ces informations sont peut-être stockées dans le cache du navigateur et peuvent par conséquent être récupérées en examinant le cache du navigateur ou en appuyant simplement sur le bouton Précédent du navigateur. Définissez la valeur d’en-tête de réponse cache-control sur « no-store » pour toutes les pages.
Il est possible d’utiliser un filtre. L’exemple suivant illustre ce cas de figure :
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
if (filterContext == null || (filterContext.HttpContext != null && filterContext.HttpContext.Response != null && filterContext.HttpContext.Response.IsRequestBeingRedirected))
{
//// Since this is MVC pipeline, this should never be null.
return;
}
var attributes = filterContext.ActionDescriptor.GetCustomAttributes(typeof(System.Web.Mvc.OutputCacheAttribute), false);
if (attributes == null || **Attributes**.Count() == 0)
{
filterContext.HttpContext.Response.Cache.SetNoStore();
filterContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);
filterContext.HttpContext.Response.Cache.SetExpires(DateTime.UtcNow.AddHours(-1));
if (!filterContext.IsChildAction)
{
filterContext.HttpContext.Response.AppendHeader("Pragma", "no-cache");
}
}
base.OnActionExecuting(filterContext);
}
Chiffrer les sections des fichiers de configuration de l’application web qui contiennent des données sensibles
Les fichiers de configuration tels que web.config et appsettings.json sont souvent utilisés pour stocker des informations sensibles, comme les noms d’utilisateur, les mots de passe, les chaînes de connexion de base de données et les clés de chiffrement. Si vous ne protégez pas ces informations, votre application est vulnérable aux attaquants ou aux personnes malveillantes qui veulent obtenir des informations sensibles, comme les noms d’utilisateur et les mots de passe de comptes, les noms de bases de données et les noms de serveurs. Selon le type de déploiement (azure/local), chiffrez les sections sensibles des fichiers de configuration à l’aide de DPAPI ou de services tels qu’Azure Key Vault.
Désactiver explicitement l’attribut HTML de saisie semi-automatique dans les formulaires et les entrées sensibles
L’attribut autocomplete spécifie si la saisie semi-automatique doit être activée ou non sur un formulaire. Lorsque la saisie semi-automatique est activée, le navigateur complète automatiquement les valeurs en fonction des valeurs que l’utilisateur a déjà entrées. Par exemple, lorsqu’un nouveau nom et un nouveau mot de passe sont entrés dans un formulaire et que le formulaire est envoyé, le navigateur vous demande si le mot de passe doit être enregistré. Par la suite, lorsque le formulaire est affiché, le nom et le mot de passe sont automatiquement renseignés ou ils sont complétés au moment de la saisie du nom. Une personne malveillante disposant d’un accès local peut obtenir le mot de passe en texte clair à partir du cache du navigateur. La saisie semi-automatique est activée par défaut et elle doit être explicitement désactivée.
S’assurer que les données sensibles affichées sur l’écran de l’utilisateur sont masquées
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 données sensibles telles que les mots de passe, les numéros de carte de crédit, les numéros de sécurité sociale, etc. doivent être masquées à l’écran. Cela empêche les personnes non autorisées d’accéder aux données (par exemple, en épiant les mots de passe saisis, ou lorsque le support technique affiche le numéro de sécurité sociale de l’utilisateur). Assurez-vous que ces éléments de données ne sont pas visibles en texte brut et qu’ils sont masqués de manière appropriée. Cela doit être pris en compte quand vous les acceptez comme entrée (par ex.,. input type="password"), et quand vous les affichez de nouveau sur l’écran (par ex., affichez uniquement les 4 derniers chiffres du numéro de carte de crédit).
Implémenter le masquage des données dynamiques pour limiter l’exposition de données sensibles aux utilisateurs non privilégiés
Le masquage dynamique des données vise à limiter l’exposition de données sensibles, en empêchant des utilisateurs ne devant pas avoir accès à celles-ci de les consulter. En revanche, le masquage dynamique des données n’a pas pour but d’empêcher des utilisateurs d’une base de données de se connecter directement à celle-ci ou d’exécuter des requêtes exhaustives ayant pour effet d’exposer des éléments de données sensibles. Le masquage des données dynamiques est complémentaire d’autres fonctionnalités de sécurité SQL Server (audit, chiffrement, sécurité au niveau des lignes, etc.) et il est fortement recommandé d’utiliser cette fonctionnalité en conjonction avec ces dernières afin d’optimiser la protection des données sensibles de la base de données. Cette fonctionnalité est prise en charge uniquement par SQL Server à partir de la version 2016 et par Azure SQL Database.
S’assurer que les mots de passe sont stockés dans un format de hachage salé
Les mots de passe ne doivent pas être stockés dans les bases de données de magasin d’utilisateurs personnalisés. Au lieu de cela, les hachages de mot de passe doivent être stockés avec des valeurs salt. Assurez-vous que la valeur salt de l’utilisateur est toujours unique et que vous appliquez b-crypt, s-crypt ou PBKDF2 avant de stocker le mot de passe, avec un nombre d’itérations de facteur de travail minimal de 150 000 boucles afin d’éliminer tout risque d’attaque par force brute.
S’assurer que les données sensibles des colonnes de la base de données sont chiffrées
Les données sensibles, comme les numéros de carte de crédit, doivent être chiffrées dans la base de données. Les données peuvent être chiffrées par le biais du chiffrement au niveau colonne ou par une fonction de l’application utilisant les fonctions de chiffrement.
S’assurer que le chiffrement au niveau de la base de données est activé
La fonction Transparent Data Encryption (TDE) de SQL Server permet de chiffrer les données sensibles dans une base de données et de protéger les clés utilisées pour chiffrer les données avec un certificat. Cela empêche toute personne ne disposant pas des clés d’utiliser les données. Le chiffrement transparent des données protège les données « au repos », autrement dit les fichiers de données et les fichiers journaux. Il permet de se conformer à de nombreuses lois, règles et instructions établies dans différents secteurs professionnels.
S’assurer que les sauvegardes de base de données sont chiffrées
SQL Server peut chiffrer les données lors de la création d’une sauvegarde. En spécifiant l’algorithme de chiffrement et le chiffreur (certificat ou clé asymétrique) lors de la création d’une sauvegarde, il est possible de créer un fichier de sauvegarde chiffré.
S’assurer que les données sensibles concernant l’API Web ne sont pas stockées dans le navigateur
Intitulé
Détails
Composant
API Web
Phase SDL
Build
Technologies applicables
MVC 5, MVC 6
Attributs
Fournisseur d’identité - ADFS, Fournisseur d’identité - Microsoft Entra ID
Informations de référence
N/A
Étapes
Dans certaines implémentations, des artefacts sensibles concernant l’authentification de l’API Web sont stockés en local dans le navigateur. C’est notamment le cas des artefacts d’authentification Microsoft Entra comme adal.idtoken, adal.nonce.idtoken, adal.access.token.key, adal.token.keys, adal.state.login, adal.session.state, adal.expiration.key, etc.
Tous ces artefacts sont disponibles même après la déconnexion ou la fermeture du navigateur. Si un pirate obtient l’accès à ces artefacts, il peut le réutiliser pour accéder aux ressources protégées (API). Assurez-vous que tous les artefacts sensibles concernant l’API Web ne sont pas stockés dans le navigateur. Si le stockage côté client est inévitable (par exemple, les applications à page unique qui tirent parti des flux implicites OpenIdConnect/OAuth doivent stocker les jetons d’accès au niveau local), utilisez des options de stockage sans persistance. Par exemple, préférez SessionStorage à LocalStorage.
Exemple
L’extrait de code JavaScript ci-dessous provient d’une bibliothèque d’authentification personnalisée qui stocke les artefacts d’authentification en local. Ce type d’implémentation doit être évité.
ns.AuthHelper.Authenticate = function () {
window.config = {
instance: 'https://login.microsoftonline.com/',
tenant: ns.Configurations.Tenant,
clientId: ns.Configurations.AADApplicationClientID,
postLogoutRedirectUri: window.location.origin,
cacheLocation: 'localStorage', // enable this for Internet Explorer, as sessionStorage does not work for localhost.
};
Chiffrer les données sensibles stockées dans Azure Cosmos DB
Intitulé
Détails
Composant
Azure Document DB
Phase SDL
Build
Technologies applicables
Générique
Attributs
N/A
Informations de référence
N/A
Étapes
Chiffrez les données sensibles au niveau de l’application avant de les stocker dans la base de données de document ou de stocker toute donnée sensible dans d’autres solutions de stockage, comme le stockage Azure ou Azure SQL
Utiliser Azure Disk Encryption pour chiffrer les disques utilisés par les machines virtuelles
Intitulé
Détails
Composant
Délimitation d’approbation de machine virtuelle Azure IaaS
Azure Disk Encryption est une nouvelle fonctionnalité qui est actuellement disponible en version préliminaire. Cette fonctionnalité vous permet de chiffrer les disques de données et de système d’exploitation utilisés par une machine virtuelle IaaS. Sur Windows, les disques sont chiffrés à l’aide de la technologie de chiffrement BitLocker standard. Sur Linux, les disques sont chiffrés à l’aide de la technologie DM-Crypt. La fonctionnalité est intégrée à Azure Key Vault pour vous permettre de contrôler et gérer les clés de chiffrement de disque. Azure Disk Encryption convient pour les trois scénarios de chiffrement client suivants :
Activation du chiffrement sur de nouvelles machines virtuelles IaaS créées à partir des fichiers VHD chiffrés par le client et des clés de chiffrement fournies par le client, qui sont stockées dans Azure Key Vault.
Activation du chiffrement sur de nouvelles machines virtuelles IaaS créées à partir d’Azure Marketplace.
Activation du chiffrement sur des machines virtuelles IaaS existantes et fonctionnant déjà dans Azure.
Chiffrer les secrets dans les applications Service Fabric
Les secrets peuvent être des informations sensibles quelconques, notamment des chaînes de connexion de stockage, des mots de passe ou d’autres valeurs qui ne doivent pas être traitées en texte brut. Utilisez Azure Key Vault pour gérer les clés et les secrets dans les applications Service Fabric.
Effectuez la modélisation de sécurité et utilisez les divisions/équipes si nécessaire
Intitulé
Détails
Composant
Dynamics CRM
Phase SDL
Build
Technologies applicables
Générique
Attributs
N/A
Informations de référence
N/A
Étapes
Effectuez la modélisation de sécurité et utilisez les divisions/équipes si nécessaire
Réduisez l’accès pour partager la fonctionnalité sur les entités critiques
Intitulé
Détails
Composant
Dynamics CRM
Phase SDL
Déploiement
Technologies applicables
Générique
Attributs
N/A
Informations de référence
N/A
Étapes
Réduisez l’accès pour partager la fonctionnalité sur les entités critiques
Formez les utilisateurs aux risques liés à la fonctionnalité de partage Dynamics CRM et aux bonnes pratiques de sécurité
Intitulé
Détails
Composant
Dynamics CRM
Phase SDL
Déploiement
Technologies applicables
Générique
Attributs
N/A
Informations de référence
N/A
Étapes
Formez les utilisateurs aux risques liés à la fonctionnalité de partage Dynamics CRM et aux bonnes pratiques de sécurité
Inclure une règle de normes de développement interdisant l’affichage des détails de configuration dans la gestion des exceptions
Intitulé
Détails
Composant
Dynamics CRM
Phase SDL
Déploiement
Technologies applicables
Générique
Attributs
N/A
Informations de référence
N/A
Étapes
Incluez une règle de normes de développement interdisant l’affichage des détails de configuration dans la gestion des exceptions en dehors du développement. Testez cette procédure lors de vérifications de code ou d’un contrôle périodique.
Utiliser Azure Storage Service Encryption pour les données au repos (version préliminaire)
Azure Storage Service Encryption pour les données au repos vous aide à protéger vos données pour répondre aux engagements de votre organisation en matière de sécurité et de conformité. Avec cette fonctionnalité, Azure Storage chiffre automatiquement vos données avant de les rendre persistantes dans le stockage et les déchiffre avant la récupération. La gestion du chiffrement, du déchiffrement et des clés est totalement transparente pour les utilisateurs. SSE s’applique uniquement aux objets blob de blocs, aux objets blob de pages et aux objets blob d’ajout. Les autres types de données, y compris les tables, les files d’attente et les fichiers, ne sont pas chiffrés.
Flux de travail de chiffrement et de déchiffrement :
Le client active le chiffrement sur le compte de stockage
Lorsque le client écrit de nouvelles données (PUT Blob, PUT Block, PUT Page, etc.) pour le stockage Blob, chaque écriture est chiffrée à l’aide du chiffrement AES 256 bits, l’un des algorithmes de chiffrement par blocs les plus puissants disponibles
Lorsque le client a besoin d’accéder aux données (GET Blob, etc.), ces dernières sont automatiquement déchiffrées avant d’être renvoyées à l’utilisateur
Si le chiffrement est désactivé, les nouvelles écritures ne sont plus chiffrées et les données chiffrées existantes restent chiffrées jusqu’à ce qu’elles soient réécrites par l’utilisateur. Lorsque le chiffrement est activé, les écritures dans Blob Storage sont chiffrées. L’état des données ne change pas lorsque l’utilisateur bascule entre l’activation et la désactivation du chiffrement pour le compte de stockage
Toutes les clés de chiffrement sont stockées, chiffrées et gérées par Microsoft
Actuellement, les clés utilisées pour le chiffrement sont gérées par Microsoft. Microsoft crée initialement les clés, puis gère le stockage sécurisé des clés ainsi que leur rotation régulière, conformément à la politique interne de Microsoft en la matière. À l’avenir, les clients pourront gérer leurs propres clés de chiffrement et passer des clés gérées par Microsoft aux clés gérées par le client.
Utiliser le chiffrement côté client pour stocker les données sensibles dans le stockage Azure
La bibliothèque cliente de stockage Azure pour le package NuGet .NET prend en charge le chiffrement des données au sein des applications clientes avant le chargement vers le stockage Azure, et le déchiffrement des données pendant leur téléchargement vers le client. La bibliothèque prend également en charge l’intégration à Azure Key Vault pour la gestion des clés de compte de stockage. Voici une brève description du fonctionnement du chiffrement côté client :
Le Kit de développement logiciel (SDK) client de stockage Azure génère une clé de chiffrement de contenu (CEK) qui est une clé symétrique à usage unique
Les données du client sont chiffrées à l’aide de cette clé de chiffrement de contenu
La clé de chiffrement de contenu est ensuite encapsulée (chiffrée) à l’aide de la clé de chiffrement de clés (KEK). La clé de chiffrement de clés est identifiée par un identificateur de clé et peut être une paire de clés asymétriques ou une clé symétrique pouvant être gérée localement ou stockée dans Azure Key Vault. Le client Storage n’a jamais accès à la clé de chiffrement de clés. Il appelle simplement l'algorithme d’encapsulage de clés fourni par Key Vault. Si besoin est, les clients peuvent choisir d’utiliser des fournisseurs personnalisés pour l’encapsulage/le désencapsulage de clés
Les données chiffrées sont ensuite téléchargées sur le service Azure Storage. Vérifiez les liens dans la section Références pour en savoir plus sur l’implémentation de bas niveau.
Chiffrer les données sensibles ou personnelles écrites dans le stockage local des téléphones
Si l’application écrit des informations sensibles, comme les informations personnelles de l’utilisateur (adresse e-mail, numéro de téléphone, prénom, nom, préférences, etc.) sur le système de fichiers mobile, ces dernières doivent être chiffrées avant leur écriture sur le système de fichiers local. Si l’application est une application d’entreprise, envisagez la publication de l’application à l’aide de Windows Intune.
Exemple
Intune peut être configuré conformément aux stratégies de sécurité suivantes pour sauvegarder les données sensibles :
Require encryption on mobile device
Require encryption on storage cards
Allow screen capture
Exemple
Si l’application n’est pas une application d’entreprise, utilisez le keystore fourni par la plateforme et les trousseaux pour stocker les clés de chiffrement, grâce auxquels l’opération de chiffrement peut être effectuée sur le système de fichiers. L’extrait de code suivant explique comment accéder à une clé du trousseau à l’aide de Xamarin :
protected static string EncryptionKey
{
get
{
if (String.IsNullOrEmpty(_Key))
{
var query = new SecRecord(SecKind.GenericPassword);
query.Service = NSBundle.MainBundle.BundleIdentifier;
query.Account = "UniqueID";
NSData uniqueId = SecKeyChain.QueryAsData(query);
if (uniqueId == null)
{
query.ValueData = NSData.FromString(System.Guid.NewGuid().ToString());
var err = SecKeyChain.Add(query);
_Key = query.ValueData.ToString();
}
else
{
_Key = uniqueId.ToString();
}
}
return _Key;
}
}
Masquer les fichiers binaires générés avant la diffusion auprès des utilisateurs finaux
Les fichiers binaires générés (assemblys dans fichiers apk) doivent être masqués pour arrêter l’ingénierie à rebours des assemblys. Des outils tels que CryptoObfuscator peuvent être utilisés à cet effet.
Définir la valeur clientCredentialType sur Certificat ou Windows
L’utilisation d’un UsernameToken avec mot de passe en texte brut sur un canal non chiffré expose le mot de passe aux personnes malveillantes qui sont alors en mesure d’intercepter les messages SOAP. Les fournisseurs de services qui utilisent UsernameToken peuvent accepter l’envoi de mots de passe en texte brut. L’envoi de mots de passe en texte brut sur un canal non chiffré peut exposer les informations d’identification à des personnes malveillantes susceptibles d’intercepter le message SOAP.
Exemple
La configuration du fournisseur de services WCF suivante utilise un UsernameToken :
Aucune sécurité liée au transport ou aux messages n’a été définie. Les applications qui transmettent des messages sans sécurité liée au transport ou aux messages ne peuvent pas garantir l’intégrité ou la confidentialité des messages. Lorsqu’une liaison de sécurité WCF est définie sur Aucune, la sécurité liée au transport et aux messages est désactivée.
Exemple
La configuration suivante définit le mode de sécurité sur Aucun.
Mode de sécurité - L’ensemble des liaisons de service offre cinq modes de sécurité :
Aucun. Sécurité désactivée.
Transport. Utilise la sécurité liée au transport pour la protection des messages et l’authentification mutuelle.
Message. Utilise la sécurité liée aux messages pour la protection des messages et l’authentification mutuelle.
Les deux. Vous permet de fournir des paramètres de sécurité au niveau du transport et des messages (seul MSMQ prend en charge cette fonctionnalité).
TransportWithMessageCredential. Les informations d’identification sont transmises avec les messages, et la protection des messages et l’authentification du serveur sont fournies par la couche de transport.
TransportCredentialOnly. Les informations d’identification du client sont transmises avec la couche de transport, et aucune protection n’est appliquée aux messages. Utilisez la sécurité liée au transport et aux messages pour protéger l’intégrité et la confidentialité des messages. La configuration ci-dessous indique au service d’utiliser la sécurité liée au transport avec les informations d’identification du message.