Erp Security Hardening | The Garnet Wiki

Erp Security Hardening is the systematic process of fortifying an enterprise resource planning system against unauthorized access, data breaches, privilege escalation, and configuration drift. It matters when the ERP becomes the central source of truth for finance, supply chain, human resources, and operations—when a single misconfiguration can expose millions in assets, delay months of payroll, or invalidate regulatory compliance. This guide focuses on the actions, checks, and configurations that transform a baseline ERP installation into a secure, auditable, and resilient platform.

Identity and Access Management

Define and Enforce Role-Based Access Control

Define roles using a hierarchical, granular model with explicit permissions. Roles must be named consistently: Finance_Lead, Inventory_Supervisor, Procurement_Admin, HR_Employee. Each role maps to a set of actions on specific entities, such as PurchaseOrder, Vendor, PayrollRun.

Permissions are defined as a list of operations with filters. For example:

{
  "role": "Finance_Lead",
  "permissions": [
    {
      "entity": "Ledger",
      "actions": ["Read", "Create", "Update", "Delete"],
      "filters": {
        "company": ["US", "EU"],
        "postingPeriod": "Open"
      }
    },
    {
      "entity": "GeneralJournal",
      "actions": ["Read", "Create", "Post"],
      "filters": {
        "journalName": ["Intercompany", "Recurring"]
      }
    }
  ]
}

Users are assigned one or more roles. A user may inherit permissions from multiple roles, with conflicts resolved by precedence order: roles higher in the list override lower ones.

Implement Multi-Factor Authentication (MFA) for All Users

MFA is enforced at login via the ERP’s built-in identity provider. The identity provider issues a 2fa_required flag during the authentication flow. Clients must include a X-2fa-Required header in the initial login request.

The MFA challenge follows this sequence:

User submits username and password.
Server responds with 200 OK and X-2fa-Required: true.
Client redirects to MFA challenge endpoint: POST /api/2fa/challenge.
Client sends deviceToken and challengeId in request body.

{
  "challengeId": "c1a2b3c4-d5e6-f7g8-h9i0-j1k2l3m4n5o6",
  "deviceToken": "otp-654321",
  "method": "TOTP"
}

On success, server returns 201 Created with a Set-Cookie header for a sessionToken and X-2fa-Verified: true.

Failures include:

401 Unauthorized with { "error": "invalid_challenge" } if the challengeId is expired.
429 Too Requests if MFA attempts exceed 5 per minute per user.

Synchronize Identity with External Directory Service

Integrate the ERP with an external identity provider (IdP) using SAML 2.0. The IdP provides a metadata file at https://idp.example.com/saml/metadata:

<EntityDescriptor entityID="https://erp.example.com">
  <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
                          Location="https://erp.example.com/saml/redirect"/>
    <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                          Location="https://erp.example.com/saml/post"/>
  </SPSSODescriptor>
</EntityDescriptor>

The ERP acts as a Service Provider (SP). During SSO, the IdP redirects to the SP’s SsoRedirect endpoint with SAMLRequest and RelayState.

The ERP validates the SAML response by:

Verifying the signature using the IdP’s public key.
Checking Audience and Destination in the Issuer element.
Verifying NotBefore and NotOnOrAfter timestamps.

Failure to validate results in a 403 Forbidden response with X-Error-Reason: saml_validation_failed and a JSON body:

{
  "error": "saml_validation_failed",
  "details": [
    "invalid_signature",
    "audience_mismatch",
    "timestamp_out_of_range"
  ]
}

Data Protection and Encryption

Encrypt Sensitive Data at Rest and in Transit

All databases are encrypted using AES-256 with a master key stored in a key management service (KMS). The ERP config includes:

database:
  encryption:
    enabled: true
    algorithm: "AES-256-CBC"
    keyId: "kms://arn:aws:kms:us-east-1:123456789012:key/abcd1234-ef56-7890-abcd-1234567890ab"
    rotationPeriod: "P30D"
    columnEncryption:
      - column: "Employee.Ssn"
        keyId: "kms://arn:aws:kms:us-east-1:123456789012:key/ef567890-abcd-1234-5678-90abcd123456"
        format: "Padded"
      - column: "Vendor.PaymentDetails"
        keyId: "kms://arn:aws:kms:us-east-1:123456789012:key/cdef1234-5678-90ab-cdef-1234567890ab"
        format: "Hybrid"

Data in transit is secured with TLS 1.3 across all public endpoints. The ERP exposes the following endpoints:

https://erp.example.com/api/v1/ — all public API endpoints
https://erp.example.com/odata — OData services
https://erp.example.com/saml — SAML SSO endpoints
https://erp.example.com/ws — web service endpoints (SOAP)

Each endpoint requires TLS 1.3 with ECDHE-ECDSA-AES256-GCM-SHA512 cipher suite and HTTP/2 multiplexing.

Certificates are issued by an internal CA and renewed every 90 days. The ERP verifies certificate chains using trustedRootCAs configured in config.yml:

tls:
  trustedRootCAs:
    - "/etc/ssl/certs/internal-ca.pem"
    - "/etc/ssl/certs/letsencrypt-root.pem"
  minimumVersion: "TLS1.3"
  requireClientCertificate: true

Audit Data Access and Changes

Enable detailed audit logging for all data modifications. The ERP maintains an audit log table DataAuditLog with the following schema:

CREATE TABLE DataAuditLog (
  id BIGSERIAL PRIMARY KEY,
  timestamp TIMESTAMPTZ NOT NULL,
  userId VARCHAR(64) NOT NULL,
  action VARCHAR(16) NOT NULL, -- "Create", "Update", "Delete", "BulkImport"
  entityName VARCHAR(64) NOT NULL,
  recordId VARCHAR(128) NOT NULL,
  oldValues JSONB,
  newValues JSONB,
  changeReason TEXT,
  ipAddress INET,
  userAgent TEXT
);

The ERP logs every change via a trigger on each entity table. For example, on PurchaseOrder:

CREATE TRIGGER purchase_order_audit
AFTER INSERT OR UPDATE OR DELETE ON PurchaseOrder
FOR EACH ROW EXECUTE FUNCTION audit_data_change('PurchaseOrder');

The function audit_data_change takes the entity name and logs the change, capturing the full JSONB representation of the old and new state.

Audit logs are indexed by timestamp, userId, and entityName. Queries for compliance use:

SELECT * FROM DataAuditLog
WHERE entityName = 'Vendor'
  AND timestamp >= '2024-01-01'
  AND userId = 'jane.doe'
ORDER BY timestamp DESC
LIMIT 100;

Protect Configuration and Secrets

All configuration is stored in a hierarchical, versioned key-value store. The ERP reads configuration from config.json and config.env at startup.

{
  "server": {
    "port": 8080,
    "host": "0.0.0.0",
    "maxRequestSize": "10MB"
  },
  "security": {
    "sessionTimeout": "2h",
    "jwt": {
      "issuer": "https://erp.example.com",
      "audience": "erp-app",
      "signingKey": "base64:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJm36XVj0yXvB83tE1IJQ"
    }
  },
  "audit": {
    "enabled": true,
    "logLevel": "INFO"
  }
}

Secrets are stored in a secure vault accessible via an API. The ERP loads secrets at startup using GET /secrets/v1/ with a X-Secret-Provider: vault header.

Example secret request:

GET /secrets/v1/erp/production/database/password HTTP/1.1
Host: vault.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJm36XVj0yXvB83tE1IJQ
Accept: application/json

Response:

{
  "key": "erp/production/database/password",
  "value": "p@ssw0rd-2024!",
  "version": 12,
  "created": "2024-01-01T00:00:00Z",
  "updated": "2024-04-01T12:34:56Z"
}

The ERP caches secrets for 10 minutes and automatically refreshes them in the background.

Runtime and Operational Hardening

Harden the Application Server

The ERP runs as a set of processes managed by systemctl. The main service file /etc/systemd/system/erp.service includes:

[Unit]
Description=ERP Application Server
After=network.target postgresql.service

[Service]
Type=simple
User=erp
Group=erp
WorkingDirectory=/opt/erp
ExecStart=/opt/erp/bin/erp-server --config /etc/erp/config.json
ExecReload=/bin/kill -HUP $MAINPID
ExecStop=/bin/kill -TERM $MAINPID
Restart=on-failure
RestartSec=10s
Environment=NODE_ENV=production
Environment=LOG_LEVEL=info
StandardOutput=journal
StandardError=journal
SyslogIdentifier=erp

[Install]
WantedBy=multi-user.target

The ERP server starts with a minimal set of dependencies. It is hardened by:

Running with noexec, nosuid, and nodev on /opt/erp.
Mounting /var/log/erp as bind with xattr, acl, and noatime.
Using chroot to isolate the runtime environment.

Secure API Endpoints and Rate Limiting

All API endpoints are protected by JWT authentication. Clients must include Authorization: Bearer <token> in every request.

The ERP validates JWTs using a public key from https://erp.example.com/.well-known/jwks.json:

{
  "keys": [
    {
      "kty": "RSA",
      "kid": "1234567890",
      "use": "sig",
      "n": "1234567890abcdef...",
      "e": "10001"
    }
  ]
}

The ERP enforces rate limiting using a sliding window algorithm. Each endpoint has a limit defined in config:

api:
  rateLimit:
    global:
      window: "1m"
      maxRequests: 1000
      burst: 200
    endpoints:
      "/api/v1/finance/reports":
        window: "5m"
        maxRequests: 200
        burst: 50
      "/api/v1/inventory/adjustments":
        window: "1m"
        maxRequests: 100
        burst: 30

A request to /api/v1/finance/reports returns:

HTTP/1.1 200 OK
Content-Type: application/json
X-RateLimit-Limit: 200
X-RateLimit-Remaining: 197
X-RateLimit-Reset: 1670000000

When the limit is exceeded, the ERP returns 429 Too Requests:

{
  "error": "rate_limit_exceeded",
  "details": {
    "limit": 200,
    "remaining": 0,
    "reset": 1670000000,
    "retryAfter": 60
  }
}

Monitor and Alert on Security Events

The ERP emits structured logs in JSON format to stdout and a file. The log format includes:

{
  "timestamp": "2024-04-01T12:34:56.789Z",
  "level": "error",
  "service": "auth",
  "message": "Failed login attempt from 192.168.1.100",
  "userId": "jane.doe",
  "ipAddress": "192.168.1.100",
  "event": "login_failed",
  "data": {
    "attemptedUsername": "jane.doe",
    "failedReason": "invalid_password",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36"
  }
}

A centralized logging system collects logs and triggers alerts using Prometheus and Alertmanager.

Example alert rule in alerting.yml:

groups:
  - name: erp-security
    rules:
      - alert: HighLoginFailures
        expr: |
          rate(erp_log{event="login_failed"}[1h]) > 5
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "High login failures in ERP: {{ $value }}"
          description: |
            {{ $labels.instance }} has experienced {{ $value }} login failures in the last hour.
            Check for brute-force attacks or misconfigured IdP.

Failure Modes and Sharp Edges

JWT expiration without refresh: The ERP silently returns 401 Unauthorized when a JWT expires, but the client must handle 401 with WWW-Authenticate: Bearer header and WWW-Authenticate: Bearer error="invalid_token".

Audit log performance degradation: When DataAuditLog grows beyond 10 million rows, queries slow down. The solution is to partition by timestamp every 3 months and compress data using zstd.

SAML assertion expiration: The ERP validates NotBefore and NotOnOrAfter, but does not enforce SessionNotOnOrAfter. A user may log in at 10:00 AM, but their session remains valid until 10:30 AM even though the IdP issued a session that expires at 10:15 AM.

MFA device token reuse: The ERP accepts the same deviceToken multiple times, but does not track device usage. A user may reuse an OTP code for 5 minutes, leading to a window of vulnerability.

Secrets not reloaded after update: After a configuration change, the ERP does not reload secrets unless RELOAD_SECRETS=true is set in environment. Without it, a new secret is not available until the next restart.

This page was rewritten on 17 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.