Interactive administration in the cloud: managing the risks

In the NCSC’s cloud platforms guidance (and most recently in our lift and shift sections), we recommend that you protect the use of legacy management protocols – such as RDP and SSH. This practise is arguably more important in the cloud than it’s ever been on-premises, due to the inherent connectivity that cloud environments offer.

Despite traditional approaches to secure remote access now being relatively well understood, we know that it can be difficult to understand the alternative protections available in the cloud, and (crucially) the benefits that adopting these more modern solutions can bring.

In this blog, I’ll discuss approaches to ‘secure infrastructure administration in the cloud’, and will explore our thinking on several additional best practises that can help you to improve the broader security posture of your cloud environment.

Protecting your management interfaces

Legacy management protocols like RDP and SSH can be used to remotely access and administer infrastructure (such as virtual machines) over a network.

In a traditional, on-premises environment, it’s common for management interfaces to be exposed locally to an internal management network. In the cloud, however, these same interfaces are often exposed directly to (and accessed via) the public internet instead. This often default configuration provides customers with a familiar access route to administer their infrastructure, but it also changes the attack surface, as it’s now easier for third parties to discover and target these cloud resources too.

Through the NCSC’s Active Cyber Defence (ACD) function (alongside data from NCSC Incident Management and in open source), we’ve seen that attackers routinely target exposed management interfaces. They attempt to exploit weaknesses such as insecure interface configurations and management protocol vulnerabilities to gain initial access. If successful, this compromised infrastructure is often used as the foundation for lateral movement or for achieving more impactful outcomes such as data theft, denial of service, or the deployment of ransomware. Unfortunately, due to the prevalence of exposed infrastructure and the potential gains from successful attacks, exposed management interfaces remain an enticing target for many attackers.

To help mitigate this risk, we’ve long recommended that management interfaces are protected from untrusted networks. These protections can take many forms. A traditional solution, often seen on-premises, is to use an administration proxy (also known as a bastion host or jump box). This is typically a virtual machine (VM) that’s configured to provide secure and strongly authenticated remote access to infrastructure on a local network. As a core security-enforcing resource, an administration proxy must be well-secured, patched, and hardened against attack. However, this process can be resource intensive and error prone, particularly at scale.

Using an administration proxy service in the cloud

Looking to the cloud, many providers now offer modern alternatives to the traditional administration proxy. These ‘administration proxy services’ provide customers with an administrative access route to their cloud infrastructure, and typically integrate with native features of the cloud platform such as networking, identity management, and log storage.

To support a range of different cloud architectures, it’s common to see multiple administration proxy services (or other modern remote access mechanisms) available within a single platform. Each solution may look quite different. For example, one solution might be agentless and another agent-based. Common examples include AWS Systems Manager Session Manager, Google Cloud Identity-Aware Proxy, and Azure Bastion.

You should look to use an administration proxy service that meets the following conditions:

Some cloud providers choose to implement their administration proxy service as the default administrative access mechanism within their platform. This configuration makes it easy to adopt a secure by default approach and can make it almost effortless for administrators to gain secure (and strongly authenticated) access to cloud infrastructure when required. Where possible, you should prefer to use an administration proxy service over more traditional remote access methods.

In more legacy cloud environments, where more traditional remote access architectures must still be used, you might still be able to gain some of the benefits of using an administration proxy service by taking a hybrid approach. This might involve using an administration proxy service to gain access to an existing administration proxy VM from which you can connect onwards (using management protocols like RDP and SSH) to your more legacy infrastructure. 

Reducing your management burden

Now I’ve demonstrated some of the benefits that using a managed service can bring to your infrastructure administration practises, you should look to adopt this general pattern more widely by choosing to use other managed services throughout your cloud environment. This might include storing data in a managed database, or hosting your workloads using a serverless compute platform.

Taking serverless compute as an example, infrastructure and host patching operations can be performed frequently and transparently by your trusted cloud provider. You won’t need to worry about how your administrators gain remote access to infrastructure (using an administration proxy service or otherwise), or how and when they’ll perform the updates. This reduces your management overheads and can help to keep your workloads secure against known vulnerabilities. It’s a win-win!

You might be adopting this approach already, without even knowing it, as object storage services in the cloud are often only provided as a fully managed solution. You have no management responsibility for (and no direct access to) the underlying hosts or to any running software. 

Limiting access to your sensitive workspaces

Finally, in a similar vein, you should look to minimise the amount of interactive (human) access required to each of your workspaces. This is especially important for more sensitive workspaces, such as those that store and process sensitive data or that host business critical applications (production environments, for example).

A common approach is to replace traditional, manual processes with automated, hands-off alternatives. This might mean replacing ‘ClickOps’ actions in the cloud console with the use of infrastructure as code (IaC) and a secure CI/CD mechanism. Deploying resources in this way can help you to better monitor your workspaces over time, as any unsanctioned or unwanted activity (such as ‘ClickOps’ actions) will be easier to detect. As a result, it should be more challenging for the resources (and data) within each workspace to be accessed or changed unexpectedly. Additionally, in the event of an incident or outage, access to IaC templates can make it simpler for you to quickly recreate the resources in each workspace.

To fully adopt this approach, you might have to make changes to your existing processes. You might now need to create immutable resources (that are created and destroyed during updates) rather than updating your existing infrastructure in-place. In the long term, this will provide you with repeatable deployments that are more straightforward to manage, monitor, and maintain through time. 

(Whilst automated and hands-off deployments are the goal, emergency access should always be retained for each workspace. This access should be treated as high-risk and configured with strong alerting to monitor when this access is used.)

The end goal

If you adopt the approaches I’ve discussed throughout this blog, you will now: