WO2010073364A1 - 情報処理装置、権限設定方法および権限設定プログラム - Google Patents

情報処理装置、権限設定方法および権限設定プログラム Download PDF

Info

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
Application number
PCT/JP2008/073716
Other languages
English (en)
French (fr)
Inventor
廣志 吉田
拓路 齊藤
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to PCT/JP2008/073716 priority Critical patent/WO2010073364A1/ja
Publication of WO2010073364A1 publication Critical patent/WO2010073364A1/ja

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

　管理モジュール群は、イベントを発生させたアカウントに対応する端末利用者が、制限操作を実行するだけの権限を有しない場合には、認証・権限ＤＢ内の情報を参照し、制限操作の実行に必要な認証を行うように要求する。管理モジュール群は、認証装置により取得された認証情報を受け付けると、受け付けた認証情報から認証の成否判断を行い、認証成功である場合には、アカウント認証記録ＤＢに記憶されている認証記録の内、イベントを発生させたアカウントに対応する認証記録について更新する。さらに、管理モジュール群は、制限操作に対応した機能の起動を所定の有効期限内で許可することを決定し、ＯＳ（Operating　System）やアプリケーションに操作を許可する旨の許可メッセージを返す。

Description

情報処理装置、権限設定方法および権限設定プログラム
　この発明は、情報処理装置、権限設定方法および権限設定プログラムに関する。
　従来、端末や端末の接続されているネットワークのセキュリティを高く保つために、オペレーティングシステムやアプリケーションにアカウント権限による起動制限をかける仕組みが存在する。具体的には、権限の範囲により管理者アカウントと利用者アカウントを用意しておき、オペレーティングシステムやアプリケーションを起動して、管理者権限の必要な作業を行う場合に、管理者アカウントを利用することで高いセキュリティ性を保っている。
　上述してきたような仕組みにおいて、管理者アカウントと利用者アカウントで与えられるアクセス権限に違いがあるにも関わらず、認証強度が同一であるという問題があった。この問題に対処するため、例えば、特許文献１では、アクセス権限に応じて複数の認証装置を利用した認証を行うように認証強度を変更する技術が提案されている。
特開２００７－１５６９５９号公報
　しかしながら、上記した特許文献１に提案の技術には、アカウントと権限とをセットで管理することを原因として、システムのセキュリティレベルを低下させる、アカウント管理が煩雑になる、端末利用者の利便性に優れたものとはいえないという問題点がある。
　具体的には、利用者アカウントで操作している途中に、管理者権限が必要になった場合に、今使用しているアカウントとは別の名前の管理者アカウントに切り替える必要がある。このため、アカウント切り替えを怠り、常に管理者アカウントを使用する端末使用者が発生する。このようなことから、システムのセキュリティレベルを低下させる可能性がある。
　また、複数の端末使用者間で管理者アカウントを共有して使用する場合が発生するので、端末使用者とアカウントとを１対１で対応させて管理することが難しく、結果として、端末のログからどの端末使用者が操作したのか分からない。さらには、アカウントの数が必然的に端末使用者より多くなる。このようなことから、アカウント管理が煩雑になることが予想される。
　また、複数の認証装置のどれか一つでも故障した場合は、認証が行えないアカウントが発生する場合が考えられる。さらには、管理者アカウントでログオン中の時は、操作自体に強力な権限を必要としない場合でも、管理者権限に応じた認証強度の煩雑な認証手順を要求される。このようなことから、端末利用者の利便性に優れたものとはいえない。
　そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、高いセキュリティレベルを保ちつつ、アカウント管理に優れるとともに、端末利用者の利便性にも優れたアカウント権限の動的な設定が可能な情報処理装置、権限設定方法および権限設定プログラムを提供することを目的とする。
　上述した課題を解決し、目的を達成するため、開示の装置は、端末利用者ごとに割り当てられているアカウントに対応付けて、当該アカウントの認証記録を記憶するアカウント認証記録記憶部と、端末利用者が各操作を実行するための権限の取得に必要とされる認証方法を記憶する権限／認証情報記憶部と、端末利用者の権限が制限されている制限操作の実行を要求するイベントの発生を検知した場合に、当該イベントを発生させたアカウントに対応する認証記録を前記アカウント認証記録記憶部から取得するとともに、前記制限操作を実行するための権限の取得に必要とされる認証方法を前記権限／認証情報記憶部から取得して、前記アカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有するか否かを判定する権限判定部と、前記イベントを発生させたアカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有していないと前記権限判定部により判定された場合には、前記イベントを発生させたアカウントに対応する端末利用者に対して、前記制限操作を実行するための権限の取得に必要な認証を行うように要求する認証要求部と、前記イベントを発生させたアカウントに対応する端末利用者が、前記認証要求部により要求された認証に成功した場合には、前記アカウント認証記録記憶部に記憶されている認証記録の内、前記イベントを発生させたアカウントに対応する認証記録を更新するとともに、前記制限操作の実行を所定の有効期限内で許可する権限許可部とを有する。
　開示の装置によれば、高いセキュリティレベルを保ちつつ、アカウント管理に優れるとともに、端末利用者の利便性にも優れたアカウント権限の動的な設定が可能である。
図１は、実施例１に係る端末装置を説明するための図である。 図２は、実施例１に係る端末装置の構成を示す図である。 図３は、実施例１に係る認証・権限ＤＢの構成例を示す図である。 図４は、実施例１に係る認証管理モジュール部の動作を説明するための図である。 図５は、実施例１に係る端末装置の処理の流れを示す図である。 図６は、実施例１による効果を説明するための図である。 図７は、権限設定プログラムを実行するコンピュータを示す図である。
符号の説明
　１００　入力部
　２００　出力部
　３００　認証装置群
　４００　端末装置
　４１０　ＤＢ群
　４１１　アカウント認証記録ＤＢ
　４１２　認証・権限ＤＢ
　４２０　管理モジュール群
　４２１　設定モジュール部
　４２２　アカウント管理モジュール部
　４２３　権限管理モジュール部
　４２４　認証管理モジュール部
　５００　コンピュータ
　５１０　入力部
　５２０　出力部
　５３０　認証装置群
　５４０　ＨＤＤ（Hard　Disk　Drive）
　５４１　権限設定プログラム
　５４２　権限設定用データ
　５５０　ＲＡＭ（Random　Access　Memory）
　５５１　権限設定プロセス
　５６０　ＣＰＵ（Central　Processing　Unit）
　６００　バス
　以下に、情報処理装置、権限設定方法および権限設定プログラムの一実施形態を詳細に説明する。なお、以下では、情報処理装置の一例として、いわゆるパーソナルコンピュータなどの端末装置を取り上げて説明する。
　実施例１に係る端末装置の骨子は、端末利用者が、権限を有しない操作を実行しようとする場合に、権限に応じて予め設定された認証を行うように端末利用者に要求して、端末利用者が認証に成功した場合には、端末利用者に有効期限を付した操作権限を与える点にある。
　図１を参照しつつ、具体的に説明する。図１は、実施例１に係る端末装置を説明するための図である。同図に示すように、実施例１に係る端末装置は、例えば、クライアント用ソフトウェアがインストールされ、指紋センサや静脈センサ等の認証装置に接続されている。
　端末利用者は、認証装置を用いた認証方法と、この認証方法による認証に成功した場合に取得可能な権限の対応関係を認証・権限ＤＢに事前に登録する（図１の（１）参照）。なお、同図に示すように、認証方法と権限との対応関係の登録には、例えば、クライアント用ソフトウェアの提供する設定画面を利用する。
　なお、アカウント認証記録ＤＢには、端末利用者ごとに割り当てられているアカウントに対応付けて、アカウントの認証記録を記憶している。また、認証・権限ＤＢは、端末利用者が各操作を実行するための権限の取得に必要とされる認証方法を記憶している。
　そして、実施例１に係る端末装置の管理モジュール群は、ＯＳ（Operating　System）やアプリケーションで発生するイベントを監視する。端末利用者の権限が制限されている（起動制限のある）制限操作の実行を要求するイベントを検知すると（図１の（２）参照）、管理モジュール群は、イベントを発生させたアカウントの情報を取得し、取得されたアカウントに対応する認証記録をアカウント認証記録ＤＢから取得するとともに、制限操作を実行するための権限の取得に必要とされる認証方法を認証・権限ＤＢから取得する。そして、管理モジュール群は、アカウント認証記録ＤＢおよび認証・権限ＤＢの各々から取得した情報を参照して、イベントを発生させたアカウントに対応する端末利用者が制限操作を実行するだけの権限を有するか否かを確認する（図１の（３）参照）。
　管理モジュール群は、確認の結果、イベントを発生させたアカウントに対応する端末利用者が、制限操作を実行するだけの権限を有しない場合には、認証・権限ＤＢ内の情報を参照し、制限操作の実行に必要な認証を行うように要求する（図１の（４）参照）。なお、同図に示すように、認証の要求には、例えば、クライアント用ソフトウェアの提供する認証画面を利用する。
　管理モジュール群は、認証装置により取得された認証情報を受け付けると（図１の（５）参照）、受け付けた認証情報から認証の成否判断を行う。そして、管理モジュール群は、認証成功である場合には、アカウント認証記録ＤＢに記憶されている認証記録の内、イベントを発生させたアカウントに対応する認証記録について更新する（図１の（６）参照）。さらに、管理モジュール群は、制限操作に対応した機能の起動を所定の有効期限内で許可することを決定し、ＯＳ（Operating　System）やアプリケーションに操作の許可する旨の許可メッセージを返す（図１の（７）参照）。
　このようなことから、実施例１に係る端末装置は、高いセキュリティレベルを保ちつつ、アカウント管理に優れるとともに、端末利用者の利便性にも優れたアカウント権限を動的に設定できる。
［端末装置の構成（実施例１）］
　図２は、実施例１に係る端末装置の構成を示す図である。実施例１に係る端末装置４００は、入力部１００、出力部２００および認証装置群３００に接続される。
　入力部１００は、キーボードやマウス、マイクなどを備えて構成され、例えば、端末利用者から、認証方法と権限との対応関係の登録情報などの各種情報の入力を受け付ける。なお、出力部２００がモニタで構成される場合には、マウスと協働してポインティングディバイス機能を実現する。また、出力部２００は、モニタ（若しくはディスプレイ、タッチパネル）やスピーカを備えて構成され、端末利用者に対して要求する認証方法の情報などの各種の情報を表示出力する。
　認証装置群３００は、端末利用者が各種認証を実行するための装置群であり、例えば、指紋センサ、静脈センサ、ＩＣカードやＴＰＭ（Trusted　Platform　Module：セキュリティチップ）などを有する。
　また、図２に示すように、端末装置４００は、ＤＢ群４１０および管理モジュール群４２０を有する。
　ＤＢ群４１０は、管理モジュール群４２０による各種処理に必要なデータおよびプログラムを記憶し、特に、アカウント認証記録ＤＢ４１１および認証・権限ＤＢ４１２を有する。
　なお、アカウント認証記録ＤＢ４１１は、特許請求の範囲に記載の「アカウント認証記録記憶部」ともいう。認証・権限ＤＢ４１２は、特許請求の範囲の記載の「権限／認証情報記憶部」ともいう。
　アカウント認証記録ＤＢ４１１は、端末利用者ごとに割り当てられているアカウントに対応付けて、アカウントの認証記録を時系列に記憶している。例えば、あるアカウントに対応する端末利用者が、ＩＣカードおよび指紋の認証に成功したことがログとして記憶され、蓄積されている。
　認証・権限ＤＢ４１２は、例えば、図３に示すように、端末利用者がＲｅａｄ（読込み）、Ｅｘｅｃｕｔｅ（実行）、Ｗｒｉｔｅ（書き込み）などの各制限操作を実行するための権限の取得に必要とされる認証方法を記憶している。具体的には、認証方法の列の右矢印（→）は、左辺の認証を行った後に右辺の認証を行うことを意味する。また、認証方法の列のプラス記号（＋）は、左辺と右辺の認証を順序に関係なく行うことを意味する。権限の列に示した「○」と「×」は、各権限の有無を表す。
　例えば、ＩＤ１～ＩＤ３は、指紋でログオンしたアカウントが、次にＩＣカードで認証を行った場合に、ＩＣカードの権限により獲得する権限が異なることを示した例である。ＩＤ１～ＩＤ３に示す例では、全てのアカウントがログオン直後は平等にＲｅａｄ（読込み）の権限を持ち、その後の認証の成功により平等に権限獲得を行うことが出来ることを示している。
　また、ＩＤ４およびＩＤ５は、認証と権限の組み合わせの自由度を示した例である。上記のＩＤ１～ＩＤ３に示す例では、Ｗｒｉｔｅ（書き込み）の権限を獲得するために必要であった管理者権限のＩＣカードを、ＩＣカード単体の認証では権限を全く得られないように設定した。これにより、１枚のＩＣカードの盗難で、全ての端末・ネットワークが操作されてしまうことを防止できる。
　また、ＩＤ６およびＩＤ７は、認証の組み合わせと順序を認証に加味した複合認証の例である。ＩＤ６およびＩＤ７に示す例では、一般権限のＩＣカードでの認証に成功した後に、管理者権限のＩＣカードでの認証に成功した場合には全ての権限を得られるが、管理者権限のＩＣカードで認証に成功した後に、一般権限のＩＣカードで認証した場合はＷｒｉｔｅ（書き込み）の権限を獲得することが出来ないことを表している。認証の順序を考慮することにより、従来よりも高いセキュリティを実現可能である。なお、図３は、実施例１に係る認証・権限ＤＢの構成例を示す図である。
　また、図２に示すように、管理モジュール群４２０は、アカウント権限の動的な設定を行うための種々の処理を実行し、特に、設定モジュール部４２１、アカウント管理モジュール部４２２、権限管理モジュール部４２３および認証管理モジュール部４２４を有する。
　なお、アカウント管理モジュール部４２２および権限管理モジュール部４２３は、特許請求の範囲に記載の「権限判定部」ともいう。また、権限管理モジュール部４２３および認証管理モジュール部４２４は、特許請求の範囲に記載の「認証要求部」ともいう。また、アカウント管理モジュール部４２２、権限管理モジュール部４２３および認証管理モジュール部４２４は、特許請求の範囲に記載の「権限許可部」ともいう。
　設定モジュール部４２１は、出力部２００を介して、クライアントソフトウェアの設定変更を行うためのＧＵＩ（Graphical　User　Interface）を端末利用者に提供する。また、入力部１００を介して受け付けた端末利用者からの入力に応じて、アカウント管理モジュール部４２２の動作ポリシの設定・変更、権限管理モジュール部４２３における権限の有効期限を示すパラメータ等の設定・変更、および認証・権限ＤＢ４１２の設定・変更等を行う。
　アカウント管理モジュール部４２２は、システム内に常駐し、ＯＳ（Operating　System）やアプリケーションで発生するイベントを監視する。アカウント管理モジュール部４２２は、権限の必要なイベントの発生を検知した場合には、権限管理モジュール部４２３を起動する。
　具体的に説明すると、アカウント管理モジュール部４２２は、端末利用者の権限が制限されている（起動制限のある）制限操作の実行を要求するイベントを検知した場合には、権限管理モジュール部４２３を起動して、イベントを発生させたアカウントの権限を確認させる。そして、アカウント管理モジュール部４２２は、権限管理モジュール部４２３から、権限「有」のメッセージを受けた場合には、ＯＳ（Operating　System）やアプリケーションに対して、制限操作を許可する旨のメッセージを返す。一方、アカウント管理モジュール部４２２は、権限管理モジュール部４２３から、権限「無」のメッセージを受けた場合には、ＯＳ（Operating　System）やアプリケーションに対して、制限操作を許可しない旨のメッセージを返す。
　権限管理モジュール部４２３は、アカウント管理モジュール部４２２により起動されると、イベントを発生させたアカウントの権限確認等を行う。
　具体的に説明すると、権限管理モジュール部４２３は、アカウント管理モジュール部４２２により起動されると、イベントを発生させたアカウントを取得して、取得されたアカウントに対応する認証記録をアカウント認証記録ＤＢ４１１から取得する。
　さらに、権限管理モジュール部４２３は、制限操作を実行するための権限の取得に必要とされる認証方法を認証・権限ＤＢ４１２から取得する。そして、権限管理モジュール部４２３は、アカウント認証記録ＤＢ４１１および認証・権限ＤＢ４１２の各々から取得した情報を参照して、イベントを発生させたアカウントに対応する端末利用者が制限操作を実行するだけの権限を有するか否かを確認する。
　なお、確認を実行する際、権限管理モジュール部４２３は、アカウント認証記録ＤＢ４１１から取得した認証記録と、認証・権限ＤＢ４１２から主得した認証方法および権限の対応関係とに基づいて、イベントを発生させたアカウントに対応する端末利用者が、権限の取得に必要な認証に全て成功しているか否かを確認する。イベントを発生させたアカウントに対応する端末利用者が、権限の取得に必要な認証に全て成功している場合には、権限管理モジュール部４２３は、さらに、権限が有効期限内にあるか否かを確認する。そして、権限管理モジュール部４２３は、イベントを発生させたアカウントに対応する端末利用者の権限が、有効期限内にあることが確認できた場合には、端末利用者が制限操作を実行するだけの権限を有するものと判定する。
　権限管理モジュール部４２３は、確認の結果、イベントを発生させたアカウントに対応する端末利用者が、制限操作を実行するだけの権限を有しない場合には、認証管理モジュール部４２４を起動して、制限操作の実行に必要な認証を端末利用者に行わせるように要求する。認証管理モジュール部４２４を起動後、権限管理モジュール部４２３は、制限操作の実行に必要な認証の認証方法を認証管理モジュール部４２４に送る。
　そして、権限管理モジュール部４２３は、認証管理モジュール部４２４から認証に成功した旨の認証結果を受けると、認証結果を用いて、イベントを発生させたアカウントに対応するアカウント認証記録ＤＢ４１１内の認証記録を更新する。認証記録の更新後、権限管理モジュール部４２３は、権限「有」のメッセージをアカウント管理モジュール部４２２に返す。一方、権限管理モジュール部４２３は、認証管理モジュール部４２４から認証に失敗した旨の認証結果を受けると、権限「無」のメッセージをアカウント管理モジュール部４２２に返す。
　また、権限管理モジュール部４２３は、端末利用者が制限操作を実行するだけの権限を有するか否かを確認した結果、イベントを発生させたアカウントに対応する端末利用者が、制限操作を実行するだけの権限を有する場合には、権限「有」のメッセージをアカウント管理モジュール部４２２に返す。
　認証管理モジュール部４２４は、権限管理モジュール部４２３により起動されると、出力部２００を介して、制限操作を実行するための権限の取得に必要とされる認証を端末利用者に要求する。そして、端末利用者からの認証データに基づいて、認証の成否を判断し、認証結果を権限管理モジュール部４２３に返す。
　具体的に説明すると、認証管理モジュール部４２４は、図４に示すように、権限管理モジュール部４２３により起動されると、権限管理モジュール部４２３から受けた認証方法を解釈する。そして、認証管理モジュール部４２４は、出力部２００を介して、解釈した認証方法に対応する認証を端末利用者に要求する。そして、認証管理モジュール部４２４は、認証装置群３００から端末利用者の認証データを受け付けると、対応する認証エンジンを起動し、認証データに基づいて認証の成否を判定する。
　認証に成功した場合には、認証に成功した旨のメッセージを権限管理モジュール部４２３に返す。一方、認証に失敗した場合には、認証に失敗した旨のメッセージを権限管理モジュール部４２３に返す。なお、図４は、実施例１に係る認証管理モジュール部の動作を説明するための図である。
　例えば、認証管理モジュール部４２４は、あるアカウントを「指紋認証かつＩＣカード認証（指紋＋ＩＣカード）」の認証方法で認証するように要求がきた場合は、指紋認証とＩＣカード認証の両方に成功した場合に、認証に成功した旨のメッセージを返す。同様に、「指紋認証またはＩＣカード認証」の認証方法で認証するように要求がきた場合は、片方の認証に成功すれば、認証に成功した旨のメッセージを返す。また、「指紋認証に成功してからＩＣカード認証に成功する（指紋→ＩＣカード）」という認証方法ならば、その順番どおりに認証し、両方に合格した場合に、認証に成功した旨のメッセージを返す。
　また、認証データに欠けがあるなどして、認証データが正確に得られなかった場合は、認証管理モジュールは端末利用者に再度認証を要求する。規定した最大回数の認証に失敗した場合は、その旨をエラーコードで権限管理モジュール部４２３に返信する。アカウント登録無し、認証手順登録無し、認証データ登録無しなどの場合に関しては、その旨をエラーコードで権限管理モジュール部４２３に知らせる。この場合、端末利用者に知らせるかどうかは、設定したセキュリティレベルによって制御する。
［端末装置の処理（実施例１）］
　図５は、実施例１に係る端末装置の処理の流れを示す図である。同図に示すように、アカウント管理モジュール部４２２は、ＯＳ（Operating　System）やアプリケーションで発生するイベントを検知すると（ステップＳ１）、端末利用者の権限が制限されている（起動制限のある）制限操作の実行を要求するイベントであるか否かを判定する（ステップＳ２）。アカウント管理モジュール部４２２は、判定の結果、端末利用者の権限が制限されている（起動制限のある）制限操作の実行を要求するイベントではない場合には（ステップＳ２否定）、操作を許可する旨のメッセージをＯＳ（Operating　System）やアプリケーションに返す。
　一方、アカウント管理モジュール部４２２は、判定の結果、端末利用者の権限が制限されている（起動制限のある）制限操作の実行を要求するイベントである場合には（ステップＳ２肯定）、権限管理モジュール部４２３を起動して（ステップＳ３）、イベントを発生させたアカウントの権限を確認させる。
　権限管理モジュール部４２３は、アカウント管理モジュール部４２２により起動されると、イベントを発生させたアカウントを取得して（ステップＳ４）、取得されたアカウントに対応する認証記録をアカウント認証記録ＤＢ４１１から取得する。さらに、権限管理モジュール部４２３は、制限操作を実行するための権限の取得に必要とされる認証方法を認証・権限ＤＢ４１２から取得する。そして、権限管理モジュール部４２３は、アカウント認証記録ＤＢ４１１および認証・権限ＤＢ４１２の各々から取得した情報を参照して、イベントを発生させたアカウントに対応する端末利用者が制限操作を実行するだけの権限を有するか否かを確認する（ステップＳ５）。
　権限管理モジュール部４２３は、確認の結果、イベントを発生させたアカウントに対応する端末利用者が、制限操作を実行するだけの権限を有しない場合には（ステップＳ５否定）、認証管理モジュール部４２４を起動して（ステップＳ６）、制限操作の実行に必要な認証を端末利用者に行わせるように要求する。
　認証管理モジュール部４２４は、権限管理モジュール部４２３により起動されると、権限管理モジュール部４２３から受けた認証手順（認証方法）を解釈する。そして、認証管理モジュール部４２４は、出力部２００を介して、解釈した認証手順（認証方法）に対応する認証を端末利用者に要求する（ステップＳ７）。そして、認証管理モジュール部４２４は、認証装置群から端末利用者の認証データを受け付けると、対応する認証エンジンを起動し、認証データに基づいて認証の成否を判定し、認証結果を権限管理モジュール部４２３に返す（ステップＳ８）。
　そして、権限管理モジュール部４２３は、認証管理モジュール部４２４から認証結果として受けたメッセージが認証に成功した旨のメッセージであるか否かを確認する（ステップＳ９）。確認の結果、認証に成功した旨のメッセージである場合には（ステップＳ９肯定）、権限管理モジュール部４２３は、認証結果を用いて、イベントを発生させたアカウントに対応するアカウント認証記録ＤＢ４１１内の認証記録を更新する（ステップＳ１０）。認証記録の更新後、権限管理モジュール部４２３は、権限「有」のメッセージをアカウント管理モジュール部４２２に返す（ステップＳ１１）。
　ここで、ステップＳ９の説明に戻ると、権限管理モジュール部４２３は、認証管理モジュール部４２４から認証結果として受けたメッセージが認証に失敗した旨のメッセージである場合には（ステップＳ９否定）、権限「無」のメッセージをアカウント管理モジュール部４２２に返す（ステップＳ１２）。
　ここで、ステップＳ５の説明に戻ると、権限管理モジュール部４２３は、確認の結果、イベントを発生させたアカウントに対応する端末利用者が、制限操作を実行するだけの権限を有する場合には（ステップＳ５肯定）、上述したステップＳ１１と同様に、権限「有」のメッセージをアカウント管理モジュール部４２２に返す。
　アカウント管理モジュール部４２２は、権限管理モジュール部４２３から受けたメッセージが権限「有」のメッセージであるか否かを確認する（ステップＳ１３）。確認の結果、権限管理モジュール部４２３から受けたメッセージが権限「有」のメッセージである場合には（ステップＳ１３肯定）、アカウント管理モジュール部４２２は、ＯＳ（Operating　System）やアプリケーションに対して、制限操作を許可する旨のメッセージを返す（ステップＳ１４）。一方、権限「無」のメッセージである場合には（ステップＳ１３否定）、アカウント管理モジュール部４２２は、ＯＳ（Operating　System）やアプリケーションに対して、制限操作を許可しない旨のメッセージを返す（ステップＳ１５）。
　なお、上述してきた端末装置４００による処理は、装置起動中において繰り返し実行される。
［実施例１による効果］
　上述してきたように、実施例１によれば、端末利用者が、権限を有しない操作を実行しようとする場合に、権限に応じて予め設定された認証を行うように端末利用者に要求する。そして、端末利用者が認証に成功した場合には、端末利用者に有効期限を付した操作権限を与える。
　このようなことから、実施例１によれば、高いセキュリティレベルを保ちつつ、アカウント管理に優れるとともに、端末利用者の利便性にも優れたアカウント権限の動的な設定を実現できる。
　すなわち、実施例１によれば、端末利用者が、一般権限のアカウントで操作している途中に、管理者権限が必要になった場合に、今使用しているアカウントとは別の名前の管理者アカウントに切り替える必要がない。このため、アカウント切り替えを怠り、常に管理者アカウントを使用する端末使用者が発生することもない。このようなことから、システムのセキュリティレベルを低下させる可能性はなくなり、高いセキュリティレベルを保つことができる。
　また、実施例１によれば、複数の端末使用者間で管理者アカウントを共有して使用する場合が発生せず、端末使用者とアカウントとを１対１で対応させて管理することも容易である。さらには、アカウントの数が必然的に端末使用者より多くなることはない。このようなことから、アカウント管理が煩雑になることがなく、アカウント管理に優れる。
　また、実施例１によれば、認証方法と権限との対応関係を複数用意しておくことで、複数の認証装置のどれか一つでも故障した場合であっても、認証が行えないアカウントの発生を防止できる。さらには、実施例１によれば、権限に応じた認証を要求するので、操作自体に強力な権限を必要としない場合には、煩雑な認証を要求されることはない。また、有効期限内で権限を付与するので、アカウント権限の放棄も自動的に行われる。このようなことから、端末利用者の利便性にも優れる。
　また、図６を用いて、従来技術と実施例１の技術との比較について説明する。従来方法と本発明のログオン時の手順を比較したものである。運用シーンとしては、従業員は全て利用者アカウントで業務を行う企業で、ＩＴ管理者が従業員の端末の設定変更を行う状況を想定している。なお、利用者アカウント（一般権限のアカウント）へのログオンにはＩＣカード認証が、管理者アカウントへログオンするには指紋認証とＩＣカード認証が必要であるとする。このシーンでは、以下の３つの点で実施例１の技術が優れている。
　１点目（図６の（１）参照）は、本発明ではログオフが不要である点で優れている。すなわち、従業員は利用者アカウントでログオン中であるため、従来技術ではログオフが必要であった。実施例１の技術では全てのアカウントで管理者権限を利用することが可能であるため、管理者権限のために一度ログオフする手順が不要である。
　２点目（図６の（２）参照）は、事前に認証した方式を記録するため、最低限の認証で管理者権限を取得可能である点で優れている。すなわち、従来の方法では、管理者アカウントでログオンするためには指紋認証とＩＣカード認証を行う必要がある。実施例１の技術では、ログオン中のアカウントが権限を要求する場合、必要な権限を得るのに不足している認証のみを行うため、ログオン時に行っているＩＣカード認証を行う必要が無い。
　３点目（図６の（３）参照）は、管理者アカウントが不要である点で優れている。すなわち、通常利用している利用者アカウントに管理者権限を設定することが可能なため、管理者権限を扱うためのアカウントが不要である。これによりアカウントと利用者の一対一の関係を作ることができるため、操作ログやアカウント管理の面で従来技術よりも優れている。
　以下に、情報処理装置、情報処理方法および情報処理プログラムの他の実施形態を説明する。
（１）装置構成等
　上記の実施例１において、図２を用いて説明した端末装置４００の各構成要素は機能概念的なものであり、必ずしも物理的に同図に示すようにして構成されていることを要しない。すなわち、端末装置４００の分散・統合の具体的形態は同図に示すものに限られず、例えば、権限管理モジュール部４２３と認証管理モジュール部４２４とを統合する。このように、端末装置４００の各構成要素の全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、端末装置４００にて行なわれる各処理機能（例えば、図５参照）は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
（２）権限設定プログラム
　ところで、上記の実施例１で説明した各種の処理（例えば、図５参照）は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、上記の実施例１と同様の機能を有する機能設定プログラムを実行するコンピュータの一例を説明する。図７は、権限設定プログラムを実行するコンピュータを示す図である。
　同図に示すように、コンピュータ５００は、入力部５１０、出力部５２０、認証装置群５３０、ＨＤＤ５４０、ＲＡＭ５５０およびＣＰＵ５６０をバス６００で接続して構成される。
　ここで、入力部５１０は、ユーザから各種データの入力を受け付ける。出力部５２０は、各種情報を表示する。認証装置群５３０は、ユーザの認証データを取得する。ＨＤＤ５４０は、ＣＰＵ５６０による各種処理の実行に必要な情報を記憶する。ＲＡＭ５５０は、各種情報を一時的に記憶する。ＣＰＵ５６０は、各種演算処理を実行する。
　そして、ＨＤＤ５４０には、図７に示すように、上記の実施例１に示した端末装置４００の管理モジュール群４２０と同様の機能を発揮する権限設定プログラム５４１と、権限設定用データ５４２とがあらかじめ記憶されている。なお、この権限設定プログラム５４１を適宜分散させて、ネットワークを介して通信可能に接続された他のコンピュータの記憶部に記憶させておくこともできる。
　そして、ＣＰＵ５６０が、この権限設定プログラム５４１をＨＤＤ５４０から読み出してＲＡＭ５５０に展開することにより、図７に示すように、権限設定プログラム５４１は、権限設定プロセス５５１として機能するようになる。すなわち、権限設定プロセス５５１は、権限設定用データ５４２等をＨＤＤ５４０から読み出して、ＲＡＭ５５０において自身に割り当てられた領域に展開し、この展開したデータ等に基づいて各種処理を実行する。なお、権限設定プロセス５５１は、図２に示した端末装置４００の管理モジュール群４２０（設定モジュール部４２１、アカウント管理モジュール部４２２、権限管理モジュール部４２３および認証管理モジュール部４２４）等において実行される処理に対応する。
　なお、上記した権限設定プログラム５４１については、必ずしも最初からＨＤＤ５４０に記憶させておく必要はない。例えば、コンピュータ５００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ－ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」、さらには、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ５００に接続される「他のコンピュータ（またはサーバ）」などに各プログラムを記憶させておき、コンピュータ５００がこれらから各プログラムを読み出して実行するようにしてもよい。
（３）権限設定方法
　上記の実施例１で説明した端末装置４００により、以下のような権限設定方法が実現される。
　すなわち、端末利用者の権限が制限されている制限操作の実行を要求するイベントの発生を検知した場合に、端末利用者ごとに割り当てられているアカウントに対応付けて、当該アカウントの認証記録を記憶するアカウント認証記録記憶部から、前記イベントを発生させたアカウントに対応する認証記録を取得するとともに、制限操作を実行するための権限の取得に必要とされる認証方法を記憶する権限／認証情報記憶部から、制限操作を実行するための権限の取得に必要とされる認証方法を取得して、イベントを発生させたアカウントに対応する端末利用者が制限操作を実行するだけの権限を有するか否かを判定する権限判定ステップ（例えば、図５のステップＳ１～ステップＳ５参照）と、イベントを発生させたアカウントに対応する端末利用者が制限操作を実行するだけの権限を有していないと権限判定ステップにより判定された場合には、イベントを発生されたアカウントに対応する端末利用者に対して、制限操作を実行するための権限の取得に必要な認証を行うように要求する認証要求ステップと（例えば、図５のステップＳ５～ステップＳ７参照）、イベントを発生させたアカウントに対応する端末利用者が、認証要求ステップにより要求された認証に成功した場合には、アカウント認証記録記憶部に記憶されている認証記録の内、イベントを発生させたアカウントに対応する認証記録を更新するとともに、制限操作の実行を所定の有効期限内で許可する権限許可ステップと（例えば、図５のステップＳ８～ステップＳ１４参照）を含んだ権限設定方法が実現される。

Claims (5)

  1. 　端末利用者ごとに割り当てられているアカウントに対応付けて、当該アカウントの認証記録を記憶するアカウント認証記録記憶部と、
    　端末利用者が各操作を実行するための権限の取得に必要とされる認証方法を記憶する権限／認証情報記憶部と、
    　端末利用者の権限が制限されている制限操作の実行を要求するイベントの発生を検知した場合に、当該イベントを発生させたアカウントに対応する認証記録を前記アカウント認証記録記憶部から取得するとともに、前記制限操作を実行するための権限の取得に必要とされる認証方法を前記権限／認証情報記憶部から取得して、前記アカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有するか否かを判定する権限判定部と、
    　前記イベントを発生させたアカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有していないと前記権限判定部により判定された場合には、前記イベントを発生させたアカウントに対応する端末利用者に対して、前記制限操作を実行するための権限の取得に必要な認証を行うように要求する認証要求部と、
    　前記イベントを発生させたアカウントに対応する端末利用者が、前記認証要求部により要求された認証に成功した場合には、前記アカウント認証記録記憶部に記憶されている認証記録の内、前記イベントを発生させたアカウントに対応する認証記録を更新するとともに、前記制限操作の実行を所定の有効期限内で許可する権限許可部と
    　を有する情報処理装置。
  2. 　前記権限判定部は、端末利用者の操作に伴うイベントの発生を検知するごとに、当該イベントを発生させたアカウントに対応する認証記録を前記アカウント認証記録記憶部から取得するとともに、前記制限操作を実行するための権限の取得に必要とされる認証方法を前記権限／認証情報記憶部から取得して、前記アカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有するか否かを判定するが、前記アカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有する場合には、当該権限が所定の有効期限内にあるか否かをさらに判定し、
    　前記認証要求部は、前記アカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有するが、当該権限が所定の有効期限内にないと前記権限判定部により判定された場合には、前記イベントを発生させたアカウントに対応する端末利用者に対して、前記制限操作を実行するための権限の取得に必要な認証を行うように要求する請求項１に記載の情報処理装置。
  3. 　前記権限／認証情報記憶部は、複数の認証方式の組合せおよび／または複数の認証方式の実行順序を認証方法として記憶する請求項１または２に記載の情報処理装置。
  4. 　端末利用者の権限が制限されている制限操作の実行を要求するイベントの発生を検知した場合に、端末利用者ごとに割り当てられているアカウントに対応付けて、当該アカウントの認証記録を記憶するアカウント認証記録記憶部から、前記イベントを発生させたアカウントに対応する認証記録を取得するとともに、前記制限操作を実行するための権限の取得に必要とされる認証方法を記憶する権限／認証情報記憶部から、前記制限操作を実行するための権限の取得に必要とされる認証方法を取得して、前記アカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有するか否かを判定する権限判定ステップと、
    　前記イベントを発生させたアカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有していないと前記権限判定ステップにより判定された場合には、前記イベントを発生されたアカウントに対応する端末利用者に対して、前記制限操作を実行するための権限の取得に必要な認証を行うように要求する認証要求ステップと、
    　前記イベントを発生させたアカウントに対応する端末利用者が、前記認証要求ステップにより要求された認証に成功した場合には、前記アカウント認証記録記憶部に記憶されている認証記録の内、前記イベントを発生させたアカウントに対応する認証記録を更新するとともに、前記制限操作の実行を所定の有効期限内で許可する権限許可ステップと
    　を含む権限設定方法。
  5. 　端末利用者の権限が制限されている制限操作に対応した機能の起動を要求するイベントの発生を検知した場合に、端末利用者ごとに割り当てられているアカウントに対応付けて、当該アカウントの認証記録を記憶するアカウント認証記録記憶部から、前記イベントを発生させたアカウントに対応する認証記録を取得するとともに、前記制限操作を実行するための権限の取得に必要とされる認証方法を記憶する権限／認証情報記憶部から、前記制限操作に対応する機能の起動に必要とされる権限を取得して、前記アカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有するか否かを判定する権限判定手順と、
    　前記イベントを発生させたアカウントに対応する端末利用者が前記制限操作を実行するだけの権限を有していないと前記権限判定手順により判定された場合には、前記イベントを発生させたアカウントに対応する端末利用者に対して、前記制限操作を実行するための権限の取得に必要とされる認証を行うように要求する認証要求手順と、
    　前記イベントを発生させたアカウントに対応する端末利用者が、前記認証要求手順により要求された認証に成功した場合には、前記アカウント認証記録記憶部に記憶されている認証記録の内、前記イベントを発生させたアカウントに対応する認証記録を更新するとともに、前記制限操作の実行を所定の有効期限内で許可する権限許可手順と
    　をコンピュータに実行させる権限設定プログラム。
PCT/JP2008/073716 2008-12-26 2008-12-26 情報処理装置、権限設定方法および権限設定プログラム WO2010073364A1 (ja)

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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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 認証処理プログラム、情報処理プログラム、認証処理装置、認証処理システムおよび情報処理システム

Patent Citations (4)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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