Infrastructure de sécurité : Authentification | Mesures de correction

Produit/Service	Article
Application Web	Envisager d’utiliser un mécanisme d’authentification standard pour l’application web Les applications doivent gérer les scénarios d’authentification ayant échoué en toute sécurité Activer l’authentification adaptative ou avancée Garantir que les interfaces d’administration sont correctement verrouillées Implémenter des fonctionnalités de mot de passe oublié en toute sécurité Garantir que la stratégie de compte et de mot de passe est implémentée Implémenter des contrôles pour empêcher l’énumération de nom d’utilisateur
Sauvegarde de la base de données	Si possible, utiliser l’authentification Windows pour la connexion à SQL Server Quand cela est possible, utilisez l’authentification Microsoft Entra pour la connexion à SQL Database Lorsque le mode d’authentification SQL est utilisé, garantir que la stratégie de compte et de mot de passe est appliquée sur SQL Server Ne pas utiliser l’authentification SQL dans des bases de données autonomes
Azure Event Hub	Utiliser les informations d’authentification par appareil à l’aide des jetons SAP
Délimitation d’approbation Azure	Activer l’authentification multifacteur Microsoft Entra pour les Administrateurs Azure
Délimitation d’approbation Service Fabric	Restreindre l’accès anonyme au cluster Service Fabric Garantir que le certificat client à nœud Service Fabric est différent du certificat nœud à nœud Utiliser Microsoft Entra ID pour authentifier les clients auprès des clusters Service Fabric Garantir que les certificats Service Fabric proviennent d’une autorité de certification approuvée
Serveur d’identité	Utiliser des scénarios d’authentification standard pris en charge par IdentityServer Remplacer le cache de jetons IdentityServer par défaut par une solution évolutive
Délimitation d’approbation machine	Garantir que les fichiers binaires de l’application déployée sont signés numériquement
WCF	Activer l’authentification lors de la connexion aux files d’attente MSMQ dans WCF WCF - Ne pas définir clientCredentialType du message sur la valeur « aucun » WCF - Ne pas définir clientCredentialType du transport sur la valeur « aucun »
API Web	Garantir que les techniques d’authentification standard sont utilisées pour sécuriser les API Web
Microsoft Entra ID	Utiliser les scénarios d’authentification standard pris en charge Microsoft Entra ID Remplacement du cache de jetons MSAL par défaut par un cache distribué Prévention de la relecture de jetons d’authentification entrants à l’aide de TokenReplayCache Utiliser les bibliothèques MSAL pour gérer les demandes de jeton des clients OAuth2 vers Microsoft Entra ID (ou AD local)
Passerelle de champ IoT	Authentifier les appareils se connectant à la passerelle de champ
Passerelle de cloud IoT	Garantir que les appareils se connectant à la passerelle de cloud sont authentifiés Utiliser les informations d’authentification par appareil
Stockage Azure	Garantir que seuls les conteneurs et blobs requis disposent d’un accès en lecture anonyme Accorder un accès limité aux objets dans le stockage Azure à l’aide de SAS ou SAP

Envisager d’utiliser un mécanisme d’authentification standard pour l’application web

Intitulé	Détails
Composant	Application Web
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	N/A
Détails	L’authentification désigne le processus dans lequel une entité prouve son identité, généralement par le biais d’informations d’identification, comme le nom d’utilisateur et le mot de passe. Il existe plusieurs protocoles d’authentification disponibles à prendre en compte. Certains d’entre eux sont répertoriés ci-dessous : Certificats clients Basé sur Windows Basé sur des formulaires Fédération - ADFS Fédération - Microsoft Entra ID Fédération - IdentityServer Envisagez d’utiliser un mécanisme d’authentification standard pour identifier le processus source.

Les applications doivent gérer les scénarios d’authentification ayant échoué en toute sécurité

Intitulé	Détails
Composant	Application Web
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	N/A
Détails	Les applications qui authentifient explicitement les utilisateurs doivent gérer de manière sécurisée des scénarios d’authentification ayant échoué. Le mécanisme d’authentification doit : Refuser l’accès aux ressources avec des privilèges lorsque l’authentification échoue. Afficher un message d’erreur générique après l’échec d’authentification et le refus de l’accès. Test des éléments suivants : Protection des ressources avec des privilèges après les échecs de connexion. Un message d’erreur générique est affiché après les événements d’échec d’authentification et de refus de l’accès. Les comptes sont désactivés après un nombre excessif d’échecs.

Activer l’authentification adaptative ou avancée

Intitulé	Détails
Composant	Application Web
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	N/A
Détails	Vérifiez que l’application dispose d’une autorisation supplémentaire (comme une authentification adaptative ou avancée via l’authentification multifacteur, par exemple l’envoi d’OTP par SMS, e-mail, etc. ou une invite de nouvelle authentification) pour que l’utilisateur soit interrogé avant qu’un accès à des informations sensibles ne lui soit octroyé. Cette règle s’applique également pour les modifications critiques d’une action ou d’un compte. Cela signifie également que l’adaptation de l’authentification doit être implémentée de manière que l’application applique correctement l’autorisation sensible au contexte pour interdire les manipulations non autorisées via la falsification de paramètres par exemple.

Garantir que les interfaces d’administration sont correctement verrouillé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
Détails	La première solution consiste à accorder l’accès uniquement à partir d’une certaine plage d’adresses IP source à l’interface d’administration. Si cette solution n’est pas envisageable, il est toujours recommandé d’appliquer une authentification adaptative ou par étapes pour la connexion à l’interface d’administration

Implémenter des fonctionnalités de mot de passe oublié en toute sécurité

Intitulé	Détails
Composant	Application Web
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	N/A
Détails	La première chose consiste à vérifier que les chemins de mot de passe oublié ou autres chemins de récupération envoient un lien incluant un jeton d’activation à durée limitée plutôt que le mot de passe lui-même. Une authentification supplémentaire basée sur les jetons logiciels (par exemple, jeton SMS, applications mobiles natives, etc.) peut être utilisée avant l’envoi du lien. Ensuite, vous ne devez pas verrouiller les comptes des utilisateurs tant que le processus d’obtention d’un nouveau mot de passe est en cours. Cela peut entraîner une attaque par déni de service lorsqu’un pirate décide de verrouiller intentionnellement les utilisateurs avec une attaque automatisée. Puis, lorsque la demande de nouveau mot de passe est en cours, le message que vous affichez doit être généralisé afin d’éviter l’énumération de nom d’utilisateur. Enfin, interdisez toujours l’utilisation des anciens mots de passe et implémentez une stratégie de mot de passe forte.

Garantir que la stratégie de compte et de mot de passe est implémentée

Intitulé	Détails
Composant	Application Web
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	N/A
Détails	Une stratégie de compte et de mot de passe conforme à la stratégie et aux bonnes pratiques de l’organisation doit être implémentée. Pour se défendre contre les attaques en force brute et les vols basés sur le dictionnaire : une stratégie de mot de passe forte doit être implémentée pour garantir que les utilisateurs créent des mots de passe complexes (par exemple, longueur minimale de 12 caractères, caractères spéciaux et alphanumériques). Les stratégies de verrouillage de compte peuvent être implémentées de la manière suivante : Verrouillage léger : il peut s’agir d’une bonne option pour protéger vos utilisateurs des attaques en force brute. Par exemple, lorsque l’utilisateur entre un mot de passe incorrect trois fois de suite, l’application peut verrouiller le compte pendant une minute pour ralentir le processus d’attaque en force brute de son mot de passe, réduisant le champ d’action de l’attaquant. Si vous souhaitez implémenter des contre-mesures de verrouillage fort pour cet exemple, vous obtenez une « attaque DoS » en verrouillant les comptes de manière permanente. Sinon, une application peut générer un OTP (mot de passe à usage unique) et l’envoyer hors bande (par e-mail, sms, etc.) à l’utilisateur. Une autre approche peut être d’implémenter CAPTCHA dès qu’un seuil d’échec de tentatives est atteint. Verrouillage fort : ce type de verrouillage doit être appliqué lorsque vous détectez un utilisateur qui attaque votre application. Il est contré au moyen d’un verrouillage permanent de son compte jusqu’à ce qu’une équipe de réponse ait le temps de traiter le problème. Après ce processus, vous pouvez décider de rendre son compte à l’utilisateur ou d’entamer des poursuites contre lui. Ce type d’approche empêche le pirate de pénétrer davantage dans votre application et infrastructure. Pour se défendre contre les attaques sur les comptes par défaut et prévisibles, vérifiez que toutes les clés et que tous les mots de passe sont remplaçables et qu’ils sont générés ou remplacés après l’installation. Si l’application doit générer automatiquement des mots de passe, assurez-vous que les mots de passe générés sont aléatoires et ont une entropie élevée.

Implémenter des contrôles pour empêcher l’énumération de nom d’utilisateur

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 messages d’erreur doivent être généralisés afin d’éviter l’énumération de nom d’utilisateur. En outre, parfois, vous ne pouvez pas éviter une fuite d’informations dans des fonctionnalités comme une page d’inscription. Ici, vous devez utiliser des méthodes de limite de débit comme CAPTCHA pour empêcher une attaque automatisée par un pirate.

Si possible, utiliser l’authentification Windows pour la connexion à SQL Server

Intitulé	Détails
Composant	Base de données
Phase SDL	Build
Technologies applicables	Local
Attributs	Version SQL - Toutes
Informations de référence	SQL Server - Choisir un mode d’authentification
Étapes	L’authentification Windows utilise le protocole de sécurité Kerberos, met en œuvre des stratégies de mot de passe portant sur la validation de la complexité des mots de passe forts et prend en charge le verrouillage des comptes et l’expiration des mots de passe.

Quand cela est possible, utilisez l’authentification Microsoft Entra pour la connexion à SQL Database

Titre	Détails
Composant	Base de données
Phase SDL	Build
Technologies applicables	SQL Azure
Attributs	Version SQL - V12
Informations de référence	Se connecter à SQL Database à l’aide de l’authentification Microsoft Entra
Étapes	Version minimum : Azure SQL Database V12 est nécessaire pour autoriser Azure SQL Database à utiliser l’authentification Microsoft Entra sur Microsoft Directory

Lorsque le mode d’authentification SQL est utilisé, garantir que la stratégie de compte et de mot de passe est appliquée sur SQL Server

Intitulé	Détails
Composant	Base de données
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	Stratégie de mot de passe SQL Server
Étapes	Lorsque vous utilisez l’authentification SQL Server, les connexions sont créées dans SQL Server et ne sont pas basées sur des comptes d’utilisateur Windows. Le nom d’utilisateur et le mot de passe sont créés à l’aide de SQL Server et stockés dans SQL Server. SQL Server peut utiliser des mécanismes de stratégie de mot de passe Windows. Il peut appliquer la même complexité et les mêmes stratégies d’expiration utilisées dans Windows pour les mots de passe utilisés dans SQL Server.

Ne pas utiliser l’authentification SQL dans des bases de données à relation contenant-contenu

Intitulé	Détails
Composant	Base de données
Phase SDL	Build
Technologies applicables	Local, SQL Azure
Attributs	Version SQL - MSSQL2012, Version SQL - V12
Informations de référence	Meilleures pratiques de sécurité recommandées avec les bases de données autonomes
Étapes	L’absence de stratégie de mot de passe peut augmenter la probabilité de faibles informations d’identification établies dans une base de données autonome. Utilisez l’authentification Windows.

Utiliser les informations d’authentification par appareil à l’aide des jetons SAP

Intitulé	Détails
Composant	Azure Event Hubs
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	Présentation du modèle de sécurité et de l’authentification Event Hubs
Étapes	Le modèle de sécurité Event Hubs est basé sur une combinaison de jetons de signature d’accès partagé (SAP) et d’éditeurs d’événements. Le nom de l’éditeur représente l’ID de l’appareil qui reçoit le jeton. Cela permet d’associer les jetons générés aux appareils respectifs. Tous les messages sont marqués avec le donneur d’ordre côté service autorisant la détection de tentatives d’usurpation d’origine en charge utile. Lors de l’authentification des appareils, générez un jeton SAP par appareil limité à un éditeur unique.

Activer l’authentification multifacteur Microsoft Entra pour les Administrateurs Azure

Titre	Détails
Composant	Délimitation d’approbation Azure
Phase SDL	Déploiement
Technologies applicables	Générique
Attributs	N/A
Informations de référence	Qu’est-ce que l’authentification multifacteur Microsoft Entra ?
Étapes	L’authentification multifacteur (MFA) est une méthode d’authentification qui nécessite plus d’une méthode de vérification et ajoute une deuxième couche de sécurité critique aux connexions et transactions des utilisateurs. Cette authentification fonctionne en nécessitant au minimum deux des méthodes de vérification suivantes : Un élément que vous connaissez (généralement un mot de passe) Quelque chose que vous possédez (un appareil de confiance qu’il est difficile de dupliquer, comme un téléphone) Un élément vous concernant particulièrement (biométrie)

Restreindre l’accès anonyme au cluster Service Fabric

Intitulé	Détails
Composant	Délimitation d’approbation Service Fabric
Phase SDL	Déploiement
Technologies applicables	Générique
Attributs	Environnement - Azure
Informations de référence	Scénarios de sécurité d’un cluster Service Fabric
Étapes	Les clusters doivent toujours être sécurisés pour empêcher les utilisateurs non autorisés de se connecter à votre cluster, surtout quand des charges de travail sont en cours d’exécution sur ce dernier. Lors de la création d’un cluster Service Fabric, assurez-vous que le mode de sécurité est défini sur la valeur « sécurisé » et configurez le certificat de serveur X.509 requis. La création d’un cluster « non sécurisé » permettra à tout utilisateur anonyme de s’y connecter si les points de terminaison de gestion sont exposés sur l’Internet public.

Garantir que le certificat client à nœud Service Fabric est différent du certificat nœud à nœud

Intitulé	Détails
Composant	Délimitation d’approbation Service Fabric
Phase SDL	Déploiement
Technologies applicables	Générique
Attributs	Environnement - Azure, environnement - Autonome
Informations de référence	Sécurité par certificat de client à nœud, Se connecter à un cluster sécurisé à l’aide d’un certificat client
Étapes	La configuration de la sécurité par certificat de client à nœud s’effectue lors de la création du cluster (par le biais du Portail Azure, des modèles Resource Manager ou d’un modèle JSON autonome) en spécifiant un certificat client d’administration et/ou un certificat de client utilisateur. Les certificats client d’administration et client utilisateur que vous spécifiez doivent être différents des certificats primaires et secondaires que vous spécifiez pour la sécurité de nœud à nœud.

Utiliser Microsoft Entra ID pour authentifier les clients sur les clusters Service Fabric

Titre	Détails
Composant	Délimitation d’approbation Service Fabric
Phase SDL	Déploiement
Technologies applicables	Générique
Attributs	Environnement - Azure
Informations de référence	Scénarios de sécurité d’un cluster - Recommandations en matière de sécurité
Étapes	Les clusters s’exécutant sur Azure peuvent également sécuriser l’accès aux points de terminaison de gestion à l’aide de Microsoft Entra ID, en plus des certificats client. Pour les clusters Azure, nous vous recommandons d’utiliser la sécurité Microsoft Entra pour authentifier les clients et les certificats, pour une sécurité de nœud à nœud.

Garantir que les certificats Service Fabric proviennent d’une autorité de certification approuvée

Intitulé	Détails
Composant	Délimitation d’approbation Service Fabric
Phase SDL	Déploiement
Technologies applicables	Générique
Attributs	Environnement - Azure
Informations de référence	Certificats X.509 et Service Fabric
Étapes	Service Fabric utilise des certificats de serveur X.509 pour l’authentification des clients et des nœuds. Voici quelques éléments importants à prendre en compte lors de l’utilisation de certificats dans Service Fabric : Les certificats utilisés dans les clusters qui exécutent des charges de travail de production doivent être créés en utilisant un service de certificats Windows Server correctement configuré ou obtenus auprès d’une autorité de certification approuvée. L’autorité de certification peut être une autorité de certification externe approuvée ou une infrastructure de clé publique interne correctement gérée. En production, n’utilisez jamais de certificats temporaires ou de test créés avec des outils comme MakeCert.exe. Vous pouvez utiliser un certificat auto-signé, mais seulement pour les clusters de test et non en production.

Utiliser des scénarios d’authentification standard pris en charge par IdentityServer

Intitulé	Détails
Composant	IdentityServer
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	IdentityServer3 - The Big Picture (IdentityServer3 - Vue d’ensemble)
Étapes	Vous trouverez ci-dessous les interactions classiques prises en charge par IdentityServer : Les navigateurs communiquent avec les applications web. Les applications web communiquent avec les API web (parfois pour elles-mêmes, parfois pour le compte d’un utilisateur). Les applications basées sur un navigateur communiquent avec les API web. Les applications natives communiquent avec les API web. Les applications basées sur un serveur communiquent avec les API web. Les API web communiquent avec les API web (parfois pour elles-mêmes, parfois pour le compte d’un utilisateur).

Remplacer le cache de jetons IdentityServer par défaut par une solution évolutive

Intitulé	Détails
Composant	IdentityServer
Phase SDL	Déploiement
Technologies applicables	Générique
Attributs	N/A
Informations de référence	Identity Server Deployment - Caching (Déploiement d’IdentityServer - Mise en cache)
Étapes	IdentityServer a un cache en mémoire intégré simple. Bien que cette fonction soit utile pour les applications natives à petite échelle, elle n’est pas adaptée pour les applications de serveur principal et de niveau intermédiaire pour les raisons suivantes : Ces applications sont accessibles par plusieurs utilisateurs simultanément. L’enregistrement de tous les jetons d’accès dans le même magasin crée des problèmes d’isolation et présente des défis lors du fonctionnement à l’échelle : beaucoup d’utilisateurs, chacun avec autant de jetons que de ressources auxquelles l’application accède pour leur compte, peut entraîner un nombre très élevé d’opérations de recherche très coûteuses. Ces applications sont généralement déployées sur des topologies distribuées, où plusieurs nœuds doivent accéder au même cache. Les jetons mis en cache doivent survivre aux désactivations et recyclages de processus. Pour toutes les raisons susmentionnées, lors de l’implémentation des applications web, il est recommandé de remplacer le cache de jeton d’IdentityServer par défaut avec une solution évolutive telle que le Cache Azure pour Redis

Garantir que les fichiers binaires de l’application déployée sont signés numériquement

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 de l’application déployée sont signés numériquement afin que l’intégrité des fichiers binaires puisse être vérifiée.

Activer l’authentification lors de la connexion aux files d’attente MSMQ dans WCF

Intitulé	Détails
Composant	WCF
Phase SDL	Build
Technologies applicables	Générique, NET Framework 3
Attributs	N/A
Informations de référence	MSDN
Étapes	Le programme ne parvient pas à activer l’authentification lors de la connexion aux files d’attente MSMQ, un pirate peut envoyer anonymement des messages à la file d’attente pour traitement. Si l’authentification n’est pas utilisée pour se connecter à une file d’attente MSMQ pour remettre un message à un autre programme, un pirate pourrait envoyer un message malveillant anonyme.

Exemple

L’élément <netMsmqBinding/> du fichier de configuration WCF ci-dessous indique à WCF de désactiver l’authentification lors de la connexion à une file d’attente MSMQ pour la remise du message.

<bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""None"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

Configurez MSMQ pour exiger l’authentification de certificat ou de domaine Windows à tout moment pour les messages entrants ou sortants.

Exemple

L’élément <netMsmqBinding/> du fichier de configuration WCF ci-dessous indique à WCF d’activer l’authentification de certificat lors de la connexion à une file d’attente MSMQ. Le client est authentifié à l’aide de certificats X.509. Le certificat client doit être présent dans le magasin de certificats du serveur.

<bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""Certificate"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

WCF - Ne pas définir clientCredentialType du message sur la valeur « aucun »

Intitulé	Détails
Composant	WCF
Phase SDL	Build
Technologies applicables	.NET Framework 3
Attributs	Type d’informations d’identification client - Aucun
Informations de référence	MSDN, Fortify
Étapes	L’absence d’authentification signifie que tout le monde peut accéder à ce service. Un service qui n’authentifie pas ses clients autorise l’accès à tous les utilisateurs. Configurez l’application pour une authentification en fonction des informations d’identification du client. Cela est possible en définissant le clientCredentialType du message sur Windows ou Certificat.

Exemple

<message clientCredentialType=""Certificate""/>

WCF - Ne pas définir clientCredentialType du transport sur la valeur « aucun »

Intitulé	Détails
Composant	WCF
Phase SDL	Build
Technologies applicables	Générique, .NET Framework 3
Attributs	Type d’informations d’identification client - Aucun
Informations de référence	MSDN, Fortify
Étapes	L’absence d’authentification signifie que tout le monde peut accéder à ce service. Un service qui n’authentifie pas ses clients autorise tous les utilisateurs à accéder à ses fonctionnalités. Configurez l’application pour une authentification en fonction des informations d’identification du client. Cela est possible en définissant le clientCredentialType du transport sur Windows ou Certificat.

Exemple

<transport clientCredentialType=""Certificate""/>

Garantir que les techniques d’authentification standard sont utilisées pour sécuriser les API Web

Intitulé	Détails
Composant	API Web
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	Authentication and Authorization in ASP.NET Web API (Authentification et autorisation dans l’API web ASP.NET), External Authentication Services with ASP.NET Web API (C#) (Services d’authentification externe avec l’API web ASP.NET (C#))
Étapes	L’authentification désigne le processus dans lequel une entité prouve son identité, généralement par le biais d’informations d’identification, comme le nom d’utilisateur et le mot de passe. Il existe plusieurs protocoles d’authentification disponibles à prendre en compte. Certains d’entre eux sont répertoriés ci-dessous : Certificats clients Basé sur Windows Basé sur des formulaires Fédération - ADFS Fédération - Microsoft Entra ID Fédération - IdentityServer Les liens dans la section Références fournissent des informations de bas niveau sur la façon dont les schémas d’authentification peuvent être implémentés pour sécuriser une API web.

Utiliser les scénarios d’authentification standard pris en charge Microsoft Entra ID

Titre	Détails
Composant	Microsoft Entra ID
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	Scénarios d’authentification pour Microsoft Entra ID, Exemples de code Microsoft Entra, Guide du développeur Microsoft Entra
Étapes	Microsoft Entra ID simplifie l’authentification des développeurs en fournissant l’identité en tant que service, avec la prise en charge des protocoles standard du secteur, comme OAuth 2.0 et OpenID Connect. Vous trouverez ci-dessous les cinq principaux scénarios d’application pris en charge par Microsoft Entra ID : Navigateur web vers application web : un utilisateur doit se connecter à une application web sécurisée par Microsoft Entra ID Application monopage (SPA) : un utilisateur doit se connecter à une application monopage sécurisée par Microsoft Entra ID Application native vers API web : une application native qui s’exécute sur un téléphone, une tablette ou un PC doit authentifier un utilisateur pour obtenir les ressources d’une API web sécurisée par Microsoft Entra ID Application web vers API web : une application web doit obtenir les ressources d’une API web sécurisée par Microsoft Entra ID Application démon ou serveur vers API web : une application démon ou une application serveur sans interface utilisateur web doit obtenir les ressources d’une API web sécurisée par Microsoft Entra ID Consultez les liens dans la section Références pour en savoir plus sur l’implémentation de bas niveau.

Remplacement du cache de jetons MSAL par défaut par un cache distribué

Intitulé	Détails
Composant	Microsoft Entra ID
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	Sérialisation du cache de jetons dans MSAL.NET
Étapes	Le cache utilisé par défaut par MSAL (la bibliothèque d’authentification Microsoft) est un cache en mémoire scalable. D’autres options sont toutefois disponibles, notamment un cache de jetons distribué. Ce type de cache comporte des mécanismes L1/L2, où L1 est en mémoire, et L2 représente l’implémentation du cache distribué. Ils peuvent être configurés en conséquence pour limiter la mémoire L1, chiffrer les données ou définir des stratégies d’éviction. Il existe d’autres solutions encore, notamment les caches Redis, SQL Server et Azure Cosmos DB. Vous trouverez une implémentation d’un cache de jetons distribué dans Tutoriel : Prise en main d’ASP.NET Core MVC.

Prévention de la relecture de jetons d’authentification MSAL à l’aide de TokenReplayCache

Intitulé	Détails
Composant	Microsoft Entra ID
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	Authentification moderne avec Microsoft Entra ID pour les applications web
Étapes	La propriété TokenReplayCache permet aux développeurs de définir un cache de relecture de jetons, un magasin qui peut être utilisé pour enregistrer les jetons afin de vérifier qu’aucun jeton ne peut être utilisé plusieurs fois. Il s’agit d’une mesure contre une attaque courante, l’attaque judicieusement appelée relecture de jetons : un pirate interceptant le jeton envoyé à la connexion peut tenter de l’envoyer à nouveau à l’application (le « relire ») pour établir une nouvelle session. Par exemple, dans le flux d’octroi de code d’OIDC, après une authentification utilisateur réussie, une demande vers le point de terminaison « /signin-oidc » de la partie de confiance est réalisée avec les paramètres « id_token », « code » et « état ». La partie de confiance valide cette demande et établit une nouvelle session. Si un adversaire capture cette demande et la relit, il peut réussir à établir une session et tromper l’utilisateur. La présence de la valeur à usage unique dans OpenID Connect peut limiter mais pas complètement éliminer les circonstances dans lesquelles l’attaque peut être mise en œuvre correctement. Pour protéger leurs applications, les développeurs peuvent fournir une implémentation de ITokenReplayCache et assigner une instance à TokenReplayCache.

Exemple

// ITokenReplayCache defined in MSAL
public interface ITokenReplayCache
{
bool TryAdd(string securityToken, DateTime expiresOn);
bool TryFind(string securityToken);
}

Exemple

Voici un exemple d’implémentation de l’interface ITokenReplayCache. (Veuillez personnaliser et mettre en œuvre votre infrastructure de mise en cache spécifique au projet)

public class TokenReplayCache : ITokenReplayCache
{
    private readonly ICacheProvider cache; // Your project-specific cache provider
    public TokenReplayCache(ICacheProvider cache)
    {
        this.cache = cache;
    }
    public bool TryAdd(string securityToken, DateTime expiresOn)
    {
        if (this.cache.Get<string>(securityToken) == null)
        {
            this.cache.Set(securityToken, securityToken);
            return true;
        }
        return false;
    }
    public bool TryFind(string securityToken)
    {
        return this.cache.Get<string>(securityToken) != null;
    }
}

Le cache implémenté doit être référencé dans les options OIDC via la propriété « TokenValidationParameters » comme suit.

OpenIdConnectOptions openIdConnectOptions = new OpenIdConnectOptions
{
    AutomaticAuthenticate = true,
    ... // other configuration properties follow..
    TokenValidationParameters = new TokenValidationParameters
    {
        TokenReplayCache = new TokenReplayCache(/*Inject your cache provider*/);
    }
}

Notez que pour tester l’efficacité de cette configuration, vous devez vous connecter à votre application locale protégée par OIDC et capturer la demande envoyée au point de terminaison "/signin-oidc" dans fiddler. Lorsque la protection n’est pas en place, la relecture de cette demande dans fiddler définira un nouveau cookie de session. Lors de la relecture de la demande après avoir ajouté la protection TokenReplayCache, l’application lève une exception comme suit :SecurityTokenReplayDetectedException: IDX10228: The securityToken has previously been validated, securityToken: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBPWWlKSE1iYTlnb0VLWSIsImtpZCI6Ik1uQ1......

Utiliser les bibliothèques MSAL pour gérer les demandes de jeton des clients OAuth2 vers Microsoft Entra ID (ou AD local)

Titre	Détails
Composant	Microsoft Entra ID
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	MSAL
Étapes	La Bibliothèque d’authentification Microsoft (MSAL) permet aux développeurs d’acquérir des jetons de sécurité auprès de la plateforme d’identités Microsoft afin d’authentifier les utilisateurs et d’accéder aux API web sécurisées. Il peut être utilisé pour fournir un accès sécurisé à Microsoft Graph, d’autres API Microsoft, des API web de tiers ou vos propres API web. MSAL prend en charge de nombreuses architectures et plateformes d’application différentes, notamment .NET, JavaScript, Java, Python, Android et iOS.

MSAL vous permet d’obtenir des jetons différentes manières, avec une API cohérente pour plusieurs plateformes. Il n’est pas nécessaire d’utiliser directement les bibliothèques ni le code OAuth sur le protocole de votre application. Vous pouvez acquérir des jetons pour le compte d’un utilisateur ou d’une application (en fonction de la plateforme).

La bibliothèque MSAL gère également un cache de jetons et actualise automatiquement les jetons quand ils sont sur le point d’expirer. Elle vous aide par ailleurs à spécifier l’audience à laquelle vous souhaitez que votre application se connecte, à configurer votre application à partir de fichiers de configuration et à résoudre les problèmes de votre application.

Authentifier les appareils se connectant à la passerelle de champ

Intitulé	Détails
Composant	Passerelle de champ IoT
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	N/A
Étapes	Assurez-vous que chaque appareil est authentifié par la passerelle de champ avant d’accepter des données provenant de ceux-ci et de faciliter les communications en amont avec la passerelle de cloud. En outre, assurez-vous que les appareils se connectent avec des informations d’identification par appareil, afin que chaque appareil puisse être identifié de manière unique.

Garantir que les appareils se connectant à la passerelle de cloud sont authentifiés

Intitulé	Détails
Composant	Passerelle cloud IoT
Phase SDL	Build
Technologies applicables	Générique, C#, Node.js,
Attributs	N/A, choix de passerelle - Azure IoT Hub
Informations de référence	N/A, Mise en route d’Azure IoT Hub (.NET), Mise en route d’Azure IoT Hub (Node), Contrôler l’accès à IoT Hub, référentiel Git
Étapes	Générique : authentifiez l’appareil à l’aide du protocole TLS (Transport Layer Security) ou IPSec. L’infrastructure doit prendre en charge l’utilisation d’une clé prépartagée (PSK) sur les périphériques qui ne peuvent pas gérer le chiffrement asymétrique complet. Tirer profit de Microsoft Entra ID, Oauth. C# : par défaut, la méthode de création Create crée une instance DeviceClient qui utilise le protocole AMQP pour communiquer avec IoT Hub. Pour utiliser le protocole HTTPS, remplacez la méthode Create afin de pouvoir spécifier le protocole. Si vous utilisez le protocole HTTPS, vous devez également ajouter le package NuGet Microsoft.AspNet.WebApi.Client à votre projet de manière à inclure l’espace de noms System.Net.Http.Formatting.

Exemple

static DeviceClient deviceClient;

static string deviceKey = "{device key}";
static string iotHubUri = "{iot hub hostname}";

var messageString = "{message in string format}";
var message = new Message(Encoding.ASCII.GetBytes(messageString));

deviceClient = DeviceClient.Create(iotHubUri, new DeviceAuthenticationWithRegistrySymmetricKey("myFirstDevice", deviceKey));

await deviceClient.SendEventAsync(message);

Exemple

Node.js : authentification

Clé symétrique

• Créer un hub IoT sur Azure
• Créez une entrée dans le registre des identités de l’appareil.

  var device = new iothub.Device(null);
  device.deviceId = <DeviceId >
  registry.create(device, function(err, deviceInfo, res) {})
  

• Créez un appareil simulé.

  var clientFromConnectionString = require('azure-iot-device-amqp').clientFromConnectionString;
  var Message = require('azure-iot-device').Message;
  var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>SharedAccessKey=<SharedAccessKey>';
  var client = clientFromConnectionString(connectionString);
  

  Jeton SAP

• Généré en interne lors de l’utilisation de la clé symétrique, mais nous pouvons le générer et l’utiliser explicitement également.
• Définissez un protocole : var Http = require('azure-iot-device-http').Http;.
• Créez un jeton SAP :

  resourceUri = encodeURIComponent(resourceUri.toLowerCase()).toLowerCase();
  var deviceName = "<deviceName >";
  var expires = (Date.now() / 1000) + expiresInMins * 60;
  var toSign = resourceUri + '\n' + expires;
  // using crypto
  var decodedPassword = new Buffer(signingKey, 'base64').toString('binary');
  const hmac = crypto.createHmac('sha256', decodedPassword);
  hmac.update(toSign);
  var base64signature = hmac.digest('base64');
  var base64UriEncoded = encodeURIComponent(base64signature);
  // construct authorization string
  var token = "SharedAccessSignature sr=" + resourceUri + "%2fdevices%2f"+deviceName+"&sig="
  + base64UriEncoded + "&se=" + expires;
  if (policyName) token += "&skn="+policyName;
  return token;
  

• Connectez-vous à l’aide du jeton SAP :

  Client.fromSharedAccessSignature(sas, Http);
  

  Certificats

• Générez un certificat X509 auto-signé à l’aide d’un outil tel qu’OpenSSL pour créer des fichiers .cert et .key pour stocker respectivement le certificat et la clé.
• Approvisionnez un appareil qui accepte une connexion sécurisée à l’aide de certificats.

  var connectionString = '<connectionString>';
  var registry = iothub.Registry.fromConnectionString(connectionString);
  var deviceJSON = {deviceId:"<deviceId>",
  authentication: {
      x509Thumbprint: {
      primaryThumbprint: "<PrimaryThumbprint>",
      secondaryThumbprint: "<SecondaryThumbprint>"
      }
  }}
  var device = deviceJSON;
  registry.create(device, function (err) {});
  

• Connectez un appareil à l’aide d’un certificat.

  var Protocol = require('azure-iot-device-http').Http;
  var Client = require('azure-iot-device').Client;
  var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>x509=true';
  var client = Client.fromConnectionString(connectionString, Protocol);
  var options = {
      key: fs.readFileSync('./key.pem', 'utf8'),
      cert: fs.readFileSync('./server.crt', 'utf8')
  };
  // Calling setOptions with the x509 certificate and key (and optionally, passphrase) will configure the client //transport to use x509 when connecting to IoT Hub
  client.setOptions(options);
  //call fn to execute after the connection is set up
  client.open(fn);
  

Utiliser les informations d’authentification par appareil

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	Contrôler l’accès à IoT Hub
Étapes	Utilisez des informations d’authentification par appareil à l’aide des jetons SAP en fonction de la clé d’appareil ou du certificat de client plutôt que des stratégies d’accès partagé au niveau d’IoT Hub. Cela empêche la réutilisation des jetons d’authentification d’une passerelle de champ ou d’un appareil par un autre.

Garantir que seuls les conteneurs et blobs requis disposent d’un accès en lecture anonyme

Intitulé	Détails
Composant	Stockage Azure
Phase SDL	Build
Technologies applicables	Générique
Attributs	StorageType - Blob
Informations de référence	Gestion de l’accès en lecture anonyme aux conteneurs et aux objets blob, Signatures d’accès partagé (SAP), partie 1 : Présentation du modèle SAP
Étapes	Par défaut, un conteneur et tous les blobs qu’il contient sont accessibles uniquement par le propriétaire du compte de stockage. Pour fournir aux utilisateurs anonymes des autorisations de lecture sur un conteneur et ses blobs, il est possible de configurer les autorisations du conteneur afin d’autoriser l’accès public. Les utilisateurs anonymes peuvent lire les objets blob d’un conteneur accessible publiquement sans avoir à authentifier la demande. Les conteneurs fournissent les options suivantes pour gérer leur accès : Accès en lecture public complet : les données de conteneur et d’objets blob sont lisibles au moyen d’une requête anonyme. Les clients peuvent énumérer les objets blob à l’intérieur du conteneur via une demande anonyme, mais ne peuvent pas énumérer les conteneurs dans le compte de stockage. Accès en lecture public pour les objets blob uniquement : Les données d'objets blob à l'intérieur de ce conteneur peuvent être lues via une demande anonyme, mais les données du conteneur ne sont pas disponibles. Les clients ne peuvent pas énumérer les blobs à l’intérieur du conteneur via une demande anonyme. Aucun accès en lecture public : seul le propriétaire du compte peut lire les données de conteneur et d’objet blob L’accès anonyme est idéal dans les situations où certains blobs doivent toujours être disponibles pour l’accès en lecture anonyme. Pour un contrôle plus fin, il est possible de créer une signature d’accès partagé de manière à déléguer un accès restreint en utilisant des autorisations différentes sur un intervalle de temps spécifié. Vérifiez que les conteneurs et les blobs, qui peuvent éventuellement contenir des données sensibles, ne reçoivent pas accidentellement un accès anonyme

Accorder un accès limité aux objets dans le stockage Azure à l’aide de SAS ou SAP

Intitulé	Détails
Composant	Stockage Azure
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	Signatures d’accès partagé, partie 1 : présentation du modèle SAP, Signatures d’accès partagé, partie 2 : Créer et utiliser une signature d’accès partagé avec Stockage Blob, Comment déléguer l’accès aux objets dans votre compte à l’aide de signatures d’accès partagé et stratégies d’accès stockées
Étapes	Une signature d’accès partagé (SAP) constitue un moyen efficace pour octroyer aux autres clients un accès limité aux blobs dans un compte de stockage, sans exposer de clé d’accès de compte. La signature d'accès partagé est un URI qui englobe dans ses paramètres de requête toutes les informations nécessaires pour un accès authentifié à une ressource de stockage. Pour accéder aux ressources de stockage avec la signature d'accès partagé, il suffit au client de transmettre cette dernière à la méthode ou au constructeur approprié. Vous pouvez utiliser une signature d'accès partagé lorsque vous voulez fournir un accès aux ressources dans votre compte de stockage à un client qui ne peut pas être approuvé avec la clé du compte. Vos clés de compte de stockage incluent une clé primaire et une clé secondaire, qui octroient toutes deux un accès administratif à votre compte et à toutes ses ressources. En exposant l'une ou l'autre des clés de votre compte, vous courez le risque d'une utilisation malveillante ou négligente de ce dernier. Les signatures d'accès partagé offrent une alternative sûre qui permet aux autres clients de lire, d'écrire et de supprimer des données dans votre compte de stockage en fonction des autorisations que vous avez octroyées, sans avoir besoin de la clé du compte. Si vous avez un ensemble logique de paramètres qui sont chaque fois similaires, il est plus judicieux d’utiliser une stratégie d’accès stockée. Comme l’utilisation d’une signature d’accès partagé dérivée d’une stratégie d’accès stockée vous permet de révoquer immédiatement cette signature d’accès partagé, il est recommandé de toujours utiliser des stratégies d’accès stockées quand cela est possible.