Zero Trust

Sécurité

• 1. Connaissez votre architecture, y compris les utilisateurs, les appareils, les services et les données

  Dans le modèle de réseau Zero Trust, il est plus important que jamais de connaître vos utilisateurs, vos appareils, vos services et vos données

  Afin de bénéficier des avantages du Zero Trust, vous devez connaître chaque composant de votre architecture, y compris vos utilisateurs, vos appareils, ainsi que les services et données auxquels ils accèdent.

  Une bonne compréhension de vos actifs impliquera très probablement une phase de découverte des actifs comme l'une des premières étapes de votre parcours Zero Trust. Dans certains environnements, cela peut être difficile et peut impliquer l'utilisation d'outils automatisés pour découvrir les actifs sur le réseau. Dans d'autres cas, vous pourrez peut-être déterminer vos actifs en suivant une procédure non technique, comme l'interrogation des dossiers d'approvisionnement.

  Il est également important de savoir quelles données sont stockées dans votre environnement, leur emplacement et leur sensibilité. Connaître vos données et leur sensibilité associée vous aidera à développer des politiques d'accès efficaces et appropriées qui vous aideront à atteindre l'objectif.

• Transition vers le zéro confiance

  La découverte d’actifs est d’une importance égale, que vous passiez d’un système établi avec de nombreux services préexistants à une architecture Zero Trust ou que vous démarriez un tout nouveau déploiement architectural.

  Si une architecture Zero Trust est mise en œuvre sans tenir compte des services existants, ces derniers peuvent être exposés à des risques plus élevés. Ces services peuvent ne pas être conçus pour un réseau hostile et non fiable et ne seront donc pas en mesure de se défendre contre les attaques.

• Effectuer une évaluation des risques

  Une fois que vous connaissez votre architecture, vous êtes mieux placé pour déterminer les risques liés à votre nouvelle architecture cible et vous assurer qu’ils sont atténués.

  Après la phase de découverte des actifs, il serait judicieux de commencer par une évaluation des risques , notamment en modélisant les menaces de votre approche Zero Trust. Cette évaluation peut être utilisée pour vous aider à comprendre si les composants Zero Trust envisagés atténueront ou protégeront tous vos risques.

  Le degré d’atténuation des risques peut dépendre de la criticité des actifs et de votre appétence au risque. Il est donc impératif d’évaluer l’importance des actifs et de leur fournir les garanties appropriées.

  Si tous les risques ne peuvent pas être atténués à l’aide d’une approche Zero Trust, les contrôles de sécurité existants de votre architecture réseau actuelle devront rester en place.

• 2. Connaissez vos identités d'utilisateur, de service et d'appareil

  Lidentité de l'utilisateur, du service et de l'appareil est un facteur très important lors de la prise de décisions d'accès dans un réseau Zero Trust

  Une identité peut représenter un utilisateur (un être humain), un service (un processus logiciel) ou un appareil. Chacun d'entre eux doit être identifiable de manière unique et vérifiable par cryptographie dans une architecture Zero Trust. Il s'agit de l'un des facteurs les plus importants

  pour décider si une personne ou un objet doit avoir accès à des données ou à des services.

  Ces identités uniques font partie d'un certain nombre de signaux qui alimentent un moteur de politique, qui utilise ces informations pour prendre des décisions d'accès . Par exemple, un moteur de politique peut évaluer les signaux d'identité de l'utilisateur et de l'appareil pour déterminer si les deux sont authentiques, avant d'autoriser l'accès à un service ou à des données.

  Réaliser un exercice de découverte est une première étape importante vers l’attribution d’une source unique d’identité à vos utilisateurs, services et appareils.

• Identité de l'utilisateur

  Votre organisation doit utiliser un annuaire utilisateur définitif, en créant des comptes liés à des individus. Cela peut prendre la forme d'un annuaire virtuel ou d'une synchronisation d'annuaires, pour donner l'apparence d'un annuaire utilisateur unique.

  Chaque identité doit être associée à un rôle et celui-ci doit être configuré pour être « à privilèges minimes », de sorte qu'un utilisateur n'ait accès qu'à ce dont il a besoin pour remplir son rôle. En fait, ces privilèges découlent souvent de la fonction de l'utilisateur au sein d'une organisation.

  Lorsqu'il s'agit d'administrer les comptes d'utilisateurs et les accès privilégiés, nos conseils d'administration sécurisée constituent un bon point de départ.

• L'annuaire devra être compatible avec tous les services de l'architecture, quel que soit l'endroit d'où ils sont accessibles, afin de disposer d'une source unique d'identité et de connexion pour les utilisateurs. Cela permettra une meilleure expérience utilisateur, mais aussi une identité unique et forte pour tous les services.

• Un service d’identité utilisateur doit être capable de :

  Créer des groupes

  Définir les rôles qui ont été configurés pour bénéficier du « moindre privilège »

  Prend en charge des méthodes d'authentification fortes et modernes telles que l'authentification multifacteur ou sans mot de passe. Consultez nos conseils sur la politique d'authentification pour plus d'informations.

  Fournir en toute sécurité des informations d'identification aux utilisateurs

  Activer l'authentification fédérée pour les services (par exemple SAML 2.0, OAuth 2.0 ou OpenID Connect)

  Gérer les identités des utilisateurs dans les services externes, le cas échéant (par exemple SCIM 2.0)

  Soutenez vos processus d'adhésion, de déménagement et de départ

  Prise en charge des identifiants fédérés tiers (acceptant les identités provenant d'autres répertoires d'utilisateurs tiers de confiance)

• Migration

  Si vous disposez déjà d'un annuaire, la migration vers un autre annuaire nécessitera une planification minutieuse. Certains services d'annuaire vous permettent d'importer, de synchroniser ou de fédérer des annuaires, ce qui permet une migration par étapes ou, de manière efficace, de fournir un annuaire partagé.

• Accès externe

  Vous devez également réfléchir à la manière dont vous offrirez l'accès aux personnes extérieures à votre organisation. Vos services peuvent se fédérer avec des fournisseurs d'identité externes afin de permettre l'accès aux services et données appropriés. Par exemple, un visiteur peut voir le menu du déjeuner ou un sous-traitant peut uniquement accéder aux documents liés à son travail.

  L'identité et l'authentification sont un sujet vaste qui nécessite une réflexion approfondie. Le NCSC propose des orientations plus détaillées sur la gestion des identités et des accès et sur la politique d'authentification .

• Jetons de service

  Les services ne devraient pas avoir la possibilité d'effectuer des actions illimitées au nom des utilisateurs. Si un service comme celui-ci est compromis, il fournira un accès hautement privilégié à n'importe quel service ou à n'importe quelle donnée de votre système.

• Une meilleure façon de donner aux services un accès approprié consiste à lier chaque action à un jeton d'accès limité dans le temps et la portée, lié à l'identité de l'utilisateur. De cette façon, si le même service devait être compromis, le montant des dommages causés à votre service serait limité aux autorisations de l'action d'origine.

• Si un comportement anormal est détecté, le niveau de confiance des utilisateurs et des appareils évaluant un service ou des données se détériore. Une action corrective doit être déclenchée immédiatement, car le jeton est moins fiable que lorsqu'il a été émis en raison du changement de l'état de l'utilisateur ou de l'appareil. Voici quelques exemples de mesures correctives : mettre fin à la connexion ou déclencher une invite pour l'authentification multifacteur.

• Identité du service

  Un service (ou plus précisément le logiciel qui fournit un service) doit avoir sa propre identité unique et se voir accorder les privilèges minimaux nécessaires pour fonctionner correctement. Cela comprend la restriction de la communication réseau entre les services au minimum requis, en maintenant une liste d'autorisations de connexions, en fonction de l'identité du service.

  Une approche d'authentification par exemple pourrait impliquer un certificat unique pour chaque service. L'authentification par certificat peut ensuite être utilisée pour établir des connexions TLS (Transport Layer Security) mutuelles entre les processus logiciels qui composent un service.

  L'accès des utilisateurs à une application ou à une plateforme de conteneurs doit être fédéré dans un seul répertoire d'utilisateurs et utiliser un moteur de politique pour autoriser l'accès en fonction d'un certain nombre de signaux . Un moteur de politique peut prendre une décision d'accès et libérer un jeton si la politique est satisfaite.

• Identité de l'appareil

  Chaque appareil appartenant à votre organisation doit être identifiable de manière unique dans un répertoire d'appareils unique. Cela permet une gestion efficace des actifs et offre une visibilité claire des appareils qui accèdent à vos services et données.

  Les politiques Zero Trust que vous définissez utiliseront les déclarations de conformité et de santé d'un appareil pour prendre des décisions sur les données auxquelles il peut accéder et les actions qu'il peut effectuer. Une identité forte est nécessaire pour garantir que ces déclarations peuvent être validées.

  Le niveau de confiance auquel un appareil peut prouver son identité dépend du type d'appareil, du matériel et de la plateforme :

  L'utilisation d'un coprocesseur matériel sécurisé, tel qu'un TPM, vous permettra d'avoir une grande confiance dans l'identité de l'appareil. L'attestation de clé doit être utilisée dans la mesure du possible pour prouver que l'identité est protégée dans un coprocesseur matériel sécurisé.

  Sur un appareil bien géré, l’utilisation d’un magasin de clés basé sur un logiciel donne une confiance moindre dans l’identité de l’appareil qu’une approche basée sur TPM.

  Sur un appareil non géré, l'utilisation d'un magasin de clés basé sur un logiciel offre le moins de confiance dans l'identité de l'appareil, par rapport à ce qui précède.

• L'identification des appareils d'une autre organisation nécessite l'établissement d'une relation de confiance entre les deux organisations. Cette relation doit se faire à la fois au niveau de la gouvernance et au niveau technique.

• Apportez votre propre scénario d'appareil

  Lorsque vous autorisez les demandes provenant d'appareils que vous ne possédez pas et ne gérez pas, l'identification peut s'avérer difficile. Les appareils d'un modèle BYOD doivent toujours avoir une identité associée à eux à des fins de surveillance, mais la confiance dans l'identité de cet appareil serait probablement plus faible.

• 3. Évaluer le comportement des utilisateurs, le service et l'état de l'appareil

  Le comportement des utilisateurs et l'état du service ou de l'appareil sont des indicateurs importants pour établir la confiance dans la sécurité de vos systèmes

  Vous devez surveiller en permanence les signaux de santé de vos utilisateurs et de vos appareils, afin d'évaluer la fiabilité de ces derniers. La mesure du comportement des utilisateurs et de l'état de santé des appareils vous aide à vous assurer de leur hygiène informatique et de leur intégrité. Ces informations peuvent être intégrées à un moteur de politique pour prendre des décisions d'accès, comme décrit dans la section 4. Utiliser des politiques pour autoriser les demandes..

  Par exemple, vous souhaitez peut-être savoir d'où vos utilisateurs tentent d'accéder aux services et avoir confiance dans l'état de vos appareils. Ces signaux d'état peuvent ensuite être transmis à un moteur de politique pour aider à prendre une décision d'accès .

  Pour faciliter ces évaluations, vous devez disposer de sources d'identité uniques pour les utilisateurs, les appareils et les services . Celles-ci doivent être précédées d' une phase de découverte des actifs.

• Appareils

  Vous devez être sûr que les appareils qui accèdent à vos services et données sont en bon état. L'état de ces appareils représente l'un des signaux les plus importants utilisés pour contrôler l'accès à vos données et services. L'état de l'appareil correspond à la conformité aux politiques de configuration et à l'état de l'appareil.

  Tout d'abord, définissez des politiques de configuration qui imposeront une base de référence sécurisée pour les appareils. Les conseils du NCSC sur les appareils mobiles peuvent vous aider à cet égard. À l'aide d'un service de gestion des appareils, appliquez ces politiques aux appareils et appliquez-les. Vérifiez ensuite en permanence que les appareils sont conformes.

  L'état de santé de l'appareil peut être déterminé à partir de l'état des fonctions de sécurité de la plateforme. Par exemple, le démarrage sécurisé est-il activé ? [Les dernières mises à jour du système d'exploitation sont-elles installées ( https://www.ncsc.gov.uk/collection/mobile-device-guidance/keeping-devices-and-software-up-to-date ) ? La sécurité basée sur la virtualisation ou la protection de l'intégrité du système sont-elles activées ?

  Pour aller plus loin, la détermination de l'état de santé sous-jacent du micrologiciel d'un appareil, du processus de démarrage, de la suite de sécurité des terminaux et du noyau du système d'exploitation sont des signaux forts qui aident à déterminer l'état général de l'appareil. L'attestation est un moyen d'y parvenir, en prenant un instantané de l'état d'un appareil, avec des déclarations sur différents composants du matériel et du système d'exploitation. Certaines suites de sécurité des terminaux peuvent fournir des signaux qui peuvent aider à déterminer si un appareil est digne de confiance.

  Vous devez vous assurer que les utilisateurs légitimes disposent d'un chemin défini et clair pour remettre leurs appareils en bon état de santé informatique si ceux-ci sont tombés accidentellement en dessous de la norme requise. Un utilisateur légitime pourrait se voir refuser l'accès à un service ou à des données si un appareil n'a pas fait l'objet d'une maintenance de routine.

  Par exemple, si un appareil est resté hors ligne pendant un certain temps et n’a pas reçu de correctif du système d’exploitation, l’utilisateur doit avoir la possibilité et l’assistance nécessaire pour mettre à jour son appareil, afin qu’il puisse être considéré comme conforme.

• Services

  L'état des services doit également être pris en compte, non seulement lorsque les appareils des utilisateurs finaux y accèdent, mais également lorsque les services communiquent avec d'autres services. L'infrastructure Zero Trust, comme le moteur de politique et les points d'application des politiques, doit également être considérée comme des services.

  Les services doivent être configurés pour satisfaire à nos principes de confiance zéro en utilisant leurs fonctions de sécurité natives. Par exemple, en appliquant des mécanismes d'authentification forts et en désactivant les protocoles hérités qui ne prennent pas en charge l'authentification moderne.

  Les services dont vous êtes responsable doivent être mis à jour avec les derniers correctifs logiciels. Vous devez également être en mesure de déterminer la version et le niveau de correctif du service. Les correctifs corrigeant les vulnérabilités doivent être appliqués dès que possible.

  La santé de vos services doit être surveillée. Un changement d'état inattendu peut indiquer une modification non autorisée ou une activité malveillante. Par exemple, il peut s'agir de s'assurer que les correctifs de service sont à jour et configurés conformément à une politique de configuration (par exemple, un conteneur qui ne s'exécute pas en tant qu'utilisateur privilégié). La source du code qui compose le service doit être vérifiée comme provenant d'une source fiable, c'est-à-dire d'un pipeline de livraison de code.

• Utilisateurs

  Le comportement des utilisateurs accédant aux services et aux données doit être soigneusement étudié. Vous pouvez utiliser la surveillance pour définir ce qui constitue une activité utilisateur normale .

  Vous devez définir des politiques qui vérifient l'état des connexions des utilisateurs. Par exemple, un utilisateur se connectant depuis une région géographique différente de celle où il se trouve habituellement, ou une activité au milieu de la nuit, peuvent être inattendus.
  

  D’autres signaux peuvent être demandés, pour améliorer l’intégrité de l’action de l’utilisateur, en demandant un autre facteur d’authentification.

• Infrastructure

  Connaître l’état de santé de votre infrastructure, qui pourrait être hébergée dans un data center ou dans le cloud en IaaS (Infrastructure as a service), serait également avantageux.

  Ces informations relatives à la santé peuvent provenir de la surveillance des flux réseau ou d’informations provenant de la journalisation de l’infrastructure.

  Cela pourrait, par exemple, vous aider à repérer un appareil malveillant sur un réseau, un flux de données non autorisé pointant vers un domaine malveillant ou un processus inattendu qui démarre et qui pourrait indiquer la présence d'un logiciel malveillant dans le système

• 4. Utilisez des politiques pour autoriser les demandes.

  Chaque demande de données ou de services doit être autorisée par rapport à une politique

  La puissance d'une architecture Zero Trust réside dans les politiques d'accès que vous définissez. Les politiques peuvent également faciliter le partage de données ou de services avec des utilisateurs invités ou des organisations partenaires, en tenant compte des risques.

  Utilisez des produits, des services gérés et des protocoles qui prennent en charge un processus d’authentification et d’autorisation continu.

• Exemple - accès autorisé par la politique

  Voici un exemple théorique simple d'un utilisateur accédant à un service ou à des données d'entreprise, avec une politique autorisant la demande. Un exemple plus approfondi, développant l'utilisation des signaux dans le processus d'autorisation, peut être trouvé dans la section Utiliser plusieurs signaux pour prendre des décisions d'accès ci-dessous

1. Un utilisateur établit une connexion à un point d’application de la politique , qui servira d’intermédiaire pour sa connexion au service ou aux données demandées.

2. Le point d'application de la politique interrogera le moteur de politique pour obtenir une décision d'accès. Le moteur de politique évaluera la demande par rapport à une politique d'accès avant de fournir une décision d'accès au point d'application.

3. Si la demande d'accès est acceptée par le moteur de politique , la demande est autorisée par le point d'application de la politique . Si elle est rejetée par le moteur de politique , la connexion est interrompue.

4. La décision d'accès est évaluée en permanence en temps réel. Un changement de posture de sécurité peut entraîner la fin de la connexion ou une nouvelle authentification.

• La manière dont vous parvenez à utiliser des politiques pour autoriser les demandes dépend des technologies Zero Trust que vous déployez. Par exemple, une technologie Zero Trust utilisant des services cloud gérés sera différente d'un réseau sur site.

  Dans certaines approches, les noms et la terminologie utilisés peuvent être légèrement différents de notre exemple ci-dessus.

• Évaluation continue

  L'évaluation continue s'appuie sur la surveillance des signaux provenant des utilisateurs et des appareils et sur leur évaluation continue. Si la confiance dans leur sécurité se dégrade, une nouvelle authentification peut être déclenchée de manière dynamique, avant d'autoriser l'accès continu aux services et aux données.

  Quelle que soit la manière dont vous concevez votre architecture Zero Trust, le moteur de politique ou tout composant qui applique la politique ne doit autoriser les connexions que si les politiques strictes que vous définissez sont satisfaites.
  

• Protéger le moteur de la politique

  Il est important que vous ayez un degré de confiance élevé dans tout produit ou service qui applique votre politique d'accès. Vous devez vous assurer que ces éléments essentiels de votre architecture ont été conçus dans un souci de confiance zéro. Si ce composant était compromis, il donnerait à un attaquant le contrôle sur qui a accès aux données ou aux services.

• Il est important que l'accès au moteur de stratégie soit limité à la communication avec des points d'application de stratégie approuvés ou des services qui fournissent des signaux, tels qu'un service d'identité utilisateur. Il ne doit pas communiquer avec des sources non approuvées, telles que des appareils d'utilisateurs finaux non authentifiés.

  Lorsque le moteur de stratégie analyse les signaux, la source doit provenir d'une entité fiable et connue, mutuellement authentifiée. L'entrée doit également être validée avant l'analyse. Cela garantit qu'aucun contenu malveillant n'est consommé par le moteur de stratégie. Si vous utilisez un moteur de stratégie qui est un service géré, il est probable que le processus d'analyse sécurisée des signaux soit de la responsabilité du fournisseur de services.

  Il est également important de protéger les politiques importées dans le moteur de politiques. La possibilité de limiter l'importation d'une politique aux utilisateurs de confiance et de pouvoir également auditer et examiner les politiques est essentielle.

• Utiliser plusieurs signaux pour prendre des décisions d'accès

  Les décisions stratégiques doivent tenir compte de plusieurs signaux, issus des informations historiques et des informations de connexion en temps réel. Ensemble, ces éléments vous permettent de créer un contexte, afin de pouvoir décider si une demande d'accès est suffisamment fiable pour se poursuivre. Ces signaux sont transmis à un moteur de stratégie afin qu'il puisse prendre une décision d'accès éclairée.
  

  Il est important d’utiliser plusieurs signaux pour gagner en confiance dans une demande d’accès, car cela donnera plus d’informations à analyser et offrira une plus grande confiance dans l’authenticité du demandeur et dans la bonne santé informatique de son appareil.
  

  Une action à fort impact, comme la création d'un nouvel utilisateur de niveau administrateur, devrait répondre à des exigences de politique strictes pour être considérée comme fiable. En revanche, une action à impact relativement faible, comme la vérification du menu du déjeuner en ligne, devrait répondre à des exigences de politique plus souple

• Exemple - évaluation des signaux envoyés à un moteur de politique

  Le diagramme ci-dessous décrit un exemple théorique de la manière dont un certain nombre de signaux sont évalués par un moteur de politique. Les signaux et l'accès des utilisateurs (via un point d'application de politique) sont continuellement évalués par le moteur de politique.

• En fonction de votre implémentation de Zero Trust et du type de signaux utilisés, les détails peuvent changer, mais le principe illustré ici devrait être le même.

• Acheter une technologie Zero Trust

  Lorsque vous choisissez des technologies pour votre architecture Zero Trust, évaluez les types de signaux qu'elles prennent en charge, ainsi que d'autres fonctionnalités pertinentes, pour assurer la compatibilité avec votre moteur de stratégie.

• Voici quelques exemples de signaux que le moteur de politique pourrait évaluer :

  • le rôle de l'utilisateur

  • l'emplacement physique de l'utilisateur

  • facteurs d'authentification

  • santé de l'appareil

  • heure de la journée

  • valeur du service auquel on souhaite accéder

  • risque de l'action demandée
    

• Moteurs basés sur le risque

  Certains moteurs de politique vous permettront de créer des politiques d'accès basées sur les risques, en demandant peut-être des signaux supplémentaires pour gagner en confiance dans la connexion.

  Les moteurs de politique basés sur les risques prennent en compte le niveau de confiance des utilisateurs et des appareils, en ajustant dynamiquement les politiques d'accès en conséquence. Par exemple, imaginez qu'un utilisateur tente d'accéder à un service à forte valeur ajoutée pour la première fois, en dehors des heures de travail normales. Dans ce cas, le moteur de politique peut demander à un utilisateur de présenter un deuxième facteur d'authentification.

  Autres considérations

  Accès refusé
  Lorsqu'une demande d'accès est refusée, réfléchissez à la manière dont l'utilisateur sera informé. Trop d'informations peuvent faciliter la tâche d'un attaquant, trop peu peuvent frustrer un utilisateur légitime.

  Vous pouvez indiquer qu'une erreur d'authentification s'est produite, mais ne pas préciser ce qui a échoué en disant quelque chose comme « le compte n'existe pas ». Sans ces indices, il est beaucoup plus difficile pour un attaquant d'énumérer les informations d'authentification.

• Briser la vitre

  En cas d'urgence où l'accès aux données est essentiel, vous devrez peut-être mettre en place un processus permettant d'établir une connexion, même si une politique d'accès ne peut pas être respectée. Toute utilisation d'une procédure de bris de glace doit être signalée sur un support partagé, tel qu'une boîte de messagerie de groupe ou un canal de discussion partagé. Cela permet de détecter toute utilisation abusive des informations d'identification et de prendre des mesures en temps opportun.
  

  Dans un tel scénario, le risque doit être géré avec soin pour éviter que cette fonctionnalité ne soit utilisée à mauvais escient. Par exemple, limitez le risque associé à l'accès d'urgence en autorisant uniquement cet accès à partir d'un compte utilisateur individuel, sur un appareil spécifique, à partir d'un emplacement spécifié, pendant une durée limitée, avec un minimum de privilèges requis.

  
  

• Disponibilité

  Une fois que vous avez défini les politiques qui régissent le contrôle d'accès à vos données et services, vous devez évaluer si la disponibilité a été affectée par le blocage par erreur de demandes d'accès légitimes.

  Une fois la politique définie, commencez par enregistrer les données et ne refusez pas l'accès pendant une courte période afin de vous assurer que la politique fonctionne comme prévu. Au cours de cette période d'évaluation, il est important que les journaux soient régulièrement vérifiés et que des mesures soient prises rapidement en cas de tentative malveillante d'accès aux données ou à un service.

  Il se peut que vous ayez besoin d'une période de transition pendant laquelle vos contrôles de sécurité traditionnels bloquent activement les demandes, pendant que vous mesurez l'efficacité des politiques nouvellement défiées.

  5. Authentifiez et autorisez partout

  Supposons que le réseau soit hostile : authentifiez et autorisez toutes les connexions qui accèdent aux données ou aux services

  Créez vos systèmes pour disposer de méthodes d’authentification fortes et créez des applications pour accepter les décisions d’accès d’un moteur de politique .

  Les décisions d’authentification et d’autorisation doivent prendre en compte plusieurs signaux, tels que l’état de l’appareil, l’emplacement de l’appareil, l’identité et le statut de l’utilisateur, lors de l’évaluation du risque associé aux demandes d’accès .

• Multi-facteurs

  L’authentification multifacteur est une exigence pour une architecture Zero Trust.

  Cela ne signifie pas que l'expérience utilisateur doit être médiocre. Sur les appareils et plateformes modernes, une MFA forte peut être obtenue avec une bonne expérience utilisateur. Par exemple, en déclenchant la MFA uniquement lorsque la confiance dans l'utilisateur et l'appareil se dégrade. Certaines applications d'authentification fournissent une notification push sur un appareil de confiance, afin que les utilisateurs n'aient pas à saisir un code ou à trouver un jeton matériel.

  Il convient de noter que tous les facteurs d'authentification ne sont pas visibles pour les utilisateurs. Il se peut que l'un d'entre eux soit une connexion sans mot de passe protégée par cryptographie, utilisant un authentificateur de plate-forme FIDO2 intégré.

  
  Facilité d'utilisation

  Il est important qu'une authentification forte ne compromette pas la convivialité d'un service. Par exemple, ne demandez des facteurs d'authentification supplémentaires que lorsque les demandes ont un impact plus important, comme les demandes de données sensibles ou d'actions privilégiées, y compris la création de nouveaux utilisateurs. L'authentification unique doit être envisagée pour réduire les frictions liées à l'authentification multifacteur.

  Une approche basée sur les risques doit être envisagée pour atténuer l'impact plus important causé par des facteurs d'authentification supplémentaires. Dans l'exemple ci-dessus, si le niveau de confiance de l'utilisateur est suffisamment élevé, des facteurs supplémentaires peuvent être évités.

  L'authentification sans mot de passe (par exemple FIDO2) est une solution idéale, car elle offre une sécurité renforcée et une excellente expérience utilisateur. Envisagez de mettre en œuvre une authentification sans mot de passe pour une expérience utilisateur forte, cohérente et positive sur tous vos services.
  

  Service à service

  Les requêtes entre services doivent également être authentifiées. Cela se fait généralement à l'aide de jetons API, de frameworks tels que OAuth 2.0 ou Public Key Infrastructure .

  Utilisez l'authentification mutuelle pour avoir la certitude que les deux services qui communiquent sont authentiques. C'est essentiel lorsque vous créez une liste d'autorisation, pour autoriser les connexions entre les services en fonction de l'identité.
  

• Lectures complémentaires

  Veuillez consulter nos conseils en matière de politique d’authentification pour obtenir un aperçu du type de technologies qui peuvent être prises en compte lors de la réflexion sur une solution à ce principe.

• 6. Concentrez votre surveillance sur les utilisateurs, les appareils et les services
  
  Une surveillance complète est essentielle, car les appareils et les services sont plus exposés aux attaques réseau
  Dans une architecture Zero Trust, il est fort probable que votre stratégie de surveillance change pour se concentrer sur les utilisateurs, les appareils et les services. La surveillance de vos appareils, services et du comportement des utilisateurs vous aidera à établir leur cyber-santé

• La surveillance doit être effectuée sur l'appareil et être périodiquement exportée ou diffusée via un transport sécurisé (tel que TLS à authentification mutuelle) vers un emplacement central. Le comportement de l'utilisateur, comme les heures de travail normales ou le lieu de travail normal, est une autre mesure importante à surveiller. Il est également important d'avoir une visibilité sur vos services et de comprendre l'interaction entre les utilisateurs et leurs données. Ces informations peuvent être utilisées comme un signal , toute activité anormale observée pouvant être utilisée par un moteur de politique pour prendre une décision d'accès.

• Vous devez savoir quelles actions les appareils, les utilisateurs et les services effectuent et à quelles données ils accèdent. Votre surveillance doit être liée aux politiques que vous avez définies , en vérifiant qu'elles sont appliquées comme vous le souhaitez.

• La surveillance de protection devra peut-être être déplacée

  Les appareils des utilisateurs au sein d'une architecture réseau traditionnelle en jardin clos doivent utiliser un VPN pour envoyer tout le trafic via un chemin contrôlé. Cela permet une surveillance à un emplacement central sur ce chemin contrôlé. Dans une architecture Zero Trust, cet emplacement central ne fait probablement plus partie de votre architecture, la surveillance de protection doit donc être déplacée sur chaque appareil.

  A souligné l'importance de la confiance dans la santé de l'appareil, car un appareil compromis - en mauvais état - ne peut pas être considéré comme capable de fournir une surveillance fiable, car ses journaux pourraient avoir été falsifiés.

  Les suites de sécurité des terminaux peuvent également constituer une bonne source d'informations de surveillance, car elles disposent de fonctionnalités permettant de détecter les menaces ou d'alerter sur un comportement étrange pouvant indiquer une compromission.
  

• BYOD et appareils invités

  Si vous utilisez le BYOD (Bring Your Own Device) ou si vous disposez d'appareils invités dans votre environnement, vous ne pourrez peut-être pas atteindre pleinement tous vos objectifs de surveillance. Dans ce cas, vous devez décider de ne pas faire confiance à ces appareils dans la même mesure qu'à ceux que vous pouvez entièrement surveiller.

  Il existe des contrôles techniques qui peuvent être mis en œuvre dans les déploiements BYOD et qui peuvent accroître la confiance dans la sécurité de ces appareils. Cela inclut l'utilisation de solutions de gestion des appareils mobiles (MDM) et de gestion des applications mobiles (MAM) .

• Surveillance du réseau

  Bien que le réseau ne soit pas fiable et considéré comme hostile, la surveillance du réseau reste importante pour garantir de bonnes performances et une bonne hygiène informatique.

  Une surveillance doit être effectuée sur vos réseaux pour mesurer les performances, identifier tous les périphériques connectés à votre réseau, détecter les périphériques malveillants et les activités malveillantes. Cela est particulièrement vrai si vous hébergez des services sur site.

  Associée à la surveillance des périphériques, la surveillance du réseau peut contribuer à améliorer la visibilité et la corrélation. Par exemple, vous pouvez retracer les connexions réseau jusqu'au processus sur un périphérique qui les a générées.

• Lectures complémentaires

  Vous trouverez des conseils et des orientations supplémentaires dans le document NCSC Logging and protective monitoring , Cloud security guidance , SaaS Guidance et Introduction to logging for security goals .

• 7. Ne faites confiance à aucun réseau, y compris le vôtre

  Le Zero Trust considère le réseau comme hostile. Vous devez instaurer la confiance envers les utilisateurs, les appareils et les service
  

  Ne faites confiance à aucun réseau entre l'appareil et le service auquel il accède, y compris le réseau local. Les communications sur un réseau, pour accéder aux données ou aux services, doivent utiliser un transport sécurisé tel que TLS . L'appareil doit être configuré pour empêcher les attaques présentes sur un réseau local. Cela comprend l'usurpation DNS, les attaques de type "man-in-the-middle" et les connexions entrantes non sollicitées.

  Les attaques visant les services réseau fondamentaux, tels que le DNS, ne peuvent souvent être atténuées que par l'encapsulation dans un transport sécurisé. Par exemple, vous devez vous assurer que les services auxquels vos utilisateurs accèdent sont protégés par des protocoles authentifiés et chiffrés. Dans le cas contraire, ils devront peut-être toujours être protégés par des solutions existantes, comme votre VPN d'entreprise.

  Quelle que soit la manière dont vous choisissez de protéger les services réseau, [vous devez pouvoir appliquer une surveillance appropriée](6-Focus-your-monitoring-on users-devices-and-services.md).

• Application de la politique d'utilisation des appareils

  Dans une architecture Zero Trust, le trafic réseau ne peut pas être redirigé vers un point central, ce qui signifie que le trafic Internet ne peut pas être inspecté et surveillé. Par conséquent, la méthode traditionnelle d'application d'une politique de navigation Internet (le blocage des domaines malveillants et l'utilisation non autorisée des protocoles réseau) devra être appliquée sur l'appareil. Les fonctionnalités de navigation Web sécurisées telles que la détection d'URL malveillantes et de phishing doivent être considérées comme des fonctionnalités de sécurité de l'appareil.

  Si vous ne pouvez pas appliquer la politique de navigation Internet à l'aide des fonctionnalités de sécurité de l'appareil, vous devrez peut-être acheminer le trafic Internet via un service cloud géré, tel qu'un proxy cloud géré.

  Lorsque vous utilisez ces services, veillez à prendre en compte leur disponibilité et leur niveau de sécurité. Nos principes de sécurité du cloud peuvent vous aider à cet égard.

• Hygiène informatique générale

  Même si le réseau doit être considéré comme hostile et non fiable, il est important de maintenir une cyberhygiène sur le réseau. Par exemple, il faut surveiller le réseau local pour détecter les hôtes non autorisés et appliquer des correctifs aux composants du réseau. Cela permettra de garantir que le réseau est performant et disponible.
  
  8. Choisissez des services conçus pour le Zero Trust

  Sélectionnez des services avec prise en charge intégrée des architectures réseau Zero Trust

  
  Lors du choix des composants d’une architecture Zero Trust, vous devez privilégier les services avec prise en charge intégrée de Zero Trust.

  Dans une architecture Zero Trust, vous ne pouvez pas faire confiance au réseau. Les services doivent donc être conçus pour se protéger de toutes les sources potentielles d'attaque. Cela inclut Internet, auquel les composants peuvent être directement exposés.

• Services hérités

  Certains services, notamment les services hérités (services qui ne sont plus en cours de développement ou de support actif), peuvent nécessiter des composants supplémentaires pour activer Zero Trust. Cela peut augmenter les frais de gestion et entraîner des problèmes d'utilisation. Assurez-vous donc de disposer des ressources nécessaires pour y faire face. Veuillez consulter notre guide sur les produits obsolètes pour plus d'informations sur la gestion des services hérités.

• Ne réinventez pas la roue

  Il est préférable d’éviter de créer sa propre infrastructure de support en raison du coût, de la complexité et du risque d’erreur. Dans ce cas comme ailleurs, le principe général de cybersécurité consistant à utiliser des produits et des services conçus et construits par des professionnels qualifiés reste valable.
  

  Rechercher des normes

  Dans la mesure du possible, utilisez des technologies basées sur des normes. Cela permet l'interopérabilité entre les appareils et les services. L'authentification et l'autorisation en sont un bon exemple : des normes communes telles qu'OpenID Connect , OAuth 2.0 ou SAML permettent l'interopérabilité entre les services et les fournisseurs d'identité.
  

  Services gérés dans le cloud

  Il existe un certain nombre de services hébergés dans le cloud qui ont été conçus pour une confiance zéro. Il est important que vous soyez sûr de pouvoir faire confiance aux fournisseurs qui gèrent ces services. Nos principes de sécurité dans le cloud peuvent vous aider à gagner cette confiance.

  Introduction au Zero Trust

  Une architecture Zero Trust est une approche de conception de système dans laquelle la confiance inhérente au réseau est supprimée. Au lieu de cela, le réseau est considéré comme hostile et chaque demande d'accès est vérifiée, sur la base d'une politique d'accès.

  La confiance dans la fiabilité d’une demande est obtenue en créant un contexte, qui repose à son tour sur une authentification forte, une autorisation, l’état de l’appareil et la valeur des données auxquelles on accède
  

  Concepts clés

  Lors de la lecture et de l’application de nos principes de confiance zéro, il y a certains concepts clés à garder à l’esprit.

  Le réseau est hostile

  Le réseau doit être traité comme compromis et donc hostile. Cela signifie que vous devez supprimer la confiance du réseau.

  Dans une architecture Zero Trust, la confiance inhérente est supprimée du réseau. Ce n'est pas parce que vous êtes connecté à un réseau que vous devez pouvoir accéder à tout ce qui se trouve sur ce réseau. Chaque demande d'accès à des données ou à un service doit être authentifiée et autorisée par rapport à une politique d'accès. Si une connexion ne satisfait pas à la politique d'accès, la connexion est interrompue.

  Il est fréquent que des pirates informatiques prennent pied sur un réseau, puis se déplacent latéralement. Cela est possible parce que tout et tous ceux qui se trouvent déjà sur le réseau ont accès au reste du réseau. Dans une architecture Zero Trust, le réseau est traité comme hostile, de sorte que chaque demande d'accès aux données ou aux services est continuellement vérifiée par rapport à une politique d'accès. Cela permettra également d'améliorer la surveillance et la détection des tentatives de déplacement latéral par un pirate, par rapport à un wall garden traditionnel, mais Zero Trust ne supprimera pas complètement la menace.

  Gagnez en confiance de manière dynamique

  Si vous supprimez la confiance du réseau, vous devez à la place gagner la confiance de vos utilisateurs, appareils et services. Plutôt que de prendre un instantané de la connexion de l'utilisateur, de l'appareil ou du service à votre réseau et de laisser l'autorisation qui en résulte persister, vous devez chercher à évaluer en permanence la fiabilité de ces connexions.

  Pour les utilisateurs qui accèdent aux services, vous devez établir une confiance dans l'identité et le comportement de l'utilisateur ainsi que dans l'état de l'appareil avant qu'ils puissent accéder au service. Pour les services interagissant entre eux, comme l'échange de données à l'aide d'une API, cela s'effectue en s'assurant que les bons services communiquent entre eux et en gagnant la confiance dans l'état des services que vous hébergez.

  Le niveau de confiance dont vous avez besoin pour faire confiance à une connexion dépend de la valeur des données auxquelles vous accédez ou de l’impact de l’action demandée.

  Par exemple, l’accès à des données personnelles sensibles peut nécessiter une politique d’accès spécifiant une liste d’utilisateurs autorisés avec une authentification forte, sur un appareil appartenant à l’organisation et en bon état, sur la base de politiques de configuration définies telles que le cryptage, les niveaux de correctifs et le démarrage sécurisé activés.

  En revanche, l’accès aux données de faible valeur, comme le menu du déjeuner, peut être effectué par n’importe qui dans l’organisation, quelle que soit la force de son authentification ou l’état de son appareil.

  Terminologie

  Lorsque l'on discute des architectures Zero Trust, il est utile d'avoir un vocabulaire commun. Vous trouverez ci-dessous quelques termes utilisés dans les principes Zero Trust. Nous avons essayé d'aligner étroitement ces termes avec d'autres sources, pour faciliter la discussion sur les technologies Zero Trust.

  • Politique d'accès - Les exigences pour qu'une demande d'accès soit fiable et autorisée.

  • Politique de configuration - Politiques qui décrivent les options de configuration des périphériques et des services.

  • Signal - Un élément d'information tel que l'état de fonctionnement ou l'emplacement d'un appareil qui peut être utilisé pour établir la

  • fiabilité d'un actif. Vous utiliserez souvent un certain nombre de signaux pour décider d'accorder ou non l'accès à une ressource.

  • Moteur de politique - Le composant qui prend les signaux et les compare aux politiques d'accès pour déterminer une décision d'accès.

  • Point d'application des politiques : transmet les demandes d'un utilisateur ou d'un appareil à un service ou à des données à l'aide du

  • moteur de politiques pour déterminer si les demandes peuvent être autorisées.

  • État de santé de l'appareil : assurance qu'un appareil est conforme aux politiques de configuration et qu'il est en bon état. Par exemple,

  • les derniers correctifs ont été installés ou une fonctionnalité comme le démarrage sécurisé est activée.

• Guide de déploiement Zero Trust

• Prérequis

• Licence Azure AD Premium P2

• Sécurité Microsoft 365 E5

• PowerShell 7.0 ou supérieur

• Accès administratif à Microsoft 365 et Entra ID

  Étapes de déploiement

  1. Configuration initiale

  # Run initial setup script .\scripts\setup\install_dependencies.ps1 -Verbose

  2. Configuration

  1. Mettre à jour les fichiers de configuration dans/config

  2. Vérifier les bases de sécurité

  3. Configurer les paramètres de surveillance

  3. Configuration de la protection de l'identité

  1. Configurer MFA

  2. Configurer des politiques d'accès conditionnel

  3. Activer les fonctionnalités de protection de l'identité

  4. Mise en œuvre du contrôle d’accès

  1. Configurer PIM

  2. Configuration des examens d'accès

  3. Implémenter l'accès JIT

• 5. Configuration de la surveillance

  1. Configurer la journalisation d'audit

  2. Configurer les règles d’alerte

  3. Activer la détection des menaces

• Liste de contrôle de vérification

  • Protection d'identité activée et configurée

  • Politiques d'accès conditionnel appliquées

  • PIM configuré pour les rôles privilégiés

  • Suivi et alerte opérationnelle

  • Examens d'accès prévus

• Bonnes pratiques en matière de sécurité

  Protection de l'identité

  1. Appliquer l'authentification multifacteur pour tous les utilisateurs

  2. Mettre en œuvre un accès conditionnel basé sur les risques

  3. Examens d'accès réguliers

  4. Utiliser PIM pour les rôles privilégiés

• Contrôle d'accès

  1. Suivre le principe du moindre privilège

  2. Mettre en œuvre un accès juste à temps

  3. Certification d'accès régulier

  4. Surveiller les activités privilégiées

• Surveillance

  1. Activer un audit complet

  2. Configurer les seuils d'alerte

  3. Examen régulier des journaux de sécurité

  4. Planification de la réponse aux incidents

• Conformité

  1. Évaluations régulières de la conformité

  2. Maintenance de la documentation

  3. Application des politiques

  4. Formation et sensibilisation régulières

• Gestion des risques

  1. Évaluations régulières des risques

  2. Modélisation des menaces

  3. Procédures de réponse aux incidents

  4. Planification de la continuité des activités

• L'architecture Zero Trust

  Aperçu

  Décrit la mise en œuvre des principes de sécurité Zero Trust dans les environnements Microsoft 365 et Entra ID.

• Composants de base

  1. Protection de l'identité

  • Authentification multifacteur (MFA)

  • Politiques d'accès conditionnel

  • Détection des risques d'identité

  • Gestion des identités privilégiées

  2. Contrôle d'accès

  • Accès juste à temps

  • Postes de travail à accès privilégié

  • Gestion des sessions

  • Accès aux avis

  3. Surveillance de la sécurité

  • Détection des menaces en temps réel

  • Analyse comportementale

  • Journalisation d'audit

  • Gestion des alertes

• Plan de déploiement de Microsoft 365 Zero Trust

  Cette illustration fournit un plan de déploiement pour la création d'une sécurité Zero Trust avec Microsoft 365. Zero Trust est un nouveau modèle de sécurité qui suppose une violation et vérifie chaque demande comme si elle provenait d'un réseau non contrôlé. Quelle que soit l'origine de la demande ou la ressource à laquelle elle accède, le modèle Zero Trust nous apprend à « ne jamais faire confiance, toujours vérifier ».

  
  Utilisez cette illustration :

  Guides de solutions associés

• Déployez votre infrastructure d'identité pour Microsoft 365

• Configurations recommandées en matière d'identité et d'accès aux appareils

• Gérer les appareils avec Intune

• Évaluer et piloter Microsoft Defender XDR

• Déployer une solution de protection des informations avec Microsoft Purview

• Déployez la protection des informations pour les réglementations sur la confidentialité des données avec Microsoft 365
  

• Options d'inscription à Intune

  Ce guide vous aide à décider quelle option d'inscription est la mieux adaptée à vos points de terminaison, y compris les options pour :

  • Appareils Windows

  • macOS

  • iOS/iPad

  • Androïde

• Guides de solutions associés

  Gérer les appareils avec Intune

  Guide de planification de Microsoft Intune

• Attaques courantes et comment les fonctionnalités Zero Trust de Microsoft peuvent protéger votre organisation

• Les cyberattaques les plus courantes et comment les fonctionnalités Microsoft pour Zero Trust peuvent aider votre organisation à chaque étape d’une attaque.

  Les fonctionnalités de Zero Trust qui peuvent aider à arrêter les attaquants à chaque étape d'une attaque.

• Guides de solutions associés

  Évaluer et piloter Microsoft Defender XDR

  Configurations recommandées en matière d'identité et d'accès aux appareils

  Déployez la protection des informations pour les réglementations sur la confidentialité des données avec Microsoft 365

  Déployez une protection contre les ransomwares pour votre locataire Microsoft 365

  Solutions de gestion des risques internes dans Microsoft 365
  

• Identité cloud Microsoft pour les architectes informatiques

  Ce que les architectes informatiques doivent savoir sur la conception d’identité pour les organisations utilisant les services et plateformes cloud Microsoft.

• Identité avec le cloud de Microsoft

• Fonctionnalités Microsoft Entra IDaaS

• Politiques d'accès aux identités et aux appareils Zero Trust

• Intégration des comptes Active Directory Domain Services (AD DS) sur site avec Microsoft Entra ID

• Intégrer des composants d'annuaire dans Azure IaaS

• Options AD DS pour les charges de travail dans Azure IaaS

  Sécurité du cloud Microsoft pour les architectes informatiques

  Ce que les architectes informatiques doivent savoir sur la sécurité des services et plateformes cloud Microsoft.

• Responsabilités de Microsoft et des clients en matière de sécurité

• Identité et accès aux appareils

• Protection contre les menaces

• Protection des informations

• Protection des applications cloud

• Réseaux cloud Microsoft pour les architectes informatiques

  Ce que les architectes informatiques doivent savoir sur la mise en réseau des services et plateformes cloud Microsoft

  • Faire évoluer votre réseau pour la connectivité cloud

  • Éléments communs de la connectivité cloud Microsoft

  • ExpressRoute pour la connectivité cloud Microsoft

  • Conception de réseaux pour Microsoft SaaS, Azure PaaS et Azure IaaS

Cloud hybride Microsoft pour les architectes informatiques

Ce que les architectes informatiques doivent savoir sur le cloud hybride pour les services et plateformes Microsoft.

• Les offres cloud de Microsoft (SaaS, Azure PaaS et Azure IaaS) et leurs éléments communs

• Architecture cloud hybride pour les offres cloud de Microsoft

• Scénarios de cloud hybride pour Microsoft SaaS (Office 365), Azure PaaS et Azure IaaS