Sitemap

Cloud Security Implementation

5 min readFeb 8, 2024

--

Cloud services demand specific cybersecurity methodologies and technologies. In principle, those are similar to security solutions for on-premises, but some aspects demand close attention for proper implementation in a cloud environment.

The most basic level to understand cloud cybersecurity demands is the nature and use of instances. These are all cloud assets and services (i.e., virtualized hardware and software) used for specific IT and business roles. The process of managing instances has scalable and elastic components. The first one refers to the process of provisioning or de-provisioning instances. In contrast, the second describes dynamic resource allocation, i.e., computational resources may be redirected from one instance to another. Those two aspects happen in response to ever-changing business environment demands.

Cloud security solutions must be adaptable to the dynamic nature of instance use and management. Two factors may help surmise this context:

  1. Constant provisioning and de-provisioning affect asset visibility. Companies must seek solutions that provide instance monitoring, avoiding situations where unnecessary instances consume resources that should not be acquired in the first place or that could be redirected to priority services;
  2. Creating and managing instances involves authentication and authorization. There must be rules regarding which users or applications have the necessary clearance to create instances. Additionally, when a cloud resource is provisioned, it must have the correct level of access privileges so it can function properly and securely.

Various security methodologies and technologies, discussed below, can be applied to meet those demands.

Cloud Policies

Users, applications, and cloud resources must access other cloud services to execute organizational functions. Like access control implemented in on-premises infrastructure, the cloud has policies that regulate authorization across its environment.

Those access policies may be attached to the user’s or the application’s identities (identity-based policies) or to the actual resource whose access the policy controls (resource-based policies). They manage access by determining which resources can be accessed and how this access happens (e.g., write, read, and execute authorizations).

Get Rodolfo Santos Flaborea’s stories in your inbox

Join Medium for free to get updates from this writer.

Conflict between the two types of policies happens when both are applied simultaneously in the same organizational environment. The security professional must remember one simple rule: any explicit-deny rule cancels any allow rule (see diagram below). So if an employee has access to resource A by the identity-based policy but has access to this resource denied by the resource-based policy, the deny rule wins.

Simple diagram illustrating the main aspects of identity-based and resource-based cloud policies. Note the conflict between the two policies: Carlos Salazar may have the right to list and read resource Z through the identity-based policy but has been denied access determined by the resource-based policy. Following the policy conflict resolution, the explicit-deny rule supersedes the allow rule, so Salazar cannot access resource Z. Extracted from: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html.

Security Groups and Access Controle Lists (ACLs)

Cloud security groups are, in principle, akin to a traditional firewall. They have rules that manage traffic between instances/services in the same cloud environment and between those and the exterior. Notwithstanding, security groups present aspects that separate them from firewalls:

  • They follow an allow principle, so they can’t explicitly deny access;
  • They directly control access to destination ports only. However, they are stateful, i.e., when inbound traffic is authorized to a particular port, the outbound traffic from the same port is also permitted;
  • By default, only SSH traffic (port 22) is allowed. All other rules must be established before implementing the security group.

ACLs are an alternative to security groups, especially between virtual subnets. They control traffic too but can be stateless and offer explicit-deny rules.

Third-Party Security Solutions

Native security solutions like the previous ones are adequate cybersecurity measures. Still, they can’t sufficiently cover scenarios where companies acquire multiple cloud services from different CSPs. This is because both CSPs and clients abide by the shared responsibility model rules: a CSP cannot cover security demands that are the client’s or another CSP’s responsibility. Third-party solutions, like Cloud Access Security Brokers (CASBs), Next-Generation Secure Web Gateways (SWGs), and Software-Defined Perimeter (SDP), jointly provide cybersecurity services for those complex situations.

CASBs aim to provide access, authorization, and visibility for SaaS services. SWGs, in turn, filter traffic to applications by monitoring and enforcing rules at layers 3 and 7, offering protection against malicious requests and other application attacks. SDPs mainly work in the IaaS context as part of an SDN approach. Still, they are focused on network perimeter security, acting as gateways and firewalls and controlling application access at the management plane. CSPs may offer third-party solutions in their marketplaces.

Press enter or click to view image in full size
Diagram illustrating how a CASB from the company Lookout manages access to multiple cloud services from different CSPs. Extracted from: https://www.lookout.com/glossary/what-is-a-cloud-access-security-broker-casb.

It’s important to note that those technologies have defined scope/layers where they can work. Combining them in a stacked security solution may cover each other’s gaps with each other’s strengths. This model, often called Zero Trust, includes an extensive architecture that provides fine control over access to organizational resources. Implementing and managing them can provide structural (architecture and awareness) and situational awareness (operations and incident response).

Secrets Management

CPSs frequently offer management services for credentials and cryptographic keys. They encrypt that information at rest and in transit and establish access rules following specific organizational policies. These services cover access to both users and applications, including APIs.

Central Logging

As described above, cloud environments are dynamic, with instances with different roles being provisioned and de-provisioned and constantly interacting with users, external applications, and each other. Proper visibility is paramount for cybersecurity awareness, whether structural (cloud architecture) or situational (incident response).

Central logging solutions consolidate and analyze events across all cloud services, especially at the infrastructure level, as the basis for good security awareness.

Virtual Private Clouds (VPCs)

VPCs are private networks inside cloud environments, frequently composed of multiple subnets. Using a VPC endpoint, companies may establish connections between VPCs and other organizational assets (e.g., other networks, devices, or services inside and outside the cloud environment), similar to VPN use cases.

Press enter or click to view image in full size
Diagram showing the interaction between different VPCs through a VPC endpoint. Extracted from: https://aws.amazon.com/blogs/architecture/reduce-cost-and-increase-security-with-amazon-vpc-endpoints/.

--

--

Rodolfo Santos Flaborea
Rodolfo Santos Flaborea

Written by Rodolfo Santos Flaborea

Psychologist and Cybersecurity Student. Holds CompTIA Security+ and CREST CPTIA (Cyber Threat Intelligence) certifications.