Security Model

Mugnsoft implements a defense-in-depth security model with mutual TLS, JWT authentication, encrypted storage, and role-based access control.

Security Layers Overview

graph TB subgraph Transport["🔒 Transport Layer"] mTLS["mTLS (mutual TLS 1.2+)"] end subgraph Auth["🔑 Authentication Layer"] JWT["RS256 JWT Tokens"] RBAC["Role-Based Access Control"] RATE["Rate Limiting (10/5min)"] end subgraph Storage["🛡️ Storage Layer"] AES["AES-256-GCM Encryption at Rest"] BCRYPT["bcrypt Password Hashing"] end subgraph Secrets["🗄️ Secrets Management"] HASHI["HashiCorp Vault"] AZURE["Azure Key Vault"] CYBER["CyberArk Conjur"] end Transport --> Auth --> Storage Storage -.-> Secrets style Transport fill:#2c5ea0,stroke:#1a3a6a,color:#fff style Auth fill:#d9984f,stroke:#b07830,color:#fff style Storage fill:#5cb85c,stroke:#3d8b3d,color:#fff style Secrets fill:#9b59b6,stroke:#7d3c98,color:#fff

Transport Security (mTLS)

All inter-component communication uses mutual TLS (mTLS). Both the client and server verify each other’s identity using X.509 certificates.

Certificate Lifecycle

Generation – Each component generates a self-signed TLS certificate and RSA key pair during installation
Exchange – During self-registration, the component uploads its certificate to the Webserver
Verification – On every HTTPS request, both parties verify the peer’s certificate
Renewal – Certificates can be reloaded without restarting the service via the /reloadCertificates API endpoint

Certificate Storage

<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

TLS Configuration

Minimum version: TLS 1.2
Cipher suites: ECDHE only with GCM (authenticated encryption)
Certificate type: X.509 with RSA 2048-4096 bit keys

Authentication (JWT)

Mugnsoft uses RS256 JWT tokens for all API authentication. Tokens are signed with RSA private keys and verified with the corresponding public keys.

Token Types

Token Type	Lifetime	Use Case
User token	15 minutes	Web UI sessions, API calls
Component token	60 days	Inter-component communication
Long-lived token	1 year	Automation and CI/CD
Extended token	15 years	Permanent integrations

JWT Claims

Each token contains these claims:

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

Token Lookup

Tokens can be provided via:

HTTP header: Authorization: Bearer <token>
Cookie: jwt=<token>
Query parameter: ?token=<token>

Token Refresh

Short-lived tokens should be refreshed before expiry:

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

Role-Based Access Control (RBAC)

User Roles

Role	Permissions
Admin	Full access to all features, settings, users, and components
User	Can manage monitors and view data within their tag scope
Viewer	Read-only access to data within their tag scope

Tag-Based Scoping

Users can be assigned tags that limit their visibility. A user with tags production,web will only see monitors and components that share those tags. Admin users have unrestricted access regardless of tags.

Rate Limiting

Authentication endpoints are protected by rate limiting:

10 attempts per IP address per 5-minute window
Failed attempts are tracked in memory with automatic cleanup

Encryption at Rest

Sensitive Configuration

All sensitive settings (passwords, API keys, tokens) are encrypted before storage in the embedded key-value store using AES-256-GCM (authenticated encryption with associated data).

Encrypted fields include:

SMTP credentials
Slack tokens
Teams webhooks
PagerDuty API keys
InfluxDB/Splunk/Elastic credentials
Kafka SASL credentials
Vault credentials

Password Hashing

User passwords are hashed using bcrypt before storage. Plaintext passwords are never stored.

Secrets Management (Vault Integration)

The Monitor component supports external vault integration for retrieving credentials at runtime:

Vault	Configuration
HashiCorp Vault	URL + token authentication
Azure Key Vault	Azure-native key vault URL
CyberArk Conjur	Conjur URL + authentication

This allows monitors to retrieve passwords, API keys, and TOTP secrets from a centralized secrets manager instead of storing them in the monitor configuration.

Network Security

Required Network Flows

Source	Destination	Port	Protocol	Purpose
Webserver	Monitor	8051	HTTPS	Push settings, pull data
Webserver	Integrator	8052	HTTPS	Push settings, test connections
Webserver	Sentinel Agent	8070	HTTPS	Push settings, pull metrics
Monitor	Webserver	8050	HTTPS	Self-registration
Monitor	Integrator	8052	HTTPS	Push monitoring data
Sentinel Agent	Webserver	8050	HTTPS	Self-registration
Sentinel Agent	Integrator	8052	HTTPS	Push discovery data
User Browser	Webserver	9090	HTTPS	Web UI access
User/API Client	Webserver	8050	HTTPS	API access

Script Execution Security

Components that execute custom scripts (Monitor, Integrator, Sentinel Agent) implement:

Script name validation: only alphanumeric characters, hyphens, underscores, and dots allowed
Path traversal prevention: scripts must reside in the scripts/ directory
Execution timeout: configurable timeout (default 30 seconds) with forced process termination
Restricted directory: scripts run from the component’s scripts/ subdirectory only

License Validation

The Webserver requires a valid license file (license_MNS.dat) to start. Without a valid license, the service will not initialize and will log a fatal error:

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

Other components (Monitor, Integrator, Sentinel Agent) also validate their license during startup.

Translations

fr: Modele de securite

Data Flow

Components Deep Dive