Rôles et permissions
SecureCodingHub utilise le contrôle d'accès basé sur les rôles à l'intérieur de chaque organisation avec deux rôles. Chaque rôle a un ensemble défini de permissions à travers les surfaces admin et l'expérience apprenant.
Vue d'ensemble des rôles
Chaque utilisateur de votre organisation se voit attribuer l'un des deux rôles. Les valeurs d'énumération interne sont org_admin et learner ; l'interface admin les affiche sous les noms lisibles ci-dessous.
| Rôle | Description |
|---|---|
| Administrateur de l'organisation | Administrateur au niveau de l'organisation. Gère les utilisateurs, équipes, affectations, cours personnalisés, SSO, SCIM, SCORM, clés API, webhooks, journal d'audit, rapports de conformité et paramètres de l'organisation. A accès au tableau de bord d'administration. |
| Apprenant | Rôle utilisateur standard pour tous les développeurs. Termine les challenges de pratique et les scénarios d'apprentissage, suit sa progression personnelle, gagne de l'XP et gère ses propres préférences technologiques. |
Matrice des permissions
Le tableau suivant montre quelles permissions sont disponibles pour chaque rôle :
| Permission | Administrateur de l'organisation | Apprenant |
|---|---|---|
| Voir le tableau de bord d'administration | ✓ | ✗ |
| Gérer les utilisateurs (ajouter, modifier, supprimer) | ✓ | ✗ |
| Gérer les équipes | ✓ | ✗ |
| Créer et gérer les affectations | ✓ | ✗ |
| Construire et gérer les cours personnalisés | ✓ | ✗ |
| Configurer SSO | ✓ | ✗ |
| Configurer le provisionnement SCIM | ✓ | ✗ |
| Générer des packages SCORM | ✓ | ✗ |
| Gérer les clés API | ✓ | ✗ |
| Gérer les points de terminaison webhook | ✓ | ✗ |
| Voir le journal d'audit | ✓ | ✗ |
| Voir les tableaux de bord de conformité | ✓ | ✗ |
| Générer des rapports de conformité / formation | ✓ | ✗ |
| Modifier les paramètres de l'organisation (classement, seuil) | ✓ | ✗ |
| Terminer les challenges de pratique | ✓ | ✓ |
| Terminer les scénarios d'apprentissage | ✓ | ✓ |
| Voir sa propre progression et ses affectations | ✓ | ✓ |
| Voir le classement (lorsque l'organisation le permet) | ✓ | ✓ |
Modification des rôles
Les administrateurs d'organisation peuvent promouvoir un apprenant en Administrateur de l'organisation ou rétrograder un administrateur d'organisation en Apprenant dans leur organisation. Les changements de rôle prennent effet immédiatement à la prochaine requête de l'utilisateur. Chaque changement de rôle est écrit dans le journal d'audit avec l'acteur, la cible et l'horodatage.
Bonnes pratiques
Minimiser les administrateurs d'organisation
Gardez le nombre d'administrateurs d'organisation à 2-3 par organisation. Cela limite la surface d'attaque pour une mauvaise configuration accidentelle et garde les pistes d'audit propres.
Apprenant pour les développeurs
Utilisez le rôle Apprenant pour tous les développeurs. Ils obtiennent un accès complet au contenu de formation, au suivi de la progression et aux préférences technologiques sans aucune capacité d'administration.
Choix des rôles pour votre organisation
La conception des rôles à l'intérieur d'une plateforme de formation semble moins critique que la conception des rôles à l'intérieur des systèmes de production, et c'est exactement pourquoi elle a tendance à être faite avec négligence. La plateforme de formation détient des données sur qui sait quoi, quelles équipes sont les plus faibles sur quels sujets et quels ingénieurs ont terminé la formation obligatoire de conformité. Ces données sont sensibles en soi — à la fois comme information concurrentielle et comme preuve dans les conversations d'audit — et le modèle de rôle devrait refléter cela.
Administrateur de l'organisation versus délégation aux chefs d'équipe
La tentation dans les organisations en croissance est de faire de chaque manager d'ingénierie un administrateur d'organisation pour qu'il puisse gérer ses propres équipes sans déposer de tickets. Le coût de ce schéma apparaît plus tard. Les administrateurs d'organisation peuvent voir les données de chaque équipe, pas seulement la leur, ce qui signifie qu'un manager peut voir comment l'équipe d'un pair performe sans que ce pair le sache. Ils peuvent aussi réattribuer des utilisateurs entre équipes, changer les échéances sur des affectations qu'ils n'ont pas créées et modifier la configuration SSO. Pour la plupart des organisations, deux ou trois administrateurs d'organisation est le bon plafond — généralement le responsable de l'ingénierie ou AppSec plus un ou deux administrateurs désignés.
Pour les opérations au niveau de l'équipe au quotidien, le meilleur schéma est de garder les chefs d'équipe comme Apprenants et de leur donner le filtre du tableau de bord pour leur équipe. Ils obtiennent la visibilité dont ils ont besoin sans le pouvoir de configuration qu'ils n'ont pas. Si un chef d'équipe a besoin de créer une affectation pour son équipe, l'administrateur d'organisation peut le faire en quelques minutes — bien moins cher que le coût à long terme d'accorder un accès administratif permanent à un groupe plus large que nécessaire.
Moindre privilège et journalisation d'audit
Le principe du moindre privilège s'applique à l'intérieur de la plateforme de formation tout comme partout ailleurs. Chaque administrateur d'organisation supplémentaire est un identifiant de plus dont la compromission permet à un attaquant de lire vos données de formation, de modifier votre configuration SCIM ou d'accorder discrètement un accès administrateur à son propre compte externe. Le moindre privilège pratique ici signifie utiliser Apprenant par défaut pour les nouveaux embauchés, promouvoir uniquement lorsque le besoin opérationnel est clair et rétrograder rapidement lorsque quelqu'un change de rôle.
Les changements de rôle et les actions administratives significatives sont enregistrés avec horodatages et identité de l'acteur pour la même raison que les systèmes de production journalisent les actions privilégiées. Lorsque quelque chose tourne mal — un utilisateur est supprimé qui ne devait pas l'être, une affectation est changée quelques jours avant un audit, une équipe est supprimée par erreur — le journal d'audit est l'artefact qui vous permet de reconstruire ce qui s'est passé. Gardez cela à l'esprit lorsque vous accordez des droits admin, car la piste d'audit sera éventuellement lue par quelqu'un, et un petit groupe d'administrateurs rend le journal lisible. Pour les détails sur la gestion des personnes à l'intérieur de ces rôles, voir Gestion des utilisateurs.