Replies: 6 comments
-
|
J'ai la meme question pour les bases de données et clusters: base de données: Cluster: Bon courage |
Beta Was this translation helpful? Give feedback.
-
|
Tu soulèves une vraie incohérence dans le modèle, et tu n'es pas le premier à la remarquer. Le champ La même logique s'applique aux bases de données ( L'idée de lier ces champs à des objets C'est cependant une modification du modèle de données qui demande une réflexion soigneuse pour ne pas casser l'existant (imports, exports, API REST, cartographies existantes). Je note cette demande comme un axe d'évolution à traiter. Un changement sera nécessaire à terme pour combler cette incohérence entre la couche physique et la couche logique. Si tu veux contribuer, proposer un modèle de migration ou une PR est la bienvenue |
Beta Was this translation helpful? Give feedback.
-
|
Bonjour Didier, Merci pour ta réponse et pour avoir confirmé l'incohérence — ça aide à bien cadrer le problème. Je ne suis pas développeur PHP/Laravel, mais voici une proposition conceptuelle que j'espère exploitable comme base de réflexion ou de PR. Le principe : une FK nullable, zéro impact sur l'existantL'idée centrale est simple : ne rien supprimer, juste ajouter une liaison optionnelle. On conserve les champs texte actuels ( Tant que ce champ est vide : comportement identique à aujourd'hui. Schéma du modèleerDiagram
applications {
int id
string name
string tag
}
physical_servers {
int id
string name
string operating_system
int os_application_id
}
logical_servers {
int id
string name
}
databases {
int id
string name
string technology_type
int technology_application_id
}
clusters {
int id
string name
string type
int technology_application_id
}
physical_servers ||--o| applications : "os_application_id (nullable)"
logical_servers }o--o{ applications : "relation existante"
databases ||--o| applications : "technology_application_id (nullable)"
clusters ||--o| applications : "technology_application_id (nullable)"
La relation sur Ce que ça donne côté UXDans le formulaire d'édition de chaque objet concerné, on ajoute un champ optionnel "Lier à une application", avec un filtre par tag pour ne proposer que les applications pertinentes :
Deux cas à gérer :
Le champ texte existant peut rester affiché en lecture seule pour ne pas perdre l'information historique. Bonus : suggestion automatique (optionnelle)Si on veut faciliter la migration des données existantes : quand Résumé des impacts
J'espère que cette approche est exploitable. La mise en œuvre concrète (migration, vue Blade, API) reste entièrement de ton côté, mais je suis disponible pour affiner le modèle ou répondre à des questions conceptuelles. Merci encore pour le projet et pour ton ouverture aux contributions ! Olivier |
Beta Was this translation helpful? Give feedback.
-
|
Bonjour Didier, Je continue de cogiter sur ce sujet, car avec l'arrivée des cartographes, il va falloir s'assurer de la cohérence et et la maturité. En partant du cas Champs identifiés comme candidats à une migrationJ'ai recensé 21 champs répartis en plusieurs catégories. 1. OS, SGBD et hyperviseurs → table
|
| Table | Champ actuel | Champ type |
Situation |
|---|---|---|---|
physical_servers |
operating_system (varchar) |
à créer | Permettrait cartes et traçabilité CVE via CPE |
databases |
type (varchar) |
existe déjà | Lien vers MariaDB, Oracle… |
clusters |
type (varchar) |
existe déjà | Lien vers Proxmox, VMware… |
workstations |
operating_system (varchar) |
à créer | Cohérence avec logical_servers |
2. Le champ responsible / owner — enjeu transversal
Ce champ apparaît dans au moins 10 tables (macro_processuses, processes, information, applications, databases, networks, physical_servers, peripherals, relations, data_processing) et est partout en varchar. La question est : vers quelle table le faire pointer ?
Je vois plusieurs options :
entities— pour une responsabilité organisationnelle (département, filiale)actors— pour une responsabilité fonctionnelle/métierroles— les rôles Mercator (cartographes, etc.), déjà associés à des utilisateurs réels de l'outiladmin_users— solution actuelle, qui mélange admins IT et responsables métier
Ma suggestion serait un paramètre de configuration du type responsible_target_type: 'entity' | 'actor' | 'role' | 'admin_user' qui permettrait à chaque organisation de choisir la cible. En Laravel, le pattern morphTo() / morphMany() semble adapté pour implémenter cela sans dupliquer les colonnes. Mais je t'avoue ne pas maîtriser les implications sur les imports/exports et l'API REST.
3. Zones de sécurité — confusion zone_admins / zones
La table zones (zones de sécurité physiques) affiche un champ "Utilisateurs" peuplé depuis zone_admins, qui ne contient que des admin_users. Pour une zone physique, le lien devrait pointer vers actors, roles ou entities selon le choix ci-dessus — pas vers des comptes d'administration.
Proposition : une table pivot zone_actors ou zone_roles distincte de zone_admins.
4. Sous-réseaux — champ zone firewall
Le champ subnetworks.zone (varchar) désigne une zone de filtrage firewall (ex : ZFW-DMZ, ZFW-LAN-PROD), pas une zone physique.
Depuis l'arrivée des ZOnes physiques, il y a une ambiguïté de nommage dans le modèle entre les zones physiques (zones) et les zones firewall. Ce champ mériterait d'être renommé (ex : firewall_zone) et lié à une petite table firewall_zones dédiée.
5. Postes de travail — liens utilisateurs (voir aussi #2198)
workstations.user_id pointe vers admin_users, ce qui n'a de sens que pour des postes d'admins. Pour un poste générique ou partagé (station industrielle, autologin), le lien devrait pointer vers actors ou roles.
6. Blocs applicatifs — usage multi-entités
Une application ne peut appartenir qu'à un seul bloc applicatif. Je pense que la contrainte 1-à-N doit être conservée pour préserver la responsabilité financière et de versionning end-to-end. En revanche, le besoin d'usage multiple pourrait être adressé côté entité : une table pivot application_block_entity permettrait à un département de déclarer qu'il utilise plusieurs blocs, sans toucher à la chaîne de responsabilité. Je ne sais pas si cela sort du périmètre du guide ANSSI.
Je ferme la discussion #2198 qui recouvre en partie ces sujets pour centraliser ici.
Encore merci pour le travail sur Mercator, c'est un outil vraiment utile. N'hésite pas à me dire si cette analyse est hors-sujet ou si certains points ont déjà été traités ailleurs.
Olivier
Beta Was this translation helpful? Give feedback.
-
|
Bonjour à tous, Ce post est très intéressant et je me pose les mêmes questions. J'ai pour ma part quelques retours personnels et par rapport à cette discussion. Relation Mercator est un outil de Cartographie, donc selon moi la mise en relation des objets doit être :
OS / Application L'OS n'est pas une application mais un support pour exécuter une application ou une base de données. Peut-être que s'il y a une table commune CPE, alors une vue Cartographie des Platform pourrait être intéressante pour connaitre
Homogéneisation des champs caractéristiques d'un matériel ou serveur logiciel Je pense que le renseignement des données suivantes OS devraient être homogènes : Partie Serveur/Equipement Physique/Routeur/Communicateur/Poste de travail Physique
Partie Serveur/Appliance Logique
Base de données :
Responsable / Administrateur Pour moi il y a vrai sujet car pour moi il faudrait nommer des rôles (la table Acteurs me parait très bien elle est censée recenser TOUS les Acteurs dans le Système) et associer ses rôles aux Utilisateurs ou des Entités. Associer plutôt des rôles à des Responsables Ainsi par exemple le Processus "Recevoir un appel" aurait un Acteur "Accueil" ou "Opérateur Appel" et serait un rôle dans Utilisateurs, de sorte à pouvoir identifier tous les utilisateurs qui ont le rôle "Accueil". Mais ça pourrait être une Entité (ex : Fournisseur SOC) Lien utilisateur Poste de Travail En principe le lien devrait être dynamique : |
Beta Was this translation helpful? Give feedback.
-
|
Pour résumer, aujourd'hui l'OS d'un serveur physique ( Du coup, contrairement aux serveurs logiques, ces éléments n'apparaissent pas comme des liens dans les cartes et ne profitent pas du mécanisme CVE/CPE. On va analyser ce point en détail dans les prochaines semaines pour proposer une amélioration cohérente — sans casser l'existant (imports/exports, API REST, cartes déjà en place). On vous tiens au courant ici. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Bonjour Didier,
J'ai un petit soucis de logique .
J'essaye de faire une carte avec serveurs physiques et logiques.
Et j'aimerais voir les os qui existent.
Pour serveur logique: l'os est un application donc j'ai bien le lien serveur logique --> application
Mais pour serveur physique c'est un champs operating_system, que l'on ne peut pas voir en lien dans une carte.
Ce qui serait bien, pour physical_server, c'est que l'on puisse lier l'os avec applications, pour mettre un name de application qui corresponde à un OS, plutôt que d’avoir un champs figé dans physical_servers, quitte à avoir un tag qui ne spécifie que les OS.
ex:
Merci
Olivier
Beta Was this translation helpful? Give feedback.
All reactions