Administration, identité et gouvernance

Équipe et rôles : inviter des membres, rôles intégrés et rôles personnalisés

L’accès à une organisation Plexicus repose sur les rôles, et la page Team affiche un rôle par membre.

Inviter un membre

Ouvrez Settings Team , cliquez sur Add member et remplissez la boîte de dialogue Invite a team member en indiquant l’adresse (Email address) et le rôle (Role). Cliquez ensuite sur Send invitation.

Les invitations s’adressent aux nouveaux utilisateurs. La personne invitée reçoit un e-mail pour créer un compte Plexicus et rejoindre votre organisation. Une adresse déjà associée à un compte Plexicus ne peut pas être invitée, et la réponse reste volontairement générique afin de ne pas révéler si ce compte existe. Demandez à vos nouveaux collègues d’attendre votre invitation plutôt que de s’inscrire d’abord : une inscription en libre-service crée normalement une organisation distincte, dont cette personne devient l’Admin. Chaque utilisateur appartient à une seule organisation ; il n’existe pas de sélecteur d’organisation.

Le membre apparaît comme Invited jusqu’à ce qu’il accepte, puis comme Active. Les liens d’invitation expirent : si un collègue laisse passer le délai, invitez de nouveau son adresse ; réinviter une adresse en attente avec un autre rôle met à jour cette invitation. Choisissez un rôle intégré lors de l’invitation, puis attribuez au membre un rôle personnalisé depuis la page Team une fois qu’il a rejoint l’organisation.

Avec le SSO et le provisionnement just-in-time, les utilisateurs obtiennent leur compte lors de leur première connexion via votre fournisseur d’identité : vous n’avez donc pas à les inviter un par un (leçon 2).

Modifier les rôles et retirer des membres

Utilisez la liste déroulante des rôles, sur la ligne d’un membre, pour modifier son rôle. Le nouveau rôle est attribué, le précédent est révoqué, et la notification « Role assignment updated » le confirme. Remove, sur une ligne, retire un membre actif ou annule une invitation en attente. Ces deux actions sont consignées dans le journal d’audit. Lorsqu’un ingénieur quitte l’entreprise, retirez-le le jour même, puis filtrez le journal d’audit sur son adresse e-mail pour examiner ses actions récentes.

Rôles intégrés

Par défaut, les rôles intégrés répartissent les responsabilités ainsi :

Rôle	Titulaire type	Ce qu’il permet	Ce qu’il ne permet pas
Admin	Responsable de la plateforme, responsable sécurité	Paramètres et connecteurs de l’organisation, membres, rôles, constats, dépôts et scans, AI pentests, ticketing et automatisations, facturation, journal d’audit	La configuration du SSO peut nécessiter des droits d’administration SSO distincts (leçon 2)
Cyberoper	Ingénieur sécurité	Trier les constats (mettre à jour, marquer comme faux positif, supprimer, envoyer aux développeurs), importer des rapports, générer des remédiations et des issues, créer, lancer et annuler des AI pentests, demander des scans, gérer les dépôts, les registres et les connexions à la gestion de code source ; consulter les automatisations	Ouvrir des pull requests, inviter des membres, gérer les rôles, consulter le journal d’audit
Developer	Ingénieur qui corrige le code	Consulter les constats, les remédiations, les dépôts, les exécutions de scans et les résultats AI Pentest ; ouvrir des pull requests et des issues, envoyer des tickets, télécharger les rapports et les exports (PDF et JSON) ; consulter les automatisations	Modifier le statut d’un constat ou marquer des faux positifs, générer des correctifs, lancer des scans, exécuter des pentests, administrer l’organisation

Avec les rôles par défaut, un Cyberoper prépare et relit un correctif, et un Developer ouvre la pull request. Le module 7 traite de ce passage de relais.

Rôles personnalisés

Selon votre offre, les Admins peuvent créer des rôles sous Settings Roles . Le tableau liste chaque rôle avec son Role Name, sa Description, son Type (un badge Built-in ou Custom) et Members, le nombre de personnes qui le détiennent.

Cliquez sur Create role, saisissez un Role Name et une Description, puis cochez des permissions dans la grille. La grille est regroupée par ressource, comme Client, Finding, Repository, Remediation et Scan, et chaque entrée porte une action read, write ou admin. Save reste désactivé tant que le rôle n’a pas de nom et au moins une permission, et les noms doivent être uniques au sein de votre organisation.

Les rôles intégrés ne peuvent être ni renommés ni supprimés. Sur la page Roles, leur ligne ne propose que Duplicate, qui ouvre le formulaire de création prérempli avec les permissions de ce rôle ; les rôles personnalisés affichent Edit et Delete.

Par exemple, vous voulez un rôle « Security Lead » qui fonctionne comme Cyberoper mais ne peut pas supprimer de constats. Dupliquez Cyberoper, nommez la copie Security Lead, décochez la permission de suppression des constats dans le groupe Finding, enregistrez, puis attribuez ce rôle depuis la page Team.

Identité : authentification unique, SCIM, authentification à deux facteurs et clés d’accès

Les utilisateurs se connectent avec GitHub, Google ou Microsoft, avec une adresse e-mail et un mot de passe, avec une clé d’accès, ou via Login via SSO, en saisissant le slug de connexion SSO de votre organisation. Les paramètres d’authentification se trouvent sous Settings Authentication , avec les lignes Two-factor authentication, SAML / SSO, Passkey et Active sessions.

Configurer le SSO

Ouvrez le hub SSO via Settings Authentication SAML / SSO Configure SSO . La configuration du SSO nécessite des droits d’administration SSO, que la documentation attribue aux Admins ; si la page vous refuse l’accès, demandez au support Plexicus qui les détient dans votre organisation. Le hub affiche le statut, le mode et le SSO Login Slug, le sélecteur de fournisseur, Verified Domains, SCIM 2.0 Provisioning, le lien Advanced settings vers la page Advanced SSO Settings, et Disable SSO, qui supprime la configuration. Les fournisseurs disponibles dépendent de votre offre.

Option du sélecteur	Protocole	Ce que vous fournissez
Okta, Azure AD / Entra ID	SAML 2.0	Assistant guidé
Google Workspace	OIDC (recommandé) ou SAML 2.0	Assistant guidé
Ironchip	SAML 2.0 ou OIDC	Assistant guidé
Generic SAML 2.0	SAML 2.0	IdP Entity ID, IdP SSO URL et certificat X.509 ; assertions signées exigées par défaut
Generic OIDC	OpenID Connect	Client ID, Client Secret, Discovery URL et scopes ; PKCE activé par défaut

Le slug compte de 3 à 64 caractères (lettres minuscules, chiffres, traits d’union ou points) et doit être unique parmi toutes les organisations Plexicus. Les valeurs côté fournisseur de services affichées par les assistants, comme l’ACS URL, l’Entity ID et l’URI de redirection OIDC, le contiennent : si vous modifiez le slug, mettez-les à jour dans votre fournisseur d’identité. Chaque assistant guidé se termine par Test, une validation à blanc qui n’enregistre rien, et Activate, qui enregistre la configuration.

Paramètres avancés : mode, JIT et mappage des groupes

Sur la page Advanced SSO Settings (le lien Advanced settings du hub), vous choisissez l’Authentication Mode. Les modifications prennent effet à la prochaine connexion de chaque utilisateur.

Mode	Comportement
Coexist (par défaut)	Le SSO et la connexion par mot de passe fonctionnent tous les deux
SSO Preferred	Le SSO est la méthode par défaut ; la connexion par mot de passe reste disponible en secours
SSO Enforced	Conçu pour être le seul moyen d’accès ; le produit indique que les connexions par mot de passe et par clé d’accès sont désactivées

JIT Provisioning, activé par défaut, crée un compte lors de la première connexion SSO d’un utilisateur, avec le rôle par défaut (developer, sauf si vous le modifiez). Les Group → Role Mappings priment sur ce rôle : le premier groupe IdP correspondant détermine le rôle. Si votre organisation dispose de domaines vérifiés, seules les adresses e-mail de ces domaines sont provisionnées, et une adresse appartenant à une autre organisation est refusée. Dans les versions actuelles, les mappages sont réévalués à chaque connexion SSO : déplacez une personne vers un autre groupe IdP et son rôle change à sa connexion suivante, avec une entrée dans le journal d’audit. Pour les utilisateurs membres d’un groupe mappé, gérez le rôle dans votre fournisseur d’identité ; une modification faite sur la page Team peut être écrasée à leur prochaine connexion.

Provisionnement SCIM

Le hub affiche votre SCIM Endpoint. Create SCIM Token émet un jeton valable 365 jours et ne l’affiche qu’une seule fois. Rotate émet un nouveau jeton et maintient l’ancien valide pendant 7 jours ; Revoke invalide immédiatement un jeton. Les jetons dont la validité restante est inférieure à 30 jours affichent Expiring soon. SCIM couvre les utilisateurs et les groupes : un utilisateur désactivé par votre fournisseur d’identité perd donc son accès sans intervention manuelle.

Authentification à deux facteurs et clés d’accès

Pour activer la 2FA, cliquez sur l’interrupteur de la ligne Two-factor authentication, scannez le QR code avec une application d’authentification et saisissez le code à 6 chiffres. La ligne affiche alors Manage.

Une clé d’accès vous connecte avec votre empreinte digitale, votre visage ou une clé de sécurité : cliquez sur Set up sur la ligne Passkey, puis sur Continue dans Link this device. Avec le SSO, la ligne Passkey indique Managed by SSO, et les clés d’accès se configurent alors dans votre fournisseur d’identité. La ligne Two-factor authentication reste inchangée.

Le journal d’audit : ce qui est enregistré, filtrage et intégrité

Le journal d’audit répond à la question « qui a fait quoi, et quand » pour l’ensemble de votre organisation. Selon votre offre, les Admins peuvent l’ouvrir via Settings Audit Log ; les autres rôles n’y ont pas accès.

Ce que vous voyez

Chaque ligne comporte un Timestamp, un Actor Type (User, System ou Integration), l’Actor, l’Action, le Resource Type, la Resource et des Details. L’icône en forme d’œil dans Details ouvre l’enregistrement complet avec ses métadonnées. Les mots de passe, jetons, clés d’API, secrets client, certificats et cookies sont remplacés par [redacted] avant l’enregistrement d’une entrée : le journal ne devient donc pas une seconde copie de vos secrets.

Filtrage

Vous pouvez combiner quatre filtres : un sélecteur Date range (avec des préréglages comme Last 7 days, Last 14 days et Last 30 days), Actor email (correspondance partielle), Action Type et Resource Type (User, Client, Repository, Finding, Remediation, Connector ou Role). Les résultats s’affichent par pages de 50, avec des boutons précédent et suivant, et un bouton de réinitialisation efface les filtres.

La liste Action Type couvre les actions d’administration les plus courantes :

Ressource	Actions
Utilisateurs	user.invited, user.removed
Organisation	client.settings_updated
Dépôts	repository.created, repository.deleted, repository.scan_triggered
Connecteurs	connector.added, connector.removed
Remédiation	remediation.created, remediation.updated
Constats	finding.status_changed
Rôles	role.created, role.deleted, role.assigned, role.revoked

Le journal enregistre davantage que cette liste. Il consigne aussi les connexions et déconnexions, les changements de mot de passe, la création et la révocation de jetons d’API, l’enregistrement de clés d’accès, les exports CSV et JSON (SARIF) de constats, les modifications d’automatisations, les modifications d’utilisateurs et de groupes via SCIM, les modifications de la configuration SSO et les connexions SSO, ainsi que les changements de rôle issus du mappage des groupes IdP. L’ouverture du journal d’audit est elle aussi enregistrée : sa consultation laisse donc sa propre trace.

Vérifier l’intégrité

Le journal rend toute falsification détectable. Chaque entrée stocke un hachage SHA-256 lié à l’entrée précédente de votre organisation. Si quelqu’un modifie ou supprime une entrée, la chaîne se rompt à cet endroit, et pour le dissimuler il faudrait réécrire toutes les entrées suivantes.

Vous vérifiez la chaîne via l’API Plexicus. Un Admin peut appeler le point de terminaison Verify Audit Log Chain Integrity à l’adresse /audit-logs/integrity-verification. Celui-ci recalcule la chaîne et renvoie valid: true lorsque tout concorde, ou valid: false avec un pointeur first_break vers la première entrée où la chaîne se rompt. Les entrées écrites avant l’arrivée du chaînage des hachages dans votre déploiement sont comptées comme des enregistrements antérieurs au chaînage et exclues du verdict, et la vérification ne porte que sur les entrées que votre organisation conserve encore. Le module 9 traite des jetons d’API et des appels à l’API.

L’utiliser comme élément de preuve

La durée de conservation dépend de votre offre et, pour les installations auto-hébergées, de votre configuration. Si un auditeur a besoin d’une période plus longue, récupérez les entrées nécessaires via l’API List Audit Logs avant qu’elles n’expirent.

Le journal d’audit facilite les revues d’accès, la reconstitution de la chronologie des incidents et les demandes des auditeurs. Plexicus fournit l’enregistrement et sa preuve d’intégrité ; il revient à vos auditeurs de déterminer si vos contrôles satisfont à un référentiel.

Paramètres de l’organisation : profil, réglementations, langue, propriété, IA et offres

Toute l’administration se trouve sous Settings, dans la barre latérale gauche, répartie en trois groupes. Organization regroupe Organization, Team, Roles et Ownership Verification. Configuration regroupe Integrations, Platform, Billing et BYOAI. My Account regroupe votre propre compte, l’authentification, les jetons et l’Audit Log. Roles et Audit Log ne sont visibles que par les Admins ; un utilisateur non administrateur qui ouvre directement leur adresse obtient une page « Page not found ». Billing et BYOAI s’affichent selon votre offre.

Profil de l’entreprise et réglementations

Ouvrez Settings Organization . La page comporte trois onglets, et chacun n’enregistre que sa propre section avec Save changes :

Profile affiche en lecture seule le nom de l’organisation, l’e-mail de facturation, l’identifiant de l’organisation et son propriétaire, ainsi que des informations modifiables sur l’entreprise : raison sociale, e-mail professionnel, URL de l’entreprise, société mère, identifiant global d’identité et catégorie.
Locations regroupe les emplacements du siège, des succursales, de service et de traitement des données, ainsi que les filiales.
Regulations vous permet de suivre les référentiels au regard desquels vous êtes audité. Plexicus y rattache les constats et produit des preuves (module 8) ; certains référentiels dépendent de votre offre.

Langue

Deux paramètres de langue sont faciles à confondre. Scan & Report Language, sur Settings Platform , s’applique à toute l’organisation : l’analyse IA, les descriptions des pull requests de correctif et les rapports PDF et JSON exportés sont produits dans cette langue. App Language, un onglet sous Settings Account , ne modifie que votre propre interface. Les deux proposent l’anglais et l’espagnol. La page Platform regroupe aussi les valeurs par défaut des scans et des correctifs (modules 3 et 7).

Vérification de propriété

La page Settings Ownership Verification permet aux Admins de gérer les domaines de toute l’organisation. Une cible de pentest nécessite soit un domaine vérifié, qui couvre ses sous-domaines, soit une vérification de l’application effectuée dans l’assistant AI Pentest. App Verification, sur cette page, est un relevé en lecture seule de ces vérifications d’application et peut être vide selon votre version. Les domaines vérifiés déterminent aussi les domaines e-mail acceptés par le provisionnement JIT du SSO. Le module 6 présente les deux méthodes en détail.

Configuration de l’IA

Par défaut, les scans s’exécutent sur les modèles de la plateforme Plexicus, et le code des clients n’est pas utilisé pour entraîner des modèles d’IA. Si votre offre l’inclut, BYOAI, sous Settings BYOAI , vous permet de les remplacer par vos propres modèles via le point de terminaison de votre fournisseur : un modèle Fast, un modèle Smart et un point de terminaison Embeddings obligatoire, enregistrés ensemble avec Save BYOAI configuration. Chaque bloc dispose de Test connection, et un unique bouton Reset to Plexicus default réinitialise les trois. Le module 7 explique le rôle de chaque emplacement.

Offres et droits d’utilisation

Votre offre détermine les fonctionnalités et le volume d’utilisation de l’IA dont dispose votre organisation. Settings Billing (Billing & Usage) affiche l’offre, la date de renouvellement, votre quota d’utilisation de l’IA avec la consommation du mois et sa date de réinitialisation, l’utilisation des sessions de pentest et Invoice History. Le menu de votre profil affiche les mêmes compteurs. Lorsque votre version l’inclut, une page Usage sous Settings ajoute une ventilation par action et un historique. Les quotas sont réinitialisés le 1er de chaque mois civil (UTC). Une fonctionnalité non incluse dans votre offre affiche une invitation à changer d’offre ou une boîte de dialogue Request Priority Access. Le module 7 explique ce qui est décompté du quota et ce qui se passe lorsqu’il est épuisé.

Sur Plexicus SaaS, Plexicus n’encaisse aucun paiement dans l’application. Un Admin sélectionne Request a plan change sous Billing, choisit l’offre et la périodicité de facturation, décrit l’utilisation prévue, puis envoie la demande. Une organisation ne peut avoir qu’une demande ouverte à la fois, dont vous suivez l’avancement sous Settings Billing Plan requests .

Statut	Signification
Received	Plexicus a bien reçu votre demande
In contact	L’équipe la traite avec vous
Offer sent	Une proposition commerciale vous attend pour examen
Invoiced	Vous avez accepté la proposition et la facture a été émise
Paid	La facture a été payée
Plan applied	Votre nouvelle offre est active
Rejected / Cancelled	La demande a été clôturée ; vous pouvez en envoyer une nouvelle

Options de déploiement pour les responsables de plateforme

Plexicus s’exécute en SaaS ou en auto-hébergé ; l’installation air-gapped est une variante de l’auto-hébergement.

Option	Lieu d’exécution	Qui l’exploite
SaaS UE	Hébergé par Plexicus sur app.plexicus.ai ; par défaut, les données SaaS restent dans l’UE	Plexicus, y compris les mises à jour
Auto-hébergé	Votre cluster Kubernetes, sur site ou dans un compte cloud que vous contrôlez, installé avec le chart Helm Plexicus	Votre équipe
Air-gapped (variante auto-hébergée)	L’installation auto-hébergée, sans accès sortant à Internet	Votre équipe

Pendant une maintenance, l’application affiche une page System Under Maintenance, ou Upcoming Update System pendant le déploiement d’une nouvelle version, et certaines fonctionnalités peuvent être brièvement indisponibles.

Auto-hébergement avec le chart Helm

Auto-hébergé et sur site désignent la même chose : un seul chart et une seule licence. Il vous faut un cluster Kubernetes conforme CNCF, en version 1.25 ou ultérieure. Plexicus vous remet un package de livraison comprenant un identifiant d’accès au registre, votre licence signée, un fichier d’environnement contenant la version de votre chart et vos paramètres d’IA et, pour la production, un fichier de valeurs pré-renseigné avec votre domaine. Vous fournissez le cluster, un domaine avec les enregistrements DNS de l’application et de l’hôte de l’API, un contrôleur d’ingress, le TLS via cert-manager ou vos propres certificats, une storage class qui conserve les volumes et, idéalement, un relais SMTP. Sans e-mail, vous déclarez que l’installation fonctionne sans messagerie, et les invitations passent alors par l’Admin : la réponse à l’invitation renvoie un lien de vérification à l’Admin qui invite, et celui-ci le transmet directement. Sans e-mail, la création du tout premier Admin nécessite aussi une étape de configuration supplémentaire décrite dans le guide d’installation.

Un déploiement auto-hébergé n’envoie aucune télémétrie hors de votre cluster. Seules les intégrations que vous configurez communiquent avec des systèmes externes, et les fonctionnalités qui dépendent des services commerciaux de Plexicus, comme la facturation, sont désactivées.

La licence est installée sous forme de secret du cluster avant l’installation du chart ; sans elle, les services principaux ne démarrent pas. Lorsque la licence approche de son expiration (30 jours ou moins), la page de connexion affiche « License expiring soon ». Après l’expiration vient une période de grâce, de 14 jours par défaut, puis « License expired » : l’accès est alors restreint jusqu’à ce que vous renouveliez la licence auprès de votre responsable de compte.

Installations air-gapped

L’installation air-gapped reprend le parcours Helm avec trois changements : mettre en miroir toutes les images dans un registre interne, faire pointer le chart vers ce miroir et remplacer l’autorité de certification publique par votre émetteur interne. Transférez le fichier de licence selon votre processus sécurisé habituel ; les vérifications de licence continuent de fonctionner hors ligne. Laissez non configurées les intégrations qui nécessitent l’accès à Internet, et fournissez à la plateforme un point de terminaison d’IA qu’elle peut joindre, y compris un point de terminaison d’embeddings, faute de quoi Deep Code Analysis ne peut pas s’exécuter. Pour une mise à niveau, mettez d’abord en miroir la nouvelle version, puis lancez la mise à niveau avec cette version exacte.

GitOps

Si vous utilisez déjà ArgoCD, il peut réconcilier le même chart depuis Git au lieu d’un helm install manuel. Les manifestes de référence sont fournis dans le chart. Épinglez le chart sur une version exacte, conservez les valeurs dans Git et ne commitez jamais de secrets en clair : utilisez des sealed secrets, un opérateur de secrets externes ou des fichiers chiffrés.

Sauvegarde et restauration

L’état de la plateforme réside à trois endroits : la base de données principale (constats, utilisateurs, dépôts, résultats de scans), la base de données de l’historique des workflows et le stockage objet (artefacts de scan, entrées et sorties de l’IA, rapports). Sauvegardez les trois ensemble, car une sauvegarde de la seule base de données peut référencer des artefacts dont vous ne disposez plus.

Plexicus est une charge de travail sur votre cluster. Le provisionnement du cluster, le durcissement des hôtes, le DNS, la confiance TLS, la politique réseau, la supervision et les sauvegardes restent sous votre responsabilité.

Points clés à retenir

Invitez les personnes depuis Settings Team avant qu’elles ne s’inscrivent d’elles-mêmes, attribuez-leur le rôle le plus restreint qui convient, et utilisez Duplicate pour transformer un rôle intégré en rôle personnalisé.
Le SSO prend en charge SAML 2.0 et OIDC via des assistants guidés ou des configurations génériques. Ne passez de Coexist à SSO Enforced qu’après un test à blanc réussi au cours des dernières 24 heures, et laissez JIT, les mappages de groupes et SCIM synchroniser les comptes avec votre fournisseur d’identité.
Les utilisateurs peuvent ajouter une application d’authentification et une clé d’accès ; lorsque votre organisation utilise le SSO, les clés d’accès sont gérées dans votre fournisseur d’identité.
Le journal d’audit est réservé aux Admins et filtrable par date, acteur, action et ressource ; il masque les champs contenant des secrets et il est protégé par une chaîne de hachage SHA-256 que vous vérifiez via l’API.
Les paramètres de l’organisation couvrent le profil de l’entreprise, les réglementations, deux paramètres de langue distincts, la vérification de propriété, BYOAI et les demandes de changement d’offre ; sur SaaS, Plexicus n’encaisse aucun paiement dans l’application.
L’auto-hébergement exécute le même produit à partir du chart Helm avec une licence signée ; l’installation air-gapped ajoute la mise en miroir et un émetteur interne, et chaque mise à niveau commence par une sauvegarde des trois emplacements de données.