JP2006085643A - Authority information generating method, communication apparatus, program, and recording medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To manage and set authentication information and authority information of each user related to both access role management functions even when an access role management function not using SNMPv3 and an access control function using SNMPv3 coexist. Etc. can be easily performed.
An access management table, which is authority information managed by a network device other than SNMPv3, and a USM table and a VACM table, which are authority information used for control using SNMPv3 from the information in the access management table. The conversion rule for generation is stored, the access management table is read at startup (S11), and the USM table and the VACM table are generated from the information on the access management table based on the conversion rule. (S12).
[Selection] FIG.

Description

  The present invention relates to an authority information generation method for generating authority information used for controlling a communication device using SNMP (Simple Network Management Protocol), a communication device capable of being controlled by SNMP, and a computer. The present invention relates to a program for executing the authority information generating method as described above or causing a computer to function as the communication device as described above, and a computer-readable recording medium recording such a program.

  2. Description of the Related Art Conventionally, communication apparatuses capable of communication via a network are adapted to support SNMP, which is a network device management protocol. Examples of such communication devices include office equipment such as printers and digital multi-function peripherals. A device that supports this SNMP can refer to or change settings from an external device via a network by using a management tool called an SNMP manager.

As such SNMP, v1 (version 1), v2 (version 2) and v3 (version 3) are known. Since v1 and v2 do not have the concept of a user and do not support data encryption, it is difficult to satisfy advanced requirements regarding authentication and security.
Patent Document 1 discloses that when SNMPv1 is used, identification information attached to a command is encrypted and transmitted / received, and whether or not the command can be executed is determined based on a match / mismatch of the identification information. Are listed. In this way, the security can be improved as compared with the case of normal SNMPv1, but even with such a method, since SNMPv1 without the concept of a user is used, the access authority for each user is set. It was difficult to do.
JP 2003-122650 A

On the other hand, in SNMPv3, a user authentication model (User-based Security Model: USM) and an access control model (View-based Access Control Model: VACM) can be used as a part of security functions. By using it, user authentication and access control for each user are possible.
This point will be described with reference to the conceptual diagram of FIG.
As an example, as shown in FIG. 20, a description will be given of a case in which a network device 201 compatible with SNMPv3 is accessed using the SNMPv3 from the terminal device 202 and the terminal device 203 connected to the network device 201 via the network 204. To do.

  First, in the network device 201, the MIB (Management Information Base) information, which is information that can be accessed using SNMP, is a range that can be accessed only by an administrator (A), in particular, a range in which access is not restricted (anyone can access). (B) etc. can be defined. In addition, for each user ID, whether or not to perform authentication and communication encryption can be determined. Here, authentication and encryption are set for the administrator ID, and authentication and encryption are not set for the guest ID.

When such a setting is made, the user A having the administrator ID transmits an SNMP request whose contents are encrypted to the network device 201, and when the user A is authenticated by the password, Both the stored MIBs (A) and (B) can be acquired. However, in the case of the user B who accesses with the guest ID, only the information (B) can be acquired although the SNMP request encryption and password authentication are unnecessary.
As described above, in SNMPv3, a range in which access to the MIB information is permitted can be determined according to the user. In FIG. 20, the acquisition of information is shown as an example, but the same access control can be performed for changing information.
Details of such SNMP are described in RFCs (Request For Comment) 2570 to 2575 issued by the Internet Engineering Task Force (IETF).

  By the way, in recent years, in a communication apparatus having various functions such as a digital multi-function peripheral, a user is registered and a right to use the function is defined for each user, and each user is allowed to use the apparatus only within the scope of the authority. To be done. Such a function is called an access role management function, and in order to realize such a function, a function related to user authentication and setting of usage authority for each user is provided in the communication device. ing. Such a function has been used before a device corresponding to SNMPv3 appeared, and has been realized using a protocol different from SNMPv3.

  On the other hand, when the device is compatible with SNMPv3, as described above, the range of information permitted to be accessed can be set for each user by using USM and VACM. There was a request to be able to realize a function similar to the access role management function using.

However, in addition to conventional access role management that does not use SNMPv3, if access role management is also performed in SNMPv3, it is necessary to manage user authentication information and authority information for use in these two types of access role management, respectively. Will occur. In this case, it is difficult to know which user is allowed to use which function as the entire apparatus, and user authentication information is separately obtained using conventional access role management and SNMPv3. There is also a problem that setting authority information is troublesome.
The present invention solves such problems, and even when an access role management function that does not use SNMPv3 and an access control function that uses SNMPv3 coexist in one communication device, both access role managements It is an object of the present invention to easily manage and set authentication information and authority information of each user related to a function.

  In order to achieve the above object, an authority information generation method of the present invention is an authority information generation method for generating authority information used for control using SNMPv3, and is managed by a device having a data processing function other than SNMPv3. Storing the first authority information that is the authority information, and the conversion rule for converting the first authority information into the second authority information that is the authority information used for the control using the SNMPv3, The user name included in the first authority information and the authority information corresponding to the user name are converted according to the conversion rule to generate the second authority information.

In such an authority information generation method, the first authority information may include information indicating whether the authority is permitted for a plurality of authorities for each user.
Further, the second authority information generated according to the conversion rule is defined in the VACM table as an authority group indicating authority of contents corresponding to all kinds of authorities defined in the first authority information. It is good to have it.

Alternatively, the conversion rule may include a definition of a correspondence relationship between an item of information in the first authority information and an item in the second authority information generated based on the information of the item. .
Further, the conversion rule may include a provision that the information of the item of vacmGroupName in the second authority information is defined based on the authority information in the first authority information, and may further be defined by the authority information. Each of the contents of authority may include a definition of information to be set in the item of vacmGroupName for a user who has authority of the contents.

In each of the authority information generation methods described above, the device having the data processing function is a device having a function of controlling itself using SNMPv3, and the device stores the first stored in the device at startup. The second authority information may be generated from the authority information, and the generated second authority information may be used for own control.
Furthermore, the first and second authority information may include authentication information for authenticating the user.

  The communication apparatus of the present invention also includes first authority information that is authority information managed by other than SNMPv3, and second authority that is authority information that uses the first authority information for control using SNMPv3. Storage means for storing a conversion rule for conversion into information, a user name included in the first authority information, and authority information corresponding to the user name are converted according to the conversion rule and the second It is a communication apparatus having conversion means for generating authority information.

In such a communication apparatus, the first authority information may include information indicating whether or not the authority is permitted for a plurality of authorities for each user.
Further, the second authority information generated by the conversion means is defined in the VACM table as an authority group indicating authority of contents corresponding to all kinds of authorities defined in the first authority information. It is good to have it.

Further, the conversion means may be means for generating the second authority information when the communication device is activated, and the generated second authority information may be used for its own control using SNMPv3.
Furthermore, the first and second authority information may include authentication information for authenticating the user.

  Further, the communication device of the present invention is authority information managed by a device other than SNMPv3 in a communication device having a function of controlling its own operation by SNMPv3. First authority information including information that determines whether or not the authority is permitted and second authority information that is authority information used for control using SNMPv3 are stored, and the second authority information is stored. However, in the VACM table, it is assumed that an authority group indicating authorities of contents corresponding to all kinds of authorities defined in the first authority information is defined.

  The program of the present invention is a program for causing a computer to generate authority information used for control using SNMPv3. In the program, the computer has first authority information that is authority information managed by other than SNMPv3; A procedure for storing a conversion rule for converting the first authority information into second authority information that is authority information used for control using the SNMPv3, and a user name included in the first authority information And a procedure for converting the user name and the corresponding authority information according to the conversion rule to generate the second authority information.

In such a program, the first authority information may include information indicating whether or not the authority is permitted for a plurality of authorities for each user.
Further, the second authority information generated according to the conversion rule is defined in the VACM table as an authority group indicating authority of contents corresponding to all kinds of authorities defined in the first authority information. It is good to have it.

Alternatively, the conversion rule may include a definition of a correspondence relationship between an item of information in the first authority information and an item in the second authority information generated based on the information of the item. .
Further, the conversion rule includes a provision that the information of the item of vacmGroupName in the second authority information is defined based on the authority information in the first authority information, and is further defined by the authority information. Each of the contents of authority to be obtained may include a definition of information to be set in the item of vacmGroupName for a user having authority of the contents.
In each of the above programs, the computer generates the second authority information from the function of controlling the communication device using SNMPv3 and the first authority information stored by itself when the computer is started. A program for realizing the function of using the generated second authority information for controlling the communication device may be further included.

  Further, the program of the present invention provides first authority information that is authority information for managing a computer other than SNMPv3, and second authority information that is used for control using SNMPv3. A storage means for storing a conversion rule for converting to the authority information, a user name included in the first authority information, and authority information corresponding to the user name are converted according to the conversion rule and It is a program for functioning as conversion means for generating second authority information.

In such a program, the first authority information may include information indicating whether or not the authority is permitted for a plurality of authorities for each user.
Furthermore, the second authority information generated by the conversion means is an authority group indicating authority of contents corresponding to all kinds of authorities defined by the authority information in the first authority information in the VACM table. It should be defined.

Further, the converting means is a means for generating the second authority information when the computer is started up, and the computer has a function of using the generated second authority information for controlling a communication device using SNMPv3. It is advisable to further include a program for realizing it.
In each of the above programs, the first and second authority information may include authentication information for authenticating the user.
The recording medium of the present invention is a computer-readable recording medium on which the above program is recorded.

According to the authority information generation method or communication device of the present invention as described above, it is a case where an access role management function that does not use SNMPv3 and an access role management function that uses SNMPv3 coexist in one communication device. In addition, it is possible to easily manage and set the authentication information and authority information of each user related to both access role management functions.
Further, according to the program of the present invention, it is possible to cause the computer to execute the above-described authority information generation method or to cause the computer to function as the above-described communication device to realize the characteristics thereof and obtain the same effect.
According to the recording medium of the present invention, the above effect can be obtained by causing a computer not storing the above program to read and execute the program.

The best mode for carrying out the present invention will be described below with reference to the drawings.
First, a configuration of a network device that is an embodiment of a communication device according to the present invention and is an example of a device that executes the authority information generation method according to the present invention will be described. FIG. 1 is a block diagram showing the configuration of the network device together with a PC (personal computer) that can access the network device.
A network device 10 shown in FIG. 1 is a digital multi-function peripheral which is an image processing apparatus having various functions such as copying, printers, scanners, and facsimile communications, and includes a CPU 11, ROM 12, RAM 13, NVRAM (nonvolatile memory) 14, An HDD (hard disk drive) 15, a network I / F 16, and an engine unit 17 are provided.

The CPU 11 is a control unit that performs overall control of the network device 10, and functions as each unit such as a conversion unit by executing various programs recorded in the ROM 12, the NVRAM 14, or the HDD 15. Various functions related to the feature of the form are realized.
The ROM 12 is a nonvolatile storage unit, and stores programs executed by the CPU 11, fixed parameters, and the like. The ROM 12 may be configured as a rewritable storage means so that these data can be updated.

The RAM 13 is storage means for storing temporarily used data or used as a work memory for the CPU 11. A storage area for information that is dynamically generated, such as SNMPv3 access management information described later, is also prepared in the RAM 13.
The NVRAM 14 is a rewritable nonvolatile storage means such as a flash memory, and stores a program executed by the CPU 11, a parameter value that needs to be retained even after the apparatus is turned off, and the like.
The HDD 15 is also a rewritable storage unit that stores programs executed by the CPU 11 and parameter values that need to be retained even after the apparatus is turned off. Further, the HDD 15 stores data that has a relatively large capacity or is frequently rewritten.

  The network interface (I / F) 16 is an interface for connecting the network device 10 to the network 30, for example, an interface for performing Ethernet (registered trademark) communication. And when communicating with another apparatus via the network 30, this network I / F16 and CPU11 function as a communication means. Note that various types of networks 30 can be used regardless of whether they are wired or wireless, and an appropriate network I / F 16 is prepared according to the standard of the network 30, the communication protocol used, and the like. It is also possible to provide a plurality of network I / Fs 16 corresponding to a plurality of standards.

  The engine unit 17 is an image forming unit, an image reading unit, a facsimile communication unit, and the like. Various operations such as copying, printing, scanning, and facsimile communication are performed on the network device 10 by the CPU 11 appropriately controlling these operations. Can be executed. Since this part is not so much related to the feature of this embodiment, the illustration is kept simple.

  Here, the network device 10 as described above can communicate with the PC 20 that is an external terminal device via the network 30. The network device 10 is compatible with SNMP as will be described later, and it is possible to refer to or change the set parameter values by accessing the PC 20 using various clients.

Next, FIG. 2 shows a functional configuration of a part related to the feature of this embodiment in the network device 10.
As shown in FIG. 2, the network device 10 includes a function management unit 110, a security management unit 120, a device access management unit 130, a network management unit 140, a setting function unit 150, a device access management information storage unit 160, and SNMPv3 access management. And an SNMP information storage unit 180. Note that the arrows connecting these units in FIG. 2 indicate that data can be exchanged, and do not indicate physical components such as a bus.

FIG. 3 shows the types of information stored in the device access management information storage unit 160, the SNMPv3 access management information storage unit 170, and the SNMP information storage unit 180, and the functional units that access them.
First, the function of a storage unit that stores information among the units illustrated in FIG. 2 will be described with reference to FIG.

  First, the device access management information storage unit 160 includes first information including a user name of each user, a password that is authentication information for authenticating each user, and authority information that defines a function use authority for each user. The device access management information, which is the authority information of, is stored. Such information is stored in a table format here, and this table is called an “access management table”. In the access management table, functions that are not handled by SNMPv3, such as execution of print, copy, FAX transmission, etc., together with authority information related to functions handled by SNMPv3, such as access to setting data managed as MIB information The authority information related to is also described, and these are managed collectively. Such a device access management information storage unit 160 may be provided in the NVRAM 14 or the HDD 15 as hardware.

  Next, the SNMPv3 access management information storage unit 170 stores a USM table and a VACM table as SNMPv3 access management information, which is second authority information used for access role control using SNMPv3. Details of the information stored in these tables will be described later. The contents of information stored in the table are dynamically generated from the contents of the access management table according to a conversion rule described later. Such an SNMPv3 access management information storage unit 170 is a storage unit that stores information that is dynamically generated, and therefore may be provided in the RAM 13 as hardware.

  The SNMP information storage unit 180 stores information to be set statically among information used for processing related to SNMP. As such information, for example, community (Community), trap (TRAP), or lower protocol information (Protocol) used for communication can be considered. Such an SNMP information storage unit 180 may be provided in the RAM 13 as hardware.

Next, among the units illustrated in FIG. 2, portions other than the storage units described above will be described.
The function management unit 110 has a function of grasping the types of functions that can be provided to the user for the entire network device 10 and managing items to be set in providing the functions. It also has a function of setting and referring to information related to these functions. In this function, for example, when a new function is added, for example, when a new application is added to the network device 10 and a FAX function is added, an area for setting availability of the function in the access management table The function of providing
The security management unit 120 has a function of managing the overall security of the network device 10. Also, it has a function of managing the security level and prompting a security check in accordance with the security level set for each management unit 110-140.

The device access management unit 130 has a function of registering / deleting a user, granting / revoking authority to each user, and the like by managing an access management table stored in the device access management information storage unit 160. . In addition, when a user tries to use a function that is subject to authority management among the functions of the network device 10 by means other than SNMP, the user is authenticated by a user ID, a password, etc. and used by the user. It also has a function of performing access role management that determines whether or not it can be used depending on whether or not it has authority.
Note that the usage authority managed by the device access management unit 130 includes authority related to functions not handled by SNMPv3, such as execution of printing, copying, and FAX transmission. Further, management of the access management table and determination of availability are performed by a method that does not use SNMPv3. For example, a method unique to the manufacturer that developed the network device 10 or a method that complies with a standard other than SNMPv3 is conceivable.

  The network management unit 140 has a function for managing and controlling the network I / F 16 and a protocol used for communication via the network I / F 16, and communication and authentication by the SNMP daemon 141 which is a program for performing communication using SNMP. Functions such as authority management are also functions of the network management unit 140. The SNMP daemon 141 is compatible with any of SNMPv1 to v3, and when an SNMP request is received, processing corresponding to an appropriate version can be performed according to the contents of the packet.

The SNMP daemon 141 in the network management unit 140 has a conversion function unit 142. The conversion function unit 142 converts the contents of the access management table according to a predetermined conversion rule when the network device 10 is activated. , Has a function of conversion means for generating a USM table and a VACM table. Also, the conversion function unit 142 generates a USM table and a VACM table in the same manner even when the contents of the access management table are changed, and reflects the latest contents of the access management table in these tables. Yes.
The SNMP daemon also has a function of referring to or changing settings in the SNMP information storage unit 180.

  The setting function unit 150 has a function of performing settings related to a network, and performs a setting according to a setting instruction received from an external device by telnet or the like in addition to a setting instruction from the operation unit of the network device 10. Have However, as shown in FIG. 3, only information stored in the SNMP information storage unit 180 can be changed from the setting function unit 150 (other than the network management unit 140) regarding information related to SNMP.

With the function of each unit as described above, the network device 10 can be used for each user registered in the network device 10 (including not only human beings but also devices having a function of automatically accessing the network device 10, etc.). When the authentication information for authenticating the user and the authority information that defines the authority to use each function for the user are centrally managed by the access management table, and each user uses the function using this information Allow / deny.
Also, by generating a USM table or VACM table used by SNMP from information in the access management table, authentication and authority management processing using SNMPv3 is performed according to the setting contents in the access management table managed by a method other than SNMPv3. It can be performed. This is the main feature of this embodiment.
Then, next, the process which produces | generates a USM table and a VACM table from the information of an access management table is demonstrated using the specific example which simplified the content.

First, FIG. 4 shows the relationship between these tables.
As described above, the access management table 161 stored in the device access management information storage unit 160 stores authentication information 162 such as a user name and password and authority information 163 in association with each other.
On the other hand, the SNMPv3 access management information storage unit 170 stores the USM table 171 and the VACM table 172 as information for performing authentication and authority management by SNMPv3 as described above. The contents of the USM table 171 are mainly generated based on the authentication information 162, and the contents of the VACM table 172 are mainly generated based on the authority information 163. The arrows in FIG. 4 indicate such a relationship.

Next, FIG. 5 shows an example of information stored in the access management table 161.
As shown in this figure, in the access management table, an authentication password used when the user is authenticated by the network device 10 in association with the user name (user ID), and when the user encrypts the SNMP packet The encryption password used for the password, the authority information indicating the contents of the authority permitted by the user, and the like are stored.

Among these, the authentication password is a password that is used in common in authentication processing other than SNMPv3 and authentication processing using SNMPv3, but the encryption password is a password used only in SNMPv3.
The encryption password is used to generate a key (key information based on it) for encrypting the SNMPv3 packet. If the encrypted and transferred packet can be decrypted with the key generated based on the same password, it is determined that the transmission source of the packet is the user (or device) who knows the correct encryption password. it can. Therefore, in this sense, it can be said that the encryption password is also a password used for authentication.

Next, a specific example of the contents of the access management table 161 is shown in FIG. This example is an example in which information related to five users A to E is described in the access management table, but the content of the uppermost row with an underline in the figure indicates which information in each column. It is a title to make it easy to understand whether it is related to the user, and is not included in the actual table.
As is apparent from FIG. 6, in the access management table, as described with reference to FIG. 5, an authentication password and an encryption password are stored as authentication information for each user in association with the user name. However, depending on the user, an authentication password or an encryption password may not be set. In this case, information indicating that there is no corresponding password is stored.

  As for authority information, for each user, information indicating whether the authority is permitted for a plurality of authorities is stored. In this example, the authority for setting A and setting B is provided as authority regarding the setting of MIB information using SNMP. For example, setting A is authority to perform network-related settings such as address and communication protocol, and setting B is It is possible to set the authority to perform settings related to device management such as system reboot and paper type to be used. Then, the authority of the setting A is permitted to the users B, D, and E, and the authority of the setting B is permitted to the users C, D, and E. Similarly, the authority of reference A and reference B is provided as authority regarding the reference of MIB information using SNMP, and permission permission / non-permission information of authority is stored for each user.

  In the example given here, the authority information on the access management table related to the access role management using SNMP is only the above four items, but information indicating permission / non-permission of authority regarding use of other functions. Are also memorized together. For example, authority such as function use A, function use B, and the like. All of these rights may be set to allow / deny independently for each user, but due to reasons such as the usage of the network device 10 and the characteristics of the rights, there is a limit to the number of people who can grant a certain right at the same time. It is conceivable to provide or limit the range of authority that one user can have.

The first authority information can be defined by the access management table as described above. Then, the device access management unit 130 permits each user to use the network device 10 only within the scope of the authority of the user by a method other than SNMPv3 based on the information stored in the access management table. Access role management is performed.
Further, as described above, the function of the conversion function unit 142 realized by the program prepared in the SNMP daemon 141 allows the management of access roles by SNMPv3 based on the information in the access management table as shown in FIG. The USM table and VACM table to be used can be generated.

  Here, before explaining such a USM table and VACM generation method, the contents of these tables and the use of data described therein will be described using specific examples. Note that the USM table and the VACM table are data expressed as MIB trees, and the format itself conforms to the contents specified in RFCs 2574 and 2575 that define the SNMP standard. However, this embodiment is characterized by the contents of information stored in these tables and the generation process thereof.

  First, FIG. 7 shows an example of a USM table generated by the conversion function unit 142 from the information shown in FIG. In this figure, only a part of the data that is actually expressed as a MIB tree is related to the features of this embodiment, and information other than that shown here is described in the table. Of course it is possible. The underlined element is a heading for indicating what the data in the column is, and does not indicate the data actually stored in the table. These points are the same for FIG. 8 described later.

The USM table is composed of information below snmpUsmMIB in the MIB tree, and important information includes usmUserTable, which is further lower than usmUser, which is lower than usmMIBObject, which is lower than snmpUsmMIB.
FIG. 7 shows this part, and the user name information is stored in the items of usmUserName and usmUserSecurityName for each user as lower-level information of the usmUserTable (more precisely, lower-level of the lower-level usmUserEntry). I have to. Here, for user A to user E, the same user name as the user name on the access management table is stored. Here, the same information is stored in the fields of usmUserName and usmUserSecurityName, but this is the reason for the specification of the USM table.

  In the authKey item, information corresponding to an authentication password used for authentication by SNMPv3 is stored. However, SNMPv3 uses a key generated based on the password, not the password itself, by hashing it with an algorithm such as MD5 (Message Digest 5) or SHA-1 (Secure Hash Algorithm 1). This data is also stored in the privKey field because hash data is also used when generating a key from a password. Actually, the character string is random as shown in FIG. 7, but the length shown in FIG. 7 is different from the actual length. “-” Indicates that there is no corresponding data.

The privKey item stores a key for decrypting the encrypted SNMPv3 packet. This key corresponds to the encryption password, and is the data obtained by further hashing the key generated based on the password, as in the case of the authentication password.
Note that these authKey and privKey information can be retrieved from the SNMP daemon 141 using the usmUserSecurityName information as a key, but are stored in a location other than the MIB tree in consideration of security. Therefore, strictly speaking, it is not a part of the USM table. This means that the frame of these items is indicated by a broken line in the figure.

  The usmUserAuthProtocol item stores information indicating whether or not the corresponding user performs authentication processing and the hash processing method used for the authentication. The usmUserPrivProtocol item stores information indicating that the user Information indicating whether or not to encrypt the current packet and the encryption method used for the encryption is stored.

Next, FIG. 8 shows an example of a VACM table generated by the conversion function unit 142 from the information shown in FIG.
The VACM table is composed of information below the snmpVacmMIB in the MIB tree. Important information includes the vacmSecurityToGroupTable and the vacmAccessTable, which are further lower than the vacmMIBObjects lower than the snmpVacmMIB.
FIG. 8 shows this portion. First, as the information of the lower level of the vacmSecurityToGroupTable (more precisely, the lower level of the lower level vacmSecurityToGroupTableEntry), the user name information is stored in the vacmSecurityName item for each user. , And vacmGroupName, the name of the authority group corresponding to the authority of the user is stored.

  The vacmAccessTable portion is a portion that stores information on each authority group described in the vacmGroupName item. Then, in the vacmAccessSecurityLevel item at the lower level of the vacmAccessTable (more precisely, the lower level of the lower vacmAccessEntry), information indicating whether or not to perform password authentication and packet encryption for users belonging to the corresponding authority group is displayed as vacmAccessReadViewName. In the item of, information indicating the type of View (view) that defines the range for which reference access is permitted for the same user, and in the item of vacmAccessWriteViewName, information indicating the type of View that also defines the range for which setting access is permitted, Each is memorized.

Next, an authentication and authority management processing procedure performed using information stored in the USM table and the VACM table described above when an SNMP request is received will be described.
First, FIG. 9 shows the structure of an SNMPv3 packet.
When an external device transmits an SNMP request to the network device 10, as shown in FIG. 9, the content is described as the text of the SNMP message, and the header and the data to be used by the security model are added thereto. And send it. When packet encryption is performed, the message body is encrypted and transmitted using the key generated based on the encryption password as described above.

  The data used by the security model includes various types of data as shown in FIG. 9, and among these, data generated mainly based on the user name (msgUserName), the authentication password (msgAuthentificationParameters), and packet encryption The access role management process is performed using information (msgPrivacyParameters) indicating whether or not the conversion is performed. In the latter two items, NULL is stored when the corresponding password is not used (authentication or encryption is not performed), and this is indicated. Further, when packet encryption is performed, information called salt is stored in msgPrivacyParameters.

Here, FIG. 10 shows an example of a password input screen in the SNMP client that generates the SNMP request.
The user can transmit an SNMP request to the network device 10 by executing a program called an SNMP client in a terminal device such as the PC 20, specifying a necessary item, and instructing transmission of the SNMP request. At this time, the SNMP client displays a password input screen 60 as shown in FIG. 10 and requests the user to input a user name, an authentication password, and an encryption password.

  When the user inputs necessary items in the input fields 61 to 63 and presses the OK key, the above-mentioned “data used by the security model” is generated based on the input information, and the SNMP including this is generated. A request is generated and transmitted to the network device 10. Note that the password input here may be the same password before conversion as that registered in the access management table. The fields other than the user name may be blank, but in this case, it is handled that there is no corresponding password.

  Next, FIG. 11 shows an outline of an access role management processing procedure performed using the “data used by the security model”. This figure shows processing after the network device 10 receives an SNMPv3 packet and determines that the packet received from the header information should be handled by SNMPv3. This process is performed by a function provided by the SNMP daemon 141.

  As shown in FIG. 11, when the network device 10 handles an SNMP packet by SNMPv3, first, by referring to the usmUserTable and its related information in the USM table, the information of usmUserAuthProtocol and usmUserPrivProtocol corresponding to the user name in the received message is obtained. Acquire and perform authentication and decryption processing according to the contents. The authentication information on the network device 10 side necessary for this processing is acquired from the privKey and authKey items for the user (S1). Then, when necessary authentication and decryption processing is successful, the processing proceeds to the following processing. If it fails, treat it as an error at this point.

  If the user is registered in the network device 10, an SNMP packet describing his / her user name should be transmitted. For example, the user B shown in FIG. 7 or the like is “UserB”, and the user D is “UserD”. If the user name in the received message is not registered in the USM table, authentication fails. Further, when it is determined that authentication and / or decryption processing is unnecessary, even if a value is described in msgAuthentificationParameters or msgPrivacyParameters on the packet side, it may be ignored.

  If step S1 ends without any problem, next, information on the vacmSecurityToGroupTable in the VACM table is referenced, and information on the authority group name corresponding to the user name in the received message is acquired from the item of vacmGroupName (S2). In the case of the above-mentioned user B, “netAdmin” corresponding to “userB” and “netmacAdmin” corresponding to user D are obtained.

  When the authority group name can be acquired, the vacmAccessTable in the VACM table is referred to, and the view information corresponding to the authority group name acquired in step S2 is acquired from the vacmAccessReadViewName and vacmAccessWriteViewName items (S3). For example, since user B corresponds to “netAdmin”, ReadView is “ALL” and WriteView is “netView”. Since the user D corresponds to “netmacAdmin”, ReadView is “ALL” and WriteView is “netmacView”. At this time, the information of the vacmAccessSecurityLevel of the corresponding group is referred to, and if the type of authentication described here is not performed in step S1, error processing is performed assuming that the authentication is insufficient.

  On the other hand, if the view name can be acquired in step S3, the vacmViewTreeFamilyTable that defines the range of information permitted to be accessed for each view is referred to, and the range where access can be permitted is grasped based on the acquired view information (S4). ). In the vacmViewTreeFamilyTable, for example, all ranges of the MIB tree corresponding to the “ALL” view, ranges that allow setting access to users with the authority of setting A corresponding to “netView”, and “netmacView” A range in which setting access is permitted to a user who has both the settings A and B authority is set. Then, depending on whether or not the range requested for access by the request described in the received packet is within the range grasped in step S4, it is possible to determine whether or not to permit the operation related to the request. it can. Although not shown in FIG. 8, the vacmViewTreeFamilyTable is information located below the snmpVacmMIB in the MIB tree, and in this sense, it can be said to be a part of the VACM table.

Next, processing for generating a USM table as shown in FIG. 7 and a VACM table as shown in FIG. 8 based on the contents of the access management table as shown in FIG. 6 will be described.
This processing is performed when the CPU 11 of the network device 10 executes the SNMP daemon 141, and converts the user name included in the access management table and the authentication information and authority information corresponding to the user name into a predetermined conversion. The conversion is performed according to the rules.
Therefore, here, the generation process of the USM table and the VACM table will be described focusing on the contents of the conversion rule.

FIG. 12 shows the types of information in the USM table or VACM table generated from the information for each information in the access management table. This figure shows the rule based on the above conversion rule, and shows that the right column information is generated based on the left column information.
As can be seen from this figure, first, from the information of “user name” in the access management table, information on usmUserName and usmUserSecurityName in usmUserTable and information on vacmSecurityName in vacmSecurityToGroupTable are generated. For this part, a necessary storage area is prepared in the table, and the same contents as the “user name” in the access management table may be stored in the storage area.

  In addition, a code indicating the user name is used as a part of the MIB index indicating the storage position of the information regarding each user in the USM table or the VACM table. For example, the MIB index of usmUserSecurityName of the user whose user name is “UserA” is “.... usmUserSecurityName.12.0.0.1.111.2.0.116.255.254.120.28.198.5.85.115.101.114.65”, of which “85.115.101.114.65” is a code indicating “UserA”. If the user name is “UserB”, this part is “85.115.101.114.66”.

  Next, authKey information and usmUserAuthProtocol information in usmUserTable are generated from the “authentication password” information in the access management table. However, for these items, the “authentication password” information is not stored as it is. For authKey, data obtained by further hashing the key generated based on the “authentication password” is generated and stored. For usmUserAuthProtocol, usmNoAuthProtocol (no authentication processing), usmHMACSHAAuthProtocol (SHA-1 is used) based on the presence / absence of “authentication password” registration in the access management table and the hash processing method supported by the network device 10 Object values such as (authentication process) and usmHMACMD5AuthProtocol (authentication process using MD5) are generated and stored.

  Also, privKey information and usmUserPrivProtocol information in usmUserTable are generated from the “encryption password” information in the access management table. For these items, the "encryption password" information is not stored as it is. For privKey, the data generated by further hashing the key generated based on the "encryption password", that is, transmitted by the user A key for decrypting the incoming SNMP request is generated and stored. For usmUserPrivProtocol, usmNoPrivProtocol (no encryption processing) and usmDESPrivProtocol (DES (Data Encryption Standard) are set based on the presence / absence of “authentication password” registration in the access management table and the encryption method supported by the network device 10. An object value such as the encryption processing used is generated and stored.

Further, from the “authority” information in the access management table, information on vacmGroupName in vacmSecurityToGroupTable is generated. Furthermore, based on the generated vacmGroupName information, vacmAccessTable information is also generated.
Among these, as the information of vacmGroupName, in the “authority” information, for each user, refer to the authority within the range of performing access role management using SNMPv3, that is, the presence or absence of each authority relating to the setting of MIB information using SNMP. And the authority group name according to the content of the authority which the user has is memorize | stored.
In order to enable such processing, for each of the contents of authority that can be defined by the information indicating the authority within the scope of performing the access role management using SNMPv3 in the access management table, the user having the authority of the contents The definition of the authority group name that should be set in the vacmGroupName item is prepared. Note that information indicating authority outside the scope of access role management using SNMPv3 does not affect the determination of the authority group, and can be ignored here.

FIG. 13 shows a definition example of the authority group definition. In this figure, in addition to the authority group name corresponding to the authority of each content, the contents of information registered in the vacmAccessTable regarding the authority group are also shown. “Contents of authority” may be described for reference, but is not necessary information.
As described in the description of FIG. 6, in this network device 10, four types of authority of setting A, setting B, reference A, and reference B are prepared as authority within the range of authority control using SNMPv3. For each of them, the authority can be set. In FIG. 13, only five combinations are shown as examples, but the contents of authority that can be defined by combinations of the presence / absence of four kinds of authorities are 2 ⁴ = 16. Therefore, in practice, the corresponding authority group name and its contents are defined for each of these 16 patterns. Therefore, when it is possible to set the presence or absence of authority for n types of authority, 2 ⁿ authority groups are defined.

When generating the VACM table, for each user, the table shown in FIG. 13 is searched according to the contents of the authority of setting A, setting B, reference A, and reference B in the access management table and registered in vacmGroupName. Get information about the authority group name to be used. At this time, all the authority information possessed by each user may be finally prepared, and information on the authorized user may be collected for each authority type.
When a group name is registered in the VACM table for the first time, an area for storing information on the authority group is prepared in the vacmAccessTable, and information such as vacmAccessSecurityLevel, vacmAccessReadViewName, and vacmAccessWriteViewName is copied from the table shown in FIG. And register. When two or more users belong to one group, registration to the vacmAccessTable is only required once.

  When such processing is performed, in the state where the information about all users has been registered, in the VACM table, the authority of the contents corresponding to all kinds of authorities defined by the authority information in the access management table is shown. An authority group is defined. Therefore, by performing access role control using SNMPv3 based on the contents of the completed VACM table, it is possible to perform control to give each user the same authority as the definition contents in the access management table.

  In addition, since the definition of the authority group corresponding to all the authority that can be specified in the access management table is prepared, even if the authority is defined by a combination of multiple authorities in the access management table, In SNMPv3 in which one user can belong to only one authority group, it is possible to control each user to have the same authority as defined in the access management table.

  In the generation of the USM table and the VACM table according to the conversion rules as described above, the network device 10 creates and stores program codes for performing conversion on each item, and stores them in the CPU 11. To do so. However, the content of the conversion rule for each item may be stored in a table or the like, and this may be read sequentially to perform processing according to the content.

  12 and 13 used for explaining the conversion rules show definitions of information to be registered in the VACM table only within the range of the items shown in FIGS. However, it goes without saying that conversion rules and definitions for more detailed information may be included. Further, regarding the contents shown in FIG. 13, the correspondence between the authority contents and the authority groups and the contents of the vacmAccessTable for each authority group e may be defined in different tables. In addition, for a user whose authority is all “x”, a corresponding authority group may not be prepared, and such a user may not be registered in the USM table or the VACM table.

  In addition, when storing a view name in the vacmAccessReadViewName or vacmAccessWriteViewName item, it is necessary to store the contents of the view in the vacmViewTreeFamilyTable, but the definition of each view necessary for this is also stored as part of the conversion rule. Shall. For example, the netmacView range describes the range that allows setting access to users who have both the settings A and B permissions, and the netView range describes the range that allows setting access to users who have the setting B permissions. , A range in which setting access is permitted for a user having the authority of setting A as a range of macView is described.

The generation of the USM table and the VACM table as described above is first performed when the network device 10 is activated, and authentication and authority management are controlled by SNMPv3 using the generated table.
FIG. 14 shows a flowchart of this process.
The CPU 11 of the network device 10 starts the processing shown in the flowchart of FIG. 14 when the network device 10 is activated by executing a required control program. First, in step S11, the access management table is read. The read access management table can be used for authentication and authority management processing other than SNMPv3.

In step S12, based on the conversion rule as described with reference to FIGS. 12 and 13, the USM table as shown in FIGS. 7 and 8 is obtained from the information on the access management table read out in step S11. MIB information constituting the VACM table is generated. Thereafter, in step S13, communication by SNMP is started, access role management based on the MIB information on the USM table and VACM table generated in step S12 is started, and the process ends.
Since the contents of the USM table and the VACM table are dynamically generated according to the contents of the access management table, it is preferable to newly generate the contents when the device is activated. By doing so, it is possible to perform access role management processing by SNMPv3 according to the contents of the access management table from the time of startup of the device.

  Also, since the contents of the USM table and VACM table must be consistent with the contents of the access management table, the same processing as that shown in FIG. 14 is performed even when the contents of the access management table are changed. It is recommended that the USM table and the VACM table be generated again. This process corresponds to an SNMP daemon restart process. However, in this case, since the access management table has already been read, the process of step S11 is unnecessary. In addition to the access management table, if settings that affect the contents of the USM table or VACM table are changed, the same handling may be performed.

  By the way, the content change of the access management table can be instructed from the operation panel of the network device 10, for example. In addition, the network device 10 is provided with a web server function, provides a web screen including a GUI (graphical user interface) in response to a browser access from an external device such as the PC 20, and receives a change instruction through the GUI. May be.

An example of such a GUI is shown in FIGS.
The GUI 40 shown in this figure indicates the presence / absence of four types of authority of setting A, setting B, reference A, and reference B, which are authorities within a range of authority control using SNMPv3 for a maximum of five users A to E. It is a GUI for setting and accepting settings of a user name, an authentication password, and an encryption password used for authentication of the user. Only when a user who has the authority to change the authority information requests display and receives authentication, such request screen data is provided to the request source and displayed.

Then, in the authority setting unit 41 at the top of the screen, by setting the check box of the user who wants to grant the authority for each authority, it is possible to perform setting to give the corresponding authority to the user. . Each check box can be turned ON / OFF independently, and FIG. 15 shows an example in which the check box is turned ON to correspond to the setting contents shown in FIG.
Further, an authentication information setting unit 42 is provided for each user under the authority setting unit 41. Then, by inputting the user name to the user name input unit 43, the user name of the corresponding user can be set. As for the password, when the change button 44 is pressed, a password change screen 50 as shown in FIG. 16 is popped up, and the password to be set in the password input fields 51 and 52 is input and the OK button 53 is pressed. The password corresponding to the change button pressed on the GUI 40 can be set. When the cancel key 54 is pressed, the setting returns to the GUI 40 without setting.

Then, after the user performs the necessary settings by operating the above units, when the apply button 46 is pressed, the content is transmitted to the network device 10 and the content of the access management table is changed in the network device 10. .
When the update button 45 is pressed, the latest registration contents in the network device 10 are reflected on the GUI 40.

  By using such a GUI 40, the contents of the access control table as shown in FIG. 6 can be easily set. When the contents of the access control table are changed, the contents are reflected in the USM table and the VACM table, so that it can be said that the setting of access role management using SNMPv3 can be performed easily. . As a GUI, it is needless to say that a screen may be prepared so that the sixth and subsequent users can be added and settings relating to other authorities can be made.

  In the network device 10 as described above, information used for access role management that does not use SNMPv3 as used conventionally and information used for access role management using SNMPv3 can be managed in an integrated manner. Therefore, it is possible to easily manage and set the authentication information and authority information of each user related to both access role management functions.

  In this case, SNMPv3 has a restriction that one user can belong to only one authority group. However, by preparing the conversion rule as described above and generating the USM table and the VACM table according to the conversion rule, it is possible for one user to have a plurality of authorities in access role management without using SNMPv3. Even if a simple setting is possible, it can be easily converted into data that satisfies the SNMPv3 format requirements.

  Therefore, it is possible to set the contents of access role management by SNMPv3 while making maximum use of the conventional access role management function. In this case, if an authority group such as general in FIG. 13 that can refer to only limited information without authentication or encryption is prepared, security is improved for important information. On the other hand, it is possible to acquire information of the network device 10 using SNMP even for a printer driver or the like that does not support authentication and encryption, and to use functions such as port generation using SNMP.

[Modifications: FIGS. 17 to 20]
Next, a modification of the above-described embodiment will be described. In this modified example, when a request related to SNMPv3 is received, even if it is determined that the operation related to the request may be permitted as a result of the access role management according to the contents of the USM table or the VACM table, The only difference is that the response is returned after being changed. Therefore, this modification will be described focusing on this point.

First, FIG. 17 shows a flowchart of processing performed when the network device of this modification receives a request related to SNMPv3.
In this modified example, when the network device 10 receives an SNMPv3 request by executing the SNMP daemon, the network device 10 starts the process shown in the flowchart of FIG.

In step S21, the access authority of the request transmission source is grasped from the contents of the USM table and the VACM table. This process may be the same as the process described with reference to FIG. 11 in the above-described embodiment.
Thereafter, in step S22, it is determined whether or not the operation related to the request may be permitted based on the result of step S21. If permitted, the process proceeds to step S23. In the above-described embodiment, the operation related to the request is executed in this case, but in this modification, whether or not the content of the request is related to acquisition of information in step S23. Judge.

  If it is related to the acquisition of information, the process proceeds to step S24 to determine whether the information can be provided as it is. As the judgment criterion, a user name, an authority group name, a transmission source IP address, and the like can be considered. For a specific area of the MIB tree, conditions such as providing information only to a transmission source that satisfies a specific condition or not providing information to a transmission source that satisfies a specific condition are set in the NVRAM 14 or the like in advance. It is conceivable to keep it. For example, it is conceivable to set a condition that information related to a password and a key is permitted only to a reliable user among access-permitted users, or permitted only when accessing from a specific terminal. Then, by comparing this condition with the information obtained by the authentication and authority management process in step S21 and the information that can be acquired when the SNMP request is received, the determination in step S24 can be made.

If it is acceptable to provide it in step S24, the information requested in step S25 (here, the MIB value) is set as it is in the response area, and SNMP response processing is performed in step S27.
If it is determined that the information should not be provided in step S24, the information requested in step S26 is masked and set in the response area, and the response process is similarly performed. Here, as the mask processing, for example, a predetermined number of symbols such as “*” may be described instead of the MIB value, or “NULL” may be described.
If “NO” in the step S23, the process according to the contents of the SNMP request is performed as it is, and a response is returned. If NO in step S22, a response is returned without executing the operation related to the request.

By performing the processing as described above, in addition to the access role management using the USM table or the VACM table, finer management can be performed, and further security enhancement can be achieved.
Note that as information used for the determination in step S24, not only whether or not the MIB value may be provided, but also other processing, for example, processing that performs simple encryption on the MIB value and sets it in the response area. You may make it define the conditions to carry out. In this way, more detailed management becomes possible.

Here, the determination as in step S24 is performed only in the case of providing information, but the same determination may be performed in the case of setting information.
Furthermore, although an example in which the processing as shown in FIG. 17 is applied to the network device of the above-described embodiment has been described here, the USM table and VACM table used in step S21 are generated based on the access management table. It is not essential to be Even in a network device in which the user directly defines the contents of the USM table or VACM table, the effect of this processing can be obtained.
Two further variations of the processing shown in FIG. 17 will be described below, but these points also apply to the examples described later.

FIG. 18 shows one such variation.
In this process, step SA is inserted between step S24 and step S25 of the process shown in FIG. 17, and even if YES in step S24, if the information cannot be encrypted, the MIB value is masked. It is set in the response area. Whether encryption is possible can be determined according to whether an encryption key is included in a packet related to the received SNMP request. If such processing is performed, the MIB information to be sent over the network can always be encrypted, so that further security enhancement can be achieved.

FIG. 19 shows another variation.
In this process, step SB is inserted between step S23 and step S24 of the process shown in FIG. 18, and an SNMP request from a host that is set not to restrict the provision of information is performed in steps S24 and S24. The process proceeds to step S25 without determining SA. The determination criterion in step SB may be stored in the NVRAM 14 as in the case of the determination criterion in step S24.

Depending on the user environment, there is a request to reduce the processing load without strengthening authentication and authority checking for access from a host with careful security management. It is possible to meet such demands.
In FIG. 19, it is possible not to provide step SA.
Above, description of the modification regarding the process at the time of receiving the request which concerns on SNMPv3 is complete | finished.

  However, other than these, various modifications can be applied to the above-described embodiment. For example, the configuration of software, the communication protocol to be used, the format of data, the contents, and the like are not limited to those described in the above embodiments. In addition, it is not essential that the USM table or the VACM table is generated by the device itself that uses these tables for control, and an external processing server or the like may be used. Alternatively, the access management table may be managed by an authentication server or the like, and a USM table or a VACM table may be generated from the access management table as necessary and transferred to a network device to be used for control. . In this case, these processing servers and authentication servers are also embodiments of the communication apparatus of the present invention.

  Of course, the present invention can be applied to any communication device as long as it can be applied to other communication devices via a network. Applicable objects include, for example, general-purpose computers, network home appliances, vending machines, medical equipment, power supply devices, air conditioning systems, gas, in addition to image processing devices such as printers, fax machines, digital copiers, scanners, and digital multifunction peripherals.・ Communication devices that have a communication function in metering systems such as water and electricity, automobiles, and airplanes are conceivable.

The program according to the present invention is a program for causing a computer to function as a communication device such as the network device 10 described above. By causing the computer to execute such a program, the above-described effects can be obtained. Can do.
Such a program may be stored in a storage means such as a ROM or HDD provided in the computer from the beginning, but a non-volatile recording such as a CD-ROM or flexible disk, SRAM, EEPROM, memory card or the like as a recording medium. It can also be recorded on a medium (memory) and provided. Each procedure described above can be executed by installing a program recorded in the memory in a computer and causing the CPU to execute the program, or causing the CPU to read and execute the program from the memory.
Furthermore, it is also possible to download and execute an external device that is connected to a network and includes a recording medium that records the program, or an external device that stores the program in a storage unit.

As described above, according to the authority information generation method, communication device, program, or recording medium of the present invention, an access role management function that does not use SNMPv3 and an access role management function that uses SNMPv3 in one communication device. Can be easily managed and set for each user's authentication information and authority information related to both access role management functions.
Therefore, by utilizing the present invention, a communication device that achieves both high security and convenience can be configured.

1 is a block diagram showing a configuration of a network device, which is an embodiment of a communication device according to the present invention and is an example of a device that executes the authority information generating method of the present invention, together with a PC that can access the network device. FIG. 2 shows a functional configuration of a portion related to the feature of this embodiment in the network device shown in FIG. 1. It is a figure which shows the kind of information memorize | stored in the apparatus access management information storage part shown in FIG. 2, the SNMPv3 access management information storage part, and the SNMP information storage part, and a function part which accesses these. It is a figure which shows the relationship between the access management table, USM table, and VACM table in the network device shown in FIG. FIG. 5 is a diagram illustrating an example of information stored in an access management table illustrated in FIG. 4. It is a figure which shows the specific example of the content of the access management table. It is a figure which shows the example of the USM table produced | generated from the information shown in FIG. It is a figure which shows the example of the VACM table produced | generated from the information shown in FIG. It is a figure which shows the structure of a SNMPv3 packet. It is a figure which shows the example of the password input screen in the SNMP client which produces | generates an SNMP request.

It is a figure which shows the outline of the process sequence of the authentication and authority management performed using the information shown in FIG. 7 thru | or FIG. It is a figure which shows the kind of information in the USM table or VACM table produced | generated from the information about each information in an access management table. It is a figure which shows the example of the definition content of the authority group which concerns on the content of the authority prescribed | regulated in an access management table. It is a figure which shows a part of process which the network apparatus shown in FIG. 1 performs at the time of starting. It is a figure which shows the example of GUI for setting the content of the access management table. It is a figure which shows the example of the pop-up screen displayed by operation of the GUI. It is a flowchart which shows the example of the process which a network apparatus performs in the modification of this invention. It is a flowchart which shows the other example. It is a flowchart which shows the further another example. It is a figure for demonstrating the authentication of the user using SNMPv3, and the access control for every user.

Explanation of symbols

10, 201: network device, 11: CPU, 12: ROM, 13: RAM,
14: NVRAM, 15: HDD, 16: Network I / F, 17: Engine part,
18: System bus, 20: PC, 30, 204: Network,
110: Function management unit, 120: Security management unit, 130: Device access management unit,
140: Network management unit, 141: SNMP daemon, 142: Conversion function unit,
150: setting function unit 160: device access management information storage unit,
161: Access management table, 170: SNMPv3 access management information storage unit,
171: USM table, 172: VACM table, 180: SNMP information storage unit,
202, 203: Terminal device

Claims (25)

An authority information generation method for generating authority information used for control using SNMPv3,
For devices with data processing functions,
Conversion rules for converting first authority information, which is authority information managed by other than SNMPv3, and second authority information, which is authority information used for control using the SNMPv3, And remember
An authority information generation method, wherein the second authority information is generated by converting a user name included in the first authority information and authority information corresponding to the user name according to the conversion rule. The authority information generation method according to claim 1,
The authority information generation method, wherein the first authority information includes, for each user, information indicating whether or not the authority is permitted for a plurality of authorities. The authority information generation method according to claim 1 or 2,
The second authority information generated according to the conversion rule is defined in the VACM table in which an authority group indicating authority of contents corresponding to all kinds of authorities defined in the first authority information is defined. An authority information generation method characterized by The authority information generation method according to claim 1 or 2,
The conversion rule includes a definition of a correspondence relationship between an item of information in the first authority information and an item in the second authority information generated based on the information of the item. Authority information generation method. The authority information generation method according to claim 4,
The conversion rule includes a provision that the information of an item of vacmGroupName in the second authority information is defined based on the authority information in the first authority information, and further, authority that can be specified by the authority information An authority information generation method characterized by including a definition of information to be set in an item of vacmGroupName for a user who has authority of the contents for each of the contents. The authority information generation method according to any one of claims 1 to 5,
The device having the data processing function is a device having a function of controlling itself using SNMPv3,
The apparatus is characterized in that the second authority information is generated from the first authority information stored in the apparatus at the time of startup, and the generated second authority information is used for own control. Authority information generation method. The authority information generation method according to any one of claims 1 to 6,
The authority information generation method, wherein the first and second authority information includes authentication information for authenticating a user. First authority information that is authority information managed by other than SNMPv3, and a conversion rule for converting the first authority information into second authority information that is authority information used for control using SNMPv3; Storage means for storing
Communication comprising: a conversion means for converting the user name included in the first authority information and the authority information corresponding to the user name according to the conversion rule to generate the second authority information. apparatus. The communication device according to claim 8,
The first authority information includes information indicating whether or not the authority is permitted for a plurality of authorities for each user. The communication device according to claim 8 or 9, wherein
The second authority information generated by the conversion means is defined in the VACM table in which an authority group indicating authority of contents corresponding to all kinds of authorities defined in the first authority information is defined. A communication apparatus characterized by being. The communication device according to any one of claims 8 to 10,
The conversion means is means for generating the second authority information when the communication device is activated,
A communication apparatus characterized in that the generated second authority information is used for its own control using SNMPv3. The communication device according to any one of claims 8 to 11,
The communication apparatus, wherein the first and second authority information includes authentication information for authenticating a user. A communication device having a function of controlling its own operation by SNMPv3,
Authority information managed by other than SNMPv3, and for each user, as authority information, first authority information including information that determines whether or not the authority is permitted for a plurality of authorities;
Second authority information that is authority information used for control using SNMPv3 is stored;
In the VACM table, the second authority information is defined as an authority group indicating authorities of contents corresponding to all types of authorities defined in the first authority information. A communication device. A program for causing a computer to generate authority information used for control using SNMPv3,
In the computer,
Conversion rules for converting first authority information, which is authority information managed by other than SNMPv3, and second authority information, which is authority information used for control using the SNMPv3, And a procedure for storing
Including a program for executing a procedure of generating the second authority information by converting the user name included in the first authority information and the authority information corresponding to the user name according to the conversion rule. A program characterized by 15. The program according to claim 14, wherein
The first authority information includes information indicating whether or not the authority is permitted for a plurality of authorities for each user. The program according to claim 14 or 15,
The second authority information generated according to the conversion rule is defined in the VACM table in which an authority group indicating authority of contents corresponding to all kinds of authorities defined in the first authority information is defined. A program characterized by being. The program according to claim 14 or 15,
The conversion rule includes a definition of a correspondence relationship between an item of information in the first authority information and an item in the second authority information generated based on the information of the item. program. A program according to claim 17,
The conversion rule includes a provision that the information of an item of vacmGroupName in the second authority information is defined based on the authority information in the first authority information, and further, authority that can be specified by the authority information A program comprising, for each content, a definition of information to be set in an item of vacmGroupName for a user having authority of the content. A program according to any one of claims 14 to 18, comprising:
In the computer,
A function of controlling a communication device using SNMPv3;
A function for generating the second authority information from the first authority information stored by itself when starting up, and realizing the function of using the generated second authority information for controlling the communication device. A program further comprising a program. Computer
First authority information that is authority information managed by other than SNMPv3, and a conversion rule for converting the first authority information into second authority information that is authority information used for control using SNMPv3; Storage means for storing
A program for causing a user name included in the first authority information and authority information corresponding to the user name to be converted according to the conversion rule to function as conversion means for generating the second authority information. The program according to claim 20, wherein
The first authority information includes information indicating whether or not the authority is permitted for a plurality of authorities for each user. The program according to claim 20 or 21,
In the VACM table, the second authority information generated by the conversion means is defined as an authority group indicating authorities of contents corresponding to all kinds of authorities defined by the authority information in the first authority information. A program characterized by that. A program according to any one of claims 20 to 22,
The converting means is means for generating the second authority information when the computer is started,
The program further comprising a program for causing the computer to realize a function of using the generated second authority information for control of a communication device using SNMPv3. A program according to any one of claims 14 to 23,
The first and second authority information includes authentication information for authenticating a user. A computer-readable recording medium in which the program according to any one of claims 14 to 24 is recorded.

Images