PolicySync : contrôle d'accès basé sur les attributs.

Remarque :

Annonce de fin de vente

À compter du 1er mai 2026, Okta ne vendra ni ne renouvellera plus Advanced Server Access. Les clients existants doivent migrer vers Okta Privileged Access dans un délai d'un an suivant leur prochaine date de renouvellement prévue pour maintenir le service.

Consultez la FAQ pour en savoir plus sur Okta Privileged Access.

Cette fonctionnalité est déployée pour tous les clients Advanced Server Access jusqu'au premier trimestre 2023. Aucune action n'est requise de votre part pour activer cette fonctionnalité pour votre équipe Advanced Server Access.

Les équipes Advanced Server Access affectent souvent des ressources à des projets regroupés par produit ou par équipe. Par exemple, vous pouvez disposer de projets distincts pour vos équipes chargées de la comptabilité, du marketing et de l'ingénierie. La méthode standard pour accorder l'accès à un serveur Advanced Server Access aux utilisateurs est la suivante : enrôlement du serveur dans le projet, affectation des utilisateurs à un groupe et ajout du groupe au projet. Cette méthode accorde l'accès à tous les serveurs qui sont enrôlés dans le projet, et ce, pour tous les membres du groupe.

Cependant, il est souvent nécessaire d'accorder aux utilisateurs l'accès à un sous-ensemble de serveurs dans un projet. Vous pourriez disposer d'une équipe d'administrateurs de base de données ayant besoin d'accéder à tous les serveurs de base de données, quel que soit le projet dans lequel le serveur est enrôlé. Dans ce cas, la création d'un projet distinct contenant uniquement les serveurs de base de données briserait le modèle de regroupement des ressources par équipes. Okta PolicySync permet aux administrateursAdvanced Server Access d'appliquer des contrôles d'accès basés sur les attributs (ABAC) aux groupes d'utilisateurs. Ces contrôles peuvent être utilisés pour accorder un accès aux ressources en fonction de leurs différents rôles. Pour cela, des étiquettes doivent être appliquées aux serveurs et des sélecteurs doivent être appliqués aux groupes, de la même manière que les clients utilisent des sélecteurs d'étiquettes pour identifier les objets dans Kubernetes.

Remarque :

La fonctionnalité PolicySync permet d'accéder aux serveurs en fonction de sélecteurs d'étiquette. Les paramètres du groupe de projet (options d'accès administrateur ou utilisateur et tous les droits sudo associés au groupe de projet) déterminent les actions que l'utilisateur peut effectuer. Plus précisément, les droits sudo attribués à un utilisateur dépendent de l'ensemble des affectations sudo attribuées aux groupes de projet dont l'utilisateur est membre. La bonne pratique consiste à limiter les actions qu'un utilisateur peut effectuer à l'aide des affectations sudo. Cela garantit que les autorisations sudo ne sont configurées que sur le groupe de projet auquel l'utilisateur est affecté.

Remarque :

Lorsque PolicySync est activé dans un projet, un fichier .asa_authorized_principals est créé pour chaque utilisateur, contenant l'ID unique du serveur Advanced Server Access. Si le projet comporte des bastions derrière un équilibreur de charge sur l'option PolicySyncactivée, les connexions utilisateur sont susceptibles d'échouer si l'ID du serveur indiqué dans la requête de connexion ne correspond pas à celui du fichier.asa_authorized_principals. Okta recommande de ne pas activer PolicySync sur les bastions derrière un équilibreur de charge.

Concepts principaux de PolicySync
Utiliser des étiquettes et des sélecteurs pour les accès granulaires au serveur

Concepts PolicySync

Trois concepts principaux caractérisent l'utilisation de PolicySync : le fichier des commettants autorisés, les étiquettes et les sélecteurs. La section suivante vous offre une description de chaque concept.

Fichier des commettants autorisés

Okta PolicySync utilise l'option de configuration du daemon OpenSSH (sshd) AuthorizedPrincipalsFile. Consultez sshd_config pour obtenir plus d'informations sur AuthorizedPrincipalsFile.

Lorsque PolicySync est activé, l'agent du serveur Advanced Server Access crée le fichier .asa_authorized_principals dans le répertoire de base de chaque utilisateur, sur chacun des serveurs auxquels il a accès. Vous pouvez modifier cet emplacement en définissant une option AuthorizedPrincipalsFile dans le fichier de configuration sftd.yaml de votre agent du serveur Advanced Server Access. Pour configurer l'emplacement, vous devez utiliser l'un des jetons utilisateur pris en charge :

%h : s'étend au chemin d'accès du répertoire de base de l'utilisateur.
%u : s'étend au nom d'utilisateur de l'utilisateur.
%U : s'étend à l'identifiant unique (UID) de l'utilisateur.

Par exemple, si vous voulez configurer Advanced Server Access pour qu'il crée un fichier des commettants autorisés dans le répertoire de base de l'utilisateur, vous pouvez ajouter ce qui suit au fichier de configuration du serveur sftd.yaml :

AuthorizedPrincipalsFile: "%h/.asa_authorized_principals"

L'agent du serveur Advanced Server Access met également à jour le fichier sshd_config du serveur avec l'instruction AuthorizedPrincipalsFile définie dans sftd.yaml .

Remarque :

Bien que l'agent du serveur Advanced Server Access, sftd, modifie sshd_config, nous vous recommandons vivement de ne pas le modifier, que ce soit manuellement ou via l'automatisation. La modification du contenu de sshd_config peut entraîner des configurations non prises en charge ou incorrectes.

Étiquettes

Les étiquettes sont appliquées à des serveurs individuels et permettent aux équipes Advanced Server Access de catégoriser et de trier les accès aux serveurs. Vous pouvez appliquer un maximum de 50 étiquettes à un serveur.

Les libellés sont stockés au format key:value. Ce format offre une plus grande flexibilité aux équipes. Par exemple, un serveur peut porter deux libellés, env:prod et region:US. Étant donné que les étiquettes peuvent provenir de sources multiples, Advanced Server Access ajoute automatiquement un préfixe qui permet d'identifier la source de l'étiquette. Si l'étiquette env:prod provient de l'API Advanced Server Access, le préfixe api apparaît comme api.env:prod. Cette méthode permet d'éviter les conflits dans le cas où la même étiquette aurait été ajoutée à partir de plusieurs sources (par exemple, si une étiquette a été spécifiée à la fois par l'API et par un fichier de configuration de l'agent serveur Advanced Server Access).

Sélecteurs de serveurs

Les sélecteurs de serveurs sont appliqués aux groupes et contrôlent le nombre de serveurs disponibles pour les membres du groupe. Un maximum de 10 sélecteurs de serveur est disponible par groupe lié à un projet. Les sélecteurs de serveurs se caractérisent comme suit :

Les utilisateurs d'un groupe dans lequel des sélecteurs sont appliqués ont uniquement accès aux serveurs qui répondent à toutes les exigences de ce sélecteur.
Les utilisateurs qui appartiennent à plusieurs groupes ont accès aux serveurs qui appartiennent à l'union des sélecteurs de ces groupes.
Les clés des sélecteurs peuvent optionnellement spécifier la source de l'étiquette.

Si la source est spécifiée, seuls les serveurs qui contiennent l'étiquette de cette source correspondront. Par exemple, si vous utilisez le sélecteur sftd.role=db, seuls les serveurs dont le fichier de configuration sftd.yaml contient l'étiquette role: dbcorrespondront.

Si la source n'est pas spécifiée, tout serveur qui contient l'étiquette spécifiée correspondra. Par exemple, si vous utilisez le sélecteur role=db, tout serveur qui contient l'étiquette aws.role: db ou sftd.role: db correspondra.

ATTENTION :

Nous vous invitons à bien réfléchir à la manière dont vous configurerez vos étiquettes et vos sélecteurs. Assurez-vous que vos utilisateurs disposent d'une connectivité réseau avec les serveurs de leurs projets en utilisant les passerelles Advanced Server Access, si nécessaire, en fonction de la topologie de votre réseau.

Utiliser des étiquettes et des sélecteurs pour les accès granulaires au serveur

Conditions nécessaires

Pour utiliser des étiquettes et des sélecteurs dans un projet Advanced Server Access, il convient de vérifier les éléments suivants :

L'indicateur de fonction PolicySync doit être activé pour votre équipe Advanced Server Access.
Les serveurs du projet doivent exécuter l'agent serveur Advanced Server Access version 1.52.1 ou ultérieure.

Ajouter une étiquette à un serveur

Les équipes peuvent ajouter des étiquettes depuis le tableau de bord Advanced Server Access. De plus, les équipes peuvent ajouter des étiquettes directement dans le fichier de configuration de l'agent serveur (sftd.yaml). Consultez la section PolicySyncÉtiquettes.

Ouvrez le tableau de bord Advanced Server Access.
Cliquez sur Projets et ouvrez un projet.
Accédez à l'onglet Serveurs.
Cliquez sur l'icône de l'engrenage qui se trouve à côté d'un serveur et sélectionnez Modifier les étiquettes.
Saisissez une ou plusieurs étiquette(s) dans le champ Ajouter ou supprimer des étiquettes, et appuyez sur la touche Enter de votre clavier après avoir saisi chaque étiquette. Remarque : les étiquettes doivent respecter le format key:value.
Cliquez sur Soumettre pour enregistrer les étiquettes.

Ajout d'un sélecteur au groupe d'un projet

Les équipes peuvent assigner des sélecteurs au niveau du groupe d'un projet. Pour assigner un sélecteur :

Ouvrez le tableau de bord Advanced Server Access.
Cliquez sur Projets et ouvrez un projet.
Accédez à l'onglet Groupes.
Cliquez sur l'icône en forme d'engrenage et sélectionnez Modifier.
Sous Accès aux serveurs, sélectionnez Serveurs spécifiques.
Saisissez une ou plusieurs étiquette(s) dans le champ Balises de sélecteurs de serveurs et appuyez sur la touche Enter de votre clavier après avoir saisi chaque étiquette. Remarque : les étiquettes doivent respecter le format key:value.
Cliquez sur Mettre à jour le groupe pour enregistrer les sélecteurs.