RBAC V3 représente un changement architectural fondamental vers un modèle décentralisé, "API First". Cela garantit que les contrôles de sécurité et les autorisations sont cohérents à la fois dans l'interface WebUI et dans l'API REST, ce qui permet d'établir une posture de sécurité unifiée. La migration vers la V3 est une évolution obligatoire de la plateforme pour toutes les fonctionnalités de New Netskope .
Concepts clés et bonnes pratiques
- Service Accounts: Un New workflow pour l'accès programmatique aux API via des comptes de service basés sur les rôles, remplaçant le système de jetons V2 obsolète. Une critical best practice consiste à copier et stocker en toute sécurité le jeton API immédiatement après sa création, car il n’est affiché qu’une seule fois.
- Principle of Least Privilege (PoLP): L'accent est mis sur la création de rôles personnalisés avec les autorisations minimales nécessaires pour une fonction donnée. Cela réduit le "rayon d'action" potentiel d'un compte compromis et inclut la création de rôles dédiés pour les comptes de service avec des permissions d'interface utilisateur désélectionnées.
- Label-Based Access Control (LBAC): Extension de RBAC V3 avec un contrôle d'accès puissant au niveau de l'objet via un système d'étiquetage hiérarchique. Les principaux cas d'utilisation comprennent l'administration déléguée (multitenancy), la séparation visuelle des configurations automatisées et l'application d'un modèle d'accès "Zero Trust".
- “Roles First” Workflow: Créer et configurer des rôles before en ajoutant des administrateurs est une pratique fondamentale.
- Object Dependency Matrix (ODM): Examinez et réenregistrez tous les rôles personnalisés après la migration vers RBAC V3 afin de déclencher l'ODM et de vous assurer que les rôles sont fonctionnels.
Avantages de RBAC V3
- Simplify Administration: Réduisez considérablement le nombre de rôles personnalisés à gérer en identifiant et en consolidant les configurations redondantes.
- Enhance Security: Éliminez les rôles redondants afin de garantir un modèle d'autorisation cohérent, contrôlable et sécurisé, basé sur les privilèges les plus bas.
Permissions maximales RBAC V3
Il y a des changements d’autorisations pour les rôles personnalisés lors de la migration vers RBAC V3. La raison principale de ce changement est l’introduction d’un concept de sécurité New dans RBAC V3 appelé Max Permissions.
Dans notre système précédent (RBAC V2), il était possible d'attribuer des autorisations à un rôle qui ne s'appliquaient pas logiquement à la fonction elle-même. L'exemple classique est l'attribution de la fonction "Gérer" au journal d'audit. Le journal d'audit est conçu pour être un enregistrement immuable et non modifiable des événements ; sa seule fonction est d'être lu ou consulté. Il n'y a rien à créer, à modifier ou à supprimer.
Par conséquent, l'autorisation "Gérer" pour le journal d'audit dans la version 2 de RBAC est en fait une autorisation "no-op" (pas d'opération) ; elle ne confère aucune capacité supplémentaire par rapport à l'autorisation "Voir" et peut être trompeuse.
RBAC V3 corrige ce problème en attribuant une autorisation maximale possible à chaque ressource du système. Pour le journal d'audit, l'autorisation la plus élevée et la seule logique est "Voir".
Comment la migration modifie les autorisations
Lors de la migration de RBAC V2 vers RBAC V3, le système vérifie automatiquement les autorisations dans chaque rôle personnalisé. Si un rôle dispose d'une autorisation qui dépasse la permission maximale New pour une ressource spécifique, le système l'ajuste automatiquement et correctement au niveau le plus élevé autorisé. Ce changement est une amélioration délibérée visant à renforcer la sécurité et la clarté du système d'autorisation de notre plateforme.
Example: Votre rôle personnalisé avait "Gérer" pour le journal d'audit dans RBAC V2.
The Logic: L'autorisation maximale pour le journal d'audit dans RBAC V3 est "View".
The Result: Le processus de migration corrige l'autorisation de "Gérer" en "Voir" afin de refléter la véritable fonctionnalité.
Cela permet de s'assurer que les autorisations d'un rôle sont claires et précises et qu'elles respectent le principe du moindre privilège, qui est une pratique exemplaire en matière de sécurité.
Principaux enseignements
No Loss of Functionality: Vos utilisateurs n'ont pas perdu de capacités réelles. Dans l'ancien système, un utilisateur ayant le droit de "gérer" dans le journal d'audit ne pouvait que le consulter, ce qui est exactement ce que permet le droit de "consulter" sur le site New .
Increased Clarity: Les autorisations sont claires. Les rôles représentent désormais avec précision ce qu'un utilisateur peut ou ne peut pas faire au sein de la plateforme.
Improved Security: En imposant des limites logiques aux autorisations, RBAC V3 fournit un cadre de contrôle d'accès plus sûr et plus robuste.