Modele de securite

Mugnsoft implemente un modele de securite en profondeur avec TLS mutuel, authentification JWT, stockage chiffre et controle d’acces base sur les roles.

Vue d’ensemble des couches de securite

Securite du transport (mTLS)

Toutes les communications inter-composants utilisent le TLS mutuel (mTLS). Le client et le serveur verifient mutuellement leur identite a l’aide de certificats X.509.

Cycle de vie des certificats

1. Generation – Chaque composant genere un certificat TLS auto-signe et une paire de cles RSA lors de l’installation
2. Echange – Pendant l’auto-enregistrement, le composant televerse son certificat vers le Webserver
3. Verification – A chaque requete HTTPS, les deux parties verifient le certificat de l’autre
4. Renouvellement – Les certificats peuvent etre recharges sans redemarrer le service via le point de terminaison API /reloadCertificates

Stockage des certificats

<install_dir>/
├── config/
│   ├── sec/                          # RSA key pairs (JWT signing)
│   │   ├── mugnsoft_<component>.key      # Private key
│   │   └── mugnsoft_<component>.key.pub  # Public key
│   └── ssl/                          # TLS certificates
│       ├── certificates/
│       │   └── <component>.pem           # Certificate (public)
│       └── private/
│           └── <component>.key           # TLS private key

Configuration TLS

• Version minimale : TLS 1.2
• Suites de chiffrement : ECDHE uniquement avec GCM (chiffrement authentifie)
• Type de certificat : X.509 avec cles RSA de 2048 a 4096 bits

Authentification (JWT)

Mugnsoft utilise des jetons JWT RS256 pour toute l’authentification API. Les jetons sont signes avec des cles privees RSA et verifies avec les cles publiques correspondantes.

Types de jetons

Claims JWT

Chaque jeton contient ces claims :

{
  "id": "username",
  "group": "admin",
  "fullName": "John Doe",
  "accountType": "local",
  "email": "john@example.com",
  "tags": "production,web",
  "apps": "app1,app2"
}

Recherche de jeton

Les jetons peuvent etre fournis via :

• En-tete HTTP : Authorization: Bearer <token>
• Cookie : jwt=<token>
• Parametre de requete : ?token=<token>

Rafraichissement du jeton

Les jetons a courte duree de vie doivent etre rafraichis avant leur expiration :

curl -k -X GET https://<host>:<port>/refresh_token \
  -H "Authorization: Bearer <current_token>"

Controle d’acces base sur les roles (RBAC)

Roles utilisateur

Portee par tags

Les utilisateurs peuvent se voir attribuer des tags qui limitent leur visibilite. Un utilisateur avec les tags production,web ne verra que les moniteurs et composants partageant ces tags. Les utilisateurs Admin ont un acces illimite independamment des tags.

Limitation du debit

Les points de terminaison d’authentification sont proteges par une limitation du debit :

• 10 tentatives par adresse IP par fenetre de 5 minutes
• Les tentatives echouees sont suivies en memoire avec un nettoyage automatique

Chiffrement au repos

Configuration sensible

Tous les parametres sensibles (mots de passe, cles API, jetons) sont chiffres avant le stockage dans le magasin cle-valeur integre a l’aide d'AES-256-GCM (chiffrement authentifie avec donnees associees).

Les champs chiffres incluent :

• Identifiants SMTP
• Jetons Slack
• Webhooks Teams
• Cles API PagerDuty
• Identifiants InfluxDB/Splunk/Elastic
• Identifiants SASL Kafka
• Identifiants Vault

Hachage des mots de passe

Les mots de passe des utilisateurs sont haches avec bcrypt avant le stockage. Les mots de passe en clair ne sont jamais stockes.

Gestion des secrets (Integration Vault)

Le composant Monitor prend en charge l’integration avec des coffres-forts externes pour recuperer les identifiants au moment de l’execution :

Cela permet aux moniteurs de recuperer des mots de passe, des cles API et des secrets TOTP depuis un gestionnaire de secrets centralise au lieu de les stocker dans la configuration du moniteur.

Securite reseau

Flux reseau requis

Securite d’execution des scripts

Les composants qui executent des scripts personnalises (Monitor, Integrator, Discovery Agent) implementent :

• Validation du nom de script : seuls les caracteres alphanumeriques, tirets, underscores et points sont autorises
• Prevention du parcours de chemin : les scripts doivent resider dans le repertoire scripts/
• Delai d’execution : delai configurable (par defaut 30 secondes) avec arret force du processus
• Repertoire restreint : les scripts s’executent uniquement depuis le sous-repertoire scripts/ du composant

Validation de la licence

Le Webserver necessite un fichier de licence valide (license_MNS.dat) pour demarrer. Sans licence valide, le service ne s’initialisera pas et enregistrera une erreur fatale :

==> stopping the service/daemon since license is not valid

Les autres composants (Monitor, Integrator, Discovery Agent) valident egalement leur licence au demarrage.

Traductions

• en: Security Model