KR102118380B1 - An access control system of controlling server jobs by users - Google Patents

Abstract

The present invention relates to an access control system with a function of controlling a server job for each user which is installed between at least one user terminal and at least one server to relay between the user terminal and the server. The access control system comprises: a job environment setting unit to select commands to be used by a user of the user terminal, and generate shellcode for a user to process only selected command (hereafter, dedicated commands); a communication relay unit to relay a message between the user terminal and the server; and an authentication processing unit to set a session (hereafter, the session for a server) with the server and a session (hereafter, the session for a client) with the user terminal, and set the session for a server after registering the shellcode for a user in the server. A command is selected only in a preregistered command set to be performed by the system to block a command other than registered commands to make command bypassing impossible.

Description

Access control system with server job control function for each user {An access control system of controlling server jobs by users}

The present invention provides a gateway with a gateway between the user terminal and the server, but registers commands to be used in advance by the user and restricts the server to perform server tasks only within the registered commands. It's about the control system.

In particular, according to the present invention, when a user registers a command set, a user-only shell code having a command selection and execution function in the set list is generated, and the user-specific shell code is registered in a corresponding server, so that a user task is applicable. It relates to an access control system equipped with a user-specific server task control function to be processed by a server shell.

In general, the command control technology of the server access control system analyzes packets passing through the access control gateway server, extracts the command entered by the user, and lists the prohibited commands that can be a threat to the security applied to the user. By comparison, if it is in the list, the corresponding command is discarded without being sent to the server. Through this, it is a technology to enhance security for the server [Patent Documents 1,2].

Specifically, the server access control system accumulates command characters input by the user at the gateway. Then, when the user presses the Enter key to execute the command, the access control system compares the list of prohibited commands applied to the user and the accumulated command string to determine whether or not it is authorized. And if some of the entered command strings are included in the forbidden command list, the command (or string) is blocked.

In particular, the current agentless access control security solutions are a part of the critical threat to the server (file deletion, server shutdown/restart, bypass, to reduce security incidents due to human error on users accessing the server) Connection) It is managed in the form of prohibited commands only for work. However, in the agentless method, the forbidden command compares based on the string entered by the user, so if you abuse it, you can bypass the entered string comparison method.

In addition, in order to increase the accuracy of whether or not the user inputs the command, the forbidden command that can be a threat to security is registered in the form of a regular expression. Therefore, it detects the case where the command text entered by the user is included as a certain rule, and supports more accurate detection.

However, there are many different ways for users to enter commands on the server. Therefore, the access control system according to the prior art cannot accurately process the identification and authorization of commands input in various formats even with the detection technology using the regular expression.

For example, you can bypass:

First, you can combine commands by replacing strings with variables. That is, when the reboot command is set as a prohibition command, the string is replaced with the variable in the form of A="re", B="boot", and A and B strings are combined. If you combine A and B strings like this, you can execute the reboot command.

As another example, the vi command can bypass the forbidden command.

That is, you can create and execute a forbidden command by using the commands available in a shell script.

In addition, when the "ls /usr/sbin/" command is entered, a file containing the strings r, e, b, o, o, and t exists in the searched result, and the string called reboot is obtained by parsing the string in the search result. Can be. You can bypass it by running the string thus obtained.

As described above, in the case of an environment in which an operator accessing a server can input a command, there are various ways to bypass the forbidden command list, so it is almost impossible to actually control the working environment of the worker.

Therefore, it can be a serious security issue.

Korean Registered Patent No. 10-1475981 (announced on December 23, 2014) Korean Registered Patent No. 10-1780764 (Announcement on September 22, 2017)

The object of the present invention is to solve the problems as described above, the relay is provided with a gateway between the user terminal and the server, but the command to be used in advance by the user is registered, and to perform the server operation only within the registered command It is to provide an access control system equipped with a limiting, user-specific server task control function.

That is, the object of the present invention is that when a user registers a command set, a user-only shell code having a command selection and execution function in the corresponding set list is generated, and the user-specific shell code is registered in the server to perform a user operation. It is to provide an access control system equipped with a server task control function for each user to be processed by the corresponding server shell.

In order to achieve the above object, the present invention relates to an access control system equipped with a server task control function for each user, which is installed between at least one user terminal and at least one server, and relays between the user terminal and the server. , A working environment setting unit that selects commands to be used by a user of the user terminal and generates a user-specific shell code to process only the selected commands (hereafter, dedicated commands); A communication relay unit relaying a message between the user terminal and the server; And an authentication processing unit for establishing a session with the server (hereinafter referred to as a server session) and a session with the user terminal (hereinafter referred to as a client session), but registering the user-only shell code with the server and establishing the server session. It is characterized by including.

In addition, in the present invention, in the access control system equipped with a server task control function for each user, the task environment setting unit defines a plurality of tasks, sets commands necessary for the task into a command list, and works by the user Is selected, it characterized in that the command of the command list corresponding to the selected task is selected as the dedicated command.

In addition, in the present invention, in the access control system equipped with a server task control function for each user, the user-only shell code displays the dedicated command as a list and selects one dedicated command from the list of the dedicated commands, It is characterized in that it is executable code that executes the selected dedicated instruction.

In addition, in the present invention, in the access control system equipped with a server task control function for each user, the authentication processing unit sets the session for the server to a session using a secure shell (SSH) protocol (hereinafter referred to as an SSH session). Create a public key and private key pair, access the server with the access information of the root account, register the public key of the SSH authentication key to the server, copy the executable file of the user-only shell code to the server, , Registering the path of the executable file to the server.

In addition, in the present invention, in the access control system equipped with a server task control function for each user, the authentication processing unit accesses the root account and registers the public key of the SSH authentication key with the server, and then accesses the server with a user account. , Using the registered public key to perform user authentication of the user account.

In addition, the present invention is characterized in that in the access control system equipped with a server job control function for each user, the authentication processing unit initializes by deleting the user-only shell code registered in the server when the server job is finished.

As described above, according to the access control system equipped with a server task control function for each user according to the present invention, by selecting and executing a command only within a pre-registered command set, commands other than the registered commands are blocked by default. An effect is obtained that can disable command bypass. This can fundamentally block the possibility of human error.

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 an access control system equipped with a server operation control function for each user according to an embodiment of the present invention.
3 is a flowchart illustrating a server access method by an access control system equipped with a server task control function for each user according to an embodiment of the present invention.
4 is an exemplary table showing allowable command list information for each job according to an embodiment of the present invention.
5 is an exemplary table showing available programming type information for each server according to an embodiment of the present invention.
Figure 6 is an exemplary view of a user-only shell code converted to a shell script according to an embodiment of the present invention.
7 is an exemplary view of a user-only shell code converted to Python according to an embodiment of the present invention.
8 is an exemplary view of a public key and a private key of an SSH authentication key according to an embodiment of the present invention.
9 is an exemplary view showing a public key value added to an authentication file according to an embodiment of the present invention.
10 is an exemplary view showing an execution file parameter added to an authentication file according to an embodiment of the present invention.
11 is an example screen for a user-only shell 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). In addition, the user terminal 10 may be executed by installing a program system such as an application.

In addition, a communication application (not shown) is installed in the user terminal 10, and a communication operation may be performed by accessing the server 40 through the communication application. A communication application (not shown) 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 is a communication system using a secure shell (SSH) protocol for accessing the server 40, a shell script, a communication application program system, and the like.

On the other hand, the communication application connects to the server 40 to perform communication, but actually accesses the server 40 by way of the access control gateway 30. That is, the communication application works by directly communicating with the server 40 from its standpoint. For example, the communication application 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 is modulated and bypassed to the access control gateway 30.

The fact that the user terminal 10 approaches the server 40 is actually accessing the server 40 through a communication application installed in the user terminal 10. However, for convenience of description, it will be described below that the user terminal 10 accesses the server.

In addition, a dedicated application (or an access control client, etc.) for bypassing the access control gateway 30 is installed in the user terminal 10, and commands to be used when a communication application accesses the server 40 are registered or the server ( 40) packets transmitted and received are bypassed to the access control gateway 30.

That is, the user terminal 10 selects and registers commands to be used when accessing the server 40 by accessing the access control gateway 30 through the access control client, before bypassing the packet of the communication application. At this time, the user terminal 10 receives a list of commands available from the server 40 to be accessed from the access control gateway 30, and the command list (or command set) selected by the user as the access control gateway 30 Register by passing.

In addition, the user terminal 10 performs the authentication processing unit 33 for access to the access control gateway 30 or receives information about the server 40 that the user can access (or connectable server information). Accessible server information consists of a list of server information and protocol information (IP address, protocol port number), etc. For example, {192.168.0.1:23, 192.168.2.1:23, ... }, etc. IP address means the server's IP address, and port number contains the protocol.

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

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 selected command set (or command list) by determining approval or disapproval. That is, the administrator terminal 20 receives an approval request for the set of commands to be used when accessing the specific server 40 from the access control gateway 30, and transmits approval or disapproval of the request to the gateway 30.

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

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 an SSH communication protocol.

In addition, the server 40 is accessed from the access control gateway 30, receives a change request (or registration request) for the public key of the SSH authentication key, and updates (or registers) the public key of the corresponding access account.

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 ID (or user ID, access ID, service 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 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, processes access, and 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. . To this end, the access control gateway 30 manages an SSH authentication key for each user (or for each user ID) and manages authorized server access information (authorized access information).

In addition, the access control gateway 30 generates or updates the SSH authentication key for each user (or user ID) and stores it. That is, a key pair of the SSH authentication key is generated, the public key is transmitted to the server 40 according to the access information, and the public key and the private key are stored in the authentication key DB 82. In addition, the authentication key DB 82 stores an SSH authentication key (or a private key of the SSH authentication key) for each user, and preferably, manages a plurality of SSH authentication keys as a list.

The SSH authentication key pair is two asymmetric encryption keys, which can be used by the SSH server to authenticate the client. Each key pair consists of a public key and a private key. Hereinafter, the SSH authentication key in a broad sense will be described as a concept including both an SSH key pair, that is, a public key and a private key, and the SSH authentication key in a narrow sense will be described as meaning a private key. That is, the SSH authentication key uses a key for SSH authentication and the meaning of a private key.

Meanwhile, the private key described above is used as an SSH authentication key held by the client in the SSH protocol. The message can be encrypted with the public key, and the encrypted message can be interpreted only as a paired private key. This feature is used in authentication schemes using asymmetric key pairs. For example, when a client requests an SSH connection to the server, the server creates a random challenge (random data string) and sends it to the client, the client encrypts the random challenger with the SSH authentication key's private key, and sends it to the server, and the server encrypts SSH authentication is performed by interpreting the message as a public key and checking if it matches the random challenge sent by the user.

The public key is uploaded to the remote server 40 that wants to log in using the SSH protocol. The public key uploaded to the server is stored in the user account. As an example, the public key is added to the user account's authentication information file (eg ~/.ssh/authorized_keys file).

In addition, if the client attempts to authenticate using an SSH authentication key, the server can test whether the client has a private key. When it is proved that the client has a private key, a shell session is created or the requested command is executed.

Meanwhile, in the user account authentication information file (~/.ssh/authorized_keys, etc.), a shell command to be executed when SSH authentication is successful can be registered. The access control gateway 30 copies the customized shellcode (or user-only shellcode) or shellcode file to each user account to the user account, and registers the corresponding shellcode file information (file name, etc.) in the authentication information file. . In this case, when the SSH authentication is successful for the client, the server 40 executes a dedicated shell code file registered in the corresponding authentication information file. That is, when the SSH authentication passes, the client receives a shell service based on the registered dedicated shell code.

In addition, the access control gateway 30 receives and manages the authorized access information 83 for the server 40 in advance. The authorization access information 83 is composed of server information (IP address), protocol (port number), access account (access account ID), and SSH authentication key information. In addition, the authorized access information may be managed as a list of a plurality of access information.

In addition, the access control gateway 30 updates the SSH authentication key according to a specific event or session setting. That is, the access control gateway 30 generates a new SSH authentication key. Then, the server 40 is accessed using the SSH authentication key stored in the authentication key DB 82 and the connection information stored in the authorized access information 82, and the public key of the newly generated SSH authentication key is transmitted to the server 40. Then, the corresponding SSH authentication key of the authentication key DB 82 is updated with the newly generated SSH authentication key.

In addition, 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 20.

At this time, the access control gateway 30 uses the SSH authentication key stored in the authentication key DB 82 to form an SSH session (hereinafter, a server session) with the server 40. In addition, the access control gateway 30 forms a session (hereinafter, a client session) with the user terminal 10. At this time, the client session can form a session without performing user authentication using an SSH authentication key.

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 client session is a session for data transmission and reception (or message transmission and reception) between the user terminal 10 and the access control gateway 30, and may be formed in its own encryption session. Send and receive messages between the communication application and the server within the encryption session.

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 sets the user's working environment, such as selecting a command to be used by the user or generating a user-specific shell code to use only the selected commands.

That is, the access control gateway 30 provides the user terminal 10 with all of the commands allowed from the server 40 to be accessed, and allows the user or the user terminal 10 to select a command to be used from among the entire commands provided. .

In addition, the access control gateway 30 generates user-only shell codes that allow only selected commands to be used. The user-specific shell code displays the selected command as a list, selects one command from the command list, and executes the selected command. Also, the user-only shell code includes a termination command, and is written to terminate the connection to the server itself when the termination command is selected.

In addition, the access control gateway 30 registers the user-only shell code to the server 40 when the user terminal 10 accesses the server 40. The user-specific shell code is the previously generated shell code, and is a shell code for executing only selected commands. Through this, the user terminal 10 receives the shell service by the registered user-only shell code, and terminates the server access service itself when it is terminated on the corresponding shell service. Therefore, the user terminal 10 can execute only selected commands by the user-specific shell code.

Next, the database 80 includes a shellcode DB 81 that stores user-specific server shell codes, an authentication key DB 82 that stores SSH authentication keys for the server 40 and the SSH protocol, and each user can access It consists of an authorized access DB (83) for storing server equipment information. 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 access control system 30 equipped with a server operation control function for each user according to an embodiment of the present invention will be described with reference to FIG. 2.

The access control system 30 according to the present invention may be implemented as the access control gateway described above. Hereinafter, reference numerals of the access control system are used as the same reference numerals 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 a work environment setting unit 31, a user terminal 10, and a server 40 for setting a work environment of a user. It consists of a communication relay unit 32 for relaying, and an authentication processing unit 33 for performing SSH authentication.

First, the work environment setting unit 31 sets a user's work environment, such as selecting a command to be used by a user or generating a user-specific shell code that allows only selected commands (hereinafter, a dedicated command) to be used.

That is, the work environment setting unit 31 provides all the commands allowed by the server 40 to be accessed to the user terminal 10, and receives a list of commands selected from the user terminal 10.

Preferably, the work environment setting unit 31 may define a plurality of types of tasks, and group commands necessary for the corresponding task to be set as a command list. That is, if a task type is selected without directly selecting a command, a command list (or a dedicated command list) required for the corresponding task can be automatically selected.

In addition, the work environment setting unit 31 generates a user-only shell code to use only selected commands (or dedicated commands). The user-specific shell code displays the selected command (or dedicated command) as a list, selects one command from the command list, and executes the selected command. Also, the user-only shell code includes a termination command, and is written to terminate the connection to the server itself when the termination command is selected.

Preferably, the user-only shell code is a module written in a programming language such as shell script, java, or C++. User-specific shell code files are executable files that execute the code. Code that needs to be compiled is a file that has been compiled and converted into an executable file.

Next, the communication relay unit 32 relays a message (or data packet) between the user terminal 10 and the server 40, and when the user terminal 10 accesses the server 40 (that is, with the server) When establishing a session), it is controlled to establish an SSH session with the server 40 through the authentication processing unit 33.

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 (hereinafter, a client session) with the user terminal 10, and transmits and receives data (message, etc.) through the established client session. In particular, the communication relay unit 32 may establish an encryption session (or a session for a client) using the SSH protocol, or establish a client session according to the encryption protocol itself.

In addition, the communication relay unit 32 forms a session (hereinafter, a server session) corresponding to a session (or a client session) formed with the user terminal 10 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 particular, the communication relay unit 32 establishes an encrypted session (or SSH session, a server session) using the SSH protocol.

At this time, the communication relay unit 32 establishes a client session and a server session under the control of the authentication processing unit 33. That is, when the communication relay unit 32 receives a message (or packet) related to session establishment, it transmits it to the authentication processing unit 33, receives the session establishment and related message from the authentication processing unit 33, and then receives the user terminal 10. Or transmit to the server 40.

Specifically, the communication relay unit 32 receives the message of the connection request (or session establishment request) from the user terminal 10, and transmits it to the authentication processing unit 33. The communication relay unit 32 filters the relayed message and, in the case of a connection request message (or session establishment message), transmits it to the authentication processing unit 33.

In addition, the communication relay unit 32 performs the connection process of the server 40 or the relay of the session establishment process with the authentication processing unit 33. That is, mutual messages in the process of establishing a server session are transferred between the authentication processing unit 33 and the server 40, and the communication relay unit 32 relays them. When the server session is set up, the authentication processing unit 33 establishes a client session by transmitting a response message to the session setting request to the user terminal 10 through the communication relay unit 32 according to the result.

At this time, the communication relay unit 32 may store the SSH authentication key in advance, and use the stored SSH authentication key to form an SSH session with the server 40 as a server session. That is, it is possible to enhance security by using a different SSH authentication key from the client session.

Next, the authentication processing unit 33 establishes a server session with the server 40, and a client session with the user terminal 10, but sets the server session as an SSH session using an SSH authentication key, and the user only The shell code file is registered in the server 40.

That is, the authentication processing unit 33 generates an SSH authentication key each time each session is established, connects to the root account, copies the SSH authentication key (or public key) to the server 40, or user-only shell code. Register the executable file of the server 40.

In addition, the authentication processing unit 33 stores the access information (password or SSH KEY) of the root account of all accessible servers in advance, accesses the server 40 using the access information of the root account, and accesses each user Sets the working environment of the account.

In addition, when the user terminal 10 accesses the server 40, the authentication processing unit 33 registers a user-only shell code in the server 40. The user-specific shell code is the previously generated shell code, and is a shell code for executing only selected commands. Through this, the user terminal 10 receives the shell service by the registered user-only shell code, and terminates the server access service itself when it is terminated on the corresponding shell service. Therefore, the user terminal 10 can execute only selected commands by the user-specific shell code.

On the other hand, the authentication processing unit 33 accesses the server 40 with the access information (root password, etc.) of the root account, registers the SSH public key of the user account to the server 40, and executes the executable file of the user-specific shell code. Copy to the server 40, and register the path of the executable file to the server 40. Then, when the authentication processing unit 33 accesses the server 40 using a user account, user authentication is performed using the registered SSH authentication key.

Next, a server access method by an access control system equipped with a server task control function for each user according to an embodiment of the present invention will be described with reference to FIG. 3.

As shown in FIG. 3, first, the access control gateway 30 or the work environment setting unit 31 pre-stores a list of all commands allowed for each server, and access information (password or SSH key) of each server in advance. (S10).

Preferably, the work environment setting unit 31 may define a plurality of types of tasks, and group commands necessary for the corresponding task to be set as a command list. That is, if a task type is selected without directly selecting a command, a list of commands required for the corresponding task can be automatically selected. For example, as shown in FIG. 4, the work environment setting unit 31 can predefine information on a permissible type of work for each server and a list of commands required for the corresponding work (hereinafter, command list information for each work). have.

In addition, as shown in FIG. 5, the work environment setting unit 31 pre-stores programming type information available for each server. For each server, it is a type of programming recognized by the server and refers to programming that can interpret shell codes for users. Therefore, user-specific shell code must be written using the programming language recognized by the server.

Next, the user or the user terminal 10 requests (selects) the target server and service account (or access account) to access, and selects a command list to be used when accessing the server (S20). Preferably, a command list is selected by selecting a task type.

For example, in the example of FIGS. 4 and 5, the user or the user terminal 10 selects the connection target server "1.1.1.1", and selects the access target account "User A". And when connecting to the server, the command list is selected by selecting the type of work to be performed on the server. That is, by selecting the operation "1. Server resource monitoring", the corresponding three command lists "cat /prco/cpuinfo", "cat /proc/meminfo", and "fdisk -l" are selected.

That is, the work environment setting unit 31 provides job types to the user terminal 10, and when a job is selected by the user terminal 10, a command is referred to with reference to a command list corresponding to the selected job (or job type) Select a list.

If the work environment setting unit 31 does not exist in the desired type of work, the user may directly create a list of commands required for the work. At this time, preferably, the work environment setting unit 31 may request the administrator to review the selected command list. After review by the administrator, the list of commands is selected.

Next, the access control gateway 30 or the work environment setting unit 31 automatically creates and stores a user-specific shell code for the selected command list (S30).

Preferably, the work environment setting unit 31 writes a dedicated shell code in a programming language acceptable to the server to which the user wants to access. That is, the work environment setting unit 31 selects a programming language to be coded by referring to available programming type information for each server as shown in FIG. 5.

The dedicated shell code is converted into an executable file format (C, JAVA, etc., and converted into an executable file in case of a language that is converted into an executable file) and saved.

In the previous example, for the server to be accessed (1.1.1.1) and the selected job type (server resource monitoring), the dedicated shell code is written as code that executes only three commands as follows, in particular, a shell script It is written in a dedicated shell code by a programming language.

[Work command for server resource monitoring]

(1) CPU information check: cat /proc/cpuinfo

(2) Check disk information: cat /proc/meminfo

(3) Check memory information: fdisk ??l

User-specific shell codes are shown in FIGS. 6 and 7.

6 is a form in which user-only shell codes are written by a shell script, and FIG. 7 is a form written by a Python language.

Next, the access control gateway 30 or the authentication processing unit 33 generates an SSH authentication key (S41), accesses the root account (S42), and copies the SSH authentication key (or public key) to the server 40. Then (S43), the user-only shell code executable file is registered in the server 40 (S44).

That is, the authentication processing unit 33 generates and stores an SSH key pair to be used for SSH authentication in the server, that is, a pair of a public key and a private key (S41). The generated SSH key pair is used to set the user or the user terminal 10 to log in to the server to be accessed (1.1.1.1) with the selected account (User A).

Preferably, the SSH Key Pair is not reused once used for a single use. That is, a new key is generated for every connection. That is, a new key is generated and used each time a session is connected.

An example of an SSH key pair is shown in FIG. 8.

In addition, when the generation of the SSH key pair is completed, the authentication processing unit 33 logs in to the root account by using the root access information on the server to be selected (1.1.1.1) selected by the user (S42).

In addition, after the login, the authentication processing unit 33 moves to the home directory/.ssh/ path of the user User A account so that the account selected by the user (User A) can receive SSH KEY authentication (created when there is no path). After moving), add the contents of the public key (ssh_key_public) among the previously created SSH key pairs to the authentication file of the user account (for example, authorized_keys file, etc.). (S43).

9 shows an example in which the SSH public key is added to the authorized_keys file.

In addition, the authentication processing unit 33 copies the previously stored user-only shell code executable file (a file that converts a user-selected job into programming code and converts it into an executable file) to the user home directory, and the user account. Register the path of the executable file in the authentication file (S44). That is, add the command="absolute path of executable file/name of executable file" parameter to the authorized_keys file where SSH KEY authentication information is recorded. Through this, when the user terminal 10 logs in to the server 40, the execution file is forced to be executed.

10 illustrates a command parameter added to the authorized_keys file.

And finally, the connection session of the root account is terminated.

The reason for using a new key for each session connection will be explained in more detail.

In general, in SSH KEY authentication, multiple SSH key pairs can be registered and used in one account. For example, in a real server environment, when a user is connecting to the 1.1.1.1 server with the User A account for the "Server Resource Monitoring" operation, the user is connected to the 1.1.1.1 server with the User A account again to "Manage Users". You can work.

When the above situation occurs, the user, the access server, and the access account are the same, but the workable types are different, so the workable items must be different in the first accessed session and the second accessed session.

In addition, a parameter called command must be added to the SSH key pair public key information added to the authorized_keys file that records the SSH KEY authentication information, so to respond to the above situation, a new key is added whenever a session is connected to the server. You need to add the command parameter to the authorized_keys file after issuing.

Next, the access control gateway 30 or the communication relay unit 33 establishes a session for relaying between the user terminal 10 and the server 40 and performs relaying (S50).

That is, the communication relay unit 33 establishes a server 40 and a server session, and sets a user terminal 10 and a client session corresponding to the server session. Preferably, the session for the server is established as an SSH session.

Specifically, when the SSH KEY authentication setting operation is completed, the communication relay unit 33 accesses the 1.1.1.1 server selected by the user with the User A account. The communication relay unit 33 establishes a session with the server 40 as an SSH session. At this time, an SSH session is established through the authentication processing unit 33. That is, the transmission and reception of messages to and from the server 40 for the SSH session and authentication is performed by the communication relay unit 33, and the generation of the messages for the SSH session and authentication is performed by the authentication processing unit 33.

Meanwhile, preferably, the server authentication is performed through the previously stored SSH KEY (private key), not a password. That is, without separate user authentication (ID and password authentication), the user account of the server 40 can be accessed by only SSH authentication.

If authentication by the SSH authentication key is successful, the server 40 executes the user-only shell code executable file (a file that changes a user-selected task into programming code and converts it into an executable file), A user-only shell is created, and the user is serviced by the user-only shell.

The communication relay unit 33 relays service communication by a user-only shell. That is, the 1.1.1.1 server connection session in which the user-only shell is created is delivered to the user terminal 10, and the user terminal 10 receiving the session can use a list-type shell with a limited working environment.

Preferably, as shown in Fig. 11, the user-only shell is a list type shell. 11 illustrates a working environment of a user who receives a session from the user terminal 10.

Next, the access control gateway 30 or the authentication processing unit 33 initializes the authentication file of the user account in the server 40 when the user's work ends and the session ends (S60).

That is, the communication relay unit 33 transmits the session information (server IP, server access account) used in the corresponding session to the authentication processing unit 33 when the user finishes the work and ends the session. The authentication processing unit 33 extracts public key information matching the private key from the stored SSH key pair information.

The authentication processing unit 33 extracts the public key information, and then logs into the root account of the server IP (1.1.1.1) through the communication relay unit 33 (the access control system already knows the root access information) Then, delete the line that matches the extracted public key information from the contents of the authentication file (or authorized_keys file) of the server access account (User A) used by the user. Also, preferably, the path of the executable file of the user-only shell code in the authentication file is also deleted, and the executable file of the user-only shell code copied to the user account is also deleted. Then, the session ends.

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

As described above, the present invention provides a service in a user-only shell when a user accesses a server. The user-only shell is a list type shell, and only the commands listed in the list can be used. No other commands can be entered.

Therefore, the malicious user or the intruder cannot perform other operations than the predetermined list of commands, thereby enhancing security.

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: working environment setting unit
32: communication relay unit 33: authentication processing unit
40: server 80: database
81: shell code DB 82: authentication key DB
83: Authorized access DB

Claims (6)

In the access control system equipped with at least one user terminal and at least one server, relaying between the user terminal and the server, equipped with a server operation control function for each user,
A work environment setting unit for selecting a command to be used by a user of the user terminal and generating a user-only shell code to process only the selected command (hereinafter, a dedicated command) when requesting access to a user account of the server;
A communication relay unit relaying a message between the user terminal and the server; And,
Establishing a session with the server (hereinafter referred to as a server session) and a session with the user terminal (hereinafter referred to as a client session), including an authentication processor configured to register the user-only shell code with the server and then establish the server session. ,
The communication relay unit performs a connection process or a session establishment process relay by a request for access to the user account with the authentication processing unit,
When the operation of the server is terminated and the session ends, the authentication processing unit accesses the server with a root account and initializes by deleting the user-only shell code registered in the server,
The authentication processing unit accesses the server with a root account, copies the executable file of the user-only shellcode to the directory of the user account in the server, and authenticates the path of the user-only shellcode executable file to the user account. By registering in the file, the user-specific shell code is registered,
When the server is accessed and authenticated with the user account, an access control system equipped with a server task control function for each user, characterized in that an executable file of a user-specific shell code is executed by a path registered in the authentication file of the user account. .
According to claim 1,
The work environment setting unit defines a plurality of tasks, sets the commands necessary for the task into a command list, selects a task by the user, and selects commands in the command list corresponding to the selected task as the dedicated commands Access control system equipped with a server task control function for each user, characterized in that.
According to claim 1,
The user-specific shell code is an execution code that displays the dedicated command as a list, selects one dedicated command from the list of dedicated commands, and executes the selected dedicated command. Access control system equipped with.
According to claim 1,
The authentication processing unit sets the session for the server to a session using a secure shell (SSH) protocol (hereinafter referred to as an SSH session), generates a public key and a private key pair of the SSH authentication key, and connects to the server with access information of the root account. By doing so, registering the public key of the SSH authentication key to the server, copying the executable file of the user-only shell code to the server, and registering the path of the executable file to the server, server operation for each user. Access control system with control function.
The method of claim 4,
The authentication processing unit accesses the root account and registers the public key of the SSH authentication key to the server, then accesses the server with a user account, and performs user authentication of the user account using the registered public key. Access control system equipped with server task control function for each user.
delete

Images