Skip to content
  • There are no suggestions because the search field is empty.

Deploy the PBRS REST API Securely

Deploy PBRS API services with approved network boundaries, TLS, service identities, secrets and upgrade checks.

Review status: Draft for Development and Support review. Routes and models labelled validation required must be tested against the supported PBRS build before publication.

Security baseline

  • Place the PBRS API on an approved internal network boundary.
  • Expose only the required host and port to allow-listed integration systems.
  • Run services under approved least-privilege identities.
  • Use separate API clients and secrets for each environment and workload.
  • Store secrets in a managed secret store and rotate them on a defined schedule.
  • Redact tokens, credentials, report data and recipients from logs.

TLS and certificates

Development must specify whether direct HTTPS binding, a reverse proxy, or both are supported. The production runbook must name the certificate store and binding procedure, trust-chain requirements, renewal owner, firewall rules and remote verification test. Do not bypass certificate warnings.

Install and upgrade integrity

  1. Record the PBRS build and installer used.
  2. Verify the API executable, service and configuration files exist.
  3. Confirm service identity, startup type and dependencies.
  4. Test local health and token acquisition.
  5. Test from the approved integration host.
  6. Run discovery, execution and controlled delivery regression tests.
  7. Retain a rollback plan and the previous validated configuration.

Network and HTTPS validation sequence

  1. Confirm the approved host name resolves from the integration host.
  2. Confirm the configured port is reachable and restricted to approved systems.
  3. Validate the certificate name, chain, expiry and revocation behavior.
  4. Call ping locally and remotely without bypassing browser or client certificate warnings.
  5. Acquire a token and call a protected read endpoint.
  6. Run a controlled execution and destination delivery.

Support history shows successful HTTPS deployments as well as closed/reset connections caused by protocol mismatch, blocked ports and environment-specific network configuration. Publish only the topology Development supports for the named build.

Repair boundaries

  • Do not copy an API executable from a different PBRS build.
  • Do not change service paths or internal timeout files without a supported procedure.
  • When an upgrade removes or fails to replace an API component, use the supported installer/upgrade repair and repeat the regression suite.
  • When moving between drives or servers, confirm every registered service path and database connection before deleting the earlier installation.

Documentation standard: Record the PBRS build used for verification, test in a non-production environment, redact credentials and customer data, and confirm the saved PBRS state after every write.