KR102110821B1 - A rights converting system for user accounts using rights of the super account - Google Patents

Abstract

The present invention relates to a user account access switch system based on whether access to super account exists, which is installed between at least one user terminal and at least one server to relay the user terminal and the server. The user account access switch system includes: a super access management part storing account access information of a user account for the server, while enabling the user account to store information about whether access to a super account for the server exists as the account access information; a communication relay part relaying a message between the user terminal and the server; and a sudoers file update part adding a user account having super account access to a sudoers file of the corresponding server with respect to the user account in accordance with the account access information. The sudoers file is a file for registering a permission for a driving command (hereinafter referred to as ′sudo command′) as a super account, and the user terminal makes a switch from the user account accessing the server to the super account for the server by using the sudo command. Based on the system, a general account is switched to a super account by permitting a user having access to use a sudo (superuser do) command (or sudo command), thus improving issues such as compulsory password use and its exposure, nonpermitted access due to exposure, the access management of a root account and the like.

Description

A rights converting system for user accounts using rights of the super account}

The present invention provides a gateway between the user terminal and the server for relaying, but manages the authority of the super account for each user account at the gateway, and supports switching from a general user account to a super account depending on whether or not the super account has authority, The present invention relates to a system for changing the authority of a user account based on the presence or absence of access authority.

Particularly, the present invention registers a user account having super account authority in a sudu file (/ etc / sudoers file or sudoers file) that registers the usage rights of a driving command (sudo command or sudu command) as a super user, and a server It relates to a user account permission switching system based on the presence or absence of access rights of the super account, which supports switching to another account or a super account by using the Shudu command on the user account.

In general, a Unix-based operating system such as Unix or Linux is a multi-user operating system, and thus it is possible for multiple people to simultaneously use computer resources. That is, in a CLI (Command Line Interface) -based multi-user operating system such as Linux and Unix, multiple users (Client) can access and use the same operating system at the same time.

In this multi-user environment, the account of the operating system is divided into a system account and a general user account, and the account means information about objects that can access computer resources. A general user account is an account that allows users to operate files or directories owned only with the set privileges, and a system administrator means an account that can perform all tasks that can be performed on the system.

On the other hand, in a multi-user environment, the process of the general user and the system management process are separated to prevent indiscriminate system access by the general user, and through this division, the root area, which is a powerful access and management authority to the system, can be used. There is a separate super user account (or super account) with privileges. The task of getting permission to use the root area like this is called rooting.

In particular, in a multi-user operating system environment, each user accesses the operating system through a personal account (general account), which means the user's own account, to perform general operations, and execute specific commands or access files during the operation. In some cases, a super account, root, is required due to the problem of authority. On Unix-based operating systems, the super account is used as the 'root' account.

At this time, to obtain the root (root) authority, the user can change the account from the regular account to the system administrator through the su (switch user) command (or switch user command) to obtain and use all rights to the system. That is, when the command 'su-root' is input from the existing general user account, it is recognized as a command to switch to the super account and use the root area as the super user's authority.

However, the indiscriminate transition to a super user account has a problem in that it is vulnerable in terms of system security by allowing unnecessary system access in a multi-user environment.

In order to solve this, it is essential to enter a password when switching to a super user account. That is, in the process of entering a password to obtain a super user account in a multi-user environment, there is a problem in that it is possible to unintentionally expose the password to another user, and the super user account is forgotten to switch to the super user account There is a problem that the transition to the market cannot be made quickly. A technique for solving the password exposure problem has been proposed [Patent Documents 1,2].

In addition to the password exposure problem, it is recommended as a server security guide or server security check and remedy such as unnecessary account removal, root group management, and use of su command by authority, but it is still not improved and pointed out as a vulnerability.

The problems that need improvement based on the above are as follows.

First, remember to use the super account root account password to use the account. In addition, second, since super account authority is obtained through password input, physical hacking may occur through password exposure. Third, authority management for the use of the root account, the super account, is not performed. Lastly, even if you don't have access, you can connect only by knowing the password of the root account.

Korean Registered Patent No. 10-1259472 (2013.05.06.announcement) Korean Registered Patent No. 10-1195292 (announced on October 26, 2012)

The object of the present invention is to solve the problems as described above, and relays by providing a gateway between the user terminal and the server, but manages the authority of the super account for each user account at the gateway, and the presence or absence of the authority of the super account. Accordingly, it is to provide a permission switching system for a user account based on the presence or absence of access rights of a super account, which supports switching from a normal user account to a super account.

That is, an object of the present invention is to register a user account having super account authority in a sudu file (/ etc / sudoers file or sudoers file) that registers the usage rights of a driving command (sudo command or sudu command) as a super user. , To provide a system for switching authority of a user account based on the presence or absence of access authority of a super account, which supports switching to another account or a super account by using the Shudu command on the user account of the server.

In order to achieve the above object, the present invention is installed between at least one user terminal and at least one server, and relays between the user terminal and the server. As it is, to store the account authority information of the user account for the server, the account authority information, the super authority management unit for storing information about the presence or absence of super account authority of the user account, the user account; A communication relay unit relaying a message between the user terminal and the server; And, according to the account permission information, for a user account with super account authority, includes a Sure file update unit that adds a corresponding user account to the server's Sure file, wherein the Sure file is a driving command as a super account. It is a file that registers the usage rights of (hereinafter, Shudu command), and is characterized in that the user terminal switches to a super account of the corresponding server by using the Shudu command in the user account connected to the server.

In addition, the present invention, in the permission switching system of the user account based on the presence or absence of access rights of the super account, the account permission information is registered and managed only by a user account having super account rights,

The Sure file update unit adds the user account to the Sure file when a user account is registered in the account authority information, and deletes the user account to the Sure file when the user account is canceled to the account authority information. It is characterized by.

In addition, in the present invention, in the permission switching system of the user account based on the presence or absence of access rights of the super account, the Sure file update unit stores the password of the super account of the server and accesses the server with the stored password to access the Sure file. It is characterized by updating.

In addition, in the present invention, in the permission switching system of the user account based on the presence or absence of access rights of the super account, the Sure file update unit sets an option to omit the password of the user account when executing the sudo command, and the Sdu command It is characterized by setting an option to include a user switching (su) command in a command that can be executed.

In addition, the present invention is characterized in that the "sudo su -root" command is input by the user terminal in order to switch to the super account in the authority switching system of the user account based on the presence or absence of access authority of the super account.

In addition, the present invention, in the permission switching system of the user account based on the presence or absence of access rights of the super account, the server is operated in a Unix-based operating system including a Unix, Linux operating system, and a command-line interface (CLI) access protocol. It provides a remote access service.

As described above, according to the authority switching system of the user account based on the presence or absence of access rights of the super account according to the present invention, a sudo (superuser do) command (or Shudu command) is allowed to an authorized user from a general account to a super account. By switching, it is possible to improve problems such as the essential use of the password and its exposure, unauthorized access by exposure, and authority management of the root account, and through this, the effect of providing an infrastructure environment with increased security is obtained. .

1 is a configuration diagram of an entire system for carrying out the present invention.
Figure 2 is a block diagram of the configuration of the authority switching system of the user account based on the presence or absence of access rights of the super account according to an embodiment of the present invention.
3 is an exemplary view of account authority information according to an embodiment of the present invention.
4 is an exemplary diagram for switching user accounts according to an embodiment of the present invention.
5, 6, 7, and 9 are exemplary views of a Sure file according to an embodiment of the present invention.
8 and 10 are exemplary diagrams of a user's command input and result screen for switching a user account according to an embodiment of the present invention.

Hereinafter, specific contents for carrying out the present invention will be described in accordance with the drawings.

In the description of the present invention, the same parts are denoted by the same reference numerals, and repeated explanation is omitted.

First, the configuration of the entire system for carrying out the present invention will be described with reference to FIG. 1.

As shown in FIG. 1, the entire system for implementing the present invention is composed of a user terminal 10, at least one server 40, and an access control gateway 30 that controls access to the server 40. . In addition, the user terminal 10 and the access control gateway 30 are connected through a network (not shown). In addition, it may be configured to further include a manager terminal 20 used by the administrator, or a database 80 for storing data.

First, the user terminal 10 is a computing terminal used by a user, and is a PC, laptop, tablet PC, smartphone, phablet, and the like. In addition, the user terminal 10 has a network function that can connect to the server 40 or the access control gateway 30 through a network (not shown). Further, 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 can 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 accesses the server 40 through a communication protocol and performs communication. Preferably, the communication application 12 is a communication program using a remote access protocol such as Telnet (TELNET) or Secure Shell (SSH) for accessing the server 40, a program system for communication such as a shell script, a communication application, and the like.

In particular, the communication application 12 remotely accesses a Unix-based server such as Linux and Unix using CLI (Command-Line Interface) remote access protocol (TELNET, SSH). . That is, the user uses the service of the server 40 through the communication application 12, and for this purpose, enters a series of characters on the shell, that is, a command string (or string), and presses enter. By input, it is transmitted to the server 40 to perform the input command or character string. In addition, the shell installed in the user terminal 10 receives the result of the command input from the server 40, and displays the result on the screen in the form of text or string.

On the other hand, the communication application 12 connects to the server 40 to perform communication, but actually accesses the server 40 via the access control gateway 30. That is, the communication application 12 works by directly communicating with the server 40 from its 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 ( 30).

The fact 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, for convenience of description, it will be described below that the user terminal 10 or the communication application 12 accesses the server 40.

In addition, a dedicated application for bypassing the access control gateway 30 is installed in the user terminal 10, that is, the access control client 11 is installed, and when the communication application 12 accesses the server 40, the server 40 ) And the packets transmitted and received are bypassed to the access control gateway 30.

In addition, the access control client 11 performs authentication for access to the access control gateway 30, or information about the server 40 that the user can access, that is, server information and protocol information (IP address, Protocol port number), and connectable server information.

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

In addition, the access control client 11 may access the access control gateway 30 to request or receive permission registration of a super account. That is, each user may access the access control gateway 30 through the access control client 11 and request to register that his user account has the authority of the server's super account. The access control gateway 30 may check the user account at the request of the access control client 11 and register super account privileges of the corresponding user account. At this time, the super account authority may be registered under the approval of the access control client 11.

Meanwhile, as another embodiment, the access control gateway 30 registers and manages the super account authority of the user account by the administrator through the administrator terminal 20, not at the request of the user through the access control client 11 Can be.

Next, the administrator terminal 20 is a computing terminal used by the administrator, and is a PC, a laptop, a tablet PC, a smartphone, and the like. In addition, the manager terminal 20 connects to the access control gateway 30 through a network (not shown). In addition, preferably, the administrator terminal 20 may perform direct communication with the user terminal 10 or may perform communication through the access control gateway 30.

Preferably, the administrator terminal 20 responds to the approval request for the super account permission registration of the user account by determining approval or disapproval. That is, the administrator terminal 20 receives an approval request for super account registration of a specific user account of the specific server 40 from the access control gateway 30, and transmits approval or disapproval thereof to the gateway 30.

In addition, as another embodiment, the administrator terminal 20 may register super account authority information for each server of each user account in the direct access control gateway 30.

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

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

Each server 40 receives a connection request from the user terminal 10 through a network (not shown), and permits 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 a remote access protocol such as Telnet (TELNET) or Secure Shell (SSH). In addition, communication is performed through a CLI (Command-Line Interface) type remote access protocol.

Further, the server 40 receives a message such as a command from the user terminal 10 using a communication protocol, performs a command or request of the corresponding message, and transmits the result (or result message) to the user terminal 10 do. At this time, a session is formed between the user terminal 10 and the server 40, and a connection request or message, result content, etc. are transmitted and received in a data packet through a communication protocol.

Meanwhile, the 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 30. That is, the request message of the user terminal 10 is transmitted to the server 40 through the access control gateway 30, and the response message of the server 40 is also transmitted through the access control gateway 30 to the user terminal 10 Is passed on.

Meanwhile, preferably, the server 40 may set a control policy such that a firewall is installed and only data (or data packets) received from the access control gate 30 pass through. Therefore, the user terminal 10 cannot directly access the server 50 and can only access the server 40 through the access control gateway 30. If the packet path is transmitted to the server 40 without changing the packet path to the gateway 30, the server access paths other than the gateway, which is the condition for establishing access control, are blocked by the firewall policy blocking all access.

On the other hand, the server 40 performs authentication (or user authentication, service authentication) using the service account and password for the user's server access, and permits server access only when the user authentication has passed, and the service of the server Provides The service account is identified by an ID (or service ID, access ID, and user ID). In addition, the corresponding 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.

In addition, the service account is divided into a root account and a user account (or general user account). The root account is a super account that has the authority to access all system resources without restriction. The user account is a service account assigned to each user, which means a general user account. That is, the user account has relatively limited authority compared to the opened account.

In addition, the server 40 receives a connection request with a root account or a user account. In particular, the server 40 receives an access request of the root account directly from the access control gateway 30 or processes access, or receives a request for access of a user account (service account) from the bypassed user terminal 10.

Next, the access control gateway 30 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 30 relays a message (or data packet) between the user terminal 10 and the server 40 when the user terminal 10 is bypassed and connected through the access control client 11. At this time, a session (hereinafter referred to as a server session) is established between the server 40 and a session (hereinafter referred to as a client session) between the user terminal 10. Then, the access control gateway 30 relays the message of the user terminal 10 to the server 40 through the established sessions (client session and server session). That is, the message (or data packet) received from the user terminal 10 is received and transmitted to the server 40, and the result (or result message, data packet) is received from the server 40 to the user terminal 10. To deliver. Hereinafter, since the message is delivered as a packet or an IP packet, the message and the packet are mixed.

At this time, the access control gateway 30 may analyze the received message, determine whether to block commands, etc. contained in the message, or monitor and store the communication content. That is, according to a predetermined security policy or access control policy, the corresponding message may be monitored, such as transmitted or blocked, to the server 40, and communication information may be recorded and stored in a log.

In addition, the access control gateway 30 manages super account authority information (hereinafter account authority information) for the user account. The account authority information is authority information for a specific user account of a specific server, and is information about whether to have authority to use super account authority for the corresponding server.

Preferably, the access control gateway 30 registers and stores account authority information according to the request or input of the access control client 11 or the administrator terminal 20. As an embodiment, the super authority is requested from the access control client 11 and the approval or disapproval is requested by requesting the administrator terminal 20 to approve the super authority registration. Then, according to the approval of the administrator terminal 20, account authority information is generated and registered (stored). In another embodiment, the access control gateway 30 receives and registers (stores) account authority information according to the input of the administrator terminal 20.

In addition, the access control gateway 30 registers the user account in the Sure file of the server 40 according to the registered account authority information. At this time, preferably, the server 40 is accessed with a root account to perform the registration operation. To this end, the access control gateway 30 stores authentication information such as the password of the root account of each server.

The sudu file (or the sudu command registration file) is a / etc / sudoers file or sudoers file used in a Unix-based operating system, and is a file that registers usage rights of a driving command (sudo command or sudu command) as a super user. That is, if a user account is registered in the Sure file, a driving command (sudo command) as a super user can be used in the user account.

Next, the database 80 is a server information DB that stores information about each server, such as an account authority DB 81 that stores information about whether a user has super privileges, a password of the root account of each server 40, and the like. 82) and the like. However, the configuration of the database 80 is only a preferred embodiment, and in developing a specific device, it may be configured in a different structure according to a database construction theory in consideration of the ease and efficiency of access and search.

Next, a detailed configuration of the authority switching system 30 of the user account based on the presence or absence of access authority of the super account according to an embodiment of the present invention will be described with reference to FIG. 2.

The account authority conversion system 30 according to the present invention may be implemented as the access control gateway described above. Hereinafter, the reference number of the account authority conversion system is used as the same reference number as the access control gateway.

As shown in FIG. 2, the access control system 30 according to an embodiment of the present invention communicates between the super authority management unit 31, the user terminal 10 and the server 40, which manages super authority information of a user account. It consists of a communication relay unit 32 for relaying, and a shoe file update unit 33 for updating the shoe file.

First, the super authority management unit 31 manages super account authority information (or account authority information) for the user account. Preferably, the super authority management unit 31 stores account authority information in the account authority DB 81.

The account authority information is authority information for a specific user account of a specific server, and is information about whether to have authority to use super account authority for the corresponding server. Preferably, account authority information is managed by registering only user accounts that can use super account authority. Therefore, the account authority information is composed of server information and user account information. Server information is composed of IP address (IP information) and port number (protocol information), and user account information is composed of user ID.

As shown in FIG. 3, preferably, account authority information may be managed as a list of server information and user account information.

In addition, the super authority management unit 31 receives and stores account authority information in advance, or registers and stores it according to the request or input of the user terminal 10 or the administrator terminal 20. As an embodiment, a request for super authority registration from the user terminal 10 is requested, and approval or disapproval is requested by requesting approval of the request to the administrator terminal 20, and account authority information is obtained according to the approval of the administrator terminal 20 Create and register. As another embodiment, the access control gateway 30 receives and registers account authority information according to the input of the administrator terminal 20.

Meanwhile, the super authority management unit 31 may receive a request for granting or canceling the super authority of the user account. When receiving a grant request, account authority information is created and added, and upon cancellation request, the account authority information is deleted.

Next, the communication relay unit 32 relays a message (or data packet) between the user terminal 10 and the server 40, or relays a message between the Sure file update unit 33 and the server 40. can do.

That is, the communication relay unit 32 receives the message from the user terminal 10 and delivers it to the server 40, and receives the result message or the like from the server 40 and delivers it to the user terminal 10.

Preferably, the communication relay unit 32 establishes a session for the client with the user terminal 10, and transmits and receives data (such as a message) through the established client session. In addition, the communication relay unit 32 forms a server session corresponding to the client session with the server 40. That is, the client session and the server session are sessions for relaying between the user terminal 10 and the server 40.

In addition, the communication relay unit 32 relays the message between the Sure file update unit 33 and the server 40. To this end, the communication relay unit 32 establishes a session between the server 40 and transmits and receives data or messages through the established session. At this time, through the established session, the server 40 is connected to the root account, and the pseudo file located on the server is updated.

Next, the shoe file update unit 33 updates the shoe file of the server 40 according to the registered account authority information.

First, the Sure file update unit 33 establishes a session with the server 40 through the communication relay unit 32. It connects to the server 40 through the established session and performs work.

Specifically, the shoe file update unit 33 accesses the server 40 with a root account, and updates the shoe file located on the server 40. In other words, the user account registered in the account permission information is added to the file, or the user account canceled in the account permission information is deleted from the file.

On the other hand, preferably, the Sure file update unit 33 stores authentication information such as a password of the root account of each server in order to access the root account of the server 40. The root account information of each server is stored in advance.

In addition, the sudu file is an / etc / sudoers file or sudoers file used in a Unix-based operating system, and is a file that registers permission to use a driving command (sudo command or sudu command) as a super user. That is, if a user account is registered in the Sure file, a driving command (sudo command) as a super user can be used in the user account.

Preferably, the pseudo file update unit 33 sets an option to omit the password of the user account when executing the sudo command.

Also, preferably, when the pseudo file update unit 33 executes a sudo command, an option is set to include a user switching (su) command in a command that can be executed by the sudu command.

Next, a switch user (su) command, a sudo command, and a sudo file used in the present invention will be described in more detail. All of the above commands are used in Unix-based operating systems.

First, the user switch (su) command is a command to switch from the current user account to another user account (or a user account to be switched). In the example of FIG. 4, the current user account userA can be switched to the user account userB by using the su command.

The su command is entered in the following format.

su-[user account]

At this time, when the su command is entered and executed, the password of the user account to be switched is requested. Therefore, it is necessary to additionally enter the password of the user account to be converted to switch to the user account.

For example, in the example of FIG. 4 above, in the account userA state, "su-userB" is input, and if a password input is requested, the password of the user account userB is input. This switches to the user account userB. For reference, if you log out of the user account userB, you are returned to the user account userA.

According to the prior art, in order to increase the account authority, the su command is used to switch from the normal user account to the root account root. That is, without logging out from the primary user account (normal user account), the root account is switched to the root account through the su command, and the operation is performed with the root account. Therefore, each user performing the account elevation must know the password of the root account root.

Next, the sudo (sudo, superuser do) command is a command that executes the corresponding command as a super user (or root account).

The sudo command is entered in the following format.

sudo [command]

Also, when the sudo command is entered, the password of the user account is inquired by default. This is for user authentication for security.

For example, in the user account userA state, entering the "sudo shutdown" command prompts for the password of the user account userA, and entering the password for userA executes the "shutdown" command with root account (or superuser) privileges. . Therefore, even if the user account userA does not have the authority to use the "shutdown" command, the corresponding command is executed because the root account has the appropriate authority.

On the other hand, the password input may be omitted according to the option setting of the Sure file. In this case, the sudo command is executed immediately without entering a password.

In addition, the sudo command can borrow the authority to use the sudo command according to the account and format specified (registered) in the / etc / sudoers file that exists on each server. That is, the sudo command is allowed only within the range registered (specified) in the Sure file.

Next, the sudo (sudoers, / etc / sudoers) file is a system file located on the server, and is a file that registers the permission and scope of the sudu command. That is, if a user account is registered in the Sdu file, the Sudo command can be used in the user account.

In addition, the Sure file is saved as a "/ etc / sudoers" file that exists for each server. In addition, the contents of the Sure file can be updated only by super user authority or root account.

Fig. 5 illustrates a Shudu file (or sudoers file). In FIG. 5, the red dotted box part is a part in which a user account capable of using the Shoo command is registered.

ohso localhost = (root) NOPASSWD: / usr / bin / su

netandA localhost = (root) NOPASSWD: / usr / bin / su

The format for registering a user account is as follows.

[User Account] [Host] = ([Permission Account]) (NOPASSWD:) [Command]

Here, [user account] denotes a user account that can use the sudo command, and [permission account] is a privilege account that is granted when executing the sudo command, and usually uses a root account. In addition, [command] indicates a command that can be executed as a sudo command. [Host] refers to the server and is usually used as localhost. The "NOPASSWD" option is an option to omit entering the password of the user account.

Thus, in the example of FIG. 5, the usage rights of the sudo command are registered for the user accounts osho and netandA. When the sudo command is executed, it is executed with root authority and without password input. Also, it can be seen that the commands that can be executed with the sudo command are limited to the su command (/ usr / bin / su).

In other words, the specified account, ohso or netandA, uses the sudo command to borrow and use root authority, and only the su (/ usr / bin / su) command can be used. Also, the nopassword policy means that the su command can be used without requiring a password. Therefore, without entering the password of the primary account ohso or netandA, it is possible to borrow and use the privileges of root. There will be.

Therefore, the present invention, unlike the prior art, is a method of elevating privileges using the super account root authority through a sudo (superuser do) command.

Next, a method for switching the authority by the authority switching system of the user account based on the presence or absence of access authority of the super account according to an embodiment of the present invention will be described with reference to FIGS. 5 to 10.

The user or user terminal 10 who wants to access the server 40 logs in with a personal account (normal user account) only for the authority authorized by the access control gateway 30 to proceed with the operation on the server. In the process, to gain system-wide privileges, use the sudo su-root command to switch to the root account (ie borrow and use the root account).

At this time, not all user accounts can be switched to the root account. Only when the authority of the root account has been granted by the access control gateway 30, the gateway 30 processes the operation of registering the user account in the / etc / sudoers file of the server in advance. Therefore, it is possible to borrow a root account differently for each user based on the access rights granted.

First, it is illustrated with reference to FIG. 5.

User A is granted the authority (account authority information) of a personal account called netandA and a root account of one server from the access control gateway 30.

As shown in Fig. 5, the access control gateway 30 sets the / etc / sudoers file of the corresponding server. That is, the netandA account is set to borrow and use the root account. The setting of the corresponding Sure file checks the account permission information managed by the access control gateway 30, and if the super account (root account) has access rights, registers the user account in the / etc / sudoers file (specified). do.

In addition, the following is added to line 94 of FIG. 5.

netandA localhost = (root) NOPASSWD: / usr / bin / su

Therefore, the user of the netandA account can switch from the netandA account status to the root account by using the sudo su-root command. That is, you can borrow and use the root authority normally in the netandA account state.

Next, it is illustrated with reference to FIG. 6.

User B 10 has been granted the authority of the personal account netandB of one server 40 from the access control gateway 30, and there is no authority of the root. At this time, as shown in FIG. 6, in the / etc / sudoers file of the server, the netandB account is not set to borrow and use the root account.

 For reference, when granting and removing access rights, the access control gateway 30 deletes the contents of the permissions registered in the / etc / sudoers file, so that the sudo command cannot be used.

When user B uses the netandB account and enters the sudo su-root command, he cannot switch to the root account because the sudo command is not set. That is, you will receive a message like "netandB is not in the sudoers configuration file." Therefore, you can confirm that it cannot be used by borrowing the authority of the root account.

Next, an example with reference to FIGS. 7 to 10 will be described.

User NETAND is a user who uses a regular user account called netand. There are cases when this user needs to use root authority to access a specific file. At this time, in order to access as root, the authority of the root is borrowed through the sudo command, and the privilege is raised to perform the operation.

User NETAND logs in with a regular account called netand, and attempts to elevate privileges through the command sudo su-root.

At this time, if the sudo command is used, the user's NETAND in the system's / etc / sudoers file checks whether the user can access the root account. In this case, it is divided into two cases: when there is no root authority and when there is no root authority.

First, the case where root authority is not described will be described.

Since there is no access right granted through the access control gateway 30, there is no work done by the access control gateway in the / etc / sudoers file. Therefore, as in the example of FIG. 7, there is no netand account in the sudoers file.

As shown in Fig. 8, in this state, when the user NETAND tries to access the root account by entering the sudo su-root command, a message such as "netand is not in the sudoers configuration file" is displayed. Receive. In other words, there is no netand account in the sudoers configuration file, so it cannot be elevated with root privileges.

Next, a description will be given of the case where the root authority is provided.

Since access authority is granted through the access control gateway 30, the access control gateway 30 automatically grants permission and adds the netand account to the / etc / sudoers file. Therefore, as shown in FIG. 9, when the / etc / sudoers file is checked, a netand account is registered.

As shown in FIG. 10, when a user attempts to elevate root authority by using the sudo command with the primary account netand account, the account specified in the / etc / sudoers file is the netand account when the sudo command is used, NOPASSWORD Due to the policy, the elevation is normally performed as root without asking for the password of the netand account.

In addition, when access rights are granted and used through the access control gateway, and the access rights are removed, the access control gateway automatically deletes the primary account (general account) entered in the / etc / sudoers file to retrieve the access rights. can do. By returning to the unreachable environment as described above, since the connection setting of the root account is not established, it is impossible to obtain the root account authority.

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

According to the prior art, in order to obtain root authority, a user is switched from a general account to a system administrator through a switch user (SU) command to obtain and use all rights to the system. However, this approach is pointed out as a system security vulnerability because it cannot control unnecessary system access in a multi-user operating system environment.

On the other hand, the present invention is limited to authorized users, so that the root account is obtained by switching from a general account to a super account through a sudo (Superuser do) command. By adopting this method, the present invention can improve the problems described above and work in an infrastructure environment with increased security.

The specific improvements are as follows.

First, according to the NOPASSWD policy written in the / etc / sudoers file, there is no need to remember the password of the root account, the super account.

Next, as the password input is eliminated, the risk of password exposure is not only eliminated, but the occurrence of an environment where physical hacking can occur is blocked.

Next, it is operated to allow the use of the super account, the root account, through the access control system, so it is managed for the authority and can be automatically operated through the solution without manual intervention. In addition, the history is recorded, and can be easily used for the post-history audit.

Next, if you know the password of the root account to use the Switch User (SU) command, you can connect to the root account regardless of the access authority. On the other hand, the present invention operates to allow the use of the super account, the root account, through the access control system, so even if the password of the root account is known, it cannot be accessed. Therefore, the present invention can block the secure hole that may be generated through the SU command.

Finally, by setting the sudo command's authority for each command, you can further enhance security by limiting the function to borrow and use the authority of the super user only as the su command.

Above, although the invention made by the present inventors has been specifically described according to the above-described embodiments, the present invention is not limited to the above-described embodiments, and it is needless to say that various modifications can be made without departing from the gist thereof.

10: user terminal 20: administrator terminal
30: access control gateway 31: super authority management department
32: Communication relay unit 33: Sure file update unit
40: server 80: database
81: account authority DB 82: server information DB

Claims (6)

In the system for switching between at least one user terminal and at least one server, relaying between the user terminal and the server, the authority account switching system based on the presence or absence of access authority of the super account,
A super permission management unit that stores account permission information of a user account for the server, and stores, as the account permission information, information about the presence or absence of super account permission of the server;
A communication relay unit relaying a message between the user terminal and the server; And,
According to the account authority information, for a user account having super account authority, a scheduling file update unit for adding the user account to the server's scheduling file is included,
The Shudu file is a file that registers usage rights of a driving command (hereinafter, Shudu command) as a super account,
From the user account that the user terminal accesses the server, switch to the super account of the server by using the Shudu command,
The Sure file update unit stores the password of the super account of the server, and accesses the server with the stored password to update the Sure file.
According to claim 1,
The account permission information is managed by registering only a user account having super account permission,
The Sure file update unit adds the user account to the Sure file when a user account is registered in the account authority information, and deletes the user account to the Sure file when the user account is canceled to the account authority information. Characteristic of a super account access authority based user account authority switching system.
delete According to claim 1,
The Shudu file update unit sets an option to omit the password of the user account when executing the Sudo command, and sets an option to include a user switch (su) command in the command that can be executed by the Shudu command. Characteristic of a super account access authority based user account authority switching system.
According to claim 1,
In order to switch to the super account, the "sudo su-root" command is inputted by the user terminal.
According to claim 1,
The server is operated on a Unix-based operating system including Unix and Linux operating systems, and provides a remote access service using a command-line interface (CLI) access protocol. Authority switching system.

Images