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 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) 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 zéro, Okta Privileged Access fait passer l'authentification de la charge de travail de clés API statiques vers 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é, authentifiant les requêtes automatisées sans stocker d'identifiants statiques sur disque.

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é. Ce document est un JSON Web Token (JWT) signé par un fournisseur tiers de confiance tel que GitHub, GitLab ou GCP.
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 plutôt que d'une clé API statique.
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 charges de travail externe. Un administrateur DevOps crée des connexions au statut Brouillon, et un administrateur de la sécurité doit les promouvoir au statut Actif pour activer l'émission de jetons. Remarque : Une connexion à la charge de travail 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, ce qui empêche une charge de travail d'obtenir par inadvertance un accès pendant les tests.
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 `wl_`) dérivé automatiquement de leur rôle de charge de travail. Ce mécanisme vérifie l'identité de la machine afin d'émettre de façon dynamique des certificats SSH de courte durée, permettant des connexions machine à machine sécurisées avec des privilèges de niveau zéro. Voir Accès SSH principal pour les charges de travail automatisées.

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é.

Un administrateur DevOps crée un brouillon de connexion à la charge de travail pour définir l'URL JWKS du fournisseur externe et les demandes de validation. 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.

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.

À l'exécution, la charge de travail s'authentifie en présentant son 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.

Rubriques

Configurer les charges de travail

Configurer une connexion de charges de travail

Configurer les rôles de charge de travail

Accès SSH principal pour les charges de travail automatisées