WO2023163509A1 - System for controlling controller-based network connection and method related to same - Google Patents

Abstract

A gateway according to an embodiment disclosed in the present document comprises a communication circuit, a memory for storing a database, and a processor operatively connected to the communication circuit and the memory. The processor can be configured to: receive a data packet; determine whether the data packet was received from an authorized subject; determine whether a data flow corresponding to service processing request information about the data packet and applied from an external server exists; inspect the service processing request information when the data flow exists; and process the data packet on the basis of the result of the inspection of the service processing request information.

Description

Controller-based system for controlling network access and method therefor

Mutual Citation with Related Applications

The present invention claims the benefit of priority based on Korean Patent Application No. 10-2022-0024308 filed on February 24, 2022, and includes all contents disclosed in the literature of the Korean patent application as part of this specification.

technology field

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

Multiple devices may communicate data over a network. For example, the terminal may transmit or receive data with a server through the Internet. The network may include a private network such as an intranet as well as a public network such as the Internet.

The terminal performs communication with the server by utilizing IP (Internet Protocol)-based TCP (Transmission Control Protocol) or UDP (User Datagram Protocol), and controls the connection between the source IP and destination IP authorized in TCP or UDP technology. Firewall technology may be used. In the case of such IP communication, since data packets are transmitted in plain text, there is a problem in that a third party can easily view important information of 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 for encrypting data packets between the terminal and the server are used.

As attacks such as key loggers, etc. are installed on a user's terminal to leak authentication information for access to a specific service and an attack by substituting an arbitrary password, personal information leakage and theft of services that are always connected to the Internet are occurring. .

Some services provide Multi Factor Authentication (MFA) to solve the above security problems, but in order to provide enhanced authentication methods for all services, a lot of money must be invested in modifying existing services. In particular, as various MFA technologies are scattered, it may be difficult to support all authentication methods preferred by users.

In addition, since the service is always connected to the Internet, that is, it is already sending and receiving data packets at the stage of general authentication (based on user ID and password input) or MFA, it prevents the attack itself by substituting a random password. There is no way to do it. That is, if a continuous attack on a specific ID occurs, it may be inconvenient from the user's point of view because only functions requiring authentication may be provided through additional authentication.

The above problems can be applied not only to Internet-connected services but also to unit systems used by companies. In this case, the unit system can be accessed, and authentication in the unit system can be more vulnerable to security because even the weaker security authentication system and minimum authentication standards are not observed than the above popular services.

In addition, as services diversify, users prefer technologies (e.g., OAuth, etc.) that enable integrated authentication for each service through one authentication information, but the current integrated authentication technology is HTTP in an insecure terminal and network environment. Since protocol-based technologies such as SSO (Single Sign On) are used, authenticating each service while being authenticated to the service for integrated authentication in a terminal and network environment that is practically insecure is a chain of authentication and personal information A more dangerous problem can arise in terms of deodorization.

Also, in a popularized service connected to the Internet, relaying all connections of each service through a gateway may cause operational and cost problems.

In addition, since only authenticated objects are accessed, and information that can be identified in each service corresponding to a service request is limited to source IP information, a problem in which it is impossible to identify which user and terminal has accessed may occur.

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

A gateway according to an embodiment disclosed in this document includes a communication circuit, a memory for storing a database, and a processor operatively connected to the communication circuit and the memory, wherein the processor receives a data packet, and the It is checked whether the data packet is received from an authorized target, it corresponds to the service processing request information of the data packet, it is checked whether there is a data flow authorized from an external server, and if the data flow exists, the It may be configured to inspect service processing request information and process the data packet based on a result of checking the service processing request information.

A service server according to an embodiment disclosed in this document includes a communication circuit, a memory including a database, and a processor operatively connected to the communication circuit and the memory, wherein the processor receives a service processing request and , It is determined whether the service processing request is a request of the authorized gateway based on whether the source IP included in the service processing request is an IP of an authorized gateway, and if the service processing request is a request of the authorized gateway, The service processing request may be processed based on whether a data flow header is included in the service processing request.

A method of operating a gateway according to an embodiment disclosed in this document includes receiving a data packet, determining whether the data packet is a data packet received from an authorized target, corresponding to service processing request information of the data packet, and , Checking whether there is a data flow authorized from an external server, checking the service processing request information if the data flow exists, and selecting the data packet based on a result of checking the service processing request information processing may be included.

A method of operating a service server according to an embodiment disclosed in this document includes receiving a service processing request, and the service processing request is sent based on whether a source IP included in the service processing request is an IP of an authorized gateway. Checking whether the request is from an authorized gateway, and if the service processing request is from the authorized gateway, processing the service processing request based on whether a data flow header is included in the service processing request can do.

According to the embodiments disclosed in this document, it is possible to provide a technology for safely accessing a service using an existing application access control technology, identifying and authenticating a connection target in the service, and easily applying it to a popularized service. Integrated authentication technology can be provided.

In addition, according to the embodiments disclosed in this document, by providing a method by which only an authenticated target can access a service server through an access control application and a gateway, a service request including an unnecessary service request transmitted from an unauthorized target or an attacking behavior is provided. By fundamentally blocking, DDoS (Distributed Denial of Service Attack) attacks can be effectively prevented by guaranteeing safe network access at all times between the authenticated target and the service server, and at the same time reducing service requests from unauthorized targets.

In addition, according to the embodiments disclosed in this document, among service requests passing through the gateway, service requests including service attack behavior information may be filtered in advance, and it is possible to check whether a target has performed the corresponding attack behavior, At the same time, continuous DDoS attack behavior can be blocked by isolating the network access of the attacker.

In addition, according to the embodiments disclosed in this document, due to the nature of HTTP, which is one of the representative service applications, session information that is not valid because it is not possible to know when the network connection of the terminal is terminated if the network connection to the terminal is not always maintained. and can prevent vulnerabilities from Session Hijacking attacks using this session information.

In addition, according to the embodiments disclosed in this document, the service server can remove invalid session information by releasing the data flow at the time of network connection termination, and by blocking service requests using invalid session information, A more secure network service may be provided.

According to the embodiments disclosed in this document, by controlling authentication through a network access control application, a unified service access and authentication structure can be provided without the need to apply a separate strong authentication method to each service.

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

1 shows an environment including a plurality of networks.

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

3 is a functional block diagram illustrating a database stored in a controller according to various embodiments.

4 shows a functional block diagram of a node in accordance with various embodiments.

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

6 shows an example of a gateway according to various embodiments.

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

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

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

10 illustrates an operational flow diagram for processing a service request at a gateway according to various embodiments.

11 illustrates an operational flow diagram for processing a service request in a service server according to various embodiments.

12 shows a signal flow diagram for updating data flow according to various embodiments.

13 illustrates a signal flow diagram for transmitting a log of a gateway according to various embodiments.

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

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

16 illustrates a signal flow diagram for termination of application execution according to various embodiments.

17 is a flowchart of a method of operating a gateway according to various embodiments.

18 is a flowchart of a method of operating a service server according to various embodiments.

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

In this document, the singular form of a noun corresponding to an item may include one item or a plurality of items, unless the context clearly dictates 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 the phrases such as "at least one of B or C" may include any one of the items listed together in the corresponding one of the phrases, or all possible combinations thereof. Terms such as "first", "second", or "first" or "secondary" may simply be used to distinguish a given component from other corresponding components, and may be used to refer to a given component in another aspect (eg, importance or order) is not limited. A (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 the certain component may be connected to the other component directly (eg by wire), wirelessly, or through a third component.

Each component (eg, module or program) of the components described in this document may include singular or plural entities. According to various embodiments, one or more components or operations among the corresponding components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of 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 of the plurality of components identically or similarly to those performed by a corresponding component of the plurality of components prior to the integration. . According to various embodiments, the actions performed by a module, program, or other component are executed sequentially, in parallel, iteratively, or heuristically, or one or more of the actions are executed in a different order, or omitted. or one or more other actions 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 integrally constructed component or a minimal unit of components or a portion 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 (eg, a program or application) including one or more instructions stored in a storage medium (eg, memory) readable by a machine. For example, the processor of the device may call at least one command among one or more commands stored from a storage medium and execute it. This enables the device to be operated to perform at least one function according to the at least one command invoked. The one or more instructions may include code generated by a compiler or code executable by an interpreter. The device-readable storage medium may be provided in the form of a non-transitory storage medium. Here, 'non-temporary' only means that the storage medium is a tangible device and does not contain a signal (e.g. electromagnetic wave), and this term refers to the case where data is stored semi-permanently in the storage medium. It does not discriminate when it is temporarily stored.

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

1 shows an environment including a plurality of 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 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, but is not limited to the aforementioned devices. For example, source node 101 may include a server or gateway capable of transmitting data packets through an application. The source node 101 may also be referred to as 'electronic device' or 'terminal'. Meanwhile, the destination node 102 may include the same or similar device as the above-described source node 101 . For another example, the destination node 102 can be substantially the same as the destination network.

The source node 101 may attempt access to 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 via the gateway 103 .

If access to the first network 10 of the starting node 101 is approved, since the starting node 101 can communicate with all servers included in the first network 10, the starting node 101 is malicious. ) can be exposed from program attacks. For example, the origin node 101 may be infected with malicious code 110c, as well as trusted and/or secure applications such as Internet web browser 110a and business application 110b. ) may receive data of an untrusted or unsecured application such as the business application 110d.

The starting node 101 infected by the malicious program may attempt access to the second network 20 and/or data transmission. When the second network 20 is formed based on IP, such as VPN, it may be difficult to individually monitor a plurality of devices included in the second network 20, and application in the OSI layer Security at the layer or transport layer may be vulnerable. In addition, if the source node 101 includes a malicious application after the channel has already been created, the data of the malicious application will be delivered to another electronic device (eg, the destination node 102) within the second network 20. can

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

Referring to FIG. 2 , nodes 201 and 206 may be various types of devices capable of performing data communication. For example, nodes 201 and 206 may include an authenticating node 201 and a non-certifying node 206 . For another example, the nodes 201 and 206 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, and a virtual reality (VR) device. ) device, or a home appliance, but is not limited to the aforementioned devices. For example, nodes 201 and 206 may include servers or gateways capable of transmitting data packets through applications. Nodes 201 and 206 may also be referred to as 'electronic devices' or 'terminals'.

The authentication node 201 may store a first target application 212 and an access control application 211 . The first target application 212 may transmit a data packet to the service server 205 through the gateway 203 under the control of the access control application 211 or, conversely, may receive a data packet. Some of the first target applications 212 may be trusted and/or secured applications, such as web browsers or business applications, while others may be untrusted or unsecured malicious programs, thus network access according to embodiments. The system may block access to the service server 205 of an unauthorized program (application) through network access control of the access control application 211 and isolate the corresponding program. For example, before the first target application 212 according to embodiments communicates with the service server 205 , the access control application 211 may check whether access is available from the controller 202 . When authentication is completed, the access control application 211 may control data packet transmission of the first target application 212 . That is, in order for the first target application 212 to access the network, it must go through the access control application 211, the access control application 211 must be authorized from the controller 202, and the access control application 211 is the controller ( Authentication-related information may be received from 202 , and the access control application 211 may transmit a data packet of the first target application 212 based on the authentication-related information.

The unauthenticated node 206 may store the second target application 216 . For example, the unauthenticated node 206 may be a node that does not have an access control application installed. According to an embodiment, the second target application 216 may access the service server 205 in a state in which safety is not guaranteed. In this case, the service server 205 may provide the second target application 216 with only functions suitable for the corresponding security level.

The controller 202 may be, for example, a server (or cloud server). The controller 202 can ensure reliable data transmission within the network environment by managing data transmission between the authentication node 201, the gateway 203, and the service server 205. For example, the controller 202 may allow the network access of the authorized authentication node 201 (or access control application 211) through policy information or blacklist information. In addition, the controller 202 may generate authentication-related information for authenticating data packets based on an authentication policy, and transmit the generated authentication-related information to the access control application 211 or the gateway 203 to transmit data It can prevent packets from being sent without authentication. In one embodiment, authentication information may be inserted into a data packet based on information about authentication received by the controller 202 of the gateway 203, and the data packet (or service processing request) into which the authentication information is inserted may be sent to the service. Forwarding may be performed to the server 205, and the service server 205 may check whether a service processing request has been received from an authorized subject based on authentication information. According to the embodiment, network access of the first 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 an access control application to perform various operations associated with network access of the authentication node 201 or access control application 211 (eg, registration, authorization, authentication, renewal, termination). 211 and control data packets can be transmitted and received. A flow through which the control data packet is transmitted (eg, 220) may be referred to as a 'control flow'. According to the embodiment, the controller 202 immediately retrieves tunneling and sessions according to security events received from the interworking system (eg, authentication node 201, gateway 203, or service server 205), thereby providing a secure network state at all times. can keep

The gateway 203 may be located at the boundary of the network to which the authentication node 201 belongs or the boundary of the network to which the service server 205 belongs. According to one embodiment, the gateway 203 may be connected to the controller 202 based on a cloud. The gateway 203 may forward only authenticated data packets based on the authentication information among the data packets received from the access control application 211 to the service server 205 . A flow in which data packets are transmitted between the access control application 211 and the gateway 203 may be referred to as 'data flow'. Data flows can be created in granular units (eg applications) as well as nodes or IP units. The gateway 203 may block indiscriminate network access in advance by forwarding only data packets for which authentication information has been checked among data packets transmitted from the access control application 211 to the service server 205 .

According to an embodiment, the gateway 203 may include modules for inspecting 5Tuples, TCP and UDP data packets, and modules for processing tunneling and secure session data packets. For example, the gateway 203 may check whether all data packets passing through the gateway 203 are data packets transmitted from an authorized target (eg, an authorized target from the controller 202).

According to the embodiment, the gateway 203 transfers data packets received through a channel such as an authorized tunneling or session to a service server (for example, the proxy module 233 of FIG. 6) through a proxy included in the gateway 203. 205) and service processing can be relayed. For example, the gateway 203 may provide a mechanism for the service server 205 to process a service request received from an authenticated subject, and the service server 205 may be a non-authenticated node (not the gateway 203). 206) may provide a separated network structure capable of handling service requests. Therefore, the above network processing structure can solve the problem of the structure in which the service server 205 must process the service through the gateway 203.

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

3 is a functional block diagram illustrating 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 communicating with an external electronic device (eg, the communication circuit 430 of FIG. 4) and a processor for controlling the overall operation of the controller (eg, FIG. Four processors 410) may be further included.

Hereinafter, node 201 may include authentication node 201 of FIG. 2 . For example, the unauthenticated node 206 of FIG. 2 may not have network access controlled by the controller 202 because the access control application is not installed.

Since the administrator can connect to the controller 202 and set connection-oriented policies to control access between the access control application 211 and the service server 205, network access is more detailed and secure than session management at the service level. can control.

The access policy database 311 may include information about networks and/or services to which the identified networks, nodes, or applications may access. For example, the controller 202, when requesting network access from the access control application 211, identifies a network based on a policy of the access policy database 311 (eg, a network to which the node 201 belongs), a node, A user (eg, a user of the node 201) and/or an application (eg, a target application 212 included in the node 201) may determine whether access to the service server 205 is possible. In , the controller 202 may create a whitelist of target applications 212 accessible to a specific service (eg, IP and port) based on the access policy database 311 .

The channel policy database 312 is a gateway (eg, gateway 203 of FIG. 2) and a proxy existing between service servers (eg, service server 205 of FIG. 2) on a connection path according to policies. (eg, the proxy module 233 of FIG. 6) information may be included.

The blacklist policy database 313 is a target (e.g., a node ID (eg, node ID ( identifier), an IP address, a media access control (MAC) address, or a user ID) may indicate a blacklist registration policy for blocking access.

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

The control flow table 315 is an example of a session table for managing a flow (eg, control flow) of control data packets generated between the node 201 and the controller 202 . When accessing the controller 202 is successful, 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 during access to and authentication of a controller, a node ID, and a user ID. For example, when access to the service server 205 is requested from the node 201, the controller 202 may search for control flow information through control flow identification information received from the node 201, and the searched control flow Whether the node 201 can access the service server 205 by mapping at least one of the IP address, node ID, or user ID included in the information to the access policy database 311, data flow for data packet transmission It can be judged (determined) whether it is created or not.

According to one embodiment, a control flow may have an expiration time. The node 201 needs to update the expiration time of the control flow, and if the expiration time is not updated for a certain period of time, the control flow (or control flow information) may be removed. In addition, when it is determined that immediate disconnection is necessary according to the security event collected from the node 201 , the controller 202 may remove the control flow according to the connection termination request of the node 201 . When the control flow is removed, the connection of the node 201 may be blocked because the previously generated data flow is also removed.

The data flow table 316 is a table for managing a flow (eg, data flow) in which detailed data packets are transmitted between the node 201 and the gateway 203 and the service server 205 . Data flows can be created in TCP sessions, applications, or more granular units. The data flow table 316 may include data flow information for tunneling and session management of the application (eg, the first target application 212) of the node 201, the gateway 230, and the service server 205. there is. The data flow table 316 may include an application ID, destination IP address, and/or service port for identifying whether a data packet transmitted from a source is an authorized data packet. The data flow table 316 may be managed based on control flow IDs. In addition, the data flow table 316 may include state information including whether or not the data flow is valid and authorized destination information for determining whether data packets are forwarded based on source IP, destination IP, and port information of the data packet. can According to an embodiment, the data flow table 316 may further include information indicating whether tunneling or a session is created between the application and the gateway 203 . According to the embodiment, the data flow table 316 inserts the authentication information of the protocol of the corresponding service application when the authentication information is inserted when the gateway 203 sends a request to the service server 205 (eg, HTTP HTTP header insertion, etc.), information for encrypting or 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). Information (eg, information generated or determined based on the authentication policy 317) may be further included. In addition, according to the embodiment, the data flow table 316 further includes a set of information (eg, information determined based on the service filtering policy 318) for filtering information about the service request in the gateway 203 can do.

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

The authentication policy database 317 determines whether or not the gateway 203 existing between the network boundaries of the service server 205 on a connection path authenticates a service request according to a policy and, if the authentication is performed, an authentication method and information. A set of related policies can be set. For example, the authentication policy database 317 inserts authentication information when transmitting a request from the gateway 203 to the service server 205, and inserts authentication information of a corresponding service application protocol (e.g., in the case of HTTP). HTTP header insertion, etc.), information for encrypting or decrypting authentication information, algorithm information for generating and verifying authentication information, and authentication information including a series of information included in the algorithm (e.g., information such as Secret Key when generating HMAC OTP) It may include information for generating.

According to an embodiment, authentication information generated based on the authentication policy database 317 may be transmitted to the node 201 , gateway 203 or service server 205 . According to an embodiment, the gateway 203 may insert authentication information into the service processing request received from the node and forward the service processing request into which the authentication information is inserted. In this case, the service server 205 may determine whether a service processing request has been received from an authorized subject based on the authentication information.

In the service filtering policy database 318, the gateway 203 existing between the network boundaries of the service server 205 on the connection path according to the policy allows the service request path or the disallowed service request path for the service request. (Example: HTTP protocol or FTP protocol URI information, Web API execution request path) and data that should not be transmitted (Example: Cross Site Scripting for HTTP attacks, SQL Injection information, personal information, etc.) can According to an embodiment, the gateway 203 may filter a data packet or a service processing request based on service filtering information set based on the service filtering policy database 318 .

4 shows a functional block diagram of a node in accordance with various embodiments.

Referring to FIG. 4 , a node may include a processor 410 , a memory 420 , and a communication circuit 430 . According to one embodiment, the node may further include a display 440 to interface with a user. According to an embodiment, the node may include the authenticated node 201 and non-certified node 206 of FIG. 2 .

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

All or part of processor 410 is electrically or operatively coupled to other components within the node (e.g., memory 420, communication circuitry 430, or display 440). (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 . The processor 410 may generate a new message, data, command, or signal based on the received message, data, command, or signal. Processor 410 may provide processed or generated messages, data, instructions, or signals to memory 420 , communication circuitry 430 , or display 440 .

The processor 410 may 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 in the memory 420 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.

The memory 420 may include one or more of volatile memory and 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). can include The nonvolatile memory may include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, and the like.

The memory 420 uses a nonvolatile medium such as a hard disk drive (HDD), a solid state disk (SSD), an embedded multi media card (eMMC), or a universal flash storage (UFS). can include more.

According to one embodiment, the memory 420 may store the first target application 212 and the access control application 211 of FIG. 2 . Also, the memory 420 may store the second target application 216 of FIG. 2 . The access 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 an embodiment, the memory 420 may store some of the information included in the memory of the controller (eg, the memory 330 of FIG. 3 ). For example, the memory 420 may store the data flow table 316 described in FIG. 3 .

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

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

A server (eg, controller) according to an embodiment may include a processor 410 , a memory 420 , and a 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 (eg, the gateway 203 of FIG. 2 ) according to an embodiment may include a processor 410 , a memory 420 , and a communication circuit 430 . 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 of controlling transmission of a data packet according to various embodiments.

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

According to the embodiment, when the access control application 211 is not connected to the controller 202 or when a data packet to be transmitted is a data packet to be transmitted based on a channel but the corresponding channel does not exist, access control Data packets transmitted from the application 211 are blocked by the gateway 203 and the access control application 211 can only request access to the controller 202 .

According to the embodiment, if the access control application 211 is not installed on the authentication node 201 or if a malicious application bypasses the control of the access control application 211, unauthorized data packets will be transmitted from the authentication node 201. can In this case, since the gateway 203 existing at the boundary of the network blocks data packets for which the corresponding channel does not exist, the data packets transmitted from the authentication node 201 (eg, data packets for TCP session creation) are sent to the service server. (205) may not be reached. In other words, the authentication node 201 can be isolated from the service server 205.

Referring to FIG. 5B, in the case of an unauthorized node 206 in which an access control application is not installed, the second target application 216 may provide a structure capable of always accessing the service server 205 through an existing network path. there is. For example, the service server 205 provides a separate network structure capable of processing a service request for an unauthorized node 206 rather than the gateway 203 so that the service server 205 must pass through the gateway 203. It can solve the problem of the inline structure incurring cost because the service must be processed.

6 shows an example of a gateway according to various embodiments.

Referring to FIG. 6 , a gateway 203 according to an embodiment disclosed in this document may include a data packet filtering module 213 , a tunneling module 223 and a proxy module 233 . According to the embodiment, the gateway 203 does not have to include all of the data packet filtering module 213, the tunneling module 223 and the proxy module 233, but the data packet filtering module 213, the tunneling module 223 and At least one of the proxy modules 233 may be included.

The data packet filtering module 213 may filter received data packets based on a service filtering policy received from a controller (eg, the controller 202 of FIG. 2 ).

The tunneling module 223 may inspect data packets received through tunneling. For example, the tunneling module 223 may check whether a received data packet is received through a corresponding authorized tunnel. According to an embodiment, the tunneling module 223 may check whether a data packet is received through an authorized channel including a tunnel or a session, not only whether or not it is received through an authorized tunnel.

According to the embodiment, each module (eg, data packet filtering module 213 or tunneling module 223) in which data packets exist in the network layer and transport layer on the OSI 7 layer, such as data packet processing of the gateway 203 and tunneling, etc. When checking whether a data packet is transmitted from an authorized target, the data flow identification information is inserted into the service processing request information so that the proxy module 233 can identify the authorized target according to the service processing policy, or the proxy module (233) transmits the information that allows the object to be identified through a method such as inter-module communication.

When a data packet is received through the data packet filtering module 213 or the tunneling module 223, the proxy module 233 may identify a connection target and a service application requested by the connection target based on the data flow table. . The proxy module 233 inserts data flow header information that can identify the service request target in the service server to an appropriate part of the protocol of the service application (eg, header area in the case of HTTP) based on authentication information included in the data flow. and transmit it to the service server. Also, the proxy module 233 may transmit a response of the service server to the service request to the node. According to the embodiment, the data flow header is a data packet flow between a target application (eg, the first target application 212 of FIG. 2), the gateway 203, and a service server (eg, the service server 205 of FIG. 2). Based on the data flow received from the controller (eg, the controller 202 of FIG. 2 ), it may be information inserted by the gateway so that the service server can check whether or not it is an authenticated data packet.

According to an embodiment, the data flow header may be configured by combining data flow identification information and encrypted authentication information. For example, when processing a service request, the service server can query the controller based on the data flow identification information included in the data flow header to check whether the authenticated target has accessed or not, and can determine whether the authenticated target stored in the controller Authentication may be performed by receiving additional information. For another example, the encrypted authentication information included in the data flow header may be used for the purpose of confirming whether the authenticated gateway 203 has performed service forwarding.

According to the embodiment, based on the authentication information encryption or decryption key included in the authentication information of the data flow received from the controller, only the authenticated object can decrypt the encrypted authentication information.

According to the embodiment, the decrypted authentication information may not be a fixed value at every data packet authentication time, such as data flow identification information, and may be OTP (One-Time Password) and Random Generation type information that changes at every authentication time. can be configured. For example, the gateway 203 generates OTP information that is changed at every service request forwarding point based on information for OTP generation and verification included in the authentication information of the data flow, and encrypts the generated OTP value to improve the data flow By forwarding service processing request information including data flow header information into which identification information is inserted to the service server, a structure for the service server to receive and verify the service request from the authenticated gateway 203 may be provided.

7 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 access or receive the network, the access control application 211 of the node 201 requests the controller 202 to create a control flow, thereby 201) can try to connect to the controller. According to an embodiment, node 201 may be substantially the same as authentication node 201 of FIG. 2 in which access control application 211 is installed.

Referring to FIG. 7 , node 201 may detect a controller connection event. For example, when the connection 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.

At operation 705 , node 201 may request controller connection from 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 (eg, terminal ID, IP address, MAC address), type, location, environment, identification information of the network to which the node 201 belongs, and/or network Arbitrary identification information generated by the system itself may be further transmitted.

In operation 710, the controller 202 may identify whether or not the controller connection request (eg, the access control application 211 or the node 201) is accessible. According to one embodiment, the controller 202 determines whether information received from the node 201 is included in the access policy database 311, the node 201, the network to which the node 201 belongs, and/or the connection. Based on at least one of whether the identification information of the control application 211 is included in the blacklist database 314 , it is possible to check whether the controller connection requesting object is accessible.

If the connection is possible, at operation 715 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 random numbers, and converts identification information of at least one of the node 201, the network to which the node 201 belongs, or the access control application 211 into a control flow table ( 315) can be stored. Information stored in the control flow table 315 may be used for user authentication of the node 201 , information update of the node 201 , policy check for network access of the node 201 , and/or validation.

In operation 720, the controller 202 connects from the access policy database 311 and the channel policy database 312 corresponding to the identified information (eg, the node 201 and source network information to which the node 201 belongs). Whitelist information of possible applications can be created. In one embodiment, the controller 202 may send the application white list to the connection control application 211 at operation 725 .

In operation 725 , 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 access is unavailable or is included in the blacklist, the controller 202 may transmit access unavailability information in operation 725 without generating a control flow. In one embodiment, the controller 202 may transmit the application white list generated through the execution of operation 720 to the connection control application 211 .

At operation 730, the access control application 211 may perform a check on the application. For example, the access control application 211 can perform a check for applications based on the white list of accessible applications received from the controller 202 . The access control application 211 may check whether the application exists (installed) in the node 201 based on the accessible application information, and in the case of the existing application, integrity and stability are checked according to the validation policy ( Above the application, tampering inspection, code signing inspection, fingerprint inspection) can be performed.

At operation 735 , the access control application 211 may send the application check result to the controller 202 . For example, the access control application 211 may transmit information about existing applications and results of validation to the controller 202 .

In operation 740, the controller 202 may check whether the application is valid based on the received application information. If it is a valid application, the controller 202 selects the gateway 203 where the node 201 is located in the access policy database 311 and the authentication policy database 317 to allow access of the node 201 connected to the network. You can check. In addition, the controller 202 may generate a data flow based on source IP, destination IP, and port information so that the node 201 can transmit data packets without a network access request procedure. According to the embodiment, the data flow includes a method of inserting authentication information of a service application protocol (eg, HTTP header insertion in case of HTTP), information for encrypting or decrypting authentication information, algorithm information for generating and verifying authentication information, and It may include authentication information including a series of information included in the algorithm (e.g. information such as secret key when generating HMAC OTP). In addition, according to the embodiment, the data flow is such that the gateway 203, which exists between the network boundaries of the service server 205 on the connection path according to the policy, provides a permitted service request path or an unlicensed service for a service request. Filtering information for request paths (e.g. HTTP protocol or FTP protocol URI information, web API execution request path) and data that should not be transmitted (e.g. Cross Site Scripting for HTTP attacks, SQL Injection information, personal information, etc.) can include

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

In operation 755, the access control application 211 may process the resulting 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 indicating completion of the controller connection to the user. When the controller connection is completed, the request for network connection of the node 201 to the destination network may be controlled by the controller 202 .

According to another embodiment, controller 202 may determine that node 201 is unreachable. For example, if identification information of the node 201 and/or a network to which the node 201 belongs is included in a blacklist database, the controller 202 may determine that the node 201 is inaccessible. In this case, the controller 202 may transmit a response indicating that access to the controller is impossible in operation 725 without generating a control flow in operation 715 . Also, in this case, operations 730 to 750 may not be performed. Depending on the embodiment, if a controller connection needs to be retried, the connection control application 211 may perform operation 705 again.

In addition, the access control application 211 updates the data flow of the node 201 when the data flow received from the controller 202 exists, and transmits the data packet based on the data flow allowed in advance when accessing the network. data flow can be managed. Afterwards, when a data packet transmission request is detected, the access control application 211 may process the data packet to be transmitted based on authentication information included in the received data flow.

According to an embodiment, when it is determined that the application does not need to be inspected, operations 730 to 750 may not be performed.

8 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 authenticate the user of the node 201 from the controller 202 . According to an embodiment, node 201 may be substantially the same as authentication node 201 of FIG. 2 in which access control application 211 is installed.

Referring to FIG. 8 , node 201 may receive an input for user authentication. An input for user authentication may be, for example, a user input for inputting a user ID and password. For another example, the input for user authentication may be a user input (eg, biometric information) for stronger authentication. In this case, the access control application 211 of the node 201 may request user authentication from the controller 202 in operation 805 . If the 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 together with control flow identification information.

At operation 810 , controller 202 may authenticate the user based on the information received from node 201 . For example, the controller 202 may use the user ID, password, and/or enhanced authentication information included in the received information and a database included in the memory of the controller 202 (e.g., the access policy database of FIG. 3). 311 or the blacklist database 314), it is possible to determine 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 815, the controller 202 may add user identification information (eg, user ID) to identification information of the control flow. The added user identification information can be used for the authenticated user's controller access or network access.

The controller 202 may generate accessible application information based on the access policy database 311 or the channel policy database 312 in operation 820 . For example, the accessible application information may be an application whitelist generated based on an access policy.

In operation 825, the controller 202 may transmit information indicating that the user is authenticated to the node 201 in response to the user authentication request. In addition, the controller 202 may transmit accessible application information to the access control application 211 .

At operation 830, the access control application 211 may perform a check on the application. For example, the access control application 211 can perform a check for applications based on the white list of accessible applications received from the controller 202 . The access control application 211 may check whether the application exists (installed) in the node 201 based on the accessible application information, and in the case of the existing application, integrity and stability are checked according to the validation policy ( Above the application, tampering inspection, code signing inspection, fingerprint inspection) can be performed.

At operation 835 , the access control application 211 may transmit the application check result to the controller 202 . For example, the access control application 211 may transmit information about existing applications and results of validation to the controller 202 .

In operation 840, the controller 202 may check whether the application is valid based on the received application information. If it is a valid application, the controller 202 selects the gateway 203 where the node 201 is located in the access policy database 311 and the authentication policy database 317 to allow access of the node 201 connected to the network. You can check. In addition, the controller 202 may generate a data flow based on source IP, destination IP, and port information so that the node 201 can transmit data packets without a network access request procedure. According to the embodiment, the data flow includes a method of inserting authentication information of a service application protocol (eg, HTTP header insertion in case of HTTP), information for encrypting or decrypting authentication information, algorithm information for generating and verifying authentication information, and It may include authentication information including a series of information included in the algorithm (eg, information such as Secret Key when generating HMAC OTP). In addition, according to the embodiment, the data flow is such that the gateway 203, which exists between the network boundaries of the service server 205 on the connection path according to the policy, determines the permitted service request path or the unauthorized service for the service request. Filtering information on the request path (e.g. HTTP protocol or FTP protocol URI information, web API execution request path) and data that should not be transmitted (e.g. Cross Site Scripting for HTTP attacks, SQL Injection information, personal information, etc.) can include

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

In operation 855, the access control application 211 may process the resulting 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 indicating completion of user authentication to the user. When user authentication is complete, the request for network access of the node 201 to the destination network may be controlled by the controller 202 .

According to another embodiment, controller 202 may determine that user authentication of node 201 is not possible. For example, if 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 and user authentication is not possible. . In this case, the controller 202 may not reflect user identification information in operation 815 and may transmit a response indicating that access to the controller is impossible in operation 825 . Also, in this case, operations 830 to 850 may not be performed.

In addition, the access control application 211 updates the data flow of the node 201 when the data flow received from the controller 202 exists, and transmits the data packet based on the data flow allowed in advance when accessing the network. data flow can be managed.

According to an embodiment, operations 830 to 850 may not be performed when the application test is not required.

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

After node 201 is authorized by controller 202, node 201 controls the network access of other applications stored in node 201 through node 201's access control application 211 to provide trusted data. delivery can be guaranteed. According to an embodiment, node 201 may be substantially the same as authentication node 201 of FIG. 2 in which access control application 211 is installed.

In operation 905 , the connection control application 211 may detect a network connection event of another application stored in the node 201 (eg, the first target application 212 of FIG. 2 ).

In operation 910, the access control application 211 may check the existence of a data flow corresponding to 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, if a data flow exists, the access control application 211 may transmit a data packet based on the data flow. According to the embodiment, the access control application 211 of the node 201 may perform a network access request in operation 915 without performing operation 910 .

When the data flow needs to be updated, such as when the data flow does not exist or when the authentication time expires and renewal is required, in operation 915, the access control application 211 may request the controller 202 to access the network. For example, the network access request may include control flow identification information, destination network identification information, and port information.

In operation 920, the controller 202 determines the access requested identification information (eg, destination network identification information) in the access policy corresponding to the identified information (eg, node, user, source network identification information) based on the control flow identification information. and port information) and whether the destination network is accessible can be checked. According to an embodiment, the controller 202 may check whether the target application can access the gateway 203 or the service server 205 . Depending on the embodiment, the controller 202 may transmit a connection failure result to the connection control application 211 of the node 201 when network access is impossible (operation 935).

If access is possible, in operation 925, the controller 202 may check whether a channel between the node 201 and the gateway 203 can be created, whether data packet authentication is required, and an authentication method based on the channel policy and the authentication policy.

Based on the channel policy, the controller 202 may check whether a channel such as tunneling or session to be created between the node 201 and the gateway 203 can be created in order to access the corresponding network. For example, if a channel can be created, but accessible channel information or valid data flow information does not exist in the data flow table, the channel A data flow including creation information may be created. According to an embodiment, when channel creation is not required, the controller 202 may not generate a data flow including channel creation information.

The controller 202 may check whether a valid data flow corresponding to the identification information and port information of the destination network exists in the data flow table. According to the embodiment, if a valid data flow exists in the data flow table, the controller 202 may transmit the corresponding data flow to the gateway 203 and the access control application (operations 930 and 935). According to another embodiment, when a valid data flow does not exist, the controller 202 may create a data flow based on source IP, destination IP, port information, authentication policy, and service filtering policy. In this case, the controller 202 may transmit the generated data flow to the gateway 203 and the access control application (operations 930 and 935). According to the embodiment, the data flow includes a method of inserting authentication information of a service application protocol (eg, HTTP header insertion in case of HTTP), information for encrypting or decrypting authentication information, algorithm information for generating and verifying authentication information, and It may include authentication information including a series of information included in the algorithm (eg, information such as Secret Key when generating HMAC OTP). In addition, according to the embodiment, the data flow is such that the gateway 203, which exists between the network boundaries of the service server 205 on the connection path according to the policy, determines the permitted service request path or the unauthorized service for the service request. Filtering information on the request path (e.g. HTTP protocol or FTP protocol URI information, web API execution request path) and data that should not be transmitted (e.g. Cross Site Scripting for HTTP attacks, SQL Injection information, personal information, etc.) can include According to another embodiment, when network access is impossible or when authentication between the node 201 and the gateway 203 is impossible and subject to filtering, the controller 202 transmits a network access failure result to the access control application in operation 935. can

At operation 940 , the connection control application 211 of the node 201 may process the resulting value of the response received from the controller 202 . For example, when the connection control application 211 receives a network connection failure result from the controller 202, it may drop a data packet to be transmitted by the target application. For another example, when a data flow is received from the controller 202 and channel creation is not required, the access control application 211 may transmit a data packet based on the received data flow.

According to the embodiment, the access control application 211 may receive a data flow including channel creation information and create a channel with the gateway 203 if channel creation is necessary (operation 945). For example, when channel creation is complete, the access control application 211 may transmit a data packet based on the created channel. For another example, if channel creation fails, the access control application 211 may drop the data packet.

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

10 illustrates an operational flow diagram for processing a service request at a gateway according to various embodiments. Depending on the embodiment, the operations shown in FIG. 10 may be performed through the gateway 203 of FIG. 2 .

At operation 1005, gateway 203 may detect a data packet reception event. For example, gateway 203 may receive a data packet from a node (eg, authentication node 201 of FIG. 2).

In operation 1010, the gateway 203 may check whether or not the target transmitting the received data packet is an authorized target. For example, each module (eg, a filtering module, a tunneling module, a channeling module, a proxy module, etc.) included in the gateway 203 may check whether a target to which the data packet is transmitted is an authorized target. Depending on the embodiment, if the target to which the data packet is transmitted is not an authorized target, the gateway 203 may drop the received data packet.

If the target to which the data packet is transmitted is an authorized target, in operation 1020, the gateway 203 may receive and process the data packet. For example, the gateway 203 requests service processing to a service server (e.g., the service server 205 of FIG. 2) based on the service processing request information included in the received data packet, or requests that the service request is impossible. results can be returned.

At operation 1025, gateway 203 may check the data flow. For example, the gateway 203 includes source IP, destination IP and port information included in service processing request information, session identification information included in protocol information and service processing request information, data flow identification information, and additional information received from other modules. It is possible to check whether a data flow exists through at least one of the identification information. Depending on the embodiment, when a data flow does not exist but it is necessary to forward a service processing request, the gateway 203 may forward the service processing request to a designated path according to a service processing policy. According to another embodiment, when a data flow does not exist and service processing request failure must be handled, the gateway 203 may return information for redirection or service request failure information.

If the data flow exists, in operation 1040, the gateway 203 may check the service processing request information. For example, the gateway 203 may check service processing request information based on service filtering information included in the data flow. Depending on the embodiment, if there is a service request path that cannot access service processing request information (eg, URI information on HTTP protocol or FTP protocol, Web API execution request path, etc.) or if it is not an authorized service request path , the gateway 203 may return service processing request failure information (operation 1055). Depending on the embodiment, if data that should not be transmitted is included in the service processing request information (eg, Cross Site Scripting for HTTP attacks, SQL Injection information, personal information, etc.), the gateway 203 returns service processing request failure information Yes (act 1055).

If the service processing request information check is successful, in operation 1045, the gateway 203 may insert a data flow header. For example, the gateway 203 may extract an authentication information generation algorithm and additional information based on authentication information included in the data flow, and generate authentication information based on the extracted authentication information generation algorithm and additional information. can In addition, the gateway 203 may encrypt the generated authentication information based on an encryption algorithm and an encryption key included in the authentication information of the data flow. The gateway 203 may insert a data flow header in which encrypted authentication information and data flow identification information are combined into service processing request information according to a protocol standard of a service application. Depending on the embodiment, the gateway 203 may insert a data flow header at the most suitable location of service processing request information based on the protocol standard of the service application.

When the data flow header is normally inserted, in operation 1050, the gateway 203 converts the service processing request information into which the data flow header is inserted based on the service server (eg, service server 205 of FIG. 2) information of the data flow. Forwarding is possible.

Depending on embodiments, operations 1025 to 1055 may be performed through a proxy module included in the gateway 203 (eg, the proxy module 233 of FIG. 6 ).

11 illustrates an operational flow diagram for processing a service request in a service server according to various embodiments.

In operation 1105, the service server 205 may detect a service processing request event. For example, the service server 205 may receive and process a service processing request received from a network.

In operation 1110, the service server 205 may check the source IP of the received service processing request. For example, the service server 205 may determine whether the service processing request is an authorized gateway based on whether a source IP included in the service processing request is an IP of an authorized gateway. For another example, the service server 205 may examine the source IP of the service processing request in order to distinguish between a case in which a non-authenticated node requests and a case in which the gateway 203 receives and forwards a request from an authenticated node. Depending on the embodiment, the service server 205 may process the service processing request as being a request from an authenticated node when it is a request from an authorized gateway. Depending on the embodiment, the service server 205 may process the service processing request as a request from an unauthorized node when it is not a request from an authorized gateway.

If the source IP is not the IP transmitted by the allowed (or authorized) gateway 203, the service server 205 regards it as a service processing request sent by an unauthorized node and processes the service processing request according to the corresponding security level. can do. Depending on the embodiment, when session information of an authenticated user is included in the service processing request transmitted by the non-authentication node, the service server 205 may de-authenticate the corresponding user according to a policy.

If the source IP is the IP transmitted by the allowed (or authorized) gateway 203, in operation 1115, the service server 205 may examine the data flow header. For example, the service server 205 may check whether a data flow header is included in service processing request information. Depending on the embodiment, when the data flow header is not included in the service processing request information, the service server 205 may return service processing request failure information.

When the data flow header is included in the service processing request information, in operation 1120, the service server 205 requests the controller 202 to authenticate the data flow based on the data flow identification information and the data flow authentication information included in the data flow header. can be performed. For example, the data flow authentication request may include data flow identification information and data flow authentication information.

At operation 1125, the controller 202 may perform a data flow authentication check. For example, the controller 202 may check whether a corresponding data flow exists in the data flow table using the received data flow identification information. Depending on the embodiment, if the data flow does not exist, the controller 202 may transmit data flow authentication failure information to the service server 205 (operation 1130).

When the data flow exists, the controller 202 may decrypt the authentication information based on the authentication information decryption algorithm and the decryption key included in the authentication information of the data flow to perform the data flow authentication information check. Depending on the embodiment, if authentication information decryption fails, the controller 202 may transmit data flow authentication failure information to the service server 205 (operation 1130).

If authentication information decryption is successful, the controller 202 may check whether the decrypted authentication information is valid based on an authentication information check algorithm or additional information included in the authentication information of the data flow. Depending on the embodiment, if the authentication information is invalid, the controller 202 may transmit data flow authentication failure information to the service server 205 (operation 1130).

If the authentication information is valid, the controller 202 determines that the target of the service request, such as the node, user, application, etc., that has requested service processing in the access policy based on application identification information, destination IP and port information, and control flow information included in the data flow, It is possible to check whether access to the service server 205 is possible. Depending on the embodiment, when the service request target cannot connect to the service server 205, the controller 202 may transmit data flow authentication failure information to the service server 205 (operation 1130).

If the service request target can access the service server 205, the controller 202 authenticates the service request target in the service server 205 based on the authentication policy, and additional information required for authentication (authenticated node, Data flow and data flow authentication success information including user, application identification information, access method, access location, and the like) may be transmitted to the service server 205 (operation 1130).

In operation 1135 , the service server 205 may process a result value based on the authentication check result received from the controller 202 . For example, if data flow authentication fails, the service server 205 may return service processing request failure information. For another example, if the data flow authentication is successful, the service server 205 based on the received data flow and authentication information (information including the authenticated node, user, application identification information, access method, access location, etc.) Service authentication processing may be performed by matching with user identification information stored in the service server 205, and a service request processing result for a service processing request may be returned.

According to an embodiment, the service server 205 periodically synchronizes the data flow with the controller 202. A data flow may be stored so as to periodically check whether a user corresponding to the corresponding data flow is accessing.

12 shows a signal flow diagram for updating data flow according to various embodiments.

The service server 205 synchronizes the data flow with the controller 202 periodically. It may periodically check whether a user corresponding to the corresponding data flow is accessing.

In operation 1205 , the service server 205 may request a data flow update to the controller 202 . For example, the service server 205 may transmit a data flow identification information list to the controller 202 based on the data flow received from the controller 202 .

At operation 1210, the controller 202 may update the data flow. For example, the controller 202 may check whether a data flow corresponding to the received data flow identification information exists. Depending on the embodiment, if the data flow does not exist, since the node or user corresponding to the corresponding data flow has terminated the network connection, the controller 202 can no longer use the authentication information of the corresponding data flow in the service server 205. Invalid data flow information may be transmitted to the service server 205 so that the network cannot be accessed (operation 1215).

When the data flow exists, in operation 1215 , the controller 202 may transmit information indicating that the data flow exists to the service server 205 . That is, in operation 1215 , the controller 202 may transmit the data flow update result to the service server 205 .

In operation 1220, the service server 205 may process the resulting value based on the data flow update result received from the controller 202. For example, the service server 205 may delete an invalid data flow based on the received data flow information, and delete session information managed by the service server 205 itself with the deleted data flow. and the subject authenticated with the deleted session can be processed so that it can no longer access.

13 illustrates a signal flow diagram for transmitting a log of a gateway according to various embodiments.

At operation 1305 , gateway 203 may transmit data packet drop and service request rejection logs to controller 202 . For example, in at least one case of dropping a data packet, filtering a service request, or rejecting a service request, the gateway 203 transmits the data packet or performs the service request. A log related to may be recorded, and the recorded log may be transmitted to the controller 202 .

At operation 1310, the controller 202 can analyze the log and update the data flow. For example, the controller 202 may determine which target periodically drops data packets or rejects service requests based on the received log, and may delete or update a data flow related to the target.

In operation 1315 , the controller 202 may transmit the update result to the gateway 203 . For example, the controller 202 may transmit an updated data flow to the gateway 203 .

In operation 1320, the gateway 203 may process the resulting value based on the updated result received from the controller 202. For example, when receiving an updated data flow, the gateway 203 may update an existing data flow based on the updated data flow.

14 illustrates 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 the control flow identification information.

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

The controller 202 may update the update time when a control flow exists in the control flow table (eg, the control flow table 315 of FIG. 3 ). In this case, the controller 202 may transmit identification information of the updated control flow to the connection control application 211 (operation 1420).

In one embodiment, the controller 202 is required to perform re-authentication among data flows subordinate to the identified control flow, or if there is a data flow to which access is no longer possible, the controller 202 transmits information about the corresponding data flow to an access control application ( 211) (operation 1420).

At operation 1425 , the connection control application 211 of the node 201 may process the resulting value of the response received from the controller 202 . For example, the access control application 211 may block all network accesses of applications when the control flow update result is impossible. For another example, the access control application 211 may update the data flow when the control flow update result is normal and updated data flow information exists.

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

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

In 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. Thus, node 201 can no longer connect to the destination network based on the removed data flow.

In operation 1525, the controller 202 may request the gateway 203 to remove all data flows dependent on the removed control flow. The gateway 203 may remove the data flow, and thus data packets corresponding to source network, destination network, and port information included in the removed data flow may no longer be transmitted.

16 illustrates a signal flow diagram for termination of application execution according to various embodiments.

Referring to FIG. 16 , in operation 1605, the access control application 211 of the node 201 may check in real time whether or not the running application is terminated, and may detect an application execution end event.

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

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

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

17 is a flowchart of a method of operating a gateway according to various embodiments. Operations shown in FIG. 17 may be performed through the gateway 203 of FIG. 2 .

At operation 1705, gateway 203 may receive a data packet.

In operation 1710, the gateway 203 may check whether the data packet is a data packet received from an authorized subject.

In operation 1715, the gateway 203 may check whether a data flow corresponding to the service processing request information of the data packet and authorized from the external server exists.

In operation 1720, the gateway 203 may check the service processing request information if there is a data flow.

In operation 1725, the gateway 203 may process the data packet based on a result of checking the service processing request information. For example, the gateway 203 may drop a data packet based on a test result or insert a data flow header into service processing request information of the data packet.

18 is a flowchart of a method of operating a service server according to various embodiments. Operations shown in FIG. 18 may be performed through the service server 205 of FIG. 2 .

In operation 1805, the service server 205 may determine whether the service processing request was forwarded by the gateway or a non-authenticated node based on the source IP of the service processing request. For example, the service server 205 may check whether the service processing request is an authorized gateway based on whether a source IP included in the service processing request is an IP of an authorized gateway. Depending on the embodiment, the service server 205 may confirm that the request is from an authenticated node when the source IP is the IP of the authorized gateway. Depending on the embodiment, the service server 205 may confirm that the request is from an unauthorized node when the source IP is not the IP of the authorized gateway.

In operation 1810, the service server 205 may process a service accessible to the unauthenticated node based on the database when the service processing request is the request of the unauthenticated node.

In operation 1815, when the service processing request is from an authenticated node, the service processing request may be processed based on whether a data flow header is included in service processing request information.

The above description is only an illustrative example of the technical idea disclosed in this document, and those skilled in the art to which the embodiments disclosed in this document belong will be within the scope of the essential characteristics of the embodiments disclosed in this document. Many modifications and variations will be possible.

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

Claims (15)

1. in the gateway,

   communication circuit;

   a memory for storing a database; and

   a processor in operative connection with the communication circuitry and the memory, the processor comprising:

   receive data packets;

   confirming that the data packet is a data packet received from an authorized target;

   Corresponding to the service processing request information of the data packet and confirming whether there is a data flow authorized from an external server;

   Examining the service processing request information if the data flow exists;

   The gateway configured to process the data packet based on a result of checking the service processing request information.
2. The method of claim 1, wherein the processor,

   a data packet filtering module for filtering the data packet;

   Tunneling module for tunneling-based communication; and

   Include a proxy module,

   When the data packet is received, check whether the data packet is received from an authorized target through the data packet filtering module or the tunneling module;

   and check whether the data flow exists through the proxy module when the data packet is received from the authorized object.
3. According to claim 2,

   The filtering module and the tunneling module,

   When the data packet is received from the authorized target, inserting information on the authorized target into the service processing request information of the data packet and forwarding the information to the proxy module;

   wherein the proxy module is configured to check whether the data flow exists based on the information about the authorized object.
4. The method of claim 2, wherein the proxy module,

   Based on the database, identify a destination that has transmitted the data packet and a service application requested by the destination;

   and inserting a data flow header into the service processing request information based on authentication information included in the data flow and a protocol of the service application.
5. According to claim 4,

   The data flow header,

   A gateway comprising encryption information of the authentication information and identification information of the data flow.
6. According to claim 4,

   The authentication information includes at least one of a method for inserting authentication information, a cycle for inserting authentication information, a maximum number of authentication times for an authentication algorithm, information for encryption/decryption of authentication information, and an algorithm for generating authentication information, gateway.
7. The method of claim 1, wherein the processor,

   Examining the service processing request information based on the service filtering information of the data flow;

   Returning service processing request failure information to a destination that sent the data packet when a service request path that cannot access the service processing request information exists or is not an authorized service request path;

   If the service processing request information includes data that cannot be transmitted, returning the service processing request failure information to the target that sent the data packet;

   and forwarding the data packet to a service server when the service processing request information check succeeds.
8. The method of claim 1, wherein the processor,

   Sending data packet drop and service request rejection logs to the external server;

   Receiving an updated data flow from the external server;

   and update the database based on the updated data flow.
9. In the service server,

   communication circuit;

   a memory containing a database; and

   a processor in operative connection with the communication circuitry and the memory, the processor comprising:

   Receive service processing requests;

   Confirm whether the service processing request is a request of the authorized gateway based on whether the source IP included in the service processing request is an IP of an authorized gateway;

   If the service processing request is a request of the authorized gateway, the service server configured to process the service processing request based on whether a data flow header is included in the service processing request.
10. The method of claim 9, wherein the processor,

    If the service processing request is not a request from the authorized gateway, the service server is configured to process a service accessible to an unauthorized node based on the database.
11. The method of claim 9, wherein the processor,

    Return service processing request failure information when the data flow header is not included in the service processing request information.

    When the data flow header is included in the service processing request information, a data flow authentication request is requested to an external server based on data flow identification information and data flow authentication information included in the data flow header;

    The service server configured to process the service processing request based on a response to the data flow authentication request received from the external server.
12. The method of claim 11, wherein the processor,

    If the data flow authentication fails, return service processing request failure information;

    If the data flow authentication is successful, processing a service corresponding to the service request based on the received data flow and authentication information;

    A service server, configured to return the processing result.
13. The method of claim 9, wherein the processor,

    Send the list of data flow identification information to an external server,

    Receiving an updated data flow from the external server;

    The service server configured to update the database based on the updated data flow.
14. In the operation method of the gateway,

    receiving a data packet;

    checking whether the data packet is received from an authorized target;

    checking whether a data flow corresponding to the service processing request information of the data packet and authorized from an external server exists;

    checking the service processing request information if the data flow exists; and

    processing the data packet based on a result of checking the service processing request information; Including, method.
15. In the operating method of the service server,

    receiving a service processing request;

    determining whether the service processing request is a request of the authorized gateway based on whether a source IP included in the service processing request is an IP of an authorized gateway; and

    processing the service processing request based on whether a data flow header is included in the service processing request when the service processing request is a request of the authorized gateway; Including, method.

Images