Automating software tests inevitably involves working with sensitive information, from credentials and API keys to interacting with applications that can access customer data. mabl’s approach to data encryption ensures that your team’s testing data is secure. To further protect your data, we recommend that you take additional security measures to avoid accidental or malicious misuse of the secrets, keys, and other data from your workspace.
This article offers several guidelines that you can follow to ensure your workspace is secure:
- Align workspace roles with team roles
- Use credentials and environments variables to store sensitive values
- Use test accounts and test data
- Set up SSO and domain lock
- Use minimally scoped API keys
- Restrict access to your network with mabl Link
All teams are different
Different teams have different security requirements:
- If you’re on a smaller team, you may prefer to implement only the security measures that suit your team’s workflow.
- If you’re part of a larger workspace and/or in a more regulated industry, you may need to implement all of the recommendations in this article.
Align workspace roles with team roles
When inviting new users to the workspace, assign them a workspace role that aligns with their role in the business. For example:
- If you’re inviting a PM who just wants to occasionally log in and view test results, give them a viewer role.
- If you’re inviting a system admin who will need to make changes to workspace settings or invite other team members, give them an owner role.
- If you’re inviting a manual tester or QA engineer who will be creating tests, give them an editor role.
For more information, check out the article on roles and permissions.
Apply more granular user permissions with resource groups
To further restrict access to specific resources in your workspace, create resource groups and apply more granular permissions for accessing them.
Use mabl credentials and environment variables for sensitive values
All data in your mabl workspace is encrypted in transit and at rest. For sensitive values in your tests, we recommend storing them as mabl credentials and environment variables, which are special types of variables that come with an extra layer of encryption.
Another benefit using mabl credentials and environment variables is the ease of updating and rotating their values as compared to updating values that are hard-coded into your tests.
Cloud-only credentials
If you’re using a test account that accesses sensitive customer data, we recommend saving your mabl credentials as cloud credentials so that no one can retrieve the password.
Use test accounts and data
mabl is not currently HIPAA or PCI certified. We recommend all customers use test accounts and data, even when testing in production. This guideline is especially important if your application collects any sensitive patient or credit card data.
Set up SSO and domain lock
If you require users on your team to log in through your corporate identity provider via SSO, you have greater control over how you validate users. With SSO logins, you can also set up domain lock so that users are required to use SSO, which removes the possibility of a user losing their mabl password.
Learn more about SSO here.
Use minimally scoped API keys
If you’re using mabl API keys to execute tasks programmatically, choose an API key type that is constrained to the minimum permissions required to execute the task.
For example, if you simply need to trigger a deployment event in mabl, use a “Deployment” key type, which has only the permissions to create deployment events and fetch their results. Comparatively, the “mabl CLI” key type has permissions to carry out the full functionality of the mabl CLI and would be better suited for a script that performs a wider variety of tasks.
Restrict access to your network with mabl Link
mabl Link is the most secure way to test applications that aren’t accessible from the public Internet. During a Link-enabled test run, a Link Agent running on a container or VM in your network establishes a secure tunnel to the mabl cloud. DNS resolution during the test run occurs on the host running the Link Agent.
To limit what mabl can access within your network even further, you could run the Link Agent within a DMZ or on a dedicated host, VM, or container with strict firewall rules that only allow it to access the desired applications under test.