KR102214162B1 - A user-based object access control system using server's hooking - Google Patents

Abstract

The present invention relates to a user-based object access control system through server hooking, which controls object access according to an object access policy assigned to an individual user when accessing a server with a service account of the server to access an object such as a file or a directory in the server in a gateway-based access control system in which a gateway is provided between a user terminal and the server to perform relay therebetween. The system comprises: an access policy management unit which stores and manages access authority information for each user with respect to an object of the server as an access control policy; a connection information management unit which manages connection information including user information and server access information as information generated when the user terminal accesses the server; an access authority authentication unit which authenticates an access authority of a user with respect to a specific object; a hooking unit which hooks a system call of an object access request and obtains information of a request process and a request object of the system call; a verification information generation unit which obtains server access information from request process information of the hooked system call, and generates verification information including the server access information and information of the request object; and an object access control unit which requests access authority authentication of the user for a corresponding request object from the access authority authentication unit and controls access according to the authentication result. By controlling object access according to the object access policy assigned to the user by using the above system, even if different users own the authority of the same service account, the access authority can be controlled for each user and for each file and directory.

Description

User-based object access control system using server's hooking}

The present invention is a gateway-based access control system in which a gateway is provided between a user terminal and a server and is relayed. When accessing objects such as files and directories in the server by accessing a server with a service account of the server, an object assigned according to the user It relates to a user-based object access control system through server hooking, which controls object access according to an access policy.

In particular, the present invention provides a user authorized through a gateway through user authentication, in addition to a service account-based access restriction method, as well as a file and directory-based access control technology that exists in the server. It relates to a user-based object access control system through server hooking, which provides finely divided access control for each.

In general, government and public institutions are proposing restrictions on direct remote access of the root account, use of one person to one account, and prohibition of using account sharing as items for analyzing/evaluating technical weaknesses of major information and communication infrastructure. Due to these regulations, when accessing a device, a method of separating the access authority in units of information (IP)/protocol (port)/account of the target device is generally adopted.

However, due to technical/financial issues, there are environments in which a single account is shared and used, or unseparated and inaccurate access rights are used. Also, in the case of old security devices, there are devices that use the initial ID/password (ID/PW) of the default account or do not provide a change function.

In such a situation, since accountability cannot be secured, additional control technology is required. Accountability refers to the principle of information protection that each individual in the system must be uniquely identified. In other words, according to this principle, the information processing system can track individuals who violate information protection rules, and each individual can be held liable for his or her actions.

In addition, since the root account, which is the super administrator account, or the account used for linking with other applications, uses a single account, it is inevitable to share the account. In this situation, inevitably, the user is granted more rights than necessary. In fact, even though all users are not given proper authority, they may be relieved that a security system has been established, leading to security insensitivity.

As described above, in general, access rights are granted in units of information (IP)/protocol (port)/account of the target device. However, if the authority is granted in this way, there is a problem in that different users have the same authority when they have the same account. There are two ways to compensate for this problem.

The first option is a one-person account method. A new account is created for each user, and only the necessary authority is granted, and the authority of the created account is granted to the user [Patent Document 1]. This method is very burdensome for the security administrator, and the account needs to be created every time a new user is created, and the account's privileges must be modified every time the privileges of an existing user are changed, which can lead to inconvenient and neglected management. There is a problem that there is.

The second method is to share and use accounts, but manage and use the access history through an access control solution. In this scheme, accounts are shared and used, so users have more privileges than they need.

However, such a method cannot utilize the DAC (Discretionary Access Control) supported by Linux/Unix. DAC is a function that divides the permissions of a file or directory into accounts and groups, and controls access to read, write, and execute. Access is controlled based on the file owning account (User Identifier, UID) or file owning group (Group Identifier, GID) managed by the operating system (OS).

As a result, there is a limit to the security hole.

If both the first and second options share a root account or a similar super administrator account, malicious actions of specific users cannot be blocked in advance. This is because all users who can access the account have the same authority, so access cannot be controlled for each user.

Since the administrator account has full privileges, you can install a backdoor to bypass the security system, or lower the DAC privileges granted to files (such as /etc/shadow) or directories containing password information that no one can access. In this case, even general users can freely access the file or directory. Existing technologies are not only impossible to cope with before such a dangerous situation occurs, and it is also difficult to identify the cause when responding afterwards.

Korean Patent Registration No. 10-1565590 (Announcement on November 4, 2015)

An object of the present invention is to solve the above-described problems, in a gateway-based access control system in which a gateway is provided and relayed between a user terminal and a server. It provides a user-based object access control system through server hooking, which controls object access according to the object access policy assigned by the user when accessing the object, etc.

In addition, it is an object of the present invention to use a file and directory-based access control technology existing in a server in addition to a service account-based access restriction method to a user who is authenticated through a gateway through user authentication, It provides a user-based object access control system through server hooking, which provides finely divided access control by user authority.

In addition, it is an object of the present invention to restrict access to devices, as well as access rights to restrict files and directories even if they have account rights, according to a comparison of access rights per service account to be granted to authenticated users. This is impossible, to provide a user-based object access control system through server hooking.

In addition, an object of the present invention is to reconfirm and approve whether an object such as a file or a directory is accessed by using LSM hooking (LINUX Security Module Hooking) technology in the kernel space, through server hooking. It is to provide a user-based object access control system.

In order to achieve the above object, the present invention relates to a system installed in a server, wherein the server communicates with a user terminal through a relay of an access control gateway, and relates to a user-based object access control system through server hooking, wherein the server object An access policy management unit that stores and manages access rights information for each user as an access control policy; A connection information management unit for managing connection information including user information and server connection information as information generated when connecting from the user terminal to the server; An access right authentication unit for authenticating a user's access right to a specific object; A hooking unit for hooking a system call of an object access request and obtaining information on a request process of the system call and a request object; A verification information generation unit that obtains server access information from the hooked system call request process information, and generates verification information including the server access information and the request object information; And an object access control unit that requests authentication of a user's access right to the requested object to the access authority authentication unit, and controls access according to the authentication result.

In addition, the present invention provides a user-based object access control system through server hooking, wherein the system collects information on objects of the server and transmits the collected object information to the access control gateway. Further comprising, the access policy management unit is characterized in that receiving the access control policy set in the access control gateway, but receiving and storing only the access control policy for objects of the server to which it belongs.

In addition, in the present invention, in a user-based object access control system through server hooking, the object access control unit transmits the verification information to the access authority authentication unit, requests authentication of the user's access right to the requested object, and the The access authority authentication unit is characterized in that it searches for connection information using server access information of verification information received from the object access control unit, and obtains user information from the searched connection information.

In addition, in the present invention, in the user-based object access control system through server hooking, the access authorization unit determines that the access authorization has passed if there is no access control policy for the object, and the object has an access control policy. If it is included in the target of, it is characterized in that it is judged that the access right authentication has passed only when the access right is granted in the access control policy.

In addition, according to the present invention, in a user-based object access control system through server hooking, the server access information includes a virtual console address, or a virtual console address and a service account.

In addition, in the user-based object access control system through server hooking, the present invention is characterized in that the user authentication for the user is performed by the access control gateway and is different from a service account used when accessing the server.

In addition, the present invention is characterized in that in the user-based object access control system through server hooking, the hooking unit is hooked using LSM hooking (LINUX Security Module Hooking) technology.

In addition, the present invention in the user-based object access control system through server hooking, the access policy management unit, the connection information management unit, the access authority authentication unit is provided in the user layer of the server, the hooking unit, the verification information generation Second, the object access control unit 37 is provided in the kernel layer of the server.

As described above, according to the user-based object access control system through server hooking according to the present invention, object access is controlled according to the object access policy granted according to the user, even if different users have the same service account authority. The effect of controlling the access rights for each file and directory for each user is obtained.

Through this, even if there is a mistake in the DAC (Discretionary Access Control), which is the access rights of files and directories that are checked by the operating system (OS), the access rights can be checked once more at the very end of the kernel area. Therefore, zero trust security can be realized by performing an appropriate authentication procedure for each access.

The Zero Trust method assumes that all places are dangerous without dividing the system outside/inside separately, and without proper authentication procedures, never trust, and before granting authority to everyone who wants to access the system, the identity must be verified again. It is a concept. In particular, according to the security perspective and policy of this method, the entire system is not viewed as one large mass to be observed at once, but all parts are divided into'micro-segmentation' elements, and'granular boundary' for each element. Security should be applied in a'granular perimeter enforcement' way.

1 is a block diagram of an entire system for implementing the present invention.
Figure 2 is a block diagram of the configuration of a server according to an embodiment of the present invention.
3 is a block diagram of a configuration of a check module according to an embodiment of the present invention.
4 is a block diagram showing the configuration of a user-based object access control system through server hooking according to an embodiment of the present invention.
5 is an exemplary screen for selecting files and directories for authority control in an access control gateway according to an embodiment of the present invention.
6 is an exemplary screen for setting an access control policy for each user for files and directories in an access control gateway according to an embodiment of the present invention.
7 is an exemplary view showing connection information according to an embodiment of the present invention.
8 is an exemplary screen showing a process of finding virtual console information and service accounts according to an embodiment of the present invention.

Hereinafter, specific details for the implementation of the present invention will be described with reference to the drawings.

In addition, in describing the present invention, the same parts are denoted by the same reference numerals, and repeated explanations thereof are omitted.

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

As shown in Figure 1, the entire system for implementing the present invention controls the access of the user terminal 10, the server 40, the access control module 30 installed in the server 40, and the server 40 It consists of an access control gateway (20). In addition, the user terminal 10 and the access control gateway 20 are connected through a network (not shown).

First, the user terminal 10 is a computing terminal used by the user, such as a PC, a notebook computer, a tablet PC, a smart phone, and a phablet. In addition, the user terminal 10 has a network function capable of connecting to the server 40 or the access control gateway 20 through a network (not shown). In addition, the user terminal 10 may be installed and executed a program system such as an access control client 11 or a communication application 12.

In addition, a communication application 12 is installed in the user terminal 10, and a communication operation may be performed by accessing the server 40 through the communication application 12. The communication application 12 is a variety of terminal tools for a user to remotely access the server 40, and connects to the server 40 through a communication protocol and performs communication. Preferably, the communication application 12 is a communication program system, such as a communication program, a shell script, a communication application, etc. using a remote access protocol such as Telnet or SSH (secure shell) for accessing the server 40.

On the other hand, the communication application 12 connects to the server 40 to perform communication, but actually connects to the server 40 indirectly through the access control gateway 20. That is, the communication application 12 operates by directly communicating with the server 40 from its own standpoint. For example, the communication application 12 establishes a session with server information and protocol information (IP address and port) and accesses the server 40, but the communication packet of the communication application 12 is modulated and the access control gateway ( 20).

That the user terminal 10 accesses the server 40 is actually accessing the server 40 through the communication application 12 installed in the user terminal 10. However, in the following description, for convenience of description, the user terminal 10 or the communication application 12 will be described as accessing the server 40.

In addition, a dedicated application for bypassing the access control gateway 20, that is, an access control client 11, is installed in the user terminal 10, and when the communication application 12 approaches the server 40, the server 40 ) And the packet transmitted/received to the access control gateway 20.

In addition, the access control client 11 performs authentication (or user authentication) for access to the access control gateway 20, or information about the server 40 that the user can access, that is, server information and protocol. Accessible server information such as information (IP address, protocol port number) can be received.

On the other hand, when the user terminal 10 bypasses the packet of the communication application 12 to the access control gateway 20 for the first time, the access control gateway 20 transmits access information of the server 40 such as the destination IP address and port number. To pass on.

Next, at least one server 40 is installed. That is, a plurality of servers 40 may be installed.

Preferably, the server 40 is operated by a Unix-based operating system such as Unix or Linux.

The server 40 receives a connection request from the user terminal 10 through a network (not shown), and allows the connection according to the request to perform communication. At this time, preferably, the server 40 communicates with the user terminal 10 through a communication protocol. In particular, communication is performed through remote access protocols such as TELNET or SSH (secure shell). As an example, communication may be performed through a remote access protocol of a command-line interface (CLI) method.

In addition, the server 40 allows access to the user terminal 10 or the communication application 12 and provides a server service. Specifically, the server 40 receives a message such as a command from the user terminal 10 using a communication protocol, performs a command or request for the message, and sends the result (or result message) to the user terminal 10. send. At this time, a session is formed between the user terminal 10 and the server 40, and a connection request, message, result content, etc. are transmitted and received as data packets through a communication protocol within the session.

Meanwhile, communication between the server 40 and the user terminal 10 described above is not directly connected and processed, but is connected through the access control gateway 20. That is, the request message of the user terminal 10 is transmitted to the server 40 through the access control gateway 20, and the response message of the server 40 is also transmitted to the user terminal 10 through the access control gateway 20. Is passed on.

Meanwhile, preferably, the server 40 may have a firewall installed and set a control policy so that only data (or data packets) received from the access control gate 30 pass. Therefore, the user terminal 10 cannot directly access the server 50 and can access the server 40 only through the access control gateway 20. If the packet path is not changed to the gateway 20 and the packet is transmitted to the server 40 as it is, access to the server is blocked by a firewall policy that blocks all server access paths other than the gateway, which is an access control construction condition.

On the other hand, the server 40 performs authentication (or service authentication) using a service account and password for the user's server access, allows server access only when the service authentication passes, and provides the server service. . Service accounts are identified by ID (or service ID, access ID). In addition, the service account is authenticated by a password. Hereinafter, the password for the service account of the server 40 will be referred to as an account password.

Meanwhile, the service account refers to an account registered and managed by the server 40. Service accounts can be shared by multiple users. That is, different users can access the server 40 using the same service account.

Next, the access control gateway 20 is a gateway installed on a network (not shown) between the user terminal 10 and the server 40, and monitors and relays between the user terminal 10 and the server 40. .

That is, the access control gateway 20 relays a message (or data packet) between the user terminal 10 and the server 40 when the user terminal 10 is connected by bypassing through the access control client 11. In this case, a session (hereinafter, referred to as a server session) is formed with the server 40 and a session (hereinafter, referred to as a client session) is formed with the user terminal 10. In addition, the access control gateway 20 relays the message of the user terminal 10 to the server 40 through the formed session (client session and server session). That is, a message (or data packet) received from the user terminal 10 is received and transmitted to the server 40, and a result (or result message, data packet) is received from the server 40 to the user terminal 10. Deliver. In the following, since a message is delivered as a packet or an IP packet, a message and a packet are mixed.

At this time, the access control gateway 20 may analyze the received message, determine whether to relay/block the message, or monitor and store communication contents. That is, according to a predetermined security policy or an access control policy, a corresponding message may be transmitted to the server 40 or monitored, such as blocking, and the communication contents may be recorded and stored in a log.

In addition, the access control gateway 20 manages a user account for each user, and performs authentication (or user authentication) for the user account. That is, the access control gateway 20 relays between the servers 40 only for the user who has passed the user authentication.

For authentication or user authentication for a user account, various authentication methods such as ID/password method and biometric authentication can be applied. Also, the user account is identified by the user ID.

The user account is different from the service account described above. That is, the service account is an account registered and managed by the server 40, and the user account is an account registered and managed by the access control gateway 20. Also, the user account is an account that is uniquely assigned to each user, and the service account can be shared by multiple users.

For example, assume that user A's user account is userA, and user B's user account is userB. At this time, the user A is authenticated as a user account userA in the access control gateway 20, and may access the server 40 with a root account, which is a service account of the server. In addition, the user B is authenticated as a user account userB by the access control gateway 20, and may access the server 40 with a root account, which is a service account of the server. As a result, both users A and B can access the same root account (service account). That is, users A and B each have different user accounts, but can access the same service account.

In addition, the access control gateway 20 collects and holds connection information that is relayed when relaying between the user terminal 10 and the server 40. Connection information is composed of user ID, equipment information (server information or server address), service account, virtual console information, etc.

In addition, the access control gateway 20 collects information on objects such as files or directories of the server 40 and sets a user access control policy for the collected objects. That is, the user access control policy refers to an access policy that is set in detail for each user for each object or group of objects.

Next, the access control module 30 is a module installed in the server 40, and some functions are installed in the kernel of the operating system of the server 40, and some are installed as user-level programs of the server 40.

The access control module 30 hooks a system call requesting access to an object, and controls user access to the object. That is, the access control module 30 finds out the user who has called the corresponding system call, and determines whether the user has access rights to the object by referring to the user access control policy for the object. Depending on the judgment result, access to the object is allowed or blocked.

In addition, the access control module 30 collects objects of the server 40 in which it is installed, and transmits the collected object information to the access control gateway 20. In this case, the information may be transmitted or periodically transmitted at the request of the access control gateway 20.

In addition, the access control module 30 receives and stores user-specific access control policies for objects or groups of objects of the server 40 installed therein from the access control gateway 20.

Next, configurations of the server 40 and the access control module 30 installed in the server 40 according to an embodiment of the present invention will be described with reference to FIG. 2.

As shown in FIG. 2, an operating system (OS, 80) and an access control module 30 are installed and operated in the server 40. The access control module 30 is composed of a hooking module 30a and an access security module 30b installed in the operating system 80, and a policy check module 30c installed on the operating system 80.

First, the operating system 80 is a system program that operates a server system, and is usually referred to as a kernel layer. In general, software programs on the server (or computer) are executed as process 60 at the user layer.

In particular, the operating system 80 manages the storage medium 41 of the server system and provides a service for accessing the storage medium to the user process 60. At this time, the operating system 80 logically organizes and manages the storage medium as a file system. Therefore, objects such as files or directories are managed in the file system.

In addition, the kernel layer of the operating system 80 includes a system call open module 81 that processes system calls such as API functions, a check module 82 that checks (checks) an object of a system call request, and files/directories. It is composed of an object access driver 83 to access.

Specifically, the user process 60 calls a system call to use the resources of the file system 83 of the server system, and the operating system 80 receives (opens) a system call by the system call open module 81 Thus, it processes the request for access to the file system or storage medium. Specifically, by system calls (open(), read(), write(), etc.) provided by the operating system 80, files are opened, created, changed, and written.

In addition, the check module 82 checks an object (file/directory, etc.) requested in the system call. Specifically, an i-node check, an error check (check), and a discretionary access control (DAC) check of an object are performed.

That is, as shown in FIG. 3, the check module 82 checks an inode check unit 82a for checking an i-node for a requested object (file or directory, etc.), and an error check for checking an error. It consists of a unit 82b and a DAC check unit 82c that performs a DAC check on the requested object.

In addition, if the access to the file/directory is normal and allowed by the check module 82, the object access driver 83 controls the storage medium 41 to perform a file/directory request operation. That is, the object access driver 83 refers to information on a file system such as an i-node, accesses a file/directory stored in the storage medium 41, and performs a necessary operation.

Next, the user process 60 refers to a state in which the service program of the server is executed on the operating system. The process 60 calls an API (Application Programming Interface) function or a system call of a system dynamic library (Win32.dll, etc.) in order to use resources (file system, etc.) of the computer system.

As an example, the process 60 calls a system call such as an API function to create, open, or execute a file. Meanwhile, at this time, the process 60 transmits the path of an object such as a corresponding file/directory and process information as parameters.

Next, the access control module 30 is composed of a hooking module 30a and an access security module 30b installed in the kernel layer, and a policy check module 30c installed in the user layer.

First, the hooking module 30a is a module that hooks between system call processing modules. In particular, the hooking module 30a is implemented using a conventional LSM hooking (LINUX Security Module Hooking) technology.

In addition, the hooking module 30a is configured to hook between the check module 82 of the operating system 80 and the object access driver 83. Through this, after the object inspection (check) provided by the operating system 80 is performed, access control according to the access control policy is performed. By configuring in this way, DAC (Discretionary Access Control) control, which is an access authority for files and directories provided by the operating system 80, can be applied.

Next, the access security module 30b finds out the user (or user ID) who called the system call, generates verification information, and passes the verification information to the policy check module 30c to determine whether the user access control policy is met. Ask to check. In addition, the access security module 30b allows or blocks access to the object according to the check result of the policy check module 30c.

Next, the policy check module 30c stores and manages the user access control policy, and according to the request of the access security module 30b, the user accesses the object by referring to the user access control policy of the object. Determine whether you have authority. The determination result is returned to the access security module 30b.

In addition, the policy check module 30c collects objects of the server 40 in which it is installed, and transmits the collected object information to the access control gateway 20. In addition, the policy check module 30c receives and stores user-specific access control policies for objects or groups of objects of the server 40 installed therein from the access control gateway 20.

Next, a detailed configuration of the user-based object access control system 30 through server hooking according to an embodiment of the present invention will be described with reference to FIG. 4.

The access control system 30 according to the present invention may be implemented with the access control module described above. Hereinafter, the reference numerals of the access control system are used as the same reference numerals as the access control module.

As shown in FIG. 4, the access control system 30 according to an embodiment of the present invention includes an object information collection unit 31 that collects object information, an access policy management unit 32 that stores and manages access control policies, A connection information management unit 33 that manages information connected from the user terminal to the server, an access authority authentication unit 34 that authenticates the user's access to a given object, and a hooking unit that hooks the processing of the system call of the object access request ( 35), a verification information generation unit 36 that generates verification information, and an object access control unit 37 that requests authentication of a user's access to an object and controls access according to the authentication result.

In addition, an object information collection unit 31, an access policy management unit 32, a connection information management unit 33, and an access authority authentication unit 34 are provided in the user layer, and a hooking unit 35, a verification information generation unit 36 ), the object access control unit 37 is provided in the kernel layer.

First, the object information collection unit 31 collects objects of the server 40 on which it is installed, and transmits the collected object information to the access control gateway 20.

Collected information collects objects (or absolute paths of objects) such as files/directories existing at the top/bottom level, and i-node information of each object. Here, the object refers to a file or directory. An i-node is a unique value for files and directories, and only one exists in the filesystem and can be used to find a directory or file with that value.

The absolute path of each object (file or directory) is used for collecting information about objects (files and directories) to be restricted (controlled). In addition, the inode of each file and directory is used for the purpose of classifying each file and directory with a unique value.

Meanwhile, when transmitting object information to the access control gateway 20, the object information collection unit 31 may transmit its own server information (or equipment information) together. In addition, since the access control gateway 20 collects object information from a plurality of servers 40, it collects object information including equipment information.

Next, the access policy management unit 32 receives from the access control gateway 20 and stores the access control policy representing the access rights for each user to the objects or object groups of the server 40 in which it is installed.

At this time, the access control gateway 20 sets an access control policy by assigning rights to the collected objects for each registered user account (or user ID). That is, an administrator or the like accesses the access control gateway 20 and sets the user-specific access rights (or access control policies) for objects of each server.

The access control policy consists of equipment, objects, service accounts, and users. Additionally, it may further include access rights (or types of rights).

The device represents the server and has the server's address, that is, the server's IP address. Also, an object is a file or directory and has an absolute path as a value. Also, the service account represents a connection account when connecting to the server. A user is a user ID or user account, and is an identifier of a user authenticated at the access control gateway.

On the other hand, the permission indicates whether or not the object has access permission, and in detail, detailed permission according to the operation type such as read, write, and remove of the object can be set.

Meanwhile, the access policy management unit 32 may receive and store only information other than equipment information from among the access control policies. Since the access policy management unit 32 is a function of a module installed in a specific server, equipment is always fixed and specified. In addition, the access policy management unit 32 receives and stores only the access control policy belonging to its server (equipment) from the access control gateway 20.

As shown in FIG. 5, first, a target device (or server) to control authority is selected in units of files and directories. Select files and directories (or objects) to be restricted to the selected target device. Preferably, multiple choices are possible. As shown in FIG. 5, the set policy content is stored in the access control gateway 20.

The selected file or directory (or object) can be accessed only if you have access rights. In other words, if you do not own the access rights to the file for which the restriction setting is set, you cannot access it. Meanwhile, access to unselected objects is not restricted.

Next, as shown in FIG. 6, access rights are set for each user for objects such as files and directories. That is, the setting of which user to grant finely divided access rights to the selected object and granting access rights is performed.

For example, the first line of the access rights of FIG. 6 is the root account access rights, and the access rights to files and directories that are not restricted in FIG. 5 are granted.

In addition, the second line of the access rights of FIG. 6 is the access rights to the "root account /etc folder", and indicates the access rights corresponding to the /etc folder among the files and directories restricted in FIG. 5.

In addition, the third line of the access authority of FIG. 6 is the access authority to the "root account /etc/shadow file", and indicates the access authority corresponding to the /etc/shadow file among the files and directories restricted in FIG. 5.

Next, the connection information management unit 33 receives and stores information connected to the server 40 from the access control gateway 20.

In the access control gateway 20, when the user terminal 10 connects to the server 40 and is connected, the connection information at this time is stored. The connection information management unit 33 interworks with the access control gateway 20 to receive and manage the connection information, and particularly, preferably, updates the connection information in real time.

As shown in FIG. 7, the connection information is composed of a user, a device, a service account, and a virtual console address. In particular, the service account and/or the virtual console address is information generated when accessing the server, and will be referred to as server access information. Two or more users can access the server 40 at the same time with the same service account. At this time, the server connection can be identified by the virtual console address. Therefore, the server access information may consist of only the virtual console address.

A user is a user ID or user account, and is an identifier of a user authenticated at the access control gateway. In addition, the device represents a server and has the server's address, that is, the server's IP address. The service account represents the connection account when connecting to the server. In addition, the virtual console address is a unique identifier given to the virtual console generated by the server, such as a tty number or tty address.

Meanwhile, the connection information management unit 33 may receive and store only information other than the equipment information among the connection information. Since the connection information management unit 33 is a function of a module installed in a specific server, equipment is always fixed and specified. In addition, the connection information management unit 33 receives and stores only connection information belonging to its server (equipment) from the access control gateway 20.

For example, through the access control gateway 20, the user or the user terminal 10 attempts to log in to the granted access authority device. At this time, the access control gateway 20 stores connection information such as virtual console information (tty information) when connecting to the target device (or server 40), and transmits the connection information to the connection information management unit 33 . In other words, it stores connection information based on the user's connected device account and terminal tty.

Here, tty means the currently connected console or terminal. In general, console access is identified as tty0, tty1, and SSH terminal access is /dev/pts/0, /dev/pts/1… Is identified as such.

Next, the access right authentication unit 34 authenticates the user's access right with reference to the access control policy for the given verification information.

In other words, it searches for connection information with server access information (virtual console address, etc.) of the verification information, and searches for a user from the found connection information. In addition, the user's access right to the object of the verification information is retrieved from the access control policy, and authentication is performed based on whether the corresponding access right is allowed. If you have access rights, you have passed authentication, otherwise you are not authenticated.

First, the access authority authentication unit 34 receives verification information such as path information of an object, virtual console information, and service account. In particular, verification information is received from the object access control unit 37.

The access authority authentication unit 34 searches for connection information corresponding to the server access information (virtual console information, service account, etc.) of the verification information. Alternatively, connection information can be searched with only the virtual console information of the verification information. That is, since the virtual console address (tty address) is uniquely assigned within a specific server, connection information can be found only with the virtual console address.

At this time, the access right authentication unit 34 refers to the connection information through the connection information management unit 33.

Connection information consists of user, (equipment), and server access information. The server access information consists of a virtual console address, or a service account and a virtual console address. Accordingly, the access right authentication unit 34 may find user information (or user ID, user account) of the connection from the connection information.

In addition, the access authority authentication unit 34 searches for an access control policy corresponding to the user and object information of the verification information. If the searched policy exists and the access right is permitted in the policy, the access right authentication unit 34 determines that the access authentication has passed.

In addition, even when the access control policy for the object does not exist at all, the access right authentication unit 34 determines that the access authentication has passed. That is, if an object is not included in the object of the access control policy, access to the object is always allowed.

Therefore, preferably, before searching for user information (or connection information), it is first searched for whether there is a policy for the object in the access control policy. So, if there is no policy, authentication is passed, and if there is a policy, the process of finding user information (or connection information) is performed.

Next, the hooking unit 35 hooks the processing of the system call of the object access request.

Preferably, the hooking unit 35 installs a driver that hooks between the system call processing modules, and hooks the system call processing of the object access request. The hooking method is implemented using LSM hooking (LINUX Security Module Hooking) technology. That is, a module hook is added to the hook list so that the hooking module is recognized by the operating system's Linux Security Module (LSM).

LSM (Linux Security Module) operates in order within the modules registered in the LSM Hook list.

In particular, the hooking unit 35 hooks in a process after object inspection (check) provided by the operating system 80 is performed.

On the other hand, hooking in the hooking unit 35 is hooking the control right of a procedure for processing a system call. In addition, a system call request is a request by a specific process to access a specific object. Therefore, the specific process and specific object at this time will be called the request process and the request object, respectively.

When a system call occurs and a specific object is accessed, information about the request process and the request object can be obtained by obtaining control through the LSM hooking technique. Since access is attempted based on the request process and information on the request object, information on the request process and the request object can be obtained.

Next, the verification information generation unit 36 generates verification information.

Verification information consists of object path information and server connection information. The server access information consists of a virtual console address, or a service account and a virtual console address.

The object path information indicates the absolute path of the object such as a file or directory. In addition, the virtual console information is a virtual console address, which is a unique identifier given to a virtual console generated by the server such as a tty number or a tty address. Also, the service account represents a connection account when connecting to the server.

On the other hand, the verification information generation unit 36 is called by the hooking unit 35, and at this time, the process (or process ID) (or request process) that calls the system call and the object (file or directory) to be accessed (or request) Object).

In addition, as shown in FIG. 8, the verification information generation unit 36 may search service account and virtual console information by using the ID of the process as an identifier. In a typical operating system such as Linux, there are commands for checking the access account (service account) and virtual console information of the account through the process ID.

In addition, since the verification information generation unit 36 receives information on the object to be accessed, the absolute path of the object can be known.

Accordingly, the verification information generation unit 36 may generate verification information such as path information of an object, virtual console information, and service account by using the received process information and object information.

Next, the object access control unit 37 receives the verification information, requests authentication of the user's access to the object, and controls the access according to the authentication result.

That is, the object access control unit 37 receives the verification information from the verification information generation unit 36. As previously seen, the verification information is composed of object path information and server access information (virtual console address, or service account and virtual console address, etc.).

In addition, the object access control unit 37 transmits the verification information to the access authority authentication unit 34, and requests the determination of whether to allow or not according to the access control policy (access control authentication of the object).

In addition, the object access control unit 37 receives the authentication result from the access authority authentication unit 34, and allows or blocks the object access request of the system call according to the authentication result. That is, the object access request is allowed only when authentication passes, and the next step of the object access request is controlled.

Next, an example in which the access control system according to the present invention is performed will be described.

The first case is an example of trying to check the contents of the /etc/shadow file.

First, execute the command (vi /etc/shadow) to check the contents of the /etc/shadow file.

Next, a basic verification (check) procedure of the operating system (OS) is performed.

Next, an LSM hook is generated.

Next, the security module of the kernel layer (Kernel Space) proceeds to request the access right verification to the module (Daemon) of the user layer (User Space), and delivers the verification information together. The verification information is as follows.

{/etc/shadow, 1114, /dev/pts/0, root}

Next, check if the policy data has permission to the /etc/shadow file among the root accounts, and because you own the access right, send an Allow answer.

Next, the first situation is performed normally.

The second case is an example of trying to check the contents of the /etc/passwd file.

First, run the command (vi /etc/passwd) to check the contents of the /etc/passwd file.

Next, a basic verification (check) procedure of the operating system (OS) is performed.

Next, an LSM hook is generated.

Next, the security module of the kernel layer (Kernel Space) proceeds to request the access right verification to the module (Daemon) of the user layer (User Space), and delivers the verification information together. The verification information is as follows.

{/etc/passwd, 1113, /dev/pts/0, root}

Next, check if the policy data has permission to the /etc/passwd file among the root accounts, and send a Deny answer because there is no access right.

Next, check if the policy data has permission to the /etc/passwd file among the root accounts.

Next, the command is not executed because the command execution is not approved by the LSM hook.

Next, the situation in the second case cannot be performed due to lack of authority.

In two cases, the user owns access rights to the same account, but it is possible to realize granular access control by checking the access rights control for each file and directory in the kernel space.

Next, the effect of the present invention will be described in more detail.

The present invention is a technology that divides and manages access rights for a single account for each file and directory, and can obtain the same advantages as below.

Even if there is an omission of DAC authority due to a human error of the administrator, it not only prevents security problems in advance by re-checking the existence of file and directory access rights, but also allows the access control solution to load the history of work contents. Therefore, when a security problem occurs, it can be combined with quick response to post-processing.

On the contrary, even in an environment where clear authority separation is not possible, more than necessary authority can be granted, the effect of being able to prevent exposure (personal information or password, etc.) due to non-authority control can be obtained.

Since the file and directory access rights to be restricted are defined by default, the same level of security can be maintained even in the absence of a security officer, and even if the security officer changes, their own security method without referring or maintaining the DAC management method of the previous person in charge It can be changed easily. According to the prior art, if the DAC is changed, a permission omission may occur. Therefore, when changing, the related user and user group should be thoroughly checked and then changed.

When new equipment is added, it is only necessary to grasp the process up to now and apply the current process as it is.If changes are made afterwards, only the relevant content needs to be set, thus significantly lowering the work intensity of the person in charge and providing work efficiency and convenience have.

In addition, even if an external worker is given access to the server, the control of important files and directories is performed once more, so that it is not leaked or altered.

In conclusion, the present invention uses a file and directory-based access control technology existing in the server to an authorized user through minimal authentication through an access control gateway, and uses a finely divided access control method to zero. The trust method can be realized.

In the above, the invention made by the present inventor has been described in detail according to the above embodiment, but the invention is not limited to the above embodiment, and it goes without saying that various modifications can be made without departing from the gist of the invention.

10: user terminal 11: access control client
12: communication application 20: access control gateway
30: access control system 30a: hooking module
30b: access security module 30c: policy check module
31: object information collection unit 32: access policy management unit
33: access authority authentication unit 34: hooking unit
35: verification information generation unit 36: object access control unit
40: server 41: storage medium
80: operating system 81: system call open module
82: check module 82a: inode check unit
82b: error check unit 82c: DAC check unit
83: object access drive

Claims (8)

A system installed in a server, wherein the server communicates with a user terminal through a relay of an access control gateway, in a user-based object access control system through server hooking,
An access policy management unit for storing and managing user-specific access right information for the object of the server as an access control policy;
A connection information management unit for managing connection information including user information and server access information as information generated when connecting from the user terminal to the server;
An access right authentication unit for authenticating a user's access right to a specific object;
A hooking unit for hooking a system call of an object access request and obtaining information on a request process of the system call and a request object;
A verification information generation unit that obtains server access information from the hooked system call request process information, and generates verification information including the server access information and the request object information; And,
A user-based object access control system through server hooking, comprising: an object access control unit that requests authentication of a user's access rights to a corresponding request object to the access authority authentication unit and controls access according to an authentication result.
The method of claim 1,
The system further includes an object information collection unit for collecting information on objects of the server and transmitting the collected object information to the access control gateway,
The access policy management unit receives the access control policy set in the access control gateway, but receives and stores only access control policies for objects of a server to which it belongs.
The method of claim 1,
The object access control unit transmits the verification information to the access authority authentication unit to request the user's access authority authentication for the requested object,
The access authority authentication unit searches for connection information using server access information of the verification information received from the object access control unit, and obtains user information from the searched connection information, a user-based object access control system through server hooking. .
The method of claim 1,
If the access control policy for the object does not exist at all, the access authority authentication unit determines that the access authority authentication has passed, and if the object is included in the object of the access control policy, the access authority is authenticated only when the access control policy has access authority. User-based object access control system through server hooking, characterized in that it is determined that it has passed.
The method of claim 1,
The server access information is a user-based object access control system through a server hooking, characterized in that it includes a virtual console address, or a virtual console address and a service account.
The method of claim 1,
User authentication for the user is performed by the access control gateway, and is different from a service account used when accessing the server.
The method of claim 1,
The user-based object access control system through server hooking, characterized in that the hooking unit hooks using LSM hooking (LINUX Security Module Hooking) technology.
The method of claim 1,
The access policy management unit, the connection information management unit, and the access authority authentication unit are provided in the user layer of the server, and the hooking unit, the verification information generation unit, and the object access control unit 37 are provided in the kernel layer of the server. User-based object access control system through server hooking, characterized in that.

Images