KR101967663B1 - A system for access control based on the role of process in the white list - Google Patents

Abstract

The present invention relates to an access control system based on ta role of an applied process, capable of safely and doubly protecting a system. According to the present invention, the access control system based on a role of an applied process comprises a process role list, a role policy list, an executing process list, a file execution control unit, an applied file determination unit, a role policy management unit, a role policy storage unit, a process generation management unit, and a role-based policy control unit.

Description

A Role Based Access Control System for Authorized Processes.

The present invention relates to a method and apparatus for judging whether a file to be executed is an authorization file, storing an authorized file in an authorization file list, performing a role-based control policy on the process of the executable file stored in the authorization file list Based access control system.

In particular, the present invention relates to a method of controlling access to a file and a registry based on a role of a process by setting a role access control policy in a driver of a kernel layer for an executable file process stored in an authorized file list, Based access control system.

In addition, according to the present invention, when a different approach is performed in contrast to a legitimate user access pattern that has been performed for a user's access, a hacker who is not a normal user or a user with malicious intention seizes a user account Based access control system of an authorized process for preventing an attack even after normal authentication.

Generally, it is determined whether the pattern information of the file matches the detection information for searching for an abnormal file in order to detect malicious code. That is, the conventional malicious code detection technology mainly uses a virus detection method using a blacklist.

With unprecedented growth of unknown malware, it no longer depends entirely on solutions that detect known malicious code for computer terminal protection, that is, blacklisted solutions. In addition, even though the threat of unknown malicious code is identified, it takes 24 to 72 hours to analyze the malicious code and generate the signature of the malicious code and apply it to the infected computer terminal. Therefore, the data and the system of the computer terminal are exposed to the threat during the update period by reflecting the new malicious code.

Therefore, a white list-based solution has been developed and studied as an alternative for computer terminal systems in such environments [Patent Literatures 1, 2, and 3]. That is, the prior art employs a scheme that allows execution only for authorized files. Therefore, the technology has little pattern update and can be used without difficulty even on a low specification computer terminal.

However, since the above-described conventional technology allows only the authorized file to be executed, it is impossible to protect the computer terminal when malicious code unknown to the authorized file list is included.

In other words, the above-described prior art prevents execution of an authorization file or execution of an unauthorized file, but does not proceed with additional control after the authorization file is executed and the process becomes a process. Therefore, after an unknown malicious code is added to the authorized file list, there is a problem in that it can not cope with an operation of accessing a document and important system resources to leak and modulate.

Korean Registered Patent No. 10-1247943 (Announcement of Apr. 02, 2013) Korean Patent No. 10-1838973 (Announcement of Mar. 19, 2018) Korean Registered Patent No. 10-1780891 (Announcement of September 21, 2017)

An object of the present invention is to solve the above-mentioned problems, and it is an object of the present invention to provide a method and apparatus for judging whether or not an authorized file is an executable file, storing an authorized file in an authorized file list, Based access control system that implements a control policy based on a user-defined process.

Particularly, the object of the present invention is to allow the authorized process to access the protected file through the role access control policy corresponding to the role, and the authorized process without the role to be protected through the file access control policy Based access control system that blocks access to a file that has been granted access.

It is another object of the present invention to provide a method and apparatus for allowing an executable file to be executed when determining whether an executable file is an authorization file, , The process role and the process role policy are set in the driver module of the kernel layer, and when the process is generated in the kernel driver after the execution is permitted, a list of the roles having the same path exists in the already set role list Based access control system of an authorized process that stores the process role in the process list.

It is another object of the present invention to provide a method and apparatus for controlling access to a protected file by determining whether to apply a role-based access control policy or a file- Based access control system.

In particular, it is an object of the present invention to provide a method and apparatus for accessing a protected file by applying a role role policy before a file access control policy, The authorization process that does not have a role is granted the role-based access control system of the authorized process which blocks the access of the file protected by the control policy by applying the file access control policy since the role policy does not exist. .

In order to achieve the above object, the present invention relates to a role-based access control system of an authorized process, which is executed on an operating system of a computer system and performs access control on a file access request of a process executed in a user layer of the operating system A list of process roles that list the roles of the process based on the process path; A list of role policies that store access control policies (hereafter, role policies) for the roles of the processes; A list of execution processes that store the path and role of the running process; A file execution control unit that suspends execution of a requested file (hereinafter referred to as a request file) when the process requests execution of the file, and permits or blocks execution of the request file according to a result of whether the request file is an authorization file ; An authorization file determination unit for determining whether the request file is an authorization file and returning a determination result to the file execution control unit; A role policy manager for requesting the process role of the request file and the role policy to be reflected in the process role list and the role policy list when the request file is an authorization file; A role policy storage unit for updating the process role list and the role policy list according to a request of the role policy management unit; A process generation management unit for inquiring the process role list when the process is created, adding the path and the role of the process to the execution process list, and storing the process; And a role-based policy control unit for performing access control based on the role of the process when the process requests file access (hereinafter referred to as non-execution file access) rather than file execution.

In the role-based access control system of an authorized process, the file execution control unit, the role policy storage unit, the process generation management unit, and the role-based policy control unit are configured in the kernel layer of the operating system The authorization file determination unit, and the role policy management unit are configured in the user layer of the operating system.

According to another aspect of the present invention, there is provided a role-based access control system for an authorized process, wherein the system performs access control based on a file-based requested file (hereinafter referred to as a request file) And a file-based policy control unit.

According to another aspect of the present invention, there is provided a role-based access control system for an authorized process, wherein the authorization file determination unit extracts a hash value of an executable code of the request file to generate authentication information, And determines whether the request file is an authorization file, and the authentication information of the authorization file is made a hash value of the executable code of the authorization file.

According to another aspect of the present invention, there is provided a role-based access control system for an authorized process, wherein the process role list stores a process role list based on a path of the process, .

As described above, according to the role-based access control system of the authorized process according to the present invention, even if an unknown malicious program is added to the authorization file, the role of accessing the file protected by the file access control policy is given Therefore, it is possible to block the operation of accessing and leaking or modulating the file, thereby providing an effect of safely protecting the system. That is, unless an unknown malicious program adds the authorized file list and the process role is concurrently granted, it is determined that the file is an authorized file and the execution is blocked. If the malicious program does not grant the role even if it is executed, It is possible to block the leakage and tampering of protected files.

In addition, according to the role-based access control system of the authorized process according to the present invention, compared to the existing technique of granting the process role based on the path by granting the process role based on the hash value of the file, It is possible to fundamentally block the case where the role is given to the process due to the role assignment and the leakage and modulation of the protected file occur.

In addition, according to the role-based access control system of the authorized process according to the present invention, the processes to be set and allowed in the access control policy of the protected file are compared with the previous method in which the path is added, Since the process role is granted and the access is allowed by the role based policy, it is possible to reduce the inconvenience of management caused by continuously adding or changing the process path to the access control policy after setting the access control policy.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram of an entire system for implementing the present invention. FIG.
2 is a block diagram of a role based access control system of an authorized process in accordance with an embodiment of the present invention;
3 is a flowchart illustrating a method of performing a file execution control unit according to an embodiment of the present invention.
4 is a flowchart illustrating a method performed by an authorization file determination unit and a role policy management unit according to an embodiment of the present invention.
FIG. 5 is a flowchart illustrating a method of performing a role policy storage unit according to an embodiment of the present invention. FIG.
FIG. 6 is a flowchart illustrating a method performed by a process generation management unit according to an embodiment of the present invention; FIG.
FIG. 7 is a flowchart illustrating a method performed by a role-based policy control unit according to an exemplary embodiment of the present invention; FIG.
FIG. 8 is a flowchart illustrating a method performed by a file-based policy control unit according to an exemplary embodiment of the present invention; FIG.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the present invention will be described in detail with reference to the drawings.

In the description of the present invention, the same parts are denoted by the same reference numerals, and repetitive description thereof will be omitted.

First, an example of the configuration of the entire system for implementing the present invention will be described with reference to FIG.

As shown in Figure 1, the present invention is implemented within a conventional computer system. That is, the overall system for implementing the present invention includes hardware 60, an operating system (OS) 20, a process 10 performed on the operating system, an access control module 30, an authorization file checking module 40 ). Further, it may be configured by adding a database 50 for storing a whitelist.

First, the hardware 60 refers to physical resources of the system such as an input / output device, a storage device (hard disk, etc.), a network device (a network card, etc.) The operating system 20 is a system program for operating a computer system, which is also commonly referred to as a kernel layer. Typically, user computer programs run as a process at the user level.

In particular, the hardware 60 includes storage resources such as a hard disk and a USB, and when the process 10 accesses and modifies a file, the process 10 is transferred to the hardware 60 through the kernel layer Accessed and modulated contents are stored. That is, the file is stored in the storage device of the hardware 60, and the contents modulated by the process 10 are reflected and stored in the file.

The kernel layer of the operating system 20 includes a system processing module for processing a system call such as an API function, a driver 23 for controlling the hardware device 60, and the like. The called system call (or API function) is processed by the system processing module of the kernel layer and, if necessary, accessed by the driver. At this time, calling the API function is called a system call. That is, in order to use the resources (hardware resources) of the computer system, a system call is called at the user layer.

Specifically, a file is opened, created, changed, or written by a system call (open (), read (), write (), etc.) of the file system provided by the operating system 20. The executable file is executed by a file execution system call (exec (), system (), etc.) provided by the operating system 20. That is, the system call includes a call function for creating and terminating a process.

On the other hand, a callback function is a function that is automatically called when a process is created and terminated, or when a process attempts to execute or access a file. It is explained that the callback function is used to create / terminate the process and access the file directly. However, for convenience of explanation, it is explained that it is executed by the system call.

Next, the process 10 refers to a state in which the computer program is executed on the operating system, and is also referred to as a program (program) code. Therefore, malicious code, malicious programs, and malicious processes are used in combination.

Process 10 also invokes an API (Application Programming Interface) function of the system dynamic library (such as Win32.dll) to utilize the resources (hardware resources) of the computer system. In particular, the process 10 invokes a system call, such as an API function, to create, open, or execute a file. That is, the process 10 of the user layer uses a service for resources of the operating system kernel layer by calling an API function. At this time, the process 10 transfers the path of the corresponding file and the process information as factors.

On the other hand, the process 10 is generated by a file execution system call or a process generation system call (fork, execve, etc.). That is, when one process executes a file by a file execution system call, another process by execution of the file can be created.

In particular, when a process is created, the process execution path (or process path) and process ID are passed as arguments through a previously registered function (or callback function). Here, the callback function is a function to be called automatically when the process creation / termination system call is called, and is created in advance and registered in the corresponding system call.

That is, when a process is created and terminated, the callback function passes the process execution path and the process ID as arguments. An information list is generated with the process ID as a key in the list of execution processes managed by the driver. Also, the user ID is inquired through the kernel API function, and the process role list is inquired and stored through the process path. Also, newly executed processes are added and managed in the execution process list.

Next, the access control module 30 determines whether the file (in particular, the executable file) of the process 10 is an authorized file and controls or accesses the file based on the role of the corresponding process ). That is, when the access control module 30 executes the file through the process 10 or modulates the file, the access control module 30 performs control on the file.

At this time, the access control module 30 can hook up a system call and control access to resources such as execution, creation, and opening of a file. That is, the access control module 30 configures a module (or a system call hooking module) for hooking a system call and hooks a system call or a system dynamic library (API function) by a normal hooking method. At this time, the system call is a call function for accessing a file such as execution, creation, modification, opening of a file, or a call function for creation and termination of a process.

Specifically, when the execution of the executable file is requested, the access control module 30 queries the process information and executable file path, and then suspends execution of the file. After the execution is suspended, the inquiry process information and the execution file path are passed to the authorization file checking module 40 to confirm whether the file is an authorization file. Then, the access control module 30 receives the determination result of whether the executable file is authorized (or whether it is an authorized file) from the authorization file checking module 40. And executes or blocks the file according to whether or not the file is authorized.

If the file is an authorization file, the access control module 30 inquires the process role and the role-based file access control policy. Thus, if there is a process role in the same path, it sets up process role information and role access control policy. In other words, you set the role and role-based policy together with the authorization file.

In particular, if the authorization file is checked through the authorization file checking module 40 and the process role and the role access control policy are inquired, the access control module 30 permits the authorization file to be executed. In addition, process roles and role policies query whether the same process roles and role policies are set. If the same process role and role policy do not exist, it is stored in the access control module 30. If the file is unauthorized, execution is blocked.

Next, the authorization file checking module 40 determines whether the requested file is an authorized file.

That is, the authorization file checking module 40 opens the file of the requested route, and checks the file header information, the execution area data location information, and the execution area data according to a predetermined rule. In particular, the authorization file checking module 40 generates a hash value based on the data of the corresponding area, compares the generated hash value with the hash value of the authorization file list generated through the database, and checks whether the same hash value exists . If the same hash value exists, it is determined that the file is an authorization file. If there is no identical hash value, it is determined that the file is an unauthorized file. Through this check, it is determined whether the process 10 is a normal file registered at the beginning or a file modulated by another cause. At this time, a judgment condition for judging whether or not the file is an authorization file is provided in advance. The judgment condition is to search for an executable file existing in the PC system except for the file judged to be a malicious process, and generate an authorized file list.

Next, the database 50 is composed of an authorization file DB 51 for storing authorization file information, process role information of the authorization file, and a role policy DB 52 for storing a role access control policy. However, the configuration of the database 50 is only a preferred embodiment, and other structures may be constructed in accordance with the database construction theory in consideration of the ease and efficiency of access and retrieval in developing a specific device.

Next, the configuration of a role-based access control system of an authorized process according to an embodiment of the present invention will be described in more detail with reference to FIG.

As shown in FIG. 2, the role-based access control system according to the present invention includes an access control module 30 configured at the kernel layer and an authorization file checking module 40 configured at the user layer.

The access control module 30 includes a file execution control unit 31 for controlling the execution of a file, a role policy storage unit 32 for storing a process role and a role access control policy, A role-based policy control unit 34 that controls based on the role, and a file-based policy control unit 35 that controls based on the file, . In addition, a list of process roles (36) for storing a list of roles of the processes, a list of execution processes (37) for storing a process ID and a process role for a currently executed process as a list, a role policy A list 38, and a file policy list 39 for storing a file policy as a list.

In addition, the authorization file checking module 40 judges whether the authorization file is an authorization file and returns the result, and if the authorization file is a authorization file, the process role and its role policy are reflected in the access control module 30 And a role-policy managing unit 42 for managing the role-policy managing unit 42.

First, the file execution control unit 31 suspends the execution of the file (or the requested file and the request file) when the process requests the execution of the file, determines whether or not the file is an authorization file, Allow or block the execution of the file.

That is, the file execution control unit 31 suspends the execution of the file and requests the authorization file determination unit 41 to determine whether the file is an authorization file. Specifically, the file path is inquired, the process information is inquired, and the execution action is suspended. When the file execution control unit 31 receives a response to the authorization file determination unit 41 from the authorization file determination unit 41, the file execution control unit 31 determines whether the execution of the held action (or the execution of the held corresponding file) .

A concrete implementation method is shown in Fig.

As shown in FIG. 3, when the process 10 requests the file operation, the file execution control unit 31 inquires the path of the file and inquires the information of the requested process.

Here, the process information includes a process ID, a user ID, a process path (an executable file path of a process, an execution path of a process), a process role list, and the like. This information is used in the role control policy and the file control policy, and also the log is generated by referring to the process information.

Specifically, when trying to execute or access a file, a handle containing information about the file is passed as an argument via a system call (or callback function). The path of the file is inquired by referring to the file information managed by the operating system by using the file information handle.

It also queries the operating system for the process ID of the current process (or current process). That is, the ID of the current process can be inquired through a kernel API function or the like. The process path is referred to by referring to the execution process list 37 by using the inquired process ID (the process ID of the process requesting the file operation).

Next, analyze the requested file operation (access behavior of the file) and confirm what action (operation) is desired. That is, it confirms whether the file access operation is any of creation, opening, and execution of a file.

Next, if it is determined that the file is to be executed as a result of the check, the file action is stored for execution hold and the inquired file path and process information are transmitted to the authorization file determination unit 41. If it is determined that the file is not to be executed, it is transmitted to the role-based policy control unit 34.

Next, the file execution control unit 31 receives a result of the authorization file determination unit 41 as to whether or not the file is an authorization file. If the returned result is an authorized file, execute the stored action that is pending and proceed. If it is not an authorized file, it blocks execution and terminates the action.

Next, the authorization file determination unit 41 determines whether the requested file (or executable file, request file) is an authorization file, and returns the determination result to the file execution control unit 31. [ In particular, the authorization file determination unit 41 determines whether or not the authorization file of the executable file is determined by using the authorization information of the authorization file stored in advance.

If the executable file is an authorization file, the role policy management unit 42 reflects the process role list 36 and the role policy list 38 for the executable file. Preferably, the role policy management unit 42 is performed by a request (request) from the authorization file determination unit 41.

At this time, the authorization file determination unit 41 or the role policy management unit 42 uses the authorization information of the authorization file stored in advance, the previously stored process role, and the role policy. That is, the authorization information of the authorization file and the process role for each authorization file are stored in advance in the authorization file DB 51, and the role policy for the process role is stored in the role policy DB 52 in advance.

In particular, the authorization file DB 51 stores authentication information (information capable of identifying or authenticating whether or not an authorization file exists) for all executable authorization files existing in the computer terminal, . Preferably, the authentication information of the authorization file is a hash value of the authorization file. More preferably, the authentication information of the authorization file is a hash value for the executable code of the authorization file.

Preferably, the authorization file determination unit 41 or the role policy management unit 42 stores the hash value (authentication information) and the process role policy for the authorization file in the authorization file DB 51 or the role policy DB 52, And stores it in a memory as a hash table form (or a hash table form). Thus, the search speed for judgment can be increased.

On the other hand, the hash table structure is one of the data structures for storing and retrieving data in the memory. The advantage of the hash table structure is that the hash value can be quickly indexed even if there is a lot of information to be retrieved. Therefore, the search speed can be increased and the judgment can be made quickly.

That is, the file path is used as follows. When the file is executed by the process, the current action is suspended, and the path and the process information of the inquired file are received. In the authorization file determination unit 41, the file of the execution- And converts the inquired data into a hash value to determine whether or not the same hash value exists. Thus, if the same hash value exists, it is an authorization file, allowing execution, and blocking execution if it does not exist.

A specific implementation method is shown in Fig.

As shown in FIG. 4, the authorization file determination unit 41 is performed at the request of the file execution control unit 31. That is, after execution of the file (execution file) is suspended by the file execution control unit 31, the process information and the path of the file are received.

Next, the authorization file determination unit 41 refers to the path of the executable file (request file), opens the executable file, and reads the file content of the executable file. This is for extracting the authentication information of the executable file and comparing it with the authentication information of the authorization file stored in advance. At this time, the authentication information is a value obtained by hashing the file contents of the executable file. It is preferably a hash value obtained by hashing executable code of an executable file.

Concretely, the header information of the executable file is checked to confirm that the executable file is executable, and the start address of the execution area data (or executable code) is confirmed. At the start address, data is copied as much as the size of the execution data, and the hash value is extracted from the data of this area.

The hash value is extracted using only the data directly related to the execution of the executable file. Therefore, even if the data in the different area is different, the same file can be recognized as the same file. In addition, it is possible to prevent an unnecessary increase in the amount of data for storing authorization file information, and it is possible to solve the problem of recognizing an executable file that performs the same action as another file.

Next, the authorization file determination unit 41 searches whether the authentication information (hash value) generated in the executable file exists in the same hash table (authentication information of the authorization file, that is, the table storing the hash value). If there is no identical authentication information (hash value), it is judged as an unauthorized file. If there is the same hash value, it is judged as an authorized file.

Next, the determination result is transmitted to the file execution control unit 31. [

If the executable file is an authorization file, the role policy management unit 42 inquires whether there is a role to be assigned. At this time, referring to the role policy DB 52, the process role of the authorization file is inquired.

Next, when there is a process role, the role policy management section 42 inquires, via the role policy storage section 32, whether the role of the inquired process is in the process role list 36. If the process role list 36 is not found, So that the role information is stored in the corresponding list 36. At this time, it is determined whether or not the process role list 36 exists using the process path.

In addition, the role policy management unit 42 inquires of the role policy DB 52 about the role access control policy corresponding to the process role. The role access control policy is stored in the list 38 if the role access policy is in the role policy list 38 through the role policy storage unit 32. If the role access policy is not in the role policy list 38, do.

Here, the process role is defined by defining a main function performed by the corresponding process. For example, the process role is divided into functions such as document editing, mail, web browser, and registry editing. Internet Explorer, Chrome, Mozilla, and others all perform functions of a Web browser, so that all the processes by these executable files have the role of a "Web browser".

In addition, a role policy for a process role is a policy that differently assigns a control policy according to the role of a process and controls the process by a control policy corresponding to a specific role when the process has a specific role.

As an example, a control policy can be set so that the registry can not be edited for the role of the web browser. In this case, the process is the role of the web browser. If you try to edit the registry, it blocks the access (work) according to the role control policy.

As another example, a role policy can be set to allow access to an object having a document extension for a document editing role. Also, a file control policy can be set to block access to all processes for objects with document extensions. In this case, the process is a document editing role. If a document is edited, document editing is permitted by the role policy that overrides the file control policy. If the process does not have the role, document editing is blocked by the file control policy.

As another example, in the case of a document file, a role control policy may be set differently for each role, as opposed to a file control policy. For example, the file control policy sets a policy to grant only read access to the word document extensions doc, docx, and to block write, delete, and file name changes for all processes. In contrast, the role control policy sets a policy that grants full rights to the word extensions doc and docx. The method of applying the policy is to inquire the role of the process. If there is a policy corresponding to the role, apply the role policy first, and if not, apply the file control policy.

Next, the role policy storage unit 32 receives the process role and role access control policy from the role policy management unit 42 and reflects the corresponding role and control policy in the process role list 36 or the role policy list 38 .

A specific method is shown in Fig.

As shown in FIG. 5, first, the role policy storage unit 32 inquires the process role list 36 about the same process role list based on the process path.

If there is no process role list in the same path, the process role information transferred to the process role list 36 is stored.

In addition, the role control policy also inquires whether there is a role control policy corresponding to the role value or whether it exists in the role policy list (38). If the role control policy corresponding to the role value is not present in the corresponding list (38), the transferred role policy is added to the list (38) and stored.

As an example, the configuration of the process role list 36 may be configured as follows.

That is, the role of the word document is a role policy that allows access to doc and docx extension files. The PowerPoint document role is governed by a role policy that allows access to the ppt, pptx extension files. The Excel document role is governed by a role policy that allows access to xls, xlsx extension files. The Hangul document role is governed by a role policy that allows access to the hwp extension file.

Next, when the process is created, the process creation management section 33 adds the process ID, the path of the process, the role, and the like to the execution process list 37 and stores it. At this time, the process role list 36 is inquired based on the process path, and the process role stored in the list 36 is referenced.

That is, the process creation management unit 33 is executed (called) by a system call (or a callback function) of process creation. That is, it is executed by a function that is automatically called when a process is created. At this time, the process ID and the process path (the path of the process executable file) are passed as arguments.

Then, the process creation management unit 33 retrieves (searches) the process role of the corresponding process from the process role list 36 based on the received process path (searching with a path as a key).

Then, the process creation management unit 33 reflects the process ID, the process path, and the inquired process role of the corresponding process in the execution process list 37 and updates it.

A specific method is shown in Fig.

As shown in FIG. 6, first, the process generation management unit 33 refers to the process role list 36 based on the process path passed as an argument, and inquires whether the process role of the process is included in the list.

If there is no process role list in the same path, it is determined that there is no role, and the process ID and the process path are stored in the execution process list 37. At this time, it is stored that there is no process role in the process.

If there is a process role list in the same path, the process role is inquired, and the process ID, the process path, and the list of the inquired process role are added to the execution process list 37 and stored.

The process of creating and controlling a process is summarized as follows.

When the process A requests the execution file B to be executed, the file execution control unit 31 requests the application file determination unit 41 whether the execution file B is an authorization file. If the authorization file determination unit 41 determines that the file is an authorization file, the role policy management unit 42 refers to the DBs 51 and 52 to determine whether there is a role or role policy of the executable file B or the process B in the role policy management unit 42. The role policy management unit 42 registers the process role and the role policy of the process B (or the execution file B) in the process role list 36 and the role policy list 38 through the role policy storage unit 32. [ Then, the file execution control unit 31 causes the execution file B to be executed, and the process B of the execution file B is generated. At this time, the process creation management unit 33 refers to the process role list 36, and registers the process ID, process path, and process role of the process B in the execution process list 37.

That is, when an execution file is requested to be executed, the process is suspended and the authorization file and process role list 36 are inquired based on the process information and the execution file path. When setting up the process role list 36 together with the authorization file, a list is set based on the process path. When the execution of the executable file is permitted and the process ID and the process path are received as parameters of the function when the process is created, the process role list 36 is inquired based on the process path (using the key) Reflects process information (process ID, process path, process role, etc.) into the list of running processes (37).

As an example, the role of a word document is to apply a role policy that allows access to doc, docx extension files. In addition, the PowerPoint document role is governed by a role policy that allows access to ppt, pptx extension files. The Excel document role is governed by a role policy that allows access to xls, xlsx extension files. The Hangul document role is governed by a role policy that allows access to the hwp extension file.

At this time, when the execution file is requested to be executed, it is determined as an authorization file. If the role of the corresponding process is a word document role, a PowerPoint document role, and a Hangul document role, three process roles are assigned to the process role list Based process is added and updated before the process is created. When the execution file of the corresponding path is allowed to be executed and the process is created, the process is added to the corresponding execution process list 37 by using the process path and the process ID information which are passed as arguments. At this time, the process role list 37 is inquired based on a path, and is set in the execution process list 37.

Therefore, since the process roles are set in the execution process list 37, when the access of the document file is requested, the current process ID of the requested system call is inquired through the kernel API function, Referring to the process list 37, the process roles of the requested process can be inquired, thereby determining whether or not the role exists.

Next, the role-based policy control unit 34 performs access control based on the role of the requesting process for the file access request (or non-execution file operation), which is not executed by the process 10. [ That is, if the requested operation is a file execution, control is performed by the file execution control unit 31. If the requested operation is access to a file, role-based access control is performed by the role-based policy control unit 34 do.

A specific method is shown in Fig.

As shown in FIG. 7, first, the role-based policy control unit 34 refers to the execution process list 37 based on the process ID, and inquires about the process information and the role. At this time, the process ID inquires the ID of the current process (the process performing the work) using the kernel system function (a function provided by the operating system).

It inquires the execution process list 37 and determines whether a process role exists in the inquired process information.

If it exists in the process role, the role policy of the corresponding process is inquired from the role policy list 38. Query process role policies as many as the number of roles of the corresponding process. In other words, by querying the role-based policies for as many process role lists as possible, it applies the policies for matching file and registry paths, if any, to allow access to files and registries protected by file-based policies.

Allows file or registry access that is protected by the referenced process role policy. If the role or role policy of the process does not exist, the file-based policy control unit 34 causes the control to proceed. That is, the role-based policy control unit 34 applies the policy in preference to the file-based policy when the process role and the role policy exist.

Next, when the requested operation is a file execution, the file execution control unit 31 performs control, and performs role-based access control when the requested operation is the file access.

Specifically, the presence or absence of a process role and the presence or absence of a role control policy are determined, and the process is controlled according to the role of the process and the role policy, if any, of the role. If the role or role policy of the process does not exist, the file-based policy control unit 35 causes the control to proceed.

That is, the role-based policy control unit 34 applies the policy in preference to the file-based policy when the process role and the role policy exist. Apply role-based policies corresponding to process roles to allow access to files and registries protected by file-based policies.

Next, the file-based policy control unit 35 blocks access to the file, which is protected by the file-based policy, when the authorization process, in which the role of the process 10 does not exist, attempts to access the file.

In particular, the file-based policy control unit 35 sets and stores a file policy list 39 to be recorded as a list of file policies in advance, and if the file to be accessed by the process exists in the file policy list 39, And access control to

The file policy list 39 includes a file identifier and access control contents for the file. Preferably, the file identifier is set to the path of the file, and the access control content of the file is a control that is blocked or allowed by a user (user ID), a user group (group ID), a process path,

That is, the file policy is set based on the path of the file, the file name, the extension, and the like. That is, it is determined whether or not the entire path of the file, the file name of the matching file, or the extension of the file coincides with each other.

As an example of a file policy, if execution is control, write is permitted, deletion is allowed, and the policy is set as such, it is determined whether or not the file is permitted to be blocked based on the accessing behavior of the access request to the file.

A specific method is shown in Fig.

As shown in FIG. 8, first, the file-based policy control unit 35 receives a file path from the role-based policy control unit 34.

Next, the file-based policy control unit 35 determines whether a file policy exists in the path of a file that the process is accessing.

Next, the file-based policy control unit 35 performs the permission or blocking according to the matching result when the file policy matches. That is, if user information and process information are compared and there is matching information, it is determined whether or not the corresponding action is permitted, and it is determined whether to block the accessing action. It is blocked by the policy because it is set to block access.

Although the present invention has been described in detail with reference to the above embodiments, it is needless to say that the present invention is not limited to the above-described embodiments, and various modifications may be made without departing from the spirit of the present invention.

10: Process 20: Operating system
30: access control module 31: file execution control section
32: Role policy storage unit 33: Process creation management unit
34: role-based policy control unit 35: file-based policy control unit
36: List of Process Roles List 37: List of Execution Processes
38: Role policy list 39: File policy list
40: authorization file checking module 41: authorization file judgment unit
42: Role policy manager
50: database 51: authorization file DB
52: Role policy DB
60: Hardware

Claims (5)

A role-based access control system of an authorized process which executes access control on a file access request of a process executed on an operating system of a computer system and executed in a user layer of the operating system,
A list of process roles that list the roles of the process based on the process path;
A list of role policies that store access control policies (hereafter, role policies) for the roles of the processes;
A list of execution processes that store the IDs, paths, and roles of the running processes;
A file execution control unit that suspends execution of a requested file (hereinafter referred to as a request file) when the process requests execution of the file, and permits or blocks execution of the request file according to a result of whether the request file is an authorization file ;
An authorization file determination unit for determining whether the request file is an authorization file and returning a determination result to the file execution control unit;
A role policy manager for requesting the process role of the request file and the role policy to be reflected in the process role list and the role policy list when the request file is an authorization file;
A role policy storage unit for updating the process role list and the role policy list according to a request of the role policy management unit;
A process generation management unit that inquires the process role list when creating a process and adds a process path and a role to the execution process list based on an ID of the process to be created; And
And a role-based policy control unit for performing access control based on the role of the process when the process requests file access (hereinafter referred to as non-execution file access) rather than file execution,
The authorization file determination unit extracts a hash value of the executable code of the request file to generate authentication information, determines whether the request file is an authorization file in contrast to authentication information of a preset authorization file, The authentication information is made into a hash value of the executable code of the authorization file,
The hash value of the authorization file and the process role of the authorization file are stored in the authorization file DB,
The role policy for the process role is stored in the role policy DB in advance,
The authorization file determination unit determines whether the request file is an authorization file by referring to the authorization file DB,
If the request file is an authorization file, the role policy management unit refers to the authorization file DB and the role policy DB to inquire the process role and the role policy of the authorization file, and, through the role policy storage unit, The process role is stored in the process role list, the process path is stored as a path of the request file based on the process path,
Wherein the role-based policy control unit refers to the execution process list based on the process ID, and inquires the process information and the role.
The method according to claim 1,
Wherein the file execution control unit, the role policy storage unit, the process generation management unit, and the role based policy control unit are configured in a kernel layer of the operating system,
Wherein the authorization file determination unit and the role policy management unit are configured in a user layer of the operating system.
The system of claim 1,
And a file-based policy control unit for performing access control based on a file-based requested file (hereinafter referred to as a request file) when the process does not have a role of a process. .
delete delete

Images