Container platform admission control method and device based on detailed role of accessor, and computer-readable recording medium

Abstract

The present invention comprises: a user authentication step for determining whether a user is an authorized user for a server system by using user information pre-registered in a trust determination machine; a trust level verification step for, if the user is an authorized user, having the trust determination machine evaluate a trust level according to the security state of a user terminal, and determining whether the trust level evaluation result for the user terminal satisfies preset access permission criteria of the server system; a resource access control step for, when information related to a target resource to be accessed is collected from the user terminal, having a trust fulfillment machine, which is synchronized with access policies of respective resources, carry out access control for the target resource on the basis of a role given to the user and the trust level evaluated for the user terminal; and an admission control step for, when a distribution request for the target resource is made by the user and the user terminal accessing the target resource, controlling whether to approve the distribution of the containerized target resource by using an admission control machine based on a secure kernel.

Description

Method, device and computer-readable recording medium for container platform authorization control based on detailed role of accessor

[0001] The present invention relates to a container platform authorization control method based on the detailed role of an accessor, and more particularly, to a technology that allows only guaranteed images to be distributed in a container platform even if a user and a user terminal accessing a server system are determined to be trusted accessors by a trust decision machine and a trust enforcement machine, and allows the accessor's trust level to be continuously checked by an authorization control machine while the deployment life cycle of a containerized resource is in progress to determine whether or not to finally distribute the resource.

[0002] In addition, this application has been filed as a result of a project having the following information: Project Identification Number: 1711193290, Subproject Number: 2020-0-00952-004, Ministry of Science and ICT, Project Management (Specialized) Agency Name: Information and Communications Technology Planning and Evaluation Institute, Research Project Name: ICT Infrastructure-Service Protection Reinforcement, Research Project Name: Development of Edge Security Technology to Ensure 5G+ Service Stability, Contribution Rate: 1 / 1, Project Performing Agency Name: Electronics and Telecommunications Research Institute, Research Period: 2020.04.01.~2023.12.31.

[0003]

[0004] Cyber ​​attacks are being carried out in an organized and intelligent manner, and in particular, the rapid increase in APT (Advanced Persistent Threat) attacks, in which hacking organizations carry out stealthy, continuous, and intelligent attacks against specific attack targets for economic purposes, is becoming a major social problem.

[0005] These APT attacks are attacks in which hackers or hacking organizations infiltrate the target organization with malware to illegally steal important information from the organization, and then continuously update the code to infect the hosts of those with access to important information with malware, thereby leaking important information, causing significant damage to the organization.

[0006] Meanwhile, as a related public technology, a system and method for detecting kernel backdoors through Windows network monitoring, Korean Patent No. 10-0635130, discloses a technology for detecting kernel backdoors by comparing and analyzing information of network packets passing through the TDI (Transport Driver Interface) layer and the NDIS (Network Driver Interface Specification) layer among Windows network components, thereby distinguishing between network packets generated from normal network behavior and network packets generated from malicious network behavior such as kernel backdoors.

[0007] However, the above-mentioned prior art is limited to preventing intrusion through kernel backdoors, and has the limitation of lacking a technology to prevent leakage or hacking of internal resources through terminals connected to server systems or internal networks.

[0008] Accordingly, the present invention aims to provide an improved security solution by using a trust decision machine that verifies the identity of a user and a user terminal accessing a server system and determines a trust level, a trust enforcement machine that monitors whether the user and the user terminal fulfill the promised trust level until accessing a target resource, and an authorization control machine that verifies the trust level of the user and the user terminal even while the deployment life cycle is in progress when a deployment request for a containerized target resource is made and determines whether to perform the final deployment.

[0009] In order to achieve the above-described object, a container platform authorization control method based on the detailed role of an accessor is implemented by a computing device including one or more processors and one or more memories storing commands executable by the processors according to an embodiment of the present invention, the method comprising: a user authentication step of verifying the identity of a user accessing a server system using user information pre-registered in a trust decision machine to determine whether the user is an authorized user of the server system; a trust level verification step of causing the trust decision machine to evaluate a trust level according to a security status of the user terminal when the user is authenticated as an authorized user, and determining whether the trust level evaluation result of the user terminal satisfies a preset access permission criterion of the server system; a resource access control step of performing access control on the target resource based on a role granted to the user and the trust level evaluated for the user terminal by a trust enforcement machine with which access policies for each resource are synchronized when information on a target resource to be accessed is collected from the user terminal after the trust level verification for the user terminal is completed; And, when there is a request for distribution of the target resource from a user or user terminal that has accessed the target resource, an authorization control step for controlling whether to approve distribution of the containerized target resource using an authorization control machine based on a security kernel is included.

[0010] At this time, the authorization control machine of the above-described authorization control step determines whether to approve deployment for the containerized target resource based on the security policy set in the security kernel, but preferably checks whether an explicit denial policy related to the containerized target resource exists in the security policy database, and if an explicit denial policy exists, denies deployment for the containerized target resource.

[0011] Additionally, it is desirable that the security policy database described above manage basic security policies for resources managed in the server system and custom security policies according to the roles of authorized users.

[0012] In addition, it is preferable that the above-described authorization control machine use a hook command to stop the deployment of the containerized target resource when a change is detected in at least one of the user's role and the trust level of the user terminal during the deployment life cycle of the containerized target resource.

[0013] In addition, it is desirable that multiple resources managed in the above-described server system can be grouped into multiple groups based on criteria including at least one of a role and an asset importance, and that independent access policies can be set for the required user role and the trust level of the user terminal for each resource and each resource group.

[0014] In addition, it is preferable that the trust enforcement machine of the above-described resource access control step receives access policies for each resource and each resource group updated from the resource access policy management system at preset intervals, and performs synchronization for the updated resource access policies.

[0015] In addition, it is preferable that the above-described trust level verification step performs trust level verification based on an electronic signature by providing the evaluation result to the user terminal after evaluating the trust level according to the security status of the user terminal, requesting the user's electronic signature for the evaluation result, receiving a signature response based on a private key, and checking whether the received signature response matches the user's public key among the user information already registered in the trust decision machine.

[0016] Meanwhile, according to an embodiment of the present invention, a container platform authorization control device based on the detailed role of an accessor, which is implemented as a computing device including one or more processors and one or more memories for storing commands executable by the processors, comprises: a user authentication unit that verifies the identity of a user accessing a server system using user information pre-registered in a trust decision machine to determine whether the user is an authorized user of the server system; a trust level verification unit that, when the user is authenticated as an authorized user, causes the trust decision machine to evaluate a trust level according to the security status of the user terminal and determines whether the trust level evaluation result of the user terminal satisfies a preset access permission criterion of the server system; a resource access control unit that, after the trust level verification for the user terminal is completed, when information on a target resource to be accessed is collected from the user terminal, a trust enforcement machine with synchronized access policies for each resource performs access control for the target resource based on a role granted to the user and the trust level evaluated for the user terminal; And, when there is a request for distribution of the target resource from a user or user terminal that has accessed the target resource, an authorization control unit that controls whether to approve distribution of the containerized target resource using an authorization control machine based on a security kernel is included.

[0017] On the other hand, in a computer-readable recording medium, the computer-readable recording medium stores instructions that cause a computing device to perform the following steps, wherein the steps are: a user authentication step of verifying the identity of a user accessing a server system using user information previously registered in a trust decision machine to determine whether the user is an authorized user of the server system; a trust level verification step of causing the trust decision machine to evaluate a trust level according to a security status of the user terminal when the user is authenticated as an authorized user and to determine whether the trust level evaluation result of the user terminal satisfies a preset access permission criterion of the server system; a resource access control step of performing access control on the target resource based on a role granted to the user and the trust level evaluated for the user terminal by a trust enforcement machine with which access policies for each resource are synchronized when information on a target resource to be accessed is collected from the user terminal after the trust level verification for the user terminal is completed; And, when there is a request for distribution of the target resource from a user or user terminal that has accessed the target resource, an authorization control step for controlling whether to approve distribution of the containerized target resource using an authorization control machine based on a security kernel is included.

[0018] According to one embodiment of the present invention, even if a user and a user terminal accessing a server system are determined to be a trusted accessor by a trust decision machine and a trust enforcement machine, only guaranteed images can be distributed on a container platform, and even while the deployment life cycle of a containerized resource is in progress, the trust level of the accessor is continuously checked by an authorization control machine to determine whether or not to finally distribute the resource, thereby providing an improved security solution.

[0019] In addition, according to one embodiment of the present invention, after the trust level evaluation of the security status of the user terminal is completed, the trust decision machine provides the evaluation result to the user terminal to provide specificity for the trust level, and by requesting the user's electronic signature for the evaluation result, a non-repudiation effect for the trust level can be provided.

[0020] In addition, according to one embodiment of the present invention, when abnormal user and user terminal behavior is detected during the process of distributing containerized resources, a hook command is used to return the target resource to the server system before the target resource is distributed to the user terminal, and the user's request for target resource distribution is rejected, thereby preventing the target resource from being executed on a user or user terminal that has lost reliability, thereby providing an effect of more strictly protecting internal resources.

[0021] FIG. 1 is a flowchart of a container platform authorization control method based on detailed roles of accessors according to one embodiment of the present invention.

[0022] Figure 2 is an example of user verification performed according to one embodiment of the present invention.

[0023] FIG. 3 is an example of a scenario prepared to evaluate the level of trust in the security status of a user terminal according to one embodiment of the present invention.

[0024] FIG. 4 is a schematic workflow of an authorization control machine based on a security kernel according to an embodiment of the present invention.

[0025] FIG. 5 is an example of a deployment life cycle of a containerized target resource according to one embodiment of the present invention.

[0026] FIG. 6 is a configuration diagram of a container platform authorization control device based on the detailed role of an accessor according to one embodiment of the present invention.

[0027] Figure 7 is an example of the internal configuration of a computing device according to one embodiment of the present invention.

[0028] Hereinafter, various embodiments and / or aspects are now disclosed with reference to the drawings. In the following description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of one or more aspects. However, it will be apparent to one skilled in the art that such aspects may be practiced without these specific details. The following description and the attached drawings detail specific exemplary aspects of one or more aspects. However, these aspects are exemplary, and it is to be understood that any of the various methods within the principles of the various aspects may be utilized, and the description is intended to encompass all such aspects and their equivalents.

[0029] The terms “embodiment,” “example,” “aspect,” “example,” and the like as used herein may not be construed to imply that any aspect or design described is better or advantageous over other aspects or designs.

[0030] Additionally, it should be understood that the terms “comprises” and / or “comprising” imply the presence of the features and / or components, but do not preclude the presence or addition of one or more other features, components and / or groups thereof.

[0031] Additionally, terms including ordinal numbers, such as first, second, etc., may be used to describe various components, but the components are not limited by the terms. The terms are used solely to distinguish one component from another. For example, without departing from the scope of the present invention, the first component may be referred to as the second component, and similarly, the second component may also be referred to as the first component. The term and / or includes a combination of a plurality of related described items or any of a plurality of related described items.

[0032] Additionally, in the embodiments of the present invention, unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by those of ordinary skill in the art to which the present invention pertains. Terms defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and shall not be interpreted in an idealized or overly formal sense unless explicitly defined in the embodiments of the present invention.

[0033] The present invention relates to a container platform authorization control method based on the detailed role of an accessor, and specifically, to provide a more improved security solution by using a trust decision machine (30) that verifies the identity of a user and a user terminal (20) accessing a server system and determines a trust level, a trust enforcement machine (40) that monitors whether the user and the user terminal (20) fulfill a promised trust level until accessing a target resource, and an authorization control machine (50) that verifies the trust level of the user and the user terminal (20) even while the deployment life cycle is in progress when a deployment request for a containerized target resource is made and determines whether to perform a final deployment.

[0034] Hereinafter, a detailed description of the present invention for achieving the above objectives will be described with reference to the attached drawings, and multiple drawings may be referenced simultaneously to describe one or more technical features or components constituting the invention.

[0035] First, referring to FIG. 1, FIG. 1 illustrates a flowchart of a container platform authorization control method based on detailed roles of an accessor according to one embodiment of the present invention.

[0036] As illustrated in FIG. 1, in the present invention, a user authentication step (S10) is performed to determine whether a user is an authorized user of the server system by verifying the identity of a user accessing the server system using user information previously registered in the trust decision machine (30).

[0037] At this time, as described above, various user information may be registered in the trust decision machine (30) to verify the user's identity.

[0038] As an example, the trust decision machine (30) may be registered with a public key of an electronic signature issued only to users whose identities have been authenticated by an identity certification authority. Furthermore, as another example, the trust decision machine (30) may be registered with one or more of the following user information: the user's name, affiliation, employee number, ID, and password, as well as frequently used IP address information, public certificate information, card information, and a unique identification number of a terminal possessed by the user.

[0039] Accordingly, in step S10, a process is performed to check whether the information collected from the user and user terminal (20) accessing the server system matches the previously registered user information, thereby checking whether the user and user terminal (20) requesting access to the server system are authorized access.

[0040] As a more specific example, referring to FIG. 2 at the same time, at 100 of FIG. 2, an example is shown in which a trust decision machine (30) requests input of an ID and password granted to an authorized user, and the user submits the ID and password as an authentication response corresponding to the request, and the trust decision machine (30) determines whether the ID and password match the user information already registered, and at 110 of FIG. 2, an example is shown in which a trust decision machine (30) requests face ID information of an authorized user, and the user submits face ID as an authentication response corresponding to the request, and the trust decision machine (30) determines whether the ID and password match the user information already registered.

[0041] Also, at 120 of FIG. 2, an example is shown in which a trust decision machine (30) requests an electronic signature (more specifically, a private key of an electronic signature) from a user and has the user submit a signature response based on the private key, thereby determining whether the user is trustworthy by checking whether the public key and private key registered in the trust decision machine (30) match each other.

[0042] That is, through an identity verification process such as the above-described embodiment, the present invention can determine whether a user attempting access is a trustworthy user. In addition, preferably, in performing step S10 of FIG. 1, the present invention may determine whether a user is a trustworthy user by using any one of the user information registered in the trust decision machine (30). However, preferably, user authentication based on an electronic signature, which is issued only to users whose identity has been verified through an external identity verification agency, may be performed mandatory, and then user authentication other than an electronic signature may be additionally performed to enable more thorough identity verification. However, the present invention is not limited thereto.

[0043] Meanwhile, when the user accessing the server system is authenticated as an authorized user through the execution of the aforementioned step S10, the present invention performs a trust level verification step (S20) in which the trust decision machine (30) evaluates the trust level according to the security status of the user terminal (20), and determines whether the trust level evaluation result of the user terminal (20) satisfies the access permission criteria set in advance by the server system.

[0044] Specifically, in step S20, in order to evaluate the trust level according to the security status of the user terminal (20), registry information within the user terminal (20) is collected from a security agent pre-installed in the user terminal (20). Thereafter, the trust decision machine (30) determines the trust level of the user terminal (20) by calculating a risk score based on a scenario assuming an attack situation by an attacker.

[0045] At this time, the scenario used by the trust decision machine (30) may be composed of multiple scenarios as illustrated in 200 of FIG. 3, and the trust decision machine (30) calculates a risk score for each scenario for the security status of the user terminal (20) from the registry information collected by the security agent to determine the trust level.

[0046] As a first embodiment, the above-described scenario may include a first scenario (Access vector) that calculates a risk score according to the access location of the user terminal (20). At this time, the first scenario determines whether the network connected to the user terminal (20) is a local network (internal network), an adjacent network (Telnet, FTP restricted network, etc.), or an external network, and then, if the network connected to the user terminal (20) is a local network, the lowest risk score among the assigned risk scores is assigned, and if the network connected to the user terminal (20) is an external network, the highest risk score among the assigned risk scores is assigned. As a more specific example, the risk score distribution of the first scenario may have a distribution of 5 to 15 points, and if the user terminal (20) is connected to a local network, the risk score is assigned 5 points, if it is connected to an adjacent network, the risk score is assigned 10 points, and if it is connected to an external network, the risk score is assigned 15 points, and thus, the network that is farther away from the host is assigned the highest risk score among the assigned points.

[0047] As a second embodiment, the above-described scenario may include a second scenario (Authentication) that calculates a risk score according to the number of authentication requests required for the user terminal (20). In this case, the second scenario assigns a risk score according to whether additional authentication is required even after an attacker accessing the internal network through the user terminal (20). For example, if the user terminal (20) is required to authenticate twice or more, the lowest risk score among the assigned risk scores is assigned, and if the user terminal (20) is required to authenticate less than once (i.e., no separate authentication is required), the highest risk score among the assigned risk scores is assigned. As a more specific example, the risk score distribution of the second scenario can have a distribution of 5 to 15 points, and a risk score of 5 points is assigned when authentication is required more than twice for the user terminal (20), a risk score of 10 points is assigned when authentication is required once, and a risk score of 15 points is assigned when authentication is required less than once, so that a higher risk score is assigned as the number of authentications is small or non-existent.

[0048] As a third embodiment, the above-described scenario may include a third scenario (Access complexity) that calculates a risk score according to the difficulty of the access condition set for a specific resource that the user terminal (20) aims to access. In this case, the third scenario assigns the lowest risk score when the difficulty (attack complexity) of the access condition set for the specific resource is high, and assigns the highest risk score when the access condition is not set for the specific resource and the difficulty of the access condition is low. Meanwhile, the difficulty of the access condition is a measure of how complex the access condition must be resolved by an attacker in order to attack a specific resource. In one embodiment, when the difficulty of the access condition is high, it can be understood that the access condition is set such that it can be resolved by a professional hacker, and when the difficulty of the access condition is low, it can be understood that the access condition is set such that anyone can access it or can access it using an automated tool. As a more specific example, the risk score distribution of the third scenario can have a distribution of 5 to 15 points, and when the access difficulty is high, the lowest risk score among the distributed risk scores is 5 points, when the access difficulty is normal, the highest risk score among the distributed risk scores is 10 points, and when the access difficulty is low, the highest risk score among the distributed risk scores is 15 points, so that the environment in which it is easy for an attacker to carry out an attack has the characteristic of assigning a higher risk score.

[0049] As a fourth embodiment, the above-described scenario may include a fourth scenario (Privileged level) that calculates a risk score according to the level of access authority granted to the user terminal (20). In this case, in the fourth scenario, if the user terminal (20) is not granted access authority to resources managed in the intranet, the damage from an attack is extremely small, so the lowest risk score among the assigned risk scores is assigned. In addition, if the access authority granted to the user terminal (20) is root authority, access to all resources managed in the intranet is possible, so the highest risk score among the assigned risk scores is assigned. As a more specific example, the risk score distribution of the fourth scenario may have a distribution of points from 5 to 20, and the lowest risk score of 5 points may be assigned to a state where no separate access authority is set (Not defined), a risk score of 10 points may be assigned to application authority, a risk score of 15 points may be assigned to user authority, and the highest risk score of 20 points may be assigned to root authority, such as actual administrator authority, and has the characteristic of assigning a higher risk score as the authority becomes higher.

[0050] As a fifth embodiment, the above-described scenario may include a fifth scenario (Impact) that calculates a risk score according to the potential impact level due to the user terminal (20) being attacked by the attacker. At this time, the fifth scenario may calculate a risk score for the potential impact level for one or more elements of confidentiality, integrity, and availability. Specifically, confidentiality calculates a risk score for the degree of information leaked by the attack, integrity calculates a risk score for the degree of information manipulated by the attack, and availability calculates a risk score for the degree of service damage by the attack. As a more specific example, in the fifth scenario, the risk score distribution may have a score of 0 to 20 points for each element, and if the user terminal (20) is attacked, 0 points are assigned, 10 points are assigned, and 20 points are assigned for complete impact, and thus, a higher risk score is assigned as the impact level increases.

[0051] That is, in step S20 of the present invention, the security status of the user terminal (20) can be determined by calculating a risk score for each scenario based on the first to fifth scenarios described above.

[0052] At this time, the present invention can also define a confidence level according to the calculated risk score. Conceptually, the higher the risk score, the lower the confidence level is determined, and the lower the risk score, the higher the confidence level is determined.

[0053] Meanwhile, the risk score calculated for each scenario in this way may be used to verify the confidence level as a score itself, but in another embodiment, the risk score may be graded into a confidence level so that the graded confidence level can be used when verifying the confidence level.

[0054] Specifically, the confidence level rating according to the risk score can be, for example, if the risk score has a range of 0 to 100, if the calculated risk score is 0, the possibility of threatening the security of the server system is extremely low, so the highest confidence level rating of 0 can be assigned, and a mechanism such as defining 1 to 20 points as grade 1, 21 to 40 points as grade 2, 41 to 60 points as grade 3, 61 to 80 points as grade 4, and 81 to 100 points as grade 5 can be used.

[0055] In addition, the trust level of the user terminal (20) evaluated in this way may be defined by the trust decision machine (30) using all trust level evaluation values ​​for the entire scenario, selectively using trust level evaluation values ​​for some scenarios, or applying weights to some scenarios according to the access requirements set for the resource, depending on the access requirements set for the user and the target resource to which the user terminal (20) wishes to access, and the present invention is not limited thereto.

[0056] Meanwhile, as a preferred embodiment of the S20 step described above, in the present invention, after the trust level evaluation of the security status of the user terminal (20) is completed in the S20 step, the trust decision machine (30) provides the evaluation result to the user terminal (20), thereby providing specificity for the trust level, and by requesting the user's electronic signature for the evaluation result, a non-repudiation effect for the trust level can be provided.

[0057] Specifically, the trust decision machine (30) requests an electronic signature from the user terminal (20), and then receives a signature response based on a private key from the user. The received signature response based on the private key is then checked to see if it matches the user's public key among the user information stored in the trust decision machine (30), thereby verifying whether the user and user terminal (20) are trustworthy.

[0058] That is, in the present invention, if a signature response based on a user's private key is decrypted with a public key previously registered as user information, it is determined that the user and user terminal (20) are trustworthy, and if a signature response based on a user's private key is not decrypted with a public key previously registered as user information, it is determined that the user and user terminal (20) are untrustworthy, and there is an effect that more thorough identity verification can be performed by using an electronic signature.

[0059] Meanwhile, after the trust level verification for the user terminal (20) is completed in step S20, when information on the target resource to be accessed from the user terminal (20) is collected, in the present invention, an access control step (S30) can be performed in which a trust enforcement machine (40) with synchronized access policies for each resource performs access control for the target resource based on the role granted to the user and the trust level evaluated for the user terminal (20).

[0060] At this time, multiple resources managed in the server system may be grouped into multiple groups based on criteria including at least one of role and asset importance, and independent access policies may be set for the required user role and trust level of the user terminal (20) for each resource and each resource group.

[0061] In one embodiment, when resources are grouped into multiple groups based on roles, the server system may group resources by role hierarchy. When such grouping criteria are applied, the present invention provides the advantage of providing convenience in controlling access to resources, such as exposing only the resource groups corresponding to the user's role when a user assigned a specific role accesses the server system, and hiding resource groups inaccessible to the user's role.

[0062] In another embodiment, if resources are grouped into multiple groups based on asset importance, the resources are grouped based on the magnitude of asset damage caused by an attack. The magnitude of asset damage can be defined as the economic loss incurred due to a resource attack. Resource groups with greater economic loss can require a relatively higher level of user trust.

[0063] For example, if there are resource groups A, B, and C, and the asset importance of resource group A is the highest and the asset importance of resource group B is the lowest, the trust enforcement machine (40) may require the highest trust level for resource group A, the lowest trust level for resource group B, and may require a relatively higher trust level for resource group C than for resource group B, but a relatively lower trust level than for resource group A.

[0064] In addition, preferably, the trust enforcement machine (40) of the S30 stage receives the access policy for each resource and each resource group updated from the resource access policy management system (41) at preset intervals, thereby performing synchronization for the updated resource access policy, thereby enabling the latest policy issues or policy change issues to be quickly reflected.

[0065] Meanwhile, when the process of steps S10 to S30 is passed, and the user and user terminal (20) access the target resource, and there is a request for distribution of the target resource from the user and user terminal (20), in the present invention, an authorization control step (S40) is performed to control whether to approve distribution of the containerized target resource using an authorization control machine (50) based on a security kernel.

[0066] At this time, in step S40, if it is determined that there is a request for distribution of the target resource from the user and user terminal (20), containerization of the target resource is performed using container technology.

[0067] As an example, the present invention may utilize Kubernetes to implement the above-described container technology, which may be understood as an open source container orchestration platform that automates a number of manual processes involved in deploying containerized resources.

[0068] Meanwhile, the containerized target resource acquired through Kubernetes is to provide a separate execution environment by isolating the process running on the operating system in order to allow the resource (application, etc.) to run on all infrastructure regardless of the environment. In simple terms, it can be understood as the concept of software that is bundled with all files and libraries required to run the application. The containerized target resource can be easily deployed in any environment, so it has excellent mobility, is executed in an isolated computing environment, so it has excellent agility, and is very lightweight in the size of microbytes because there is no guest OS, so it has the advantage of excellent scalability.

[0069] In addition, the approval control machine (50) of the S40 step described above in the present invention determines whether to approve distribution of a containerized target resource based on the security policy set in the security kernel.

[0070] Referring to Fig. 4, which illustrates a schematic workflow for performing the functions of the above-described approval control machine (50), the approval control machine (50) largely follows the workflow of authentication, authorization, and approval control.

[0071] At this point, authentication is the process of verifying the identity of a user accessing the server system. The process of steps S10 to S30 in Figure 1 can be understood as an example. Next, authorization is the process of verifying who has what authority and what actions they can perform. Authorization control applies detailed security policies to restrict or modify user actions.

[0072] Specifically, the detailed security policy used in the present invention applies an explicit deny policy, and for this purpose, it is checked in the security policy database whether an explicit deny policy related to the containerized target resource exists, and if an explicit deny policy exists, distribution for the containerized target resource is denied.

[0073] In one embodiment, a user and user terminal (20) are assigned roles that determine which tasks can be performed on which resources. If an explicit denial policy is applied to a specific resource, access to all tasks is explicitly denied if the conditions set for the resource are not met.

[0074] As a more specific example, assuming that an explicit deny policy exists for a user and a target resource that the user is attempting to access, and that the conditions of the explicit deny policy are specified as a specific IP range corresponding to an internal network and a specific user role corresponding to an administrator role, the explicit deny policy will explicitly deny access from all users and user terminals (20) accessing from an external network other than the internal network, or user accounts other than administrator roles, thereby functioning as a more stringent security solution.

[0075] Of course, the rejection conditions of the explicit rejection policy described above may be determined in the security administrator account, and it is preferable to view the above embodiment as one embodiment for understanding the present invention.

[0076] In addition, as another preferred embodiment of the present invention, the security policy database mentioned in the present invention manages a basic security policy for resources managed in a server system and a custom security policy according to the role of an authorized user, and the authorization control machine (50) can stop the deployment of the containerized target resource using a hook command when a change in an element including at least one of the role of the user and the trust level of the user terminal (20) is detected during the deployment life cycle of the containerized target resource.

[0077] For a more specific explanation, referring to FIG. 5, FIG. 5 illustrates an example of a deployment life cycle of a containerized target resource according to an embodiment of the present invention.

[0078] The deployment life cycle of a containerized target resource is roughly divided into a waiting state, which is when the container is not in a running or terminated state; a running state, which means the container is running without any issues; and a terminated state, which indicates when the container has either completed execution successfully or failed to execute for some reason.

[0079] At this time, the hook command is called in at least one of the processes of PostStart and Prestop in the example of the life cycle described above, and when there is a change issue such as a change in the user's role or a decrease in the trust level of the user terminal (20), the hook command is used to return the target resource to the server system before the target resource is distributed to the user terminal (20) and to reject the user's request for target resource distribution, thereby preventing the target resource from being executed on the user and user terminal (20) that have lost trust, thereby providing an effect of more strictly protecting internal resources.

[0080] Meanwhile, referring to FIG. 6, FIG. 6 illustrates a configuration diagram of a container platform authorization control device (10) based on the detailed role of an accessor according to one embodiment of the present invention.

[0081] As illustrated in FIG. 6, the device (10) of the present invention may preferably include a user authentication unit (11), a trust level verification unit (12), an access control unit (13), and an authorization control unit (14).

[0082] Specifically, the user authentication unit (11) described above performs a function of determining whether a user is an authorized user of the server system by verifying the identity of a user accessing the server system using user information previously registered in the trust decision machine (30).

[0083] That is, the user authentication unit (11) can be understood as being capable of performing all of the functions performed by step S10 of the aforementioned FIG. 1, and by performing the functions of the user authentication unit (11), the primary identity of the accessor accessing the server system is verified.

[0084] Next, the trust level verification unit (12) described above performs a function of causing the trust decision machine (30) to evaluate the trust level according to the security status of the user terminal (20) when the user accessing the server system is authenticated as an authorized user by the user authentication unit (11), and to determine whether the trust level evaluation result of the user terminal (20) satisfies the access permission criteria set by the server system.

[0085] That is, the above-described trust level verification unit (12) can be understood as being capable of performing all of the functions performed by the S20 step of the above-described FIG. 1, and in the present invention, by performing the function of the trust level verification unit (12), only trusted users and user terminals (20) can access the server system, thereby enhancing the protection effect on internal resources managed in the server system.

[0086] Next, when information on a target resource to be accessed from a user terminal (20) is collected after the trust level verification for the user terminal (20) is completed in the trust level verification unit (12), the resource access control unit (13) described above performs access control for the target resource based on the role granted to the user and the trust level evaluated for the user terminal (20) by the trust enforcement machine (40) with which the access policy for each resource is synchronized.

[0087] That is, the above-described resource access control unit (13) can be understood as being capable of performing all of the functions performed by step S30 of FIG. 1, and in the present invention, by performing the function of the resource access control unit (13), the work actions of the user and the user terminal (20) are controlled until the user and the user terminal (20) access the target resource after the user and the user terminal (20) access the server system, thereby preventing a situation that poses a threat to security from occurring or providing an effect of enabling a quick response when a situation that poses a threat to security occurs.

[0088] In addition, the authorization control unit (14) described below performs a function of controlling whether to approve distribution of a containerized target resource by using an authorization control machine (50) based on a security kernel when a distribution request for the target resource is made from a user or user terminal (20) who has accessed the target resource.

[0089] That is, it can be understood that the above-described approval control unit (14) can perform all the functions performed by step S40 of FIG. 1, and in the present invention, by performing the function of the approval control unit (14), the trust level of the accessor is continuously checked even when the distribution life cycle of the containerized resource is in progress, thereby determining whether or not to finally distribute the resource, thereby providing a security solution with maximized security.

[0090] Although the embodiments have been described with limited examples and drawings, those skilled in the art will appreciate that various modifications and variations can be made from the above description.

[0091] On the other hand, referring to FIG. 7, FIG. 7 illustrates an example of the internal configuration of a computing device according to an embodiment of the present invention, and in the following description, descriptions of unnecessary embodiments that overlap with the descriptions of FIGS. 1 to 6 described above will be omitted.

[0092] As illustrated in FIG. 7, the computing device (10000) may include at least one processor (11100), memory (11200), peripheral interface (11300), input / output subsystem (I / O subsystem) (11400), power circuit (11500), and communication circuit (11600). In this case, the computing device (10000) may correspond to a user terminal (A) connected to a tactile interface device or the computing device (B) described above.

[0093] The memory (11200) may include, for example, high-speed random access memory, a magnetic disk, SRAM, DRAM, ROM, flash memory, or non-volatile memory. The memory (11200) may include software modules, instruction sets, or other various data required for the operation of the computing device (10000).

[0094] At this time, access to the memory (11200) from other components such as the processor (11100) or peripheral interface (11300) may be controlled by the processor (11100).

[0095] The peripheral interface (11300) may couple input and / or output peripherals of the computing device (10000) to the processor (11100) and memory (11200). The processor (11100) may execute software modules or instruction sets stored in the memory (11200) to perform various functions for the computing device (10000) and process data.

[0096] The input / output subsystem (11400) can couple various input / output peripheral devices to the peripheral interface (11300). For example, the input / output subsystem (11400) can include a controller for coupling peripheral devices such as a monitor, a keyboard, a mouse, a printer, or, as needed, a touchscreen or sensor to the peripheral interface (11300). In another aspect, the input / output peripheral devices can be coupled to the peripheral interface (11300) without going through the input / output subsystem (11400).

[0097] The power circuit (11500) may supply power to all or part of the components of the terminal. For example, the power circuit (11500) may include a power management system, one or more power sources such as a battery or alternating current (AC), a charging system, a power failure detection circuit, a power converter or inverter, a power status indicator, or any other components for power generation, management, and distribution.

[0098] The communication circuit (11600) may enable communication with another computing device using at least one external port.

[0099] Alternatively, as described above, the communication circuit (11600) may enable communication with other computing devices by transmitting and receiving RF signals, also known as electromagnetic signals, including RF circuits, as needed.

[0100] The embodiment of FIG. 7 is only an example of a computing device (10000), and the computing device (11000) may have some of the components illustrated in FIG. 7 omitted, may further include additional components not illustrated in FIG. 7, or may have a configuration or arrangement that combines two or more components. For example, a computing device for a communication terminal in a mobile environment may further include a touchscreen or a sensor, in addition to the components illustrated in FIG. 7, and may include a circuit for RF communication of various communication methods (WiFi, 3G, LTE, Bluetooth, NFC, Zigbee, etc.) in the communication circuit (1160). Components that can be included in the computing device (10000) may be implemented as hardware including one or more signal processing or application-specific integrated circuits, software, or a combination of both hardware and software.

[0101] Methods according to embodiments of the present invention may be implemented in the form of program instructions that can be executed through various computing devices and recorded on a computer-readable medium. In particular, the program according to the present embodiment may be configured as a PC-based program or an application exclusively for mobile terminals. An application to which the present invention is applied may be installed on a user terminal through a file provided by a file distribution system. For example, the file distribution system may include a file transmission unit (not shown) that transmits the file at the request of the user terminal.

[0102] The devices described above may be implemented as hardware components, software components, and / or a combination of hardware components and software components. For example, the devices and components described in the embodiments may be implemented using one or more general-purpose computers or special-purpose computers, such as, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), a programmable logic unit (PLU), a microprocessor, or any other device capable of executing instructions and responding. The processing device may execute an operating system (OS) and one or more software applications running on the operating system.

[0103] Additionally, the processing device may access, store, manipulate, process, and generate data in response to the execution of software. For ease of understanding, the processing device is sometimes described as being used alone; however, those skilled in the art will appreciate that the processing device may include multiple processing elements and / or multiple types of processing elements. For example, the processing device may include multiple processors, or a processor and a controller. Other processing configurations, such as parallel processors, are also possible.

[0104] Software may include computer programs, codes, instructions, or a combination of one or more of these, which may configure a processing device to perform a desired operation or may, independently or collectively, command the processing device. The software and / or data may be permanently or temporarily embodied in any type of machine, component, physical device, virtual equipment, computer storage medium, or device for interpretation by the processing device or for providing instructions or data to the processing device. The software may also be distributed across network-connected computing devices and stored or executed in a distributed manner. The software and data may be stored on one or more computer-readable recording media.

[0105] The method according to the embodiment may be implemented in the form of program commands that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program commands, data files, data structures, etc., alone or in combination. The program commands recorded on the medium may be those specially designed and configured for the embodiment or may be those known and available to those skilled in the art of computer software. Examples of the computer-readable recording medium include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, magneto-optical media such as floptical disks, and hardware devices specially configured to store and execute program commands such as ROMs, RAMs, and flash memories.

[0106] Examples of program instructions include not only machine language code, such as that generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter, etc. The hardware device described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

[0107] Although the embodiments have been described with limited examples and drawings, those skilled in the art will recognize that various modifications and variations can be made based on the above teachings. For example, appropriate results can be achieved even if the described techniques are performed in a different order than described, and / or components of the described systems, structures, devices, circuits, etc. are combined or combined in a different manner than described, or are replaced or substituted with other components or equivalents. Therefore, other implementations, other embodiments, and equivalents of the claims also fall within the scope of the following claims.

Claims

1. A method for controlling access to a container platform based on the detailed role of an accessor, implemented as a computing device including one or more processors and one or more memories storing instructions executable by the processors, A user authentication step for determining whether a user is an authorized user of the server system by verifying the identity of a user accessing the server system using user information registered in a trust decision machine; A trust level verification step in which, if the user is authenticated as an authorized user, the trust decision machine evaluates the trust level according to the security status of the user terminal and determines whether the trust level evaluation result of the user terminal satisfies the access permission criteria set by the server system; After the trust level verification for the user terminal is completed, when information on a target resource to be accessed from the user terminal is collected, a resource access control step in which a trust enforcement machine with synchronized access policies for each resource performs access control for the target resource based on the role granted to the user and the trust level evaluated for the user terminal; and, A container platform authorization control method based on the detailed role of an accessor, characterized in that it includes an authorization control step for controlling whether to approve the deployment of a containerized target resource by using an authorization control machine based on a security kernel when a request for deployment of the target resource is made from a user or user terminal that has accessed the target resource.

2. In paragraph 1, The above approval control machine of the above approval control step, Decide whether to approve deployment for the containerized target resource based on the security policy set in the above security kernel. A container platform authorization control method based on detailed roles of accessors, characterized in that it checks whether an explicit deny policy related to the containerized target resource exists in a security policy database and, if an explicit deny policy exists, denies deployment to the containerized target resource.

3. In paragraph 2, In the above security policy database, A container platform authorization control method based on detailed roles of accessors, characterized in that a basic security policy for resources managed in the above server system and a custom security policy according to the role of an authorized user are managed.

4. In paragraph 3, The above approval control machine, A container platform authorization control method based on the detailed role of an accessor, characterized in that when a change in an element including at least one of the user's role and the trust level of the user terminal is detected during the progress of the deployment life cycle of the containerized target resource, the deployment of the containerized target resource is stopped using a hook command.

5. In paragraph 1, A plurality of resources managed in the above server system can be grouped into a plurality of groups based on criteria including at least one of roles and asset importance. A container platform authorization control method based on detailed role of accessor, characterized in that independent access policies can be set for required user roles and trust levels of user terminals for each resource and each resource group.

6. In paragraph 5, The trust enforcement machine of the above resource access control step, A container platform authorization control method based on detailed roles of accessors, characterized in that the access policies for each resource and each resource group, which are updated in a resource access policy management system at preset intervals, are received and synchronization for the updated resource access policies is performed.

7. In paragraph 1, The above confidence level verification step is: A container platform authorization control method based on the detailed role of an accessor, characterized in that after evaluating the trust level according to the security status of the user terminal, the evaluation result is provided to the user terminal, an electronic signature of the user is requested for the evaluation result, a signature response based on a private key is received, and the received signature response is checked to see whether it matches the user's public key among the user information already registered in the trust decision machine, thereby performing trust level verification based on an electronic signature.

8. In a container platform admission control device based on the detailed role of an accessor, implemented as a computing device including one or more processors and one or more memories storing instructions executable by the processors, A user authentication unit that verifies the identity of a user accessing the server system using user information registered in a trust decision machine to determine whether the user is an authorized user of the server system; A trust level verification unit that causes the trust decision machine to evaluate a trust level according to the security status of the user terminal when the user is authenticated as an authorized user, and determines whether the trust level evaluation result of the user terminal satisfies the access permission criteria set by the server system; After the trust level verification for the user terminal is completed, when information on a target resource to be accessed from the user terminal is collected, a resource access control unit in which a trust enforcement machine with synchronized access policies for each resource performs access control for the target resource based on the role granted to the user and the trust level evaluated for the user terminal; and, A container platform authorization control device based on the detailed role of an accessor, characterized in that it includes an authorization control unit that controls whether to approve distribution of a containerized target resource using an authorization control machine based on a security kernel when a distribution request for the target resource is made from a user or user terminal that has accessed the target resource.

9. In a computer-readable recording medium, The above computer-readable recording medium stores instructions that cause a computing device to perform the following steps, the steps being: A user authentication step for determining whether a user is an authorized user of the server system by verifying the identity of a user accessing the server system using user information registered in a trust decision machine; A trust level verification step in which, if the user is authenticated as an authorized user, the trust decision machine evaluates the trust level according to the security status of the user terminal and determines whether the trust level evaluation result of the user terminal satisfies the access permission criteria set by the server system; After the trust level verification for the user terminal is completed, when information on a target resource to be accessed from the user terminal is collected, a resource access control step in which a trust enforcement machine with synchronized access policies for each resource performs access control for the target resource based on the role granted to the user and the trust level evaluated for the user terminal; and, A computer-readable recording medium characterized by including an authorization control step for controlling whether to approve distribution of a containerized target resource by using an authorization control machine based on a security kernel when a distribution request for the target resource is made from a user or user terminal that has accessed the target resource.

Images