Cherchez-vous plus de granularité dans la gestion de la configuration d'Identity Threat Protection avec Okta AI ? Nous comprenons que la sécurité est un effort d'équipe, et que différents administrateurs ont des responsabilités différentes. Pour mieux aligner l'accès sur ces responsabilités et adhérer au principe du moindre privilège, Okta a publié une nouvelle fonctionnalité permettant d'étendre les rôles d'administrateur personnalisés à de nouvelles autorisations et de nouveaux types de ressources pour Identity Threat Protection avec Okta AI.
Qu'est-ce qu'Identity Threat Protection avec Okta AI ?
Identity Threat Protection avec Okta AI est un produit qui s'exécute dans Okta Workforce Identity. Il est soumis au modèle d'administration avec des utilisateurs/groupes affectés aux rôles d'administrateur.
Auparavant, nous avions endu la fonction Rles d'administrateur pour permettre la cration de Rles d'administrateur personnalisables. Cela comprenait deux parties bsp;:
- Exposition des autorisations de rôle qui étaient intégrées aux rôles d’administrateur standard, afin que des rôles personnalisés puissent être définis. Ces autorisations décrivent les opérations qui peuvent être effectuées sur des objets, comme « Gérer les utilisateurs », « Créer des utilisateurs » et « Modifier les états du cycle de vie des utilisateurs ».
- L'ajout d'Ensembles de ressources avec ressources permet de limiter les rôles d'administrateur à des ensembles de données spécifiques. Par exemple, vous pouvez avoir un ensemble de ressources pour tous les utilisateurs, leurs groupes et leurs applications dans un service spécifique afin de restreindre les rôles d'administrateur à ces seuls objets.
Nous avons maintenant étendu cette fonctionnalité pour inclure de nouvelles autorisations pour les opérations liées à la protection contre la menace de l'identité et de nouvelles ressources. Il ne s'agit pas d'une nouvelle fonctionnalité, mais d'une extension de l'ensemble des fonctionnalités existantes avec davantage de permissions et de types de ressources.
Rôles et permissions
Nous n'avons pas ajouté de nouveaux rôles, mais de nouvelles autorisations sont disponibles, notamment la possibilité de :
- Visualiser et gérer les risques pour les utilisateurs
- Visualiser et gérer les flux de récepteurs du cadre de signaux partagés (SSF)
- Consulter et gérer les politiques
- Afficher les rapports
- Configurer la déconnexion
- Créer un workflow
Lors de la définition des rôles, vous pouvez envisager d'inclure des autorisations pour bsp:
- Consulter ou modifier des utilisateurs : Comprend l'accès à la visualisation et à la modification des utilisateurs
- Effacer les sessions des utilisateurs : Fournit un accès administrateur pour effacer les sessions utilisateur
- Voir les groupes : Nécessaire pour que les administrateurs puissent voir les affectations de groupes dans la politique de risque de l'entité et la politique de session post-auth.
- Gérer les applications : Donne aux administrateurs la possibilité de configurer la déconnexion universelle pour une application.
- Exécuter le flux délégué : Permet d'exécuter un flux délégué à utiliser dans la stratégie de risque d'entité ou la stratégie de session post-authentification
- Afficher le flux délégué : Permet de visualiser un flux délégué
- Gérer les personnalisations : Requis pour que les administrateurs gèrent la politique de session post-authentification
Vous pouvez utiliser ces nouvelles permissions pour créer des rôles d'administrateur personnalisés pour Identity Threat Protection. Par exemple, vous pouvez étendre la capacité de visualiser et d'escalader les risques à vos administrateurs utilisateurs, mais avoir des rôles distincts pour la gestion des politiques et les intégrations SSF.
Pour une comparaison des autorisations de rôle pour différents rôles d'administrateur, consultez la documentation du produit.
Ensembles de ressources
Les ensembles de ressources sont des collections de ressources associées à des rôles d'administrateur afin d'accorder un accès administratif. Un rôle définit ce qu'un utilisateur peut faire (opérations) et un ensemble de ressources définit ce sur quoi ce rôle peut agir (données).
Deux nouveaux types de ressources ont été ajoutés pour cette fonctionnalité :
- Récepteur Shared Signals Framework (SSF)
- Stratégies (par exemple, stratégie de risque d'entité, stratégie de protection de session)
Ces derniers peuvent être combinés à d'autres types de ressources (tels que les utilisateurs, les applications, les groupes et les workflows) afin de prendre en charge un modèle d'administration déléguée.
Exemple de rôle d'administrateur personnalisé
Prenons l'exemple d'un rôle d'administrateur personnalisé pour un administrateur d'Identity Threat Protection qui couvre tous les aspects d'Identity Threat Protection, mais pas au niveau d'un rôle de Super Admin Okta.
Le rôle possède les permissions suivantes :
- User
- Désactiver les utilisateurs
- Suspendre des utilisateurs
- Effacer les sessions des utilisateurs
- Gérer le risque des utilisateurs
- Groupe
- Afficher un groupe et ses détails
- Application
- Consulter une demande et ses détails
- Workflow
- Afficher un flux délégué
- Exécuter un flux délégué
- Cadre de signaux partagés Récepteur
- Gérer les flux de récepteur Shared Signals Framework (SSF)
- Politiques
- Gérer les stratégies
Dans ce scénario, le rôle fournit un accès limité à l'utilisateur - la possibilité de voir (mais pas de modifier) les applications et les groupes de l'utilisateur et de voir le risque de l'utilisateur (mais pas d'accéder au profil de l'utilisateur ou aux appareils).
L'extension des rôles d'administrateur personnalisés au sein d'Identity Threat Protection permet un contrôle plus précis des autorisations d'administrateur. En ajoutant de nouvelles autorisations et de nouveaux types de ressources, les organisations peuvent créer des rôles spécifiques adaptés à la gestion d'Identity Threat Protection sans se fier uniquement aux privilèges de Super Admin. Cette amélioration renforce la sécurité et réduit les risques en permettant une allocation précise des responsabilités administratives, ce qui conduit à un déploiement plus sécurisé d'Okta.
Les fonctionnalités étendues permettent d'effacer les sessions utilisateur, d'élever le niveau de risque et de suspendre/désactiver l'utilisateur.
Cette mise à jour permet également d'accéder aux groupes, aux applications, aux stratégies de sécurité et à d'autres fonctions d'administration courantes, ainsi qu'à la possibilité de gérer les récepteurs SSF. Toutefois, elle ne permet pas la configuration de la déconnexion universelle pour une application.
Le rôle d'administrateur peut ensuite être délimité par les ressources dans un ensemble de ressources : applications, utilisateurs (par groupe), workflows, stratégies et groupes spécifiques. Lorsqu'elles sont combinées avec les autorisations nouvelles (et existantes), vous pouvez définir des administrateurs correctement autorisés et éliminer le besoin du rôle de super administrateur, réduisant ainsi les risques de ce rôle pour votre déploiement Okta.
Prêt à en savoir plus ? Consultez la documentation dans notre base de connaissances ou découvrez d’autres nouvelles fonctionnalités d’Identity Threat Protection avec Okta AI dans notre dernier article de blog.
