Skip to main content

Security Considerations

Data Protection​

Data shared with Sixpack is only data provided by generators as outputs or configuration parameters provided as inputs either by users or automated tests. By design:

  • That data will not contain real personal data
  • That data may contain credentials to log in systems under test as test customers or similar test identities

The custom code of generators and their configuration that actually interacts with your systems is not shared with Sixpack and stays in your infrastructure.

To allow using Sixpack in the SaaS model, it is important to be aware of that and to run your own assessment of the risk.

Our assessment​

We have designed Sixpack to pass general data protection standards. Main argumentation lines:

  • Sixpack only handles non-production systems
  • All data are fully synthetic
  • Data that transits to/from Sixpack is only a portion of data serving as references to full datasets stored within your systems, it does not allow any reverse engineering or similar attacks
  • Sixpack cannot initiate any action in your systems directly, it only can trigger predefined procedures coded by your developers and deployed in your infrastructure
  • Sixpack runs itself on infrastructure designed with high security standards such as service communication network isolation, encryption at rest, encryption at transit anytime data leaves the platform perimeter
  • Sixpack is developed with high quality management standards in place including:
    • Full coverage by automated tests for any change
    • Code reviews

For specific regulated environments where that would not be enough, we offer Sixpack as a managed instance in your infrastructure.

Encryption​

Sixpack uses encryption at rest provided by public cloud providers. More specifically the PostgresSQL database service is used. We do not disclose the cloud provider in written, but it's one of the major ones with the highest security standards.

For data in transit, Sixpack uses gRPC with mTLS for communication between Generators and the Sixpack platform where the risk to actively interact with systems is higher. The private key generated by Sixpack for the mTLS is a 2048-bit RSA key.

The REST API that allows to order and pick test datasets is secured with Sha256 HMAC using a shared API Key. The key is renewable upon request in which case all clients need to be updated.

Both the mTLS private key and the API Key should be stored in a secure way and injected in your clients in the runtime only. The SDKs typically require the private key to be located in a file and the file to be referenced in an environment variable. In a Kubernetes environment, that can be achieved by mounting the file from a secret, which is a common practice.

Authentication and Authorization​

For user interaction, OpenID Connect is used to authenticate users each time the user starts a new session. The session validity is 1 day. Upon support request we are able to end the session immediately. This feature will be self-service in the future.

As of today, there is no super-user access that would allow any user to gain access to all datasets or similar, all users are at the same level which allows them to only access datasets that they have ordered previously.