KR102782378B1 - System for controlling network access based on proxy and method of the same - Google Patents

Abstract

According to one embodiment of the present invention, a gateway comprises a communication circuit, a memory storing a database, and a processor operatively connected to the communication circuit and the memory, wherein the processor receives a data packet from a node, verifies tuple information of the data packet or data flow authentication information included in the data packet, and if a data flow corresponding to the tuple information or the data flow authentication information exists, verifies whether NAT for proxy processing is necessary based on NAT (Network Address Translation) information included in the data flow and for forwarding the data packet to a proxy, and if NAT for proxy processing is necessary, performs NAT for the data packet based on the NAT information, updates the tuple information in the data flow, forwards the data packet on which the NAT was performed to the proxy, or if NAT for proxy processing is not necessary, forwards the data packet to the service server, and if NAT for the data packet is performed, updates tuple information before NAT and tuple information after NAT in the data flow, and a proxy included in the gateway performs the NAT. The data flow may be identified based on the pre-tuple information and the tuple information after performing NAT, and if NAT performance for the proxy processing is not required, the data packet may be configured to be forwarded to the service server.

Description

{SYSTEM FOR CONTROLLING NETWORK ACCESS BASED ON PROXY AND METHOD OF THE SAME}

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

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.

The technology for performing network connection processing based on a proxy has a method of sequentially controlling service requests and responses after logical connections (TCP, UDP) at the transport layer for processing network connections, tunnels created before allowing logical connections, and security sessions (TLS, QUIC) created after logical connections.

The method of controlling logical connections through the network access control application of the node enables the source blocking of unauthorized target communication through the identification of the target application and the destination network. In addition, by using the data flow processing technology authorized through the controller corresponding to the network access point of the node, the gateway can perform detailed control on the domain, URL, and data corresponding to the service request.

However, since the gateway processes the service request after at least two connections (logical connection, tunnel, security session) are created between the gateway and the node acting as the proxy, unnecessary connections may be involved due to the characteristics of the logical connection that determines whether the destination network is determined by the IP address and the characteristics of the proxy that identifies the destination network and service using either the IP address or the domain address.

In addition, when processing logical connections by setting up a proxy on a node, the destination network information that allows logical connections is processed by the proxy IP and port set on the node, which may cause difficulties in controlling the destination network.

The various embodiments disclosed in this document are intended to provide a system and method thereof for solving the above-described problems in a network environment.

According to one embodiment of the present invention, a gateway comprises a communication circuit, a memory storing a database, and a processor operatively connected to the communication circuit and the memory, wherein the processor receives a data packet from a node, verifies tuple information of the data packet or data flow authentication information included in the data packet, and if a data flow corresponding to the tuple information or the data flow authentication information exists, verifies whether NAT for proxy processing is necessary based on NAT (Network Address Translation) information included in the data flow and for forwarding the data packet to a proxy, and if NAT for proxy processing is necessary, performs NAT for the data packet based on the NAT information, updates the tuple information in the data flow, forwards the data packet on which the NAT was performed to the proxy, or if NAT for proxy processing is not necessary, forwards the data packet to the service server, and if NAT for the data packet is performed, updates tuple information before NAT and tuple information after NAT in the data flow, and a proxy included in the gateway performs the NAT. The data flow may be identified based on the pre-tuple information and the tuple information after performing NAT, and if NAT performance for the proxy processing is not required, the data packet may be configured to be forwarded to the service server.

According to one embodiment of the present invention, a method of operating a gateway comprises: receiving a data packet from a node and checking tuple information of the data packet or data flow authentication information included in the data packet; if a data flow corresponding to the tuple information or the data flow authentication information exists, checking whether NAT (Network Address Translation) for proxy processing is necessary based on NAT information included in the data flow and for forwarding the data packet to a proxy; if NAT for proxy processing is necessary, performing NAT for the data packet based on the NAT information; updating the tuple information in the data flow; forwarding the data packet on which the NAT has been performed to the proxy, or if NAT for proxy processing is not necessary, forwarding the data packet to the service server; if NAT for the data packet is performed, updating tuple information before NAT and tuple information after NAT in the data flow; The proxy included in the gateway may include an operation of identifying the data flow based on tuple information before performing the NAT and tuple information after performing the NAT; and an operation of forwarding the data packet to the service server if NAT performance for the proxy processing is not required.

According to the embodiments disclosed in this document, it is possible to provide a technology capable of safely accessing a service using existing application access control technology, identifying and authenticating a target of access in a service, and providing an integrated authentication technology that can be easily applied to popular services.

Additionally, according to the embodiments disclosed in this document, it is possible to block the creation of a secure session by an unauthorized subject through a gateway including a proxy function.

In addition, according to the embodiments disclosed in this document, a gateway including a proxy function performs data flow processing corresponding to at least one of a connection request time of a proxy protocol or a security session request time based on logical connection information or tunnel-based fixed IP information capable of identifying a node, and prevents unnecessary network access by blocking network access of an unauthorized target.

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

Figure 1 illustrates an environment including multiple networks.
Figure 2 illustrates an architecture within a network environment according to various embodiments.
FIG. 3 is a functional block diagram illustrating a database stored in a controller according to various embodiments.
FIG. 4 illustrates a functional block diagram of a node according to various embodiments.
FIG. 5 illustrates an operation for controlling transmission of data packets according to various embodiments.
Figures 6a and 6b illustrate examples of operation of a gateway according to various embodiments.
Figure 7 illustrates a signal flow diagram for controller connection according to various embodiments.
FIG. 8 illustrates a signal flow diagram for user authentication according to various embodiments.
FIG. 9 illustrates a signal flow diagram for network connection according to various embodiments.
FIG. 10 illustrates a signal flow diagram for data packet transmission of a node according to various embodiments.
Figure 11 illustrates examples of data packets according to various embodiments.
FIG. 12 illustrates an operational flow diagram for data packet forwarding of a gateway according to various embodiments.
FIG. 13 illustrates a signal flow diagram for responding to a request for creating a security session of a gateway according to various embodiments.
FIG. 14 illustrates a signal flow diagram for disconnection according to various embodiments.
FIG. 15 illustrates a signal flow diagram for control flow update according to various embodiments.
Figure 16 illustrates a signal flow diagram for terminating application execution according to various embodiments.

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 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 prior to 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" as 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, for example. 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 machine-readable storage medium (e.g., a memory). For example, a processor of the device may call at least one instruction among the one or more instructions stored from the storage medium and execute it. This enables the device 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 executable 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., electromagnetic waves), 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.

Figure 1 illustrates an environment including multiple networks.

Referring to FIG. 1, the first network (10) and the second network (20) may be different networks. For example, the first network (10) may be a public network such as the Internet, and the second network (20) may be a private network such as an intranet or VPN.

The first network (10) may include a source node (101). In the embodiments described in FIG. 1 and below, the 'source node' may be various types of devices capable of performing data communication. For example, the source node (101) may include a portable device such as a smart phone or tablet, a computer device such as a desktop or 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. For example, the source node (101) may include a server or gateway capable of transmitting data packets through an application. The source node (101) may also be referred to as an 'electronic device' or a 'terminal'. Meanwhile, the destination node (102) may include a device identical or similar to the aforementioned source node (101). For another example, the destination node (102) may be substantially identical to the destination network.

The originating node (101) can attempt to access the second network (20) and transmit data to the destination node (102) included in the second network (20). The originating node (101) can transmit data to the destination node (102) through the gateway (103).

When the access of the source node (101) to the first network (10) is approved, the source node (101) can communicate with all servers included in the first network (10), so the source node (101) can be exposed to attacks by malicious programs. For example, the source node (101) can receive data from trusted and/or secure applications, such as an Internet web browser (110a) and a business application (110b), as well as data from untrusted or insecure applications, such as malicious code (110c) and infected business applications (110d).

The source node (101) infected with a malicious program may attempt to connect to and/or transmit data to the second network (20). If the second network (20) is formed based on IP, such as a VPN, the second network (20) may have difficulty individually monitoring a plurality of devices included in the second network (20), and may be vulnerable to security for the application layer or the transport layer in the OSI layer. In addition, if the source node (101) includes a malicious application after the tunnel has already been created, data of the malicious application may be transmitted to another electronic device (e.g., the destination node (102)) within the second network (20).

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

Referring to FIG. 2, the node (201) may be various types of devices capable of performing data communication. For example, the node (201) may include a portable device such as a smart phone or tablet, a computer device such as a desktop or 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 devices described above. For example, the node (201) may include a server or gateway capable of transmitting data packets through an application. The node (201) may also be referred to as an 'electronic device' or a 'terminal'.

The node (201) can store a target application (212) and a connection control application (211). The target application (212) is controlled by the connection control application (211) and can transmit data packets to the service server (205) or, conversely, receive data packets through the gateway (203). Some of the target applications (212) 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 system according to the embodiments can block access to the service server (205) of unauthorized programs (applications) through the network access control of the connection control application (211) and isolate the programs. For example, before the target application (212) according to the embodiments communicates with the service server (205), the connection control application (211) can check whether connection is possible from the controller (202). If connection is possible, the access control application (211) can control the transmission of data packets of the target application (212). That is, in order for the target application (212) to connect to the network, it must go through the access control application (211), the access control application (211) must be authorized by the controller (202), and the access control application (211) can transmit the data packets of the target application (212) based on a data flow based on the policy of the controller (202).

The controller (202) may be, for example, a server (or a cloud server). The controller (202) may manage data transmission among the node (201), the gateway (203), and the service server (205), thereby ensuring reliable data transmission within a network environment. For example, the controller (202) may allow network access of an authorized node (201) (or an access control application (211)) through policy information or blacklist information. The controller (202) may provide information that enables a tunnel to be created between the node (201) and the gateway (203). Accordingly, the access control application (211) of the node (201) may prevent an unauthorized application from transmitting data packets for an unauthorized purpose, and may provide a structure in which only authorized data packets may be transmitted to the service server (205) through the tunnel created with the gateway (203).

In an embodiment, the network access of the target application (212) may be blocked by the access control application (211), the controller (202), or the gateway (203). In one embodiment, the controller (202) may transmit and receive control data packets with the access control application (211) to perform various operations (e.g., registration, approval, authentication, renewal, termination) associated with the network access of the node (201) or the access control application (211). The flow (e.g., 220) through which the control data packets are transmitted may be referred to as a 'control flow'. In an embodiment, the controller (202) may maintain a secure network state at all times by immediately retrieving tunnels and sessions according to security events received from the interworking system (e.g., the node (201), the gateway (203), or the service server (205)).

The gateway (203) may be located at the boundary of the network to which the node (201) belongs or the boundary of the network to which the service server (205) belongs. According to one embodiment, the gateway (203) may be connected to the controller (202) based on a cloud. According to an embodiment, the gateway (203) may relay communication with the service server (205) through the proxy server (233) for data packets received through an authorized tunnel, and may provide a structure for the service server (205) to process a service request received from an authenticated target. According to an embodiment, the flow in which data packets are transmitted between the access control application (211) and the gateway (203) may be referred to as a 'data flow'. The data flow may be generated not only in units of nodes or IPs but also in units of more detailed information (e.g., applications).

According to an embodiment, the gateway (203) can control the network connection of the node (201) where the tunnel or logical connection is created. For example, the gateway (203) can transmit only the data packets allowed through the connection control application (211) installed in the node (201) and the created connection to the proxy server (233) in order to correspond to the protocol operating in the application layer, and the proxy server (233) can provide a structure for forwarding only the data packets of the authorized connection to the service server by using a connection control element corresponding to at least one of the proxy connection protocol or the security session in order to control the connection to the allowed service server (205).

According to an embodiment, the gateway (203) may include a tunnel server (213) for forming a tunnel with an access control application (211) and a data packet processing module (223) for verifying whether a data packet is authenticated or determining whether to forward the data packet. For example, the gateway (203) may verify whether all data packets passing through the gateway (203) are data packets transmitted from an authorized target (e.g., a target authorized by the controller (202)).

According to an embodiment, the gateway (203) can relay service processing with the service server (205) through a proxy server (233) included in the gateway (203) for data packets received through a tunnel such as an authorized tunnel or session.

According to various embodiments, the node (201) may include a connection control application (211) and a network driver (not shown) for managing network connection of a target application (212) stored in the node (201). For example, when a connection event for a service server (205) of a target application (212) included in the node (201) occurs, the connection control application (211) may determine whether the target application (212) is connectable. If the target application (212) is connectable, the connection control application (211) may transmit a data packet to the gateway (203). The connection control application (211) may control transmission of the data packet through a kernel including an operating system and a network driver within the node (201).

FIG. 3 is a functional block diagram showing a database stored in a controller according to various embodiments. Although FIG. 3 only shows a memory (330), the controller may further include a communication circuit (e.g., a communication circuit (430) of FIG. 4) for communicating with an external electronic device and a processor (e.g., a processor (410) of FIG. 4) for controlling the overall operation of the controller.

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

The access policy database (311) may include information about networks and/or services to which the identified network, node, or application can connect. For example, when the access control application (211) requests network connection, the controller (202) may determine, based on the policies of the access policy database (311), whether the identified network (e.g., a network to which the node (201) belongs), node, user (e.g., a user of the node (201)), and/or application (e.g., a target application (212) included in the node (201)) can connect to the service server (205). In one embodiment, the controller (202) may generate a whitelist of target applications (212) that can connect to a specific service (e.g., an IP and a port) based on the access policy database (311).

The tunnel policy database (312) may include information on a gateway (e.g., gateway (203) of FIG. 2) existing between service servers (e.g., service servers (205) of FIG. 2) on a connection path according to a policy. For example, the tunnel policy database (312) may include a series of information (authentication information, encryption algorithm, tunnel endpoint, etc.) required for tunnel creation with the gateway (203) and, if a tunnel previously connected via another gateway exists between the connection paths, a series of information for using it (e.g., collection of IP information assigned to a node and whether to perform replacement processing).

The blacklist policy database (313) 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, or a user ID) identified through analysis of the risk level, occurrence cycle, and/or behavior of a security event among security events periodically collected from a node (201) or a gateway (203).

The blacklist database (314) may include a list of objects blocked by the blacklist policy database (313). For example, the controller (202) may isolate a node (201) by denying a network connection request if the identification information of the node (201) requesting network connection is included in the blacklist database (314).

The control flow table (315) is an example of a session table for managing the flow of control data packets (e.g., control flows) generated between the node (201) and the controller (202). When successfully connecting to the controller (202), control flow information can be generated by the controller (202). The control flow information can include at least one of identification information of the control flow, an IP address identified when connecting to and authenticating the controller, a node ID, or a user ID. For example, when a connection to the service server (205) is requested from the node (201), the controller (202) can search for control flow information through the control flow identification information received from the node (201), and map at least one of the IP address, node ID, or user ID included in the searched control flow information to the connection policy database (311), thereby determining (determining) whether the node (201) can connect to the service server (205) and whether to generate a data flow for transmitting data packets.

According to one embodiment, a control flow may have an expiration time. The node (201) must 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 connection blocking is necessary based on a security event collected from the node (201), the controller (202) may remove the control flow based on a connection termination request from the node (201). When the control flow is removed, the previously generated data flow is also removed, so that the connection of the node (201) may be blocked.

The data flow table (316) is a table for managing a flow (e.g., data flow) in which detailed data packets are transmitted between the node (201), the gateway (203), and the service server (205). The data flow may be generated by a TCP session, an application, or a more detailed unit. The data flow table (316) may include data flow information for managing an application (e.g., target application (212)) of the node (201), a tunnel and a session of the gateway (203), and the service server (205). The data flow table (316) may include an application ID, a destination IP address, and/or a service port for identifying whether a data packet transmitted from a source is an authorized data packet. The data flow table (316) may be managed based on a control flow ID. Additionally, the data flow table (316) may include authorized target information for determining whether to forward a data packet based on the source IP and destination IP of the data packet, port information, and status information including whether the data flow is valid.

According to an embodiment, the data flow table (316) may include authentication information. For example, the authentication information may include a series of information for verifying whether an authorized node has transmitted a data packet, a method for inserting authentication information for each transmission protocol (e.g., in the case of TCP, inserting TCP SYN packets, in the case of UDP, inserting authentication information for each data packet or inserting authentication information at regular intervals (or cycles)), information for encrypting and 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), and authentication information including whether the source IP is authenticated. According to an embodiment, the authentication information may be determined (or generated) based on the authentication policy database (312).

According to an embodiment, the authorized target information included in the data flow table (316) may include logical identification information (e.g., domain address, server host name, etc.) identified during the security session creation process in addition to the destination IP address. For example, the authorized target information may include information for identifying a communication flow with the communication target, such as whether the data flow included in the data flow table (316) is based on logical connection authentication between the communication target and the gateway (203) or based on a source IP assigned to the node (201) based on a tunnel. For another example, when identifying a communication flow in a transport layer (transport layer of the OSI 7 layers), the authorized target information may include 5 Tuples information (source IP, source port, destination IP, destination port, and transport protocol information) that is updated so that the communication flow can be identified in the application layer.

According to an embodiment, the data flow table (316) may include a security session ID. For example, the security session ID may include security session information identified by the node (201) and the gateway (203) respectively during the security session creation process. According to an embodiment, the security session ID may not be included in the data flow table (316) if the communication is not based on a security session.

According to an embodiment, the data flow table (316) may further include NAT information. For example, the NAT information may include NAT (Network Address Translation) information for proxy processing depending on the destination service and service.

According to an embodiment, the data flow table (316) may be identically stored in the node (201), the gateway (203), or the service server (205).

The logical connection authentication policy database (317) may include information for authenticating a logical connection between a communication target and a gateway (203) based on the connection policy database (311) (e.g., a method for generating and checking authentication information according to a protocol, etc.).

The proxy and certificate policy database (318) may include information for performing NAT (Network Address Translation) based on the connection policy database (311) depending on the destination server (e.g., service server (205)) that must pass through a proxy on the connection path, and when performing communication based on a secure session via a proxy, the node (201) may include trustworthy certificate information when creating a secure session. For example, a node (201) for which certificate information is not set may not be able to communicate through the gateway (203).

The tunnel table (319) may include a list of tunnels created between the node (201) and the gateway (203). For example, the tunnel table (319) may be composed of tunnel identification information for managing and identifying a tunnel when a valid tunnel exists, control flow identification information for controlling between the node (201) and the controller (202), and additional information for managing TEP (tunnel end point), TSP (tunnel start point), tunnel algorithm and type, encryption level, etc.

The harmful domain database (320) may include information for checking whether a destination domain address identified during a security session is harmful and blocking access if it is a harmful domain address.

FIG. 4 illustrates a functional block diagram of a node according to various embodiments.

Referring to FIG. 4, the node may include a processor (410), a memory (420), and a communication circuit (430). According to one embodiment, the node may further include a display (440) to perform an interface with a user.

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

All or part of the processor (410) may be electrically or operatively coupled with or connected to other components within the node (e.g., memory (420), communication circuitry (430), or display (440). The processor (410) may receive commands from other components of the node, interpret the received commands, and perform calculations or process data in accordance with the interpreted commands. The processor (410) may interpret and process messages, data, commands, or signals received from the memory (420), communication circuitry (430), or display (440). The processor (410) may generate new messages, data, commands, or signals based on the received messages, data, commands, or signals. The processor (410) may provide the processed or generated messages, data, commands, or signals to the memory (420), communication circuitry (430), or display (440).

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

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

The memory (420) 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 (420) 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).

According to one embodiment, the memory (420) may store the target application (212) and the access control application (211) of FIG. 2. For example, the access control application (211) may perform a control flow generation and update function with the controller (202). For this purpose, the access control application (211) may include one or more security modules.

According to one embodiment, the memory (420) may store some of the information contained in the memory of the controller (e.g., the memory (330) of FIG. 3). For example, the memory (420) may store the data flow table (316) described in FIG. 3.

The communication circuit (430) can support the establishment of a wired or wireless communication connection between a node and an external electronic device (e.g., the controller (202), the gateway (203), or the service server (205) of FIG. 2), and the performance of communication through the established connection. According to one embodiment, the communication circuit (430) 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 the corresponding communication circuit, communication with an external electronic device can be made 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 (430) described above can be implemented as one chip or can be implemented as separate chips.

The display (440) can output content, data, or signals. In various embodiments, the display (440) can display image data processed by the processor (410). According to embodiments, the display (440) may be configured with an integrated touch screen by being combined with a plurality of touch sensors (not shown) that can receive touch inputs, etc. When the display (440) is configured with a touch screen, the plurality of touch sensors may be disposed above the display (440) or below the display (440).

A server (e.g., a controller) according to one embodiment may include a processor (410), a memory (420), and a communication circuit (430). The processor (410), the memory (420), and the communication circuit (430) included in the server may be substantially the same as the processor (410), the memory (420), and the communication circuit (430) described above.

A gateway according to one embodiment (e.g., gateway (203) of FIG. 2) may include a processor (410), a memory (420), and a communication circuit (430). The processor (410), the memory (420), and the communication circuit (430) included in the gateway may be substantially the same as the processor (410), the memory (420), and the communication circuit (430) described above.

FIG. 5 illustrates an operation for controlling transmission of data packets according to various embodiments.

Referring to FIG. 5, the access control application (211) can detect a network connection request to the service server (205) from a target application (212) included in the node (201), and determine whether the node (201) or the access control application (211) is connected to the controller (202). If the node (201) or the access control application (211) is not connected to the controller (202), the access control application (211) can block transmission of data packets in a kernel or network driver including an operating system. Through the access control application (211), the node (201) can block connections from malicious applications in advance in the application layer of the OSI layer.

According to an embodiment, if the access control application (211) is not connected to the controller (202) or if the data packet to be transmitted is a data packet that must be transmitted based on a tunnel but a corresponding tunnel does not exist, the data packet transmitted from the access control application (211) is blocked by the gateway (203) and the access control application (211) can only request a connection to the controller (202).

According to an embodiment, if the access control application (211) is not installed in the node (201) or a malicious application bypasses the control of the access control application (211), unauthorized data packets may be transmitted from the node (201). In this case, the gateway (203) existing at the boundary of the network blocks data packets for which a corresponding tunnel does not exist, so that data packets (e.g., data packets for TCP session creation) transmitted from the node (201) may not reach the service server (205). In other words, the node (201) may be isolated from the service server (205).

As a result, unauthorized nodes or applications may be unable to access the service server (205) by default through the gateway (203) if there is no multi-layer connection leading to a tunnel, logical connection, or secure session.

Figures 6a and 6b illustrate examples of operation of a gateway according to various embodiments.

Referring to FIGS. 6A and 6B, according to the conventional technology, connectivity control corresponds to security session connection control of tunnel or logical connection, certificate verification, and service processing in a proxy server can provide a structure that enables detailed access and filtering based on a previously created connection.

When all traffic of a node (201) is transmitted to a proxy server, since the destination network of all connections is limited to the IP of a trusted gateway (203), access control based on the destination network cannot help but depend on information included in a service request at the application layer after all connections (tunnels, logical connections, proxy connections, secure session connections, etc.) are created.

In addition, as man-in-the-middle attacks through proxy settings become widespread and security issues arise, the operating systems that support proxy protocols are limited, so the use of methods for controlling network access through a proxy may be limited.

According to the embodiments disclosed in this document, the gateway (203) can identify a communication target through a tunnel or logical connection control method created in the node (201) and the gateway (203), and if proxy processing is required according to the service server (205), the gateway (203) can perform NAT (Network Address Translation) to transmit data packets to the proxy.

In addition, according to the embodiments disclosed in this document, a proxy server (233) included in a gateway (203) that receives a data packet through a NAT can identify destination network information (e.g., Connect Header, Server Name Indication of TLS, etc.) included in a secure session connection request (e.g., Client Hello phase of TLS), and the gateway (203) can check whether connection is possible through a query with a controller (202) if the information is included or not in the data flow, and if connection is possible, provide a structure for processing each connection, thereby performing detailed network access control.

Figure 7 illustrates a signal flow diagram for controller connection according to various embodiments.

Since the node (201) needs to be authorized by the controller (202) to access or receive a network, the access control application (211) of the node (201) can attempt to access the controller of the node (201) by requesting the controller (202) to create a control flow. According to an embodiment, the node (201) can be substantially identical to the node (201) of FIG. 2 in which the access control application (211) is installed.

Referring to FIG. 7, the node (201) can detect a controller connection event. For example, when a connection control application (211) is installed and executed within the node (201), the node (201) can detect that a connection to the controller (202) is requested.

In operation 705, the node (201) may request a controller (202) to connect to the controller. For example, the connection control application (211) may transmit identification information of the connection control application (211) to the controller (202). Additionally, the connection control application (211) may further transmit identification information of the node (201) (e.g., terminal ID, IP address, MAC address), type, location, environment, identification information of a network to which the node (201) belongs, and/or any identification information generated by the network system itself.

In operation 710, the controller (202) can identify whether a target (e.g., a connection control application (211) or a node (201)) that has requested controller connection is accessible. According to one embodiment, the controller (202) can identify whether a target that has requested controller connection is accessible based on at least one of whether information received from the node (201) is included in a connection policy database (311) or whether identification information of the node (201), the network to which the node (201) belongs, and/or the connection control application (211) is included in a blacklist database (314).

If connectable, in operation 715, the controller (202) can generate a control flow between the node (201) (or the access control application (211)) and the controller (202). In this case, the controller (202) can generate control flow identification information in the form of a random number and store identification information of at least one of the node (201), the network to which the node (201) belongs, or the access control application (211) in the control flow table (315). The information stored in the control flow table (315) can be used for user authentication of the node (201), information update of the node (201), policy verification for network access of the node (201), and/or validity check.

In operation 720, the controller (202) may generate a whitelist of applications that can be connected from the access policy database (311) and the tunnel policy database (312) corresponding to the identified information (e.g., node (201), information on the source network to which the node (201) belongs). According to an embodiment, the controller (202) may determine whether there is destination network information to which the node (201) that has currently requested connection can connect by default, based on the identified information, the access policy database (311), and the tunnel policy database (312). In one embodiment, the controller (202) may transmit the application whitelist to the access control application (211) in operation 725.

According to an embodiment, when generating an application whitelist, the controller (202) may include information for inspecting an application based on an application inspection policy (e.g., unique information of the application such as the execution or installation location of the application, signature, fingerprint, hash, registry, etc., a series of information for analyzing the binary of the application such as an executable file, a library and a series of files or processes referenced by the executable file, memory information, at least one of a malware detection tool or pattern DB information for inspecting whether the application is safe).

In addition, if connection is possible, the controller (202) can list the types of tunnels and gateways including proxies to which the node (201) can be connected. For example, the controller (202) can list the types of tunnels and gateways to which the node (201) can be connected based on at least one of the type of the node (201), location information, environment, and network information that the node (201) is included in the control flow for the node (201) to connect to the destination network, identification information (e.g., IP information) of the node (201) identified through the controller (202), and identification information of the node (201) identified in the node (201). For another example, the controller (202) may list the types of tunnels and gateways to which the node (201) may connect based on a combination of two or more of the type, location information, environment, and network information of the node (201) included in the control flow for the node (201) to access the destination network, identification information (e.g., IP information) of the node (201) identified through the controller (202), and identification information of the node (201) identified in the node (201). According to an embodiment, the controller (202) may list gateways (203) including a proxy based on the proxy and certificate policy (318).

The controller (202) can check the status of the listed gateways and identify a tunnel and gateway (203) optimized for the node (201) among the listed gateways. For example, the controller (202) can identify one tunnel and gateway (203). According to an embodiment, if there is a tunnel and gateway (203) accessible to the node (201), the controller (202) can transmit connection information, such as gateway (203) information for creating a tunnel and tunnel authentication information, gateway (203) information for proxy connection, and certificate information that can be set for the node (201), to the node (201) (operation 725).

According to an embodiment, if there is a gateway (203) that includes a proxy that can be accessed without a tunnel existing in the network to which the node (201) belongs and a structure in which a tunnel is not created between the node (201) and the gateway (203), the controller (202) may not transmit connection information including gateway information for proxy connection and certificate information that can be set in the node (201) to the node (201).

In operation 725, the controller (202) may transmit control flow identification information to the node (201) in response to the controller connection request. In an embodiment, if the target requesting the controller connection is inaccessible or included in a blacklist, the controller (202) may transmit inaccessibility information in operation 725 without generating a control flow. In one embodiment, the controller (202) may transmit an application whitelist generated by performing operation 720 to the connection control application (211).

In operation 730, the access control application (211) may request tunnel creation to the gateway (203) based on information for tunnel creation received from the controller (202) (e.g., a series of information required for tunnel creation, such as the gateway (203) and tunnel authentication information) if tunnel creation is required (e.g., if tunnel creation information is not received from the controller (202), or if unnecessary tunnel creation information is received from the controller (202), etc.). The gateway (203) may create a tunnel in response to the tunnel creation request of the node (201). According to an embodiment, if the controller (202) determines that tunnel creation is unnecessary (e.g., if tunnel creation information is not received from the controller (202), or if unnecessary tunnel creation information is received from the controller (202), the access control application (211) may not perform operation 730.

When tunnel creation is complete, at operation 735, the access control application (211) can perform certificate setup on the node (201) based on the received certificate information.

According to an embodiment, the access control application (211) can perform a check on the application. For example, the access control application (211) can perform a check on the application based on the connectable application white list received from the controller (202). The access control application (211) can check whether the application exists (is installed) on the node (201) based on the connectable application information, and if the application exists, can perform an integrity and stability check (an application tampering check, a code signing check, a fingerprint check) according to a validation policy.

In operation 740, the access control application (211) can transmit tunnel creation completion information and IP information, if there is a dedicated IP set according to tunnel creation, to the controller (202) when tunnel creation is completed. In addition, the access control application (211) can additionally transmit application inspection results to the controller (202).

In operation 745, if tunnel creation is completed according to the tunnel creation result, the controller (202) can register the tunnel-only IP and tunnel creation information assigned to the node (201) in the tunnel table (319) and update the information transmitted by the node (201) in the control flow.

According to an embodiment, the controller (202) can check whether the application is valid based on the received application information. According to an embodiment, if the application is invalid, the controller (202) can evaluate the risk level of the application inspection result based on the application inspection policy, and based on the risk level, release the control flow to block the connection of the node (201) or register it in a blacklist.

If it is a valid application, the controller (202) can create a data flow based on the access policy and authentication policy to allow the node (201) to transmit data packets without a network access request procedure in order to allow the node (201) to access in advance.

According to an embodiment, the data flow may include authentication information including transmission protocol information, a source IP, a destination IP, port information, and, when performing authentication of a data packet, a method for inserting authentication information by transmission protocol (e.g., in the case of TCP, inserting TCP SYN packets, in the case of UDP, inserting authentication information for each data packet or inserting authentication information at regular intervals (or cycles)), information for encrypting and 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 a Secret Key when generating HMAC OTP), and authentication information including whether the source IP is authenticated.

According to an embodiment, the controller (202) can determine whether an allowed destination service and server pass through a proxy through a gateway (203) existing between destination networks based on a proxy policy. In this case, the controller (202) can generate NAT (Network Address Translation) information for proxy processing by including it in the data flow at the gateway (203).

The controller (202) can compare the certificate information received from the node (201) to determine whether there is an additional certificate or a renewal certificate that needs to be set in the node (201), and if certificate setting is required, can return the certificate information to the node (201) (operation 755).

The controller (202) can transmit the generated data flow to the gateway (203) and the access control application (211) (operations 750, 755).

In operation 760, the access control application (211) can process the result value according to the received response. For example, the access control application (211) can store the received control flow identification information and display a user interface screen indicating that the controller connection is completed to the user. When the controller connection is completed, the network connection request of the node (201) to the destination network can be controlled by the controller (202).

In another embodiment, the controller (202) may determine that the node (201) is inaccessible. For example, if the identification information of the node (201) and/or the network to which the node (201) belongs is included in a blacklist database, the controller (202) may determine that the node (201) is inaccessible. In this case, the controller (202) may not generate a control flow at operation 715, but may transmit a response indicating that the controller connection is inaccessible at operation 725. Additionally, in this case, operations 730 to 755 may not be performed. In an embodiment, if a retry of the controller connection is required, the connection control application (211) may perform operation 705 again.

In addition, the access control application (211) can manage the data flow by updating the data flow of the node (201) when there is a data flow received from the controller (202), so that data packets can be transmitted based on the data flow previously allowed when connecting to the network. Thereafter, when a request for data packet transmission is detected, the access control application (211) can process the data packet to be transmitted based on the received data flow.

FIG. 8 illustrates a signal flow diagram for user authentication according to various embodiments.

In order for the node (201) to be granted detailed access rights to the destination network, the access control application (211) of the node (201) can receive authentication for the user of the node (201) from the controller (202). According to an embodiment, the node (201) can be substantially identical to the node (201) of FIG. 2 in which the access control application (211) is installed.

Referring to FIG. 8, the node (201) can receive input for user authentication. The input for user authentication can be, for example, a user input for entering a user ID and a password. As another example, the input for user authentication can be a user input for more reinforced authentication (e.g., biometric information). In this case, in operation 805, the access control application (211) of the node (201) can request the controller (202) for user authentication. If a control flow between the node (201) and the controller (202) has already been created, the access control application (211) can transmit input information for user authentication together with the control flow identification information.

In operation 810, the controller (202) may authenticate the user based on information received from the node (201). For example, the controller (202) may determine whether the user can access according to the access policy and whether the user is included in a blacklist based on the user ID, password, and/or enhanced authentication information included in the received information and a database (e.g., the access policy database (311) or the blacklist database (314) of FIG. 3) included in the memory of the controller (202).

Once the user is authenticated, at operation 815, the controller (202) may add the user's identification information (e.g., user ID) to the identification information of the control flow. The added user identification information may be used for the authenticated user's controller access or network access.

In operation 820, the controller (202) may generate a whitelist of applications that can be connected from the access policy database (311) and the tunnel policy database (312) corresponding to the identified information (e.g., node (201), information on the source network to which the node (201) belongs). According to an embodiment, the controller (202) may determine whether there is destination network information to which the node (201) that has currently requested connection can connect by default, based on the identified information, the access policy database (311), and the tunnel policy database (312). In one embodiment, the controller (202) may transmit the application whitelist to the access control application (211) in operation 825.

According to an embodiment, when generating an application whitelist, the controller (202) may include information for inspecting an application based on an application inspection policy (e.g., unique information of the application such as the execution or installation location of the application, signature, fingerprint, hash, registry, etc., a series of information for analyzing the binary of the application such as an executable file, a library and a series of files or processes referenced by the executable file, memory information, at least one of a malware detection tool or pattern DB information for inspecting whether the application is safe).

In addition, if connection is possible, the controller (202) can list the types of tunnels and gateways including proxies to which the node (201) can be connected. For example, the controller (202) can list the types of tunnels and gateways to which the node (201) can be connected based on at least one of the type of the node (201), location information, environment, and network information that the node (201) is included in the control flow for the node (201) to connect to the destination network, identification information (e.g., IP information) of the node (201) identified through the controller (202), and identification information of the node (201) identified in the node (201). For another example, the controller (202) may list the types of tunnels and gateways to which the node (201) may connect based on a combination of two or more of the type, location information, environment, and network information of the node (201) included in the control flow for the node (201) to access the destination network, identification information (e.g., IP information) of the node (201) identified through the controller (202), and identification information of the node (201) identified in the node (201). According to an embodiment, the controller (202) may list gateways (203) including a proxy based on the proxy and certificate policy (318).

The controller (202) can check the status of the listed gateways and identify a tunnel and gateway (203) optimized for the node (201) among the listed gateways. For example, the controller (202) can identify one tunnel and gateway (203). According to an embodiment, if there is a tunnel and gateway (203) accessible to the node (201), the controller (202) can transmit connection information, such as gateway (203) information for creating a tunnel and tunnel authentication information, gateway (203) information for proxy connection, and certificate information that can be set for the node (201), to the node (201) (operation 825).

According to an embodiment, if there is a gateway (203) that includes a proxy that can be accessed without a tunnel existing in the network to which the node (201) belongs and a structure in which a tunnel is not created between the node (201) and the gateway (203), the controller (202) may not transmit connection information including gateway information for proxy connection and certificate information that can be set in the node (201) to the node (201).

At operation 825, the controller (202) may transmit information indicating that the user is authenticated to the node (201) in response to the user authentication request. In one embodiment, the controller (202) may transmit the application white list generated through the performance of operation 820 to the access control application (211).

In operation 830, the access control application (211) may request tunnel creation to the gateway (203) based on information for tunnel creation received from the controller (202) (e.g., a series of information required for tunnel creation, such as the gateway (203) and tunnel authentication information) if tunnel creation is required (e.g., if tunnel creation information is not received from the controller (202), or if unnecessary tunnel creation information is received from the controller (202), etc.). The gateway (203) may create a tunnel in response to the tunnel creation request of the node (201). According to an embodiment, if the controller (202) determines that tunnel creation is unnecessary (e.g., if tunnel creation information is not received from the controller (202), or if unnecessary tunnel creation information is received from the controller (202), the access control application (211) may not perform operation 830.

When tunnel creation is complete, at operation 835, the access control application (211) can perform certificate setup on the node (201) based on the received certificate information.

According to an embodiment, the access control application (211) can perform a check on the application. For example, the access control application (211) can perform a check on the application based on the connectable application white list received from the controller (202). The access control application (211) can check whether the application exists (is installed) on the node (201) based on the connectable application information, and if the application exists, can perform an integrity and stability check (an application tampering check, a code signing check, a fingerprint check) according to a validation policy.

In operation 840, the access control application (211) can transmit tunnel creation completion information and IP information, if there is a dedicated IP set according to tunnel creation, to the controller (202) when tunnel creation is completed. In addition, the access control application (211) can additionally transmit the application inspection result to the controller (202).

In operation 845, if tunnel creation is completed according to the tunnel creation result, the controller (202) can register the tunnel-dedicated IP and tunnel creation information assigned to the node (201) in the tunnel table (319) and update the information transmitted by the node (201) in the control flow.

According to an embodiment, the controller (202) can check whether the application is valid based on the received application information. According to an embodiment, if the application is invalid, the controller (202) can evaluate the risk level of the application inspection result based on the application inspection policy, and based on the risk level, release the control flow to block the connection of the node (201) or register it in a blacklist.

If it is a valid application, the controller (202) can create a data flow based on the access policy and authentication policy to allow the node (201) to transmit data packets without a network access request procedure in order to allow the node (201) to access in advance.

According to an embodiment, the data flow may include authentication information including transmission protocol information, a source IP, a destination IP, port information, and, when performing authentication of a data packet, a method for inserting authentication information by transmission protocol (e.g., in the case of TCP, inserting TCP SYN packets, in the case of UDP, inserting authentication information for each data packet or inserting authentication information at regular intervals (or cycles)), information for encrypting and 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 a Secret Key when generating HMAC OTP), and authentication information including whether the source IP is authenticated.

According to an embodiment, the controller (202) can determine whether an allowed destination service and server pass through a proxy through a gateway (203) existing between destination networks based on a proxy policy. In this case, the controller (202) can generate NAT (Network Address Translation) information for proxy processing by including it in the data flow at the gateway (203).

The controller (202) can compare the certificate information received from the node (201) to determine whether there is an additional certificate or a renewal certificate that needs to be set in the node (201), and if certificate setting is required, can return the certificate information to the node (201) (operation 855).

The controller (202) can transmit the generated data flow to the gateway (203) and the access control application (211) (operations 850, 855).

In operation 860, the access control application (211) can process the result value according to the received response. For example, the access control application (211) can store the received control flow identification information and display a user interface screen indicating that the user authentication is completed to the user. When the user authentication is completed, the network access request for the destination network of the node (201) can be controlled by the controller (202).

In another embodiment, the controller (202) may determine that user authentication of the node (201) is impossible. For example, if identification information of the node (201) and/or the network to which the node (201) belongs is included in a blacklist database, the controller (202) may determine that the node (201) is inaccessible and that user authentication is impossible. In this case, the controller (202) may not reflect the user identification information in operation 815 and may transmit a response indicating that controller connection is impossible in operation 825. Additionally, in this case, operations 830 to 855 may not be performed.

In addition, the access control application (211) can update the data flow of the node (201) when there is a data flow received from the controller (202), and manage the data flow so that data packets can be transmitted based on the data flow previously allowed when connecting to the network.

According to an embodiment, the access control application (211) can perform certificate setting if there is certificate information received from the controller (202).

FIG. 9 illustrates a signal flow diagram for network connection according to various embodiments.

After the node (201) is authorized by the controller (202), the node (201) can ensure reliable data transmission by controlling the network access of other applications stored in the node (201) through the access control application (211) of the node (201). According to an embodiment, the node (201) can be substantially identical to the node (201) of FIG. 2 in which the access control application (211) is installed.

Referring to FIG. 9, at operation 905, the access control application (211) may detect a network access event of another application (e.g., target application (212) of FIG. 2) stored in the node (201).

In operation 910, the access control application (211) can check the existence of a data flow corresponding to the identification information of the application requesting network connection, the destination network identification information, and the port information. According to an embodiment, if the data flow exists but is invalid, the access control application (211) can drop the data packet. According to another embodiment, if the data flow exists, the access control application (211) can transmit the data packet based on the data flow. According to an embodiment, the access control application (211) of the node (201) can perform a network connection request in operation 915 without performing operation 910.

In case the data flow needs to be updated, such as when the data flow does not exist or the authentication time has expired and needs to be updated, at operation 915, the access control application (211) can perform a network connection request to the controller (202). For example, the network connection request can include control flow identification information, destination network identification information, and port information.

In operation 920, the controller (202) can check whether the access policy and proxy policy corresponding to the identified information (e.g., node, user, source network identification information) based on the control flow identification information include the identification information (e.g., transmission protocol, destination network identification information, and port information) requested for access and whether the destination network is accessible. According to an embodiment, the controller (202) can check whether the target application is accessible to the gateway (203) or the service server (205). According to an embodiment, if the network access is not possible, the controller (202) can transmit a connection failure result to the access control application (211) of the node (201) (operation 935).

If connectable, at operation 925, the controller (202) may generate a data flow based on the connection policy and authentication policy to allow the node (201) to transmit data packets without a network connection request procedure in order to allow the node (201) to connect in advance.

According to an embodiment, the data flow may include authentication information including transmission protocol information, a source IP, a destination IP, port information, and, when performing authentication of a data packet, a method for inserting authentication information by transmission protocol (e.g., in the case of TCP, inserting TCP SYN packets, in the case of UDP, inserting authentication information for each data packet or inserting authentication information at regular intervals (or cycles)), information for encrypting and 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 a Secret Key when generating HMAC OTP), and authentication information including whether the source IP is authenticated.

According to an embodiment, the controller (202) can determine whether an allowed destination service and server pass through a proxy through a gateway (203) existing between destination networks based on a proxy policy. In this case, the controller (202) can generate NAT (Network Address Translation) information for proxy processing by including it in the data flow at the gateway (203).

The controller (202) can transmit the generated data flow to the node (201) and the gateway (203) (operations 930, 935). Depending on the embodiment, operation 935 may not be performed if the generated data flow does not exist.

In operation 940, the access control application (211) of the node (201) can process a result value for a response received from the controller (202). For example, if the access control application (211) receives a network connection failure result from the controller (202), the access control application (211) can drop a data packet that the target application wants to transmit. For another example, if a data flow is received from the controller (202), the access control application (211) can transmit a data packet based on the received data flow.

According to an embodiment, when a network connection request is successful and certificate setup is required, the connection control application (211) can set a certificate based on certificate information included in the received data flow and transmit a data packet after the certificate setup.

In one embodiment, after performing operation 910, the access control application (211) may perform a validation check on the access application according to a validation policy. For example, the access control application (211) may further perform an integrity and stability check of the access application (such as an application forgery, tampering check, code signing check, and fingerprint check). If the validation result is successful, the access control application (211) may perform operation 915.

FIG. 10 illustrates a signal flow diagram for data packet transmission of a node according to various embodiments.

Referring to FIG. 10, at operation 1005, the access control application (211) of the node (201) may detect that a network connection is permitted and a data packet transmission event is detected. For example, the access control application (211) may identify the transmission protocol, destination network identification information, port, and application of the data packet being transmitted.

In operation 1010, the access control application (211) can check whether there is a data flow corresponding to the transmission protocol, destination network identification information, port, and application of the data packet. According to an embodiment, if the data flow does not exist or is invalid, the access control application (211) can drop the data packet (operation 1015).

If a data flow exists, at operation 1020, the access control application (211) may determine whether to insert authentication information into the data packet based on the data flow.

If insertion of authentication information is unnecessary, in operation 1030, the access control application (211) can check whether the data packet includes security session identification information (e.g., a security session ID). According to an embodiment, if the security session identification information is included in the data packet, the access control application (211) can update the security session identification information in the data flow (operation 1035) and transmit the data packet (operation 1040).

According to an embodiment, when the security session identification information is updated in the data flow, the access control application (211) of the node (201) can transmit the updated data flow to the controller (202). In this case, the controller (202) can update the data flow table based on the received data flow, and can process the data flow to be removed when the application using the updated data flow in the node (201) is terminated (operation 1050).

If authentication information insertion is required, in operation 1025, the access control application (211) can generate authentication information based on an authentication information generation algorithm and additional information included in the authentication information of the data flow.

In addition, the access control application (211) may encrypt the authentication information with an encryption algorithm and an encryption key included in the authentication information of the data flow. For example, the access control application (211) may generate a data flow header by combining the encrypted authentication information and the identification information of the data flow, and may insert the data flow header into the data packet according to the authentication information insertion method included in the authentication information of the data flow. According to an embodiment, when the transmission protocol is TCP, the access control application (211) may insert the data flow header in front of the payload of a TCP SYN packet. According to an embodiment, when the transmission protocol is UDP, the access control application (211) may insert the data flow header in front of the payload of a UDP data packet.

Once the data flow header insertion is complete, at operation 1040, the access control application (211) can transmit the data packet.

Figure 11 illustrates examples of data packets according to various embodiments.

According to an embodiment, the data packet (1105) may be a TCP data packet or a UDP data packet.

When transmitting TCP-based data packets, the target application must create a TCP session with the destination node before transmitting the actual data packets, and the access control application (211) can insert a data flow header (1120) in front of the payload (1125) of the TCP SYN data packet (1105) for TCP session creation during the 3 Way Handshake process for TCP session creation. For example, the TCP SYN data packet (1105) can include an IP header (1110), a protocol header (1115), a data flow header (1120), and a payload (1125).

Accordingly, the access control application (211) inserts a data flow header (1120) into a TCP SYN data packet (1105) for creating a TCP Session and authenticates it so that a TCP Session is created only for an authenticated target and a TCP Session is not created if not authenticated, thereby providing a more efficient TCP-based data packet control method than the method of inserting authentication information every time a TCP data packet is transmitted.

When transmitting UDP-based data packets, the access control application (211) can manage its own authentication time for UDP since there is no concept of session creation as in TCP.

Based on the authentication information of the data flow received from the controller (202), the access control application (211) transmits the data packet by inserting the data flow header information into the first data packet of the flow of UDP data packets that are continuously transmitted when transmitting UDP-based data packets, and transmits the data packets without inserting the data flow header information for subsequent data packets, or inserts the data flow header into all UDP data packets when strong data packet authentication is required.

The data flow header (1120) may be information inserted by the access control application (211) to determine whether a data packet can be transmitted from the gateway (203) based on authentication information of the data flow received from the controller (202) in the data packet flow between the target application and the destination node.

According to an embodiment, the data flow header (1120) may include data flow identification information (1130) and encrypted authentication information (1135). Additionally, the encrypted authentication information (1135) may be decrypted and used as authentication information (1140) to verify whether the data packet was transmitted from a normal target.

In an IP network, since a data packet has no identifiable information other than 5 Tuple information (protocol, source IP, port, destination IP, and port), it is impossible to know whether a node assigned an IP is actually authenticated and whether an application, which is the actual communication subject, was transmitted by an authorized target. Therefore, in order to confirm that the data packet was transmitted from an authenticated target, an access control application (211) and a gateway (203) can perform basic data packet transmission control using data flow identification information, destination IP, and port information included in a data flow received from a controller (202).

When controlling data packet transmission, the destination node can check whether a corresponding data flow exists based on data flow identification information included in the data flow header, and compare the destination IP and port information included in the data flow information with the destination IP and port information included in the data packet to check whether they are the same, thereby allowing only authenticated targets based on data flow identification information rather than source IP to access the destination network.

In an embodiment, for the UDP protocol, the destination node can check whether the destination is authenticated by inserting it into each data packet or comparing it with the source IP.

In addition, the structure of verifying an authenticated target through a data flow header can provide an effective method in cases where the source IP of a node cannot be specified, such as when a node with mobility connects, when configuring a sub-network using a router, and when controlling the flow of data packets by actual communication subject.

Encrypted authentication information (1135) included in the data flow header (1120) may be used to verify whether the entity that transmitted the data packet, including the data flow identification information (1130), actually transmitted the data packet.

Encrypted authentication information (1135) can only be decrypted by an authenticated target (a target that received the data flow from the controller (202)) based on the encryption/decryption key included in the authentication information of the data flow received from the controller (202).

The decrypted authentication information may be composed of information in the form of an OTP (One-Time Password) and Random Generation that changes at each authentication time, rather than a fixed value at each data packet authentication time, such as data flow identification information. Therefore, the above network structure can solve a problem that occurs when authentication information does not change at each authentication time, when authentication information is encrypted and transmitted, and when the data packet flow is maintained by the data flow received from the controller, because it is transmitted as fixed authentication information.

The network access control application (211) and the gateway or server (210) can generate OTP information that changes at each authentication point based on information for OTP generation and verification included in the authentication information of the data flow, encrypt the value, and transmit a data packet including data flow header information with data flow identification information inserted therein.

FIG. 12 illustrates an operational flow diagram for data packet forwarding of a gateway according to various embodiments.

Referring to FIG. 12, in operation 1205, the gateway (203) may detect a data packet reception event. For example, the gateway (203) may receive a data packet transmitted from the node (201).

In operation 1210, the gateway (203) can check whether there is a data flow corresponding to the 5 Tuples information (source IP, source port, destination IP, destination port, transmission protocol information) of the IP (Internet Protocol) of the received data packet.

If a data flow exists, in operation 1215, the gateway (203) can determine whether NAT (Network Address Translation) needs to be performed based on NAT information for proxy processing included in the data flow.

When NAT is required, the gateway (203) can perform NAT based on proxy information (operation 1220) and forward data packets (operation 1225).

For another example, if NAT performance for proxy processing is not required, the gateway (203) can forward data packets without performing NAT (operation 1225).

In the absence of a data flow, at operation 1230, the gateway (203) can check whether a data packet includes a data flow header.

If a data flow header is included in a data packet, in operation 1235, the gateway (203) can extract the data flow header from the data packet and perform data packet authentication information inspection. For example, the gateway (203) can check whether a data flow corresponding to the data flow identification information included in the data flow header exists. According to an embodiment, if a data flow corresponding to the data flow identification information does not exist or the corresponding data flow is invalid, the gateway (203) can drop the data packet (operation 1245).

If there is a data flow corresponding to the data flow identification information, the gateway (203) can check whether the identified data flow and the destination IP, port, and transmission protocol information of the data packet are the same. According to an embodiment, if the identified data flow and the destination IP, port, and transmission protocol information of the data packet are not the same, the gateway (203) can drop the data packet (operation 1245).

If the identified data flow and the destination IP, port, and transmission protocol information of the data packet are the same, the gateway (203) can perform decryption and authentication information verification based on the authentication information included in the data flow header. According to an embodiment, if decryption or authentication information verification fails, the gateway (203) can drop the data packet (operation 1245).

When the authentication information check is completed, in operation 1260, the gateway (203) can remove the data flow header included in the data packet and update the 5 Tuples information (source IP, source port, destination IP, destination port, transmission protocol information) identified through logical connection authentication to the data flow.

If it is determined in operation 1230 that a data flow header does not exist in a data packet, in operation 1240, the gateway (203) can search for a data flow corresponding to the source IP, destination IP, destination port, and transmission protocol included in the IP header and processed based on a tunnel.

If there is a data flow corresponding to the combined identification information, in operation 1260, the gateway (203) can update the identified 5 Tuples (source IP, source port, destination IP, destination port, transmission protocol information) information to the data flow.

According to an embodiment, if there is no data flow corresponding to the combined identification information, the gateway (203) may drop the data packet (operation 1245).

In operation 1250, the gateway (203) can determine whether NAT (Network Address Translation) is required based on NAT information for proxy processing included in the data flow.

If NAT is required, the gateway (203) can perform NAT based on proxy information (operation 1255) and forward data packets (operation 1265).

For another example, if NAT performance for proxy processing is not required, the gateway (203) may forward data packets without performing NAT (operation 1265). In this case, operation 1255 may be omitted.

FIG. 13 illustrates a signal flow diagram for responding to a request for creating a security session of a gateway according to various embodiments.

Referring to FIG. 13, in operation 1305, the gateway (203) may detect a security session creation request event. For example, the gateway (203) may receive a security session creation request (e.g., responding to the Client Hello procedure when creating a TLS session) from the node (201).

In operation 1310, the gateway (203) can check whether there is a data flow corresponding to the source IP, source port, destination IP, destination port, and transmission protocol information included in the security session creation request information. According to an embodiment, if there is no data flow, the gateway (203) can reject the security session creation request (operation 1360).

If a data flow exists, the gateway (203) can check whether the service access information included in the security session creation request information (e.g., Server Name Indication information, domain address or IP address, host name, etc. included in the TLS session creation information) is permitted. According to an embodiment, if the service access information is not permitted, the gateway (203) can reject the security session creation request (operation 1360).

If a data flow exists but the service access information is not included in the data flow, in operation 1315, the gateway (203) may transmit the service access information and data flow identification information or 5 Tuples information (source IP, source port, destination IP, destination port, transmission protocol information) to the controller (202) and perform a request for whether to allow service access.

At operation 1320, the controller (202) may receive a request to allow a service request.

In operation 1325, the controller (202) can check whether there is a data flow corresponding to the service access permission request information (data flow identification information or source IP, source port, destination IP, destination port, transmission protocol information) received from the gateway (203). According to an embodiment, if there is no valid data flow, the controller (202) can transmit access rejection information to the gateway (203).

If a valid data flow exists, the controller (202) can identify a communication target (node (201), user, application, etc.) through whether service access information is included in harmful domain information and control flow identification information included in the data flow. In addition, the controller (202) can check whether the communication target is accessible through service access information received through the gateway (203) based on a database (e.g., access policy, domain policy, proxy policy).

According to an embodiment, if the domain is included in a harmful domain or access is not possible through policy verification, the controller (202) may return access rejection information to the gateway (203).

If it is not included in a harmful domain and access is possible through policy verification, in operation 1335, the controller (202) can update the service access information received in the data flow to allow access, and transmit the updated data flow information to the gateway (203).

In operation 1340, the gateway (203) may receive a result value from the controller (202). For example, if connection rejection information is returned, the gateway (203) may return a security session creation rejection to the node (201) (operation 1360). In this case, the gateway (203) may update the connection rejection information to the data flow.

When an updated data flow is received, the gateway (203) can store the updated data flow.

If the data flow includes service access permission information or if the service access is allowed through an updated data flow according to the result of a request to the controller (202) to allow service access, in operation 1345, the gateway (203) can check whether there is certificate information for creating a security session corresponding to the service access information.

If there is no certificate information corresponding to the service access information, in operation 1350, the gateway (203) can generate a certificate corresponding to the service access information for creating a secure session based on the certificate information included in the data flow received from the controller (202) and update the generated certificate in the certificate pool of the proxy.

If the certificate information exists, or in operation 1355, a certificate has been created and updated in the certificate pool, the gateway (203) may allow the secure session creation request.

The gateway (203) can update the security session identification information (e.g., TLS Session ID information, etc.) identified during the security session creation request and response process to the data flow. In addition, in operation 1365, the gateway (203) can transmit the updated data flow to the controller (202).

At operation 1370, the controller (202) can update an existing data flow based on the received data flow.

FIG. 14 illustrates a signal flow diagram for disconnection according to various embodiments.

Referring to FIG. 14, at operation 1405, the node (201) may detect at least one of termination of the node (201), termination of the access control application (211), termination of the target application, no longer using the network connection, and a connection termination request based on information identified from the linking system. In this case, at operation 1410, the node (201) or the access control application (211) may request the controller (202) to remove the control flow.

In operation 1415, the controller (202) may remove the identified control flow based on the received control flow identification information.

At operation 1420, the controller (202) can remove all data flows dependent on the removed control flow. Accordingly, the node (201) can no longer access the destination network based on the removed data flow.

In operation 1425, the controller (202) can perform a removal request for all data flows dependent on the removed control flow to the gateway (203). The gateway (203) can remove the data flow, and thus, data packets corresponding to the source network, destination network, and port information included in the removed data flow can no longer be transmitted.

FIG. 15 illustrates a signal flow diagram for control flow update according to various embodiments.

Referring to FIG. 15, at operation 1505, the access control application (211) may detect a control flow update event.

In operation 1510, the access control application (211) may request the controller (202) to update the control flow based on the control flow identification information.

In operation 1515, the controller (202) can check whether a control flow exists in a control flow table (e.g., a control flow table (315) of FIG. 3) based on the received control flow identification information. According to an embodiment, if a control flow does not exist (e.g., a case where the connection is disconnected by another security system, a case where the connection is disconnected due to self-risk detection, etc.), the controller (202) can transmit a connection failure result to the connection control application (211) because the connection of the node (201) is invalid (operation 1520).

The controller (202) can update the update time if a control flow exists in the control flow table (e.g., the control flow table (315) of FIG. 3). In this case, the controller (202) can transmit identification information of the updated control flow to the access control application (211) (operation 1520).

In one embodiment, the controller (202) may transmit information about a data flow that is dependent on an identified control flow and that requires re-authentication or is no longer accessible to the access control application (211) (operation 1520).

In operation 1525, the access control application (211) of the node (201) can process the result value for the response received from the controller (202). For example, the access control application (211) can block all network connections of the application if the result of the control flow update is impossible. For another example, the access control application (211) can update the data flow if the result of the control flow update is normal and the updated data flow information exists.

Figure 16 illustrates a signal flow diagram for terminating application execution according to various embodiments.

Referring to FIG. 16, in operation 1605, the access control application (211) of the node (201) can check in real time whether the running application has been terminated and detect an application execution termination event.

According to an embodiment, the access control application (211) can check whether there is a data flow corresponding to terminated application identification information and PID (Process ID and Child Process ID Tree) information.

In operation 1610, the access control application (211) may perform a data flow removal request to the controller (202). For example, the access control application (211) may transmit identification information of a terminated application or identification information of a data flow corresponding to a terminated application to the controller (202) and perform the data flow removal request.

In operation 1615, the controller (202) can delete the data flow for which removal is requested. In addition, the controller (202) can perform a removal request for the removed data flow to the gateway (203) (operation 1620). The gateway (203) can remove the data flow, and thus, data packets corresponding to the source network, destination network, and port information included in the removed data flow can no longer be transmitted.

The above description is merely an example 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 belong 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 (9)

At the gateway,
Communication circuits; memory; and
A processor operatively connected to the above communication circuit and the above memory, the processor comprising:
Receive a data packet from a node and verify the tuple information of the data packet or the data flow authentication information included in the data packet,
If there is a data flow corresponding to the above tuple information or the above data flow authentication information, it is checked whether NAT for proxy processing is necessary based on the NAT (Network Address Translation) information included in the data flow and for forwarding data packets to the proxy.
If NAT is required for the above proxy processing, NAT is performed on the data packet based on the NAT information,
Update the above tuple information to the above data flow,
Forwarding data packets on which the above NAT has been performed to a proxy, or
If NAT is not required for the above proxy processing, the data packet is forwarded to the service server,
When performing NAT on the above data packet, the tuple information before performing NAT and the tuple information after performing NAT are updated in the above data flow,
The proxy included in the above gateway identifies the data flow based on the tuple information before performing the NAT and the tuple information after performing the NAT.
A gateway configured to forward the data packets to the service server if NAT performance for the above proxy processing is not required. In paragraph 1,
The above data flow is a data flow authorized from an external server.
The above NAT information is determined by the external server based on policy, depending on whether a proxy must be used to access the service server through the gateway. In the first paragraph, the processor
If there is no data flow corresponding to the above tuple information, check the IP header of the data packet,
Check whether there is a data flow that corresponds to the above IP header and is processed based on a pre-created tunnel authorized from an external server,
A gateway configured to perform NAT of the data packet based on NAT information of the data flow processed based on the tunnel and to forward the data packet based on a proxy. In the third paragraph, the processor,
When performing NAT on the above data packet, the tuple information before performing NAT and the tuple information after performing NAT are updated in the above data flow,
A gateway wherein the proxy included in the gateway is configured to identify the data flow based on tuple information before performing the NAT and tuple information after performing the NAT. In the third paragraph, the processor,
A gateway configured to update the tuple information in the data flow and forward the data packet to the service server when NAT performance is not required based on NAT information of the data flow processed based on the tunnel. In the first paragraph, the processor,
Receive a request for creating a secure session from the above node, wherein the request for creating a secure session includes second tuple information and service access information,
Check whether there is a data flow from an external server corresponding to the second tuple information above,
If the above data flow exists, it is configured to determine whether the service access information is permitted based on the above data flow and whether a security session can be created.
The above service access information includes at least one of server name indication information, domain address, IP address, or host name included in the session creation information. In the sixth paragraph, the processor,
If the above data flow does not exist, the second tuple information and the service connection information are transmitted to the external server and a request for permission to access the service is made.
configured to receive an updated data flow from the external server and determine whether the secure session can be created;
The above updated data flow is the gateway, which is the information updated by the external server to allow access with the above service access information. In the sixth paragraph, the processor,
Check whether the above data flow includes certificate information for creating a security session corresponding to the above service access information,
Based on the above certificate information, a certificate is created for creating the above security session corresponding to the above service access information,
A gateway configured to create a secure session with the above node once certificate generation is complete. In terms of how the gateway operates,
An operation of receiving a data packet from a node and verifying tuple information of the data packet or data flow authentication information included in the data packet;
If there is a data flow corresponding to the above tuple information or the above data flow authentication information, an operation of checking whether NAT (Network Address Translation) for proxy processing is necessary based on NAT information included in the data flow and for forwarding data packets to a proxy;
If NAT is required for the above proxy processing, an operation of performing NAT on the data packet based on the NAT information;
An action of updating the above tuple information in the above data flow;
Forwarding data packets on which the above NAT has been performed to a proxy, or
If NAT performance for the above proxy processing is not required, an action of forwarding the data packet to the service server;
When performing NAT on the above data packet, an operation of updating the tuple information before performing NAT and the tuple information after performing NAT in the data flow;
The proxy included in the above gateway identifies the data flow based on the tuple information before performing the NAT and the tuple information after performing the NAT;
If NAT performance for the above proxy processing is not required, an operation of forwarding the data packet to the service server;
How the gateway works.

Images