Version: 1.0 Last Updated: September 2026 Owner: Nova IAM Security Team

1. Purpose

This document defines the security controls, practices, and standards implemented in Nova IAM to protect customer identity data and ensure secure operation of the platform.

2. Authentication & Access Control

2.1 Password Security

All passwords are hashed using Werkzeug's scrypt/pbkdf2 algorithm (memory-hard, salted) before storage
Plain-text passwords are never stored, logged, or returned in API responses
Password changes require an authenticated session and are fully audited

2.2 Session Management

Server-side session management via cryptographically signed cookies
Sessions are bound to the SECRET_KEY environment variable, which must be set to a strong, unique value per deployment
Explicit session destruction on logout with full audit trail
Session cookies are transmitted over HTTPS only in production deployments

2.3 API Authentication

All API endpoints (except /api/login and /api/me) require authentication
Authentication is enforced at the middleware level via a before_request hook, ensuring no endpoint can accidentally bypass auth
Unauthenticated requests receive HTTP 401 with no data leakage

2.4 Role-Based Access

Nova IAM implements role-based access control (RBAC) for managed users
Entitlements and business roles control access to connected backend systems
Inherited entitlements cannot be removed without first removing the parent business role assignment

2.5 Multi-Factor Authentication

Optional TOTP second factor (RFC 6238) for the local login, with single-use backup codes, provided as the MFA plugin
Administrators can require MFA for administrators or for all users
Alternatively, MFA via Entra ID or OIDC single sign-on for IdP-backed deployments

3. Data Protection

3.1 Data in Transit

Production deployments use TLS 1.2+ via nginx reverse proxy with automated Let's Encrypt certificates
Internal service-to-service communication occurs over isolated Docker networks not exposed to the public internet
Database connections support sslmode=require for encrypted app-to-DB communication

3.2 Data at Rest

PostgreSQL database runs on dedicated infrastructure with filesystem-level access controls
Database credentials are supplied via environment variables, never hardcoded in production
Sensitive configuration (API keys, connection strings) is managed through environment variables and .env files excluded from version control

3.3 SQL Injection Prevention

All database queries use parameterized statements (psycopg2 %s placeholders)
No string interpolation or concatenation is used in SQL construction
This protection is applied consistently across all 16+ route modules

4. Audit & Logging

4.1 Audit Trail

Security-relevant events (logins, changes to accounts, roles and requests) are recorded in the audit_log table, including actions taken via the AI chat
Each audit entry captures:
- Timestamp (PostgreSQL server time)
- Event type and category
- Actor (authenticated user ID and name)
- Target (affected object type, ID, and name)
- Client IP address
- Details (structured context, including the origin, e.g. AI chat)
There is no function in the UI or API to edit or delete audit records
Indexed for efficient retrieval and filtering by timestamp and category

4.2 Audited Events Include

Login and logout (with IP address)
Password changes (actor and target user)
Role and entitlement assignments/removals
Business role modifications
System provisioning actions
User lifecycle changes (create, update, deactivate)

5. Infrastructure Security

5.1 Production Architecture

Application server (Gunicorn) behind nginx reverse proxy
PostgreSQL database on isolated backend network
Database port not exposed to public internet
Container health checks ensure service availability

5.2 Network Isolation

Docker network segmentation between frontend proxy and backend services
Application listens on loopback (127.0.0.1) in development mode
Production deployments restrict direct access to application and database ports

6. Secure Development Practices

Idempotent database migrations prevent schema corruption during upgrades
Referential integrity enforced via foreign key constraints
Input validation on all API endpoints
Dependencies declared with version ranges in requirements.txt; frontend dependencies locked in package-lock.json
Code quality enforced via Ruff linter and automated test suite

7. Vulnerability Disclosure

See the Vulnerability Disclosure Policy.

8. Incident Response

See the Incident Response Plan.

Security Policy