Security
Platform security controls and recommended production deployment practices.
FireSonic combines lightweight deployment with practical security controls for persisted healthcare data, administrative access, outbound TLS trust, secrets, and customer-specific scripting.
Security controls
| Area | Description |
|---|---|
| Message persistence | Incoming HL7 payloads can be compressed, encrypted, and durably persisted on local storage. |
| Administration access | Administration Console authentication with recommended TLS termination and network restrictions. |
| Script isolation | Customer Groovy scripts run inside a restricted sandbox rather than with unrestricted JVM/OS access. |
| Credential configuration | Sensitive values can be externalized with environment-variable placeholders or deployment secret stores. |
| Outbound TLS trust | JVM default trusted CAs plus optional private/hospital X.509 certificates. |
| Operational recovery | Durable persistence, restart recovery, retry, and diagnostics reduce the operational impact of failures. |
| Audit visibility | Message states, failure diagnostics, processing history, and operational information are visible through the platform. |
Groovy script sandbox
Core Java processing is separated from customer-specific Groovy customization. Scripts execute in a restricted runtime intended to reduce the risk of unsafe behavior while still providing managed integration APIs.
Restricted capabilities include:
- Operating-system process execution.
- Unrestricted filesystem access.
- Arbitrary network access outside managed clients.
- Reflection-based access.
- Dynamic class loading.
- Nested script execution.
For outbound HTTP and FHIR integrations, use the managed clients exposed by the Developer SDK instead of direct unrestricted networking.
Secrets and credentials
Passwords, tokens, encryption keys, and external-service credentials should be externalized instead of committed to configuration files or source control.
fhir.server.auth.basic.password=${FHIR_PASSWORD:change-me}
payload.crypto.keys.k1.password=${FS_PAYLOAD_KEY}Additional trusted TLS certificates
When a FHIR or terminology server uses a private Certificate Authority, enable additional certificate loading and place trusted X.509 certificates under ./config/certs.
tls.certs.enabled=true
tls.certs.dir=./config/certs- FireSonic continues to use the JVM default trusted Certificate Authorities.
- Supported files:
.pem,.crt, and.cer. - Certificates are loaded during FireSonic startup. Restart FireSonic after changing them.
Recommended deployment practices
- Terminate HTTPS/TLS for administrative HTTP endpoints.
- Restrict management endpoints to trusted network segments.
- Use VPN-secured remote administration where required.
- Deploy inside protected internal network segments or DMZ environments appropriate to the integration topology.
- Apply firewall restrictions to MLLP listener ports.
- Use encrypted filesystem or disk storage where appropriate.
- Use environment variables or secret-management systems for credentials and encryption secrets.
- Maintain and test database backup and recovery procedures.
Securing MLLP
HL7 MLLP is commonly deployed on trusted internal networks and does not inherently provide transport encryption. Where encrypted MLLP transport is required and the sending system does not provide it natively, an external TLS tunnel such as sTunnel can be used to protect the TCP connection.
Restrict MLLP endpoints to known senders and trusted network paths. Do not expose MLLP listener ports directly to untrusted networks.