Tableau de bord/Chapter 3/1.3 — Créer et gérer les Security Groups
Chapter 3 · leçon 3 sur 12
CertaviaPerson (identité) → User (login) → Security Group (autorisations) → Start Center (UI personnalisée). Ordre strict, FK NOT NULL à chaque maillon.READ (consulter), INSERT (créer), SAVE (modifier), DELETE (supprimer). Granularité par business object.Qualified (clause WHERE row-level), Conditional (expression runtime-évaluée), Hidden (attribut retiré de l'UI column-level).Security Groups app (flag Default cochet sur le record group). Auto-assignation aux nouveaux users.L'architecture de sécurité Maximo Manage repose sur une chaîne hiérarchique stricte de 4 entités. Chaque maillon est une étape obligatoire avant la suivante, validée par des contraintes FK au niveau base de données. Cette séparation est volontaire : elle permet de gérer indépendamment les identités (Person), les logins (User), les autorisations (Security Group) et l'UI (Start Center).
La logique métier sous-jacente : un Person représente une personne physique réelle (un humain dans l'organigramme), un User représente son compte d'accès aux systèmes, un Security Group regroupe les autorisations communes à un rôle métier (technicien, planner, controller), un Start Center personnalise l'UI selon ce rôle. Cette granularité permet de gérer 1 000 users avec ~10-20 Security Groups sans dupliquer les configurations individuellement.
People → Users → Security Groups → Start Centers. Inverser l'ordre est impossible (FK NOT NULL bloquent). Cette séparation permet d'auditer chaque couche indépendamment et de respecter les principes SOC2 / ISO 27001 de moindre privilège.Maximo applique strictement 4 permissions primitives sur chaque business object (WORKORDER, ASSET, LOCATION, PO, INVENTORY, etc.). Ces 4 verbes forment le CRUD basique et chaque permission peut être accordée ou refusée indépendamment. L'examen IBM teste systématiquement ces 4 noms — c'est un piège classique avec des distracteurs comme « UPDATE », « MODIFY », « VIEW », « CREATE » qui n'existent PAS dans Maximo.
| Permission | Verbe SQL | Action UI Maximo | Exemple révocation |
|---|---|---|---|
READ |
SELECT | Voir / lister / rechercher les records | WO confidentiels masqués pour group « stagiaires » |
INSERT |
INSERT | Créer un nouveau record (button New) | Group « consultation » ne peut pas créer de WO |
SAVE |
UPDATE | Modifier un record existant (button Save) | Read-only group peut consulter sans modifier |
DELETE |
DELETE | Supprimer un record (button Delete) | Personne ne peut supprimer hors administrateur |
APPR sur WORKORDER pour l'approbation workflow) — ce sont des permissions étendues, pas object-level standard.Les ODRs permettent de filtrer dynamiquement les données visibles ou éditables par un Security Group, sans modifier le schéma sous-jacent. Les autres groups voient toujours les données complètes. Maximo offre exactement 3 types, avec des portées de filtrage différentes : 2 row-level (Qualified, Conditional) et 1 column/attribute-level (Hidden).
| Type ODR | Portée | Mécanisme | Exemple concret |
|---|---|---|---|
Qualified |
Row-level | Clause SQL WHERE ajoutée à toutes les queries | « STATUS IN ('WAPPR','APPR') » pour cacher les WO terminés |
Conditional |
Row ou field | Expression évaluée au runtime via Conditional Expression Manager | « :user = assignedto » pour ne voir que ses propres WOs |
Hidden |
Field-level | Retire l'attribut de l'UI pour ce Security Group | Cacher SALARY pour groups non-HR |
L'accès multi-Sites se gère exclusivement via l'onglet Sites d'un Security Group. Cette approche est scalable : un admin sélectionne le group, ouvre l'onglet Sites, ajoute chaque Site autorisé (BEDFORD, NASHUA, etc.) ou coche « Authorize All Sites » pour accès global. Tous les users assignés héritent automatiquement de l'accès — aucune config per-user requise.
Avantage majeur : quand un Site s'ajoute ou se retire, on modifie le group une fois au lieu de mettre à jour 200 users individuellement. Anti-pattern à éviter : créer un user par Site et faire switcher les logins (multiplie la gestion, brise l'audit trail). Une autre erreur courante : tenter d'ajouter les Sites au record Person — le Person porte l'identité (email, phone, supervisor) mais pas les autorisations Site.
Les 5 confusions les plus fréquentes sur la sécurité à l'examen :
READ, INSERT, SAVE, DELETE. IBM utilise systématiquement les autres noms comme distracteurs.Q. Quelles sont les 4 permissions object-level par défaut dans Maximo Security Groups ?
Afficher la réponseREAD, INSERT, SAVE, DELETE. Pas CREATE, pas UPDATE, pas MODIFY, pas VIEW.
Q. Quels sont les 3 types d'Optional Data Restrictions (ODR) ?
Afficher la réponseQualified (clause WHERE row-level), Conditional (expression runtime row ou field), Hidden (attribut retiré UI column-level). 2 row-level + 1 column-level.
Q. Comment accorde-t-on l'accès multi-site à un user ?
Afficher la réponseVia l'onglet Sites d'un Security Group dans Security Groups app. Ajouter les Sites souhaités ou cocher Authorize All Sites. Tous les users assignés au group héritent automatiquement.
Q. Quelle est la chaîne de création complète pour qu'un nouveau user puisse se connecter ?
Afficher la réponse1. Person record (People app) → 2. User record (Users app, lié au Person via PERSONID) → 3. Assignation à ≥1 Security Group → 4. Start Center template associé au group. Ordre inverse impossible.
Bonne réponse : C
Pourquoi cette question existe — STU §3.3 — la question vérifie que le déverrouillage d'un compte verrouillé pour échecs de connexion se fait au niveau Suite (MAS), pas dans Manage. Les distracteurs proposent des changements de statut plausibles mais inexistants ou mal localisés. En pratique, chercher ce déverrouillage dans Manage People fait perdre du temps support.
Le contexte théorique d'abord — Lorsque le nombre de tentatives de connexion échouées dépasse le seuil configuré (Account lockout), le compte utilisateur est verrouillé au niveau Suite. Le déverrouillage se fait via MAS Suite administration > Users > action Unlock, et non via un changement de statut de Person dans Manage.
Ce que Maximo en fait — version opérationnelle — Dans Suite Administration > Users, l'administrateur sélectionne l'utilisateur verrouillé et applique l'action Unlock, qui réinitialise le compteur de tentatives échouées sans toucher au statut Person/User dans Manage.
Exemple chiffré — Avec un seuil configuré à 5 tentatives échouées, un utilisateur bloqué après sa 6ᵉ tentative reste verrouillé jusqu'à l'action Unlock, indépendamment des 0 changements de statut effectués côté Manage.
Analogie quotidienne — C'est comme un digicode qui se bloque après plusieurs codes erronés : seul le gestionnaire de l'immeuble (Suite administration), pas le locataire (Manage People), peut le réarmer.
Pourquoi A est faux — Pattern D6 mauvaise-app : le statut Person dans Manage People ne pilote pas le verrouillage de compte lié aux tentatives de connexion Suite.
Pourquoi B est faux — Pattern D2 inventé : désactiver le « Compliance enforcement » ne déverrouille pas un compte, et ce réglage n'a pas cette fonction.
Pourquoi D est faux — Pattern D6 mauvaise-app : Manage Users ne porte pas de statut BLOCKED/ACTIVE pilotant ce verrouillage ; le mécanisme est géré côté Suite.
Bonne réponse : C
Pourquoi cette question existe — STU §3.3 — cette question teste la capacité à diagnostiquer une erreur d'API REST (MXAPIxxxxxx) et à la résoudre au bon endroit : l'onglet Object Structures, pas l'onglet Applications ou Data Restrictions qui gèrent d'autres couches de sécurité. En pratique, cette erreur est l'une des plus fréquentes lors de l'intégration via REST API.
Le contexte théorique d'abord — Les objets MXAPIxxxxxx (ex. MXAPIASSET, MXAPIINVENTORY) sont des Object Structures exposées via API REST. L'accès à ces structures est contrôlé séparément de l'accès aux applications classiques, via l'onglet Object Structures du Security Group, où l'on accorde explicitement les droits READ/INSERT/SAVE par structure.
Ce que Maximo en fait — version opérationnelle — Dans Security Groups > sélectionner le groupe > onglet Object Structures > filtrer sur MXAPIASSET > cocher READ (et INSERT/SAVE si besoin pour les écritures). Sans ce droit, toute requête API échoue avec l'erreur citée, même si l'utilisateur a accès à l'application correspondante.
Exemple chiffré — Une intégration consommant 3 object structures (MXAPIASSET, MXAPIWO, MXAPIINVENTORY) nécessite 3 lignes d'autorisation distinctes dans l'onglet Object Structures, indépendamment des droits applicatifs déjà accordés sur les 3 applications correspondantes.
Analogie quotidienne — C'est comme avoir la clé de la porte d'entrée (l'application) mais pas celle du coffre-fort intérieur (l'object structure exposée en API) : il faut une autorisation distincte pour chaque niveau.
Pourquoi A est faux — Pattern D5 champ-frère : Data Restrictions filtre des lignes/colonnes selon condition, mais ne résout pas une absence totale de droit READ sur l'object structure.
Pourquoi B est faux — Pattern D6 mauvaise-app : l'onglet Applications gère les droits sur les applications classiques, pas sur les Object Structures exposées en API.
Pourquoi D est faux — Pattern D5 champ-frère : Global Data Restrictions s'applique transversalement à plusieurs groupes mais cible aussi des restrictions de données, pas l'octroi initial de READ sur un object structure.
Bonne réponse : C
Pourquoi cette question existe — STU §3.3 — la question identifie précisément l'application dédiée à la génération de clés API, distincte des applications de gestion des utilisateurs ou des groupes de sécurité. En pratique, confondre Users et API Keys retarde la mise en place d'intégrations REST sécurisées.
Le contexte théorique d'abord — L'application API Keys permet à un administrateur de générer une clé d'authentification pour un utilisateur Maximo préexistant, afin que des clients externes puissent s'authentifier aux API Maximo Application Suite sans utiliser le mot de passe de l'utilisateur.
Ce que Maximo en fait — version opérationnelle — L'administrateur se connecte avec un compte membre du groupe d'administration (ex. MAXADMIN), ouvre API Keys, sélectionne l'utilisateur cible (préalablement créé dans Users) et génère la clé. Les permissions de la clé héritent des droits déjà configurés pour cet utilisateur via ses Security Groups.
Exemple chiffré — Une intégration externe utilisant 1 clé API par système tiers (ex. 3 systèmes ERP/IoT connectés) nécessite 3 utilisateurs Maximo distincts, chacun avec sa propre clé générée dans API Keys.
Analogie quotidienne — C'est comme un badge magnétique distinct du trousseau de clés physique : le badge (clé API) permet d'entrer sans jamais connaître le mot de passe (les clés) du titulaire du compte.
Pourquoi A est faux — Pattern D5 champ-frère : Security Groups définit les droits d'accès, mais ne génère pas la clé d'authentification elle-même.
Pourquoi B est faux — Pattern D2 inventé : « Administration Work Center » n'est pas une application standard de génération de clé API dans MAS.
Pourquoi D est faux — Pattern D4 demi-vérité : Users sert à créer le compte cible, prérequis nécessaire, mais la génération de la clé se fait dans l'application API Keys.
Bonne réponse : A
Pourquoi cette question existe — STU §3.3 — cette question vérifie la compréhension du mécanisme général de cumul des droits dans Maximo lorsqu'un utilisateur appartient à plusieurs Security Groups, un point fondamental souvent mal interprété (croyance erronée que les restrictions s'additionnent au lieu des privilèges). Les distracteurs proposent des règles plausibles mais inversées ou inventées. En pratique, mal comprendre ce cumul mène à des audits de sécurité erronés.
Le contexte théorique d'abord — Le security profile d'un utilisateur est la liste cumulée des droits qu'il tire de tous les Security Groups auxquels il appartient. Lorsque des Data Restrictions diffèrent entre groupes pour la même donnée, Maximo accorde à l'utilisateur le privilège le plus élevé parmi tous les groupes — les droits se cumulent, ils ne se restreignent pas mutuellement.
Ce que Maximo en fait — version opérationnelle — Dans Security Groups > onglet Applications ou Data Restrictions, chaque groupe définit ses propres droits CRUD et restrictions par attribut/condition. L'utilisateur appartenant à plusieurs groupes (ex. Managers + Maintenance) reçoit l'union de ces droits via son Security Profile dans Users.
Exemple chiffré — Un utilisateur membre des groupes Managers (accès lecture/écriture sur le taux de paye) et Maintenance (pas d'accès au taux de paye) verra son accès final inclure la lecture/écriture du taux de paye : 2 groupes combinés → 1 droit final, le plus permissif des deux, sur les 3 attributs sensibles évalués (taux de paye, coût standard, marge).
Analogie quotidienne — C'est comme posséder deux badges d'accès dans un immeuble : si l'un ouvre la salle des serveurs et l'autre non, posséder les deux badges donne quand même accès à la salle des serveurs.
Pourquoi B est faux — Pattern D2 inventé : la date de création d'un groupe n'a aucune influence sur le cumul des droits dans Maximo.
Pourquoi C est faux — Pattern D3 inverse : c'est l'exact opposé de la règle réelle — Maximo retient le privilège le plus permissif, pas le plus restrictif.
Pourquoi D est faux — Pattern D4 demi-vérité : le groupe d'insertion par défaut (Default Insert Group) définit certaines valeurs par défaut à la création d'enregistrements, mais ne limite pas le cumul des droits d'accès des autres groupes.