Security Hardening
Security Hardening & Cryptographic Infrastructure
Security Mandate
This document outlines the security hardening protocols for the Level 4 HMIS. It specifies Role-Based Access Control (RBAC), application-layer field encryption, API authentication, and defensive physical server isolation configurations.
1. Application-Layer Field-Level Encryption (CLE)
To ensure strict compliance with the Kenya Data Protection Act (2019), Personally Identifiable Information (PII) must never be stored in cleartext inside database blocks or logs. The HMIS enforces Application-Layer Cryptographic Field-Level Encryption using AES-256-GCM.
1.1 Python Cryptographic Mixin Implementation
The Django persistence layer uses an abstract model field mixin to automate encryption and decryption during database read/write cycles:
2. Multi-Tenant Role-Based Access Control (RBAC)
System privileges are strictly coupled to functional roles within the clinical hierarchy. Access control is enforced using a declarative permissions model down to the individual API route level.
2.1 Role-Based Privilege Grid
| System Role | Scope Boundaries | Allowed Operations | Data Access Restrictions |
|---|---|---|---|
| HRIO / Clerk | Master Patient Index | Create Patient, Search Record, Print ID | Blocked from reading clinical notes/vitals. |
| Triage Nurse | OPD Triage, Ward Care | Read Patient, Write Vitals, Enqueue Patient | Cannot prescribe drugs or modify bills. |
| Medical Officer | Global Clinical Scope | Read Patient, Write History, Order Labs, Prescribe | Cannot modify financial transaction status. |
| Pharmacist | Pharmacy Module | Read Prescriptions, Dispense Items, Track Inventory | Blocked from viewing psychiatric consultation blocks. |
| Billing Officer | Financial Ledger | Collect Cash, Trigger M-Pesa, Split Bills | Blocked from writing clinical diagnostic rows. |
2.2 API Authorization Decorator Pattern
The backend uses functional Python decorators to intercept and validate user clearance tokens before route execution:
3. API & Web Session Security Hardening
To secure the user session pipeline across browser instances and analyzer gateways, the backend enforces specific token management and browser protection headers.
3.1 Token and Session Security Settings
- State Management Isolation: Authentication tokens use cryptographically signed JWT payloads with short lifetimes (15-minute access token lifespan, 8-hour sliding refresh window token).
- Defensive HTTP Response Headers: The reverse proxy layer injects strict security policy parameters into every outbound transmission sequence:
- On-Premise Physical Server Infrastructure Hardening Since deployment occurs locally on server hardware within the physical boundaries of a Level 4 hospital, software configurations must defend against physical intrusions and local network exploits.
4.1 Linux Operating System Hardening Policy
- SSH Port Obfuscation: The standard SSH port is remapped from 22 to 2222. Password-based authentication is explicitly disabled in /etc/ssh/sshd_config, requiring cryptographically signed SSH keys for all administrative connections.
- UFW Firewall Rule Enforcement: The host system blocks all network ports by default, opening only essential access paths:
- Database Access Isolation: PostgreSQL is configured to reject external TCP network requests by enforcing listen_addresses = 'localhost' within postgresql.conf. External network routing inside the monolith relies entirely on isolated, virtual Docker-managed networks.
Document Verification Block
Author: Ian Wataka - Backend DeveloperTarget Scope: Level 4 Hospital Production Infrastructure