Architecture

There are many ways Governor can be deployed. A simple and typical deployment architecture of Governor is shown below.

deployment

  • Frontend server/reverse proxy is NGINX running on port 80 (which should be put behind some load balancer/SSL terminator etc).

  • Frontend NGINX server redirects backend requests to Java backend service typically running on port 8081.

  • Java backend needs a PostgreSQL database typically running on port 5432.

  • Java Backend and PostgreSQL can be on a private network with NGINX server, the only thing which is public is port 80 of NGINX.

  • Besides that, Java Backend service must have a network access to source/target databases.

Other services which can be utilized by UI can be accessible to Java Backend:

* HashiCorp Vault
* LDAP/ActiveDirectory

Architectural Properties

Enterprise-grade security

Synthesized supports industry-standard security protocols including Secure Sockets Layer (SSL), JWT Tokens and Bcrypt cryptography. Governor can be installed in isolated security zones so the data transformation process takes place locally and no data is exposed outside of its home jurisdiction. Synthesized requires no server or outside connection. It is designed to work without network access and within air-gapped deployment environments.

Inactivity timeouts

Implemented appropriate timeouts, based on risk considerations.

Cryptographic systems

The list of enabled protocols and ciphers, and approved exceptions (or ORIs) for any non-approved protocols or ciphers.

Date format

The usual format as described in ISO8601-01:2019 is YYYY-MM-DD”T”hh:mm:ss, where the time zone descriptor may by "Z" for UTC, or a positive or negative number as offset to UTC. E.g. 2020-08-06T15:48:15Z, or 2020-08-06T16:48:15+01.

Logging must not be disabled

The component doesn’t allow disabling of logging, or it must trigger a security event on the logging stream. Disabling logging triggers a security event, by getting such an entry from the component’s log stream.

Auditing

The format of the log entries which are produced by the component.

Identification & Access control

Enforcing authentication and access control is usually done either on OS level (e.g. using Active Directory), or authentication on OS level and access control on application level. This is depending on the needed granularity of the access control, which is coarse on OS level.

Disabling of built-in accounts

Built-in accounts should be “disabled”, which means either deleted (seldom feasible), or configured to be not usable for interactive use, e.g. by denying login, or not having a shell (i.e. CLI). Typically, built-in accounts are used to own running processes, which is fine. But using a built-in account interactively must not be possible, as it does not allow to trace activities back to who triggered them.