Présentation du développement d’applications Windows sécurisées

Article
07/08/2024

Cet article introductif aide les architectes d’applications et les développeurs à mieux comprendre les différentes capacités de la plate-forme Windows 10 qui accélèrent la création d’applications sécurisées de la plate-forme universelle Windows (UWP). Il détaille comment utiliser les fonctionnalités de sécurité de Windows disponibles à chacune des étapes suivantes : l’authentification, les données en transit et les données au repos. Vous pouvez trouver des informations plus approfondies sur chaque sujet en examinant les ressources supplémentaires incluses dans chaque chapitre.

1 Introduction

Le développement d’une application sécurisée peut présenter des difficultés. Dans un monde où tout va très vite avec les applications mobiles, sociales, cloud et les applications d’entreprise complexes, les clients s’attendent à ce que les applications soient disponibles et mises à jour plus rapidement que jamais. Ils utilisent également de nombreux types d’appareils, ce qui ajoute à la complexité de la création d’expériences d’application. Si vous créez pour Windows plateforme Windows universelle (UWP), qui peut inclure la liste traditionnelle des ordinateurs de bureau, des ordinateurs portables, des tablettes et des appareils mobiles ; en plus d’une liste croissante de nouveaux appareils couvrant l’Internet des objets, Xbox One, Microsoft Surface Hub et HoloLens. En tant que développeur, vous devez vous assurer que vos applications communiquent et stockent les données de manière sécurisée, sur toutes les plates-formes ou tous les appareils impliqués.

Voici quelques-uns des avantages de l’utilisation des fonctionnalités de sécurité Windows.

Vous aurez une sécurité standardisée sur tous les appareils qui prennent en charge Windows, en utilisant des API cohérentes pour les composants et technologies de sécurité.
Vous écrivez, testez et maintenez moins de code que si vous implémentiez du code personnalisé pour couvrir ces scénarios de sécurité.
Vos applications deviennent plus stables et plus sécurisées car vous utilisez le système d’exploitation pour contrôler la façon dont l’application accède à ses ressources et aux ressources système locales ou distantes.

Pendant l’authentification, l’identité d’un utilisateur demandant l’accès à un service particulier est validée. Windows Hello est le composant de Windows qui permet de créer un mécanisme d’authentification plus sécurisé dans les applications Windows. Avec lui, vous pouvez utiliser un numéro d’identification personnel (PIN) ou des biométriques tels que les empreintes digitales, le visage ou l’iris de l’utilisateur pour mettre en œuvre une authentification multi-facteurs pour vos applications.

Les données en transit font référence à la connexion et aux messages transférés à travers celle-ci. Par exemple, la récupération de données depuis un serveur distant à l’aide de services web. L’utilisation de Secure Sockets Layer (SSL) et du protocole HTTPS sécurise la connexion. Empêcher les tiers d’accéder à ces messages, ou les applications non autorisées de communiquer avec les services web, est essentiel pour sécuriser les données en transit.

Enfin, les données au repos concernent les données résidant en mémoire ou sur des supports de stockage. Les applications Windows ont un modèle d’application qui empêche l’accès non autorisé aux données entre les applications et offre des API de chiffrement pour sécuriser davantage les données sur l’appareil. Une fonctionnalité appelée Credential Locker peut être utilisée pour stocker en toute sécurité les informations d’identification de l’utilisateur sur l’appareil, l’exploitation système empêchant les autres applications d’y accéder.

2 Facteurs d’authentification

Pour protéger les données, la personne demandant l’accès à ces données doit être identifiée et autorisée à accéder aux ressources de données qu’elle demande. Le processus d’identification d’un utilisateur est appelé authentification, et la détermination des privilèges d’accès à une ressource est appelée autorisation. Ce sont des opérations étroitement liées, et pour l’utilisateur, elles pourraient être indiscernables. Elles peuvent être des opérations relativement simples ou complexes, selon de nombreux facteurs : par exemple, si les données résident sur un seul serveur ou sont réparties sur de nombreux systèmes. Le serveur fournissant les services d’authentification et d’autorisation est appelé le fournisseur d’identité.

Pour s’authentifier auprès d’un service et/ou d’une application particulière, l’utilisateur utilise des informations d’identification composées de quelque chose qu’il connaît, de quelque chose qu’il possède et/ou de quelque chose qu’il est. Chacun de ces éléments est appelé facteur d’authentification.

Quelque chose que l’utilisateur connaît est généralement un mot de passe, mais cela peut aussi être un numéro d’identification personnel (PIN) ou une paire de question/réponse « secrète ».
Quelque chose que l’utilisateur possède est le plus souvent un dispositif de mémoire matérielle tel qu’une clé USB contenant les données d’authentification propres à l’utilisateur.
Quelque chose que l’utilisateur est englobe souvent ses empreintes digitales, mais il existe des facteurs de plus en plus populaires comme la parole, les caractéristiques faciales, oculaires (yeux) ou les modèles de comportement de l’utilisateur. Lorsqu’ils sont stockés sous forme de données, ces mesures sont appelées biométrie.

Un mot de passe créé par l’utilisateur est un facteur d’authentification en lui-même, mais il n’est souvent pas suffisant ; quiconque connaît le mot de passe peut se faire passer pour l’utilisateur qui le possède. Une carte à puce peut fournir un niveau de sécurité plus élevé, mais elle peut être volée, perdue ou égarée. Un système capable d’authentifier un utilisateur par empreinte digitale ou par un scanner oculaire pourrait offrir le niveau de sécurité le plus élevé et le plus pratique, mais cela nécessite un matériel coûteux et spécialisé (par exemple, une caméra Intel RealSense pour la reconnaissance faciale) qui pourrait ne pas être disponible pour tous les utilisateurs.

La conception de la méthode d’authentification utilisée par un système est un aspect complexe et important de la sécurité des données. En général, plus vous utilisez de facteurs dans l’authentification, plus le système est sécurisé. En même temps, l’authentification doit être utilisable. Un utilisateur se connectera généralement plusieurs fois par jour, donc le processus doit être rapide. Votre choix de type d’authentification est un compromis entre la sécurité et la simplicité d’utilisation ; l’authentification à un seul facteur est la moins sécurisée et la plus facile à utiliser, et l’authentification multi-facteurs devient plus sécurisée, mais plus complexe à mesure que davantage de facteurs sont ajoutés.

2.1 Authentification à un seul facteur

Cette forme d’authentification est basée sur une seule information d’identification utilisateur. Il s’agit généralement d’un mot de passe, mais il peut également s’agir d’un numéro d’identification personnel (PIN).

Voici le processus d’authentification à un seul facteur.

L’utilisateur fournit son nom d’utilisateur et son mot de passe au fournisseur d’identité. Le fournisseur d’identité est le processus serveur qui vérifie l’identité de l’utilisateur.
Le fournisseur d’identité vérifie si le nom d’utilisateur et le mot de passe sont les mêmes que ceux stockés dans le système. Dans la plupart des cas, le mot de passe sera crypté, fournissant une sécurité supplémentaire afin que d’autres ne puissent pas le lire.
Le fournisseur d’identité renvoie un statut d’authentification qui indique si l’authentification a réussi.
En cas de succès, l’échange de données commence. En cas d’échec, l’utilisateur doit être ré-authentifié.

Authentification à facteur unique

Aujourd’hui, cette méthode d’authentification est la plus couramment utilisée à travers les divers services. C’est également la forme d’authentification la moins sécurisée lorsqu’elle est utilisée comme seul moyen d’authentification. Les exigences de complexité des mots de passe, les « questions secrètes » et les changements réguliers de mot de passe peuvent rendre l’utilisation des mots de passe plus sécurisée, mais ils imposent plus de contraintes aux utilisateurs et ne constituent pas un moyen efficace de dissuasion contre les hackers.

Le défi avec les mots de passe est qu’il est plus facile de les deviner avec succès que les systèmes qui ont plus d’un facteur. S’ils volent une base de données avec des comptes utilisateur et des mots de passe hachés d’une petite boutique en ligne, ils peuvent utiliser les mots de passe utilisés sur d’autres sites web. Les utilisateurs ont tendance à réutiliser des comptes tout le temps, car les mots de passe complexes sont difficiles à mémoriser. Pour un service informatique, la gestion des mots de passe entraîne également la complexité de devoir offrir des mécanismes de réinitialisation, exigeant des mises à jour fréquentes des mots de passe et de les stocker de manière sécurisée.

Malgré tous ses inconvénients, l’authentification à un seul facteur donne à l’utilisateur le contrôle de l’identifiant. Ils le créent et le modifient, et seul un clavier est nécessaire pour le processus d’authentification. C’est le principal aspect de distinction entre l’authentification à un seul facteur et l’authentification à plusieurs facteurs.

2.1.1 Service Broker d’authentification web

Comme évoqué précédemment, l’un des défis de l’authentification par mot de passe pour un service informatique est le surcroît de gestion de la base de données des noms d’utilisateur/mots de passe, des mécanismes de réinitialisation, etc. Une option de plus en plus populaire est de s’appuyer sur des fournisseurs d’identité tiers qui offrent l’authentification via OAuth, une norme ouverte pour l’authentification.

En utilisant OAuth, les services informatiques peuvent « externaliser » efficacement la complexité de la maintenance d’une base de données avec des noms d’utilisateur et des mots de passe, des fonctionnalités de réinitialisation de mot de passe, etc. à un fournisseur d’identité tiers comme Facebook, X ou Microsoft.

Les utilisateurs ont un contrôle total sur leur identité sur ces plate-formes, mais les applications peuvent demander un jeton au fournisseur, après que l’utilisateur soit authentifié et avec son consentement, qui peut être utilisé pour autoriser les utilisateurs authentifiés.

Le répartiteur d’authentification web dans Windows fournit un ensemble d’API et d’infrastructure pour que les applications utilisent des protocoles d’authentification et d’autorisation tels que OAuth et OpenID. Les applications peuvent initier des opérations d’authentification via l’API WebAuthenticationBroker, ce qui entraîne le retour d’un WebAuthenticationResult. Une vue d’ensemble du flux de communication est illustrée dans la figure suivante.

flux de travail wab

L’application agit en tant que courtier, initiant l’authentification avec le fournisseur d’identité via un WebView dans l’application. Lorsque le fournisseur d’identité a authentifié l’utilisateur, il renvoie un jeton à l’application qui peut être utilisé pour demander des informations sur l’utilisateur auprès du fournisseur d’identité. Par mesure de sécurité, l’application doit être enregistrée auprès du fournisseur d’identité avant de pouvoir servir d’intermédiaire dans les processus d’authentification avec le fournisseur d’identité. Cette procédure d’enregistrement est différente pour chaque fournisseur.

Voici le flux de travail général pour appeler l’API WebAuthenticationBroker pour communiquer avec le fournisseur.

Construire les chaînes de demande à envoyer au fournisseur d’identité. Le nombre de chaînes et les informations contenues dans chaque chaîne sont différents pour chaque service web mais cela inclut généralement deux chaînes URI contenant chacune une URL : une à laquelle la demande d’authentification est envoyée, et une à laquelle l’utilisateur est redirigé après l’autorisation est terminée.
Appeler WebAuthenticationBroker.AuthenticateAsync, en passant les chaînes de demande, et attendre la réponse du fournisseur d’identité.
Appeler WebAuthenticationResult.ResponseStatus pour obtenir le statut lorsque la réponse est reçue.
Si la communication est réussie, traiter la chaîne de réponse retournée par le fournisseur d’identité. En cas d’échec, traiter l’erreur.

Si la communication est réussie, traiter la chaîne de réponse retournée par le fournisseur d’identité. En cas d’échec, traiter l’erreur.

Vous trouverez ci-dessous un exemple de code C# d’exemple pour ce processus. Pour des informations et une explication détaillée, voir WebAuthenticationBroker. Pour un exemple de code complet, consultez l’échantillon WebAuthenticationBroker sur GitHub.

string startURL = "https://<providerendpoint>?client_id=<clientid>";
string endURL = "http://<AppEndPoint>";

var startURI = new System.Uri(startURL);
var endURI = new System.Uri(endURL);

try
{
    WebAuthenticationResult webAuthenticationResult = 
        await WebAuthenticationBroker.AuthenticateAsync( 
            WebAuthenticationOptions.None, startURI, endURI);

    switch (webAuthenticationResult.ResponseStatus)
    {
        case WebAuthenticationStatus.Success:
            // Successful authentication. 
            break;
        case WebAuthenticationStatus.ErrorHttp:
            // HTTP error. 
            break;
        default:
            // Other error.
        break;
    }
}
catch (Exception ex)
{
    // Authentication failed. Handle parameter, SSL/TLS, and
    // Network Unavailable errors here. 
}

2.2 Authentification multi-facteur

L’authentification multi-facteur utilise plusieurs facteurs d’authentification. En règle générale, il s’agit de « quelque chose que vous connaissez », comme un mot de passe, combiné à « quelque chose que vous possédez », comme un téléphone portable ou une carte à puce. Même si un agresseur découvre le mot de passe de l’utilisateur, le compte est toujours inaccessible sans l’appareil ou la carte. Et si seul l’appareil (ou la carte) est compromis, l’agresseur ne peut rien en faire sans le mot de passe. L’authentification multi-facteur est donc plus sécurisée, mais également plus complexe que l’authentification à facteur unique.

Les services qui utilisent l’authentification multi-facteur donnent souvent à l’utilisateur le choix concernant la façon dont il reçoit les deuxième informations d’identification. Ce type d’authentification est par exemple un processus couramment utilisé dans lequel un code de vérification est envoyé au téléphone mobile de l’utilisateur à l’aide de SMS.

L’utilisateur fournit son nom d’utilisateur et son mot de passe au fournisseur d’identité.
Le fournisseur d’identité vérifie le nom d’utilisateur et le mot de passe comme dans l’autorisation à facteur unique, puis recherche le numéro de téléphone mobile de l’utilisateur stocké dans le système.
Le serveur envoie un sms contenant un code de vérification généré sur le téléphone portable de l’utilisateur.
L’utilisateur fournit le code de vérification au fournisseur d’identité ; par le biais d’un formulaire présenté à l’utilisateur.
Le fournisseur d’identité retourne un état d’authentification qui indique si l’authentification des deux informations d’identification a réussi.
En cas de succès, l’échange de données commence. Sinon, l’utilisateur doit être ré-authentifié.

authentification à deux facteurs

Comme vous pouvez le voir, ce processus diffère également de l’authentification à facteur unique dans lequel les informations d’identification du deuxième utilisateur sont envoyées à l’utilisateur au lieu d’être créées ou fournies par l’utilisateur. L’utilisateur n’a donc pas le contrôle complet des informations d’identification nécessaires. Cela s’applique également lorsqu’une carte à puce est utilisée comme deuxième biais d’identification : l’organisation est chargée de la créer et de la fournir à l’utilisateur.

2.2.1 Azure Active Directory

Azure Active Directory (Azure AD) est un service de gestion des identités et des accès basé sur le cloud qui peut servir de fournisseur d’identité dans l’authentification à un seul facteur ou multi-facteur. L’authentification Azure AD peut être utilisée avec ou sans code de vérification.

Bien qu’Azure AD puisse également mettre en œuvre l’authentification à facteur unique, les entreprises nécessitent généralement la sécurité plus élevée de l’authentification multi-facteur. Dans une configuration d’authentification à plusieurs facteurs, un utilisateur s’authentifiant avec un compte Azure AD a la possibilité de recevoir un code de vérification envoyé sous forme de message SMS soit sur son téléphone portable, soit via l’application mobile Azure Authenticator.

De plus, Azure AD peut être utilisé en tant que fournisseur OAuth, fournissant à l’utilisateur standard un mécanisme d’authentification et d’autorisation pour les applications sur différentes plate-formes. Pour en savoir plus, veuillez consulter la rubrique Azure Active Directory et l’authentification multi-facteur sur Azure.

2.4 Windows Hello

Dans Windows, un mécanisme d’authentification multifacteur pratique est intégré au système d’exploitation. Windows Hello est le nouveau système de connexion biométrique intégré à Windows. Parce qu’il est intégré directement dans le système d’exploitation, Windows Hello permet l’identification par reconnaissance faciale ou empreinte digitale pour déverrouiller les appareils des utilisateurs. Le magasin de certificats sécurisé de Windows protège les données biométriques sur l’appareil.

Windows Hello offre un moyen robuste pour qu’un appareil reconnaisse un utilisateur individuel, ce qui répond à la première partie du chemin entre un utilisateur et un service ou un élément de données demandé. Après que l’appareil ait reconnu l’utilisateur, il doit encore authentifier l’utilisateur avant de déterminer s’il doit accorder l’accès à une ressource demandée. Windows Hello fournit également une authentification forte à deux facteurs (2FA) entièrement intégrée à Windows et remplace les mots de passe réutilisables par la combinaison d’un appareil spécifique et d’un geste biométrique ou d’un PIN. Le PIN est spécifié par l’utilisateur dans le cadre de son inscription au compte Microsoft.

Windows Hello n’est pas seulement un remplacement pour les systèmes d’authentification à deux facteurs traditionnels. Il est conçu de façon similaire aux cartes à puce : l’authentification est effectuée en utilisant des primitives cryptographiques au lieu de comparaisons de chaînes, et le matériel clé de l’utilisateur est sécurisé à l’intérieur d’un matériel résistant aux manipulations. Microsoft Hello ne nécessite pas non plus les composants d’infrastructure supplémentaires nécessaires au déploiement de cartes à puce. Vous n’avez notamment pas besoin d’une infrastructure à clé publique (PKI) pour gérer les certificats, si vous n’en avez pas actuellement. Windows Hello combine les principaux avantages des cartes à puce : la flexibilité de déploiement pour les cartes à puce virtuelles et la sécurité robuste pour les cartes à puce physiques, et cela sans aucun de leurs inconvénients.

Un appareil doit être enregistré auprès de Windows Hello avant que les utilisateurs puissent s’authentifier avec celui-ci. Windows Hello utilise le chiffrement asymétrique (clé publique/privée) dans lequel une partie utilise une clé publique pour chiffrer les données que l’autre partie peut déchiffrer en utilisant une clé privée. Dans le cas de Windows Hello, il crée un ensemble de paires de clés publique/privée et écrit les clés privées dans la puce TPM (Trusted Platform Module) de l’appareil. Après qu’un appareil ait été enregistré, les applications UWP peuvent appeler les API système pour récupérer la clé publique de l’utilisateur, qui peut être utilisée pour enregistrer l’utilisateur sur le serveur.

Le flux de travail d’enregistrement d’une application pourrait ressembler à ceci :

Windows Hello Registration

Les informations d’enregistrement que vous collectez peuvent inclure beaucoup plus d’informations d’identification que dans ce scénario simple. Par exemple, si votre application accède à un service sécurisé tel qu’un service bancaire, vous devrez demander une preuve d’identité ainsi que d’autres éléments dans le cadre du processus d’inscription. Une fois que toutes les conditions sont remplies, la clé publique de cet utilisateur sera stockée dans le back-end et utilisée pour valider la prochaine fois que l’utilisateur utilisera le service.

Pour plus d’informations sur Windows Hello, consultez la vue d’ensemble Windows Hello Entreprise et le guide du développeur Windows Hello.

3 Méthodes de sécurité des données en transit

Les méthodes de sécurité des données en transit s’appliquent aux données en cours de transfert entre des appareils connectés à un réseau. Les données peuvent être transférées entre des systèmes dans l’environnement hautement sécurisé d’un intranet d’entreprise privé, ou entre un client et un service web dans l’environnement non sécurisé du web. Les applications Windows prennent en charge des normes telles que SSL via leurs API de mise en réseau et fonctionnent avec des technologies telles qu’Azure Gestion des API avec lesquelles les développeurs peuvent garantir le niveau de sécurité approprié pour leurs applications.

3.1 Authentification d’un système distant

Il existe deux scénarios génériques où la communication s’effectue avec un système informatique distant.

Un serveur local authentifie un utilisateur via une connexion directe. Par exemple, lorsque le serveur et le client se trouvent sur un intranet d’entreprise.
Un service web communique sur Internet.

Les exigences de sécurité pour la communication avec les services web sont plus élevées que dans les scénarios de connexion directe, car les données ne font plus uniquement partie d’un réseau sécurisé et la probabilité que des attaquants malveillants cherchent à intercepter les données est également plus élevée. Étant donné que différents types d’appareils accéderont au service, ils seront probablement construits comme des services RESTful, par opposition à WCF par exemple, ce qui signifie que l’authentification et l’autorisation du service posent également de nouvelles difficultés. Nous discuterons de deux exigences pour la communication sécurisée avec des systèmes distants.

La première exigence est la confidentialité des messages : les informations échangées entre le client et les services web (par exemple, l’identité de l’utilisateur et d’autres informations personnelles) ne doivent pas être lisibles par des tiers pendant le transit. Cela est généralement accompli en chiffrant la connexion sur laquelle les messages sont envoyés et en chiffrant le message lui-même. Dans le chiffrement par clé publique/privée, la clé publique est disponible pour tout le monde et est utilisée pour chiffrer les messages à envoyer à un destinataire spécifique. La clé privée est uniquement détenue par le destinataire et est utilisée pour déchiffrer le message.

La deuxième exigence est l’intégrité des messages : le client et le service web doivent être en mesure de vérifier que les messages qu’ils reçoivent sont ceux qui sont censés être envoyés par l’autre partie, et que le message n’a pas été altéré en transit. Cela est accompli en signant les messages avec des signatures numériques et en utilisant une authentification par certificat.

3.2 Connexions SSL

Pour établir et maintenir des connexions sécurisées avec les clients, les services web peuvent utiliser le protocole Secure Sockets Layer (SSL), qui est pris en charge par le protocole Secure Hypertext Transfer Protocol (HTTPS). SSL assure la confidentialité et l’intégrité des messages en prenant en charge le chiffrement à clé publique ainsi que les certificats de serveur. SSL est remplacé par le protocole Transport Layer Security (TLS), mais TLS est souvent désigné de manière informelle comme SSL.

Lorsqu’un client demande l’accès à une ressource sur un serveur, SSL entame un processus de négociation avec le serveur. Cela s’appelle une négociation SSL (SSL handshake). Un niveau de chiffrement, un ensemble de clés de chiffrement publiques et privées, ainsi que les informations d’identité dans les certificats client et serveur sont convenus comme base de toute communication pour la durée de la connexion SSL. Le serveur peut également exiger que le client soit authentifié à ce moment-là. Une fois que la connexion est établie, tous les messages sont chiffrés avec la clé publique négociée jusqu’à ce que la connexion se ferme.

3.2.1 Épinglage SSL (SSL pinning)

Bien que SSL puisse assurer la confidentialité des messages en utilisant le chiffrement et les certificats, il ne vérifie pas que le serveur avec lequel le client communique est le bon. Le comportement du serveur peut être imité par un tiers non autorisé, interceptant les données sensibles que le client transmet. Pour prévenir cela, une technique appelée épinglage SSL est utilisée pour vérifier que le certificat sur le serveur est le certificat que le client attend et en qui il a confiance.

Il existe plusieurs façons de mettre en œuvre l’épinglage SSL dans les applications, chacune avec ses avantages et ses inconvénients. L’approche la plus simple passe par la déclaration de certificats dans le manifeste de package de l’application. Cette déclaration permet au package de l’application d’installer des certificats numériques et de spécifier une confiance exclusive en eux. Cela permet des connexions SSL uniquement entre l’application et les serveurs qui possèdent les certificats correspondants dans leur chaîne de certificats. Ce mécanisme permet également l’utilisation sécurisée de certificats auto-signés, car aucune dépendance à des tiers n’est nécessaire vis-à-vis des autorités de certification publiques de confiance.

manifeste ssl

Pour plus de contrôle sur la logique de validation, des API sont disponibles pour valider le(s) certificat(s) renvoyé(s) par le serveur en réponse à une requête HTTPS. Notez que cette méthode nécessite l’envoi d’une requête et l’inspection de la réponse, alors assurez-vous de l’ajouter comme validation avant d’envoyer réellement des informations sensibles dans une requête.

Le code C# suivant illustre cette méthode d’épinglage SSL. La méthode ValidateSSLRoot utilise la classe HttpClient pour exécuter une requête HTTP. Après que le client ait envoyé la réponse, il utilise la collection RequestMessage.TransportInformation.ServerIntermediateCertificates pour inspecter les certificats renvoyés par le serveur. Le client peut ensuite valider l’ensemble de la chaîne de certificats avec les empreintes digitales qu’il a incluses. Cette méthode nécessite que les empreintes digitales des certificats soient mises à jour dans l’application lorsque le certificat serveur expire et est renouvelé.

private async Task ValidateSSLRoot()
{
    // Send a get request to Bing
    var httpClient = new HttpClient();
    var bingUri = new Uri("https://www.bing.com");
    HttpResponseMessage response = 
        await httpClient.GetAsync(bingUri);

    // Get the list of certificates that were used to
    // validate the server's identity
    IReadOnlyList<Certificate> serverCertificates = response.RequestMessage.TransportInformation.ServerIntermediateCertificates;
  
    // Perform validation
    if (!ValidateCertificates(serverCertificates))
    {
        // Close connection as chain is not valid
        return;
    }
    // Validation passed, continue with connection to service
}

private bool ValidateCertificates(IReadOnlyList<Certificate> certs)
{
    // In this example, we iterate through the certificates
    // and check that the chain contains
    // one specific certificate we are expecting
    foreach (var cert in certs)
    {
        byte[] thumbprint = cert.GetHashValue();

        // Check if the thumbprint matches whatever you 
        // are expecting
        var expected = new byte[] { 212, 222, 32, 208, 94, 102, 
            252, 83, 254, 26, 80, 136, 44, 120, 219, 40, 82, 202, 
            228, 116 };

        // ThumbprintMatches does the byte[] comparison 
        if (ThumbprintMatches(thumbprint, expected))
        {
            return true;
        }
    }
    return false;
}

3.3 Publication et sécurisation de l’accès aux API REST

Pour garantir un accès autorisé aux services web, ceux-ci doivent exiger une authentification à chaque appel d’API. La capacité à contrôler les performances et l’échelle est également quelque chose à prendre en compte lorsque les services web sont exposés sur le web. Azure API Management est un service qui peut aider à exposer les API sur le web, tout en offrant des fonctionnalités sur trois niveaux.

Les Éditeurs/Administrateurs de l’API peuvent facilement configurer l’API via le Portail Éditeur de Azure API Management. Ici, des ensembles d’API peuvent être créés et l’accès à ceux-ci peut être géré pour contrôler qui a accès à quelles APIs.

Les développeurs souhaitant accéder à ces APIs peuvent faire des demandes via le Portail Développeur, qui peut soit fournir immédiatement l’accès, soit exiger une approbation par l’éditeur/administrateur. Les développeurs peuvent également consulter la documentation de l’API et le code d’exemple dans le Portail Développeur, pour adopter rapidement les APIs proposées par le service web.

Les applications que ces développeurs créent accèdent ensuite à l’API via le proxy offert par Azure API Management. Le proxy fournit à la fois une couche d’obscurité, cachant le véritable point de terminaison de l’API sur le serveur de l’éditeur/administrateur, et peut également inclure une logique supplémentaire comme la traduction d’API pour garantir que l’API exposée reste cohérente lorsqu’un appel à une API est redirigé vers une autre. Il peut également utiliser un filtrage IP pour bloquer les appels d’API provenant d’un domaine IP spécifique ou d’un ensemble de domaines. Azure API Management sécurise également ses services web en utilisant un ensemble de clés publiques, appelées clés API, pour authentifier et autoriser chaque appel d’API. Lorsque l’autorisation échoue, l’accès à l’API et aux fonctionnalités qu’elle prend en charge est bloqué.

Azure API Management peut également réduire le nombre d’appels d’API à un service (une procédure appelée lissage) pour optimiser les performances du service web. Pour en savoir plus, veuillez consulter les sections Azure API Management et Azure API Management lors de l’AzureCon 2015.

4 Méthodes de sécurité des données au repos

Lorsque les données arrivent sur un appareil, nous les qualifions de « données au repos ». Ces données doivent être stockées sur l’appareil de manière sécurisée, de sorte qu’elles ne puissent pas être accessibles par des utilisateurs ou des applications non autorisés. Le modèle d’application dans Windows fait beaucoup pour s’assurer que les données stockées par n’importe quelle application sont uniquement accessibles à cette application, tout en fournissant des API pour partager les données si nécessaire. Des API supplémentaires sont également disponibles pour garantir que les données peuvent être chiffrées et que les informations d’identification peuvent être stockées en toute sécurité.

4.1 Modèle d’application Windows

Traditionnellement, Windows n’a jamais eu de définition d’une application. Il était le plus souvent désigné sous le nom de fichier exécutable (.exe), et cela n’incluait jamais l’installation, le stockage de l’état, la durée d’exécution, la version, l’intégration à l’OS ou la communication entre applications. Le modèle Universal Windows Platform définit un modèle d’application qui couvre l’installation, l’environnement d’exécution, la gestion des ressources, les mises à jour, le modèle de données et la désinstallation.

Les applications Windows 10 s’exécutent dans un conteneur, ce qui signifie qu’elles ont par défaut des privilèges limités (des privilèges supplémentaires peuvent être demandés et accordés par l’utilisateur). Par exemple, si une application souhaite accéder à des fichiers sur le système, un sélecteur de fichiers de l’espace de noms Windows.Storage.Pickers doit être utilisé pour permettre à l’utilisateur de choisir un fichier (l’accès direct aux fichiers n’est pas autorisé). Un autre exemple est si une application souhaite accéder aux données de localisation de l’utilisateur, elle doit activer la fonctionnalité du périphérique de localisation, ce qui amène l’utilisateur, au moment du téléchargement, à autoriser cette application à demander l’accès à sa localisation. De plus, la première fois que l’application souhaite accéder à la localisation de l’utilisateur, une boîte de dialogue de consentement supplémentaire est affichée à l’utilisateur, demandant la permission d’accéder aux données.

Notez que ce modèle d’application agit comme une « prison » pour les applications, ce qui signifie qu’elles ne peuvent pas s’étendre, mais ce n’est pas un " château " qui ne peut pas être atteint depuis l’extérieur (les applications avec des privilèges administrateur peuvent bien sûr encore y accéder). Device Guard dans Windows, qui permet aux organisations/informatiques de spécifier les applications (Win32) autorisées à s’exécuter, peut aider à limiter davantage cet accès.

Le modèle d’application gère également le cycle de vie de l’application. Par exemple, il limite l’exécution en arrière-plan des applications par défaut; dès qu’une application passe en arrière-plan, le processus est suspendu (après avoir donné à l’application une brève période pour traiter la suspension de l’application dans le code) et sa mémoire est figée. Le système d’exploitation fournit également des mécanismes permettant aux applications de demander l’exécution de tâches en arrière-plan spécifiques (sur un calendrier, déclenchées par divers événements tels que la connectivité Internet/Bluetooth, les changements de puissance, etc., et dans des scénarios spécifiques tels que la lecture de musique ou le suivi GPS).

Lorsque les ressources mémoire sur l’appareil sont faibles, Windows libère de l’espace mémoire en terminant les applications. Ce modèle de cycle de vie oblige les applications à persister les données chaque fois qu’elles sont suspendues, car il n’y a pas de temps supplémentaire disponible entre la suspension et la terminaison.

Pour plus d’informations, veuillez consulter la rubrique Comprendre le cycle de vie d’une application Windows 10/11.

4.2 Protection des informations d’identification stockées

Les applications Windows qui accèdent à des services authentifiés proposent souvent aux utilisateurs l’option de stocker leurs informations d’identification sur l’appareil local. Ceci est pratique pour les utilisateurs ; lorsqu’ils fournissent leur nom d’utilisateur et leur mot de passe, l’application les utilise automatiquement lors des lancements ultérieurs de l’application. Étant donné qu’il peut s’agir d’un problème de sécurité si un attaquant obtient l’accès à ces données stockées, Windows permet aux applications empaquetées de stocker les informations d’identification utilisateur dans un casier d’informations d’identification sécurisé. L’application appelle l’API du coffre-fort des informations d’identification pour stocker et récupérer les informations d’identification du coffre-fort au lieu de les stocker dans le conteneur de stockage de l’application. Le coffre-fort des informations d’identification est géré par le système d’exploitation, mais l’accès est limité à l’application qui les stocke, offrant ainsi une solution de stockage sécurisée pour les informations d’identification.

Lorsqu’un utilisateur fournit les informations d’identification à stocker, l’application obtient une référence vers le coffre-fort des informations d’identification en utilisant l’objet PasswordVault dans l’espace de noms Windows.Security.Credentials. Ensuite, elle crée un objet PasswordCredential contenant un identifiant pour l’application Windows ainsi que le nom d’utilisateur et le mot de passe. Cela est passé à la méthode PasswordVault.Add pour stocker les informations d’identification dans le coffre-fort. L’exemple de code C# suivant montre comment faire cela.

var vault = new PasswordVault();
vault.Add(new PasswordCredential("My App", username, password));

Dans l’exemple de code C# suivant, l’application demande toutes les informations d’identification correspondant à l’application en appelant la méthode FindAllByResource de l’objet PasswordVault. Si plus d’une est renvoyée, elle demande à l’utilisateur de saisir son nom d’utilisateur. Si les informations d’identification ne sont pas dans le coffre-fort, l’application demande à l’utilisateur de les fournir. L’utilisateur est ensuite connecté au serveur en utilisant les informations d’identification.

private string resourceName = "My App";
private string defaultUserName;

private void Login()
{
    PasswordCredential loginCredential = GetCredentialFromLocker();

    if (loginCredential != null)
    {
        // There is a credential stored in the locker.
        // Populate the Password property of the credential
        // for automatic login.
        loginCredential.RetrievePassword();
    }
    else
    {
        // There is no credential stored in the locker.
        // Display UI to get user credentials.
        loginCredential = GetLoginCredentialUI();
    }
    // Log the user in.
    ServerLogin(loginCredential.UserName, loginCredential.Password);
}

private PasswordCredential GetCredentialFromLocker()
{
    PasswordCredential credential = null;

    var vault = new PasswordVault();

    IReadOnlyList<PasswordCredential> credentialList = null;

    try
    {
        credentialList = vault.FindAllByResource(resourceName);
    }
    catch(Exception)
    {
        return null;
    }

    if (credentialList.Count == 1)
    {
        credential = credentialList[0];
    }
    else if (credentialList.Count > 0)
    {
        // When there are multiple usernames,
        // retrieve the default username. If one doesn't
        // exist, then display UI to have the user select
        // a default username.
        defaultUserName = GetDefaultUserNameUI();

        credential = vault.Retrieve(resourceName, defaultUserName);
    }
    return credential;
}

Pour plus d’informations, veuillez consulter la rubrique coffre-fort des informations d’identification.

4.3 Protection des données stockées

Lorsque vous travaillez avec des données stockées, communément appelées données au repos, les crypter peut empêcher les utilisateurs non autorisés d’accéder aux données stockées. Les deux mécanismes courants pour crypter les données sont l’utilisation de clés symétriques ou l’utilisation de clés asymétriques. Cependant, le chiffrement des données ne peut pas garantir que les données n’ont pas été altérées entre le moment où elles ont été envoyées et le moment où elles ont été stockées. En d’autres termes, l’intégrité des données ne peut pas être assurée. L’utilisation de codes d’authentification de message, de hachages et de signatures numériques sont des techniques courantes pour résoudre ce problème.

4.3.1 Cryptage des données

Avec le cryptage symétrique, l’expéditeur et le destinataire utilisent la même clé pour à la fois chiffrer et déchiffrer les données. Le défi avec cette approche est de partager la clé de manière sécurisée afin que les deux parties en soient conscientes.

Une réponse à cela est le cryptage asymétrique, dans lequel une paire de clés publique/privée est utilisée. La clé publique est partagée librement avec quiconque souhaite chiffrer un message. La clé privée est toujours gardée secrète afin que vous seul puissiez l’utiliser pour déchiffrer les données. Une technique courante pour permettre la découverte de la clé publique est l’utilisation de certificats numériques, également simplement appelés certificats. Le certificat contient des informations sur la clé publique, ainsi que des informations sur l’utilisateur ou le serveur telles que le nom, l’émetteur, l’adresse e-mail et le pays.

Les développeurs d’applications Windows peuvent utiliser les classes SymmetricKeyAlgorithmProvider et AsymmetricKeyAlgorithmProvider pour mettre en œuvre le cryptage symétrique et asymétrique dans leurs applications UWP. De plus, la classe CryptographicEngine peut être utilisée pour chiffrer et déchiffrer des données, signer du contenu et vérifier des signatures numériques. Les applications peuvent également utiliser la classe DataProtectionProvider dans l’espace de noms Windows.Security.Cryptography.DataProtection pour chiffrer et déchiffrer des données locales stockées.

4.3.2 Détection de manipulation des messages (MACs, hachages et signatures)

Un MAC est un code (ou une balise) résultant de l’utilisation d’une clé symétrique (appelée clé secrète) ou d’un message en entrée dans un algorithme de chiffrement MAC. La clé secrète et l’algorithme sont convenus par l’expéditeur et le destinataire avant le transfert du message.

Les MAC vérifient les messages de cette manière.

L’expéditeur dérive la balise MAC en utilisant la clé secrète comme entrée dans l’algorithme MAC.
L’expéditeur envoie la balise MAC et le message au destinataire.
Le destinataire dérive la balise MAC en utilisant la clé secrète et le message comme entrées dans l’algorithme MAC.
Le destinataire compare sa balise MAC avec celle de l’expéditeur. Si elles sont identiques, alors nous savons que le message n’a pas été altéré.

vérification mac

Les applications Windows peuvent implémenter la vérification de message MAC en appelant la classe MacAlgorithmProvider pour générer la clé et la classe CryptographicEngine pour effectuer l’algorithme de chiffrement MAC.

4.3.3 Utilisation des hachages

Une fonction de hachage est un algorithme cryptographique qui prend un bloc de données de longueur arbitraire et renvoie une chaîne de bits de taille fixe appelée valeur de hachage. Il existe toute une famille de fonctions de hachage qui peuvent faire cela.

Une valeur de hachage peut être utilisée à la place d’un MAC dans le scénario de transfert de message décrit ci-dessus. L’expéditeur envoie une valeur de hachage et un message, et le destinataire dérive sa propre valeur de hachage de la valeur de hachage et du message de l’expéditeur, puis compare les deux valeurs de hachage. Les applications s’exécutant sur Windows peuvent appeler la classe HashAlgorithmProvider pour énumérer les algorithmes de hachage disponibles et exécuter l’un d’eux. La classe CryptographicHash représente la valeur de hachage. La méthode CryptographicHash.GetValueAndReset peut être utilisée pour hacher plusieurs fois des données différentes sans avoir à recréer l’objet à chaque utilisation. La méthode Append de la classe CryptographicHash ajoute de nouvelles données à un tampon à hacher. Tout ce processus est illustré dans l’exemple de code C# suivant.

public void SampleReusableHash()
{
    // Create a string that contains the name of the
    // hashing algorithm to use.
    string strAlgName = HashAlgorithmNames.Sha512;

    // Create a HashAlgorithmProvider object.
    HashAlgorithmProvider objAlgProv = HashAlgorithmProvider.OpenAlgorithm(strAlgName);

    // Create a CryptographicHash object. This object can be reused to continually
    // hash new messages.
    CryptographicHash objHash = objAlgProv.CreateHash();

    // Hash message 1.
    string strMsg1 = "This is message 1";
    IBuffer buffMsg1 = CryptographicBuffer.ConvertStringToBinary(strMsg1, BinaryStringEncoding.Utf16BE);
    objHash.Append(buffMsg1);
    IBuffer buffHash1 = objHash.GetValueAndReset();

    // Hash message 2.
    string strMsg2 = "This is message 2";
    IBuffer buffMsg2 = CryptographicBuffer.ConvertStringToBinary(strMsg2, BinaryStringEncoding.Utf16BE);
    objHash.Append(buffMsg2);
    IBuffer buffHash2 = objHash.GetValueAndReset();

    // Convert the hashes to string values (for display);
    string strHash1 = CryptographicBuffer.EncodeToBase64String(buffHash1);
    string strHash2 = CryptographicBuffer.EncodeToBase64String(buffHash2);
}

4.3.4 Signatures numériques

L’intégrité des données d’un message stocké signé numériquement est vérifiée de manière similaire à l’authentification MAC. Voici comment fonctionne le flux de travail de la signature numérique.

L’expéditeur dérive une valeur de hachage (également appelée code de hachage) en utilisant le message comme entrée pour un algorithme de hachage.
L’expéditeur chiffre le code hachage en utilisant sa clé privée.
L’expéditeur envoie le message, le condensé chiffré et le nom de l’algorithme de hachage utilisé.
Le destinataire utilise la clé publique pour déchiffrer le code de hachage chiffré qu’il a reçu. Il utilise ensuite l’algorithme de hachage pour hacher le message et créer son propre condensé. Enfin, le destinataire compare les deux codes de hachage (celui qu’il a reçu et déchiffré, et celui qu’il a créé). Ce n’est que si les deux correspondent que le destinataire peut être sûr que le message a été envoyé par le détenteur de la clé privée, et donc qu’il est bien celui qu’il prétend être, et que le message n’a pas été altéré en transit.

signatures numériques

Les algorithmes de hachage sont très rapides, donc les valeurs de hachage peuvent être dérivées rapidement même à partir de messages volumineux. La valeur de hachage résultante a une longueur arbitraire et peut être plus courte que le message complet, donc l’utilisation de clés publiques et privées pour chiffrer et déchiffrer uniquement le condensé plutôt que le message complet est une optimisation.

Pour plus d’informations, consultez les articles sur les signatures numériques, les MACs, hachages et signatures, et la cryptographie.

5 Résumé

Le plateforme Windows universelle dans Windows offre plusieurs façons de tirer parti des fonctionnalités du système d’exploitation pour créer des applications plus sécurisées. Dans différents scénarios d’authentification, tels que l’authentification à facteur unique, à facteurs multiples, ou avec un fournisseur d’identité OAuth, des API existent pour atténuer les défis les plus courants de l’authentification. Windows Hello fournit un nouveau système de connexion biométrique qui reconnaît l’utilisateur et contrecarre activement les tentatives de contourner une identification correcte. Il fournit également plusieurs couches de clés et de certificats qui ne peuvent jamais être révélés ou utilisés en dehors du module de plate-forme de confiance. De plus, une autre couche de sécurité est disponible grâce à l’utilisation facultative de clés et de certificats d’identité d’attestation.

Pour sécuriser les données en transit, des API existent pour communiquer avec des systèmes distants de manière sécurisée via SSL, tout en permettant de valider l’authenticité du serveur avec l’épinglage SSL. La publication sécurisée et contrôlée des API est facilitée par Azure API Management, qui propose de puissantes options de configuration pour exposer les API sur le web à l’aide d’un proxy qui offre une obfuscation supplémentaire du point de terminaison de l’API. L’accès à ces API est sécurisé en utilisant des clés API et les appels d’API peuvent être limités pour contrôler les performances.

Lorsque les données arrivent sur l’appareil, le modèle d’application Windows offre un plus grand contrôle sur la manière dont l’application est installée, mise à jour et accède à ses données, tout en l’empêchant d’accéder aux données d’autres applications de manière non autorisée. Le gestionnaire de références d’informations d’identification peut fournir un stockage sécurisé des informations d’identification utilisateur géré par le système d’exploitation et d’autres données peuvent être protégées sur l’appareil en utilisant les API de chiffrement et de hachage offertes par la Plateforme Universelle Windows.

Partager via