- v1.0.0-latest-prod
Configuring and operating an environment in a secure way to protect sensitive customer private information is important. There are best practices in general that should be observed when considering the specific needs of a Broadleaf environment.
Encrypting data at rest is generally not achieved directly through the framework tooling, but instead through infrastructure facilities - specifically the cloud provider. Cloud storage is configured for encryption and is often established by default (e.g. GCP storage is by default encrypted using AES256).
The two locations where personal identifiable information may be stored are:
file store backing the database
file store backing the search engine (e.g. solr search service from Broadleaf)
Encrypting data as it’s transported over the network (e.g. customer browser communication to the microservice) is important as well. All communications with Broadleaf services are setup by default to use https protocol leveraging TLS1.2.
Both the database and search engine (solr) should require authentication. The passwords for the accounts used by the system to interact with these components should be appropriately complex. For example, GDPR indicates passwords at least 8 characters in length (but preferably longer). Using a password generation algorithm with appropriate entropy is indicated for this use case.
Passwords should be stored in a secret manager. Examples of this include Hashicorp Vault, as well as cloud native solutions such as Google Secret Manager. Applications should retrieve secrets at runtime and keep them in-memory during the lifecycle of the application. They should never be retrieved from the file system.
From a Broadleaf Microservices and Kubernetes perspective, traditionally the approach has been to use
kubernetes secrets and to expose those secrets to the container at runtime using environment variables.
However, this is not considered secure, since these secrets are stored Base64 encoded in linux etcd.
There are several strategies to help with this situation:
At a minimum, use envelope encryption for the secrets stored in etcd. This makes sure the secret data stored
there is not decipherable if accessed by an adversary. This topic is covered in more detail here:
https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/. A more specific example for the GCP
case is demonstrated here: https://cloud.google.com/kubernetes-engine/docs/how-to/encrypting-secrets.
It is also advantageous to not store secrets in kubernetes secrets directly, but instead focus on secret storage in a secret manager. This provides the additional benefit of secret versioning and access auditing. The latter feature has the benefit of opening the door for anomaly detection based on secret manager access logs. This can help with security event detection. There are different facilities for integrating the secret manager concept with container runtime consumption, but the most straightforward approaches involve connecting environment variables, config maps, and kubernetes secrets with the secret manager via a third-party component, like kube-secrets-init.
Personnel access to secrets should be limited to a select set of individuals that require knowledge as part of system support. Secrets should not be shared via standard messaging channels. By using a secret manager (as mentioned above), secret access can be limited appropriately using the authentication and authorization features of those platforms.
In addition to the database and solr filesystem, database backups can be a source of sensitive information leakage should those backups be stored in an insecure way. If using a cloud provider, it is generally recommended to leverage a cloud native database with built-in backup support. These backups will generally be stored securely with encryption at rest by the cloud provider.