Bundle de commandes sudo
Par défaut, les systèmes d'exploitation *nix prennent en charge deux niveaux d'accès utilisateur : le niveau utilisateur et le niveau super utilisateur (racine). L'ensemble de commandes sudo permet aux administrateurs d'accorder des autorisations granulaires aux utilisateurs sans leur donner un accès racine complet. Avec sudo, les administrateurs de sécurité Okta Privileged Access peuvent créer un système d'autorisations à plusieurs niveaux définissant les commandes exactes qu'un utilisateur peut exécuter en tant qu'autre utilisateur ou avec des autorisations de super utilisateur.
Les administrateurs de ressources peuvent créer, modifier et supprimer des ensembles de commandes sudo. Les administrateurs de sécurité peuvent utiliser des ensembles de commandes sudo prédéfinis pour spécifier un type de méthode accès spécifique pour un compte individuel au sein d'une règle de politique.
Types de commandes sudo
Il existe trois types de commandes sudo :
- Brute : ce type de commandes sudo permet aux utilisateurs d'exécuter uniquement une commande précise telle que définie par l'administrateur lors de la création de la commande sudo. L'administrateur peut définir n'importe quelle commande. Les utilisateurs ne pourront pas modifier la commande.
- Répertoire : ce type de commande sudo permet aux utilisateurs d'exécuter n'importe quelle commande dans le répertoire défini par l'administrateur lors de la création de la commande sudo. Il peut s'agir d'un répertoire UNIX conforme défini par une chaîne commençant et se terminant par le caractère « / », y compris le répertoire racine défini par le caractère « / ».
- Exécutable : ce type de commande sudo permet aux utilisateurs d'exécuter l'exécutable tel que défini par l'administrateur lors de la création de la commande sudo. L'administrateur peut déterminer si cette commande accepte les arguments Tous, Aucun ou Spécifique. Cette commande doit être un chemin d'accès UNIX conforme défini par une chaîne commençant par le caractère « / ».
Règles relatives aux ensembles de commandes sudo
Les ensembles de commandes sudo doivent observer les règles suivantes :
- Seuls les administrateurs de ressources Okta Privileged Access peuvent créer des ensembles de commandes sudo.
- Seuls les administrateurs de sécurité Okta Privileged Access peuvent ajouter des ensembles de commandes sudo à une politique, ce qui accorde aux utilisateurs des autorisations sudo sur les serveurs cibles.
- Les commandes sudo de type exécutable prennent également en charge les arguments Tous, Aucun ou Spécifique. Les commandes sudo de type raw et directory n'autorisent pas la spécification d'arguments supplémentaires.
- Les ensembles de commandes sudo doivent spécifier le chemin d'accès complet vers le répertoire du binaire à exécuter.
- Les noms des ensembles de commandes sudo peuvent contenir tout caractère alphanumérique à l'exception des espaces.
- Les descriptions des ensembles de commandes sudo peuvent contenir toute combinaison de caractères alphanumériques.
Fonctionnement des ensembles de commandes sudo
Lorsque les utilisateurs Okta Privileged Access tentent d'établir une connexion SSH avec un serveur Linux, une liste de méthodes accès disponibles leur est présentée. Si la fonctionnalité de commande sudo est configurée et que les utilisateurs se voient accorder un accès sudo via les paramètres de la politique, ils peuvent se connecter avec un accès de niveau sudo s'ils remplissent les conditions requises.
Les exemples suivants montrent comment les demandes de connexion sont évaluées en fonction des différentes configurations des politiques de sécurité et des méthodes d'accès présentées à l'utilisateur.
Exemples
Imaginons qu'un ingénieur SRE soit de service et qu'il ait besoin d'un accès sudo à certaines ressources pendant trois jours. ON-CALL et SRE sont les noms d'affichage d'un ensemble de lots de commandes sudo tels que définis dans la politique de sécurité. SRE contient les ensembles de commandes sudo 1, 2 et 3, et ON-CALL contient les ensembles de commandes sudo 4, 5 et 6.
- Politiques de sécurité comportant des conditions et droits d'accès sudo différents
-
- Politique de sécurité n° 1 : exige des Demandes d'accès et des conditions MFA pour obtenir un accès de niveau sudo à la collection d'ensembles de commandes sudo sous SRE.
- Politique de sécurité n° 2 : exige des Demandes d'accès et des conditions MFA pour obtenir un accès de niveau sudo à la collection d'ensembles de commandes sudo sous ON-CALL.
En fonction des politiques, l'utilisateur se voit proposer les méthodes d'accès suivantes pour obtenir un accès de niveau sudo :
The following access methods are available to access "S": 1: john.doe via SSH (sudo level individual account - SRE) Conditions: Condition Met? Approval - MFA - 2: john.doe via SSH (sudo level individual account - ON-CALL) Conditions: Condition Met? Approval - MFA -
- Politiques de sécurité comportant le même droit d'accès sudo et des conditions différentes
-
- Politique de sécurité n° 1 : exige une condition Demandes d'accès pour obtenir un accès de niveau sudo à la collection d'ensembles de commandes sudo sous SRE.
- Politique de sécurité 2 : exige une condition MFA pour obtenir un accès de niveau sudo à la collection d'ensembles de commandes sudo sous SRE.
En fonction des politiques, l'utilisateur se voit proposer les méthodes d'accès suivantes pour obtenir un accès de niveau sudo :
The following access methods are available to access "S": 1: john.doe via SSH (sudo level individual account - SRE) Conditions: Condition Met? Approval - 2: john.doe via SSH (sudo level individual account - SRE) Conditions: Condition Met? MFA -
- Politiques de sécurité comportant le même droit d'accès sudo et aucune condition
-
- Politique de sécurité n° 1 : exige une condition Demandes d'accès pour obtenir un accès de niveau sudo à la collection d'ensembles de commandes sudo sous SRE.
- Politique de sécurité 2 : ne comporte aucune condition et accorde un accès de niveau sudo à la collection d'ensembles de commandes sudo sous SRE .
En fonction des politiques, l'utilisateur se voit proposer la méthode d'accès suivante pour obtenir un accès de niveau sudo :
The following access methods are available to access "S": 1: john.doe via SSH (sudo level individual account - SRE)
Ordre de tri des ensembles de commandes sudo
Lorsque vous répertoriez un ensemble de commandes sudo dans le répertoire /etc/sudoers.d/, la sortie est triée par ordre lexicographique en fonction du nom de l'ensemble de commandes sudo. Le nom du fichier suit la structure suivante : <sudo_commands_bundle_name> -okta-<user_name> -<random_hash_value>.
L'ordre de tri est établi en analysant les valeurs dans l'ordre lexicographique, ce qui est semblable à la manière dont l'analyse est effectuée pour les fichiers du répertoire /etc/sudoers.d/ sur les systèmes Linux. L'ordre de priorité repose sur la séquence suivante : 0-9, A-Z, puis a-z.
Par exemple, prenons la liste suivante de fichiers définis dans le répertoire sudoers.d d'un système *nix.
01_abc_nginx-okta-user_name-d6e13ad78522b789a7f510eae4dbdc73 ABB_nginx-okta-user_name-de67ee27c291c25adb659937b1407368 01_ABc_nginx-okta-user_name-de67ee27c291c25adb659937b1407368 xyz_nginx-okta-user_name-de67ee27c291c25adb659937b1407368 01_FULL_NGINX-okta-user_name-d8cb7fddad549121afcf00d25fb75a36 01_full_nginx-okta-user_name-348c6f1a9070b4e1c4a65234ce223dbe 012_nginx-okta-user_name-de67ee27c291c25adb659937b1407368Les fichiers seront répertoriés dans l'ordre suivant.
user@12345:/etc/sudoers.d$ sudo visudo -c 012_nginx-okta-user_name-de67ee27c291c25adb659937b1407368: parsed OK 01_ABc_nginx-okta-user_name-de67ee27c291c25adb659937b1407368: parsed OK 01_FULL_NGINX-okta-user_name-d8cb7fddad549121afcf00d25fb75a36: parsed OK 01_abc_nginx-okta-user_name-d6e13ad78522b789a7f510eae4dbdc73: parsed OK 01_full_nginx-okta-user_name-348c6f1a9070b4e1c4a65234ce223dbe: parsed OK ABB_nginx-okta-user_name-de67ee27c291c25adb659937b1407368: parsed OK xyz_nginx-okta-user_name-de67ee27c291c25adb659937b1407368: parsed OK