WO2010073364A1 - 情報処理装置、権限設定方法および権限設定プログラム - Google Patents
情報処理装置、権限設定方法および権限設定プログラム Download PDFInfo
- Publication number
- WO2010073364A1 WO2010073364A1 PCT/JP2008/073716 JP2008073716W WO2010073364A1 WO 2010073364 A1 WO2010073364 A1 WO 2010073364A1 JP 2008073716 W JP2008073716 W JP 2008073716W WO 2010073364 A1 WO2010073364 A1 WO 2010073364A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- authentication
- authority
- account
- terminal user
- event
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
Definitions
- the present invention relates to an information processing apparatus, an authority setting method, and an authority setting program.
- Patent Document 1 proposes a technique for changing the authentication strength so as to perform authentication using a plurality of authentication devices according to access authority.
- Patent Document 1 reduces the security level of the system due to the management of the account and authority as a set, makes account management complicated, and makes it convenient for the terminal user. There is a problem that it cannot be said that it is excellent.
- the present invention has been made to solve the above-described problems of the prior art, and is capable of account authority operations that are excellent in account management and excellent in convenience for terminal users while maintaining a high security level. It is an object to provide an information processing apparatus, an authority setting method, and an authority setting program capable of performing general settings.
- the disclosed apparatus includes an account authentication record storage unit that stores an authentication record of the account in association with an account assigned to each terminal user, and terminal use Of an authority / authentication information storage unit for storing an authentication method required for acquiring an authority for the user to execute each operation, and an event for requesting execution of a restricted operation in which the authority of the terminal user is restricted And detecting an authentication record corresponding to the account that has generated the event from the account authentication record storage unit, and an authentication method required for acquiring the authority for executing the restriction operation.
- An authentication request unit that requests the terminal user corresponding to the account to perform authentication necessary for acquiring the authority to execute the restriction operation, and the terminal use corresponding to the account that generated the event
- the authentication record corresponding to the account that generated the event is updated in the authentication records stored in the account authentication record storage unit.
- an authority permission unit that permits the execution of the restriction operation within a predetermined expiration date.
- FIG. 1 is a diagram for explaining the terminal device according to the first embodiment.
- FIG. 2 is a diagram illustrating the configuration of the terminal device according to the first embodiment.
- FIG. 3 is a diagram illustrating a configuration example of the authentication / authorization DB according to the first embodiment.
- FIG. 4 is a diagram for explaining the operation of the authentication management module unit according to the first embodiment.
- FIG. 5 is a diagram illustrating a process flow of the terminal device according to the first embodiment.
- FIG. 6 is a diagram for explaining the effect of the first embodiment.
- FIG. 7 is a diagram illustrating a computer that executes an authority setting program.
- the gist of the terminal device according to the first embodiment is that when the terminal user intends to perform an operation without authority, the terminal user is requested to perform authentication set in advance according to authority, If the terminal user succeeds in authentication, the terminal user is given an operation authority with an expiration date.
- FIG. 1 is a diagram for explaining the terminal device according to the first embodiment.
- the terminal device according to the first embodiment is installed with, for example, client software and connected to an authentication device such as a fingerprint sensor or a vein sensor.
- an authentication device such as a fingerprint sensor or a vein sensor.
- the terminal user registers in advance in the authentication / authorization DB the correspondence between the authentication method using the authentication device and the authority that can be acquired when authentication by this authentication method is successful (see (1) in FIG. 1). .
- a setting screen provided by the client software is used to register the correspondence between the authentication method and the authority.
- the account authentication record DB stores account authentication records in association with accounts assigned to each terminal user.
- the authentication / authorization DB stores an authentication method that is necessary for the terminal user to acquire authority for executing each operation.
- the management module group of the terminal device monitors an event that occurs in an OS (Operating System) or an application.
- an event requesting execution of a restricted operation in which the authority of the terminal user is restricted (having activation restriction) is detected (see (2) in FIG. 1)
- the management module group provides information on the account that generated the event.
- an authentication record corresponding to the acquired account is acquired from the account authentication record DB, and an authentication method required for acquiring the authority for executing the restriction operation is acquired from the authentication / authorization DB.
- the management module group has authority to refer to the information acquired from each of the account authentication record DB and the authentication / authorization DB, and for the terminal user corresponding to the account that generated the event to execute the restricting operation. (See (3) in FIG. 1).
- the management module group refers to the information in the authentication / authorization DB and restricts the user.
- a request is made to perform authentication necessary for execution of the operation (see (4) in FIG. 1).
- the authentication request for example, an authentication screen provided by the client software is used.
- the management module group When the management module group receives the authentication information acquired by the authentication device (see (5) in FIG. 1), the management module group determines the success or failure of the authentication from the received authentication information. If the authentication is successful, the management module group updates the authentication record corresponding to the account that generated the event from the authentication records stored in the account authentication record DB ((6) in FIG. 1). reference). Further, the management module group decides to permit the activation of the function corresponding to the restricted operation within a predetermined expiration date, and returns a permission message indicating that the operation is permitted to the OS (Operating System) and the application (FIG. 1). (See (7)).
- the terminal device can dynamically set account authority that is excellent in account management and excellent in convenience for terminal users while maintaining a high security level.
- FIG. 2 is a diagram illustrating the configuration of the terminal device according to the first embodiment.
- the terminal device 400 according to the first embodiment is connected to the input unit 100, the output unit 200, and the authentication device group 300.
- the input unit 100 includes a keyboard, a mouse, a microphone, and the like, and accepts input of various information such as registration information on the correspondence between authentication methods and authorities from, for example, a terminal user.
- the output unit 200 is configured with a monitor, a pointing device function is realized in cooperation with the mouse.
- the output unit 200 includes a monitor (or display or touch panel) and a speaker, and displays and outputs various types of information such as information on an authentication method requested to the terminal user.
- the authentication device group 300 is a device group for a terminal user to perform various authentications, and includes, for example, a fingerprint sensor, a vein sensor, an IC card, a TPM (Trusted Platform Module: security chip), and the like.
- the terminal device 400 includes a DB group 410 and a management module group 420.
- the DB group 410 stores data and programs necessary for various processes performed by the management module group 420, and particularly includes an account authentication record DB 411 and an authentication / authority DB 412.
- the account authentication record DB 411 is also referred to as an “account authentication record storage unit” described in the claims.
- the authentication / authorization DB 412 is also referred to as “authority / authentication information storage unit” described in the claims.
- the account authentication record DB 411 stores account authentication records in time series in association with accounts assigned to each terminal user. For example, the fact that a terminal user corresponding to an account has successfully authenticated the IC card and the fingerprint is stored and accumulated as a log.
- the authentication / authority DB 412 is required for the terminal user to acquire the authority for executing each restricting operation such as Read (read), Execute (execute), and Write (write).
- the authentication method is stored.
- the right arrow ( ⁇ ) in the authentication method column means that the right side is authenticated after the left side is authenticated.
- the plus sign (+) in the authentication method column means that authentication of the left side and the right side is performed regardless of the order.
- “O” and “X” shown in the authority column indicate the presence or absence of each authority.
- ID1 to ID3 are examples in which the authority acquired by the authority of the IC card is different when the account logged on with the fingerprint is authenticated with the IC card next time.
- ID1 to ID3 it is shown that all the accounts have the authority of Read (read) equally immediately after logging on, and the authority can be acquired equally by the subsequent successful authentication.
- ID4 and ID5 are examples showing the degree of freedom of the combination of authentication and authority.
- the IC card having the administrator authority necessary for acquiring the write (write) authority is set so that no authority can be obtained by the authentication of the IC card alone. Thereby, it is possible to prevent all terminals / networks from being operated due to the theft of one IC card.
- ID6 and ID7 are examples of composite authentication in which the combination and order of authentication are added to the authentication.
- all authority can be obtained.
- the write (write) authority cannot be obtained.
- the management module group 420 executes various processes for dynamically setting account authority, and in particular, setting module unit 421, account management module unit 422, authority management module unit. 423 and an authentication management module unit 424.
- the account management module unit 422 and the authority management module unit 423 are also referred to as “authority determination unit” described in the claims.
- the authority management module unit 423 and the authentication management module unit 424 are also referred to as “authentication request unit” described in the claims.
- the account management module unit 422, the authority management module unit 423, and the authentication management module unit 424 are also referred to as “authorization permission unit” described in the claims.
- the setting module unit 421 provides a terminal user with a GUI (Graphical User Interface) for changing the setting of the client software via the output unit 200. Further, in accordance with the input from the terminal user received via the input unit 100, setting / changing of the operation policy of the account management module unit 422, setting of parameters indicating the expiration date of authority in the authority management module unit 423, and the like Change and set / change the authentication / authorization DB 412.
- GUI Graphic User Interface
- the account management module unit 422 is resident in the system and monitors events that occur in the OS (Operating System) and applications.
- the account management module unit 422 activates the authority management module unit 423 when detecting the occurrence of an event requiring authority.
- the account management module unit 422 detects an event requesting execution of a restriction operation in which the authority of the terminal user is restricted (with activation restriction), the account management module part 422 Start up and check the authority of the account that generated the event.
- the account management module unit 422 receives a message “permission” from the authority management module unit 423, the account management module unit 422 returns a message indicating that the limited operation is permitted to the OS (Operating System) and the application.
- the account management module unit 422 receives a message of “no” authority from the authority management module unit 423, the account management module unit 422 returns a message not permitting the restricted operation to the OS (Operating System) or the application. .
- the authority management module unit 423 When the authority management module unit 423 is activated by the account management module unit 422, the authority management module unit 423 checks the authority of the account that generated the event.
- the authority management module unit 423 when activated by the account management module unit 422, acquires the account that generated the event and sends an authentication record corresponding to the acquired account from the account authentication record DB 411. get.
- the authority management module unit 423 acquires from the authentication / authority DB 412 an authentication method required for acquiring the authority for executing the restriction operation. Then, the authority management module unit 423 refers to the information acquired from each of the account authentication record DB 411 and the authentication / authority DB 412, and the authority for the terminal user corresponding to the account that generated the event to execute the restriction operation. Check if you have.
- the authority management module unit 423 When executing the confirmation, the authority management module unit 423 generates an event based on the authentication record acquired from the account authentication record DB 411 and the authentication method and authority correspondence obtained mainly from the authentication / authority DB 412. Confirm that the terminal user corresponding to the account has successfully completed all the authentication required to acquire the authority. If the terminal user corresponding to the account that generated the event has succeeded in all the authentication necessary for acquiring the authority, the authority management module unit 423 further determines whether the authority is within the expiration date. Confirm. When the authority of the terminal user corresponding to the account that generated the event is confirmed to be within the expiration date, the authority management module unit 423 only executes the restriction operation. Judged to have authority.
- the authority management module unit 423 activates the authentication management module unit 424 when the terminal user corresponding to the account that generated the event does not have authority to execute the restriction operation. Requests the terminal user to perform the authentication required to execute the restriction operation. After starting the authentication management module unit 424, the authority management module unit 423 sends an authentication method for authentication necessary for executing the restriction operation to the authentication management module unit 424.
- the authority management module unit 423 Upon receiving the authentication result indicating that the authentication has been successful from the authentication management module unit 424, the authority management module unit 423 uses the authentication result to authenticate the authentication record in the account authentication record DB 411 corresponding to the account that generated the event. Update. After updating the authentication record, the authority management module unit 423 returns a message “permission” to the account management module part 422. On the other hand, upon receiving an authentication result indicating that the authentication has failed from the authentication management module unit 424, the authority management module unit 423 returns a message of “no” authority to the account management module unit 422.
- the authority management module unit 423 confirms whether or not the terminal user has the authority to execute the restriction operation, and as a result, the terminal user corresponding to the account that generated the event executes the restriction operation. If the user has only the authority, the message “permission” is returned to the account management module unit 422.
- the authentication management module unit 424 When the authentication management module unit 424 is activated by the authority management module unit 423, the authentication management module unit 424 requests the terminal user through the output unit 200 for authentication necessary for acquiring the authority for executing the restriction operation. Based on the authentication data from the terminal user, the success or failure of the authentication is determined, and the authentication result is returned to the authority management module unit 423.
- the authentication management module unit 424 interprets the authentication method received from the authority management module unit 423 when activated by the authority management module unit 423, as shown in FIG. And the authentication management module part 424 requests
- the authentication management module unit 424 receives the authentication data of the terminal user from the authentication device group 300, the authentication management module unit 424 activates the corresponding authentication engine and determines the success or failure of the authentication based on the authentication data.
- FIG. 4 is a diagram for explaining the operation of the authentication management module unit according to the first embodiment.
- the authentication management module unit 424 has succeeded in both fingerprint authentication and IC card authentication. In this case, a message indicating that authentication was successful is returned.
- a request is made to authenticate using an authentication method of “fingerprint authentication or IC card authentication”
- a message indicating that the authentication is successful is returned if one of the authentications is successful.
- the authentication method is “successful fingerprint authentication and then successful IC card authentication (fingerprint ⁇ IC card)”
- authentication is performed in that order, and if both pass, a message indicating successful authentication return it.
- the authentication management module requests the terminal user to authenticate again. If the specified maximum number of authentications fails, a message to that effect is returned to the authority management module unit 423. In the case of no account registration, no authentication procedure registration, no authentication data registration, etc., this is notified to the authority management module unit 423 by an error code. In this case, whether to notify the terminal user is controlled by the set security level.
- FIG. 5 is a diagram illustrating a process flow of the terminal device according to the first embodiment.
- the account management module unit 422 detects an event that occurs in an OS (Operating System) or an application (step S1), the authority of the terminal user is restricted (startup is restricted). It is determined whether or not the event is an operation requesting execution (step S2). If the determination result indicates that the event is not an event requesting execution of a restricted operation in which the authority of the terminal user is restricted (having activation restriction) (No in step S2), the account management module unit 422 permits the operation. A message to that effect is returned to the OS (Operating System) or application.
- the account management module unit 422 determines that the authority of the terminal user is restricted (having activation restriction) as a result of the determination (Yes in step S2), the authority management is performed.
- the module unit 423 is activated (step S3), and the authority of the account that generated the event is confirmed.
- the authority management module unit 423 When started by the account management module unit 422, the authority management module unit 423 acquires the account that generated the event (step S4), and acquires the authentication record corresponding to the acquired account from the account authentication record DB 411. . Further, the authority management module unit 423 acquires an authentication method required for acquiring the authority for executing the restriction operation from the authentication / authority DB 412. Then, the authority management module unit 423 refers to the information acquired from each of the account authentication record DB 411 and the authentication / authority DB 412, and the authority for the terminal user corresponding to the account that generated the event to execute the restriction operation. (Step S5).
- the authority management module unit 423 confirms the authentication management module unit 424. Is activated (step S6), and the terminal user is requested to perform authentication necessary for executing the restriction operation.
- the authentication management module unit 424 interprets the authentication procedure (authentication method) received from the authority management module unit 423 when activated by the authority management module unit 423. Then, the authentication management module unit 424 requests the terminal user for authentication corresponding to the interpreted authentication procedure (authentication method) via the output unit 200 (step S7). When the authentication management module unit 424 receives the authentication data of the terminal user from the authentication device group, the authentication management module unit 424 activates the corresponding authentication engine, determines the success or failure of the authentication based on the authentication data, and sends the authentication result to the authority management module unit. It returns to 423 (step S8).
- the authority management module unit 423 confirms whether or not the message received as the authentication result from the authentication management module unit 424 is a message indicating that the authentication has succeeded (step S9). As a result of the confirmation, if the message indicates that the authentication has succeeded (Yes at Step S9), the authority management module unit 423 uses the authentication result to store the account authentication record DB 411 corresponding to the account that generated the event. The authentication record is updated (step S10). After updating the authentication record, the authority management module unit 423 returns a message of authority “present” to the account management module unit 422 (step S11).
- the authority management module unit 423 determines that the authority received when the message received as an authentication result from the authentication management module part 424 is a message indicating that the authentication has failed (No in step S9). A message “No” is returned to the account management module unit 422 (step S12).
- step S5 the authority management module unit 423 confirms that, as a result of the confirmation, the terminal user corresponding to the account that generated the event has authority to execute the restricting operation ( In step S5, the message “permission” is returned to the account management module unit 422 as in step S11 described above.
- the account management module unit 422 confirms whether or not the message received from the authority management module unit 423 is an authority “Yes” message (step S13). As a result of the confirmation, if the message received from the authority management module unit 423 is an authority “Yes” message (Yes at step S13), the account management module unit 422 restricts the OS (Operating System) and applications. A message to permit the operation is returned (step S14). On the other hand, if the message indicates that the authority is “No” (No at Step S13), the account management module unit 422 returns a message indicating that the restricted operation is not permitted to the OS (Operating System) or the application (Step S15). ).
- the first embodiment it is possible to realize the dynamic setting of the account authority which is excellent in account management and excellent in convenience for the terminal user while maintaining a high security level.
- the terminal user when the terminal user is required to have the administrator authority while operating with the account with the general authority, the management of the name different from the account currently used is used. There is no need to switch to a subscriber account. For this reason, there is no occurrence of a terminal user who neglects to switch accounts and always uses an administrator account. For this reason, there is no possibility of lowering the security level of the system, and a high security level can be maintained.
- the first embodiment there is no case where an administrator account is shared between a plurality of terminal users, and it is easy to manage the terminal user and the account in a one-to-one correspondence. It is. Furthermore, the number of accounts will inevitably be greater than the terminal user. For this reason, the account management is not complicated and the account management is excellent.
- the first embodiment by preparing a plurality of correspondences between authentication methods and authorities, even if any one of a plurality of authentication devices fails, an account that cannot be authenticated can be obtained. Occurrence can be prevented. Furthermore, according to the first embodiment, since authentication according to authority is requested, complicated authentication is not required when a strong authority is not required for the operation itself. Further, since the authority is granted within the expiration date, the account authority is automatically abandoned. For this reason, it is excellent in convenience for the terminal user.
- the first point (see (1) in FIG. 6) is excellent in that log-off is unnecessary in the present invention. In other words, since the employee is logged on with a user account, logoff is necessary in the prior art.
- the administrator authority can be used for all accounts, and therefore, a procedure for logging off once for the administrator authority is unnecessary.
- the second point (see (2) in FIG. 6) is superior in that the administrator authority can be acquired with the minimum authentication because the method authenticated in advance is recorded. That is, in the conventional method, it is necessary to perform fingerprint authentication and IC card authentication in order to log on with an administrator account.
- the technique of the first embodiment when an account being logged on requests authority, only authentication that is insufficient to obtain the necessary authority is performed, so that it is not necessary to perform IC card authentication performed at the time of logon.
- the third point (see (3) in FIG. 6) is excellent in that an administrator account is unnecessary. That is, since it is possible to set the administrator authority to the user account that is normally used, an account for handling the administrator authority is unnecessary. This makes it possible to create a one-to-one relationship between an account and a user, which is superior to conventional techniques in terms of operation logs and account management.
- each component of the terminal device 400 described with reference to FIG. 2 is functionally conceptual, and is not necessarily physically configured as shown in FIG. You don't need to be. That is, the specific form of distribution / integration of the terminal device 400 is not limited to that shown in the figure.
- the authority management module unit 423 and the authentication management module unit 424 are integrated.
- all or some of the constituent elements of the terminal device 400 can be configured to be functionally or physically distributed / integrated in arbitrary units according to various loads or usage conditions.
- each processing function (for example, see FIG. 5) performed in the terminal device 400 is realized by a CPU and a program that is analyzed and executed by the CPU, or wired logic. It can be realized as hardware.
- FIG. 7 is a diagram illustrating a computer that executes an authority setting program.
- a computer 500 is configured by connecting an input unit 510, an output unit 520, an authentication device group 530, an HDD 540, a RAM 550, and a CPU 560 through a bus 600.
- the input unit 510 receives input of various data from the user.
- the output unit 520 displays various information.
- the authentication device group 530 acquires user authentication data.
- the HDD 540 stores information necessary for the CPU 560 to execute various processes.
- the RAM 550 temporarily stores various information.
- the CPU 560 executes various arithmetic processes.
- an authority setting program 541 that exhibits the same function as the management module group 420 of the terminal device 400 shown in the first embodiment and authority setting data 542 are stored in advance. It is remembered. Note that the authority setting program 541 can be appropriately distributed and stored in a storage unit of another computer that is communicably connected via a network.
- the CPU 560 reads out the authority setting program 541 from the HDD 540 and expands it in the RAM 550, so that the authority setting program 541 functions as an authority setting process 551 as shown in FIG. That is, the authority setting process 551 reads the authority setting data 542 and the like from the HDD 540, expands them in an area allocated to itself in the RAM 550, and executes various processes based on the expanded data and the like.
- the authority setting process 551 is executed in the management module group 420 (setting module unit 421, account management module unit 422, authority management module unit 423, and authentication management module unit 424) of the terminal device 400 shown in FIG. Corresponds to processing.
- the authority setting program 541 is not necessarily stored in the HDD 540 from the beginning.
- “portable physical media” such as a flexible disk (FD), a CD-ROM, a DVD disk, a magneto-optical disk, and an IC card to be inserted into the computer 500, and a public line, the Internet, a LAN, a WAN, etc.
- Each program may be stored in “another computer (or server)” connected to the computer 500 via the computer 500, and the computer 500 may read and execute each program from these.
- Authority setting method The following authority setting method is realized by the terminal device 400 described in the first embodiment.
- an authentication record of the account is stored in association with an account assigned to each terminal user
- An authentication / authentication information storage that acquires an authentication record corresponding to the account that generated the event from an account authentication record storage unit that stores the authentication method required to acquire the authority for executing the restriction operation Whether the terminal user corresponding to the account that generated the event has the authority to execute the restricting operation by acquiring the authentication method required for acquiring the authority for executing the restricting operation from the department Corresponding to the account that generated the event and the authority determination step (see, for example, steps S1 to S5 in FIG. 5).
- the restriction operation is executed for the terminal user corresponding to the account that generated the event.
- An authentication requesting step for requesting the authentication necessary for acquiring the authority for the authentication see, for example, steps S5 to S7 in FIG. 5
- the terminal user corresponding to the account that generated the event If the authentication requested by is successful, the authentication record corresponding to the account that generated the event is updated among the authentication records stored in the account authentication record storage unit, and the execution of the restriction operation is performed.
- An authority setting method including an authority permission step that permits within the expiration date is realized.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Storage Device Security (AREA)
Abstract
管理モジュール群は、イベントを発生させたアカウントに対応する端末利用者が、制限操作を実行するだけの権限を有しない場合には、認証・権限DB内の情報を参照し、制限操作の実行に必要な認証を行うように要求する。管理モジュール群は、認証装置により取得された認証情報を受け付けると、受け付けた認証情報から認証の成否判断を行い、認証成功である場合には、アカウント認証記録DBに記憶されている認証記録の内、イベントを発生させたアカウントに対応する認証記録について更新する。さらに、管理モジュール群は、制限操作に対応した機能の起動を所定の有効期限内で許可することを決定し、OS(Operating System)やアプリケーションに操作を許可する旨の許可メッセージを返す。
Description
この発明は、情報処理装置、権限設定方法および権限設定プログラムに関する。
従来、端末や端末の接続されているネットワークのセキュリティを高く保つために、オペレーティングシステムやアプリケーションにアカウント権限による起動制限をかける仕組みが存在する。具体的には、権限の範囲により管理者アカウントと利用者アカウントを用意しておき、オペレーティングシステムやアプリケーションを起動して、管理者権限の必要な作業を行う場合に、管理者アカウントを利用することで高いセキュリティ性を保っている。
上述してきたような仕組みにおいて、管理者アカウントと利用者アカウントで与えられるアクセス権限に違いがあるにも関わらず、認証強度が同一であるという問題があった。この問題に対処するため、例えば、特許文献1では、アクセス権限に応じて複数の認証装置を利用した認証を行うように認証強度を変更する技術が提案されている。
しかしながら、上記した特許文献1に提案の技術には、アカウントと権限とをセットで管理することを原因として、システムのセキュリティレベルを低下させる、アカウント管理が煩雑になる、端末利用者の利便性に優れたものとはいえないという問題点がある。
具体的には、利用者アカウントで操作している途中に、管理者権限が必要になった場合に、今使用しているアカウントとは別の名前の管理者アカウントに切り替える必要がある。このため、アカウント切り替えを怠り、常に管理者アカウントを使用する端末使用者が発生する。このようなことから、システムのセキュリティレベルを低下させる可能性がある。
また、複数の端末使用者間で管理者アカウントを共有して使用する場合が発生するので、端末使用者とアカウントとを1対1で対応させて管理することが難しく、結果として、端末のログからどの端末使用者が操作したのか分からない。さらには、アカウントの数が必然的に端末使用者より多くなる。このようなことから、アカウント管理が煩雑になることが予想される。
また、複数の認証装置のどれか一つでも故障した場合は、認証が行えないアカウントが発生する場合が考えられる。さらには、管理者アカウントでログオン中の時は、操作自体に強力な権限を必要としない場合でも、管理者権限に応じた認証強度の煩雑な認証手順を要求される。このようなことから、端末利用者の利便性に優れたものとはいえない。
そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、高いセキュリティレベルを保ちつつ、アカウント管理に優れるとともに、端末利用者の利便性にも優れたアカウント権限の動的な設定が可能な情報処理装置、権限設定方法および権限設定プログラムを提供することを目的とする。
上述した課題を解決し、目的を達成するため、開示の装置は、端末利用者ごとに割り当てられているアカウントに対応付けて、当該アカウントの認証記録を記憶するアカウント認証記録記憶部と、端末利用者が各操作を実行するための権限の取得に必要とされる認証方法を記憶する権限/認証情報記憶部と、端末利用者の権限が制限されている制限操作の実行を要求するイベントの発生を検知した場合に、当該イベントを発生させたアカウントに対応する認証記録を前記アカウント認証記録記憶部から取得するとともに、前記制限操作を実行するための権限の取得に必要とされる認証方法を前記権限/認証情報記憶部から取得して、前記アカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有するか否かを判定する権限判定部と、前記イベントを発生させたアカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有していないと前記権限判定部により判定された場合には、前記イベントを発生させたアカウントに対応する端末利用者に対して、前記制限操作を実行するための権限の取得に必要な認証を行うように要求する認証要求部と、前記イベントを発生させたアカウントに対応する端末利用者が、前記認証要求部により要求された認証に成功した場合には、前記アカウント認証記録記憶部に記憶されている認証記録の内、前記イベントを発生させたアカウントに対応する認証記録を更新するとともに、前記制限操作の実行を所定の有効期限内で許可する権限許可部とを有する。
開示の装置によれば、高いセキュリティレベルを保ちつつ、アカウント管理に優れるとともに、端末利用者の利便性にも優れたアカウント権限の動的な設定が可能である。
100 入力部
200 出力部
300 認証装置群
400 端末装置
410 DB群
411 アカウント認証記録DB
412 認証・権限DB
420 管理モジュール群
421 設定モジュール部
422 アカウント管理モジュール部
423 権限管理モジュール部
424 認証管理モジュール部
500 コンピュータ
510 入力部
520 出力部
530 認証装置群
540 HDD(Hard Disk Drive)
541 権限設定プログラム
542 権限設定用データ
550 RAM(Random Access Memory)
551 権限設定プロセス
560 CPU(Central Processing Unit)
600 バス
200 出力部
300 認証装置群
400 端末装置
410 DB群
411 アカウント認証記録DB
412 認証・権限DB
420 管理モジュール群
421 設定モジュール部
422 アカウント管理モジュール部
423 権限管理モジュール部
424 認証管理モジュール部
500 コンピュータ
510 入力部
520 出力部
530 認証装置群
540 HDD(Hard Disk Drive)
541 権限設定プログラム
542 権限設定用データ
550 RAM(Random Access Memory)
551 権限設定プロセス
560 CPU(Central Processing Unit)
600 バス
以下に、情報処理装置、権限設定方法および権限設定プログラムの一実施形態を詳細に説明する。なお、以下では、情報処理装置の一例として、いわゆるパーソナルコンピュータなどの端末装置を取り上げて説明する。
実施例1に係る端末装置の骨子は、端末利用者が、権限を有しない操作を実行しようとする場合に、権限に応じて予め設定された認証を行うように端末利用者に要求して、端末利用者が認証に成功した場合には、端末利用者に有効期限を付した操作権限を与える点にある。
図1を参照しつつ、具体的に説明する。図1は、実施例1に係る端末装置を説明するための図である。同図に示すように、実施例1に係る端末装置は、例えば、クライアント用ソフトウェアがインストールされ、指紋センサや静脈センサ等の認証装置に接続されている。
端末利用者は、認証装置を用いた認証方法と、この認証方法による認証に成功した場合に取得可能な権限の対応関係を認証・権限DBに事前に登録する(図1の(1)参照)。なお、同図に示すように、認証方法と権限との対応関係の登録には、例えば、クライアント用ソフトウェアの提供する設定画面を利用する。
なお、アカウント認証記録DBには、端末利用者ごとに割り当てられているアカウントに対応付けて、アカウントの認証記録を記憶している。また、認証・権限DBは、端末利用者が各操作を実行するための権限の取得に必要とされる認証方法を記憶している。
そして、実施例1に係る端末装置の管理モジュール群は、OS(Operating System)やアプリケーションで発生するイベントを監視する。端末利用者の権限が制限されている(起動制限のある)制限操作の実行を要求するイベントを検知すると(図1の(2)参照)、管理モジュール群は、イベントを発生させたアカウントの情報を取得し、取得されたアカウントに対応する認証記録をアカウント認証記録DBから取得するとともに、制限操作を実行するための権限の取得に必要とされる認証方法を認証・権限DBから取得する。そして、管理モジュール群は、アカウント認証記録DBおよび認証・権限DBの各々から取得した情報を参照して、イベントを発生させたアカウントに対応する端末利用者が制限操作を実行するだけの権限を有するか否かを確認する(図1の(3)参照)。
管理モジュール群は、確認の結果、イベントを発生させたアカウントに対応する端末利用者が、制限操作を実行するだけの権限を有しない場合には、認証・権限DB内の情報を参照し、制限操作の実行に必要な認証を行うように要求する(図1の(4)参照)。なお、同図に示すように、認証の要求には、例えば、クライアント用ソフトウェアの提供する認証画面を利用する。
管理モジュール群は、認証装置により取得された認証情報を受け付けると(図1の(5)参照)、受け付けた認証情報から認証の成否判断を行う。そして、管理モジュール群は、認証成功である場合には、アカウント認証記録DBに記憶されている認証記録の内、イベントを発生させたアカウントに対応する認証記録について更新する(図1の(6)参照)。さらに、管理モジュール群は、制限操作に対応した機能の起動を所定の有効期限内で許可することを決定し、OS(Operating System)やアプリケーションに操作の許可する旨の許可メッセージを返す(図1の(7)参照)。
このようなことから、実施例1に係る端末装置は、高いセキュリティレベルを保ちつつ、アカウント管理に優れるとともに、端末利用者の利便性にも優れたアカウント権限を動的に設定できる。
[端末装置の構成(実施例1)]
図2は、実施例1に係る端末装置の構成を示す図である。実施例1に係る端末装置400は、入力部100、出力部200および認証装置群300に接続される。
図2は、実施例1に係る端末装置の構成を示す図である。実施例1に係る端末装置400は、入力部100、出力部200および認証装置群300に接続される。
入力部100は、キーボードやマウス、マイクなどを備えて構成され、例えば、端末利用者から、認証方法と権限との対応関係の登録情報などの各種情報の入力を受け付ける。なお、出力部200がモニタで構成される場合には、マウスと協働してポインティングディバイス機能を実現する。また、出力部200は、モニタ(若しくはディスプレイ、タッチパネル)やスピーカを備えて構成され、端末利用者に対して要求する認証方法の情報などの各種の情報を表示出力する。
認証装置群300は、端末利用者が各種認証を実行するための装置群であり、例えば、指紋センサ、静脈センサ、ICカードやTPM(Trusted Platform Module:セキュリティチップ)などを有する。
また、図2に示すように、端末装置400は、DB群410および管理モジュール群420を有する。
DB群410は、管理モジュール群420による各種処理に必要なデータおよびプログラムを記憶し、特に、アカウント認証記録DB411および認証・権限DB412を有する。
なお、アカウント認証記録DB411は、特許請求の範囲に記載の「アカウント認証記録記憶部」ともいう。認証・権限DB412は、特許請求の範囲の記載の「権限/認証情報記憶部」ともいう。
アカウント認証記録DB411は、端末利用者ごとに割り当てられているアカウントに対応付けて、アカウントの認証記録を時系列に記憶している。例えば、あるアカウントに対応する端末利用者が、ICカードおよび指紋の認証に成功したことがログとして記憶され、蓄積されている。
認証・権限DB412は、例えば、図3に示すように、端末利用者がRead(読込み)、Execute(実行)、Write(書き込み)などの各制限操作を実行するための権限の取得に必要とされる認証方法を記憶している。具体的には、認証方法の列の右矢印(→)は、左辺の認証を行った後に右辺の認証を行うことを意味する。また、認証方法の列のプラス記号(+)は、左辺と右辺の認証を順序に関係なく行うことを意味する。権限の列に示した「○」と「×」は、各権限の有無を表す。
例えば、ID1~ID3は、指紋でログオンしたアカウントが、次にICカードで認証を行った場合に、ICカードの権限により獲得する権限が異なることを示した例である。ID1~ID3に示す例では、全てのアカウントがログオン直後は平等にRead(読込み)の権限を持ち、その後の認証の成功により平等に権限獲得を行うことが出来ることを示している。
また、ID4およびID5は、認証と権限の組み合わせの自由度を示した例である。上記のID1~ID3に示す例では、Write(書き込み)の権限を獲得するために必要であった管理者権限のICカードを、ICカード単体の認証では権限を全く得られないように設定した。これにより、1枚のICカードの盗難で、全ての端末・ネットワークが操作されてしまうことを防止できる。
また、ID6およびID7は、認証の組み合わせと順序を認証に加味した複合認証の例である。ID6およびID7に示す例では、一般権限のICカードでの認証に成功した後に、管理者権限のICカードでの認証に成功した場合には全ての権限を得られるが、管理者権限のICカードで認証に成功した後に、一般権限のICカードで認証した場合はWrite(書き込み)の権限を獲得することが出来ないことを表している。認証の順序を考慮することにより、従来よりも高いセキュリティを実現可能である。なお、図3は、実施例1に係る認証・権限DBの構成例を示す図である。
また、図2に示すように、管理モジュール群420は、アカウント権限の動的な設定を行うための種々の処理を実行し、特に、設定モジュール部421、アカウント管理モジュール部422、権限管理モジュール部423および認証管理モジュール部424を有する。
なお、アカウント管理モジュール部422および権限管理モジュール部423は、特許請求の範囲に記載の「権限判定部」ともいう。また、権限管理モジュール部423および認証管理モジュール部424は、特許請求の範囲に記載の「認証要求部」ともいう。また、アカウント管理モジュール部422、権限管理モジュール部423および認証管理モジュール部424は、特許請求の範囲に記載の「権限許可部」ともいう。
設定モジュール部421は、出力部200を介して、クライアントソフトウェアの設定変更を行うためのGUI(Graphical User Interface)を端末利用者に提供する。また、入力部100を介して受け付けた端末利用者からの入力に応じて、アカウント管理モジュール部422の動作ポリシの設定・変更、権限管理モジュール部423における権限の有効期限を示すパラメータ等の設定・変更、および認証・権限DB412の設定・変更等を行う。
アカウント管理モジュール部422は、システム内に常駐し、OS(Operating System)やアプリケーションで発生するイベントを監視する。アカウント管理モジュール部422は、権限の必要なイベントの発生を検知した場合には、権限管理モジュール部423を起動する。
具体的に説明すると、アカウント管理モジュール部422は、端末利用者の権限が制限されている(起動制限のある)制限操作の実行を要求するイベントを検知した場合には、権限管理モジュール部423を起動して、イベントを発生させたアカウントの権限を確認させる。そして、アカウント管理モジュール部422は、権限管理モジュール部423から、権限「有」のメッセージを受けた場合には、OS(Operating System)やアプリケーションに対して、制限操作を許可する旨のメッセージを返す。一方、アカウント管理モジュール部422は、権限管理モジュール部423から、権限「無」のメッセージを受けた場合には、OS(Operating System)やアプリケーションに対して、制限操作を許可しない旨のメッセージを返す。
権限管理モジュール部423は、アカウント管理モジュール部422により起動されると、イベントを発生させたアカウントの権限確認等を行う。
具体的に説明すると、権限管理モジュール部423は、アカウント管理モジュール部422により起動されると、イベントを発生させたアカウントを取得して、取得されたアカウントに対応する認証記録をアカウント認証記録DB411から取得する。
さらに、権限管理モジュール部423は、制限操作を実行するための権限の取得に必要とされる認証方法を認証・権限DB412から取得する。そして、権限管理モジュール部423は、アカウント認証記録DB411および認証・権限DB412の各々から取得した情報を参照して、イベントを発生させたアカウントに対応する端末利用者が制限操作を実行するだけの権限を有するか否かを確認する。
なお、確認を実行する際、権限管理モジュール部423は、アカウント認証記録DB411から取得した認証記録と、認証・権限DB412から主得した認証方法および権限の対応関係とに基づいて、イベントを発生させたアカウントに対応する端末利用者が、権限の取得に必要な認証に全て成功しているか否かを確認する。イベントを発生させたアカウントに対応する端末利用者が、権限の取得に必要な認証に全て成功している場合には、権限管理モジュール部423は、さらに、権限が有効期限内にあるか否かを確認する。そして、権限管理モジュール部423は、イベントを発生させたアカウントに対応する端末利用者の権限が、有効期限内にあることが確認できた場合には、端末利用者が制限操作を実行するだけの権限を有するものと判定する。
権限管理モジュール部423は、確認の結果、イベントを発生させたアカウントに対応する端末利用者が、制限操作を実行するだけの権限を有しない場合には、認証管理モジュール部424を起動して、制限操作の実行に必要な認証を端末利用者に行わせるように要求する。認証管理モジュール部424を起動後、権限管理モジュール部423は、制限操作の実行に必要な認証の認証方法を認証管理モジュール部424に送る。
そして、権限管理モジュール部423は、認証管理モジュール部424から認証に成功した旨の認証結果を受けると、認証結果を用いて、イベントを発生させたアカウントに対応するアカウント認証記録DB411内の認証記録を更新する。認証記録の更新後、権限管理モジュール部423は、権限「有」のメッセージをアカウント管理モジュール部422に返す。一方、権限管理モジュール部423は、認証管理モジュール部424から認証に失敗した旨の認証結果を受けると、権限「無」のメッセージをアカウント管理モジュール部422に返す。
また、権限管理モジュール部423は、端末利用者が制限操作を実行するだけの権限を有するか否かを確認した結果、イベントを発生させたアカウントに対応する端末利用者が、制限操作を実行するだけの権限を有する場合には、権限「有」のメッセージをアカウント管理モジュール部422に返す。
認証管理モジュール部424は、権限管理モジュール部423により起動されると、出力部200を介して、制限操作を実行するための権限の取得に必要とされる認証を端末利用者に要求する。そして、端末利用者からの認証データに基づいて、認証の成否を判断し、認証結果を権限管理モジュール部423に返す。
具体的に説明すると、認証管理モジュール部424は、図4に示すように、権限管理モジュール部423により起動されると、権限管理モジュール部423から受けた認証方法を解釈する。そして、認証管理モジュール部424は、出力部200を介して、解釈した認証方法に対応する認証を端末利用者に要求する。そして、認証管理モジュール部424は、認証装置群300から端末利用者の認証データを受け付けると、対応する認証エンジンを起動し、認証データに基づいて認証の成否を判定する。
認証に成功した場合には、認証に成功した旨のメッセージを権限管理モジュール部423に返す。一方、認証に失敗した場合には、認証に失敗した旨のメッセージを権限管理モジュール部423に返す。なお、図4は、実施例1に係る認証管理モジュール部の動作を説明するための図である。
例えば、認証管理モジュール部424は、あるアカウントを「指紋認証かつICカード認証(指紋+ICカード)」の認証方法で認証するように要求がきた場合は、指紋認証とICカード認証の両方に成功した場合に、認証に成功した旨のメッセージを返す。同様に、「指紋認証またはICカード認証」の認証方法で認証するように要求がきた場合は、片方の認証に成功すれば、認証に成功した旨のメッセージを返す。また、「指紋認証に成功してからICカード認証に成功する(指紋→ICカード)」という認証方法ならば、その順番どおりに認証し、両方に合格した場合に、認証に成功した旨のメッセージを返す。
また、認証データに欠けがあるなどして、認証データが正確に得られなかった場合は、認証管理モジュールは端末利用者に再度認証を要求する。規定した最大回数の認証に失敗した場合は、その旨をエラーコードで権限管理モジュール部423に返信する。アカウント登録無し、認証手順登録無し、認証データ登録無しなどの場合に関しては、その旨をエラーコードで権限管理モジュール部423に知らせる。この場合、端末利用者に知らせるかどうかは、設定したセキュリティレベルによって制御する。
[端末装置の処理(実施例1)]
図5は、実施例1に係る端末装置の処理の流れを示す図である。同図に示すように、アカウント管理モジュール部422は、OS(Operating System)やアプリケーションで発生するイベントを検知すると(ステップS1)、端末利用者の権限が制限されている(起動制限のある)制限操作の実行を要求するイベントであるか否かを判定する(ステップS2)。アカウント管理モジュール部422は、判定の結果、端末利用者の権限が制限されている(起動制限のある)制限操作の実行を要求するイベントではない場合には(ステップS2否定)、操作を許可する旨のメッセージをOS(Operating System)やアプリケーションに返す。
図5は、実施例1に係る端末装置の処理の流れを示す図である。同図に示すように、アカウント管理モジュール部422は、OS(Operating System)やアプリケーションで発生するイベントを検知すると(ステップS1)、端末利用者の権限が制限されている(起動制限のある)制限操作の実行を要求するイベントであるか否かを判定する(ステップS2)。アカウント管理モジュール部422は、判定の結果、端末利用者の権限が制限されている(起動制限のある)制限操作の実行を要求するイベントではない場合には(ステップS2否定)、操作を許可する旨のメッセージをOS(Operating System)やアプリケーションに返す。
一方、アカウント管理モジュール部422は、判定の結果、端末利用者の権限が制限されている(起動制限のある)制限操作の実行を要求するイベントである場合には(ステップS2肯定)、権限管理モジュール部423を起動して(ステップS3)、イベントを発生させたアカウントの権限を確認させる。
権限管理モジュール部423は、アカウント管理モジュール部422により起動されると、イベントを発生させたアカウントを取得して(ステップS4)、取得されたアカウントに対応する認証記録をアカウント認証記録DB411から取得する。さらに、権限管理モジュール部423は、制限操作を実行するための権限の取得に必要とされる認証方法を認証・権限DB412から取得する。そして、権限管理モジュール部423は、アカウント認証記録DB411および認証・権限DB412の各々から取得した情報を参照して、イベントを発生させたアカウントに対応する端末利用者が制限操作を実行するだけの権限を有するか否かを確認する(ステップS5)。
権限管理モジュール部423は、確認の結果、イベントを発生させたアカウントに対応する端末利用者が、制限操作を実行するだけの権限を有しない場合には(ステップS5否定)、認証管理モジュール部424を起動して(ステップS6)、制限操作の実行に必要な認証を端末利用者に行わせるように要求する。
認証管理モジュール部424は、権限管理モジュール部423により起動されると、権限管理モジュール部423から受けた認証手順(認証方法)を解釈する。そして、認証管理モジュール部424は、出力部200を介して、解釈した認証手順(認証方法)に対応する認証を端末利用者に要求する(ステップS7)。そして、認証管理モジュール部424は、認証装置群から端末利用者の認証データを受け付けると、対応する認証エンジンを起動し、認証データに基づいて認証の成否を判定し、認証結果を権限管理モジュール部423に返す(ステップS8)。
そして、権限管理モジュール部423は、認証管理モジュール部424から認証結果として受けたメッセージが認証に成功した旨のメッセージであるか否かを確認する(ステップS9)。確認の結果、認証に成功した旨のメッセージである場合には(ステップS9肯定)、権限管理モジュール部423は、認証結果を用いて、イベントを発生させたアカウントに対応するアカウント認証記録DB411内の認証記録を更新する(ステップS10)。認証記録の更新後、権限管理モジュール部423は、権限「有」のメッセージをアカウント管理モジュール部422に返す(ステップS11)。
ここで、ステップS9の説明に戻ると、権限管理モジュール部423は、認証管理モジュール部424から認証結果として受けたメッセージが認証に失敗した旨のメッセージである場合には(ステップS9否定)、権限「無」のメッセージをアカウント管理モジュール部422に返す(ステップS12)。
ここで、ステップS5の説明に戻ると、権限管理モジュール部423は、確認の結果、イベントを発生させたアカウントに対応する端末利用者が、制限操作を実行するだけの権限を有する場合には(ステップS5肯定)、上述したステップS11と同様に、権限「有」のメッセージをアカウント管理モジュール部422に返す。
アカウント管理モジュール部422は、権限管理モジュール部423から受けたメッセージが権限「有」のメッセージであるか否かを確認する(ステップS13)。確認の結果、権限管理モジュール部423から受けたメッセージが権限「有」のメッセージである場合には(ステップS13肯定)、アカウント管理モジュール部422は、OS(Operating System)やアプリケーションに対して、制限操作を許可する旨のメッセージを返す(ステップS14)。一方、権限「無」のメッセージである場合には(ステップS13否定)、アカウント管理モジュール部422は、OS(Operating System)やアプリケーションに対して、制限操作を許可しない旨のメッセージを返す(ステップS15)。
なお、上述してきた端末装置400による処理は、装置起動中において繰り返し実行される。
[実施例1による効果]
上述してきたように、実施例1によれば、端末利用者が、権限を有しない操作を実行しようとする場合に、権限に応じて予め設定された認証を行うように端末利用者に要求する。そして、端末利用者が認証に成功した場合には、端末利用者に有効期限を付した操作権限を与える。
上述してきたように、実施例1によれば、端末利用者が、権限を有しない操作を実行しようとする場合に、権限に応じて予め設定された認証を行うように端末利用者に要求する。そして、端末利用者が認証に成功した場合には、端末利用者に有効期限を付した操作権限を与える。
このようなことから、実施例1によれば、高いセキュリティレベルを保ちつつ、アカウント管理に優れるとともに、端末利用者の利便性にも優れたアカウント権限の動的な設定を実現できる。
すなわち、実施例1によれば、端末利用者が、一般権限のアカウントで操作している途中に、管理者権限が必要になった場合に、今使用しているアカウントとは別の名前の管理者アカウントに切り替える必要がない。このため、アカウント切り替えを怠り、常に管理者アカウントを使用する端末使用者が発生することもない。このようなことから、システムのセキュリティレベルを低下させる可能性はなくなり、高いセキュリティレベルを保つことができる。
また、実施例1によれば、複数の端末使用者間で管理者アカウントを共有して使用する場合が発生せず、端末使用者とアカウントとを1対1で対応させて管理することも容易である。さらには、アカウントの数が必然的に端末使用者より多くなることはない。このようなことから、アカウント管理が煩雑になることがなく、アカウント管理に優れる。
また、実施例1によれば、認証方法と権限との対応関係を複数用意しておくことで、複数の認証装置のどれか一つでも故障した場合であっても、認証が行えないアカウントの発生を防止できる。さらには、実施例1によれば、権限に応じた認証を要求するので、操作自体に強力な権限を必要としない場合には、煩雑な認証を要求されることはない。また、有効期限内で権限を付与するので、アカウント権限の放棄も自動的に行われる。このようなことから、端末利用者の利便性にも優れる。
また、図6を用いて、従来技術と実施例1の技術との比較について説明する。従来方法と本発明のログオン時の手順を比較したものである。運用シーンとしては、従業員は全て利用者アカウントで業務を行う企業で、IT管理者が従業員の端末の設定変更を行う状況を想定している。なお、利用者アカウント(一般権限のアカウント)へのログオンにはICカード認証が、管理者アカウントへログオンするには指紋認証とICカード認証が必要であるとする。このシーンでは、以下の3つの点で実施例1の技術が優れている。
1点目(図6の(1)参照)は、本発明ではログオフが不要である点で優れている。すなわち、従業員は利用者アカウントでログオン中であるため、従来技術ではログオフが必要であった。実施例1の技術では全てのアカウントで管理者権限を利用することが可能であるため、管理者権限のために一度ログオフする手順が不要である。
2点目(図6の(2)参照)は、事前に認証した方式を記録するため、最低限の認証で管理者権限を取得可能である点で優れている。すなわち、従来の方法では、管理者アカウントでログオンするためには指紋認証とICカード認証を行う必要がある。実施例1の技術では、ログオン中のアカウントが権限を要求する場合、必要な権限を得るのに不足している認証のみを行うため、ログオン時に行っているICカード認証を行う必要が無い。
3点目(図6の(3)参照)は、管理者アカウントが不要である点で優れている。すなわち、通常利用している利用者アカウントに管理者権限を設定することが可能なため、管理者権限を扱うためのアカウントが不要である。これによりアカウントと利用者の一対一の関係を作ることができるため、操作ログやアカウント管理の面で従来技術よりも優れている。
以下に、情報処理装置、情報処理方法および情報処理プログラムの他の実施形態を説明する。
(1)装置構成等
上記の実施例1において、図2を用いて説明した端末装置400の各構成要素は機能概念的なものであり、必ずしも物理的に同図に示すようにして構成されていることを要しない。すなわち、端末装置400の分散・統合の具体的形態は同図に示すものに限られず、例えば、権限管理モジュール部423と認証管理モジュール部424とを統合する。このように、端末装置400の各構成要素の全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、端末装置400にて行なわれる各処理機能(例えば、図5参照)は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
上記の実施例1において、図2を用いて説明した端末装置400の各構成要素は機能概念的なものであり、必ずしも物理的に同図に示すようにして構成されていることを要しない。すなわち、端末装置400の分散・統合の具体的形態は同図に示すものに限られず、例えば、権限管理モジュール部423と認証管理モジュール部424とを統合する。このように、端末装置400の各構成要素の全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、端末装置400にて行なわれる各処理機能(例えば、図5参照)は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
(2)権限設定プログラム
ところで、上記の実施例1で説明した各種の処理(例えば、図5参照)は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、上記の実施例1と同様の機能を有する機能設定プログラムを実行するコンピュータの一例を説明する。図7は、権限設定プログラムを実行するコンピュータを示す図である。
ところで、上記の実施例1で説明した各種の処理(例えば、図5参照)は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、上記の実施例1と同様の機能を有する機能設定プログラムを実行するコンピュータの一例を説明する。図7は、権限設定プログラムを実行するコンピュータを示す図である。
同図に示すように、コンピュータ500は、入力部510、出力部520、認証装置群530、HDD540、RAM550およびCPU560をバス600で接続して構成される。
ここで、入力部510は、ユーザから各種データの入力を受け付ける。出力部520は、各種情報を表示する。認証装置群530は、ユーザの認証データを取得する。HDD540は、CPU560による各種処理の実行に必要な情報を記憶する。RAM550は、各種情報を一時的に記憶する。CPU560は、各種演算処理を実行する。
そして、HDD540には、図7に示すように、上記の実施例1に示した端末装置400の管理モジュール群420と同様の機能を発揮する権限設定プログラム541と、権限設定用データ542とがあらかじめ記憶されている。なお、この権限設定プログラム541を適宜分散させて、ネットワークを介して通信可能に接続された他のコンピュータの記憶部に記憶させておくこともできる。
そして、CPU560が、この権限設定プログラム541をHDD540から読み出してRAM550に展開することにより、図7に示すように、権限設定プログラム541は、権限設定プロセス551として機能するようになる。すなわち、権限設定プロセス551は、権限設定用データ542等をHDD540から読み出して、RAM550において自身に割り当てられた領域に展開し、この展開したデータ等に基づいて各種処理を実行する。なお、権限設定プロセス551は、図2に示した端末装置400の管理モジュール群420(設定モジュール部421、アカウント管理モジュール部422、権限管理モジュール部423および認証管理モジュール部424)等において実行される処理に対応する。
なお、上記した権限設定プログラム541については、必ずしも最初からHDD540に記憶させておく必要はない。例えば、コンピュータ500に挿入されるフレキシブルディスク(FD)、CD-ROM、DVDディスク、光磁気ディスク、ICカードなどの「可搬用の物理媒体」、さらには、公衆回線、インターネット、LAN、WANなどを介してコンピュータ500に接続される「他のコンピュータ(またはサーバ)」などに各プログラムを記憶させておき、コンピュータ500がこれらから各プログラムを読み出して実行するようにしてもよい。
(3)権限設定方法
上記の実施例1で説明した端末装置400により、以下のような権限設定方法が実現される。
上記の実施例1で説明した端末装置400により、以下のような権限設定方法が実現される。
すなわち、端末利用者の権限が制限されている制限操作の実行を要求するイベントの発生を検知した場合に、端末利用者ごとに割り当てられているアカウントに対応付けて、当該アカウントの認証記録を記憶するアカウント認証記録記憶部から、前記イベントを発生させたアカウントに対応する認証記録を取得するとともに、制限操作を実行するための権限の取得に必要とされる認証方法を記憶する権限/認証情報記憶部から、制限操作を実行するための権限の取得に必要とされる認証方法を取得して、イベントを発生させたアカウントに対応する端末利用者が制限操作を実行するだけの権限を有するか否かを判定する権限判定ステップ(例えば、図5のステップS1~ステップS5参照)と、イベントを発生させたアカウントに対応する端末利用者が制限操作を実行するだけの権限を有していないと権限判定ステップにより判定された場合には、イベントを発生されたアカウントに対応する端末利用者に対して、制限操作を実行するための権限の取得に必要な認証を行うように要求する認証要求ステップと(例えば、図5のステップS5~ステップS7参照)、イベントを発生させたアカウントに対応する端末利用者が、認証要求ステップにより要求された認証に成功した場合には、アカウント認証記録記憶部に記憶されている認証記録の内、イベントを発生させたアカウントに対応する認証記録を更新するとともに、制限操作の実行を所定の有効期限内で許可する権限許可ステップと(例えば、図5のステップS8~ステップS14参照)を含んだ権限設定方法が実現される。
Claims (5)
- 端末利用者ごとに割り当てられているアカウントに対応付けて、当該アカウントの認証記録を記憶するアカウント認証記録記憶部と、
端末利用者が各操作を実行するための権限の取得に必要とされる認証方法を記憶する権限/認証情報記憶部と、
端末利用者の権限が制限されている制限操作の実行を要求するイベントの発生を検知した場合に、当該イベントを発生させたアカウントに対応する認証記録を前記アカウント認証記録記憶部から取得するとともに、前記制限操作を実行するための権限の取得に必要とされる認証方法を前記権限/認証情報記憶部から取得して、前記アカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有するか否かを判定する権限判定部と、
前記イベントを発生させたアカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有していないと前記権限判定部により判定された場合には、前記イベントを発生させたアカウントに対応する端末利用者に対して、前記制限操作を実行するための権限の取得に必要な認証を行うように要求する認証要求部と、
前記イベントを発生させたアカウントに対応する端末利用者が、前記認証要求部により要求された認証に成功した場合には、前記アカウント認証記録記憶部に記憶されている認証記録の内、前記イベントを発生させたアカウントに対応する認証記録を更新するとともに、前記制限操作の実行を所定の有効期限内で許可する権限許可部と
を有する情報処理装置。 - 前記権限判定部は、端末利用者の操作に伴うイベントの発生を検知するごとに、当該イベントを発生させたアカウントに対応する認証記録を前記アカウント認証記録記憶部から取得するとともに、前記制限操作を実行するための権限の取得に必要とされる認証方法を前記権限/認証情報記憶部から取得して、前記アカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有するか否かを判定するが、前記アカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有する場合には、当該権限が所定の有効期限内にあるか否かをさらに判定し、
前記認証要求部は、前記アカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有するが、当該権限が所定の有効期限内にないと前記権限判定部により判定された場合には、前記イベントを発生させたアカウントに対応する端末利用者に対して、前記制限操作を実行するための権限の取得に必要な認証を行うように要求する請求項1に記載の情報処理装置。 - 前記権限/認証情報記憶部は、複数の認証方式の組合せおよび/または複数の認証方式の実行順序を認証方法として記憶する請求項1または2に記載の情報処理装置。
- 端末利用者の権限が制限されている制限操作の実行を要求するイベントの発生を検知した場合に、端末利用者ごとに割り当てられているアカウントに対応付けて、当該アカウントの認証記録を記憶するアカウント認証記録記憶部から、前記イベントを発生させたアカウントに対応する認証記録を取得するとともに、前記制限操作を実行するための権限の取得に必要とされる認証方法を記憶する権限/認証情報記憶部から、前記制限操作を実行するための権限の取得に必要とされる認証方法を取得して、前記アカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有するか否かを判定する権限判定ステップと、
前記イベントを発生させたアカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有していないと前記権限判定ステップにより判定された場合には、前記イベントを発生されたアカウントに対応する端末利用者に対して、前記制限操作を実行するための権限の取得に必要な認証を行うように要求する認証要求ステップと、
前記イベントを発生させたアカウントに対応する端末利用者が、前記認証要求ステップにより要求された認証に成功した場合には、前記アカウント認証記録記憶部に記憶されている認証記録の内、前記イベントを発生させたアカウントに対応する認証記録を更新するとともに、前記制限操作の実行を所定の有効期限内で許可する権限許可ステップと
を含む権限設定方法。 - 端末利用者の権限が制限されている制限操作に対応した機能の起動を要求するイベントの発生を検知した場合に、端末利用者ごとに割り当てられているアカウントに対応付けて、当該アカウントの認証記録を記憶するアカウント認証記録記憶部から、前記イベントを発生させたアカウントに対応する認証記録を取得するとともに、前記制限操作を実行するための権限の取得に必要とされる認証方法を記憶する権限/認証情報記憶部から、前記制限操作に対応する機能の起動に必要とされる権限を取得して、前記アカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有するか否かを判定する権限判定手順と、
前記イベントを発生させたアカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有していないと前記権限判定手順により判定された場合には、前記イベントを発生させたアカウントに対応する端末利用者に対して、前記制限操作を実行するための権限の取得に必要とされる認証を行うように要求する認証要求手順と、
前記イベントを発生させたアカウントに対応する端末利用者が、前記認証要求手順により要求された認証に成功した場合には、前記アカウント認証記録記憶部に記憶されている認証記録の内、前記イベントを発生させたアカウントに対応する認証記録を更新するとともに、前記制限操作の実行を所定の有効期限内で許可する権限許可手順と
をコンピュータに実行させる権限設定プログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2008/073716 WO2010073364A1 (ja) | 2008-12-26 | 2008-12-26 | 情報処理装置、権限設定方法および権限設定プログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2008/073716 WO2010073364A1 (ja) | 2008-12-26 | 2008-12-26 | 情報処理装置、権限設定方法および権限設定プログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2010073364A1 true WO2010073364A1 (ja) | 2010-07-01 |
Family
ID=42287032
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2008/073716 WO2010073364A1 (ja) | 2008-12-26 | 2008-12-26 | 情報処理装置、権限設定方法および権限設定プログラム |
Country Status (1)
Country | Link |
---|---|
WO (1) | WO2010073364A1 (ja) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012155365A (ja) * | 2011-01-21 | 2012-08-16 | Canon Marketing Japan Inc | 情報処理装置とその処理方法及びプログラム |
JP2015007893A (ja) * | 2013-06-25 | 2015-01-15 | キヤノン株式会社 | 画像処理装置及びその認証方法、並びにプログラム |
JP2015144026A (ja) * | 2011-08-02 | 2015-08-06 | クアルコム,インコーポレイテッド | デバイスにおけるセキュリティ強化のために多要素パスワードまたは動的パスワードを使うための方法および装置 |
JPWO2017013713A1 (ja) * | 2015-07-17 | 2017-11-02 | 三菱電機株式会社 | 機器管理装置、機器管理方法およびプログラム |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0916523A (ja) * | 1995-06-30 | 1997-01-17 | Fujitsu Ltd | セキュリティチェックシステム |
JPH0935030A (ja) * | 1995-07-14 | 1997-02-07 | Dainippon Printing Co Ltd | 携帯用情報記憶媒体 |
JP2007156959A (ja) * | 2005-12-07 | 2007-06-21 | Fuji Xerox Co Ltd | アクセス制御プログラムおよび情報処理装置およびアクセス制御方法 |
JP2008257492A (ja) * | 2007-04-05 | 2008-10-23 | Fuji Xerox Co Ltd | 認証処理プログラム、情報処理プログラム、認証処理装置、認証処理システムおよび情報処理システム |
-
2008
- 2008-12-26 WO PCT/JP2008/073716 patent/WO2010073364A1/ja active Application Filing
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0916523A (ja) * | 1995-06-30 | 1997-01-17 | Fujitsu Ltd | セキュリティチェックシステム |
JPH0935030A (ja) * | 1995-07-14 | 1997-02-07 | Dainippon Printing Co Ltd | 携帯用情報記憶媒体 |
JP2007156959A (ja) * | 2005-12-07 | 2007-06-21 | Fuji Xerox Co Ltd | アクセス制御プログラムおよび情報処理装置およびアクセス制御方法 |
JP2008257492A (ja) * | 2007-04-05 | 2008-10-23 | Fuji Xerox Co Ltd | 認証処理プログラム、情報処理プログラム、認証処理装置、認証処理システムおよび情報処理システム |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012155365A (ja) * | 2011-01-21 | 2012-08-16 | Canon Marketing Japan Inc | 情報処理装置とその処理方法及びプログラム |
JP2015144026A (ja) * | 2011-08-02 | 2015-08-06 | クアルコム,インコーポレイテッド | デバイスにおけるセキュリティ強化のために多要素パスワードまたは動的パスワードを使うための方法および装置 |
US9892245B2 (en) | 2011-08-02 | 2018-02-13 | Qualcomm Incorporated | Method and apparatus for using a multi-factor password or a dynamic password for enhanced security on a device |
JP2015007893A (ja) * | 2013-06-25 | 2015-01-15 | キヤノン株式会社 | 画像処理装置及びその認証方法、並びにプログラム |
JPWO2017013713A1 (ja) * | 2015-07-17 | 2017-11-02 | 三菱電機株式会社 | 機器管理装置、機器管理方法およびプログラム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5593327B2 (ja) | あるユーザに成り代わるための方法およびシステム | |
US8438400B2 (en) | Multiple user desktop graphical identification and authentication | |
US7496952B2 (en) | Methods for authenticating a user's credentials against multiple sets of credentials | |
US7257835B2 (en) | Securely authorizing the performance of actions | |
US7845003B2 (en) | Techniques for variable security access information | |
US8079069B2 (en) | Cardspace history validator | |
JP5125187B2 (ja) | 認証処理プログラム、情報処理プログラム、認証処理装置、認証処理システムおよび情報処理システム | |
JP2008527574A (ja) | 共用アカウントを用いる許可ベースのアクセスのためのシステムおよび方法 | |
WO2019103945A1 (en) | Protecting against malicious discovery of account existence | |
US20090320117A1 (en) | Remote sign-out of web based service sessions | |
EP1787214A2 (en) | Multiple user desktop system | |
US8903360B2 (en) | Mobile device validation | |
EP4084401A1 (en) | Method and apparatus for securely managing computer process access to network resources through delegated system credentials | |
US20090254982A1 (en) | Methods, programs and a system of providing remote access | |
JP4738183B2 (ja) | アクセス制御装置及びアクセス制御方法及びプログラム | |
CN110826086A (zh) | 跨租户授权方法、装置、计算机设备及存储介质 | |
WO2010073364A1 (ja) | 情報処理装置、権限設定方法および権限設定プログラム | |
JP4387856B2 (ja) | コンピュータロック管理プログラム、コンピュータロック管理方法およびコンピュータロック管理装置 | |
JP2006119719A (ja) | コンピュータシステム及びユーザ認証方法 | |
CN110301127B (zh) | 用于预测性令牌验证的装置和方法 | |
US20190325412A1 (en) | Maintaining Secure Access to a Self-Service Terminal (SST) | |
US20070079116A1 (en) | Method, system and computer program product for access control | |
JP4358830B2 (ja) | 外部接続機器を用いたコンピュータの制御方法及びコンピュータの制御システム | |
JP2006065712A (ja) | 統合認証方法、統合認証装置および統合認証のためのプログラム | |
JP2002222171A (ja) | 情報処理セキュリティシステム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 08879160 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 08879160 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: JP |