KR102613414B1 - System for controlling network access and method of the same - Google Patents

Abstract

A gateway according to an embodiment disclosed in this document includes a communication circuit, a memory, and a processor operatively connected to the communication circuit and the memory, wherein the processor receives a data flow from an external server, and the data flow is Contains information related to whether the node that made the network connection request to the external server can be connected and certificate information related to whether a secure session can be created, receives a secure session creation request from the node, and responds to the secure session creation request. Check the existence of a data flow, and if a data flow corresponding to the secure session creation request exists, check whether the secure session creation request is valid based on the certificate information included in the data flow, and the secure session is created. Once created, it may be configured to process service processing requests received from the node based on the secure session.

Description

System for controlling network access and method related thereto {SYSTEM FOR CONTROLLING NETWORK ACCESS AND METHOD OF THE SAME}

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

Multiple devices can communicate data over a network. For example, a terminal can transmit or receive data to and from a server via the Internet. Networks may include public networks such as the Internet as well as private networks such as intranets.

The terminal communicates with the server using IP (Internet Protocol)-based TCP (Transmission Control Protocol) or UDP (User Datagram Protocol), and is used to control the connection between the source IP and destination IP authorized by TCP or UDP technology. Firewall technology may be used. In the case of IP communication, because data packets are transmitted in plain text, there is a problem that a third party can easily view important information in the data packet using sniffing technology such as tapping equipment or rouge WiFi. To solve this problem, VPN (Virtual Private Network) technology and tunneling technology are used to encrypt data packets between the terminal and the server.

Because tunneling technology uses different tunneling technologies and related standards depending on the service server, the scope may be limited to controlling only network access dependent on a specific network or service. In addition, since tunneling technology requires setting up a wide network band, it may be difficult to control communication at the unit of each application running in the terminal and the service server to which the application wants to access.

To compensate for these shortcomings of tunneling technology, secure session technology that can ensure safe communication more easily and conveniently than tunneling can be considered. For example, protocols such as Transport Layer Security (TLS), Secure Sockets Layer (SSL), Datagram Transport Layer Security (DTLS), Mutual Transport layer Security (MTLS), or Hyper Text Transfer Protocol over Secure Socket Layer (HTTPS). Secure session technology may be applied.

In secure session technology, the terminal and the service server must perform session creation and negotiation procedures in advance, but due to the nature of IP communication based on OSI (Open Systems Interconnection) 7 layer, the target requesting communication (e.g. the terminal or Since there is no way to check whether an application) is a pre-authorized and safe target, it is difficult to block unauthorized targets at the network level (i.e., OSI layer 7). The service server can block access from targets that do not meet the authentication conditions, but this method is possible after a TCP session or security session has already been created or a service protocol access procedure (e.g. HTTP) has been performed, so this method alone is not permitted. It is impossible to fundamentally block or disable network access of unauthorized targets, and attackers can launch DoS (Denial of Service) attacks through well-known protocols such as HTTPS and open ports. Furthermore, if the security function included in the terminal's application is not executed or if a risk element exists in the application, there is no way to block the detected threat while connected to the network even if the terminal or the network detects it.

In addition, when a security session is created between a terminal and a service server, encrypted data packets are sent using filtering-based security technologies (e.g., IDS (Intrusion Detection System), IPS (Intrusion Prevention System), NGFW (Next Generation System) that exist at the network boundary of the service server. Problems may arise where Firewall) cannot be used.

In the case of mobile terminals, because the source IP continuously changes due to handover, a problem may occur where the gateway blocks data packet transmission based on the source IP. In other words, in the case of terminals with frequent handovers, a problem may arise where network connection authentication is required every time the IP is changed.

In addition, when creating a security session for the first time, only applications authorized through the authentication process can create a secure session. However, since it is unknown which application the security session was actually matched with and authorized, the security session is immediately terminated when the application is terminated. There is no way to do it.

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

A gateway according to an embodiment disclosed in this document includes a communication circuit, a memory, and a processor operatively connected to the communication circuit and the memory, wherein the processor receives a data flow from an external server, and the data flow is Contains information related to whether the node that made the network connection request to the external server can be connected and certificate information related to whether a secure session can be created, receives a secure session creation request from the node, and responds to the secure session creation request. Check the existence of a data flow, and if a data flow corresponding to the secure session creation request exists, check whether the secure session creation request is valid based on the certificate information included in the data flow, and the secure session is created. Once created, it may be configured to process service processing requests received from the node based on the secure session.

In the gateway according to an embodiment disclosed in this document, it includes a communication circuit, a memory, and a processor operatively connected to the communication circuit and the memory, wherein the processor receives a data flow from an external server, and The flow includes information related to whether the node that made the network connection request to the external server can be connected, certificate information related to whether a secure session can be created, creates a secure session with the node based on the certificate information, and creates the security session. When receiving a service request from the node for which session creation has been completed, the service server receiving the service request may be configured to insert the identification information of the node into the service request and transmit it to the service server so that the service server can identify the node. there is.

A service server according to an embodiment disclosed in this document includes a communication circuit, a memory, and a processor operatively connected to the communication circuit and the memory, wherein the processor receives a data flow from an external server, and stores the data. The flow includes information related to whether the node that made the network connection request to the external server can be connected and certificate information related to whether a secure session can be created, receives a secure session creation request from the node, and receives the secure session creation request. Check the existence of a data flow corresponding to, and if a data flow corresponding to the secure session creation request exists, check whether the secure session creation request is valid based on the certificate information included in the data flow, and Once a session is created, it may be configured to process service processing requests received from the node based on the secure session.

A method of operating a gateway according to an embodiment disclosed in this document includes receiving a data flow from an external server, the data flow including information related to the connection availability of the node that made a network connection request to the external server and creating a security session. Contains certificate information related to availability, and includes an operation of receiving a secure session creation request from the node, an operation of checking the existence of a data flow corresponding to the secure session creation request, and a data flow corresponding to the secure session creation request. If present, an operation is performed to check whether the security session creation request is valid based on the certificate information included in the data flow, and when a security session is created, the service processing request received from the node is processed based on the security session. It may include actions such as:

A method of operating a gateway according to an embodiment disclosed in this document includes an operation of receiving a data flow from an external server, and the data flow determines whether a node that has made a network connection request to the external server can be connected. information related to, certificate information related to whether or not a secure session can be created, an operation of creating a secure session with a node based on the certificate information, upon receiving a service request from the node for which the secure session creation has been completed, sending a service request. It may include inserting identification information of the node into the service request and transmitting it to the service server so that the receiving service server can identify the node.

According to embodiments disclosed in this document, a system for controlling network access provides a method by which only authorized subjects can access the network based on a security session, and can block data packet transmission by unauthorized subjects.

According to embodiments disclosed in this document, a system for controlling network access provides a method for detection of threats and disconnection of invalid targets, and clarifies the ambiguous network connection release point between the application and the service server. Life cycle management can be facilitated.

According to embodiments disclosed in this document, a system for controlling network access prevents DoS attacks and brute force attacks through service resource access by blocking data packets transmitted by unauthorized entities through a gateway. You can.

According to embodiments disclosed in this document, a system for controlling network access solves the problems inherent in existing IP communication by implementing a secure network connection life cycle ranging from network access control, threat blocking, and isolation of applications. It can solve the problem and provide a secure network connection.

According to embodiments disclosed in this document, a system for controlling network access can control data transmission at the transport layer more easily and in detail than tunneling technology that protects data packets over a wide network range.

According to embodiments disclosed in this document, a secure session with a gateway or server can be created without the need for individual modification for each application that wants to connect to the service server.

According to the embodiments disclosed in this document, it is possible to identify which application created a secure session with the service server, so that when the application is terminated, the secure session can be terminated immediately.

Additionally, according to embodiments disclosed in this document, when an application transmits a data packet without a security session being created or when the transmitted security session identification information is different from the security session identification information collected from the destination network, a rogue security session is established. The network connection can be terminated immediately by determining whether it goes through a proxy server, and when the application is terminated, the security session can be immediately removed to prevent communication with the destination network using previously authenticated security session information.

Additionally, according to the embodiments disclosed in this document, it is possible to solve the round trip problem in which security sessions created at nodes and gateways must be inspected and the inspection results must be verified through a controller.

In addition, according to the embodiments disclosed in this document, each communication target application of the node sets or stores a certificate issued by the controller in advance, so that the controller can partially trust the communication target application. When attempting to connect to a destination gateway or server, the round trip problem can be resolved by passing the certificate information for creating a secure session and creating a secure session with the connection target permitted to access the network based on the certificate. It can provide technology that can additionally support applications that are issued and used in advance.

Additionally, according to the embodiments disclosed in this document, when the gateway returns a service request result, the header information is removed and transmitted, thereby solving the problem of the node interpreting the header information and using it for malicious purposes.

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

Figure 1 shows an environment including multiple networks.
2A and 2B illustrate architecture within a network environment according to various embodiments.
3 is a functional block diagram showing a database stored in a controller according to various embodiments.
Figure 4 shows a functional block diagram of a node according to various embodiments.
5A and 5B illustrate an operation for controlling transmission of data packets according to various embodiments.
Figure 6 shows a signal flow diagram for controller connection according to various embodiments.
7 shows a signal flow diagram for user authentication according to various embodiments.
Figure 8 shows a signal flow diagram for network access according to various embodiments.
9 shows an operational flowchart for receiving data packets according to various embodiments.
FIG. 10 illustrates an operation flowchart for creating a secure session according to various embodiments.
11 illustrates an operational flowchart for service request processing according to various embodiments.
12 shows an example of a service request according to various embodiments.
Figure 13 shows an operation flowchart for receiving a service request result according to various embodiments.
Figure 14 shows a signal flow diagram for control flow update according to various embodiments.
15 shows a signal flow diagram for disconnection according to various embodiments.
Figure 16 shows a signal flow diagram for terminating application execution according to various embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS Various embodiments of the present invention are described below with reference to the accompanying 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 to the embodiments of the present invention.

In this document, the singular form of a noun corresponding to an item may include one or plural items, unless the relevant context clearly indicates otherwise. In this document, “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 “A, Each of phrases such as “at least one of B, or C” may include any one of the items listed together in the corresponding phrase, or any possible combination thereof. Terms such as "first", "second", or "first" or "second" may be used simply to distinguish one component from another, and to refer to that component in other respects (e.g., importance or order) is not limited. One (e.g., first) component is said to be “coupled” or “connected” to another (e.g., second) component, with or without the terms “functionally” or “communicatively.” When mentioned, it means that any of the components can be connected to the other components directly (e.g. wired), wirelessly, or through a third component.

Each component (eg, module or program) described in this document may include singular or plural entities. According to various embodiments, one or more of the corresponding components or operations may be omitted, or one or more other components or operations may be added. Alternatively or additionally, multiple components (eg, modules or programs) may be integrated into a single component. In this case, the integrated component may perform one or more functions of each component of the plurality of components in the same or similar manner as those performed by the corresponding component of the plurality of components prior to the integration. . According to various embodiments, operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, or omitted. Alternatively, one or more other operations may be added.

The term “module” 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 integrated part or a minimum unit of the parts or a part thereof that performs one or more functions. For example, according to one embodiment, the module may be implemented in the form of an application-specific integrated circuit (ASIC).

Various embodiments of this document may be implemented as software (e.g., a program or application) including one or more instructions stored in a storage medium (e.g., memory) that can be read by a machine. For example, the processor of the device may call at least one instruction among one or more instructions stored from a storage medium and execute it. This allows the device to be operated to perform at least one function according to the at least one instruction called. The one or more instructions may include code generated by a compiler or code that can be executed by an interpreter. A storage medium that can be read by a device 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 contain signals (e.g. electromagnetic waves), and this term refers to cases where data is semi-permanently stored in the storage medium. There is no distinction between temporary storage cases.

Methods according to various embodiments disclosed in this document may be provided and included in a computer program product. Computer program products are commodities and can be traded between sellers and buyers. A computer program product may be distributed in the form of a machine-readable storage medium (e.g. compact disc read only memory (CD-ROM)) or through an application store or between two user devices (e.g. smartphones). It may be distributed in person or online (e.g., downloaded or uploaded). In the case of online distribution, at least a portion of the computer program product may be at least temporarily stored or temporarily created in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store server, or a relay server.

Figure 1 shows 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 FIG. 1 and the embodiments described below, the 'source node' may be various types of devices capable of performing data communication. For example, the source node 101 may be a portable device such as a smartphone or tablet, a computer device such as a desktop or laptop, a multimedia device, a medical device, a camera, a wearable device, or a virtual reality (VR) device. , or home appliances and is not limited to the above-mentioned devices. For example, the source node 101 may include a server or gateway that can transmit 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 the same or similar device as the above-described source node 101. As another example, the destination node 102 may be substantially the same as the destination network.

The source node 101 may attempt to access the second network 20 and transmit data to the destination node 102 included in the second network 20. The source node 101 may transmit data to the destination node 102 through the gateway 103.

If the connection 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, and therefore the source node 101 is malicious. ) may be exposed to program attacks. For example, the source node 101 may be infected with malicious code 110c, as well as trusted and/or secure applications such as Internet web browsers 110a and business applications 110b. ) It is possible to receive data from untrusted or unsecured applications, such as the business application 110d.

The source node 101 infected by a malicious program may attempt to connect to the second network 20 and/or transmit data. If the second network 20 is formed based on IP, such as a VPN, it may be difficult for the second network 20 to individually monitor a plurality of devices included in the second network 20, and application at the OSI layer may be difficult. Security at the layer or transport layer may be vulnerable. Additionally, if the source node 101 includes a malicious application after the channel has already been created, the data of the malicious application will be transmitted to another electronic device (e.g., the destination node 102) within the second network 20. You can.

2A and 2B illustrate architecture within a network environment according to various embodiments.

Referring to FIG. 2A, the node 201 may be various types of devices capable of performing data communication. As another example, the node 201 may be a portable device such as a smartphone or tablet, a computer device such as a desktop or laptop, a multimedia device, a medical device, a camera, a wearable device, or a virtual reality (VR) device. , or home appliances and is not limited to the above-mentioned devices. For example, node 201 may include a server or gateway that can transmit data packets through an application. Node 201 may also be referred to as an ‘electronic device’ or a ‘terminal’.

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

Controller 202 may be, for example, a server (or cloud server). The controller 202 can ensure reliable data transmission within a network environment by managing data transmission between the node 201, the gateway 203, and the service server 205. For example, the controller 202 may allow the authorized node 201 (or the access control application 211) to access the network through policy information or blacklist information. The controller 202 may provide information that allows a secure session to be created between the node 201 and the gateway 203. Accordingly, the access control application 211 of the node 201 can prevent unauthorized applications from transmitting data packets for unauthorized purposes, and allows data packets to be transmitted through the security session created with the gateway 203. It is possible to provide a structure that can only be transmitted to the service server 205. Additionally, the controller 202 may be connected to the harmful application inspection system 206 to provide a structure to check whether a harmful application exists.

Depending on the embodiment, the network connection of the target application 212 may be blocked from the access control application 211, the controller 202, or the gateway 203. According to one embodiment, the controller 202 is a connection control application (e.g., registration, approval, authentication, renewal, termination) to perform various operations associated with the network connection of the node 201 or the access control application 211. 211) and control data packets can be transmitted and received. The flow through which control data packets are transmitted (e.g., 220) may be referred to as a 'control flow'. According to the embodiment, the controller 202 maintains a secure network state at all times by immediately retrieving a security session according to a security event received from an interconnected system (e.g., node 201, gateway 203, or service server 205). You can.

The gateway 203 may be located at the border of the network to which the node 201 belongs or the border of the network to which the service server 205 belongs. According to one embodiment, the gateway 203 may be connected to the controller 202 on a cloud basis. According to an embodiment, the gateway 203 may relay communication with the service server 205 through the proxy 213 for data packets received through an authorized security session, and the service server 205 may transmit data packets received through an authorized security session from an authenticated target. A structure can be provided to process received service requests. According to the 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'. Data flows can be created at a node or IP level, as well as at more granular units (e.g. applications).

According to an embodiment, the gateway 203 may include a proxy, and the proxy may process a secure session creation request of the node 201 based on certificate information generated by the controller 202.

According to the embodiment, the connectivity control technology utilizing a secure session creates a secure session with the gateway 203 in order for the target application 212 to access the service server 205, and controls the connection existing in the node 201. The application 211 can prevent unauthorized applications from transmitting data packets to unauthorized destinations, and transmits only permitted data packets to the service server 205 through a security session created between the gateways 203. It can provide structure.

According to the embodiment, even after network access is permitted by the controller 202, the target application 212 of the node 201 cannot transmit a service request unless a secure session is created with the gateway 203, and network access is permitted. and a service request can be transmitted to the gateway 203 only when a secure session is created.

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

Referring to FIG. 2B, the target application 212 stored in the node 201 can create a secure session with the service server 205 without going through a gateway.

According to an embodiment, the service server 205 may include a proxy, and the proxy may process a secure session creation request of the node 201 based on certificate information generated by the controller 202.

According to the embodiment, the connectivity control technology utilizing a secure session creates a secure session with the service server 205 in order for the target application 212 to access the service server 205, and creates a connection existing in the node 201. The control application 211 may prevent unauthorized applications from transmitting data packets or service requests to unauthorized destinations, and only allow data packets or service requests through the security session created with the service server 205. A structure for transmitting to the service server 205 can be provided.

According to the embodiment, the target application 212 of the node 201 cannot transmit a service request unless a secure session is created with the service server 205, even after network access is permitted by the controller 202, and the network connection is blocked. A service request can be transmitted to the service server 205 only when permitted and a secure session is created.

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

The administrator can access the controller 202 and set a connection-oriented policy to control the connection between the access control application 211 and the service server 205, so network access is more detailed and safer than managing sessions at the service level. can be controlled.

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

The security session policy database 312 is a gateway (e.g., the service server 205 in FIG. 2A or FIG. 2B) that exists between the service servers (e.g., the service server 205 in FIG. 2A or FIG. 2B) on the connection path according to the policy. Gateway (203)) information may be included. For example, the security session policy database 312 may include certificate information related to whether a secure session is possible for a connection target application (eg, target application 212). According to an embodiment, the certificate information may be information issued in advance by the target application 212 to create a secure session with the gateway 203 or the service server 205.

The blacklist policy database 313 is a target (e.g., node ID ( identifier), an IP address, a media access control (MAC) address, or a user ID). Additionally, the blacklist policy database 313 can be used as information to determine the risk level of an application according to the application inspection results and whether to temporarily or permanently isolate it depending on the risk level.

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

The control flow table 315 is an example of a session table for managing the flow (eg, control flow) of control data packets generated between the node 201 and the controller 202. When successfully connecting to the controller 202, control flow information may be generated by the controller 202. The control flow information may include at least one of control flow identification information, an IP address identified when connecting to and authenticating the controller, a node ID, or a user ID. For example, when connection to the service server 205 is requested from the node 201, the controller 202 can retrieve control flow information through the control flow identification information received from the node 201, and the retrieved control flow Whether the node 201 can connect to the service server 205 by mapping at least one of the IP address, node ID, or user ID included in the information to the connection policy database 311, data flow for data packet transmission You can determine (decide) whether to create it or not.

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 within a certain period of time, the control flow (or control flow information) may be removed. Additionally, if it is determined that immediate connection blocking is necessary according to security events collected from the node 201, the controller 202 may remove the control flow according to the node 201's connection termination request. When the control flow is removed, the previously created data flow is also removed, so the connection to the node 201 may be blocked.

The data flow table 316 is a table for managing the flow (eg, data flow) in which detailed data packets are transmitted between the node 201, the gateway 203, and the service server 205. Data flows can be created by TCP sessions, applications, or more granular units. The data flow table 316 may include data flow information for managing security sessions of the application (eg, target application 212) of the node 201, the gateway 203, and the service server 205. The data flow table 316 may include an application ID, destination IP address, and/or service port to identify whether the data packet transmitted from the source is an authorized data packet. The data flow table 316 can be managed based on control flow ID.

In addition, the data flow table 316 may include status information including authorized target information for determining whether to forward a data packet based on the source IP and destination IP and port information of the data packet, and whether the data flow is valid. You can. According to an embodiment, the data flow table 316 may further include information indicating whether a channel has been created between the application and the gateway 203.

According to the embodiment, the data flow table 316 is issued in advance to process a secure session creation request from an authorized connection target (e.g., node 201, target application 212, or access control application 211, etc.) One more certificate information may be included.

According to an embodiment, the data flow table 316 may further include security session information including whether a secure session has been created between the target application 212 and the gateway 203 or the service server 205 and security session identification information. You can.

According to an embodiment, the data flow table 316 may include service information. For example, service information includes service IP and port information that permitted access targets can access through proxy, protocol information (e.g. HTTP, FTP, IoT-specific protocol, etc.), whether service request filtering is necessary, and service request filtering processing method. , may include filtering information (e.g. personal information, harmful service request information). In addition, the service information is a series of information to block unnecessary or dangerous service requests in advance at the proxy, and when QoS (Quality of Service) for service requests is required, the number of service requests available in a certain time unit is set. Accordingly, the proxy may include a series of information to adjust the number of service requests. According to the embodiment, service information may be created based on the service policy 317.

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

The service policy database 317 is a connection target (e.g., a node or a connection relay application) that can connect through a proxy (e.g., a proxy included in the gateway 203 or the service server 205) according to the connection policy 311. It may include service IP, port information, and protocol information (e.g. HTTP, FTP, IoT-specific protocols, etc.). According to an embodiment, the service policy database 317 includes whether service request filtering is necessary, a service request filtering processing method, and filtering information (e.g., personal information, harmful service request information), and removes unnecessary or dangerous information from the proxy in advance. It may contain a set of information to block service requests. According to the embodiment, when QoS (Quality of Service) for a service request is required, the service policy database 317 sets the number of service requests possible in a certain time unit and configures the number of service requests in the proxy accordingly. may include information.

The security session table 318 may include identification information of a secure session created between the node 201 and the gateway 203 or service server 205. For example, the controller 202 may determine whether a secure session has been created between the node 201 and the gateway 203 or the service server 205 based on the security session table 318. In addition, the security session table 318 is a table for managing security sessions created between the node 201 and the gateway 203 or service server 205, and manages and identifies the security session when a valid security session exists. It may be composed of security session identification information for controlling the gateway 203 and the controller 202, a control flow ID for control between the gateway 203 and the controller 202, and additional information for managing the security session algorithm and type, encryption level, etc.

Figure 4 shows a functional block diagram of a node according to various embodiments.

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

According to an embodiment, the structure shown in FIG. 4 may be equally included in the gateway 203 or service server 205 of FIG. 2A.

The processor 410 can control the overall operation of the node. In various embodiments, the processor 410 may include one processor core (single core) or may include a plurality of processor cores. For example, the processor 410 may include multi-core, such as dual-core, quad-core, or hexa-core. Depending on embodiments, the processor 410 may further include a cache memory located internally or externally. Depending on 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 a portion of processor 410 is electrically or operatively coupled to other components within the node (e.g., memory 420, communication circuitry 430, or display 440). It can be (coupled with) or connected to. The processor 410 may receive commands from other components of the node, interpret the received commands, and perform calculations or process data according to the interpreted commands. The processor 410 may interpret and process messages, data, commands, or signals received from the memory 420, the communication circuit 430, or the display 440. Processor 410 may generate new messages, data, instructions, or signals based on received messages, data, instructions, or signals. Processor 410 may provide processed or generated messages, data, instructions, or signals to memory 420, communication circuit 430, or display 440.

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

The memory 420 may store commands for controlling nodes, 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.

Memory 420 may include one or more of volatile memory or non-volatile memory. Volatile memory includes dynamic random access memory (DRAM), static RAM (SRAM), synchronous DRAM (SDRAM), phase-change RAM (PRAM), magnetic RAM (MRAM), resistive RAM (RRAM), and ferroelectric RAM (FeRAM). It can be included. 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 uses non-volatile media such as a hard disk drive (HDD), solid state disk (SSD), embedded multi media card (eMMC), and universal flash storage (UFS). More may be included.

According to one embodiment, the memory 420 may store the target application 212 and the access control application 211 of FIG. 2A or 2B. The connection control application 211 may perform control flow creation and update functions with the controller 202. To this end, 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 included in the controller's memory (eg, memory 330 in FIG. 3). For example, memory 420 may store data flow table 316 described in FIG. 3 .

Communication circuitry 430 establishes a wired or wireless communication connection between a node and an external electronic device (e.g., controller 202, gateway 203, or service server 205 of FIG. 2A or FIG. 2B), and supports the established connection. It can support communication through According to one embodiment, the communication circuit 430 may be a wireless communication circuit (e.g., a cellular communication circuit, a short-range wireless communication circuit, or a global navigation satellite system (GNSS) communication circuit) or a wired communication circuit (e.g., a local area network (LAN) ) communication circuit, or power line communication circuit), and using the corresponding communication circuit, a short-range communication network such as Bluetooth, WiFi direct, or IrDA (infrared data association) or a long-distance communication such as a cellular network, the Internet, or a computer network It can communicate with external electronic devices through a network. The various types of communication circuits 430 described above may be implemented as one chip or may be implemented as separate chips.

The display 440 can output content, data, or signals. In various embodiments, the display 440 may display image data processed by the processor 410. Depending on embodiments, the display 440 may be configured with an integrated touch screen by being combined with a plurality of touch sensors (not shown) capable of receiving touch input, etc. When the display 440 is configured as a touch screen, a plurality of touch sensors may be placed above the display 440 or below the display 440.

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

A gateway (e.g., gateway 203 in FIG. 2A) and a service server (e.g., service server 205 in FIG. 2b) according to an embodiment include a processor 410, a memory 420, and a communication circuit 430. It can be included. The processor 410, memory 420, and communication circuit 430 included in the gateway may be substantially the same as the processor 410, memory 420, and communication circuit 430 described above.

5A and 5B illustrate an operation for controlling transmission of data packets according to various embodiments.

Referring to FIG. 5A, the access control application 211 detects a network connection request to the service server 205 from the target application 212 included in the node 201, and connects the node 201 or the access control application 211. ) can be determined whether it 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 may block the transmission of data packets in the kernel or network driver that includes the operating system. there is. Through the access control application 211, the node 201 can block access of malicious applications in advance at the application layer of the OSI layer.

According to the embodiment, in order for the target application 212 to create a secure session with the gateway 203 and control data transmission and reception with the service server 205, the proxy included in the gateway 203 is the target application 212. Based on the certificate information included in the transmitted secure session creation request and the certificate information received from the controller 202, it can be confirmed whether the request for secure session creation is from an authorized target. Accordingly, the gateway 203 may reject the creation of a secure session if it is not a request for creation of a secure session from an authorized target, and the target application 212 for which a secure session has not been created may access the network based on the controller 202. Even if this is possible, data packets or service requests may not be transmitted. That is, according to the embodiments disclosed in this document, the gateway 203 requests the creation of a secure session using a stolen certificate, or requests the creation of a secure session using an incorrect certificate, based on the certificate. Since the creation of a security session can be controlled and communication with the service server 205 without a security session is blocked, a more secure network environment can be provided through two-stage network access control.

When the access control application 211 is not connected to the controller 202, or when the data packet or service request to be transmitted is a data packet or service request that must be transmitted based on a security session, but the corresponding security session does not exist. In this case, the data packet or service request 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 the embodiment, if the access control application 211 is not installed on the node 201 or a malicious application bypasses the control of the access control application 211, an unauthorized data packet or service request is transmitted from the node 201. It can be. In this case, the gateway 203 located at the border of the network blocks data packets or service requests for which a corresponding security session does not exist, so data packets or service requests transmitted from the node 201 (e.g., for creating a TCP session) data packet) may not reach the service server 205. In other words, the node 201 may be isolated from the service server 205.

Referring to FIG. 5B, the service server 205 can directly control the data packets or service requests of the node 201 without the gateway 203 of FIG. 5A. For example, if the network connection of the target application 212 is not authorized by the controller 202, the service server 205 may block the data packet or service request of the target application 212. In addition, if the target application 212's request for creating a secure session is not a request based on a certificate authorized by the controller 202, the service server 205 rejects the request for creating a secure session, thereby sending the data packet of the target application 212 Alternatively, service requests can be blocked.

Figure 6 shows a signal flow diagram for controller connection according to various embodiments.

Since the node 201 needs to be authorized by the controller 202 to connect to or receive the network, the access control application 211 of the node 201 requests the controller 202 to create a control flow, thereby establishing the node ( 201), you can try to connect to the controller. According to an embodiment, the node 201 may be substantially the same as the node 201 of FIG. 2A or 2B on which the access control application 211 is installed.

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

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

In operation 610, the controller 202 may identify whether the object requesting controller connection (e.g., the access control application 211 or the node 201) can be connected. According to one embodiment, the controller 202 determines whether information received from the node 201 is included in the connection policy database 311 or determines whether the node 201, the network to which the node 201 belongs, and/or the connection It is possible to check whether the object requesting controller access can be connected based on at least one of whether the identification information of the control application 211 is included in the blacklist database 314.

If a connection is available, at operation 615 the controller 202 may create a control flow between the node 201 (or the connection control application 211) and the controller 202. In this case, the controller 202 generates control flow identification information in the form of a random number and stores the 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 may be used for user authentication of the node 201, update of information of the node 201, confirmation of policy for network connection of the node 201, and/or validation.

In operation 620, the controller 202 based on the access policy database 311 and the channel policy database 312 corresponding to the identified information (e.g., node 201, source network information to which node 201 belongs). You can create whitelist information of accessible applications. Depending on the embodiment, the controller 202 has destination network information to which the current connection requesting node 201 can basically connect based on the identified information, the connection policy database 311, and the security session policy database 312. You can check if it does. In one embodiment, the controller 202 may transmit the application white list to the connection control application 211 in operation 625.

In operation 625, the controller 202 may transmit control flow identification information to the node 201 in response to the controller connection request. Depending on the embodiment, if the object requesting controller connection is unconnectable or included in the blacklist, the controller 202 may transmit unconnection information in operation 625 without generating a control flow. In one embodiment, the controller 202 may transmit the application white list created through operation 620 to the access control application 211.

In operation 630, the access control application 211 may perform a check on the application. For example, the access control application 211 may perform a check on applications based on a white list of accessible applications received from the controller 202. The access control application 211 can check whether an application exists (installed) on the node 201 based on accessible application information, and determines the integrity and safety of the existing application (whether the application has been forged or modified, whether the code has been used). A test related to at least one of an innings test and a fingerprint test may be performed.

In operation 635, the access control application 211 may transmit the test result to the controller 202. For example, the access control application 211 transmits to the controller 202 the results of performing a check related to the integrity and safety of the application (at least one of application forgery, code signing check, and fingerprint check). You can.

At operation 640, the controller 202 may perform data flow processing. For example, the controller 202 may check whether the application is valid based on the received application inspection result, and if the application is valid, establish an access policy 311 to allow the node 201 connected to the network to access the network. and a source IP so that the gateway 203 or service server 205 corresponding to the node 201 can be confirmed based on the security session policy 312, and the node 201 can transmit data packets without a network connection procedure. You can create a data flow that includes destination IP and port information. According to the embodiment, when a data flow is created, the controller 202 may transmit the generated data flow to the node 201 and the gateway 203 or the service server 205 (operation 645).

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

According to another embodiment, controller 202 may determine that node 201 is unreachable. For example, if the identification information of the node 201 and/or the network to which the node 201 belongs is included in the 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 in operation 615 and may transmit a response indicating that controller connection is not possible in operation 625. Additionally, in this case, operations 630 to 645 may not be performed. Depending on the embodiment, if a retry of controller connection is required, the connection control application 211 may perform operation 605 again.

In addition, the access control application 211 can update the data flow of the node 201 when a data flow received from the controller 202 exists and transmit data packets based on a pre-allowed data flow when connecting to the network. Data flow can be managed so that Afterwards, when a data packet transmission request is detected, the access control application 211 may process the data packet to be transmitted based on the received data flow.

According to the embodiment, operations 630 to 645 may be omitted.

According to the embodiment, when the connection control application 211 receives network connection release information from the controller 202, it may terminate the application or block all network connections of the application.

7 shows 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 may receive authentication for the user of the node 201 from the controller 202. According to an embodiment, the node 201 may be substantially the same as the node 201 of FIG. 2A or 2B on which the access control application 211 is installed.

Referring to FIG. 7, node 201 may receive input for user authentication. The input for user authentication may be, for example, a user input of entering a user ID and password. For another example, the input for user authentication may be a user input for stronger authentication (e.g., biometric information). In this case, in operation 705, the access control application 211 of the node 201 may request user authentication from the controller 202. If a control flow between the node 201 and the controller 202 has already been created, the access control application 211 may transmit input information for user authentication along with control flow identification information.

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

If the user is authenticated, in operation 715, the controller 202 may add the user's identification information (e.g., user ID) to the control flow's identification information. The added user identification information can be used to connect the authenticated user to the controller or network.

In operation 720, the controller 202 retrieves the identified information (e.g., node 201, source network information to which node 201 belongs) from the access policy database 311 and the security session policy database 312. You can create whitelist information of accessible applications.

In operation 725, 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 created through operation 720 to the access control application 211.

In operation 730, the access control application 211 may perform a check on the application. For example, the access control application 211 may perform a check on applications based on a white list of accessible applications received from the controller 202. The access control application 211 can check whether an application exists (installed) on the node 201 based on accessible application information, and determines the integrity and safety of the existing application (whether the application has been forged or modified, whether the application has been forged or not, and whether the code has been used). A test related to at least one of an innings test and a fingerprint test may be performed.

In operation 735, the access control application 211 may transmit the test result to the controller 202. For example, the access control application 211 transmits to the controller 202 the results of performing a check related to the integrity and safety of the application (at least one of application forgery, code signing check, and fingerprint check). You can.

At operation 740, controller 202 may perform data flow processing. For example, the controller 202 may check whether the application is valid based on the received application inspection result, and if the application is valid, establish an access policy 311 to allow the node 201 connected to the network to access the network. and a source IP so that the gateway 203 or service server 205 corresponding to the node 201 can be confirmed based on the security session policy 312, and the node 201 can transmit data packets without a network connection procedure. You can create a data flow that includes destination IP and port information. According to the embodiment, when a data flow is created, the controller 202 may transmit the generated data flow to the node 201 and the gateway 203 or the service server 205 (operation 745).

In operation 750, the access control application 211 may process a result value according to the received response. For example, the access control application 211 may store the received control flow identification information and display a user interface screen to the user indicating that user authentication is complete. Once user authentication is completed, the node 201's network connection request for the destination network may be controlled by the controller 202.

According to another embodiment, the controller 202 may determine that user authentication of node 201 is not possible. For example, if the identification information of node 201 and/or the network to which node 201 belongs is included in the blacklist database, the controller 202 may determine that node 201 is inaccessible and user authentication is not possible. . In this case, the controller 202 may not reflect the user identification information in operation 715 and may transmit a response indicating that controller access is not possible in operation 725. Additionally, in this case, operations 730 to 745 may not be performed.

In addition, the access control application 211 can update the data flow of the node 201 when a data flow received from the controller 202 exists and transmit data packets based on a pre-allowed data flow when connecting to the network. Data flow can be managed so that

According to the embodiment, when the connection control application 211 receives network connection release information from the controller 202, it may terminate the application or block all network connections of the application.

According to the embodiment, operations 730 to 745 may be omitted.

Figure 8 shows a signal flow diagram for network access according to various embodiments.

After the node 201 is authorized by the controller 202, the node 201 controls the network access of other applications stored in the node 201 through the access control application 211 of the node 201, thereby controlling the network access of other applications stored in the node 201. Transmission can be guaranteed. According to an embodiment, the node 201 may be substantially the same as the node 201 of FIG. 2A or 2B on which the access control application 211 is installed.

Referring to FIG. 8 , in operation 805, the connection control application 211 may detect a network connection event of another application (eg, the target application 212 in FIG. 2A or FIG. 2B) stored in the node 201.

In operation 810, the access control application 211 may confirm the existence of a data flow corresponding to the identification information of the application requesting network access, destination network identification information, and port information. Depending on the embodiment, if a data flow exists but is not valid, the access control application 211 may drop the data packet. According to another embodiment, when a data flow exists, the access control application 211 may transmit data packets based on the data flow. According to an embodiment, the access control application 211 of the node 201 may perform a network connection request in operation 815 without performing operation 810.

When the data flow needs to be updated, such as when the data flow does not exist or when the authentication time has expired and needs to be updated, in operation 815, the access control application 211 may request network access from the controller 202. For example, a network connection request may include control flow identification information, identification information of the destination network, and port information.

In operation 820, the controller 202 collects the connection request identification information (e.g., identification information of the destination network) from the connection policy corresponding to the identified information (e.g., node, user, source network identification information) based on the control flow identification information. and port information) and whether the destination network is accessible. According to the embodiment, the controller 202 may check whether the target application can connect to the gateway 203 or the service server 205. Depending on the embodiment, if network connection is not possible, the controller 202 may transmit a connection failure result to the connection control application 211 of the node 201 (operation 835).

If connection is available, in operation 825, the controller 202 establishes a secure session between the node 201 and the gateway 203 or the service server 205 for the target application to access the network based on the security session policy 312. You can check whether creation is possible. According to the embodiment, when it is impossible to create a secure session or when certificate information for creating a secure session does not exist, the controller 202 may transmit a result of an unavailable connection to the access control application 211.

If a secure session can be created but a valid data flow does not exist, the controller 202 provides the service IP, port information, and protocol information that the target application can access through the proxy included in the gateway 203 or the service server 205. You can create data flows including (e.g. HTTP, FTP, IoT-specific protocols, etc.). In addition, the data flow generated by the controller 202 may include whether service request filtering is necessary, a service request filtering processing method, and filtering information (e.g., personal information, harmful service request information), and may include information that is unnecessary in advance by the proxy. Or, if a series of information to block dangerous service requests and QoS (Quality of Service) for service requests are required, set the number of service requests possible in a certain time unit and adjust the number of service requests in the proxy accordingly. Information, data flow information including certificate information can be created to check whether the connection target is permitted when creating a security session.

According to the embodiment, the data flow generated by the controller 202 is information necessary for the gateway 203 to insert a data flow header, and includes a method of inserting authentication information when requesting a service (e.g., inserting an HTTP header of HTTP), Authentication information including 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) is removed when returning a service request. Additional header information may be included.

According to an embodiment, when a data flow is created, the controller 202 may transmit data flow and security session information to the gateway 203 or the service server 205 (operation 830). Additionally, the controller 202 may transmit the generated data flow to the connection control application 211 (operation 835).

According to the embodiment, when a valid data flow exists, the controller 202 may transmit the valid data flow to the gateway 203 or the service server 205 without generating the data flow, and transmit the valid data flow to the access control application. 211 (operations 830 and 835).

In operation 840, the access control application 211 of the node 201 may process a result of the response received from the controller 202. For example, when the connection control application 211 receives a network connection unavailable result from the controller 202, the connection control application 211 may drop the data packet that the target application wants to transmit. As another example, when a data flow is received from the controller 202, the access control application 211 may transmit data packets based on the received data flow. In this case, the access control application 211 may update the existing data flow with the received data flow.

9 shows an operational flowchart for receiving data packets according to various embodiments. The operations shown in FIG. 9 may be performed through the gateway 203 or service server 205.

When receiving a data packet, the gateway 203 or the service server 205 can block unauthorized data packets from being received by checking them based on the data flow authorized by the controller 202.

In operation 905, the gateway 203 or the service server 205 may receive a data packet reception event received from the built-in network interface from the network kernel of the operating system.

In operation 910, the gateway 203 or service server 205 determines whether a corresponding data flow exists based on the destination IP, port information, and protocol information (e.g., TCP, UDP, etc.) included in the IP header of the received data packet. You can check it.

According to the embodiment, if a data flow exists, the gateway 203 or the service server 205 may receive and process data packets (operation 915).

According to an embodiment, when a data flow exists but is invalid (e.g., data packet transmission is not possible, data packets are not received from a network interface authorized on the data flow, or a channel for data packet transmission does not exist) etc.) or when no data flow exists, the gateway 203 or service server 205 may drop the received data packet (operation 920).

FIG. 10 illustrates an operation flowchart for creating a secure session according to various embodiments. The operations shown in FIG. 10 may be performed through the gateway 203 or service server 205.

When the gateway 203 or service server 205 receives a request for creating a secure session from the node 201, it checks whether a secure session can be created through a proxy based on the certificate information received from the controller 202 and creates a secure session. By allowing or rejecting, transmission of service requests can be controlled through a secure session even after the network connection of the node 201 is authorized.

In operation 1005, the gateway 203 or the service server 205 may detect a secure session creation request event of the node 201.

In operation 1010, the gateway 203 or the service server 205 may check whether a data flow exists based on the destination IP, port information, and protocol information (e.g., TCP, UDP, etc.) included in the received IP header. .

According to an embodiment, when a data flow exists but is invalid (e.g., data packet transmission is not possible, data packets are not received from a network interface authorized on the data flow, or a channel for data packet transmission does not exist) etc.) or if a data flow does not exist, the gateway 203 or the service server 205 may refuse to create a secure session (operation 1225).

If a valid data flow exists, in operation 1015, gateway 203 or service server 205 may check the certificate through the proxy. For example, the gateway 203 or the service server 205 may check whether the request for creating a secure session is valid based on certificate information included in the data flow. According to an embodiment, if the certificate is valid, the gateway 203 or service server 205 may complete secure session creation (operation 1020).

According to an embodiment, if the certificate is invalid, the gateway 203 or service server 205 may refuse to create a secure session (operation 1025).

11 illustrates an operational flowchart for service request processing according to various embodiments. The operations shown in FIG. 11 may be performed through the gateway 203 or service server 205.

When transmitting a service request, the gateway 203 or the service server 205 may control so that only the node 201 for which a secure session is created can access the permitted service.

In operation 1105, the gateway 203 or the service server 205 may detect a service request event of the node 201.

In operation 1110, the gateway 203 or service server 205 may check whether a data flow exists based on the destination IP, port information, and protocol information (e.g., TCP, UDP, etc.) included in the received IP header. .

According to an embodiment, when a data flow exists but is invalid (e.g., data packet transmission is not possible, data packets are not received from a network interface authorized on the data flow, or a channel for data packet transmission does not exist) etc.) or when no data flow exists, the gateway 203 or the service server 205 may reject the service request (operation 1140).

According to the embodiment, when a data flow exists, the gateway 203 or service server 205 allows a service request within the data flow based on the destination IP or domain identification information and port information included in the received service request header. You can check whether service information exists. For example, if service information does not exist, the gateway 203 or service server 205 may reject the service request (operation 1140). For another example, if service information exists, the gateway 203 or the service server 205 may perform operation 1115.

If data flow and service information exist, in operation 1115, the gateway 203 or service server 205 may check whether service request QoS is required based on service request QoS information included in the service information.

If service request QoS is required, the gateway 203 or service server 205 checks the number of service requests that can be transmitted per certain time included in the service request QoS information, and determines whether QoS is necessary based on the service request QoS statistical information. You can check it.

If the number of service requests exceeds the allowable number per certain time, the gateway 203 or service server 205 delays the service request for a certain time according to the service request QoS method and then processes the request or induces a re-request for the service request. The service request may be rejected (operation 1140).

In operation 1120, the gateway 203 or the service server 205 determines whether the protocol of the service request (e.g., HTTP, FTP, or a dedicated protocol for IoT devices) is normal based on the service request filtering information included in the service information. You can check it. For example, if the protocol of the service request is not normal, the gateway 203 or the service server 205 may reject the service request (operation 1140).

If the protocol of the service request is normal, the gateway 203 or service server 205 may filter the service request. For example, if the service request requires replacement, the gateway 203 or the service server 205 may replace the information included in the service request based on replacement information or rules included in service filtering information of service information. For another example, when substitution of a service request is not required or filtering is not required, the gateway 203 or the service server 205 may perform operation 1125 without performing operation 1120. For another example, if it is necessary to block a service request, the gateway 203 or the service server 205 may reject the service request.

In operation 1125, the gateway 203 or the service server 205 may generate authentication information to be inserted into the service request using an authentication information generation algorithm and additional information included in the authentication information included in the data flow. In this case, the gateway 203 or the service server 205 may encrypt the authentication information to be inserted based on the encryption algorithm and encryption key included in the authentication information, and create a data flow combining the encrypted authentication information and data flow identification information. Headers can be inserted into service requests according to the protocol specifications of the service application. According to the embodiment, the service server 205 may omit operation 1125.

If the data flow header is normally inserted, the gateway 203 or the service server 205 may transmit a service request with the data flow header inserted (operation 1130).

In operation 1135, the gateway 203 or the service server 205 may update the number of service request processing times in the QoS statistical information of the service information included in the data flow after processing the service request transmission and service request rejection.

12 shows an example of a service request according to various embodiments.

When transmitting a service request, the gateway 203 may insert and transmit a data flow header to confirm that the service request is transmitted from an authorized entity through a secure session.

When receiving a service request through an authorized security session, the proxy included in the gateway 203 can identify the target application through a data flow and identify the service application requested by the target application. In this case, the gateway 203 can identify the service request target from the service server 205 in a part suitable for the protocol of the service application (e.g., header area 1205 in the case of HTTP) according to the authentication information included in the data flow. The data flow header can be inserted and transmitted to the service server 205.

The gateway 203 may insert an additional HTTP header 1215 in addition to the node-transmitted HTTP header 1210 included in the HTTP header 1205 transmitted from the node.

According to the embodiment, the data flow header 1220 is authenticated by the service server 205 based on the data flow received from the controller 202 in the data packet flow between the target application, the gateway 203, and the service server 205. This may be information inserted by the gateway 203 to check whether it is a data packet.

According to an embodiment, the data flow header may be generated by combining data flow identification information and encrypted authentication information.

In an IP network, data packets have no identifiable information other than 5 Tuples information (protocol, source IP, port, destination IP, port), so the service server 205 determines whether the node assigned the IP is actually authenticated and the actual You can check whether the target application, which is the subject of communication, is allowed. Therefore, when processing a service request, the service server 205 can query the controller 205 with the data flow identification information included in the data flow header to check whether an authenticated subject has connected, and the controller 202 stores and It can provide an effective method for authentication by receiving additional information about the authenticated target.

In addition, encrypted authentication information in addition to the data flow identification information included in the data flow header can be used for the purpose of checking whether the authenticated gateway 203 has forwarded the service, and thus the service server 205 can verify whether the service request is authorized. It is possible to check whether the message has been received from the authorized destination through the authorized gateway 203.

According to the embodiment, the encrypted authentication information can be decrypted only for the authenticated object (with which the data flow exists) through the authentication information encryption/decryption key included in the authentication information included in the data flow received from the controller 202.

According to an embodiment, the decrypted authentication information may not be a fixed value at each data packet authentication time, but may be composed of information in the form of OTP (One-Time Password) and Random Generation that changes at each authentication time.

According to the embodiment, based on the information for OTP generation and verification included in the authentication information of the data flow, the gateway 203 generates OTP information that changes at each service request forwarding time and encrypts the OTP information to identify the data flow. By inserting and transmitting data flow header information generated by combining information into a service request, a method can be provided to verify whether the service server 205 has received a service request from the authenticated gateway 203.

Figure 13 shows an operation flowchart for receiving a service request result according to various embodiments. The operations shown in FIG. 13 may be performed through the gateway 203.

In operation 1305, the gateway 203 or the service server 205 may detect a service request result reception event. For example, the service server 205 may directly generate service request results.

In operation 1310, the gateway 203 or the service server 205 may check whether a data flow corresponding to the service request result exists. According to the embodiment, if a data flow does not exist, the gateway 203 or the service server 205 may drop the service request result.

In operation 1315, the gateway 203 or the service server 205 may check whether the data flow header inserted when requesting the service exists in the service request result. For example, if there is a data flow header inserted when requesting a service, the gateway 203 or service server 205 may remove the data flow header and forward the service request result to the node 201 (operation 1320). .

Therefore, according to the embodiments disclosed in this document, if the service request result (reverse direction) received after forwarding the service request information includes header information, the gateway (201) prevents the node 201 from identifying the information. 203) or the service server 205 may remove unnecessary information (e.g., data flow header) and forward the service request result.

Figure 14 shows a signal flow diagram for control flow update according to various embodiments.

Referring to FIG. 14, in operation 1405, the access control application 211 may detect a control flow update event.

In operation 1410, the access control application 211 may request a control flow update from the controller 202 based on control flow identification information. According to the embodiment, the access control application 211 may transmit the security check results to the controller 202.

In operation 1415, the controller 202 may check whether a control flow exists in a control flow table (e.g., control flow table 315 of FIG. 3) based on the received control flow identification information. Depending on the embodiment, when a control flow does not exist (e.g., when the connection is disconnected by another security system, when the connection is disconnected due to its own risk detection, etc.), the controller 202 determines that the connection of the node 201 is valid. Since this is not done, a connection failure result can be transmitted to the access control application 211 (operation 1420).

According to the embodiment, if the inspection result is normal, the controller 202 may update the update time, check the data flow dependent on the control flow, perform re-authentication of the data flow, or return the data flow to the node 201. there is.

In operation 1425, the access control application 211 of the node 201 may process the result of the response received from the controller 202. For example, the access control application 211 may block all network connections of nodes connected to the node 201 when the control flow update result is impossible. For another example, the connection control application 211 may update the data flow if the control flow update result is normal and an updated data flow exists.

15 shows a signal flow diagram for disconnection according to various embodiments.

Referring to FIG. 15, in operation 1505, the node 201 terminates the node 201, terminates the connection control application 211, no longer uses the network connection, and terminates the connection based on information identified from the interworking system. At least one of the requests can be detected. In this case, in operation 1510, the node 201 or the access control application 211 may request the controller 202 to remove the control flow.

At operation 1515, the controller 202 may remove the identified control flow based on the received control flow identification information.

In operation 1520, the controller 202 may remove all data flows dependent on the removed control flow. Accordingly, node 201 can no longer connect to the destination network based on the removed data flow. In addition, the controller 202 requests the removal of security sessions and data flows to the gateway 203, which relays all data flows dependent on the removed control flow, so that data packets can no longer be transmitted to the destination network. can be provided.

Figure 1605 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 is terminated and detect an application execution termination event.

Depending on the embodiment, the access control application 211 may check whether a data flow corresponding to the terminated application identification information and PID (Process ID and Child Process ID Tree) information exists.

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

At operation 1615, the controller 202 may delete the data flow for which removal has been requested. Additionally, the controller 202 may request the gateway 203 to remove the removed data flow. The gateway 203 may 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 illustrative explanation of the technical idea disclosed in this document, and those skilled in the art in the technical field to which the embodiments disclosed in this document belong will understand without departing from the essential characteristics of the embodiments disclosed in this document. Various modifications and variations will be possible.

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

Claims (12)

In the gateway,
communication circuit; Memory; and
a processor operatively connected to the communication circuit and the memory, the processor comprising:
Receive a secure session creation request from a node, check whether a data flow received from an external server exists based on destination network information included in the secure session creation request, and the data flow is a secure session between the node and the gateway. Contains certificate information determined in advance by the external server in relation to whether it can be generated,
Create a secure session between the node and the gateway by checking whether the secure session creation request is valid based on the certificate information transmitted from the node included in the secure session creation request and the certificate information included in the data flow; ,
When a service request is received from the node based on the secure session, whether service information allowing the service request exists in the data flow based on the identification information of the secure session and destination network information included in the service request. Check and
If service information allowing the service request exists, insert data flow header information into the service request and forward it to the service server so that the service server can identify the node,
When returning a result of a service request to the node, the data flow header information is removed from the result of the service request and forwarded to the node,
The data flow header information includes identification information of the data flow used when the service server requests information about the node from the external server and authentication information for authenticating the request for information about the node. Gateway. The method of claim 1, wherein the processor:
Receiving a service request from the node,
If there is no data flow corresponding to the service request, the service request is rejected,
If a data flow corresponding to the service request exists, determine whether the service request requires QoS based on QoS information included in the data flow corresponding to the service request,
If the service request requires QoS, check the amount of service request that can be transmitted based on the QoS information,
When the transmittable service request amount is exceeded, the gateway is configured to delay transmission of the service request for a certain period of time based on the QoS information and transmit the service request, or to induce retransmission of the service request. The method of claim 1, wherein the processor:
Receiving a service request from the node,
If there is no data flow corresponding to the service request, the service request is rejected,
If a data flow corresponding to the service request exists, check whether the protocol of the service request is normal based on filtering information included in the data flow corresponding to the service request,
If the protocol of the service request is not normal, the service request is rejected,
If replacement of the information included in the service request is necessary based on the filtering information, the information included in the service request is replaced and transmitted based on the replacement information or replacement rule included in the filtering information,
A gateway, configured to reject the service request if blocking of the service request is necessary. The method of claim 1, wherein the processor:
Receiving a service request from the node,
If there is no data flow corresponding to the service request, the service request is rejected,
If a data flow corresponding to the service request exists, authentication information to be inserted is generated based on authentication information included in the data flow corresponding to the service request,
Encrypting the authentication information to be inserted based on the authentication information included in the data flow,
Generate a data flow header by combining the encrypted authentication information and the identification information of the data flow,
A gateway, configured to insert and process the data flow header into the service request. The method of claim 4, wherein the processor:
Receiving the results of the service request,
If the data flow header inserted at the time of the service request exists in the result of the service request, the data flow header is removed,
A gateway configured to forward a result of the service request to the node. delete The method of claim 1, wherein the processor:
When a service request is received from the node, the encrypted authentication information generated based on the authentication information included in the data flow and the identification information of the data flow are combined and inserted into the service request and transmitted,
Receiving the results of the service request,
If information inserted at the time of the service request exists in the result of the service request, the information inserted at the time of the service request is removed,
A gateway configured to transmit a result of the service request to the node. The method of claim 1, wherein the processor:
Receive a secure session creation request from the node,
Confirm the existence of a data flow corresponding to the secure session creation request,
If a data flow corresponding to the secure session creation request exists, check whether the secure session creation request is valid based on the certificate information included in the data flow,
Once a secure session is created, the gateway is configured to process a service request received from the node based on the secure session. In the service server,
communication circuit; Memory; and
a processor operatively connected to the communication circuit and the memory, the processor comprising:
Receive a secure session creation request from a node, check whether a data flow received from an external server exists based on destination network information included in the secure session creation request, and the data flow is secure between the node and the service server. Contains certificate information determined in advance by the external server in relation to whether a session can be created,
Creating a secure session between the node and the service server by checking whether the secure session creation request is valid based on the certificate information transmitted from the node included in the secure session creation request and the certificate information included in the data flow. do,
When a service request is received from the node based on the secure session, whether service information allowing the service request exists in the data flow based on the identification information of the secure session and destination network information included in the service request. Check and
If service information allowing the service request exists, check whether the service request includes data flow header information,
When returning a result of a service request to the node, the data flow header information is removed from the result of the service request and forwarded to the node,
The data flow header information includes identification information of the data flow used when the service server requests information about the node from the external server and authentication information for authenticating the request for information about the node. service server. delete In the method of operating the gateway,
An operation of receiving a data flow from an external server, wherein the data flow includes information related to whether a node that has made a network connection request to the external server can be connected and certificate information related to whether a secure session can be created;
Receiving a secure session creation request from the node, the secure session creation request including certificate information transmitted from the node;
Confirming the existence of a data flow corresponding to the secure session creation request;
If a data flow corresponding to the secure session creation request exists, checking whether the secure session creation request is valid based on certificate information included in the data flow and certificate information transmitted from the node; and
When a security session is created, processing a service request received from the node based on the security session; Method, including. delete