Admin: Add Navbox deployment template before Related (via update-page on MediaWiki MCP Server)

2026-07-06T04:04:19Z

Add Navbox deployment template before Related (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 09:34, 6 July 2026
Line 57:		Line 57:
	* '''Deploy through automated CI/CD.''' Branch-based continuous integration and delivery removes manual, unaudited access to production and gives you a record of every change.		* '''Deploy through automated CI/CD.''' Branch-based continuous integration and delivery removes manual, unaudited access to production and gives you a record of every change.
	* '''Roll out without downtime or exposure.''' Create new pods before terminating the old ones so a deploy never drops traffic, and so partially-updated code is never publicly reachable.		* '''Roll out without downtime or exposure.''' Create new pods before terminating the old ones so a deploy never drops traffic, and so partially-updated code is never publicly reachable.

	== Next steps ==

	Security controls protect the system; '''privacy controls protect the people in it'''. Continue to [[Deployment/Security/Privacy and data protection\|Privacy and data protection]] for how to handle patient data responsibly and meet your regulatory obligations.		Security controls protect the system; '''privacy controls protect the people in it'''. Continue to [[Deployment/Security/Privacy and data protection\|Privacy and data protection]] for how to handle patient data responsibly and meet your regulatory obligations.

			{{Navbox deployment}}

	{{Related}}		{{Related}}

Admin: OHC identity seed

2026-07-04T23:08:35Z

OHC identity seed

New page

{{Doc header
|type=guide
|domain=deployment
|title=Data security
|order=1
}}

Care holds sensitive patient health data, so a production deployment should be hardened at every layer — the edge, the network, transport, data at rest, and the operational paths your team uses to manage it.

This page lists the '''standard security practices to enable''', based on how OHC operates its own production instances. Treat it as a recommended baseline rather than a finished checklist: the exact mechanism depends on your provider (for example [<nowiki/>https://www.cloudflare.com/ Cloudflare], [<nowiki/>https://aws.amazon.com/waf/ AWS WAF & Shield], [<nowiki/>https://cloud.google.com/armor Google Cloud Armor], or the [<nowiki/>https://apisix.apache.org/ APISIX] ingress used in the [[Deployment/Kubernetes/Reference architecture|Kubernetes reference deployment]]), but the controls themselves apply to any deployment.

{{Note|1=This is a baseline, not an exhaustive standard. Security is ongoing — pair these controls with periodic penetration testing and security audits, and review them whenever your infrastructure changes.}}

== Edge protection and WAF ==

* '''Run a Web Application Firewall''' in front of the application, configured with the [<nowiki/>https://owasp.org/www-project-modsecurity-core-rule-set/ OWASP Core Rule Set] to protect against common attack categories such as SQL injection and cross-site scripting (XSS).
* '''Add custom WAF rules''' for application-specific threats and bot mitigation, on top of the core rule set.
* '''Block by IP reputation / threat score.''' Deny traffic from IP addresses with a poor reputation (for example, a threat score above a chosen threshold).
* '''Apply ASN- and geo-based lockdown''' where appropriate for your deployment — restrict or block traffic from networks and regions you do not serve, against a known threat matrix.
* '''Enable rate limiting and sanity checks''' so a single client cannot flood the application, and obvious malformed or abusive requests are dropped at the edge.
* '''Use DDoS protection''' from your edge/CDN provider to absorb volumetric attacks.

== Network controls ==

* '''Lock down ports.''' Allow only ports <code>80</code> and <code>443</code> from the internet across the network; everything else should be reachable only over private networking.
* '''Reverse-proxy all traffic''' so the origin server IPs are masked and never exposed directly to clients.
* '''Isolate internal services.''' Databases, caches, object storage, and search must not be reachable from the public internet — only from the application hosts that need them (see [[#data-at-rest-and-the-database|Data at rest and the database]]).

== Transport and browser security ==

* '''Encrypt everything in transit''' with TLS 1.2 or above — origin-to-edge, service-to-service, and edge-to-user.
* '''Preload HSTS''' ([<nowiki/>https://developer.mozilla.org/docs/Web/HTTP/Headers/Strict-Transport-Security HTTP Strict Transport Security]) domain-wide with a long <code>max-age</code> (for example one year) to enforce HTTPS-only traffic.
* '''Set a strict Content Security Policy (CSP)''' header to mitigate clickjacking and content-injection attacks, and '''monitor CSP and Certificate Transparency (CT) violations''' to keep your threat matrix current.
* '''Enable DNSSEC''' on your domain to protect against forged DNS answers and domain takeover. DNSSEC-protected zones are cryptographically signed so resolvers can verify the records came from the domain owner.
* '''Serve over HTTP/2 and HTTP/3''' with Brotli compression — primarily a performance gain, but it keeps clients on modern, well-maintained protocols.

== Data at rest and the database ==

* '''Encrypt all storage''' — server nodes, volumes, and database instances — using keys managed by a Key Management Service (KMS).
* '''Keep the database private.''' Allow database connectivity only over the internal private network, and only from the backend hosts that require it. Never expose the database to the public internet.
* '''Scope credentials tightly.''' Each component should authenticate with its own least-privilege credentials, rotated regularly.

== Backups ==

* '''Take automated, scheduled backups''' (daily snapshots at minimum) of the database and any stateful stores.
* '''Encrypt backups''' with KMS-managed keys and store them inside your cloud infrastructure without external access.
* '''Test restores.''' A backup you have never restored is not a backup — verify periodically that a fresh environment can be rebuilt from it. See [[Deployment/Kubernetes/Day-2 operations|Day-2 operations]] for the Kubernetes reference deployment's backup tooling.

== Access and operational security ==

* '''Gate all maintenance access''' behind a VPN plus a bastion (jump) host. Cluster and server management should never be performed directly over the public internet.
* '''Enforce least privilege''' for human operators and service accounts alike, and review access grants regularly.
* '''Use strong authentication''' (and multi-factor authentication) for every administrative entry point.

== Deployment pipeline ==

* '''Deploy through automated CI/CD.''' Branch-based continuous integration and delivery removes manual, unaudited access to production and gives you a record of every change.
* '''Roll out without downtime or exposure.''' Create new pods before terminating the old ones so a deploy never drops traffic, and so partially-updated code is never publicly reachable.

== Next steps ==

Security controls protect the system; '''privacy controls protect the people in it'''. Continue to [[Deployment/Security/Privacy and data protection|Privacy and data protection]] for how to handle patient data responsibly and meet your regulatory obligations.

{{Related}}

Deployment/Security/Data security - Revision history

Admin: Add Navbox deployment template before Related (via update-page on MediaWiki MCP Server)

Admin: OHC identity seed