Administrateurs RBAC V3

Sur l'onglet Settings > Administration > Administrators & Roles page > Administrators , vous pouvez voir la liste de tous les administrateurs configurés pour votre organisation.

Pour chaque administrateur, vous pouvez voir les éléments suivants :

• Name: email ou nom d'utilisateur de l'utilisateur/invité.
• StatusL'option Actif ou En attente s'affiche selon que l'utilisateur a accepté ou non l'invitation.
• TypeLe rôle de l'administrateur : affiche le type de rôle de l'administrateur (utilisateur ou compte de service).
• Provisioned By: le type d'utilisateur/rôle qui a créé l'utilisateur admin (local, SCIM ou SAML).
• Role: le niveau d'accès de l'administrateur aux domaines fonctionnels, les permissions sur les pages et l'accès aux fichiers. Il s'agit du rôle choisi, qui peut être prédéfini ou personnalisé.
• API CredentialLe statut du jeton REST API : affiche le statut du jeton REST API, la date d'expiration du jeton, l'option pour générer/modifier/révoquer le jeton. 
• MFALe bouton : affiche l'état, Désactivé/Activé.
• Last LoginDate et heure de la dernière connexion de l'utilisateur.
• Authla méthode par laquelle l'administrateur a été authentifié, par ex. Clé API, etc.
• EllipsesCliquez sur pour modifier/désactiver l'administrateur, générer/modifier/révoquer le jeton ou supprimer l'utilisateur de la liste des administrateurs.

Vous pouvez filter la liste des administrateurs en

• Nom
• Role
• Approvisionné par (local, SCIM ou SAML)
• Type (compte d'utilisateur ou compte de service)

En cliquant sur Clear all filters, vous effacez les sélections de filtres et en cliquant sur Clear and remove all filters, vous effacez les sélections et supprimez les filtres de la barre d'affichage Filtres.

Tenant Admins

Dans le contrôle d'accès basé sur les rôles (RBAC) V3, un Tenant Admin dispose du plus haut niveau d'autorisations administratives au sein de son locataire/compte, y compris la capacité de gérer d'autres administrateurs et rôles. Toutefois, lorsqu'un utilisateur tente de créer ou de cloner un rôle, l'autorisation “Administration > Admins > Manage” est intentionnellement désactivée pour tous les rôles autres que le rôle principal Tenant Admin.

Il s'agit d'une fonction de sécurité essentielle conçue pour empêcher l'escalade des privilèges.

The Purpose of the Security Control
La principale raison de ce comportement est de maintenir un cadre RBAC sécurisé et robuste. La possibilité de gérer d'autres administrateurs et rôles est un privilège unique réservé exclusivement au rôle prédéfini Tenant Admin . Cette restriction est un principe fondamental de la conception RBAC V3 et s'applique à tous les rôles créés ou clonés par l'utilisateur, et pas seulement à ceux dérivés du rôle d'administrateur de locataire.
Voici pourquoi ce contrôle de sécurité a été mis en place :

• Preventing Privilege Escalation: Si n'importe quel utilisateur peut créer un rôle New et accorder la possibilité de gérer d'autres administrateurs et rôles, cela créerait une faille potentielle. Un acteur malveillant peut créer un rôle New avec cette autorisation, puis l'utiliser pour créer des utilisateurs ou des rôles New avec des privilèges encore plus élevés, contournant ainsi les contrôles de sécurité. Cela leur permet d'accorder un accès administratif complet à des utilisateurs non autorisés.
• Maintaining a Secure Hierarchy: Le modèle RBAC V3 est conçu avec une hiérarchie claire et sûre. Le rôle d'administrateur du locataire est l'administrateur principal du locataire/compte. Permettre à d'autres rôles, potentiellement moins contrôlés, de gérer les administrateurs compromettrait cette structure et rendrait difficile le suivi et le contrôle des autorisations administratives.
• Ensuring the Integrity of the RBAC System: En limitant l'autorisation "Gérer" au rôle original d'administrateur du locataire, le système garantit que les contrôles fondamentaux pour la création d'utilisateurs et de rôles restent dans un état fiable et non compromis. Cela permet d'éviter qu'un utilisateur ayant un rôle non standard ou cloné ne rende les contrôles RBAC inefficaces.

Expected Behavior

• Le seul rôle prédéfini qui possède la permission “Administration > Admins > Manage” est le Tenant Admin.
• Lorsque tout autre rôle est créé ou cloné, l'autorisation “Administration > Admins > Manage” sera grayed out and disabled. Il s'agit d'un choix de conception délibéré pour se protéger contre l'escalade des privilèges.

Cette conception garantit que seul l'administrateur des locataires désigné peut exécuter des fonctions critiques telles que la création de rôles New et la gestion des comptes d'utilisateurs, protégeant ainsi l'intégrité de l'ensemble du système.

Compte d'utilisateur local

Cliquez sur Settings pour accéder à la page Compte d'utilisateur local.

• Max Failed Login Attempt: spécifie le nombre minimum de tentatives de connexion qui peuvent être autorisées avant que l'utilisateur administrateur ne soit bloqué hors de l'interface utilisateur. Le minimum est de trois tentatives de connexion
• Idle Timeout: définit la fréquence d'interruption d'une session, le minimum étant de 5 minutes et le maximum de 60 minutes.
• Password Expiration: définir la fréquence d'expiration d'un mot de passe.
• Allow concurrent logins by the same adminPour interdire les connexions simultanées par le même administrateur, cochez la case correspondante. Cela signifie que si un administrateur se connecte à partir d'une deuxième instance de navigateur, il sera déconnecté de sa première session de navigateur.
• Verification Link Validity: définir le nombre d'heures et/ou de minutes pendant lesquelles le lien de vérification est valide.

Migration des utilisateurs locaux et SSO

Dans certains cas, vous pouvez avoir un utilisateur local et un utilisateur SSO avec la même adresse électronique. Si vous avez un utilisateur qui a à la fois un login local et un login SSO, après la migration vers RBAC V3, le "provisioned by" sera Local . Le rôle qui apparaît dans la colonne Rôle de l'interface utilisateur est celui qui a été attribué à l'utilisateur local.

Paramètres d'authentification de l'API REST

Cliquez sur Settings pour accéder à la page REST API Auth Settings.

Vos options incluent via API Key.

Ou via OAuth 2.0

Invitez un administrateur New

Naviguez jusqu'à la page Settings > Administration > Administrators & Roles > Administrators onglet > cliquez sur Invite

La page Invite s'affiche.

1. Saisissez l'adresse électronique de l'administrateur de New. Assurez-vous que le domaine de messagerie de l'administrateur de New fait partie des domaines du compte d'administration. 
2. Select un rôle dans la liste déroulante. Conseil : assurez-vous que le rôle existe avant d'inviter des administrateurs.
3. Optionnellement, activez le MFA pour l'administrateur.
4. Cliquez sur Terminé.

Netskope vous enverra un courriel de vérification avec une URL d'activation du compte. 

L'utilisateur administrateur de New peut modifier le mot de passe au cours de la procédure de vérification du compte. 

L'utilisateur recevra un deuxième courriel contenant le mot de passe à usage unique (OTP) à ajouter en plus de la modification de son mot de passe.

Le compte administrateur sera activé une fois la vérification du compte terminée. 

Allez dans Paramètres pour configurer la période de vérification. Les utilisateurs recevront un lien de vérification par courrier électronique lorsque l'administrateur crée ou réinitialise les mots de passe d'un compte local. Vous pouvez définir la durée de validité du lien de vérification. Le minimum est de 15 minutes et le maximum de 72 heures. 

Créez un compte de service New

Les comptes de service permettent aux administrateurs de créer des comptes d'administration non interactifs à utiliser avec les API REST. 

Naviguez jusqu'à la page Settings > Administration > Administrators & Roles > Administrators onglet > cliquez sur Service Account

La page New Service Account s'affiche.

1. Saisissez le nom du compte de service.
2. Select un rôle dans la liste déroulante. Conseil : assurez-vous que le rôle existe avant de créer un compte de service.
3. En option, vous pouvez générer un jeton API REST et définir l'expiration en nombre de jours.
4. Si vous le souhaitez, cochez la case pour générer le jeton ultérieurement.
5. Cliquez sur Create.

Pour générer le jeton ultérieurement à partir de l'étape 4 ci-dessus, accédez à la page de la liste des administrateurs et cliquez sur l'ellipse au bout de la ligne.

Understanding Authentication pour les comptes de service

Vous ne verrez pas d'option "Activer l'authentification multi-facteurs" (MFA) pour les comptes ayant le rôle Service Account. C'est un choix délibéré.

• Admin Accounts sont utilisés par les humains pour se connecter à l'interface utilisateur. Ils s'authentifient à l'aide d'un courriel et d'un mot de passe, et peuvent avoir recours à l'AFM en tant que couche de sécurité supplémentaire pour cette connexion interactive.
• Service Accounts sont non interactifs. Ils sont conçus pour l'accès programmatique à l'API Netskope et do not se connecter à l'interface utilisateur. Au lieu d’un mot de passe et d’une authentification multifacteur, ils s’authentifient à l’aide d’un API token sécurisé et révocable.

Comme les comptes de service n'ont pas de mot de passe et ne peuvent pas se connecter à l'interface utilisateur, l'AMF traditionnelle n'est pas applicable. La sécurité est assurée par la gestion et la protection appropriées de leurs jetons d'API.