For the best user experience please upgrade your browser

Cloud Services Security

Securing Data and Assets in the Cloud

Over the last few years, there has been a huge shift in to hosting data and services in the cloud. The elasticity, scalability, and agility of the services offered allows a well-designed cloud infrastructure to be an extremely cost-effective solution to business requirements.

Due to the abstraction of resources however, securing this data is now the responsibility of two parties, the client, and the Cloud Service Provider (CSP). Whilst the CSP can give assurances to the physical security, hardware, networking, and some operating system elements, ultimately the responsibility for security belongs to the client, and therefore understanding the risks in your environment is key to maintaining security.

The shared responsibility model below shows some of the demarcation points of security responsibility in the cloud.

CSPs offer a vast amount of services that can be utilized, and many of these are extremely specific to certain tasks, for example text to speech, automatic image analysis, and even quantum computing. If you have a requirement, there is a strong possibility that there is a cloud service tailored for your needs.

However, the core services used across all CSPs can be broken down into the following areas:

  • Identity and Access Management
  • Networking
  • Storage
  • Compute Resources
  • Databases

Whilst all services should be appropriately secured, the core services listed above are those most similar to on-premise solutions.

Identify and Access Management

Identity and Access Management (IAM) is key to access control security within an environment.

Users can have rights assigned directly to their account, be put into a group, and inherit the group rights, be granted a role, or even be governed by a policy and integrated with already existing identity managers (e.g. Active Directory). It is possible that through misconfigurations of roles, policies, groups, or users, that a user could have unrequired levels of access.

Consider the scenario in which a user has rights to edit the settings of a virtual machine, but not create resources. The service account the virtual machine uses may have additional rights. The user may then edit the virtual machine configuration in a manner that gives them control of the service account therefore elevating their privileges.

Ensuring authentication and authorisation is managed correctly is a vital first step in the securing the cloud. This includes multi-factor authentication, single sign-on solutions, role-based access control, and more.


On-prem, in the cloud, or anywhere else. Systems need to communicate, and networks need to be deployed.

Virtual Private Networks (VPCs), subnets, and route tables define the topology, however Network Security Groups (NSGs) are the key to securing them. Traditional firewalls can also be deployed, however NSGs tend to be used for internal security, with firewalls controlling the perimeter.

NSGs can be applied to a host, a network card, a subnet, or a service meaning a full understanding of what rules apply to each asset can be a challenge. It is common to allow all internal resources to freely communicate, assuming the perimeter is secure. A security audit will therefore aim to give a contextualised view of the intra-service communications to help ensure defence in depth.

Reviews will also ensure any compliance or security requirements are met such as ensuring end to end encryption or allowing traffic to flow one way through a network out to clients while disallowing connection requests from the internet.


All CSPs offer unstructured storage, known as buckets. These are used to store data such website content, log data, build scripts, customer data, or anything else you need readily available.

The access controls to buckets are extremely important as several high-profile breaches have been the result of improperly secured buckets.

Encryption at rest, and during transit should be considered as well as the key material to encrypt bucket contents.

Recommendations can be made to ensure that buckets and their access is secure. Due to the multitude of options CSPs provide for data security choosing the most relevant for any environment can be challenging. Our cloud experts can shed light on the choices you may be facing and ensure that implementations are robust and production ready.

Compute resources

Virtual machines, serverless code functions, and containerisation platforms such as Docker and Kubernetes are all compute resources, and all have their own specific challenges regarding security. Virtual machines require operating system updates and patch management in line with an on-promise solution.

A serverless function may not have an underlying operating system to maintain but may store secrets as environment variables that may be revealed in certain circumstances. Given the elasticity of the cloud environment the server may be deleted and re-initiated frequently. This means the source image that is used to build the system needs to be patched.

However, if the virtual machine runs for a long time, then patching the source image alone would mean the virtual machine would fall behind. Secure build and maintenance processes are therefore key. This is especially the case with containerisation services such as Docker and Kubernetes.

In a Kubernetes cluster for example, service may be invoked and destroyed thousands of times a day. The Kubernetes service should be secured to prevent unauthorized access; however, it is more common for access to be granted through a service offered by a pod. If the pod is compromised then it may be possible to attack the node, cluster, or even hosts outside of the service.

Automated security is required in containerized environments as it is not possible to manage pods effectively directly.


Considerations for database security in the cloud are much the same as they are for on-premise, however with a few additional points.

CSPs offer updated and automated ways to securely access and run a database for your environments.

Access to databases should be granted using secrets, or service accounts rather than traditional credentials.

Data encryption at rest and in transit, along with the key material should be assessed to ensure integrity.

Log file storage and access controls should be well protected.

Cloud specific functionality such as scaling, and snapshotting would also require security reviews.

Other considerations

This document has outlined some of the security concerns, with some of the core services in cloud environments, however there are thousands of services across CSPs, each with their own security considerations.

With security the cloud, it is important to consider the flow of information into, and out of the services, and how the service is checking for authentication and authorization.

Usernames and passwords factor less into cloud security than authentication tokens do.

It is sadly common to find access keys hard coded into applications or published to public code repositories. At this point the keys can be used to authenticate to services and carry out actions with their respective permissions.

It is therefore important to consider all aspects of the deployment including:

  • Access controls including token usage
  • Automated deployment pipelines (CI/CD)
  • Configuration
  • Maintenance
  • Logging
  • Backups
  • Compliance

Top 10 security considerations

Why wait until the penetration test results to start securing your cloud service? Below are 10 security questions to consider immediately:

  1. Are all my users, service accounts, groups, roles, and policies configured in line with the principal of least privilege?
  2. Are all external services adequately protected with Web Application Firewalls, Virtual Firewalls, and Network Security Groups?
  3. Is my internal network correctly segregated and firewalled to prevent one compromised host from accessing other, unrelated resources?
  4. Are my storage buckets secured, preventing unauthorised access?
  5. If an access key were compromised or leaked, how long would it take me to notice and revoke access?
  6. Are my virtual machines, including containers, automatically patched, tested, and deployed ensuring security is maintained?
  7. Are my serverless functions coded securely to prevent compromise?
  8. Is my data secured at rest using key material under my control?
  9. Are services communicating both internally and externally over encrypted protocols?
  10. Would I notice if resources were created in other regions either maliciously or accidentally?

How we can help you?

Traditional on-premise security testing generally consists of testing assets that are already there.

Given the ephemeral nature of some cloud services, it is important to assess the development and deployment of resources to ensure they are secure before, during, and even after deployment.

By working with clients to understand their business requirements, we can offer security services from the design phase, to working in live environments to assess and advise on relevant security practices.