Cloud Security Infrastructure Transition: Technical Constraints of Security Products and Solutions

1. Digital Transformation of IT Infrastructure from On-Premise to Cloud

Digital transformation is a trend that goes beyond simply storing data in the cloud; it innovates the fundamental structure of a company's working methods and IT infrastructure. 

Traditional networks and data centers based on on-premise environments are gradually migrating to public or private cloud environments, offering flexible operation of IT resources and cost efficiency. However, the burden of redesigning existing security systems is increasing simultaneously. 

In particular, systems in the cloud are configured based on a logical network structure called VPC (Virtual Private Cloud). This requires a completely different security approach compared to traditional physical networks. For instance, in an on-premise environment, security devices such as firewalls, IPS, and DLP could be placed on the physical path to directly control traffic. 

However, in the cloud, physical connections between these devices are impossible, and network flows can only be controlled within limited paths. This presents new challenges in terms of security product placement, traffic flow management, and securing visibility. 

2. Hurdles in Security Product Transition: Technical Constraints of the Cloud Environment

When configuring security products in cloud infrastructure, there are network and traffic control constraints completely different from those in on-premise environments. Let’s look at some representative examples. 

2.1. Direct Network Connection Between Devices is Impossible

Within the cloud, direct connections between VMs (Virtual Machines) via specific dedicated links or L2 bridges are not possible. All VMs are connected only through a Virtual Switch, and routing policies must be used to configure traffic paths. In other words, security VMs are forced to operate as L3 routing hops rather than in the form of L2 bridges. 

[Figure 1] Example of implementing an on-premise environment directly into the cloud

Due to these characteristics, Transparent Inline configurations (such as WAF or IPS), which were commonly used in on-premise environments, are difficult to apply in the cloud. Furthermore, ensuring High Availability (HA) through hardware bypass functions provided by physical appliances is virtually impossible to implement. 

This is because the internal cloud structure allows only single-path-based traffic flows, rather than TAP, mirroring, or bridge methods. 

Therefore, functions requiring collaboration between security devices, such as DPI (Deep Packet Inspection) and traffic analysis, face constraints compared to on-premise environments. In the cloud, it is essential to design a routing-based security architecture that can bypass or replace these limitations. 

2.2. Network Flow Resulting in SNAT When Passing Through Security Products

Cloud network environments are divided by subnets, and each subnet is designed to look at the IGW (Internet Gateway) as its default gateway. Security products also run as VMs within defined subnets, and they too use the IGW as their default gateway. 

Even if service traffic is configured via routing policies to necessarily pass through security VMs, constraints arise for the response traffic to return along the same path. Since all VMs recognize the IGW as their default gateway, SNAT (Source NAT) processing eventually becomes necessary. 

[Figure 2] Traffic flow based on SNAT usage

This is a common operational method in cloud environments. For example, the Load Balancer (LB) service provided by the cloud also uses SNAT to return responses normally. In fact, many network services provided in the cloud operate on this SNAT-based structure. 

The problem is that the original IP is changed during this process. If SNAT is applied in a general inline configuration, security devices can only see the translated IP, not the original. 

This limits the ability to trace the actual origin of an attack or to apply granular session-based policies. Consequently, security visibility and traceability are degraded, leading to reduced precision in policy control. 

2.3. Difficulty in Applying Selective SSL Decryption in VPC

The SSL Termination function provided by the Load Balancer (LB) in a VPC decrypts encrypted traffic and delivers it to the desired target. 

While this method offers high convenience, it is difficult to precisely designate the scope of decryption. Since SSL decryption is applied uniformly across the entire VPC, security vulnerabilities may exist. Accordingly, some customers want to apply SSL decryption selectively, limited only to specific security product sections. 

In particular, customers who operated SSL VA (Visibility Appliance) products in on-premise environments to apply decryption only to selective sections desire to operate with the same configuration in the cloud, creating a need for a solution.

Failure to apply decryption only to the desired scope can lead to unnecessary exposure of personal information and difficulties in meeting security requirements. This is a major limitation to consider when handling SSL traffic in a cloud environment. 

2.4. Redirect-Based Configuration Unavailable; Only Route-Based Configuration Possible

In on-premise environments, various methods such as Policy-Based Routing (PBR), GRE tunnels, and L2 Redirects are used to guide traffic to security devices. In particular, the MAC-based Redirect function via L4 switches is a representative method for inserting security devices into the traffic path transparently. However, this configuration is difficult in the cloud. 

Cloud networks basically communicate based only on the IP addresses assigned to VMs by the hypervisor and do not support MAC routing or L2 Redirects. Therefore, you cannot naturally insert security devices into the path using the Redirect function of an L4 switch as you would on-premise. 

[Figure 3] Example of passing through security products via Route configuration 

Since most cloud platforms provide a static routing table-based structure, explicit path settings are required to guide traffic to security devices. This brings fundamental constraints to flexibly controlling traffic flows or dynamically changing paths. 

2.5. Mandatory HA Configuration and Increased Costs Due to Above Constraints

In the cloud, security devices cannot be transparently inserted into the traffic path, and path control is possible only through routing policies. 

For this reason, security devices are generally located on a single path. If a problem occurs with the device, it carries the risk of leading directly to a total service outage. To prevent this, an Active-Standby High Availability (HA) configuration is virtually essential. 

However, implementing HA requires introducing separate components like load balancers and health checks, or implementing redundancy within the security product itself, which complicates the architecture and increases management points. Furthermore, the additional resources required for redundancy lead to increased costs. 

Ultimately, to guarantee service availability in the cloud, redundancy of security devices is inevitable, but this creates new challenges of cost burden and operational complexity.  

3. The Necessity and Role of L4/L7 Switch Technology

LB services provided in cloud environments focus solely on SLB (Server Load Balancing). They focus only on the SLB function among the various functions provided by ADC (Application Delivery Controller, L4/L7 Switch) products mainly used on-premise. 

However, to configure security products by resolving cloud constraints, various functions capable of determining traffic paths—such as CSLB, FWLB, GWLB, and ILB found in commercial ADCs—are required. 

Accordingly, as demand for cloud migration from on-premise increases, traffic processing methods based on L4/L7 switches provided by ADCs are gaining attention. L4 switches allow session branching at the TCP/UDP level, while L7 switches enable granular traffic control at the application level. 

These allow traffic to be guided to specific security devices even in cloud environments, or enable conditional decryption and filtering, offering the following benefits:

● Conditional SSL Decryption & Service Chain Configuration: Decryption can be applied only to desired sections for critical services, while general traffic is bypassed, securing both performance and privacy protection.

 [Figure 4] Example of Service Chain Configuration

● Minimization of Existing NAT Constraints: Retention of original IPs and session tracking become possible, increasing the accuracy of security policies.

● Load Balancing Between Security Devices & Failover: Flexible traffic processing and collaboration between devices are possible to guarantee high availability. 

This flexible traffic processing structure based on L4/L7 switches is becoming a core pillar in designing cloud security infrastructure. There are various cloud-dedicated ADCs, with PIOLINK's cloud-dedicated product, PAS-KS, being a representative example. 

[Figure 5] Example of SSL Section Decryption + Security Product LB + Application LB Configuration using PAS-KS

4. Government 3-Line Security Control System Requirements and PAS-KS Utilization

Public and financial institutions are required to have a 3-line security control system according to government guidelines. Accordingly, traffic flows must be segmented, and inline real-time detection must be carried out in parallel with log-based detection. PAS-KS proposes the following two operational methods to meet these requirements. 

● TMS (Threat Management System) Mirroring Configuration: PAS-KS performs detection in passive mode through L4 switch-based traffic replication, without affecting original traffic. This has the advantage of maintaining detection accuracy without causing service delays. 

● Service Chain-Based Inline Configuration: PAS-KS is incorporated as part of a specific security service chain to apply SSL decryption and detection functions in real-time. Since the scope of application can be designated based on policy, flexible control system configuration is possible. For example, this includes the function of distinguishing between WEB and Non-WEB traffic and transmitting it to the necessary security products.

These configurations enable the implementation of a security architecture that satisfies both policy compliance and performance while overcoming the technical constraints of the cloud environment. 

[Figure 6] Naver Cloud 3-Line Security Control System Configuration Case  

5. Conclusion

Applying security products in a cloud environment goes beyond simply placing devices; it requires a design that considers the understanding of the cloud network structure and technical constraints. In the cloud, where traditional methods are not permitted, L4/L7 switch-based traffic control is establishing itself as a core technology, allowing for the simultaneous assurance of security and flexibility. 

PAS-KS is a platform that aligns with these technological trends. It can serve as a pillar of cloud security architecture through selective SSL decryption, flexible inline/mirroring configurations, and service chain configurations. In particular, by supporting policy-based configurations and high-availability processing structures, it offers the flexibility and scalability to respond to diverse cloud security requirements. 

Future cloud security is being designed around the 'path' of traffic, and security platforms like PAS-KS will play a significant role at the center of that flow. 

This is evolving beyond the simple deployment of security products into part of a higher-level concept called 'Security Architecture Design.' Security in the cloud environment requires a comprehensive approach combining technology and strategy, and PAS-KS will establish itself as one of the solutions.