WO2024177384A1

WO2024177384A1 - System for controlling network access, and method therefor

Info

Publication number: WO2024177384A1
Application number: PCT/KR2024/002271
Authority: WO
Inventors: 김영랑
Original assignee: 프라이빗테크놀로지 주식회사
Priority date: 2023-02-21
Filing date: 2024-02-21
Publication date: 2024-08-29
Also published as: KR102600442B1

Abstract

According to an embodiment disclosed in the present document, a gateway comprises a communication circuit, a memory, and a processor operatively connected to the communication circuit and the memory, wherein the processor can be configured to: receive, from a node, a data packet for a service request; identify whether there is a channel corresponding to the data packet; forward the data packet to a destination network of the data packet if it is identified that there is a channel; forward the data packet to an external server if it is identified that there is no channel; and, after forwarding the data packet to the external server, receive information about the channel from the external server according to an authentication result for the node.

Description

System for controlling network access and method thereof

Cross-citation with related applications

This invention claims the benefit of priority from Korean Patent Application No. 10-2023-0022775, filed on February 21, 2023, which is incorporated herein by reference in its entirety.

Technical field

Embodiments disclosed in this document relate to a system for controlling network access and a method thereof.

A number of devices can communicate data over a network. For example, a terminal can transmit or receive data to or from a server over the Internet. The network can include a public network such as the Internet, as well as a private network such as an intranet.

Controlling a node's network access using tunneling or authentication information embedded in data packets can prevent unauthorized or insecure nodes from accessing the destination network.

In order to control the network access of a node in the manner described above, a gateway existing at the border of a destination network (target service) must use authentication information included in a tunnel or data packet, which is the minimum access control unit, to check whether the node is authorized, etc. In this case, an access control application (network access control application) that generates authentication information must be installed on the node.

If a node attempts to access a target service without an access control application installed, access to the destination network is blocked, and there is a problem in that the user of the node has no idea why access to the destination network is blocked.

In addition, if the access control application cannot be installed (e.g., a node with an old operating system for which technical support required to install the access control application has ended, a low-power IoT with low absolute hardware specifications, a node with an operating system not supported by the access control application, etc.), there is a problem in that the node cannot access the destination network.

A gateway according to an embodiment disclosed in the present document comprises a communication circuit, a memory, and a processor operatively connected to the communication circuit and the memory, wherein the processor is configured to receive a data packet for a service request from a node, determine whether a channel corresponding to the data packet exists, and if it is determined that the channel exists, forward the data packet to a destination network of the data packet, and if it is determined that the channel does not exist, forward the data packet to an external server, and after forwarding the data packet to the external server, receive information about the channel from the external server according to an authentication result for the node.

In addition, an external server according to an embodiment disclosed in the present document includes a communication circuit, a memory, and a processor operatively connected to the communication circuit and the memory, wherein the processor may be configured to, when a data packet for a service request is obtained, transmit authentication support information to the node with reference to the data packet, obtain a network connection request including a source IP (internet protocol) from the node based on the authentication support information, determine whether the node is connectable to the destination network based on information included in the network connection request, and, if it is determined that connection is possible, transmit information about a channel to a gateway.

In addition, the method of operating the gateway according to the embodiment disclosed in the present document may include the steps of receiving a data packet for a service request from a node, the step of checking whether a data flow and a security session corresponding to the data packet exist, and if it is checked that the data flow and the security session exist, the step of forwarding the data packet to a destination network of the data packet, and if it is checked that the data flow and the security session do not exist, the step of forwarding the data packet to an external server, and then receiving information on the channel from the external server according to the authentication result for the node.

According to embodiments disclosed in this document, a node can access a target service even if a connection control application is not installed on the node.

In addition, according to the embodiments disclosed in this document, a node installing an access control application is granted first access rights, and a node performing an authentication process is granted second access rights, thereby enabling the node to efficiently access a target service.

Additionally, according to the embodiments disclosed in this document, it is possible to prevent unauthorized transmission of data packets to an unauthorized destination network.

Additionally, according to the embodiments disclosed in this document, the security of the destination network can be improved by recovering a tunnel or data flow when a target application installed on a node is terminated or based on a security event received from a linking system.

Additionally, according to the embodiments disclosed in this document, even when data packets received from multiple nodes include the same source IP, network access can be controlled independently for each node based on the channel.

In addition, various effects may be provided that are directly or indirectly identified through this document.

Figure 1 illustrates an architecture within a network environment according to various embodiments.

FIG. 2 is a functional block diagram illustrating a database stored in a control server according to various embodiments.

FIG. 3 illustrates a functional block diagram of a gateway according to various embodiments.

FIGS. 4A and 4B illustrate operations for controlling transmission of data packets according to various embodiments.

Figure 5 is a diagram explaining the operation of a gateway when a node on which an access control application is not installed attempts to access a service server.

Figures 6 to 10 are drawings for explaining operations related to nodes on which an access control application is not installed.

FIG. 11 is a diagram illustrating data packets according to various embodiments related to authentication information required for creating a logical connection.

Figures 12 to 16 are drawings for explaining operations related to a node on which an access control application is installed.

Figure 17 is a diagram explaining the protocol inspection process.

Figure 18 is a flowchart schematically illustrating the process by which a gateway creates a secure session.

Figure 19 is a diagram explaining the process by which a gateway processes a service request.

Figure 20 is a diagram for explaining the structure of service request information with a data flow header inserted.

In connection with the description of the drawings, the same or similar reference numerals may be used for identical or similar components.

Hereinafter, various embodiments of the present invention will be described with reference to the attached drawings. However, this is not intended to limit the present invention to specific embodiments, but should be understood to include various modifications, equivalents, and/or alternatives of the embodiments of the present invention.

In this document, the singular form of a noun corresponding to an item may include one or more of said items, unless the context clearly dictates otherwise. In this document, the phrases "A or B", "at least one of A and B", "at least one of A or B", "A, B or C", "at least one of A, B and C" and "at least one of A, B, or C" each include any one of the items listed together in that phrase, or all possible combinations of them. Terms such as "first", "second", or "first" or "second" may be used merely to distinguish one component from another, and do not limit the components in any other respect (e.g., importance or order). When a component (e.g., a first component) is referred to as being “coupled” or “connected” to another component (e.g., a second component), with or without the terms “functionally” or “communicatively,” it means that the component can be connected to the other component directly (e.g., wired), wirelessly, or through a third component.

Each component (e.g., a module or a program) of the components described in this document may include a single or multiple entities. According to various embodiments, one or more of the components or operations of the components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., a module or a program) may be integrated into a single component. In such a case, the integrated component may perform one or more functions of each of the components of the plurality of components identically or similarly to those performed by the corresponding component of the plurality of components before the integration. According to various embodiments, the operations performed by the module, program or other component may be executed sequentially, in parallel, repeatedly, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

The term "module" or "...part" used in this document may include a unit implemented in hardware, software or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit. A module may be an integrally configured component or a minimum unit of the component or a portion thereof that performs one or more functions. For example, according to one embodiment, a module may be implemented in the form of an application-specific integrated circuit (ASIC).

Various embodiments of the present document may be implemented as software (e.g., a program or an application) including one or more instructions stored in a storage medium (e.g., a memory) that can be read by a machine. For example, a processor of the machine may call at least one instruction among the one or more instructions stored from the storage medium and execute it. This enables the machine to operate to perform at least one function according to the at least one instruction called. The one or more instructions may include code generated by a compiler or code that can be executed by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. Here, 'non-transitory' only means that the storage medium is a tangible device and does not include a signal (e.g., an electromagnetic wave), and this term does not distinguish between cases where data is stored semi-permanently and cases where it is stored temporarily in the storage medium.

The method according to various embodiments disclosed in this document may be provided as included in a computer program product. The computer program product may be traded between a seller and a buyer as a commodity. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., a compact disc read only memory (CD-ROM)), or may be distributed online (e.g., downloaded or uploaded) through an application store or directly between two user devices (e.g., smartphones). In the case of online distribution, at least a part of the computer program product may be temporarily stored or temporarily generated in a machine-readable storage medium, such as a memory of a manufacturer's server, a server of an application store, or an intermediary server.

Referring to FIG. 1, nodes (103_1, 103_2) may be various types of devices capable of performing data communication. For example, nodes (103_1, 103_2) may include portable devices such as smartphones or tablets, computer devices such as desktops or laptops, multimedia devices, medical devices, cameras, wearable devices, virtual reality (VR) devices, or home appliance devices, but are not limited to the aforementioned devices. Nodes (103_1, 103_2) may also be referred to as 'electronic devices' or 'terminals'.

The gateway (101) can be connected to nodes (103_1, 103_2). For example, the gateway (101) can support nodes (103_1, 103_2) to connect to service servers (105_1, 105_2) by providing nodes (103_1, 103_2) with a structure that allows communication only when a data flow authorized by a control server (102) exists. In addition, the gateway (101) can provide nodes (103_1, 103_2) with a structure that allows communication only when a data flow does not exist.

According to an embodiment, the gateway (101) may receive a data packet for connection to a destination network from a node, check whether a channel (e.g., a tunnel or a secure session) corresponding to the data packet exists, and if it is determined that the channel exists, forward the data packet to the destination network to support processing of the node's service request. If it is determined that the channel does not exist, the gateway may forward the data packet to an external server (e.g., an authentication server (104)) to support authentication of the node. In addition, information about the channel may be received from the external server according to the authentication result of the node.

According to an embodiment, the gateway (101), if it is confirmed that a channel exists, checks whether a data flow corresponding to the data packet exists, and if it is confirmed that the data flow exists, the gateway can forward the data packet to a destination network. If it is confirmed that the data flow does not exist, it checks whether the data packet is a data packet of an authenticable protocol, and if it is confirmed that the data packet is a data packet of an authenticable protocol, the gateway can perform a network address translation (NAT) process that converts a destination IP and a destination port of the data packet to an external server IP and an external server port corresponding to an external server (e.g., an authentication server (104)), thereby forwarding the data packet.

According to an embodiment, when an access control application is installed, the gateway (101) receives a tunnel creation request for creating a tunnel from a node (103_1), creates a tunnel with the node (103_1) based on the tunnel creation request, and then communicates with the node through the tunnel.

In addition, the service server (105_1, 105_2) may be various types of devices capable of performing data communication. For another example, the service server (105_1, 105_2) may include a portable device such as a smart phone or a tablet, a computer device such as a desktop or a laptop, a multimedia device, a medical device, a camera, a wearable device, a virtual reality (VR) device, or a home appliance device, but is not limited to the aforementioned devices. The service server (105_1, 105_2) may also be referred to as an 'electronic device' or a 'terminal'.

Nodes (103_1, 103_2) can transmit data packets to service servers (105_1, 105_2) or receive data packets from service servers (105_1, 105_2). Some of the target applications included in nodes (103_1, 103_2) may be trusted and/or secure applications, such as web browsers or business applications, while others may be untrusted or insecure malicious programs. Therefore, the network access control system according to embodiments may block access of unauthorized programs (applications) to service servers (105_1, 105_2) and isolate (e.g., blacklist) such programs.

The control server (102) can ensure reliable data transmission within a network environment by managing data transmission between the gateway (101) and the service servers (105_1, 105_2). For example, the control server (102) can allow network access of an authorized access control application through policy information or blacklist information. The control server (102) can provide authentication information that can perform authentication between the gateway (101) and the service servers (105_1, 105_2). Accordingly, the access control application can prevent an unauthorized node from transmitting data packets to an unauthorized destination.

According to an embodiment, the network access of a node may be blocked by a connection control application, a control server (102), or a gateway (101). According to one embodiment, the control server (102) may transmit and receive control data packets with the gateway (101) in order to perform various operations (e.g., registration, approval, authentication, renewal, termination) associated with the network access of the gateway (101). The flow in which the control data packets are transmitted may be referred to as a 'control flow'. According to an embodiment, the control server (102) may immediately recover a tunnel according to a security event received from a linking system (e.g., gateway), or may immediately recover a tunnel when a target application is terminated, thereby maintaining a secure network state at all times. In addition, the above-described structure may be substantially equally applied to the relationship between the connection control application and the control server (102).

According to an embodiment, the control server (102) can communicate with the authentication server (104). For reference, although FIG. 1 illustrates a case where the control server (102) and the authentication server (104) are separated, the present invention is not limited thereto, and the control server (102) and the authentication server (104) may be configured as a single integrated server (e.g., an external server).

FIG. 2 is a functional block diagram showing a database stored in a control server (102) according to various embodiments. Although FIG. 2 only shows a memory, the control server (102) may further include a communication circuit for performing communication with an external electronic device and a processor for controlling the overall operation of the control server (102).

An administrator can access the control server (102) and set a connection-centric policy to control access between the access control application, gateway (101), and service server, thereby enabling more detailed and safer control of network access than managing sessions at the service level.

The access policy database (211) may include at least some of the information for identification of the node (such as unique node identification information, user information corresponding to the node, information about services that the target application of the node can access, etc.) and authentication (such as a certificate). For example, when a network access request is obtained from a target application controlled by the access control application, the control server (102) may determine whether the node, target application, and/or user identified at the time of the network access request can access the destination (such as a service server or gateway (101)) based on the policy of the access policy database (211). In addition, even when the access control application is not installed, the control server (102) may determine whether the node, target application, and/or user identified at the time of the network access request can access the destination (such as a service server or gateway) based on the policy of the access policy database (211) when a network access request is obtained from the target application.

According to an embodiment, the control server (102) can check whether connection is possible and generate a data flow based on a method for identifying a connection target and identification information (e.g., an identification method based on a MAC address of a node, an identification method based on authentication information transmitted by a node when requesting network connection, an identification method of an application requesting network connection within a router (201) and thus, destination IP and port information included in an IP header, protocol information (e.g., TCP, UDP, etc.), MAC address, application identification information, IP allocated to the node, received network interface identification information, etc.).

The tunnel policy database (212) may include a series of information (e.g., authentication information, encryption algorithm, tunnel endpoint IP, etc.) required to create a tunnel to be connected to a gateway (101) on a connection path according to a connection policy. If a tunnel already connected to another gateway (not shown) on the connection path exists, a series of information (e.g., whether to collect IP information assigned to a node and whether to perform replacement processing) for using it may be included. For example, the control server (102) may provide a tunnel and gateway (101) optimized for the node based on the tunnel policy when a network connection request is made by a node connected to the gateway (101).

The authentication policy database (213) may include a series of information related to whether to authenticate network access based on the identification information of a node when a node connected to the gateway (101) accesses the network according to the access policy (211) and, if authentication is performed, the authentication method. In addition, the authentication policy database (213) may include certificate information (e.g., Mutual-TLS) previously issued to a connection target (e.g., a node) and may include certificate information (e.g., TLS) for inducing a connection target (e.g., a node) to create a secure session in a proxy included in the gateway (101).

The protocol policy database (214) may include protocol identification signature information, protocol version information, protocol header information, and agreement information for identifying protocol information included when transmitting and receiving data packets as protocol information that can communicate with the target service. In addition, the protocol policy database (214) includes information on whether to process a data packet as a normal protocol by examining the data packet to a certain extent (length) to identify the protocol, information on the timing of a network connection attempt or the protocol examination cycle, information on the protocol examination performing entity, and a series of information related to network connection release, control flow release, and isolation in case of non-compliance with the protocol.

The service policy database (215) may include service IP and port information, protocol information (e.g., HTTP, FTP, IoT-specific protocol, etc.) that a connection target (e.g., a node) can access through a proxy (e.g., a proxy included in a gateway (101)) according to the access policy (211). In addition, the service policy database (215) may include whether service request filtering is necessary, a service request filtering processing method, filtering information (e.g., personal information, harmful service request information), and a series of information for blocking unnecessary or dangerous service requests in advance in the proxy. According to an embodiment, the service policy database (215) may include a series of information for setting the number of service requests possible per a certain time unit and adjusting the number of service requests in the proxy accordingly when QoS (Quality of Service) for a service request is required.

The control flow table (216) is an example of a session table for managing the flow of control data packets (e.g., control flows) generated between the connection control application and the control server (102). When successfully connecting to the control server (102), control flow information may be generated by the control server (102). The control flow information may include identification information of the control flow, an IP address identified upon connection and authentication to the control server (102), node identification information, target application identification information, information additionally identified through linkage with the service server, etc. For example, when connection to the service server is requested, the control server (102) may search for control flow information through the control flow identification information, and may determine (decide) whether the node can connect to the service server, whether to generate a data flow for data packet transmission, etc. by mapping the identification information included in the searched control flow information to the connection policy database (211).

According to one embodiment, a control flow may have an expiration time. The access control application must periodically/aperiodically update the expiration time of the control flow, and if the expiration time is not updated for a certain period of time, the control flow (or control flow information) may be removed. In addition, if it is determined that immediate access blocking is necessary based on a security event collected from the target application and/or the gateway (101), or if a connection termination request from the target application is obtained, the control server (102) may remove the control flow. If the control flow is removed, previously generated data flows are also removed, so that access to the service server through the corresponding gateway (101) may be blocked.

The data flow table (217) is a table for managing the flow (e.g., data flow) of detailed data packets transmitted between a node and a gateway (101), and may include data flow information for managing tunnels and/or sessions in a target application of the node, the gateway (101), and a service server.

Since data flow identification information (e.g., ID) for identifying a data flow and node identification information (e.g., MAC address information) can create one or more logical connections with a service server, the data flow table (217) can be managed based on the control flow ID.

According to an embodiment, the data flow table (217) may include at least a portion of the following: an application and a minimum identification unit of the application; information for the gateway (101) to determine whether network connection is possible based on the source IP, destination IP, and service port information of the data packet; a series of information (authentication information, encryption algorithm, Tunnel End Point IP, etc.) required to create a tunnel with the gateway (101) on the connection path; data flow status information regarding whether the data flow is available; and authentication expiration time information required when periodically authenticating the corresponding data flow.

According to an embodiment, the data flow table (217) may include authentication information. For example, the authentication information may include a series of information for checking whether an authorized node has transmitted a data packet, a method for checking authentication information by protocol (e.g., in the case of TCP, TCP SYN packet inspection, in the case of UDP, authentication information inspection by data packet or authentication information inspection at regular intervals (or cycles), inspection method, etc.), information for decrypting authentication information, algorithm information for generating and verifying authentication information, and a series of information included in the algorithm (e.g., information such as Secret Key when generating HMAC OTP, etc.).

According to an embodiment, the data flow table (217) may include certificate information issued in advance to process a request for creating a secure session of an authorized connection target (e.g., a node).

Additionally, the data flow table may contain information about security sessions.

According to an embodiment, the data flow table (217) may include service information. For example, the service information may include service IP and port information that an allowed connection target can access through the proxy, protocol information (e.g., HTTP, FTP, IoT-specific protocol, etc.), whether service request filtering is necessary, a service request filtering processing method, and filtering information (e.g., personal information, harmful service request information). In addition, the service information may include a series of information for blocking unnecessary or dangerous service requests in advance in the proxy, and a series of information for setting a number of service requestable times per period when QoS (Quality of Service) for the service request is required, and adjusting the number of service requests in the proxy accordingly. According to an embodiment, the service information may be generated based on a service policy (318).

According to an embodiment, the data flow table (217) may be identically stored in the node and/or gateway (101) where the access control application is installed.

The tunnel table (218) may include identification information of a tunnel created between a target application and a gateway (101), an IP address of the tunnel, etc. For example, the control server (102) may determine whether a tunnel has been created between a target application and a gateway (101) based on the tunnel table (218). In addition, the tunnel table (218) is a table for managing tunnels connected between the target application and the gateway (101), and may be configured with a tunnel ID for managing and identifying a tunnel if a valid tunnel exists, a control flow ID for controlling between the gateway (101) and the control server (102), and additional information for managing a TEP (tunnel endpoint), a TSP (tunnel start point), a tunnel algorithm and type, an encryption level, etc.

The blacklist database (219) may include a list of targets blocked by the blacklist policy database (220). For example, if the identification information of a target application requesting network access is included in the blacklist database (219), the control server (102) may isolate the target application by denying the network access request.

The blacklist policy database (220) may represent a blacklist registration policy for blocking access of a target (e.g., at least one of a node ID (identifier), an IP address, a MAC (media access control) address, and a user) identified through analysis of the risk level, occurrence cycle, and/or behavior of a security event among security events periodically collected from a node or gateway (101).

FIG. 3 illustrates a functional block diagram of a gateway (101) according to various embodiments. Referring to FIG. 3, the gateway (101) may include a processor (310), a memory (320), and a communication circuit (330).

The processor (310) may control the overall operation of the gateway (101). In various embodiments, the processor (310) may include a single processor core or may include a plurality of processor cores. For example, the processor (310) may include a multi-core such as a dual-core, a quad-core, a hexa-core, etc. According to embodiments, the processor (310) may further include a cache memory located internally or externally. According to embodiments, the processor (310) may be configured with one or more processors. For example, the processor (310) may include at least one of an application processor, a communication processor, or a GPU (graphical processing unit).

All or part of the processor (310) may be electrically or operatively coupled with or connected to other components (e.g., memory (320), communication circuitry (330)) within the control server (102). The processor (310) may receive commands from other components of the gateway (101), interpret the received commands, and perform calculations or process data according to the interpreted commands. The processor (310) may interpret and process messages, data, commands, or signals received from the memory (320), communication circuitry (330). The processor (310) may generate new messages, data, commands, or signals based on the received messages, data, commands, or signals. The processor (310) may provide the processed or generated messages, data, commands, or signals to the memory (320), communication circuitry (330).

The processor (310) can process data or signals generated or produced by the program. For example, the processor (310) can request a command, data, or signal from the memory (320) to execute or control the program. The processor (310) can record (or store) or update a command, data, or signal to the memory (320) to execute or control the program.

The memory (320) can store commands, control command codes, control data, or user data for controlling the gateway (101). For example, the memory (320) can include at least one of an application program, an operating system (OS), middleware, or a device driver.

The memory (320) may include one or more of volatile memory or non-volatile memory. The volatile memory may include dynamic random access memory (DRAM), static RAM (SRAM), synchronous DRAM (SDRAM), phase-change RAM (PRAM), magnetic RAM (MRAM), resistive RAM (RRAM), ferroelectric RAM (FeRAM), etc. The non-volatile memory may include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, etc.

The memory (320) may further include a non-volatile medium such as a hard disk drive (HDD), a solid state disk (SSD), an embedded multi media card (eMMC), or a universal flash storage (UFS).

The communication circuit (330) can support the establishment of a wired or wireless communication connection between the gateway (101) and an external electronic device (e.g., the control server, the service server, etc. of FIG. 1), and the performance of communication through the established connection. According to one embodiment, the communication circuit (330) includes a wireless communication circuit (e.g., a cellular communication circuit, a short-range wireless communication circuit, or a GNSS (global navigation satellite system) communication circuit) or a wired communication circuit (e.g., a LAN (local area network) communication circuit, or a power line communication circuit), and using a corresponding communication circuit among them, communication can be made with an external electronic device through a short-range communication network such as Bluetooth, WiFi direct, or IrDA (infrared data association), or a long-range communication network such as a cellular network, the Internet, or a computer network. The various types of communication circuits (330) described above can be implemented as one chip or can be implemented as separate chips.

For reference, the above has described the structure of the gateway (101), but the same/similar description may be applied to the control server (102), nodes (103_1, 103_2), authentication server (104), and/or service server (105_1, 105_2).

Referring to FIG. 4a, when a network connection request to a service server from a target application (e.g., malware) is detected by the connection control application, and the connection control application or gateway (101) is not connected to the control server (102), the connection control application can block transmission of data packets in a kernel or network driver including an operating system. Through the connection control application, the control server can block connections from malicious nodes in advance in the application layer of the OSI layer.

A node (103) connected to a connection control application must perform authentication by connecting to an external server (e.g., control server (102)), and after performing authentication, when connecting to a service server (105), it queries the control server (102) for connection network information to check whether connection is possible, and if connection is possible, it can transmit a data packet to the service server (105).

The gateway (101) can confirm the data packet received from the target application through an external server (e.g., control server (102)), and if it is a data packet transmitted by an authorized target application, it can allow transmission of a response data packet to the target application. For example, the gateway (101) can confirm whether a tunnel has been created with the target application from which the data packet has been received, and can forward the data packet to the destination only if a tunnel has been created. As a result, unauthorized nodes are basically unable to communicate with each other, and even authorized nodes cannot transmit and receive data packets if a tunnel determined by the control server (102) is not created.

Additionally, referring to FIG. 4b, when a data packet is received from a target application, the gateway (101) can determine whether the node and/or the target application is authenticated, and if the node and/or the target application is not authenticated, can drop the data packet.

Figure 5 is a drawing for explaining the operation of the gateway (101) according to the target application type.

Referring to FIG. 5, when a node (103) on which an access control application is not installed attempts to access a service server (105_1, 105_2), the gateway (101) can check whether the service request is in accordance with a universal protocol. If it is a universal protocol (e.g., IETF RFC standard protocols such as HTTP and FTP) that can be processed by the proxy of the gateway (101), the gateway (101) can perform detailed service access control by data flow. On the other hand, in the case of a native protocol that cannot be processed by the proxy, the gateway (101) can perform access control and data packet inspection by data flow.

Figure 6 schematically illustrates the process of forwarding data packets from a node where an access control application is not installed.

Referring to FIG. 6, in operation 605, a node (103) on which an access control application is not installed may transmit a series of data packets for accessing a service server, and the data packets may pass through a gateway (101) located at the boundary between the service server and the node.

And, in operation 610, the gateway (101) can check whether the data packet is transmitted from a node (103) on which the access control application is not installed by referring to the data flow information obtained from the control server (102). If it is confirmed that the data packet is transmitted from a node (103) on which the access control application is not installed, the gateway (101) can check whether there is a data flow that can access the service server IP and port based on the source IP (e.g., node IP).

In operation 615, if it is confirmed that an accessible data flow exists, since the node (103) has already obtained the minimum authentication and access rights from the control server (102), the gateway (101) can forward the data packet to the service server based on the data flow obtained from the control server (102). At this time, by updating the time or Timestamp information corresponding to the last data packet forwarding time, the control server (102) can be made aware that the node (103) is continuously performing network access through periodic data flow synchronization between the gateway (101) and the control server (102).

On the other hand, if no data flow exists, the node (103) may be considered as an unauthenticated node. In this case, the gateway (101) may check whether the data packet obtained from the node (103) is a data packet of an authenticable protocol (e.g., a data packet using the HTTP protocol) in order to induce the node (103) to install an access control application or to communicate with an authentication server (104) for separate authentication.

In operation 625, if it is a data packet of an authenticable protocol, the data packet is forwarded to an external server (e.g., an authentication server (104)) by performing NAT (Network Address Translation) processing on the destination IP and port included in the IP header of the data packet based on external server IP and external server port information, and in operation 630, the authentication server (104) can receive the data packet. If it is not a data packet of an authenticable protocol (e.g., a data packet using the HTTP protocol), the gateway (101) can drop the data packet, but is not limited thereto, and similarly to the case of a data packet of an authenticable protocol, it can also be forwarded to the authentication server (104) after NAT processing.

Figure 7 schematically illustrates the authentication processing process when a node (103) on which an access control application is not installed transmits a service request.

Referring to FIG. 7, in operation 705, a node (103) on which an access control application is not installed may attempt to access a service by executing an application, and may transmit a service request accordingly in operation 710. In operation 715, the service request of the node (103) may be forwarded to an external server (e.g., an authentication server (104)) after NAT processing through the gateway (101). However, the present invention is not limited thereto, and the node (103) may also directly transmit a service request to the authentication server (104).

And, in operation 720, the authentication server (104) may receive a service request, and in operation 725, return authentication-related service information for installing an access control application or performing separate authentication to the node (103).

And, in operation 730, the node (103) receives the service connection result, and may attempt to connect to the network by installing a connection control application according to the received service connection result (e.g., authentication-related service information) or perform network connection through an authentication procedure. This will be described with reference to FIG. 8.

Figure 8 schematically illustrates authentication-related service information output through the display of a node.

A node (user) can perform an authentication procedure by (i) installing a connection control application (network connection control application) based on the authentication-related service information illustrated in Fig. 8, or (ii) using a separate authentication method (user ID-based authentication, QR authentication, Multi Factor Authentication, etc.) provided by an authentication server (104). When authentication for a node is completed, the control server (102) generates data flow information including information on a service server to which the node can connect and transmits it to the gateway (101), after which the node can connect to the service server.

Figure 9 schematically illustrates a process in which a node (103) performs an authentication procedure according to a separate authentication method provided by an external server (e.g., an authentication server (104)).

Referring to FIG. 9, when a node (103) transmits an authentication request to an authentication server (104), it may be transmitted to a gateway (101) as in operation 905, and then forwarded to the authentication server (104) after NAT processing through the gateway (101) in operation 910, but is not limited thereto, and the node (103) may also directly transmit an authentication request to the authentication server (104).

In operation 915, when an authentication request is received, processing for the authentication request may be performed by an authentication server (104) or a control server (102) including an authentication server function, and in operation 920, the authentication server (104) may perform processing for the authentication request by processing an authentication request received from a node (103) or an authentication request by another authentication system (e.g., Multi Factor Authentication, etc.) connected to the authentication server (104).

The authentication server (104) can check the information related to the authentication request transmitted by the node (103), and if authentication fails, return authentication failure information to the node (103).

If authentication is successful, in operation 925, the authentication server (104) can request authentication to the control server (102) based on node identification information (operating system information of the node that has been authenticated, terminal type information, etc.), source IP information, user identification information, etc. identified during the authentication process.

In addition, when an authentication request is made through authentication server redirection from a gateway (101), the authentication server can request authentication to the control server (102) by including data flow identification information and security session identification information included in the authentication request information.

The control server (102) can generate a control flow based on authentication request information (node identification information (operating system information of the node that has completed authentication, terminal type information, etc.), source IP information, user identification information, etc.) received from the authentication server (104) when the node performs initial authentication, and add the control flow to the control flow table.

In addition, in operation 930, the control server (102) checks whether there is a service server that the node (103) can connect to by looking up the connection policy database, and if there is a service server that can connect, the source IP, destination IP, service port information, and information for checking the protocol of the data packet transmitted and received between the service servers so that the node (103) can connect to the service server, including protocol identification signature and version information, header information, and protocol information included when transmitting and receiving the data packet, and information on whether to process the data packet to a certain extent (length) to identify the protocol and whether to process it as a normal protocol, information on whether to check the protocol at the time of a network connection attempt or periodically, and status information on whether the check is completed or whether more checks are needed, and service IP and port information that can be accessed through the proxy included in the gateway (101), protocol information (e.g., HTTP, FTP, IoT-specific protocol, etc.), and whether service request filtering is necessary, service request filtering processing method, filtering information (e.g., personal information, harmful services, etc.) A series of data flow information including a series of information for blocking unnecessary or dangerous service requests in advance from the proxy, a series of information for setting the number of possible service requests per certain time unit when QoS (Quality of Service) for the service request is required and for adjusting the number of service requests from the proxy accordingly, certificate information for verifying whether the access target is a permitted target when creating a security session, and authentication information for identifying and checking so that the data flow and the security session can be matched when the corresponding node creates a security session and performs a service request, can be generated, and in operation 935, the data flow information can be transmitted to the gateway (101), and in operation 940, result information can be returned to the authentication server (104).

Here, when the node performs a service request by creating a security session, the control server (102) can return to the authentication server authentication information including authentication information for identification and verification so that the data flow can match the security session.

Meanwhile, the control server (102) can search for data flows using the received data flow identification information when the node performs authentication by authentication service redirection from the gateway (101) rather than initial authentication.

If no data flow exists, the control server (102) may return authentication failure information.

If a data flow exists, the control server (102) can check whether the authentication request information (node identification information (operating system information of the node that has completed authentication, terminal type information), source IP information, and user identification information) received from the authentication server matches the identified data flow information and the control flow information included in the data flow information.

If there is a mismatch, the control server (102) may return authentication failure information.

If there is a match, the control server (102) updates the security session identification information and whether the security session is matched (completed) to the identified data flow so that a node accessing the corresponding security session can identify the data flow based on the security session identification information, transmit the corresponding data flow information to the gateway (101), and return the authentication request result information to the authentication server.

And, in operation 945, when the authentication server (104) returns the authentication request processing result to the node (103), the node (103) can access the service server with the second access right (e.g., minimum access right) without installing the access control application.

The case where a node that has been authenticated as above requests deauthentication will be explained with reference to Fig. 10.

Referring to FIG. 10, a node (103) can transmit a deauthentication request to an external server (e.g., an authentication server (104)) through an authentication deauthentication request function. At this time, after transmitting a deauthentication request to a gateway as in operation 1005, a related data packet can be forwarded to the authentication server after NAT processing at the gateway (101) as in operation 1010. However, the present invention is not limited thereto, and the node (103) can also transmit a deauthentication request to the authentication server (104).

In operation 1015, the authentication server (104) receives a deauthentication request, and the deauthentication request processing can be performed by the authentication server (104) or the control server (102) including the authentication server function, and in operation 1020, the authentication server (104) can process the deauthentication request by processing the deauthentication request received from the node (103) or the deauthentication request of another authentication system (e.g., Multi Factor Authentication, etc.) connected to the authentication server (104).

The authentication server (104) can check information related to the deauthentication request transmitted by the node (103), and if the deauthentication request fails, return deauthentication failure information to the node (103).

In operation 1025, if the information for deauthentication is valid, the authentication server (104) may request the control server (102) to deauthenticate the node (103) based on the identified node identification information (operating system information of the authenticated node, terminal type information, etc.), source IP information, user identification information, etc.

In operation 1030, the control server (102) removes the control flow according to the authentication de-authentication request information (node identification information (operating system information of the node that has been authenticated, terminal type information, etc.), source IP information, user identification information) received from the authentication server (104), and can remove a series of data flow information dependent on the control flow.

In operation 1035, the control server (102) can propagate the removed data flow information to the gateway (101), and in operation 1040, the result of processing the deauthentication request can be returned to the authentication server (104).

And, in operation 1045, the authentication server (104) returns the result of the deauthentication request processing to the node (103), and if the deauthentication is completed, the node (103) may be in a state where it can access the service server only after installing an access control application or performing a separate authentication process.

FIG. 11 illustrates data packets according to various embodiments related to authentication information required to create a logical connection.

Referring to FIG. 11, a UDP data packet (1110) including node (terminal) header information may include an IP header, a node header (Device Header), and a payload. For example, the node header (1130) may include node identification information and node authentication information.

Additionally, a TCP data packet (1120) including node header information may include an IP header, a TCP header, a node header, and a payload. For example, the node header (1130) may include node identification information and node authentication information.

According to an embodiment, node authentication information may be information for commonly authenticating all network connections transmitted from a node (103) or for authenticating network connection units (destination IP and port).

The node (103) may generate a node header and include it in a data packet based on at least one of a method of inserting node identification information and authentication information previously provided from the control server (102) (e.g., in the case of TCP, inserting a TCP SYN packet, in the case of UDP, inserting authentication information for each data packet or inserting authentication information at regular intervals (or cycles), insertion method and timing, etc.), information for encrypting authentication information, information on an algorithm for generating authentication information, and a series of information included in the algorithm (e.g., information such as a Secret Key when generating HMAC OTP). The node header included in the data packet may be checked to determine whether it is a normally transmitted data packet by performing authentication by the gateway (101) or the control server (102).

Figure 12 schematically illustrates a connection step of a node (103) on which a connection control application is installed to an external server (e.g., a control server (102)).

Referring to FIG. 12, in operation 1205, a connection control application installed on a node (103) may request a connection to a control server (102) to create a control flow (control data packet flow and a series of sessions).

In operation 1210, the control server (102) verifies the connection request, and based on a policy database (e.g., a connection policy database, a tunnel policy database, a blacklist database, etc.), the access control application can refer to the information requested for connection (type of node, location information, environment and network including the node, access control application information, user or device authentication information for identifying whether the node is an authorized node, etc.) to verify whether the node (103) is in a connectable state, and can check whether node and network identification information (node ID, IP, MAC address, etc.) is included in a blacklist.

If connection to node (103) is impossible or included in a blacklist, the control server (102) transmits connection impossibility information to node (103), and node (103) can stop and terminate execution of the connection control application or output related error information.

On the other hand, in operation 1215, if it is determined to be a connectable node, the control server (102) can generate a control flow, generate a control flow ID in the form of a random number, and add node and network identification information (node ID, IP, MAC address, etc.) to the control flow table.

In operation 1220, the control server (102) can refer to the access policy database and tunnel policy database that match the identified information (node, source network information, etc.) to check whether there is destination network information that the currently connected node (103) can basically connect to, and generate a whitelist of applications that can connect.

The control server (102) can return a control flow ID and application whitelist information for identifying the control flow.

In addition, the control server (102) lists the types of tunnels and gateways (101) that can be connected to the node (103) by referring to the type of the node (103), location information, environment, and information such as the network in which the node (103) is included, the IP of the node (103), and can identify the optimal tunnel and optimal gateway by checking the status (throughput, failure status) of the listed gateways.

In operation 1225, if there is a tunnel and gateway accessible to the node (103), the control server (102) can transmit a series of information, such as a gateway and tunnel authentication for creating a tunnel, to the node (103).

In operation 1230, when a new tunnel needs to be created, the node (103) requests tunnel creation to the corresponding gateway (101) based on a series of information required for tunnel creation, such as a gateway for tunnel creation and tunnel authentication, received from the control server (102), thereby creating a tunnel.

When tunnel creation is completed, the control server (102) can obtain tunnel creation completion information and/or dedicated IP information set according to tunnel creation, register the tunnel dedicated IP and the corresponding tunnel creation information in the tunnel table, and update a series of information transmitted by the node (103) in the control flow.

In operation 1235, if a new tunnel is not created and a connection is made through a tunnel previously connected between a gateway (101) existing in a network to which the node (103) belongs and a gateway (101) existing at the destination network boundary, or if a connection is made between the node (103) and the destination network boundary through another tunnel technology, the control server (102) may not transmit separate tunnel creation information to the node (103). If tunnel creation is not required, an application whitelist check may be performed.

In operation 1240, the control server (102) checks the gateway where the node is located by referring to the access policy database and the service policy database in order to allow access of a node connected to the network according to the application installation list transmitted by the node (103), and allows the node to allow network access without a network access request procedure, and includes protocol identification signatures and version information, header information, and protocol information included when transmitting and receiving data packets as information for examining the protocol of the data packets transmitted and received by the application, and information on whether to examine the data packets to a certain extent (length) to identify the protocol and process them as a normal protocol, whether the network access control application will perform the protocol inspection or whether to transmit the data packet information to the controller, information on whether to examine the protocol at the time of a network access attempt or periodically, and status information on whether the inspection has been completed or whether more inspection is needed, and service IP and port information that can be accessed through a proxy included in the gateway, and protocol information (e.g., HTTP, FTP, IoT). The method of claim 12, wherein the data flow information includes information on whether filtering of a service request is required (e.g., a dedicated protocol, etc.), a method for processing service request filtering, filtering information (e.g., personal information, information on harmful service requests), a series of information for blocking unnecessary or dangerous service requests in advance at the proxy, a series of information for setting the number of possible service requests per unit of time and adjusting the number of service requests at the proxy accordingly when QoS (Quality of Service) for the service request is required, certificate information for verifying whether the access target is an allowed target when creating a security session, etc., and in operations 1245 and 1250, the information is transmitted to the node (103) and the gateway, and in operation 1255, the gateway (101) can receive the data flow information.

And, when the node (103) and/or gateway (101) receives updated data flow information from the control server (102), it can update the data flow information by referring to it.

Figure 13 schematically illustrates the user authentication step of a node (103) on which an access control application is installed.

Referring to FIG. 13, in operation 1305, the access control application of the node (103) may request user authentication by transmitting authentication information using a user ID and password or an enhanced authentication method after creating a control flow with an external server (e.g., control server (102)).

In operation 1310, the control server (102) receives a user authentication request, and checks whether the user of the corresponding node (103) is a user who can access based on the information (user ID and password, reinforced authentication information, etc.) requested for authentication by the access control application, and whether the user is included in a blacklist, thereby checking whether the user is blocked, and if access is not possible or included in a blacklist, information on inaccessibility can be transmitted to the node (103).

In operation 1315, if it is confirmed that the user is a connectable user, the control server (102) can search for a corresponding control flow in the control flow table by referencing the control flow ID, add user identification information (user ID) to the identification information of the control flow, and return an authentication completion status and access policy information of the authenticated user to the node (103) as a result of user authentication.

In operation 1320, the control server (102) can refer to the access policy database and tunnel policy database that match the identified information (node, source network information, etc.) to check whether there is destination network information to which the currently connected node (103) can connect, and generate a whitelist of applications that can connect.

If connection is possible, the node (103) can list the types of tunnels and gateways that the node (103) can connect to through the type, location information, environment, network that the node is included in, etc. of the node (103) included in the control flow to connect to the destination network, the IP of the node identified through the control server (102), and the IP of the node identified in the node, etc., and the status (throughput, failure status) of the listed gateways can be checked to identify the optimal tunnel and the optimal gateway.

In operation 1325, if there is a tunnel and gateway accessible to the node (103), the control server (102) can transmit a series of information, such as a gateway and tunnel authentication for creating a tunnel, to the node (103).

In the case where a tunnel is not created between a node (103) and a gateway (101), but rather a connection is made through a tunnel previously connected between a gateway (101) existing in the network to which the node (103) belongs and a gateway (101) existing at the destination network boundary, or a connection is made between the node (103) and the destination network boundary through another tunnel technology, separate tunnel creation information may not be transmitted to the node (103).

In operation 1330, the node (103) processes the result value of the user authentication request processing received from the control server (102), and if tunnel creation is required, a tunnel can be created by requesting tunnel creation to the gateway (101) based on a series of information required for tunnel creation, such as the gateway (101) for tunnel creation and tunnel authentication received from the control server (102).

When tunnel creation is completed, the node (103) can transmit tunnel creation completion information and IP information, if there is a dedicated IP set according to tunnel creation, to the control server (102). In operation 1335, when an application whitelist is received from the control server (102), the result of checking whether the corresponding application is installed in the node (103) can be transmitted to the control server (102).

In operation 1340, if tunnel creation is completed according to the result of tunnel creation processing, the control server (102) can register the tunnel-only IP assigned to the node (103) and the corresponding tunnel creation information in the tunnel table and update a series of information transmitted by the node (103) to the identified control flow. In addition, in order to allow access of a node connected to the network according to the application installation list transmitted by the node (103), the gateway where the node is located is verified in the access and service policy, and the information for checking the protocol of the data packet transmitted and received by the application, such as the source IP, destination IP, service port information, and protocol information included when transmitting and receiving the data packet so that the node can allow network access without a network access request procedure, the protocol identification signature and version information, header information, and protocol information, etc. for identifying the protocol included when transmitting and receiving the data packet, and information on whether to inspect the data packet to a certain extent (length) as necessary to identify the protocol and process it as a normal protocol, whether the protocol inspection will be performed by the access control application or performed by transmitting the data packet information to the controller, information on whether to inspect the protocol at the time of a network access attempt or periodically, and status information on whether the inspection has been completed or whether more inspection is needed, and the service IP and port information that can be accessed through the proxy included in the gateway, protocol information (e.g., HTTP, FTP, IoT-specific protocol, etc.), and whether service request filtering is necessary, service request filtering processing method, and filtering. The data flow information may be generated to include information (e.g., personal information, harmful service request information), a series of information for blocking unnecessary or dangerous service requests in advance from the proxy, a series of information for setting the number of possible service requests per certain time unit and adjusting the number of service requests from the proxy accordingly when QoS (Quality of Service) for the service request is required, and certificate information for verifying whether the access target is an allowed target when creating a security session. In operations 1345 and 1350, the control server (102) transmits the corresponding information to the node (103) and the gateway (101), and in operation 1355, the gateway (101) may receive the data flow information.

If tunnel creation is deemed unnecessary by the control server (102) or tunnel creation is completed, the control server (102) can obtain tunnel creation completion information and/or dedicated IP information set according to tunnel creation, register the tunnel dedicated IP allocated to the node (103) and the corresponding tunnel creation information in the tunnel table, and update a series of information transmitted by the node (103) to the identified control flow.

And, when updated data flow information is received from the control server (102), the node (103) can refer to it and update the data flow information stored in the node (103).

Figure 14 schematically illustrates the network connection processing steps of a node (103) on which a connection control application is installed.

Referring to FIG. 14, at operation 1405, the access control application of the node (103) can detect the network access of the target application. At operation 1410, it can be checked whether data flow information exists based on the target application identification information, destination IP, and port information to communicate with the destination network (1410). If a valid data flow exists, the access control application can transmit a data packet to the gateway. If the data flow exists but is invalid (e.g., in a state where transmission is not possible or network access has been rejected by the control server (102) in the past), the data packet can be dropped.

In operation 1415, if a data flow renewal is required due to reasons such as a data flow not existing or an authentication time expiry, a network connection request may be sent.

In operation 1420, the control server (102) can refer to a connection policy database that matches the information (node, application, source network information, etc.) identified in the control flow to check whether the requested connection identification information (destination IP and service port information, etc.) is included and whether connection to a service server mapped to the corresponding identification information is possible.

If connection to the mapped service server is not possible, the control server (102) may transmit a connection failure result to the node (103), which may cause data packets to be dropped.

If connection to the mapped service server is possible, the control server (102) can check whether a tunnel has been created in the tunnel table to connect to the network.

In operation 1425, if a tunnel is not created, the control server (102) refers to at least a part of the tunnel policy database and the protocol policy database to check whether a tunnel must be created in order to access the corresponding service, and if it is confirmed that a tunnel must be created, the control server (102) can transmit a connection failure result to the node (103).

If it is determined that a tunnel has already been created or that tunnel creation is unnecessary, the control server (102) can check whether there is a valid data flow corresponding to the information (destination IP and service port information, etc.) requested for connection by the node (103) in the data flow table.

If a valid data flow exists, the corresponding information (network connection request result value) can be transmitted to the node (103) and/or gateway (101).

In operation 1430, if there is no valid data flow, the control server (102) includes protocol information including a source IP, a destination IP, service port information, protocol information included when transmitting and receiving data packets as information for examining the protocol of the data packets transmitted and received by the corresponding application, a protocol identification signature and version information, header information, and protocol information, and information on whether to examine the data packets to a certain extent (length) to identify the protocol and process them as a normal protocol, whether the protocol examination will be performed by the network access control application or performed by transmitting data packet information to the controller, information on whether to examine the protocol at the time of a network access attempt or periodically, and status information on whether the examination is completed or further examination is required, and service IP and port information that can be accessed through a proxy included in the gateway, protocol information (e.g., HTTP, FTP, IoT-only protocol, etc.), and whether service request filtering is necessary, a service request filtering processing method, and filtering information (e.g., personal information, harmful service request information), and includes information on blocking unnecessary or dangerous service requests in advance from the proxy. When a QoS (Quality of Service) for a series of information and a service request is required, a data flow information including a series of information for setting the number of possible service requests per a certain time unit and adjusting the number of service requests from a proxy accordingly, certificate information for verifying whether the connection target is an allowed target when creating a security session, etc. is generated, and in operation 1440, the corresponding information is transmitted to a gateway (101), and in operation 1435, the result of processing a network connection request can be transmitted to a node (103).

And, the connection control application can process the connection request result value received from the control server (102).

If data flow information is received from the control server (102), the access control application can update the data flow information stored in the node (103), and if the network access request is successful, the data packet can be transmitted to the gateway (101).

Figure 15 schematically illustrates a tunneling-based data packet forwarding process of a node (103) on which an access control application is installed.

Referring to FIG. 15, in operation 1505, if tunnel creation is required, the node (103) may request tunnel creation to the gateway (101) based on a series of information required for tunnel creation, such as tunnel authentication and gateway (101) for tunnel creation, received from an external server (e.g., control server (102)).

In operation 1505, the gateway (101) can perform a data flow inspection, and can check whether the data packet received from the node (103) is a data packet for tunnel creation processing, and whether the port on which the tunneling-related module existing in the gateway (101) is receiving is confirmed, and if it is confirmed that the port on which the tunneling-related module is receiving is confirmed, the data packet is forwarded and, in operation 1515, the tunnel creation is processed by referring to the data packet related to the tunnel creation request, and, in operation 1520, the tunnel creation result can be transmitted to the node (103).

If the data packet is a port that the tunneling-related module is not receiving and attempts to connect to a source IP, destination IP, or port that is not permitted, the gateway (101) can drop the data packet.

And, in operation 1525, the node (103) receives the tunnel creation result, and if tunnel creation is completed, in operation 1530, it can perform connection (data packet transmission) to the service server based on tunneling.

In operation 1535, the gateway (101) can perform a data flow inspection and, based on the tunneling IP assigned to the node (103), can determine whether the node (103) can connect to the service server by referring to the accessible data flow information received from the control server (102). In operation 1540, if the connection is possible, the data packet is forwarded to the service server, and in operation 1545, the service server can receive the data packet.

If the data packet attempts to connect to an unauthorized source IP, destination IP, or port, the gateway (101) can drop the data packet.

Figure 16 schematically illustrates a data packet forwarding process based on data packet authentication of a node (103) on which an access control application is installed.

Referring to FIG. 16, in operation 1605, when a logical connection (e.g., TCP authentication-based TCP Session creation, UDP authentication-based UDP related Session or flow creation, etc.) is required between a node (103) and a service server, the node (103) may request the service server to create a logical connection based on a series of information required for creating authentication information for logical connection authentication received from the control server (102).

In operation 1610, the gateway (101) can perform a data flow inspection, and, in order to verify a series of data packets for a logical connection received from a node (103), can check whether authentication information for the logical connection is valid based on authentication information received from the control server (102), and can check whether connection to the service server is possible with the authentication information.

In operation 1615, if the authentication information is valid, the gateway (101) forwards the data packet to the service server, and if the authentication information is invalid or the network connection request is from a service server that cannot be connected with the authentication information, the gateway (101) can drop the data packet.

And, in operation 1620, a logical connection is created, and in operation 1625, a result of creating the logical connection is transmitted to the node (103), and when the node (103) receives the result of creating the logical connection in operation 1630, in operation 1635, the node (103) can transmit a data packet to the service server based on the logical connection.

In operation 1640, the gateway (101) examines data flow information received from the control server (102) based on logical connection information assigned to the node (103), and in operation 1645, if the node (103) can connect to the service server, forwards the data packet to the service server, and in operation 1650, the service server can receive the data packet.

If the data packet attempts to access a service based on an unauthorized logical connection, the gateway (101) may drop the data packet.

Through this process, the gateway (101) can perform network access and data packet transmission control only for nodes (103) to which authentication-based logical connections have been granted.

Figure 17 is a flow chart schematically illustrating the process by which a gateway (101) examines a protocol.

Referring to FIG. 17, in operation 1705, the gateway (101) may receive a data packet transmission event from the network kernel of the operating system, and in operation 1710, may perform a data flow inspection.

For example, the gateway (101) can check whether data flow information exists by using one or more of the destination IP and port information, protocol information (e.g., TCP, UDP, etc.), and source IP or logical connection information included in the received IP header.

If no valid data flow exists, the gateway (101) may drop the data packet.

In operation 1715, if a valid data flow exists, the gateway (101) can determine whether a protocol inspection is necessary based on a protocol inspection status (whether a protocol inspection is necessary, whether a protocol inspection is completed by inspection of a previous data packet transmission, whether a protocol inspection is necessary periodically, etc.) included in the protocol information included in the data flow.

If protocol inspection is not required, the gateway (101) can forward the data packet to the service server.

If protocol inspection is required, protocol inspection can be performed by a gateway (101) or an external server (e.g., a control server (102)).

In operation 1720, when the gateway (101) directly performs protocol inspection, the gateway (101) checks whether the data packet contains or complies with a signature and version information, header information, and protocol information for identifying whether the data packet is an allowed protocol based on information for inspecting the protocol of the data packet included in the data flow, and can inspect the data packet up to the inspection range (length) included in the protocol information as necessary.

If the protocol check is successful, the protocol check status changes to completed, and data packets can be forwarded.

In operation 1725, if the protocol inspection fails, the gateway can drop the corresponding data packet, remove the data flow, and in operation 1730, transmit the protocol inspection result including the control flow identification information to the control server (102). In operation 1735, the control server (102) can receive the protocol inspection result and determine the level of risk by referring to the corresponding protocol policy database and blacklist policy database.

In operation 1740, if the risk is low, the control server (102) can remove the corresponding data flow and propagate the updated data flow to the gateway (101). On the other hand, if the risk is high, the control server (102) can remove the control flow and tunnel so that the corresponding node (103) can no longer maintain network connection, and propagate the updated control flow, data flow, and tunnel information to the gateway (101). If the risk is severe, the control server (102) can add the identified node (103) to a blacklist so that it can no longer access after performing the above-described control flow removal procedure.

And the gateway (101) can process the result value upon receiving the protocol inspection result transmission result from the control server (102).

Meanwhile, although not shown in Fig. 17, the same/similar description may be applied even when protocol inspection is performed by the control server (102).

For example, the gateway (101) may collect all data packets or, if necessary, up to the inspection range (length) included in the protocol information to identify whether the data packet is an allowed protocol based on information for inspecting the protocol of the data packet included in the data flow.

And, the gateway (101) can request a protocol inspection to the control server (102) including the collected data packets and data flow identification information.

The control server (102) can check whether the data packet contains or complies with the signature and version information, header information, and protocol information based on the identified data flow information and the protocol information included in the data flow.

If the inspection is successful, the control server (102) can change the inspection status of the received data packet of the data flow to complete and return the updated data flow information to the gateway (101).

On the other hand, if the inspection fails, the control server (102) can determine whether there is a risk based on the protocol policy and blacklist policy according to the protocol inspection result. If the risk is low, the control server (102) can remove the data flow and transmit the updated data flow information to the gateway (101). On the other hand, if the risk is high, the control server (102) can remove the control flow and tunnel so that the corresponding node (103) can no longer maintain network connection, and transmit the updated control flow, data flow, and tunnel information to the gateway (101). If the risk is severe, the control server (102) can add the corresponding node (103) to the blacklist so that it can no longer access after performing the above-mentioned control flow removal procedure.

Figure 18 is a flow chart schematically illustrating the process by which a gateway (101) creates a security session.

Referring to FIG. 18, at operation 1905, the gateway (101) receives a request to create a secure session (e.g., a secure session such as TLS, QUIC, etc. for protecting a protocol such as HTTP) from a node, and at operation 1910, the gateway (101) can examine a data flow to identify a source IP included in an IP header and determine whether a valid data flow corresponding to a proxy port included in the gateway (101) exists to create a secure session.

At operation 1925, if no valid data flow exists, the gateway (101) may reject the secure session creation request.

In operation 1915, if a valid data flow exists, the gateway (101) can create a secure session between the node and the proxy through the proxy and return the result to the node.

In operation 1920, if the secure session creation is completed, the gateway (101) can check the certificate information used to create the secure session and update the data flow.

If the certificate is a specific certificate for identifying a specific node, the gateway (101) updates the security session identification information and whether the security session is matched (completed) for the data flow identified based on the specific certificate identification information, and enables the node connecting to the security session thereafter to identify the data flow based on the security session identification information.

If the certificate is a general certificate that can be used by all nodes, the security session identification information and whether the security session is matched (incomplete) are updated in the security session information of the data flow identified by the source IP, and the node or user using the security session identification information can be matched through the authentication procedure thereafter.

Figure 19 is a flow chart schematically illustrating the process by which a gateway (101) processes a service request.

Referring to FIG. 19, when a secure session-based service request event is received at operation 1805, at operation 1810, a proxy included in the gateway (101) can perform a data flow inspection to check whether data flow information exists using the destination IP and port information and protocol information (e.g., TCP, UDP, etc.) included in the received IP header.

In operation 1840, if a data flow exists but is invalid (e.g., data packet transmission unavailable state) or if a data flow does not exist, the gateway (101) may reject the service request.

In operation 1840, if there is a data flow requiring authentication information verification, the gateway (101) checks whether authentication information exists in the received service request header or parameter.

For reference, authentication information may be information used by the gateway (101) to match the authentication information with a security session by returning the authentication information in the form of a header or parameter after node and user authentication is completed through the authentication server, and then the node includes the authentication information when requesting a security session-based service and transmits it.

In operation 1850, if there is no authentication information, the gateway (101) redirects to the authentication server including data flow identification information and security session identification information, and when node and user authentication is completed, it checks whether the data flow and the security session can be matched and updates the data flow.

If authentication information exists, the gateway (101) can check whether the authentication information is valid based on the authentication information of the data flow.

In operation 1845, if the authentication information is valid, the gateway (101) updates the security session identification information and whether the security session is matched (complete) in the security session information of the data flow, and then examines the data flow based on the security session identification information. On the other hand, if the authentication information is invalid, the gateway (101) can reject the service request.

And, if a valid data flow exists, the gateway (101) can check whether service information allowing the service request exists in the data flow information based on the destination IP or domain identification information and port information included in the received service request header.

If there is no service information that allows a service request, the gateway (101) may reject the service request.

If there is service information that allows a service request, the gateway (101) can check whether QoS is required through the service request QoS information included in the service information.

In operation 1815, if service request QoS is required, the gateway (101) can perform service request QoS processing. The gateway (101) can check the number of service requests per a certain time period included in the service request QoS information, and if it is confirmed that the number of service requests exceeds the allowable number of service requests per a certain time period, the gateway (101) can delay the service request for a certain time period and then process it, or reject the service request to induce a service re-request, according to the service request QoS method.

In operation 1820, if service request QoS is not required, the gateway (101) can filter service request information and, through service filtering information included in the service information, determine whether the protocol of the service request (e.g., HTTP, FTP, or a dedicated protocol for IoT devices, etc.) is normal.

If the protocol of the service request is not normal, the gateway (101) may reject the service request.

Meanwhile, when filtering service request information, the gateway (101) can replace the request information through replacement information or rules included in the service filtering information and transmit the service request if replacement of the information is required.

On the other hand, if filtering for the service request is not required and/or substitution for the service request information is not required, the gateway (101) can transmit the service request.

If a service request requires blocking, the gateway (101) may reject transmission of the service request.

The gateway (101) can generate authentication information using an authentication information generation algorithm and additional information included in the authentication information of the data flow. Thereafter, the authentication information can be encrypted using an encryption algorithm and an encryption key included in the authentication information. Then, in operation 1825, the gateway (101) can insert a data flow header that combines the encrypted authentication information and the data flow identification information into the service request information according to the protocol specification of the service application, and in operation 1830, can transmit the service request.

In operation 1835, after processing a service request transmission or a service request rejection, the gateway (101) can reflect the number of times the service request is processed in the QoS statistical information included in the service information in the data flow.

Meanwhile, the gateway (101) can update the data flow through the following process.

For example, the gateway (101) updates the processing time or Timestamp information when forwarding a data packet or service request from a node (103) based on the data flow received from the control server (102), and may periodically request the control server (102) to update the data flow information.

Additionally, the control server (102) can check whether data flow information exists by referring to the received data flow identification information.

If a data flow does not exist, it means that the node (103) has terminated the network connection, so the control server (102) can return invalid data flow information to the gateway (101) so that access with the data flow information through the gateway (101) is no longer possible.

In addition, the control server (102) checks the last connection processing time of the data flow, and if the time available after the first authentication has expired according to the authentication policy and re-authentication is required, or if the connection of the node (103) has been released, the data flow and control flow of the corresponding node (103) can be removed, and since the corresponding node (103) has terminated the network connection, invalid data flow information can be returned to the gateway (101) so that the corresponding gateway (101) can no longer be connected.

Additionally, the gateway (101) can delete invalid data flows based on the received data flow information.

Referring to Fig. 20, the structure of service request information with a data flow header inserted by the gateway (101) can be confirmed.

A proxy included in a gateway (101) can insert data flow header information that can identify a service request target from a service server based on authentication information included in a data flow into a portion suitable for the protocol of the service application (e.g., a header area in the case of HTTP) and retransmit the data flow header information to the service server, and return a response value of the service server for the service request to the node (103).

A data flow header can be inserted to verify whether a data packet received from a control server (102) is an authenticated data packet in a data packet flow between a node (103), a gateway (101), and a service server.

These data flow headers may include data flow identification information and encrypted authentication information.

Since data packets in an IP network have no identifiable information other than 5 Tuples information (protocol, source IP, port, destination IP, port), the service server cannot know whether the node (103) assigned the IP is actually authenticated and whether the application, which is the actual communication subject, was transmitted by an authorized target.

Accordingly, when processing a service request, the service server queries the control server (102) using the data flow identification information included in the data flow header to check whether an authenticated target has connected, and receives additional information about the authenticated target stored by the control server (102) to perform authentication processing.

Additionally, encrypted authentication information, in addition to the data flow identification information included in the data flow header, can be used to verify whether an authenticated gateway (101) forwarded the service request.

At this time, only an authenticated target (i.e., when a data flow exists) can decrypt the encrypted authentication information through the authentication information encryption/decryption key included in the authentication information of the data flow received from the control server (102).

Decrypted authentication information may include information in the form of a One-Time Password (OTP) and Random Generation that changes at each authentication time, rather than being a fixed value at each data packet authentication time, such as data flow identification information.

In addition, the gateway (101) can generate OTP information that changes at each service request forwarding time based on information for OTP generation and verification included in the authentication information of the data flow, and forward service request information including data flow header information in which data flow identification information is inserted by encrypting the corresponding value.

According to an embodiment of the present invention, a service access of a node using a general protocol such as HTTP is identified, and a secure session is connected through a proxy, and after the secure session is connected, a data flow header is inserted into service information through user authentication of the node and returned to the node, and during the return process to the node or the service re-request process of the node, a gateway performs a procedure of mapping security session identification information to the corresponding data flow based on data flow identification information included in the service information, thereby inspecting the data flow of a node that connects to the service thereafter based on node authentication information and/or security session, and accordingly, even when data packets received from a plurality of nodes include the same source IP, network access can be controlled independently for each node.

The above description is merely an illustrative description of the technical idea disclosed in this document, and those skilled in the art in the art to which the embodiments disclosed in this document pertain may make various modifications and variations without departing from the essential characteristics of the embodiments disclosed in this document.

Therefore, the embodiments disclosed in this document are not intended to limit the technical ideas disclosed in this document but to explain them, and the scope of the technical ideas disclosed in this document is not limited by these embodiments. The protection scope of the technical ideas disclosed in this document should be interpreted by the claims below, and all technical ideas within the equivalent scope should be interpreted as being included in the scope of the rights of this document.

Claims

At the gateway,

communication circuit;

memory; and

A processor operatively connected to the above communication circuit and the above memory, the processor comprising:

Receive data packets for service requests from nodes,

Check whether there is a channel corresponding to the above data packet,

If the above channel is confirmed to exist, the data packet is forwarded to the destination network of the data packet,

If the above channel is determined not to exist, the data packet is forwarded to an external server,

A gateway configured to receive information about the channel from the external server based on an authentication result for the node after forwarding the data packet to the external server.
In paragraph 1,

The above channel comprises a tunnel or a secure session, a gateway.
In paragraph 1,

The above processor,

If it is confirmed that the above channel exists, it is checked whether a data flow corresponding to the above data packet exists,

A gateway configured to forward the data packet to the destination network when the above data flow is determined to exist.
In the third paragraph,

The above processor,

If it is confirmed that the above data flow exists, it is checked whether QoS is required for the service request based on the QoS (Quality of Service) information included in the data flow,

If it is determined that the above QoS is required for the above service request, it is checked whether the above service request satisfies the critical service request condition corresponding to the above QoS information,

A gateway configured to cause the service request to be transmitted after a preset time has elapsed or to cause the node to retransmit the service request if it is determined that the service request does not satisfy the threshold service request condition.
In paragraph 4,

The above processor,

If the above data flow is confirmed to exist, the validity of the node authentication information included in the data packet is determined,

A gateway configured to, if the above node authentication information is determined to be valid, update the above data flow and then check whether the above QoS is required for the above service request.
In paragraph 4,

The above processor,

If it is confirmed that the above service request satisfies the above critical service request condition or if it is confirmed that the QoS is not required for the above service request, it is confirmed whether the protocol of the data packet is normal based on the filtering information included in the data flow,

If the protocol of the above data packet is confirmed to be normal, it is determined whether replacement of the information included in the above data packet is necessary based on the above filtering information,

A gateway configured to forward the data packet to the destination network by replacing the information included in the data packet based on at least some of the replacement information and replacement rules included in the filtering information, if the replacement is determined to be necessary.
In the third paragraph,

The above processor,

Generate authorized node identification information to identify authorized nodes based on data flow identification information,

A gateway configured to insert the above-mentioned authorization node identification information into a data packet for the above-mentioned service request and forward it to the above-mentioned destination network.
In paragraph 1,

The above processor,

After forwarding the above data packet to the external server, information about the channel is received from the external server as the authentication result satisfies the authentication condition.

The above authentication condition corresponds to at least one of the installation information of the access control application of the node and the authentication process execution information of the node.
On external servers,

communication circuit;

memory; and

A processor operatively connected to the above communication circuit and the above memory, the processor comprising:

When a data packet for a service request is obtained, authentication support information is transmitted to the node by referring to the data packet,

Based on the above authentication support information, a network connection request including a source IP (internet protocol) is obtained from the node,

Verifying whether the node is accessible to the destination network based on the information included in the network access request;

An external server configured to send information about the channel to the gateway when a connection is confirmed.
In Article 9,

The above processor,

When an access control application is installed on the node based on the above authentication support information, the node is granted first access to the destination network,

An external server configured to grant the node second access rights to the destination network when the node authentication process is performed based on the above authentication support information.
In terms of how the gateway operates,

A step of receiving a data packet for a service request from a node;

A step of checking whether a data flow and a security session corresponding to the above data packet exist; and

A method comprising the steps of: if it is confirmed that the data flow and the security session exist, forwarding the data packet to the destination network of the data packet; if it is confirmed that the data flow and the security session do not exist, forwarding the data packet to an external server; and then receiving information about the channel from the external server according to the authentication result for the node.
In Article 11,

The step of forwarding the above data packet to the destination network is:

A step of generating authorization node identification information for identifying an authorized node based on data flow identification information; and

A method comprising the step of inserting the above-mentioned authorization node identification information into the data packet and forwarding it to the destination network.