WO2023211104A1

WO2023211104A1 - System for controlling controller-based network access, and method related thereto

Info

Publication number: WO2023211104A1
Application number: PCT/KR2023/005573
Authority: WO
Inventors: 김영랑
Original assignee: 프라이빗테크놀로지 주식회사
Priority date: 2022-04-25
Filing date: 2023-04-24
Publication date: 2023-11-02
Also published as: KR102495369B1

Abstract

A node according to one embodiment disclosed in the present document stores instructions for sensing a network access event through an access control application, confirming the presence of a data flow, which corresponds to a data packet to be transmitted by a target application and is applied from an external server, confirming the type of the data packet, permitting the transmission of a TCP SYN packet on the basis of whether the TCP SYN packet can be transmitted on the basis of the type of the data packet, performing a network access authentication check after the generation of a TCP session or if it is unnecessary to check the TCP SYN packet, and processing data packets transmitted thereafter on the basis of the authentication check result, wherein the data flow can include information about whether to fundamentally permit the transmission of the TCP SYN packet.

Description

System and method for controlling controller-based network access

Cross-citation with related applications

The present invention claims the benefit of priority based on Korean Patent Application No. 10-2022-0050926 filed on April 25, 2022, and all contents disclosed in the document of the Korean Patent Application are included as part of this specification.

Technology field

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

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

In general, communication between nodes and servers uses IP (Internet Protocol)-based TCP (Transmission Control Protocol), and access control is performed by identifying the source IP, destination IP, and port information with 5 Tuples information included in the data packet. Firewall technology is commonly used.

Firewall technology identifies IPs assigned to nodes or network nodes and performs access control for inbound or outbound data packets between network boundaries, thereby blocking unauthorized IPs from accessing unauthorized destination networks.

Technologies such as IP-based firewalls may cause problems where IP-based control is difficult in the case of nodes in the Internet band where IP allocation and control are difficult, or when private IP bands are created by configuring subnetworks with routers and gateways. In practice, firewalls are used as a minimum security device.

To solve the above problems, data packets transmitted between nodes and servers or gateways are encrypted, or connectivity controls such as tunneling technology or security sessions are used to prevent forgery and alteration and to allow unique access only to authorized subjects. Technology is being used.

However, VPN (Virtual Private Network) based on tunneling technology created at the terminal level has a vulnerability that allows unauthorized or insecure applications to access unauthorized destination networks through tunneling that is always connected after initial authentication when used. In other words, with regard to the above vulnerabilities, VPN technology is experiencing an increase in security incidents caused by various malware and ransomware infiltration.

In addition, with the recent complexity of business, communication between servers has increased on always-connected networks, and the target application running within the server is a Micro Service Architecture in which all service logic operates separately in modules or functional units rather than in a single application. As the form develops, the identification unit of actual communication changes to communication at a module or functional level that is lower than the application, and network access control technology at a lower level than the application is required.

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

A node according to an embodiment disclosed herein includes a communication circuit, a processor operatively connected to the communication circuit, and a memory operatively connected to the processor and storing a connection control application and a target application, When the memory is executed by the processor, the node detects a network connection event through the access control application and confirms the existence of a data flow authorized from an external server that corresponds to the data packet that the target application wants to transmit, Check the type of the data packet, allow transmission of the TCP SYN packet based on whether the TCP SYN packet can be transmitted based on the type of the data packet, and do not require inspection of the TCP SYN packet after creating a TCP session or Stores instructions for performing a network connection authentication check and processing subsequently transmitted data packets based on the results of the authentication check, and whether the data flow will basically allow transmission of the TCP SYN packet. May contain information.

A method of operating a connection control application installed in a node according to an embodiment disclosed in this document includes detecting a network connection event, detecting the existence of a data flow authorized from an external server corresponding to a data packet to be transmitted by the target application, Confirming, confirming the type of the data packet, allowing transmission of the TCP SYN packet based on whether the TCP SYN packet can be transmitted if the data packet is a TCP SYN packet, and if the data packet is an authentication data packet If so, performing a network connection authentication check, and dropping the data packet if the data packet is not the TCP SYN packet and the authentication data packet, and the data flow basically involves transmission of the TCP SYN packet. It may include information about whether to allow it or not.

According to embodiments disclosed in this document, application connectivity control technology that allows only permitted safe applications to access the permitted network is applied to identify the application that is the fundamental communication subject and prevent access to unauthorized applications in advance. By doing so, various malware and ransomware can be prevented from accessing unauthorized destination networks, and at the same time, various currently occurring network security problems can be effectively solved.

According to the embodiments disclosed in this document, due to the increase in data dam, my data, and AI services, communication in modules or functional units can be controlled in a more detailed unit than the application, and data or data held by the data provider In order to deliver data entrusted by the owner to the data consumer, the network access can be controlled so that the permitted module transmits only data permitted by the data owner or permitted by policy in advance.

According to the embodiments disclosed in this document, the results of AI calculations centered on Data Centric Networking overlaid on a conventional IP-based network and countless processed valuable data stored in the server are transmitted to the consumer and provide actual value. It can be used as a base technology for granting.

In addition, according to the embodiments disclosed in this document, in order to control network access in module units and data units that cannot be controlled by conventional application connectivity control technology, a lower level than an application that cannot be identified in the operating system (Kernel Level) is used. For unit identification, an additional identification layer can be inserted when connecting to a network in the target application (User Level), providing a method to control network access at the module or data level.

In addition, according to the embodiments disclosed in this document, when a module or function in the target application (User Level) that cannot be identified in the operating system (Kernel Level) connects to the network and transmits data, the target application transmits data when connected to the network. It is possible to provide a structure that allows or disallows network access depending on whether to allow network access containing the identification information by checking each identification information included in one authentication data packet with the controller.

In addition, according to the embodiments disclosed in this document, whitelist-based network access is permitted for each identification unit according to the authentication policy of the controller set in advance, or a third party (e.g., data owner) is allowed to access the network of the corresponding identification unit. By additionally checking whether to allow access, it is possible to provide a structure that allows network access only with third-party approval. Since network access for each identification unit is recorded, it is possible to inquire what data was transmitted by which module and when. We can provide a way to do this.

In addition, according to the embodiments disclosed in this document, when Data Centric Networking is configured to transmit the credit information of the data owner entrusted to the credit institution to another institution, the data owner's credit information data is approved by the entrusted credit institution. In order to control transmission to other organizations, only the data permitted by the user can be created at the time of data provision to other organizations permitted by the permitted data supply agency, and the network connection can be disconnected at the end of data provision. Because it can provide technology that can be used, it can provide a way to reach the actual purpose of My Data.

In addition, according to the embodiments disclosed in this document, various authentication information (e.g., public key-based encryption and decryption key and certificate), data information signed based on the authentication information (e.g., approved data propagation on a blockchain network) ) It is always connected to the network, such as transmission, personal information stored in the cloud, etc., but it connects to the Internet only when remote storage containing information that must be isolated from the Internet is required, thereby blocking external risks coming from the Internet. , By transmitting only permitted data, it is possible to block unauthorized subjects from transmitting unauthorized data (e.g., when personal information is arbitrarily leaked by a thief).

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

Figure 1 shows an environment including multiple networks.

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

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

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

Figure 5 is a diagram showing the structure of an authentication data packet according to various embodiments.

Figure 6 is a diagram showing an operation for controlling transmission of data packets according to various embodiments.

Figure 7 shows a signal flow diagram for connecting a node to a controller according to various embodiments.

Figure 8 shows an operation flowchart for network connection of a node according to various embodiments.

FIG. 9A shows a signal flow diagram for checking network connectivity of a node according to various embodiments.

FIG. 9B shows a signal flow diagram for checking network connection authentication of a node according to various embodiments.

Figure 10 shows a signal flow diagram for transmitting a data packet of a node according to various embodiments.

Figure 11 shows a signal flow diagram for controlling reception of data packets by a gateway according to various embodiments.

Figure 12 shows a signal flow diagram for updating the control flow of a node according to various embodiments.

Figure 13 shows a signal flow diagram for disconnection of a node according to various embodiments.

Figure 14 shows a signal flow diagram for termination of application execution of a node according to various embodiments.

Figure 15 shows an operation flowchart of a method of operating an access control application installed in a node according to various embodiments.

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

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

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

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

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

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

Figure 1 shows an environment including multiple networks.

Referring to FIG. 1, the first network 10 and the second network 20 may be different networks. For example, the first network 10 may be a public network such as the Internet, and the second network 20 may be a private network such as an intranet or VPN. Depending on the embodiment, the first network 10 may include the data provider network 210 of FIG. 2, and the second network 20 may include the data consumer network 220 of FIG. 2.

The first network 10 may include a source node 101. In FIG. 1 and the embodiments described below, the 'source node' may be various types of devices capable of performing data communication. For example, the source node 101 may be a portable device such as a smartphone or tablet, a computer device such as a desktop or laptop, a multimedia device, a medical device, a camera, a wearable device, or a virtual reality (VR) device. , or home appliances and is not limited to the above-mentioned devices. For example, the source node 101 may include a server or gateway that can transmit data packets through an application. The source node 101 may also be referred to as an ‘electronic device’ or a ‘terminal’. Meanwhile, the destination node 102 may include the same or similar device as the above-described source node 101. As another example, the destination node 102 may be substantially the same as the destination network.

The source node 101 may attempt to access the second network 20 and transmit data to the destination node 102 included in the second network 20. The source node 101 may transmit data to the destination node 102 through the gateway 103 and tunnel 105. However, the data is not limited to this, and the source node 101 may transmit data to the destination node 102 through various paths such as tunnels, security sessions, and channels.

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

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

Referring to FIG. 2, the number of nodes 201, gateways 203, destination networks 204, data provider networks 210, and data consumer networks 220 is not limited to the number shown in FIG. 2. For example, a plurality of nodes may have network access controlled by the controller 202, and the controller 202 may communicate with a plurality of gateways and control transmission of data to a plurality of destination networks.

Node 201 may include a connection control application 211 and a target application 221. For example, the access control application 211 checks whether a connection is possible from the controller 202 when a network connection occurs, and only if a connection is possible, connects to the destination through the gateway 203 based on the data flow generated by the controller 202. Data packets may be transmitted to the network 204. For example, the gateway 203 may include a first gateway 213 that exists at a network boundary on the node 201 side and a second gateway 223 that exists on a network boundary on the destination network 204 side.

Data flow-based connectivity control technology provides a structure in which communication is possible only when a data flow authorized by the controller 202 exists for the node 201 to access the destination network 204, and when no data flow exists, If not, a structure in which the node 201 cannot communicate may be provided. For example, the access control application 211 may restrict transmission of data packets of the target application 212 when a data flow does not exist.

Controller 202 may be a server (or cloud server). The controller 202 may perform network access control for the destination network 204 of the node 201.

According to one embodiment, the controller 202 transmits and receives control data packets with the node 201 to perform various operations (e.g., registration, approval, authentication, renewal, termination) associated with the network connection of the node 201. You can. The flow through which control data packets are transmitted may be referred to as a control flow.

Through the above-described operations, the controller 202 can provide an environment in which access to the destination network 204 of unauthorized nodes can be blocked.

The gateway 203 may include a first gateway 213 and a second gateway 223. For example, the gateway 203 may provide technology to safely transmit data packets in a network section through a secure channel. In addition, the gateway 203 checks whether the data packet received from the access control application 211 is actually transmitted by the permitted node 201, and detects the data packet transmitted by bypassing the access control application 211. It can play a blocking role. In other words, the gateway 203 can enable a secure network configuration at all times throughout the data provider network 210 and the data consumer network 220.

Data owner 206 may communicate with controller 202. The controller 202 can allow whitelist-based network access for each identification unit according to the authentication policy, and additionally checks whether the data owner 206 will allow network access for the corresponding identification unit, so that the data owner (206) 206) can provide a structure that allows network access only with approval. Additionally, since network access can be recorded for each identification unit, the data owner 206 can inquire when and where which module transmitted what data.

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

The administrator can connect to the controller 202 and set a connection-critical policy to control the connection between the application and the server, so it can provide security such as existing NAC (Network Access Control) and firewalls that simply perform access control based on IP. Network access control is possible in more detail than the technology and is more secure from a network access perspective.

The access policy database 311 may include information about networks and/or services to which an identified network, node (e.g., node 201 in FIG. 2), user, unidentified user, or application can access. For example, when connection to a destination network is requested from a node, the controller identifies the network (e.g., the network to which the node belongs), node, user (e.g., user of the node), and And/or it may be determined whether the application (application included in the node) can connect to the destination network.

The authentication policy database 312 identifies the access target at a more detailed level than the application, which is the minimum unit of access control in the access policy (e.g., information included in the access policy database 311), and identifies the access target to which the identified target can access. May include service information. For example, when a network access request exists with the corresponding identification information, the authentication policy database 312 determines whether to always allow access to services accessible by policy or to other systems or third parties connected to the controller (e.g. : Can include whether to allow access only when approved by the data owner). For another example, the authentication policy database 312 determines whether to continuously allow network access after network access is permitted or determines whether certain conditions (e.g., TCP SYM Packet, TCP FIN Packet, and the amount of transmitted data packets are related to the data flow). This can include whether to release the network connection and re-perform data packet authentication if rules such as exceeding the amount of included data packets or including update processing characters for data packets included in the data flow are met. there is. Additionally, the authentication policy database 312 may include whether to perform data packet authentication only upon initial network connection or whether to check data packet authentication at every data packet transmission. Depending on the embodiment, the authentication policy database 312 may include a method for extracting and inspecting identification information included in an authentication data packet (eg, authentication information generation and inspection algorithms such as One time Password, HMAC, etc.). Depending on the embodiment, the authentication policy database 312 may provide an authentication policy that includes information about whether it is possible to transmit a data packet without additional authentication and information about changing the authentication status of the data flow when the update conditions of the data flow are met. It may contain information for generating information. That is, the controller 202 may generate authentication information based on the authentication policy database 312.

The blacklist policy database 313 may include policies for permanently or temporarily blocking access to nodes. The blacklist policy database 313 provides information (e.g., node, IP address, media access control) address, or at least one of the user ID).

The blacklist database 314 may include a list of at least one of nodes, IP addresses, MAC addresses, or users blocked by the blacklist policy database 313. For example, if a node requesting access to the destination network is included in the blacklist database 314, the controller may isolate the node from the destination network by rejecting the node's connection request.

The control flow table 315 is an example of a session table for managing the flow (e.g., control flow) of control data packets generated between a node and a controller. When successfully connecting to the controller, control flow information can be generated by the controller. The control flow information may include at least one of control flow identification information, an IP address identified when connecting to and authenticating the controller, a node ID, or a user ID. For example, when connection to a destination network is requested from a node, the controller can retrieve control flow information through the control flow identification information received from the node, and use the IP address, node ID, or user included in the retrieved control flow information. By mapping at least one of the IDs to the connection policy database 311, it can be determined whether the node can connect and whether a data flow for creating a TCP session with the destination network can be created.

According to one embodiment, a control flow may have an expiration time. The node must update the expiration time of the control flow, and if the expiration time is not updated within a certain period of time, the control flow (or control flow information) may be removed. Additionally, if it is determined that immediate connection blocking is necessary according to security events collected from the node, the controller may remove the control flow according to the node's connection termination request. If the control flow is removed, the previously created data flow is also removed, so the node's connection may be blocked.

The data flow table 316 is a table for managing the flow (eg, data flow) in which detailed data packets are transmitted between a node, a gateway, and a destination network. Data flows can be created as TCP sessions on a per-node or per-IP basis, applications on a node, or on a more granular basis. The data flow table 316 includes data flow identification information, control flow identification information if the data flow is dependent on the control flow, an application ID to identify whether the data packet transmitted from the node is an authorized data packet, and source network identification information. , may include destination network identification information and/or service port. The data flow table 316 determines whether to continuously allow network access after network access is permitted or determines under certain conditions (e.g., TCP SYM Packet, TCP FIN Packet, the amount of transmitted data packets is the amount of data packets included in the data flow). If it exceeds , it may contain authentication information including whether to release the network connection and re-perform data packet authentication if rules such as including update processing characters of data packets included in the data flow are met. . Depending on the embodiment, the authentication information may include whether to perform data packet authentication only upon initial network connection or whether to check data packet authentication at every data packet transmission. In addition, the data flow table 316 contains data flow status information (including whether data flow authentication has been completed and transmission is possible, authentication is required, or authentication is not required and network connection is possible without authentication. or authentication status information of the data flow).

Depending on the embodiment, the data flow table 316 may be equally included in a node (eg, node 201 in FIG. 2) and a gateway (eg, gateway 203 in FIG. 2).

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

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

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

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

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

Memory 420 may include one or more of volatile memory or non-volatile memory. Volatile memory includes dynamic random access memory (DRAM), static RAM (SRAM), synchronous DRAM (SDRAM), phase-change RAM (PRAM), magnetic RAM (MRAM), resistive RAM (RRAM), and ferroelectric RAM (FeRAM). It can be included. Non-volatile memory may include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, etc.

The memory 420 uses non-volatile media such as a hard disk drive (HDD), solid state disk (SSD), embedded multi media card (eMMC), and universal flash storage (UFS). More may be included.

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

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

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

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

A gateway (eg, gateway 203 in 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.

Existing data packets can be composed of a data packet structure that includes an IP header and payload containing 5 Tuples (source, destination information, etc.) information, which is a unit that can be identified in OSI (Open System Interconnection) during IP communication. .

In order to implement Micro Service Architecture and Data Centric Networking, target applications (e.g. : You may need to know whether the minimum identification unit (unit defined at the user level) within the target application 212 in FIG. 2 is connected to the network.

The target application (e.g., target application 212 in FIG. 2) is an authentication data packet (e.g., a single authentication data packet) containing information that can identify the included module or function, and data to identify that element when connected to the network. (510) and a data packet (520) using an authentication data packet as a header can be transmitted. In this case, the network access control application (e.g., the access control application 211 in FIG. 2) that controls network access in the node's operating system (kernel level) can check the received

authentication data packets

510 and 520, Authentication information is extracted from the

authentication data packets

510 and 520 and transmitted to a controller (e.g., controller 202 in FIG. 2) to check whether network access is permitted based on the authentication information, and A structure that allows network access can be provided based on whether network access is allowed.

The authentication information in the

authentication data packets

510 and 520 can identify a level that cannot be identified by the operating system (kernel), and is the minimum identification unit for which the target application requests network access permission when connecting to the network in order to control network access. may include. For example, the identification unit may include information such as a module, function, or data, and the identification unit may be assigned according to the intention of the target application developing and operating. As another example, the authentication information may include an authentication information generation algorithm specified by the controller to double check the network connection of the target application.

A single authentication data packet 510 may include an IP header and payload. For example, the payload of a single authentication data packet 510 may include an authentication data packet. Depending on the embodiment, the single authentication data packet 510 may be structured for initial network connection authentication.

The data packet 520 using the authentication data packet as a header may include an IP header, a payload including the authentication data packet, and a payload including the actual transmitted data packet. Depending on the embodiment, the data packet 520 using the authentication data packet as a header may be a data packet for checking consecutive data packets.

In one embodiment,

authentication data packets

510, 520 may include one or more pieces of authentication information.

Referring to FIG. 6, the node 201 is blocked at the kernel level of the network driver and operating system in the case of an unauthorized data packet for which no data flow exists among the data packets transmitted to the destination network 204 after connecting to the controller 202. You can. Accordingly, node 201 may not transmit any data packets that do not pass through access control application 211 to destination network 204 .

The access control application 211 must access the controller 202 to perform identification and authentication of a node or one or more identification information and applications, modules and functions included in the application, and data. After performing authentication, the access control application 211 queries the controller 202 for access network information when accessing the destination network 204 of the target application 212 to check whether access is possible, and determines whether the connection is possible, including the modules and functions of the authorized application, It can be controlled so that only objects such as data can access the network.

Unauthorized nodes or applications, modules, functions, and data included in the application are basically unable to access the destination network 204, and are sent from the controller 202 to the target application 212 and the modules included in the target application 212. And if the data flow information including connection information such as functions and data is not delivered to the first gateway 213 or the second gateway 223, the first gateway 213 or the second gateway 223 transmits the data packet. Because forwarding is blocked, the node 201 cannot reach the destination network 204, that is, it is in an isolated state.

In order for the node 201 to connect to or receive a network, it needs to be authorized by the controller 202, so the access control application 211 of the node 201 requests the controller 202 to create a control flow, thereby creating a node ( 201), you can try to connect to the controller.

Referring to FIG. 7, the connection control application 211 of the node 201 may request controller connection from the controller 202 in operation 705. For example, the connection control application 211 may perform a controller connection request to create a control flow with the controller 202. For example, the controller connection request may include information about the node 201 or the connection control application 211.

In operation 710, the controller 202 may check whether the connection control application 211 is in a state in which connection is possible according to the connection policy based on the connection request information. For example, the information requested for access by the access control application 211 may include the type of node 201, location information, environment, network in which the node 201 is included, and information about the access control application 211. there is.

In one embodiment, the controller 202 controls the access control application ( 211), connection inaccessibility information may be transmitted (operation 725).

If the node 201 is reachable, in operation 715, the controller 202 may create a connection control application 211 or a control flow between the node 201 and the controller 202. In this case, the controller 202 may generate control flow identification information in the form of a random number, and enter the identification information of the node 201 and/or the network to which the node 201 belongs in a control flow table (e.g., the control flow in FIG. 3). It can be stored in the table 315). Information (e.g., control flow identification information and/or control flow information) stored in the control flow table is used to authenticate the user of the node 201, update the information of the node 201, check the policy for network access of the node 201, and/ Or it can be used for validation. In one embodiment, the controller 120 may generate whitelist information for accessible applications in a connection policy that matches the node 201.

In operation 720, the controller 202 may create a whitelist of accessible applications based on an access policy matched with identification information of the node, user, and source network. When a whitelist is created, the controller 202 provides control flow identification information (e.g., ID) to identify the control flow when the connection is completed as a result of the connection and subsequent node user authentication requests and continuous update of node information are required. The application whitelist may be transmitted to the access control application 211 of the node 201 (operation 725).

Additionally, the controller 202 may check whether to allow data packets for which authentication has not been performed based on an authentication policy (e.g., the authentication policy database 312 of FIG. 3). In this case, the controller 202 can check information on whether unauthenticated network access is possible to determine whether the node 201 will allow network access without data packet authentication based on the authentication policy, and unauthenticated network access is possible. Availability information may be transmitted to the node 201 (operation 725).

Once the control flow is created, in operation 725, the controller 202 may transmit a response to the controller connection request to the connection control application 211 of the node 201. In this case, the controller 202 may transmit the generated control flow identification information to the access control application 211. In one embodiment, the controller 202 may transmit accessible application whitelist information to the access control application 211.

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

In operation 735, 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 on applications existing in the node 201 and the results of validation to the controller 202.

At operation 740, the controller 202 may check whether the application is valid based on the received application information. If the application included in the received application information is a valid application, the controller 202 sets the gateway 203 where the node 201 is located in the access policy to allow access to the node 201 connected to the network including the application. You can check, and in the authentication policy, you can create a data flow so that the application can pre-allow data packet transmission without data packet authentication. For example, a data flow can be created based on source IP, destination IP, and port information.

According to an embodiment, the controller 202 may check in the authentication policy whether to allow data packets for which authentication has not been performed. For example, the controller 202 determines whether the node 201 can connect to an unauthenticated network to determine whether to allow network access without data packet authentication or whether to basically allow transmission of TCP SYN packets. It may be transmitted to the control application 211 (operation 745).

In operation 745, the controller 202 may transmit the generated data flow to the gateway 203. For another example, if the generated data flow does not exist, the controller 202 may not transmit the data flow to the gateway 203.

In operation 750, the controller 202 may transmit the generated data flow to the node 201. For another example, if the generated data flow does not exist, the controller 202 may not transmit the data flow to the gateway 203.

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

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

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

Depending on the embodiment, operations 730 to 750 may not be performed when the access control application 211 determines that inspection of the application is not necessary.

Figure 8 shows an operation flowchart for network connection of a node according to various embodiments. Depending on the embodiment, the operations shown in FIG. 8 may be performed through the access control application 211 of the node 201 shown in FIG. 2.

When the node 201 needs to communicate with a destination network, the destination network may need to check whether network access is possible or authenticate network access from the controller 202 in order to communicate.

At operation 805, the connection control application 211 of node 201 may detect a network connection event. For example, the connection control application 211 may detect a network connection event for the destination network of the target application. According to the embodiment, the access control application 211 may detect a network connection event by detecting a data packet that the target application wants to transmit.

At operation 810, the connection control application 211 may inspect the data flow. For example, the access control application 211 can confirm the existence of a data flow authorized by the controller 202 and corresponding to the data packet that the target application wants to transmit. For another example, the access control application 211 may check whether a data flow corresponding to the identification information of the target application 211 and the identification information of the destination network exists. Depending on the embodiment, if a data flow exists but is not valid, the connection control application 211 may drop the data packet (operation 840). According to another embodiment, if a data flow exists and the data flow is authenticated, or if authentication is not required, the access control application 211 may transmit a data packet (act 815).

If a data flow does not exist or a data flow exists but authentication is required, in operation 820, the access control application 211 may check whether the data packet is a TCP SYN packet for TCP session creation. Depending on the embodiment, when the data packet is a TCP SYN packet, the connection control application 211 may perform a network connection check (operation 825) related to whether the TCP SYN packet can be transmitted. For another example, when the data packet is a TCP SYN packet, the connection control application 211 may allow transmission of the TCP SYN packet based on whether the TCP SYN packet can be transmitted. For another example, when the data packet is a TCP SYN packet, the connection control application 211 can check whether transmission of the TCP SYN packet is allowed based on whether the TCP SYN packet can be transmitted. Depending on the embodiment, the process of checking whether transmission of the TCP SYN packet is permitted may be performed through a network connection test. For example, a network connectivity check may be performed through the operations shown in FIG. 9A. If the data packet is not a TCP SYN packet, in operation 830, the access control application 211 may check whether the data packet is an authentication data packet. Depending on the embodiment, if the data packet is not an authentication data packet, the access control application 211 may drop the data packet (operation 840).

If the data packet is an authentication data packet, in operation 835, the access control application 211 may perform a network connection authentication check related to whether the authentication data packet can be transmitted. For example, a network connection authentication check may be performed through the operations shown in FIG. 9B.

When a target application attempts to connect to a TCP-based network, the node 201 may transmit a TCP SYN packet and perform a 3 Way Handshake procedure to create a TCP session. Node 201 may be in a state capable of transmitting actual data packets after a TCP session is created. Due to the nature of TCP communication, in order to authenticate data packets, the node 201 must have a TCP session created in advance, and the controller 202 must check whether network access is possible at the time of creating the TCP session, and after creating the TCP session, At the time of data packet authentication, the controller 202 may need to confirm whether network access is possible. In this case, when frequent communication is made to various destination networks, the network connection of the node 201 may have the disadvantage of requiring a lot of time to round trip and actually transmit the data packet. According to an embodiment disclosed in this document, the connection control application 211 of the node 201 basically allows the creation of a TCP session, but then checks whether network access is possible at the time of data packet authentication and actual data packet transmission. The process of receiving confirmation from the controller 202 can be reduced to once.

Referring to FIG. 9A, in operation 905, the access control application 211 may detect a network connection check event. For example, the access control application 211 may detect a network connection check event through operation 825 of FIG. 8.

In operation 910, the connection control application 211 may check whether the TCP SYN packet is inspected. For example, if the connection control application 211 does not need to check the TCP SYN packet, it can create a TCP session by sending the TCP SYN packet to the destination network. For another example, the connection control application 211 may previously allow TCP SYN data packets, i.e., if the data packet has not been authenticated, but a data flow exists that can transmit the TCP SYN data packet, the TCP SYN packet You can create a TCP session by sending it to the destination network. Depending on the embodiment, operation 915 may be performed when a TCP SYN packet needs to be checked or when there is no data flow capable of transmitting a TCP SYN data packet.

In operation 915, the access control application 211 may request a network connection to the controller 202. For example, the network connection request may include at least one of control flow identification information previously created with the controller 202, identification information of the target application, and identification information of the destination network.

In operation 920, the controller 202 may confirm an access policy matching the identified node 201, user, and source network information based on the control flow identification information. For example, the controller 202 determines whether the connection request identification information (e.g., identification information of the target application, identification information of the destination network) is included in the access policy and whether the destination network corresponding to the identification information is accessible. You can check it. Depending on the embodiment, when network access is not possible, the controller 202 may transmit a result of network access failure to the access control application 211 in operation 935.

If a connection is available, at operation 925 the controller 202 may process the data flow. For example, the controller 202 provides data flow information that can be accessed with identification information of the destination network based on a data flow table (e.g., data flow table 316 in FIG. 3) to allow the node 201 to access the network. You can check whether exists. Depending on the embodiment, if an accessible data flow exists in the data flow table, the controller 202 may transmit the data flow to the node 201 (operation 935).

If there is no valid data flow information in the data flow table, the controller 202 may create a data flow based on the source IP and destination network identification information so that the target application can connect to the destination network, and the generated Data flows may be transmitted to node 201 and gateway 203 (operations 930 and 935).

In operation 940, the access control application 211 may process a result of the response received from the controller 202. For example, when the connection control application 211 receives a result of network connection not being possible, it may drop a data packet. For another example, when a data flow is received, the connection control application 211 may transmit a data packet (TCP SYN packet) based on the received data flow. there is. Depending on the embodiment, the access control application 211 of the node 201 may update the data flow based on the received data flow.

According to an embodiment, the access control application 211 of the node 201 may further perform validation before performing operation 915. For example, the access control application 211 may perform a check on the integrity and stability of the target application (application forgery check, tampering check, code signing check, fingerprint check, etc.) according to the validation policy. Depending on the embodiment, if the validation is successful, the access control application 211 may perform operation 915. Depending on the embodiment, if the validation check fails, the access control application 211 may drop the data packet (TCP SYN packet).

When the node 201 needs to communicate with a destination network, it needs to check whether authentication has been completed in order to communicate with the destination network.

Referring to FIG. 9B, in operation 950, the access control application 211 may detect a network connection authentication check event. For example, the access control application 211 may detect a network connection authentication check event through operation 835 shown in FIG. 8.

In operation 955, the access control application 211 may request network access authentication from the controller 202. In this case, the access control application 211 may request network connection authentication including control flow identification information, target application identification information, identification information of the destination network to be connected, and authentication data packet information to the controller 202.

In operation 960, the controller 202 may confirm an access policy that matches the identified node 201, user, and source network information based on the control flow identification information. For example, the controller 202 determines whether the connection request identification information (e.g., identification information of the target application, identification information of the destination network) is included in the access policy and whether the destination network corresponding to the identification information is accessible. You can check it. Depending on the embodiment, when network access is not possible, the controller 202 may transmit a result of network access failure to the access control application 211 in operation 980.

If a connection is available, at operation 965, the controller 202 checks whether the authentication data packet transmitted by the node 201 is valid based on an authentication policy (e.g., the authentication policy database 312 of FIG. 3). You can. For example, in order to check the validity of an authentication data packet, the controller 202 checks whether the transmittable identification information included in the authentication policy is the same as the identification information transmitted by the node, and determines whether network access is possible with the identification information. For network access authentication, it is possible to determine whether the authentication information is valid through the authentication information generated through the authentication information generation algorithm and the authentication information inspection algorithm included in the authentication policy.

Depending on the embodiment, when the controller 202 may allow network access with the approval of a third party (e.g., the data owner 206 in FIG. 2) matched based on the identification information of the node 201, Authentication data packet validity can be checked through third-party authentication confirmation. Through the above confirmation, third parties can safely manage the data they own and check records of data use.

If verification of the connection and authentication policy is complete, at operation 970, the controller 202 configures a data flow table (e.g., data flow table 316 in FIG. 3) to allow node 201 to access the network. You can check whether accessible data flow information exists using the identification information of the destination network.

If there is no valid data flow information in the data flow table, the controller 202 generates data including the source IP, destination network identification information, and authentication information generated according to the authentication policy so that the target application can connect to the destination network. You can create flows.

Depending on the embodiment, the authentication information may be information including whether it is possible to always transmit data packets without additional authentication renewal and the time of authentication renewal. For example, authentication information may be used to determine whether to continue to allow network access after network access has been granted, or to determine whether to allow network access under certain conditions (e.g., TCP SYM Packet, TCP FIN Packet, the amount of data packets transmitted is the amount of data packets included in the data flow). may include whether to release the network connection and re-perform data packet authentication if a rule (such as including an update processing character of a data packet included in the data flow) is met. Additionally, the authentication information may include information that sets the authentication status of the data flow to an authentication required state when the data flow update conditions are satisfied.

At operation 975, the controller 202 may transmit the generated data flow to the gateway 203. For another example, if the generated data flow does not exist, the controller 202 may not transmit the data flow to the gateway 203.

At operation 980, the controller 202 may transmit a response to the network connection authentication request (operation 955) of the access control application 211. For example, if a generated data flow exists, the controller 202 may transmit the generated data flow to the access control application 211. For another example, if there is a data flow that can be accessed in the data flow table, the data flow can be transmitted to the node 201. For another example, if the network connection of the target application of the node 201 is not possible or authentication fails, the controller 202 may transmit a result of the inability to connect.

In operation 985, the access control application 211 may process the result of the response sent from the controller 202. For example, when the access control application 202 receives a data flow from the controller 202, it updates the data flow of the node 201 with the received data flow and drops or transmits an authentication data packet according to the authentication information. It can be handled. For another example, the access control application 211 may drop a data packet when receiving an authentication failure result or a connection inaccessibility result from the controller 202.

Depending on the embodiment, after performing operation 950, the access control application 211 may perform a validation check on the target application according to a validation policy. For example, the access control application 211 may further perform an integrity and stability check of the target application (application forgery check, tampering check, code signing check, fingerprint check, etc.). The access control application 211 may perform operation 955 if the validation result is successful.

The access control application 211 of the node 201 can check whether the data packet is authenticated and whether renewal is necessary before transmitting the data packet, and can control not to transmit the data packet if authentication is not performed or renewal is required. there is.

At operation 1005, the access control application 211 may detect a data packet transmission event. For example, the access control application 211 may detect an operation of another application included in the node 201 (eg, the target application 212 in FIG. 2) transmitting a data packet.

In operation 1010, the access control application 211 may perform a data packet authentication check. For example, the access control application 211 may check authentication information included in the data flow corresponding to the destination network identification information of the data packet requested to be transmitted. The access control application 211 can check whether or not each data packet contains an authentication data packet based on the authentication information, and can perform a data packet test when it is necessary to check whether or not the authentication data packet is included. In this case, the access control application 211 may drop the data packet if the authentication data packet included in the data packet does not exist or if the authentication information included in the data packet is different from the authentication information included in the data flow. For another example, if it is not necessary to check whether the authentication data packet is included, the access control application 211 may perform operation 1015.

In operation 1015, the access control application 211 may perform a data packet update check. For example, the access control application 211 may check whether data packet inspection for authentication renewal is necessary based on authentication information included in the data flow. For example, when inspection of a data packet for authentication renewal is required, the access control application 211 may inspect the data packet requested to be transmitted according to the authentication renewal method included in the authentication information. Depending on the embodiment, when the data packet requested to be transmitted is a TCP SYN Packet or a TCP FIN Packet, and the amount of transmitted data packets exceeds the amount of data packets included in the data flow, the connection control application 211 If the data flow update conditions are met according to a series of rules included in the authentication information, such as including the update processing character (Suffix) of the data packet included in the flow, the data flow update procedure can be performed. For example, the access control application 211 can change the update status of the data flow to update required, transmit information about the data flow to the controller 202, and request update of the data flow (operation 1020).

In operation 1025, the controller 202 may update the data flow based on information about the data flow received from the access control application 211.

At operation 1030, the controller 202 may transmit the updated data flow to the gateway 203.

Depending on the embodiment, operations 1020 to 1030 may not be performed if update of the data flow is not necessary.

If data packet inspection for authentication renewal is not necessary, in operation 1035, the access control application 211 may transmit and process the data packet. Additionally, when authentication renewal is completed, the access control application 211 can transmit and process data packets. Additionally, the access control application 211 may transmit the data packet when the inspection of the data packet is completed through operation 1010 or operation 1015. Depending on the embodiment, the access control application 211 may drop the data packet if the inspection of the data packet fails in operation 1010 or operation 1015.

When receiving a data packet, the gateway 203 can check whether the data packet is authenticated and whether renewal is necessary before forwarding the data packet, and can control not to forward the data packet if it is not authenticated or requires renewal. there is.

At operation 1105, gateway 203 may detect a data packet reception event. For example, the gateway 203 may detect data packets transmitted from the access control application 211 of the node 201.

In operation 1110, the gateway 203 can check the source IP and identification information of the destination network of the received data packet, and check whether a data flow corresponding to the source IP and the identification information of the destination network exists. Depending on the embodiment, if there is no data flow corresponding to the identification information of the source IP and destination network, the gateway 203 may drop the data packet.

If a data flow exists, in operation 1115, the gateway 203 may perform a data packet authentication check. For example, the gateway 203 may check authentication information included in the data flow corresponding to the destination network identification information of the received data packet. The gateway 203 can check whether each data packet contains an authentication data packet based on the authentication information, and can perform a data packet test when it is necessary to check whether the authentication data packet is included. In this case, the gateway 203 may drop the data packet if the authentication data packet included in the data packet does not exist or if the authentication information included in the data packet is different from the authentication information included in the data flow. For another example, if it is not necessary to check whether the authentication data packet is included, the gateway 203 may perform operation 1120.

At operation 1120, the gateway 203 may perform a data packet update check. For example, the gateway 203 may determine whether data packet inspection for authentication renewal is necessary based on authentication information included in the data flow. For example, when inspection of a data packet for authentication renewal is necessary, the gateway 203 may inspect the received data packet according to the authentication renewal method included in the authentication information. Depending on the embodiment, the gateway 203 includes the received data packet in the data flow if the received data packet is a TCP SYN Packet or a TCP FIN Packet and the amount of the received data packet exceeds the amount of data packets included in the data flow. If the data flow update conditions are satisfied according to a series of rules included in the authentication information, such as including the update processing character (Suffix) of the updated data packet, the data flow update procedure can be performed. For example, the gateway 230 may change the update status of the data flow to need to be updated, transmit information about the data flow to the controller 202, and request an update of the data flow (operation 1125).

In operation 1130, the controller 202 may update the data flow based on information about the data flow received from the gateway 203.

Depending on the embodiment, operations 1125 and 1130 may not be performed if update of the data flow is not necessary.

If inspection of the data packet for authentication renewal is not necessary, in operation 1135, the gateway 203 may forward the data packet. Additionally, when authentication renewal is completed, the gateway 203 may forward the data packet. Additionally, the gateway 203 may forward the data packet when the inspection of the data packet is completed through operation 1115 or operation 1120. Depending on the embodiment, the gateway 203 may drop the data packet if the inspection of the data packet fails in operation 1115 or operation 1120.

The access control application 211 maintains information about the control flow and data flow of the node 201, and periodically checks the control flow to receive an updated data flow from the controller 202 or check whether the control flow is valid. You can request renewal.

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

In operation 1210, the access control application 211 may request a control flow update from the controller 202 based on control flow identification information.

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

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

In one embodiment, if re-authentication is required among data flows dependent on the identified control flow, or if there is a data flow that is no longer accessible, the controller 202 sends information about the data flow to the access control application ( 211) (operation 1220).

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

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

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

In operation 1320, the controller 202 may remove all data flows dependent on the removed control flow. Accordingly, node 201 can no longer connect to the destination network based on the removed data flow.

In operation 1325, the controller 202 may request the gateway 203 to remove all data flows dependent on the removed control flow.

Referring to FIG. 14, in operation 1405, the access control application 211 of the node 201 can check in real time whether the running application is terminated and detect an application execution termination event.

In operation 1410, the access control application 211 may check whether a data flow corresponding to the terminated application identification information and PID (Process ID and Child Process ID Tree) information exists. If a data flow exists, the access control application can delete the data flow. Depending on the embodiment, the access control application 211 may check whether the terminated application exists in the running process list in order to track termination of multiple executable applications, and if not, identify the terminated application. All data flows corresponding to can be deleted.

In operation 1415, the access control application 211 may request deletion of the deleted data flow from the controller 202.

In operation 1420, the controller 202 may delete the data flow for which deletion has been requested. Additionally, the controller 202 may request the gateway 203 to remove a deleted data flow. Accordingly, data packets corresponding to the source network, destination network, and port information included in the deleted data flow can no longer be transmitted.

Figure 15 shows an operation flowchart of a method of operating an access control application installed in a node according to various embodiments. In one embodiment, the operation shown in FIG. 15 may be performed through the access control application 211 installed on the node 201 of FIG. 2.

Referring to FIG. 15, in operation 1505, the access control application 211 may detect a network connection event. For example, the connection control application 211 may detect a network connection event by detecting a data packet that the target application wants to transmit to the destination network.

In operation 1510, the access control application 211 may confirm the existence of a data flow authorized from an external server and corresponding to the data packet that the target application wants to transmit.

In operation 1515, the access control application 211 may check the type of data packet. For example, the connection control application 211 can determine whether a data packet is a TCP SYN packet, an authentication data packet, or neither a TCP SYN packet nor an authentication data packet.

In the case of a TCP SYN packet, in operation 1520, the connection control application 211 may allow transmission of the TCP SYN packet based on whether the TCP SYN packet can be transmitted.

In the case of an authentication data packet, in operation 1525, the access control application 211 may perform a network connection authentication check related to whether the authentication data packet can be transmitted.

If it is not a TCP SYN packet or an authentication data packet, in operation 1530, the connection control application 211 may drop the data packet.

The above description is merely an illustrative explanation of the technical idea disclosed in this document, and those skilled in the art in the technical field to which the embodiments disclosed in this document belong will understand without departing from the essential characteristics of the embodiments disclosed in this document. Various modifications and variations will be possible.

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

Claims

In the node,

communication circuit;

a processor operatively connected to the communication circuit; and

a memory operatively coupled to the processor and storing a connection control application and a target application, wherein the memory, when executed by the processor, causes the node to:

Detect network access events through the access control application,

Confirm the existence of a data flow authorized by an external server corresponding to the data packet that the target application wants to transmit, and confirm the type of the data packet,

Allow transmission of a TCP SYN packet based on whether the TCP SYN packet can be transmitted based on the type of the data packet,

After creating a TCP session or when inspection of TCP SYN packets is not necessary, perform a network connection authentication check,

storing commands to process subsequently transmitted data packets based on the authentication check results;

The data flow includes information on whether to basically allow transmission of the TCP SYN packet.
The method of claim 1, wherein the commands cause the node to:

When checking whether the TCP SYN packet can be transmitted, check whether the TCP SYN packet is inspected based on the data flow through the connection control application,

If inspection of the TCP SYN packet is not necessary or if the TCP SYN packet was previously allowed, transmit the TCP SYN packet to the destination network,

If inspection of the TCP SYN packet is necessary, perform a network connection request to the external server through the connection control application,

Receive a data flow from the external server and transmit the TCP SYN packet based on the received data flow,

The network connection request includes identification information of the destination network and identification information of the target application, a node,
The method of claim 1, wherein the commands cause the node to:

When performing the network connection authentication check, a network connection authentication request is made to the external server based on information about the authentication data packet through the access control application,

Receiving data flow or network connection inaccessibility information including authentication information from the external server,

transmit the authentication data packet based on a data flow including the authentication information,

The authentication information is generated based on the authentication policy included in the external server,

The authentication information includes information on whether it is possible to transmit a data packet without additional authentication and information for changing the authentication status of the data flow when the update conditions of the data flow are satisfied based on the authentication policy. .
The method of claim 1, wherein the commands cause the node to:

Determining whether to transmit the data packet of the target application without authentication based on information on whether unauthenticated network access is possible received from the external server through the access control application,

If the data packet is transmitted without authentication, a network connection request is made to the external server,

Receiving a data flow including the authentication information from the external server,

A node configured to transmit the data packet based on the received data flow.
The method of claim 1, wherein the commands cause the node to:

Verify authentication information included in the data flow corresponding to the information included in the data packet requested to be transmitted from the target application through the access control application,

Determine whether to inspect the data packet based on whether authentication is required included in the authentication information,

Determine whether to inspect the data packet based on whether authentication renewal needed included in the authentication information is required,

A node that transmits the data packet when the data packet inspection is completed.
The method of claim 5, wherein the commands cause the node to:

Through the access control application, check whether each data packet transmitted based on the authentication information includes an authentication data packet,

If it is necessary to check whether each transmitted data packet contains an authentication data packet, check the data packet,

A node that drops the data packet when there is no authentication data packet in the data packet or when authentication information included in the data packet is different from authentication information included in the data flow.
The method of claim 5, wherein the commands cause the node to:

Through the access control application, determine whether data packet inspection for authentication renewal is necessary based on the authentication information,

If data packet inspection for authentication renewal is necessary, inspect the data packet based on the authentication renewal method included in the authentication information,

A node that sets the update status of the data flow to need to be updated when the data flow update condition included in the authentication information is satisfied.
In the method of operating the access control application installed on the node,

detecting a network connection event;

Confirming the existence of a data flow authorized from an external server and corresponding to a data packet to be transmitted by the target application;

Confirming the type of the data packet;

If the data packet is a TCP SYN packet, transmission of the TCP SYN packet is allowed based on whether the TCP SYN packet can be transmitted; if the data packet is an authentication data packet, a network connection authentication check is performed, and the data packet is dropping the data packet if it is not the TCP SYN packet and the authentication data packet; Including,

The data flow includes information on whether to basically allow transmission of the TCP SYN packet.