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.

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.

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.