Depuis toujours, les équipes IT et équipe sécurité du secteur public ont dû choisir entre l’automatisation cloud moderne et agile, et des frameworks de sécurité cryptographique hérités et rigides. Désormais, ce n'est plus nécessaire.
Alors que les agences gouvernementales des États-Unis ont considérablement progressé dans la sécurisation de l’authentification des personnes grâce à des outils tels que les cartes à puce et Okta FastPass, la sécurisation des communications machine-to-machine (M2M) en arrière-plan demeure un challenge. À mesure que les agences mettent en place des pipelines automatisés pour gérer les cycles de vie des utilisateurs, provisionner des ressources et orchestrer les opérations de sécurité, ces workflows automatisés doivent interagir avec des infrastructures externes.
Historiquement, sécuriser ces connexions API sortantes impliquait de gérer les contraintes liées aux secrets partagés, aux clés API ou à l’authentification de base, des méthodes qui exposent à des risques majeurs en cas de fuite d’un seul token. Prendre une longueur d’avance sur les attaquants actuels implique d’étendre un modèle de sécurité Zero Trust dynamique au-delà de l’espace de connexion et jusque dans les opérations automatisées.
C’est pourquoi nous avons le plaisir d’annoncer que Okta Workflows prend désormais en charge le mTLS sortant (mutual TLS). Conçue exclusivement pour les organisations relevant de nos cellules de conformité, cette fonctionnalité offre aux équipes du secteur public un mécanisme d’authentification hautement sécurisé, basé sur des certificats, adapté aux exigences strictes des environnements fortement réglementés.
Pourquoi utiliser mTLS avec Okta Workflows ?
En sécurisant la couche d’intégration sortante grâce à des échanges cryptographiques — où les deux parties d’une connexion réseau vérifient leurs identités numériques — le mTLS réduit les vulnérabilités liées aux tokens partagés.
Avec la fonctionnalité mTLS sortante d’Okta Workflows, les agences fédérales et leurs partenaires peuvent :
- Éliminer la fatigue liée aux secrets : Abandonner les tokens API statiques, les clés à longue durée de vie et l’authentification de base, et les remplacer par une vérification d’identité basée sur la cryptographie et adaptée à la rotation.
- Relier l’automatisation moderne à l’infrastructure héritée : Déclencher en toute sécurité des workflows automatisés qui s’intègrent sans difficulté à des systèmes externes anciens et fortement isolés, qui ne prennent pas en charge les protocoles modernes comme OAuth mais exigent une authentification mutuelle basée sur des certificats.
- Appliquer le Zero Trust aux entités non humaines : Étendre les principes de l’architecture Zero Trust (ZTA) aux workflows automatisés, en vérifiant l’identité cryptographique explicite du moteur de workflow avant d’exécuter des actions externes.
Fonctionnement : le magasin de confiance Workflows
Au cœur de cette fonctionnalité se trouvent le Connecteur API Workflows et le trust store, une couche de gestion sécurisée intégrée nativement à votre environnement Okta Workflows conforme. Le connecteur API et le magasin de confiance servent de bibliothèque centralisée pour les connexions API et les certificats nécessaires au lancement de connexions sortantes sécurisées.
Configurer un pipeline mTLS sortant vise à restreindre de manière stricte la confiance et la sécurité à des connexions spécifiques :
- Téléverser un certificat d’autorité de certification (CA): Les administrateurs téléversent le ou les certificats CA nécessaires directement dans le magasin de confiance Workflows, ce qui permet à Okta Workflows de vérifier de manière fiable l’identité du service cible externe.
- Configurer le Connecteur API : Lors de la création ou de la mise à jour d’un flux d’automatisation, les administrateurs accèdent simplement au Connecteur API, sélectionnent mTLS comme type d’authentification, puis l’associent au certificat téléchargé.
Une fois déployé, chaque action sortante exécutée par le workflow déclenche une authentification cryptographique mutuelle, validant les deux extrémités du pont avant qu’un seul octet de données de l’organisation ne soit échangé.
Responsabilités des clients et obligations fédérales
La mise en place d’un modèle de sécurité multiniveau est un parcours collectif. Alors qu’Okta offre un environnement sécurisé pour développer ces automatisations dans le cadre de nos exigences fédérales, les clients conservent plusieurs responsabilités afin de garantir la conformité avec les obligations fédérales telles que OMB M-22-09 et NIST SP 800-53rev5 :
- Configuration du Terminal : Les clients doivent veiller à ce que leur infrastructure externe de réception soit explicitement configurée pour exiger et valider correctement les certificats mTLS ainsi que leurs émetteurs.
- Cryptographie FIPS : Conformément aux exigences fédérales, les organismes doivent vérifier que les modules de cryptographie et les autorités de certification générés et utilisés respectent les standards FIPS 140.
- Gestion du cycle de vie des certificats : Les agences sont responsables de la gestion, de l’audit et du renouvellement des certificats conservés dans le référentiel de confiance Workflows, conformément à leurs exigences internes en matière de mission et de sécurité.
Prêt à sécuriser les pipelines automatisés de votre agence ?
La protection des identités non humaines et des infrastructures automatisées peut s’avérer complexe. Notre documentation Okta Workflows mTLS peut aider votre organisation à démarrer la configuration de pipelines mTLS automatisés.
Découvrez directement comment Okta poursuit la lutte contre les attaques d’identité, qu’elles ciblent des utilisateurs humains ou non humains. Contactez votre interlocuteur Okta ou regardez à la demande nos sessions du Gov Identity Summit pour découvrir comment Okta étend le Zero Trust à l’ensemble des organisations fédérales.
