Replies: 1 comment
-
|
Merci Olivier pour ces propositions bien détaillées 👍
Bonne idée — il existe déjà une table security_controls dans Mercator. Relier les informations à ces mesures a du sens, notamment pour le rôle de data owner. C'est en cours d'analyse pour une prochaine version.
Tout à fait pertinent, surtout pour l'archivage tardif. L'idée est de généraliser un champ attributes à la quasi-totalité des objets de la cartographie — c'est une réflexion en cours.
Dans la même logique, pouvoir personnaliser l'icône de (presque) tous les objets serait utile. C'est noté. Merci pour ta contribution ! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Bonjour Didier,
Et oui, encore des questions 😇 🙏 voire plutôt une proposition d'enhancement
J'ai vu dans une de tes vidéos que dans le futur tu penses ajouter des droits d'accès par type de métier.
Donc, j'en profite pour parler du role de data owner et sa relation avec l'IT
Dans information, on a un champs qui permet de mettre les règles RGPD, ce qui est bien
1) Je me demandais , si ce ne serait pas utile de rajouter un champ de liens vers les règles de sécurité aussi.
Les règles prédéfinis que tu proposes sont ISO27001:2022, ce qui est bien, mais en regardant il y en pas mal de redondante avec RGPD EU 30. (je fais le kéké, mais je n'y connais rien, je viens de regarder)
Ce qui serait utile, c'est que chaque data owner, au moment du référencement de son information, ajoute les règles qu'il veut, mais plus opérationnelle, comme NIST, ITIL, OCCAR, ITAR, CIS...
et que le data owner puisse piocher et les lier à ses informations..
Exemples:
{
"name": "[CIS-10.3] Backup 3-2-1 avec tests de restauration",
"description": "Sauvegardes quotidiennes incrémentielles + hebdomadaires complètes. 3 copies (1 locale, 2 distantes), dont 1 immuable (WORM). Tests de restauration mensuels. Applicable aux données critiques (ex : bases RH, contrats)."
},
{
"name": "[NIST-SI-12] Rétention des backups (7 ans)",
"description": "Conservation des backups pendant 7 ans pour les données archivées (ex : données fiscales, contrats). Stockage sécurisé (ex : bande magnétique, glacier AWS)."
},
{
"name": "[CIS-14.9] Centralisation des logs (SIEM)",
"description": "Tous les logs (système, applicatifs, accès) doivent être centralisés dans un SIEM (ex : Splunk, ELK). Rétention : 1 an pour les logs système, 6 mois pour les logs applicatifs."
},
{
"name": "[NIST-SI-4] Journalisation des accès aux données personnelles",
"description": "Journalisation obligatoire des accès aux données personnelles (qui, quand, quelle action). Logs conservés 2 ans et accessibles uniquement au SOC."
},
{
"name": "[CIS-5.1] Gestion des comptes (RBAC + MFA)",
"description": "Accès aux données sensibles restreint via RBAC (rôles : Data Owner, Admin, Lecteur). MFA obligatoire pour tous les accès distants. Revues trimestrielles des droits."
},
{
"name": "[NIST-SI-2] Chiffrement des données (AES-256)",
"description": "Chiffrement obligatoire pour les données personnelles au repos (ex : bases SQL) et en transit (TLS 1.3). Clés de chiffrement gérées via un HSM ou un service dédié (ex : AWS KMS)."
},
{
"name": "[ITIL-IncidentMgmt] Procédure de gestion des incidents",
"description": "Détection des incidents via SIEM/EDR. Escalade en <1h pour les incidents critiques (ex : fuite de données). Notification à la CNIL sous 72h si impact sur des données personnelles (RGPD Art. 33)."
},
{
"name": "[CIS-6.7] Surveillance continue (SOC)",
"description": "Surveillance 24/7 des systèmes critiques via un SOC (ex : détection d’intrusions, anomalies). Utilisation d’outils comme Wazuh, CrowdStrike, ou TheHive."
},
{
"name": "[RGPD-Art32] Pseudonymisation des données",
"description": "Pseudonymisation recommandée pour les données personnelles utilisées à des fins analytiques ou de test. Méthodes : hachage, tokenisation, ou outils dédiés (ex : GDPR Anonymization)."
},
{
"name": "[NIST-IR-4] Réponse aux incidents de sécurité",
"description": "Procédure formalisée pour la réponse aux incidents : identification, containment, éradication, récupération, et leçons apprises. Inclut la notification aux autorités (CNIL) si nécessaire."
},
{
"name": "[CIS-3.5] Gestion des configurations sécurisées",
"description": "Désactivation des services inutiles, application des correctifs de sécurité sous 30 jours, et configuration sécurisée des systèmes (ex : CIS Benchmarks pour Linux/Windows)."
},
{
"name": "[ITIL-ChangeMgmt] Gestion des changements",
"description": "Tout changement sur les systèmes traitant des données personnelles doit être validé via un processus de Change Management (ex : comité de changement hebdomadaire)."
},
{
"name": "[RGPD-Art30] Registre des traitements",
"description": "Documentation obligatoire des traitements de données personnelles : finalité, base légale, durée de conservation, responsables. Mise à jour annuelle minimum."
},
{
"name": "[CIS-1.4] Inventaire des actifs",
"description": "Inventaire à jour de tous les actifs (serveurs, bases de données, applications) traitant des données personnelles, avec responsable désigné (Data Owner)."
},
{
"name": "[NIST-AC-6] Revues d’accès trimestrielles",
"description": "Revues trimestrielles des droits d’accès aux données sensibles. Suppression des comptes inactifs après 90 jours."
},
{
"name": "[CIS-13.2] Protection des données en transit",
"description": "Utilisation de protocoles sécurisés pour les données en transit (ex : TLS 1.3, VPN avec chiffrement fort). Interdiction des protocoles non chiffrés (ex : HTTP, FTP)."
},
{
"name": "[ITIL-SLA] Accords de niveau de service (SLA)",
"description": "SLA pour la restauration des données : <4h pour les données critiques, <24h pour les données non critiques. Tests de restauration semestriels."
},
{
"name": "[RGPD-Art17] Droit à l’effacement",
"description": "Procédure pour répondre aux demandes d’effacement de données personnelles sous 30 jours. Inclut la suppression des backups et archives."
},
{
"name": "[CIS-4.8] Désactivation des comptes inactifs",
"description": "Désactivation automatique des comptes utilisateurs inactifs depuis 90 jours. Notification préalable à 30 et 60 jours."
},
{
"name": "[NIST-CM-8] Gestion des correctifs",
"description": "Application mensuelle des correctifs de sécurité critiques (ex : CVE avec score >7). Tests en environnement de pré-production avant déploiement."
},
{
"name": "[CIS-5.4] Durée et rotation des mots de passe",
"description": "Mots de passe d'une longueur minimale de 12 caractères, avec complexité (majuscules, minuscules, chiffres, symboles). Rotation obligatoire tous les 90 jours pour les comptes administrateurs et tous les 180 jours pour les comptes utilisateurs. Interdiction de la réutilisation des 5 derniers mots de passe. Utilisation d'un gestionnaire de mots de passe recommandée (ex : Bitwarden, 1Password)."
},
{
"name": "[NIST-IA-5] Authentification multi-facteurs (MFA) et durée des mots de passe",
"description": "MFA obligatoire pour tous les accès aux systèmes traitant des données sensibles. Les mots de passe doivent être changés uniquement en cas de suspicion de compromission (pas de rotation forcée sauf pour les comptes privilégiés, aligné sur NIST SP 800-63B). Utilisation de phrases de passe (passphrases) encouragée."
},
{
"name": "[OCCAR-SAR] Protection des données classifiées OCCAR",
"description": "Conformité aux exigences du Security Assurance Requirement (SAR) de l'OCCAR : chiffrement AES-256 pour les données au repos et en transit, stockage dans des environnements certifiés (ex : UE/Europe), accès restreint aux ressortissants des États membres de l'OCCAR. Audit annuel obligatoire par une autorité agréée."
},
{
"name": "[ITAR-EAR] Protection des données ITAR/EAR",
"description": "Conformité à l'International Traffic in Arms Regulations (ITAR) et Export Administration Regulations (EAR) : stockage exclusif sur des serveurs situés aux États-Unis ou dans des pays approuvés, accès limité aux citoyens américains (ou personnes autorisées via licence ITAR). Chiffrement FIPS 140-2 validé. Audit semestriel obligatoire."
},
{
"name": "[OCCAR-ITAR] Double classification OCCAR/ITAR",
"description": "Pour les données soumises à la fois à OCCAR et ITAR : application des exigences les plus strictes des deux réglementations. Stockage dans des environnements segmentés et certifiés, avec accès restreint aux personnes doublement habilitées. Revue trimestrielle des accès et audits annuels croisés."
}
2) Ajout d'un champ attributs pour mettre des metadata
dans le cas d'archivage de la donnée, on demande toujours quels métadata il serait nécessaire d'avoir. (peut-etre moins vrai avec l'IA)
Si un, champs attributs pouvait être présent, ça pourrait servir de méta data.. car générer des metadata, parfois 10 ans après mise on prod car on veut archiver, c'est parfois long et coûteux et souvent on ne retrouve plus ni le data owner, ni l'organisation responsable ( réorganisation et retraite)
3) Demande icon_id si possible dans information.
Ce serait bien, si possible d'avoir une icone différente sur des informations de type ou de criticité différentes en fonction du besoin..
Et voila.. Bonne lecture..
Olivier
Beta Was this translation helpful? Give feedback.
All reactions