PII - GDPR, HIPAA, PDPA and other regulations

Security is of paramount importance to Zato Source and Zato is a product with security designed in. In all phases of development or maintenance, at each step, a great deal of effort goes into making sure that Zato is secure by default.

This document presents an overview of security mechanisms that can be used by technical architects to design environments expected to protect Personally Identifiable Information (PII) in accordance with regulations such as GDPR, HIPAA or PDPA.

The contents is provided for informational purposes and it is not legal advice. Readers are advised to contact qualified personnel to discuss PII requirements in their projects.

Secure by design

• Security is an ingrained part of the product, it is not an afterthought; instead, each and every part of the architecture takes strong security into account from a given part's very inception, through development up to ongoing maintenance

Access permissions

• User-defined services can be secured with a range mechanisms, including API keys, AWS, Basic Auth, JWT, NTLM, OAuth, SSL/TLS, Vault, WS-Security, and XPath
• Permissions to services can be grouped into role-based access control hierarchies (RBAC)
• There are no default credentials - all secrets are always dynamically generated and set to very strong ones (uuid4 or stronger)

Data in transit

• Data in transit can be encrypted with TLS, including ability to require client certificates and certificate pinning

Data at rest

• All secrets (e.g. connection passwords) are kept in an encrypted form
• Keys needed for decryption of secrets can be read from safe storage such as Amazon CloudHSM
• Arbitrary PII can be transparently stored in an encrypted form in databases and decrypted on the fly without a need for user programming

SSO and user management

• Ships with a built-in API for building Single Sign-On environments
• Includes user management calls and workflows
• Users can be described by arbitrary attributes, each possibly transparently encrypted and decrypted when needed
• All access to PII is always reflected in an audit log, including information who carried out a given operation

Strong cryptography

• Zato includes safe and strong means for cryptographic operations: encryption, decryption and hashing of secrets

Log processing

• Logs can be stored in files or remote processing facilities (e.g. NewRelic or Sentry)
• Data masking - to minimize the risk of attackers gaining access to PII, the secret parts of connection parameters are not stored in log files (e.g. instead of passwords a placeholder ****** is stored)

Clustering

• To ensure business continuity, Zato servers are always part of a cluster and there are no limits to how many clusters can be created for High Availability