Il s’agit du premier blog d’une série en trois volets consacrée au rôle de l’identité dans CMMC 2.0.
BLUF : Une question essentielle qui sous-tend chaque politique d’accès : Êtes-vous réellement la personne que vous affirmez être ?
Cet article explore en détail la famille de contrôles Identification et authentification (IA). Nous allons démontrer pourquoi une vérification d’identité robuste constitue le prérequis indispensable à un contrôle des accès plus sécurisé et montrer comment Okta vous aide à répondre à ces exigences à chaque niveau de maturité du CMMC 2.0.
Vue d’ensemble : l’authentification, fondement du contrôle des accès
La famille de contrôles identification et authentification (IA) constitue le gardien numérique de votre entreprise. Son objectif est de s’assurer que chaque utilisateur, appareil ou processus est légitime et vérifié avant même de pouvoir tenter d’accéder à une ressource. Vos politiques de contrôle des accès, même élaborées avec soin, n’ont aucune valeur si vous doutez de l’identité de la personne à l’origine de la demande.
C’est pourquoi la méthodologie de notation du CMMC 2.0 accorde une importance particulière aux contrôles d’IA. Un auditeur doit avoir la certitude et la preuve de l’identité avant de pouvoir faire confiance aux mesures de sécurité que vous avez mises en place.
Avec Okta, les entreprises peuvent répondre immédiatement à une part importante de ces exigences à forte valeur ajoutée. Rien qu’au sein de la famille IA, Okta vous aide à répondre à trois contrôles valant 5 points— les « points clés » essentiels pour réussir votre audit.
Examinons un contrôle clé de la gestion des identités à chaque niveau du CMMC.
CMMC Niveau 1 : le socle fondamental
Le niveau 1 met l’accent sur « l’hygiène cybernétique de base » et s’applique aux prestataires qui traitent des informations contractuelles fédérales (FCI). Vous disposez ainsi de l’essentiel.
Contrôle clé de niveau 1 : IA.L1-3.5.1
Exigence CMMC | Contrôle corrélé NIST SP 800-53 |
|---|---|
IA.L1-3.5.1 : Identifier et authentifier les utilisateurs, les processus ou les appareils du système d’information. | IA-2 : identification et authentification (utilisateurs et utilisatrices de l’organisation) : Le système d’information identifie et authentifie de manière unique les utilisateurs et utilisatrices de l’organisation (ou les processus agissant pour leur compte). |
Ce contrôle exige d’attribuer une identité unique à chaque utilisateur et de supprimer les comptes partagés.
Comment Okta répond à l’exigence :
L’ Okta Universal Directory et l’ authentification unique (SSO) sont les outils idéaux pour répondre à cette exigence du CMMC. Okta joue le rôle de source fiable centrale pour toutes les identités utilisateur, veillant à ce que chaque personne dispose d’un, et d’un seul, compte. En fédérant vos applications avec l’authentification unique (SSO) d’Okta, vous contribuez à faire en sorte qu’une seule identité unique soit utilisée pour chaque connexion, rendant ainsi les comptes partagés obsolètes.
- Cas concret : Un petit fournisseur du secteur DIB se connecte au portail d’un grand prestataire pour accéder à des FCI, comme les plannings de livraison. Au lieu d’utiliser un compte shipping@supplier.com partagé, l’entreprise utilise Okta pour attribuer à chaque collaborateur un compte utilisateur unique. Lorsqu’un collaborateur accède au portail, il s’authentifie avec Okta en utilisant ses identifiants personnels, ce qui permet d’associer chaque action directement à cette personne et de répondre à l’exigence fondamentale de traçabilité requise pour le niveau 1.
IA.L1-3.5.1 Recommandations de conception :
Pour mettre en place ce contrôle, configurez Okta comme fournisseur d’identité central en le connectant à une source fiable, telle que votre système RH, ou en créant des profils utilisateur directement dans l’Okta Universal Directory. Pour chacune de vos applications, configurez une intégration SSO à l’aide de SAML ou d’OIDC. Il est essentiel de configurer l’application pour autoriser les connexions uniquement via Okta, en désactivant la possibilité pour les utilisateurs et utilisatrices de créer des comptes locaux distincts avec un nom d’utilisateur et un mot de passe. Cela impose l’utilisation de l’identité unique et gérée pour tous les accès.
IA.L1-3.5.1 Preuve de conformité :
Pour démontrer votre conformité à un évaluateur, vous lui présenterez votre Okta Universal Directory afin de prouver que chaque collaborateur dispose d’un profil utilisateur unique. Vous accédez ensuite à la page de configuration d’une application clé (par exemple, Microsoft 365) et affichez les paramètres d’authentification unique (SSO), en constatant qu’elle est fédérée avec Okta. Enfin, vous consulteriez le journal système Okta, filtreriez les connexions récentes d’un utilisateur spécifique, puis afficheriez le journal détaillé des événements, démontrant que chaque action est traçable à un actor.id unique.
CMMC Niveau 2 : le gardien des CUI
Le niveau 2 s’adresse aux prestataires qui traitent les informations non classifiées contrôlées (CUI) les plus sensibles. Ce niveau est conforme à la norme NIST SP 800-171 et exige une sécurité nettement plus renforcée.
Key niveau 2 control : IA.L2-3.5.3
Exigence CMMC | Contrôle corrélé NIST SP 800-53 |
|---|---|
IA.L2-3.5.3 : Utilisez l’authentification multifacteur pour l’accès local et réseau. | IA-2(1) : Accès réseau aux comptes à privilèges et aux comptes sans privilèges : Le système d’information met en œuvre une authentification multifacteur pour l’accès réseau aux comptes à privilèges et aux comptes sans privilèges. |
Ce contrôle majeur en cinq points impose qu’un simple mot de passe ne suffit pas. Vous devez imposer un second facteur d’authentification (MFA) afin de protéger contre le vol de mots de passe.
Comment Okta répond à l’exigence :
Okta Adaptive MFA est l’outil idéal pour répondre à cette exigence du CMMC. En tant que fournisseur d’identité centralisé, Okta peut appliquer une authentification multifacteur (MFA) renforcée à chaque tentative d’accès à toute application traitant des informations CUI. Les politiques peuvent être configurées pour exiger l’authentification multifacteur (MFA) pour tous les utilisateurs et s’adapter en fonction du risque, par exemple en imposant un facteur plus robuste lorsqu’un utilisateur se connecte depuis un réseau non fiable.
- Cas concret : Une personne ingénieure en aérospatiale travaillant à domicile doit accéder à une application de CAO dans le cloud contenant des informations CUI. Pour se connecter, ils saisissent d’abord leur mot de passe. Okta leur demande ensuite d’approuver une notification push sur leur smartphone enregistré. Ce n’est qu’après avoir validé ce deuxième facteur qu’ils obtiennent l’accès aux fichiers de conception sensibles. Un attaquant ayant obtenu le mot de passe par hameçonnage serait immédiatement bloqué lors du défi MFA.
IA.L2-3.5.3 Recommandations de conception :
Dans votre console d’administration Okta, créez une politique « Authenticator Enrollment » qui impose à tous les utilisateurs de s’inscrire à au moins un facteur d’authentification multifacteur. Créez ensuite une « politique de connexion » et appliquez-la à toutes les applications qui traitent des informations CUI. Configurez les règles de cette politique pour « exiger une authentification multifacteur » à chaque connexion. Une bonne pratique consiste à définir la règle suivante : si un utilisateur se trouve sur un réseau non fiable, une authentification MFA lui est systématiquement demandée. Pour renforcer davantage votre posture, exigez un facteur résistant au phishing pour tout accès à ces applications critiques.
IA.L2-3.5.3 Preuve de conformité :
Pour une personne chargée de l’évaluation, vous afficheriez d’abord la politique de connexion que vous avez créée, en montrant la règle qui impose explicitement l’authentification multifacteur (MFA) à chaque connexion à une application contenant des CUI. Vous effectueriez ensuite une démonstration en direct : tenter de vous connecter à cette application en tant qu’utilisateur de test et montrer à la personne chargée de l’évaluation l’affichage en temps réel de la demande d’authentification multifacteur (MFA) sur un appareil enregistré. Enfin, montrez-leur l’événement de réussite « Authentification multifacteur » correspondant pour cet utilisateur dans le journal système Okta.
CMMC niveau 3 : la défense experte
Le niveau 3 s’adresse aux entreprises participant aux programmes les plus prioritaires du DoW. Cela nécessite l’ensemble des contrôles de niveau L2 ainsi que des contrôles renforcés issus de NIST SP 800-172 afin de se protéger contre les menaces persistantes avancées (APTs).
Contrôle clé de niveau 3 : IA.L3-3.5.4e
Exigence CMMC | Contrôle corrélé NIST SP 800-53 |
|---|---|
IA.L3-3.5.4e : Utiliser une authentification multifacteur résistante au phishing pour tous les accès, qu’ils soient à privilèges ou non. | IA-2(8) : résistant au phishing / résistant à la réutilisation : Le système d’information utilise des mécanismes d’authentification qui sont résistants au phishing et à la réutilisation. |
Ce contrôle avancé impose l’utilisation de la MFA résistante au phishing afin de contrer les attaques sophistiquées capables de contourner des types de MFA moins robustes.
Comment Okta répond à l’exigence :
Okta propose certains des authentificateurs les plus résistants au phishing du secteur, des outils qui répondent à cette exigence de niveau expert du CMMC. Cela inclut des clés de sécurité matérielles compatibles FIDO2/WebAuthn comme les YubiKeys, ainsi que des solutions sans mot de passe telles que Okta FastPass, qui s’appuie sur la biométrie de la plateforme, comme Windows Hello ou Face ID/Touch ID d’Apple. Les politiques d’Okta peuvent être configurées pour exiger exclusivement ces facteurs inviolables pour toute personne accédant à l’environnement CUI à forte valeur.
- Cas concret : Un analyste en cybersécurité dans une entreprise de défense de premier plan gère des systèmes contenant des CUI hautement sensibles. Pour accéder à la console d’administration, ils doivent s’authentifier via Okta. Après avoir saisi leur mot de passe, il leur est demandé de toucher la YubiKey insérée dans leur poste de travail. La clé exécute un protocole challenge-réponse cryptographique unique à leurs utilisateurs et au service Okta, prouvant ainsi leur identité avec le plus haut niveau de confiance et rendant impossible pour un adversaire sophistiqué d’intercepter leurs identifiants.
IA.L3-3.5.4e Recommandations de conception :
Dans votre politique « Authenticator Enrollment » d’Okta, veillez à ce que les authentificateurs FIDO2/WebAuthn soient activés. Ensuite, créez ou modifiez votre politique de connexion pour les applications CUI. Au lieu d’imposer une exigence générale de MFA, créez une règle qui impose explicitement l’utilisation d’un authentificateur dont la propriété « Phishing Resistance » est requise. Cette règle imposera l’utilisation de facteurs tels qu’une YubiKey ou Okta FastPass, exploitant la biométrie intégrée de l’appareil, et n’autorisera pas de facteurs moins robustes comme les SMS ou les questions de sécurité pour accéder à ces applications à haute sensibilité.
IA.L3-3.5.4e Preuves de conformité :
Pour le démontrer à l’évaluateur, vous présenterez la règle de politique de connexion que vous avez configurée et qui exige spécifiquement des authentificateurs résistants au phishing. Ensuite, effectuez une démonstration de connexion en direct. Commencez par tenter de vous connecter en utilisant un facteur non résistant au phishing (comme une notification push), puis montrez que l’accès est refusé. Répétez ensuite la connexion en utilisant une YubiKey ou Okta FastPass avec Windows Hello, puis vérifiez que l’accès est accordé avec succès. Cela constitue une preuve irréfutable de l’application des mesures.
Poursuivre votre parcours CMMC sur des bases solides
En associant un contrôle des accès robuste à une identification et une authentification résilientes, vous mettez en place une défense solide pour vos CUI ainsi qu’une base fiable pour votre audit CMMC. En centralisant votre stratégie sur une plateforme d'identité moderne, vous permettez uniquement aux personnes autorisées d'accéder aux bonnes ressources.
Restez à l’écoute pour notre prochain article de la série, dans lequel nous explorerons le domaine Audit et responsabilité (AU) afin de vous montrer comment démontrer l’efficacité de vos contrôles de sécurité.
Pour en savoir plus sur la façon dont Okta peut aider votre entreprise à répondre aux exigences du CMMC, téléchargez notre guide découverte CMMC à l’adresse https://www.okta.com/resources/datasheet-okta-cmmc-discovery-guide/ ou contactez-nous à okta.com/contact-sales/.
Bien que cet article aborde certaines notions de droit, il ne constitue pas un avis juridique et ne doit pas être interprété comme tel. Sa finalité est uniquement informative. Si vous avez besoin de conseils juridiques sur les exigences de conformité s’appliquant à votre organisation, veuillez vous adresser à votre service juridique. Okta ne formule aucune déclaration, garantie ou autre assurance concernant le contenu de cet article. Pour en savoir plus sur les assurances contractuelles d’Okta à ses clients, rendez-vous à cette adresse okta.com/agreements.
