What do you need to know about security and cloud based testing? What (if anything) should you worry about, and what can you do about it?
Here's a spoiler: There are reasons to be concerned when it comes to cloud based testing and security, but there are also things that you can do to guarantee a high level of security in cloud based testing.
First, let's take a quick look at general cloud security issues.
Perhaps the most basic concern most users have regarding cloud security is that they do not have physical or underlying administrative control over the servers on which their software is deployed. In the pre-cloud world, on-premises deployment was the rule, and an organization's IT staff would have control of the servers all the way down to bare metal.
This meant that security could be configured and implemented to suit the specific requirements of the organization. If there was a breach, it was the result of an unanticipated vulnerability, or one which had not been adequately addressed, and did not arise from conditions that were fundamentally beyond the control of in-house IT.
In the cloud, of course, this relationship is reversed to a significant degree. A cloud user's IT staff will have control only at a fairly high level of abstraction—typically, with the deployment of virtual machines and containers, or in the case of serverless deployment systems such as AWS Lambda, strictly at the level of code. Control at all lower levels is in the hands of the cloud service provider (CSP).
This means that:
Cloud service providers must maintain a very high level of security in order to retain the trust of their clients.
Cloud users and providers of cloud based applications must take full responsibility for security at the levels where they do have control.
In other words, cloud security requires dual responsibility. If either service providers or users fail to adequately deal with security, it may result in potential or real security breaches.
Along with the general concern over responsibility for cloud security, there are some specific cloud-based security issues. These include:
Insider access at cloud service provider sites. This is a more specialized issue tied into provider responsibility. CSPs need to closely screen all employees and place strict controls over access to sensitive user data.
Communication with cloud services. Users must communicate with cloud servers by means of Internet routes and carriers of varying security, with little or no control over the paths taken by the data.
Data shared on a single server. CSPs may store multiple users' data on the same server. When this happens, they must take active steps to isolate each user's data.
Recycling of virtualized instances. If cloud-based applications reuse VMs and containers, individual client data may be compromised. In this case, providers of cloud-based software and services are largely responsible for security.
Security in cloud based testing is closely tied into most of these issues. In addition, there are some testing-specific points that are important to address.
Perhaps the most important of these involves the sensitivity of the test process itself. Whether it is a matter of bug fixes or new features, software under development often requires an added level of security in order to prevent the details (or even the general nature) of upgrades and fixes from becoming known to competitors, industry-based journalists, or the general public.
Leaked development information can reveal vulnerabilities, give competitors a chance to rush-release cloned versions of new features, and provide fragmentary and often inaccurate information to industry-based rumor mills.
In many ways, raw test data is equally sensitive. It can reveal not only vulnerabilities, but also specific ways in which they can be exploited, and that can be extremely valuable for competitors who are developing similar software. In many respects, test data is as sensitive as source code itself, and depending on the circumstances, it may even be more sensitive.
Does this mean that you shouldn't test your software in the cloud?
Hardly. For one thing, in many cases, cloud based testing is a practical necessity. If you are deploying in the cloud, then at some point, you need to test in the cloud. This is even more true when your application is virtualized and microservices-based. You may be able to use a local instance of your MV/container ecosystem for the initial stages of testing, but at some point, you will need to run your full, cloud-based deployment through a thorough test regime.
Cloud based testing also makes good economic sense. This is particularly true when you use a cloud based testing service, such as Sauce, which eliminates virtually all of the overhead involved in maintaining local test devices and servers. For many developers, there is simply no economic justification for taking on the cost of in-house test equipment, not to mention the time required for setup and maintenance.
The truth is that cloud based testing can be as safe as on-premises testing. The best guarantee of security is, in fact, a good cloud based testing service, which can implement measures specifically designed to provide a high level of test security.
Sauce Laboratories, for example, provides a high-security tunnel for test data, with a single-use virtual test machine which is destroyed when you close the tunnel. Sauce also provides Transport Layer Security (TLS) encryption for test data. When you follow the recommended practice of using one tunnel per test suite, the result is a test environment which is effectively as secure as anything you could set up on-premises.
Good test security, of course, requires a high level of security consciousness on your part, but this is always the case, with any kind of security, in any environment. The key take-home point is that a first-rate cloud based testing service makes it easy to maintain that security consciousness, and implement the measures on your end which will make cloud based testing truly secure.
Michael Churchman started as a scriptwriter, editor, and producer during the anything-goes early years of the game industry. He spent much of the 90s in the high-pressure bundled software industry, where the move from waterfall to faster release was well under way, and near-continuous release cycles and automated deployment were already de facto standards. During that time he developed a semi-automated system for managing localization in over fifteen languages. For the past ten years, he has been involved in the analysis of software development processes and related engineering management issues.