Charges de travail
Okta Privileged Access offre un maillage de sécurité des identités unifié qui régit les identités non humaines (NHI) (telles que des comptes de service et des éxécuteurs CI/CD) avec la même rigueur que pour les utilisateurs humains. En proposant une nouvelle alternative aux utilisateurs de service et aux clés d'API statiques, l'authentification de la charge de travail Okta Privileged Access permet aux organisations d'utiliser des identités fédérées, signées par la plateforme (JWT/OIDC) ou des clés d'API sécurisées pour établir la confiance sans risque de secret zéro. Cette couche de politique centralisée dissocie l'identité machine des secrets qu'elle consomme. Cela permet une transition transparente de la mise en coffre des identifiants statiques à la fourniture d'un accès Just-in-Time aux serveurs, aux bases de données et aux secrets éphémères.
Pour éliminer le risque de prolifération du secret, Okta Privileged Access propose deux approches d'authentification : * Charges de travail hébergées dans le cloud : fait passer l'authentification de clés d'API statiques à une attestation cryptographique. En établissant des connexions à la charge de travail avec des fournisseurs de confiance, notamment CircleCI, GitLab, GitHub Actions et Google Cloud Platform (GCP), Okta Privileged Access vérifie à l'exécution des JSON Web Tokens (JWT) signés. Les charges de travail utilisent des jetons signés fournis par l'environnement pour prouver leur identité sans stocker d'identifiants statiques sur le disque. * Charges de travail hors cloud ou locales : les connexions par clé d'API Okta Privileged Access permettent une authentification sécurisée à l'aide de secrets gérés à courte durée de vie, avec des capacités de rotation et de révocation intégrées contrôlées par les administrateurs de sécurité.
Fonctionnalités et concepts clés
| Fonctionnalité/composant | Description |
|---|---|
| Charge de travail |
Une tâche automatisée ou une entité machine, telle qu'un contrôleur Ansible ou un exécuteur CI/CD, qui demande l'accès à une ressource privilégiée. |
|
Document d'identité de la charge de travail |
Un document d'identité présenté par la charge de travail pour prouver son identité. Pour les connexions avec JWT, il s'agit d'un jeton JSON Web Token (JWT) signé par un tiers de confiance tel que GitHub, GitLab ou GCP. Pour les connexions avec une clé d'API, il s’agit d’une clé d'API signée de manière cryptographique et gérée par Okta. |
|
Identité de la charge de travail |
Une identité numérique qui permet aux systèmes, tels que des serveurs, des conteneurs, des machines virtuelles ou des pipelines CI/CD, de s'authentifier et d'obtenir une autorisation pour des tâches automatisées au sein d'une organisation. |
|
Authentification de la charge de travail |
Le processus par lequel une charge de travail prouve son identité au moyen d'un document d'identité de la charge de travail. |
|
Jeton Okta Privileged Access |
Okta Privileged Access émet un jeton sécurisé et inviolable pour la charge de travail après une authentification réussie. La charge de travail utilise ce jeton d'accès pour accéder aux ressources protégées par Okta Privileged Access. |
|
Connexion à la charge de travail |
La configuration centrale définit la relation de confiance avec un fournisseur de charge de travail externe (pour les connexions avec JWT) ou configure une authentification par clé d'API gérée (pour les connexions avec clé d'API). Un administrateur DevOps crée les connexions avec JWT avec le statut Brouillon, et un administrateur de la sécurité les promeut au statut Actif pour activer l'émission de jetons. Pour les connexions avec une clé d'API, seul un administrateur de sécurité crée et gère la connexion. Remarque :
Une connexion à la charge de travail JWT avec le statut Brouillon permet d'effectuer des tests de validation de JWT, mais n'émet pas de jetons d'accès fonctionnels pour l'accès aux ressources. Il ne peut pas non plus correspondre à un rôle de charge de travail qui empêche un accès par inadvertance un accès pendant les tests. Les connexions avec une clé d'API sont gérées exclusivement par les administrateurs de sécurité, sans phase de brouillon. |
|
Rôles de charge de travail |
Entités d'autorisation critiques qui servent de principaux dans les politiques Okta Privileged Access. Ces rôles simplifient la gestion des politiques en associant les attributs des charges de travail à des groupes de sécurité logiques. |
|
Attribution de politique aux principaux de charge de travail |
Les administrateurs de la sécurité définissent des politiques qui utilisent des rôles de charge de travail en tant que principaux pour protéger les ressources. L'application des politiques repose sur des informations d'attribut détaillées provenant des intégrations de plateforme. |
|
Outils client améliorés |
Le client CLI Okta Privileged Access prend désormais en charge une utilisation autonome et non interactive, éliminant la nécessité d'une intervention humaine. |
|
Accès SSH principal |
Permet aux charges de travail de se connecter directement à des serveurs à l'aide d'un nom d'utilisateur Unix/Linux géré par le système (préfixé par |
Processus de charge de travail pour l'accès automatisé
Le workflow Okta Privileged Access pour sécuriser des charges de travail automatisées est structuré en deux phases distinctes : configuration administrative et exécution automatisée. Cette séparation garantit que les administrateurs humains maintiennent une supervision et une gouvernance strictes tandis que les identités machine opèrent de manière autonome à l'exécution.
Configuration administrative
La phase administrative se concentre sur l'établissement de la confiance et la définition des périmètres de sécurité pour l'automatisation. Ce processus nécessite une collaboration entre les équipes DevOps et de sécurité.
Pour les connexions avec JWT : un administrateur DevOps crée un brouillon de connexion à la charge de travail pour définir la source de validation et les demandes de validation JWKS du fournisseur externe. L'administrateur prépare et teste des commandes CLI sur la connexion brouillon pour vérifier la syntaxe et la validation du JWT. Quand l'administrateur de la sécurité active la connexion, elle passe de brouillon à actif et l'administrateur DevOps perd l'accès en écriture. La connexion émet ensuite des jetons Okta Privileged Access valides. L'administrateur de la sécurité définit un rôle de charge de travail avec des blocs de correspondance d'attributs et le lie à une politique pour définir des règles d'accès aux ressources et aux secrets.
Pour les connexions avec clé d'API : un administrateur de sécurité crée une connexion à la charge de travail par clé d'API au statut actif (aucune phase de brouillon n’est requise). L'administrateur génère une clé d'API et la transmet à l'équipe DevOps via un canal sécurisé hors bande. L'administrateur de sécurité définit un rôle de charge de travail avec des conditions de correspondance d'attributs et le lie à une politique pour définir des règles d'accès aux ressources.
Exécution automatisée
Cette phase détaille le processus en temps réel qui se produit chaque fois qu'une charge de travail requiert l'accès à une ressource privilégiée. Après la configuration, la phase d'exécution automatisée s'exécute chaque fois que la charge de travail demande un accès.
Pour les connexions avec JWT : au moment de l'exécution, la charge de travail s'authentifie en présentant son jeton JWT et en faisant référence à sa connexion à la charge de travail. Le système valide le JWT et, en cas de réussite, émet un jeton d'accès à durée de vie courte afin d'établir l'identité de session de la charge de travail. Avec le jeton d'accès, la charge de travail demande l'accès à une ressource protégée et spécifie son rôle. Le moteur de politiques valide le jeton et vérifie les exigences de rôle. En cas d'approbation, il applique le principe du moindre privilège et consigne l'événement. La charge de travail utilise ensuite des identifiants pour se connecter et accomplir sa tâche.
Pour les connexions avec clé d'API : au moment de l’exécution, la charge de travail présente sa clé d'API et fait référence à sa connexion à la charge de travail. Le système valide la clé d'API et, en cas de réussite, émet un jeton d'accès à courte durée de vie. La charge de travail utilise ce jeton pour demander l'accès à des ressources protégées et spécifie son rôle. Le moteur de politiques valide le jeton et vérifie les exigences de rôle. Si l’approbation est accordée, l’accès est autorisé et l’événement est enregistré.
Rubriques
Configurer une connexion de charges de travail
Commande CLI pour l'authentification des charges de travail
Configurer les rôles de charges de travail
Générer des clés d'API, procéder à leur rotation et les révoquer
Accès SSH principal pour les charges de travail automatisées