Cloud Infrastructure Security: Securing the 7 Key Components

What is Cloud Infrastructure Security?

Cloud infrastructure security is the practice of securing resources deployed in a cloud environment and supporting systems. 

Public cloud infrastructure is, in many ways, more vulnerable than on-premises infrastructure because it can easily be exposed to public networks, and is not located behind a secure network perimeter. However, in a private or hybrid cloud, security is still a challenge, as there are multiple security concerns due to the highly automated nature of the environment, and numerous integration points with public cloud systems.

Cloud infrastructure is made up of at least 7 basic components, including user accounts, servers, storage systems, and networks. Cloud environments are dynamic, with short-lived resources created and terminated many times per day. This means each of these building blocks must be secured in an automated and systematic manner. Read on to learn best practices that can help you secure each of these components.

In this article, you will learn:

• Securing Public, Private, and Hybrid Clouds
• Securing 7 Key Components of Your Cloud Infrastructure
• Cloud Infrastructure Security with Aqua

Securing Public, Private, and Hybrid Clouds

Cloud security has different implications in different cloud infrastructure models. Here are considerations for security in each of the three popular models—public cloud, private cloud, and hybrid cloud.

Public Cloud Security

In a public cloud, the cloud provider takes responsibility for securing the infrastructure, and provides tools that allow the organization to secure its workloads. Your organization is responsible for:

• Securing workloads and data, fully complying with relevant compliance standards, and ensuring all activity is logged to enable auditing.
• Ensuring cloud configurations remain secure, and any new resources on the cloud are similarly secured, using automated tools such as a Cloud Security Posture Management (CSPM) platform.
• Understanding which service level agreements (SLA), supplied by your cloud provider, deliver relevant services and monitoring.
• If you use services, machine images, container images, or other software from third-party providers, performing due diligence on their security measures and replacing providers if they are insufficient.

Private Cloud Security

The private cloud model gives you control over all layers of the stack. These resources are commonly not exposed to the public Internet. This means that you can achieve a certain level of security using traditional mechanisms that protect the corporate network perimeter. However, there are additional measures you should take to secure your private cloud:

• Use cloud native monitoring tools to gain visibility over any anomalous behavior in your running workloads.
• Monitor privileged accounts and resources for suspicious activity to detect insider threats. Malicious users or compromised accounts can have severe consequences in a private cloud, because of the ease at which resources can be automated.
• Ensure complete isolation between virtual machines, containers, and host operating systems, to ensure that compromise of a VM or container does not allow compromise of the entire host. 
• Virtual machines should have dedicated NICs or VLANs, and hosts should communicate over the network using a separate network interface.
• Plan ahead and prepare for hybrid cloud by putting security measures in place to ensure that you can securely integrate with public cloud services

Hybrid Cloud Security

Hybrid clouds are a combination of on-premise data center, public cloud, and private cloud. The following security considerations are important in a hybrid cloud environment:

• Ensure public cloud systems are secured using all the best practices.
• Private cloud systems should follow private cloud security best practices, as well as traditional network security measures for the local data center.
• Avoid separate security strategies and tools in each environment—adopt a single security framework that can provide controls across the hybrid environment.
• Identify all integration points between environments, treat them as high-risk components and ensure they are secured.

Learn more in our detailed guides to:

• Hybrid cloud security ›
• Multi cloud security ›

Securing 7 Key Components of Your Cloud Infrastructure

Here are key best practices to securing the key components of a typical cloud environment.

Accounts

Service accounts in the cloud are typically privileged accounts, which may have access to critical infrastructure. Once compromised, attackers have access to cloud networks and can access sensitive resources and data. 

Service accounts may be created automatically when you create new cloud resources, scale cloud resources, or stand up environments using infrastructure as code (IaC). The new accounts may have default settings, which in some cases means weak or no authentication. 

Use identity and access management (IAM) to set policies controlling access and authentication to service accounts. Use a cloud configuration monitoring tool to automatically detect and remediate non-secured accounts. Finally, monitor usage of sensitive accounts to detect suspicious activity and respond.

Servers

While a cloud environment is virtualized, behind the scenes it is made up of physical hardware deployed at multiple geographical locations. This includes physical servers, storage devices, load balancers, and network equipment like switches and routers. 

Here are a few ways to secure a cloud server, typically deployed using a compute service like Amazon EC2:

• Control inbound and outbound communication—your server should only be allowed to connect to networks, and specific IP ranges needed for its operations. For example, a database server should not have access to the public internet, or any other IP, except those of the application instances it serves. 
• Encrypt communications—whether communications go over public networks or within a secure private network, they should be encrypted to avoid man in the middle (MiTM) attacks. Never use unsecured protocols like Telnet or FTP. Transmit all data over HTTPS, or other secure protocols like SCP (Secure Copy) or SFTP (Secure FTP).
• Use SSH keys—avoid accessing cloud servers using passwords, because they are vulnerable to brute force attacks and can easily be compromised. Use SSH keys, which leverage public/private key cryptography for more secure access.
• Minimize privileges—only users or service roles that absolutely need access to a server should be granted access. Carefully control the access level of each account to ensure it can only access the specific files and folders, and perform specific operations, needed for their role. Avoid using the root user—any operation should be performed using identified user accounts. 

Hypervisors

A hypervisor runs on physical hardware, and makes it possible to run several virtual machines (VMs), each with a separate operating system. 

All cloud systems are based on hypervisors. Therefore, hypervisors are a key security concern, because compromise of the hypervisor (an attack known as hyperjacking) gives the attacker access to all hosts and virtual machines running on it.

In public cloud systems, hypervisor security is the responsibility of the cloud provider, so you don’t need to concern yourself with it. There is one exception—when running virtualized workloads on a public cloud, using systems like VMware Cloud, you are responsible for securing the hypervisor.

In private cloud systems, the hypervisor is always under your responsibility. Here are a few ways to ensure your hypervisor is secure:

• Ensure machines running hypervisors are hardened, patched, isolated from public networks, and physically secured in your data center
• Assign least privileges to local user accounts, carefully controlling access to the hypervisor
• Harden, secure, and closely monitor machines running the virtual machine monitor (VMM) and virtualization management software, such as VMware vSphere
• Secure and monitor shared hardware caches and networks used by the hypervisor
• Pay special attention to hypervisors in development and testing environments—ensure appropriate security measures are applied when a new hypervisor is deployed to production

Storage

In cloud systems, virtualization is used to abstract storage from hardware systems. Storage systems become elastic pools of storage, or virtualized resources that can be provisioned and scaled automatically. 

Here are a few ways to secure your cloud storage services:

• Identify which devices or applications connect to cloud storage, which cloud storage services are used throughout the organization, and map data flows. 
• Block access to cloud storage for internal users who don’t need it, and eliminate shadow usage of cloud services by end users. 
• Classify data into sensitivity levels—a variety of automated tools are available. This can help you focus on data stored in cloud storage that has security or compliance implications.
• Remove unused data—cloud storage can easily scale and it is common to retain unnecessary data, or entire data volumes or snapshots that are no longer used. Identify this unused data and eliminate it to reduce the attack surface and your compliance obligations.
• Carefully control access to data using identity and access management (IAM) systems, and applying consistent security policies for cloud and on-premises systems.
• Use cloud data loss prevention (DLP) tools to detect and block suspicious data transfers, data modification or deletion, or data access, whether malicious or accidental. 

Databases

Databases in the cloud can easily be exposed to public networks, and almost always contain sensitive data, making them an imminent security risk. Because databases are closely integrated with the applications they serve and other cloud systems, those adjacent systems must also be secured to prevent compromise of the database.

Here are a few ways to improve security of databases in the cloud:

• Hardening configuration and instances—if you deploy a database yourself in a compute instance, it is your responsibility to harden the instance and securely configure the database. If you use a managed database service, these concerns are typically handled by the cloud provider.
• Database security policies—ensure database settings are in line with your organization’s security and compliance policies. Map your security requirements and compliance obligations to specific settings on cloud database systems. Use automated tools like CSPM to ensure secure settings are applied to all database instances.
• Network access—as a general rule, databases should never be exposed to public networks and should be isolated from unrelated infrastructure. If possible, a database should only accept connections from the specific application instances it is intended to serve. 
• Permissions—grant only the minimal level of permissions to users, applications and service roles. Avoid “super users” and administrative users with blanket permissions. Each administrator should have access to the specific databases they work on.
• End user device security—security is not confined to the cloud environment. You should be aware what endpoint devices administrators are using to connect to your database. Those devices should be secured, and you should disallow connections from unknown or untrusted devices, and monitor sessions to detect suspicious activity.

Network

Here are a few ways you can secure cloud networks:

Cloud systems often connect to public networks, but also use virtual networks to enable communication between components inside a cloud. All public cloud providers let you set up a secure, virtual private network for your cloud resources ( called a VPC in Amazon and a VNet in Azure).  

• Use security groups to define rules that define what traffic can flow between cloud resources. Keep in mind that security groups are tightly connected to compute instances, and compromise of an instance grants access to the security group configuration, so additional security layers are needed.
• Use Network Access Control Lists (ACL) to control access to virtual private networks. ACLs provide both allow and deny rules, and provide stronger security controls than security groups. 
• Use additional security solutions such as firewalls as a service (FWaaS) and web application firewalls (WAF) to actively detect and block malicious traffic.
• Deploy Cloud Security Posture Management (CSPM) tools to automatically review cloud networks, detect non-secure or vulnerable configurations and remediate them.

Kubernetes

When running Kubernetes on the cloud, it is almost impossible to separate the Kubernetes cluster from other cloud computing layers. These include the application or code itself, container images, compute instances, and network layers. Each layer is built on top of the previous layer, and all layers must be protected for defense in depth.

The Kubernetes project recommends approaching security from four angles, known as the “4 Cs”:

• Code—ensuring code in containers is not malicious and uses secure coding practices
• Containers—scanning container images for vulnerabilities, and protecting containers at runtime to ensure they are configured securely according to best practices
• Clusters—protecting Kubernetes master nodes and ensuring cluster configuration is in line with security best practices
• Cloud—using cloud provider tools to secure the underlying infrastructure, including compute instances and virtual private clouds (VPC)

Compliance with security best practices, industry standards and benchmarks, and internal organizational strategies in a cloud-native environment also face challenges.

In addition to maintaining compliance, organizations must also provide evidence of compliance. You need to adjust your strategy so that your Kubernetes environment fits the controls originally created for your existing application architecture.

Learn more in our detailed guide to Kubernetes security best practices ›

Aqua Cloud Security Posture Management (CSPM)

Scan, monitor and remediate configuration issues in public cloud accounts according to best practices and compliance standards, across AWS, Azure, Google Cloud, and Oracle Cloud.CSPM

Eliminate misconfigurations in your public cloud accounts

Aqua CSPM provides automated, multi-cloud security posture management to scan, validate, monitor, and remediate configuration issues in your public cloud accounts. Aqua CSPM ensures the use of best practices and compliance standards across AWS, Azure, Google Cloud, and Oracle Cloud — including Infrastructure-as-code templates.

Protect against:

• Servers exposed publicly to the internet
• Unencrypted data storage
• Lack of least-privilege policies
• Poor password policies or missing MFA
• Misconfigured backup/restore settings

Multi-cloud visibility – Gain visibility across all your cloud accounts

Aqua CSPM continuously audits your cloud accounts for security risks and misconfigurations to assess your infrastructure risk and compliance posture. It provides checks across hundreds of configuration settings and compliance best practices to ensure consistent, unified multi-cloud security.

Rapid remediation – Find and fix misconfigurations before they’re exploited

Aqua provides self-securing capabilities to ensure your cloud accounts don’t drift out of compliance. Get detailed, actionable advice and alerts, or choose automated remediation of misconfigured services with granular control over chosen fixes.

Enterprise scale – Unify security across VMs, containers, and serverless

Protect applications in runtime on any cloud, orchestrator, or operating system using a zero-trust model that provides granular control to accurately detect and stop attacks. Leverage micro-services concepts to enforce immutability and micro-segmentation.