Abstract:
A computer system regarding which there is no possibility that data loss or data leakage will occur caused by volume migration is provided. 
     The computer system includes: a memory resource to be accessed by a host computer; a storage system for providing a volume, which logicizes the memory resource, to the host computer; and a management device for managing migration of the volume. When detecting a task of migration of the volume based on a request from a first administrator, the management device compares an encryption function setting status of the volume with the encryption function setting status of a migration destination object of the volume; and sends notice of this comparison result to a second administrator, who is different from the first administrator, for security management of the storage system.

Description:
TECHNICAL FIELD 
     The present invention relates to a computer system capable of executing volume mobility securely and a volume migration control method using such a computer system. 
     BACKGROUND ART 
     Recently, the scale of a storage system for a computer system has been expanding due to an increase of an amount of information to be processed by an information processing system. A storage system in which a plurality of storage devices are arrayed is known as an example of the above-mentioned storage system. With the storage system, data is stored in an array system by a storage controller processing data from a host computer. 
     Information processing systems are exposed to various security threats and storage systems are no exception. Therefore, it is necessary to always prepare for the various threats such as data theft, unauthorized access, falsification, and data destruction. Regarding security systems associated with the storage system, there are upper-level-application-side security at a host computer and storage side security. A security function on the storage system side is enhanced in order to reduce the burden on the high-level applications. 
     Even if the security function on the storage system side is enhanced, a storage-drive-based encryption function would possibly face data leakage due to a theft or taking out of the storage drives from a chassis of the storage system. So, a storage-controller-based encryption function is provided instead of or together with the storage-drive-based encryption function. When data is stored in the storage drive by using the above-mentioned encryption function, the storage controller can directly encrypt data and store the encrypted data in the storage drive. Then, since an encryption key is managed by the storage controller, even if the storage drive is taken out for the purpose of, for example, device maintenance, the encryption key will not exist in the storage drive itself and it is difficult to carry out unauthorized analysis of data, thereby realizing a data leakage countermeasure of a high security level. 
     A secret key that is required for data encryption and decoding is commonly stored as a file by a security administrator or managed by a server that performs key management services (KMS). The KMS manages secret key generation, issue, backup, and recovery in an integrated manner. 
     Incidentally, a conventional example of a storage system equipped with the storage-controller-based encryption function is described in, for example, Japanese Patent Application Laid-Open (Kokai) Publication No. 2010-33319. 
     CITATION LIST 
     Patent Literature 
     
         
         PTL 1: Japanese Patent Application Laid-Open (Kokai) Publication No. 2010-33319 
       
    
     SUMMARY OF INVENTION 
     Technical Problem 
     In a cloud environment, a volume mobility function migrating volumes out of the storage system is required. For example, the volume mobility function that would not stop a host computer(s) along with VM (virtual machine) migration between host computers or resource load distribution between storage systems is desirable. Specified storage functions such as data migration between a plurality of volumes, data replication, and volume addition to a pool are realized by volume migration. 
     However, if an administrator of the storage system migrates a volume, to which a data encryption function is set, to an object to which the encryption function is not set, there is a possibility that data may be leaked. Furthermore, even if the encryption function is set to a migration destination volume, if a protection level of an encryption key for a migration destination volume is lower than that of a migration source volume, this would result in data loss due to loss of the encryption key or data leakage due to leakage of the encryption key at the migration destination volume. 
     Furthermore, when migrating a volume during a volume life cycle, events such as cancellation of encryption at the migration destination or a level change of the encryption function occur in order to, for example, switch to a host-based encryption system. When this happens, if a storage administrator can easily cancel the encryption at the migration destination, this might result in data leakage or violation of a security policy. So, the security administrator needs to cancel or change the encryption function at the migration destination; however, just simply cancelling or changing the encryption function at the migration destination would impair flexibility of a volume mobility function. 
     Therefore, it is an object of the present invention to provide a computer system regarding which there is no possibility that data loss or data leakage will occur as a result of volume migration. It is another object of this invention to provide a computer system that enables the security administrator to securely and flexibly change the encryption function at a volume migration destination without impairing the flexibility of the volume mobility function. 
     Solution to Problem 
     In order to achieve the above-described objects, a computer system according to the present invention includes a memory resource to be accessed by a host computer, a storage system for providing a volume(s), which logicizes the memory resource, to the host computer, and a management device for managing migration of the volume; wherein when the management device detects a task of migration of the volume based on a request from a first administrator, it compares an encryption function setting status of the volume with the encryption function setting status of a migration destination object, and sends notice of this comparison result to a second administrator, who is different from the first administrator, for security management of the storage system. 
     Advantageous Effects of Invention 
     According to the present invention, the encryption function setting status of a volume can be adjusted to match the encryption function setting status of a migration destination object of that volume in relation to migration of the volume. So, a computer system regarding which there is no possibility that data loss or data leakage will occur as a result of the volume migration can be provided. Furthermore, according to the present invention, a computer system that enables the security administrator to securely and flexibly change the encryption function at a volume migration destination without impairing the flexibility of the volume mobility function can be provided. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         FIG. 1  is a block configuration diagram of a computer system according to a first embodiment. 
         FIG. 2  is a block configuration diagram of a host computer. 
         FIG. 3  is a block configuration diagram of a storage system. 
         FIG. 4  is a block diagram of a management server. 
         FIG. 5  is an example of a storage management table for managing the storage system. 
         FIG. 6  is an example of a management table for managing volumes. 
         FIG. 7  is an example of a parity group management table for managing parity groups. 
         FIG. 8  is an example of an encryption key management table. 
         FIG. 9  is a flowchart illustrating encryption key management processing executed by a management server. 
         FIG. 10  is a block diagram of a computer system (second embodiment) including a storage system operated according to a thin provisioning system. 
         FIG. 11  is an example of a specific pool management table that is required for encryption setting processing executed by the computer system according to the second embodiment. 
         FIG. 12  is a flowchart illustrating encryption function setting processing according to thin provisioning. 
         FIG. 13  is an example of an authority management table to which the correspondence relationship between authorities granted to a user and bit addresses is set. 
         FIG. 14  is an example of a table for managing the correspondence relationship between user roles and authority bitmaps. 
         FIG. 15  is an example of a management table relating to the correspondence relationship between user group (UG) IDs and roles. 
         FIG. 16  is an example of a management table relating to the correspondence relationship between user IDs and user group IDs. 
         FIG. 17A  is a flowchart (first half) illustrating processing executed by the management server on login from a user. 
         FIG. 17B  is a flowchart (second half) illustrating the processing executed by the management server on login from the user. 
         FIG. 18  is a flowchart illustrating processing executed by the management server on login from a storage administrator. 
         FIG. 19  is a flowchart for explaining security administrator authentication processing on login from the storage administrator to the management server. 
         FIG. 20  is an example of an approval request screen provided by the management server to the security administrator via a GUI. 
         FIG. 21  is an example of a password input screen for an approval request. 
         FIG. 22  is a flowchart illustrating processing for judging whether a request from the storage administrator can be executed or not. 
         FIG. 23  is a block diagram of a variation of the computer system shown in  FIG. 10 . 
         FIG. 24  is an example of a table for managing the correspondence relationship between the external volume in the first storage system, the external storage system, the volume to be added to the pool of the first storage system, and a parity group of that volume. 
     
    
    
     DESCRIPTION OF EMBODIMENTS 
     Next, an embodiment of the present invention will be explained.  FIG. 1  is a block diagram of a computer system according to a first embodiment. While a computer system of the present invention may be equipped with one or more storage systems, the computer system according to this embodiment is equipped with a host system, a plurality of storage systems, and a management device for managing volume migration and an encryption function relating to the volume migration. Forms of the volume migration include data migration between a plurality of volumes, data replication between the plurality of volumes, and addition of a volume to a pool according to thin provisioning. Storage drives mounted in the storage system may be semiconductor memory drives such as SSDs, besides disk drives such as hard disk drives. 
     The computer system includes a host computer  70 , a first storage system (ST 1 )  10 , a second storage system (ST 2 )  20 , a third storage system (ST 3 )  30 , and a management server  60  for these storage systems. 
     When performing volume migration, the first storage system  10  includes an original volume (Origin VOL)  100 , which is a data migration source, and a first target volume (Target VOL)  100 A as a data migration destination volume which is an execution target of data migration or data replication from the original volume  100 . The second storage system  20  includes a second target volume  100 B and the third storage system  30  includes a third target volume  100 C. 
     The host computer  70  is connected to the first storage system  10  via a communication network  80  such as a front-end SAN. The second storage system  20  and the third storage system  30  are connected to external connection ports of the first storage system, respectively. The management server  60  is connected via a communication network  90 , such as a LAN, to the first storage system  10 , the second storage system  20 , and the third storage system  30 , respectively. 
     Intra-chassis data copying is performed between the original volume  100  and the first target volume  100 A and inter-chassis data copying performed between the original volume  100 , the second target volume  100 B, and the third target volume  100 C. 
     The original volume  100  is set to a parity group (ENCRYPTED PG)  200  to which an encryption function is set; and the first target volume  100 A is set to a parity group (NORMAL PG)  200 A to which the encryption function is not set. The second target volume  100 B is set to a parity group  200 B to which the encryption function is set. The third target volume  100 C is set to a parity group  200 C to which the encryption function is not set. 
     The data encryption function in the storage system is applied to each parity group. If the encryption function is set to a parity group and when data is written to a volume which is set to the parity group, the data written to the storage drive is encrypted. The encryption setting is executed by a controller for the storage system. As other forms of the encryption setting, there are storage-drive-based encryption and host-computer-based encryption. 
     A “parity group to which the encryption function is not set” means a state where the encryption function is mounted in the storage system, but that function is turned off by the controller according to the operation based on an authority of a security administrator  40 ; or the relevant function is not originally mounted in the storage system. A parity group is a combination of a plurality of hard disk drives according to a RAID level. Drives equipped with the encryption function are used for encryption of parity groups. 
       FIG. 2  is a block configuration diagram of the host computer  70 . The host computer includes: a memory  702  storing, for example, business application software  700 ; an input device  704 ; an output device  706 ; a processor  708 ; a file system  710  that enables file access to the storage system; a hot bus adapter (HBA)  712  for connection to the storage system; and an internal bus  716  connecting these elements. If a raw device  714  is set to the HBA  712 , the host computer can access the storage system  10  without the intermediary of the file system. 
       FIG. 3  is a hardware block diagram of the first storage system  10 . Since the second storage system  20  and the third storage system  30  have the same configuration as that of the first storage system, its explanation has been omitted. The host computer  70  serving as the upper computer is connected to an interface (I/F)  211  of each front-end package (FEPK)  210 . A storage drive such as a hard disk drive is connected to each interface (I/F)  241  of each back-end package (BEPK)  240 . The front-end package  210  receives a read/write request from the host computer  70  and transfers the read/write request to a microprocessor package (MPPK)  220 . 
     Each microprocessor package  220  processes the read/write request and the back-end package  240  writes write data to the storage drive  270  or reads data from the storage device  270 . Each microprocessor package  220  has a plurality of microprocessors  221 , a local memory  222 , and an internal bus  223 . 
     Each memory package  230  has: a cache memory  231  for temporarily storing write/read data; and a control memory  232  for recording control information. The reference numeral  260  represents a management interface to which the management server  60  is connected. The reference numeral  250  represents a switch for mutually connecting the respective elements such as the memory packages  220 . 
     Data encryption is realized by the controller (back-end package  240 ). Encryption executed when data is written to a volume is performed by a combination of a public key and a secret key. The same encryption key (secret key) may be set to all the drives constituting a parity group or a different encryption key (secret key) may be set to each drive. 
     The management server  60  includes a storage management program  600  and a data encryption program  602  as shown in  FIG. 1 . A client as a security administrator  40  and a client as a storage administrator  50  are connected to the management server  60 . 
       FIG. 4  is a block diagram of the management server  60 . The management server includes: a memory  610  storing management tables or management programs for realizing management functions of the storage system; an input device  612 ; an output device  614 ; a processor  616 ; and an internal bus  618  for connecting these elements. 
     The memory  610  stores a storage management table  620 , a volume management table  622 , a parity group management table  624 , an encryption key (secret key) management table (key management table)  626 , a pool management table  628 , a storage management program  630 , a data encryption management program  632 , an account control program  634 , a graphical user interface  636 , and a command line interface  638 . 
       FIG. 5  is an example of the storage management table  620  for managing the storage system. The storage management table  620  has a data structure in which a storage system ID  620 A, a serial number  620 B of the relevant storage system, and an IP address  620 C of a management port  260  are associated with each other. 
       FIG. 6  is an example of the management table  622  for managing volumes. The volume management table  622  has a data structure in which a volume ID  622 A of each storage system and an ID  622 B of a parity group (PG) of each storage system corresponding to the relevant volume are associated with each other. 
       FIG. 7  is an example of the parity group management table  624  for managing parity groups (PG). The parity group management table  624  has a data structure in which a parity group ID  624 A of each storage system, an encryption status  624 B of the relevant parity group, and an encryption key ID  624 C are associated with each other. The encryption status  624 B [ON] indicates that the data encryption function is set to the relevant parity group and data written to a logical volume of the parity group is encrypted; the encryption status  624 B [OFF] indicates that the encryption function is set to the relevant parity group, but data is not encrypted; and the encryption status  624 B [N/A] indicates that the encryption function for the parity group is not originally assigned to the controller (the microprocessor package  220 ) for the storage system. 
       FIG. 8  is an example of the encryption key management table  626 . The key management table  626  has a data structure in which an encryption key ID ( 626 A), creation date and time ( 626 B) of the relevant encryption key, an encryption key backup type ( 626 C), and a KMS IP address  626 D are associated with each other. The encryption key backup type includes the management system by KMS as described earlier and a management system by file storage. The file management system is to have the security administrator  40  store the encryption key. The encryption key management system by the KMS is to register the KMP IP address in the key management table  626 . 
     Next, encryption key management processing for volume migration between a plurality of volumes will be explained with reference to a flowchart.  FIG. 9  shows the operation of the management server  60 . When the storage administrator  50  sends a data migration request to the storage management program (volume migration management program)  630  of the management server  60 , the storage management program  630  outputs an encryption setting check request to the data encryption management program  632  and starts processing of the flowchart in  FIG. 9 . 
     Next, the data encryption management program  632  executes the processing of the flowchart in  FIG. 9  and executes processing for checking the encryption setting status of each of the original volume  100  and the target volume  100 A ( 100 B,  100 C). Firstly, the data encryption management program  632  extracts the ID of the original volume  100  and the ID of the target volume  100 A ( 100 B,  100 C) from the volume migration request from the storage administrator  50  (S 900 ). 
     Next, the data encryption management program  632  refers to the volume management table  622  and checks the ID of a parity group  200  ( 200 A,  200 B,  200 C) to which each of the original volume  100  and the target volume  100 A ( 100 B,  100 C) belongs (S 902 ). 
     Then, the data encryption management program  632  refers to the parity group management table  624  and judges whether or not the encryption function is set to the parity group  200  of the original volume  100  and the original volume  100  is encrypted (S 904 ). If the original volume  100  is not encrypted, the management processing on the encryption key is not necessary and, therefore, the data encryption management program  632  terminates the processing of the flowchart. Then, the computer system  10  continues to execute data copying required for the volume migration between the original volume the target volume. 
     If the original volume  100  is encrypted, the data encryption management program  632  refers to the parity group management table  624  and judges whether or not the encryption function is set to the parity groups PG 2  to PG 4 , to which the target volume  100 A ( 100 B,  100 C) belongs, and the target volume is encrypted (S 906 ). 
     If the encryption function setting status of the parity group of the target volume is [OFF] or [N/A], the data encryption management program  630  notifies the security administrator  40  that the encryption of data will be lost as a result of volume migration between the original volume and the target volume, and then rejects the data migration request from the storage administrator; or rejects the data migration request from the user without notice (S 910 ). Either of the above-described means would be selected depends on the advance setting of the management server  60  by the storage management user  50 . If the encryption function of the parity group of the target volume is [OFF], the security administrator who has received the above notice can demand that the data encryption management program should set the encryption function to [ON]. Having received this request, the data encryption management program can demand a change of the encryption function setting by the controller for the migration destination storage system. 
     If the encryption setting status of the parity group of the target volume is [ON] and the target volume is encrypted, the data encryption management program  632  obtains the encryption key backup type( 626 C) of each of the original volume and the target volume from the encryption key management table  626  ( FIG. 8 ) (S 908 ). 
     Next, the data encryption management program  632  judges whether or not the encryption key backup type of the original volume is the same as the encryption key backup type of the target volume (S 912 ). If they are the same, the data encryption management program  632  terminates the processing of the flowchart. Subsequently, the data encryption management program  632  notifies the storage management program  630  of the termination of the processing of the flowchart; and the storage management program  630  issues an instruction to the migration source storage system and the migration destination storage system to execute data copying between the original volume and the target volume and these storage systems executes data copying between the original volume and the target volume. 
     If the encryption key backup type of the original volume  100  is different from the encryption key backup type of the target volume  100 A ( 100 B,  100 C), the data encryption management program  632  notifies the security administrator  40 , via the GUI  636 , that the encryption key backup type of the original volume is different from the encryption key backup type of the target volume; and then terminates the processing of the flowchart. 
     After the data encryption management program  632  terminates the processing of the flowchart, the storage management program  630  waits for confirmation by the security administrator  40  and then executes volume migration between the original volume and the target volume. 
     On the other hand, if a backup type level of the parity group of the target volume is lower than that of the original volume, the data encryption management program  632  may not only send the notice, but also output a request to prompt the security administrator  40  to adjust the former type to the latter type, via the GUI to the security administrator  40 . Specifically speaking, it is a case where the latter backup type is the file management system and the former backup type is the KMS system and the latter management system is to be changed to the KMS system. This change is executed by the security administrator  40 . Unless these encryption key backup systems are adjusted to be the same backup system, the data encryption management program may reject the volume migration request from the storage administrator. 
     On the other hand, if the former backup level is higher than the latter backup level, the security administrator may only receive the notice and the storage management program may execute the volume migration request. Alternatively, in this case, the notice in S 914  may not be issued. 
     Incidentally, if the storage administrator attempts to cancel the encryption function in the volume migration destination storage system by, for example, changing the encryption to the host-computer-based encryption, the encryption management program returns a negative judgment in S 906 . As the security management program sends the notice in S 910  and then obtains an approval from the security administrator, the storage management program can continue the volume migration processing without having the security management program change the encryption setting status of the target volume. 
     Furthermore, the judgment in S 904  and S 906  is based on whether the encryption is performed or not, but the judgment may be based on superiority of the encryption level, instead. If the encryption level of the volume migration destination storage system is lower than the encryption level of the volume migration source storage system, the data encryption management program may execute the same processing as in S 910 . 
     According to the flowchart shown in  FIG. 9 , security of the volume mobility system can be maintained and enhanced while maintaining the flexibility of the volume mobility function by synchronizing the volume migration processing, the volume migration destination environment, and the processing for controlling the encryption setting status with respect to the volume migration destination environment. 
     Next, a computer system according to a second embodiment will be explained.  FIG. 10  is a block diagram of a computer system including a storage system  10  operated according to the thin provisioning. The difference between the system in  FIG. 1  and the system according to the second embodiment will be mainly explained. The host computer  70  accesses a virtual volume  1001  that does not have an actual capacity. When the virtual volume  1001  is accessed by the host computer  70 , the storage system  10  allocates a storage area having an actual capacity from a pool  1000  to the virtual volume  1001 . 
     A volume(s) is allocated from a parity group  1010  to the pool  1000 . Volumes allocated to the pool are pool volumes  1002 ,  1004 . A pool volume is composed of a storage area with an actual capacity. The reference numeral  1006  represents a volume  1006  to be allocated from a parity group  1008  to the pool  1000 . 
     The encryption key management method becomes a problem in this embodiment when the encryption setting status and the encryption key backup type of a parity group, which is the basis of a pool volume, are different from those of the pool. Referring to  FIG. 10 , the encryption function is set to the parity group  1010 . The storage system  10  manages the pool  1000  so that the pool  1000  is encrypted in accordance with the pool volumes  1002 ,  1004  whose data can be encrypted. 
     On the other hand, data cannot be encrypted with respect to the volume  1006  from the parity group  1008  to which the encryption function is not set. So, if an attempt is made to allocate this volume  1006  as a pool volume to the pool  1000 , the volume  1006  will not match the encryption status of the pool  1000 . Therefore, processing for dealing with volume allocation to the pool is required. 
       FIG. 11  shows an example of a specific pool management table that is required for encryption setting processing of the computer system according to the second embodiment. The pool management table has a data structure in which a pool ID  1100 , an encryption setting status  1102  of the relevant pool, a pool volume ID  1104 , and a parity group ID  1106  are associated with each other. 
     Next, the encryption function setting processing according to thin provisioning will be explained with reference to a flowchart in  FIG. 12 . When the storage management program  630  receives a request for allocation of the volume  1006  to the pool  1000  from the storage administrator  50 , the data encryption management program  632  receives an encryption setting check request from the storage management program  630  and then obtains the ID of the additional volume  1006  to be added to the pool  1000  and the ID of the pool  1000  from the request from the storage administrator  50  (S 1200 ). Then, the data encryption management program  632  refers to the pool management table  1100  and obtains the IDs of the pool volumes  1002 ,  1006  already existing in the pool  1000  (S 1202 ). 
     Subsequently, the data encryption management program  632  judges whether the encryption setting is set to the pool or not, by referring to the pool management table  1100  (S 1204 ). If a negative judgment is returned in this step, the data encryption management program  632  terminates the processing of the flowchart and the storage management program  630  receives notice of termination of the flowchart processing from the encryption setting program  632  and allocates a new volume  1006  to the pool  1000 . 
     Next, if an affirmative judgment is returned in S 1204 , the data encryption program  632  judges whether or not the encryption setting is set to the parity group  1008  to which the volume  1006  to be added to the pool  1000  belongs (S 1206 ). 
     If a negative judgment is returned in this step, the data encryption management program  632  rejects the request from the storage administrator via the GUI  636  in order to prevent the volume  1006 , which is not encrypted, from being allocated to the pool  1000  defined as an encryption target (S 1208 ). 
     On the other hand, if an affirmative judgment is returned, the data encryption management program  632  obtains the encryption key backup type of the parity group  1010  related to the pool from the encryption key management table  626  based on the related parity group, that is, the parity group  1008  of the additional volume  1006  and the IDs of the pool volumes  1002 ,  1004  existing in the pool (S 1202 ) (S 1210 ). 
     Next, the data encryption management program  632  checks whether the backup types of all these related encryption keys are the same or not (S 1212 ). If an affirmative judgment is returned, the data encryption management program terminates the processing of the flowchart. When this happens, the storage management program  630  issues an instruction to the controller for the storage system  10  to allocate the additional volume  1008  to the pool  1000 . 
     On the other hand, if a negative judgment is returned in S 1212 , the data encryption management program  632  checks whether or not the key backup type of at least one of all the related encryption keys is the KMS management system (S 1214 ). If an affirmative judgment is returned, the data encryption management program  632  notifies the security administrator  40  via the GUI  636  that the encryption key which has been backed up by an encryption key backup type other than the KMS system should be changed to the KMS system backup type (S 1216 ). 
     On the other hand, if a negative judgment is returned in this step, the data encryption management program  632  applies a unified encryption key backup system other than KMS by, for example, prompting the security administrator to change the encryption key backup system of the additional volume  1006  to make it match the encryption key backup type of the pool to which the volume is to be added (S 1218 ). 
     A unified encryption key backup type, such as the KMS system or the file management system, can be applied to the pool volumes belonging to the pool  1000  as a result of the processing in S 1214 . If there are a plurality of backup systems other than the KMS system, it is better to use the safest backup system as the unified backup system. 
     As a result of the above-described processing, the encryption key backup systems of the pool volumes can be adjusted to the same encryption key backup system as triggered by the addition of a new volume to the pool. Incidentally, the embodiment shown in  FIG. 10  has described a case where the encryption function is not set to the parity group  1008 ; however, the encryption function can be set to the parity group  1008  as a premise of S 1218 . 
     Next, a third embodiment will be explained. The aforementioned embodiments adopt the configuration in which the data encryption management program  632  of the management server  60  executes the processing of the aforementioned flowcharts to determine an optimum backup form of the encryption key. On the other hand, the third embodiment provides a system by which the data encryption management program asks for an approval of the security administrator  40  when attempting to change the encryption key backup type. For this purpose, a control function managing authorities and roles of the security administrator  40  and the storage administrator in an integrated manner is required. The management server  60  includes management tables and control programs in order to realize the above-described function. 
       FIG. 13  is an example of an authority management table to which the correspondence relationship between each authority  1300 B granted to a user and bit addresses  1300 A is set. Each authority  1300 B corresponds to each bit address  1300 A. For example, [Key Management] corresponds to a bit address [ 4 ] and [Data Encryption Management] corresponds to a bit address [ 5 ]. The former authority includes the authority to approve, for example, the determination and change of a key pair (a public key and a secret key), backup of the secret key, and determination and change of the secret key backup type. The latter authority includes an authority to, for example, encrypt data and cancel the encryption of the data. 
       FIG. 14  is an example of a table for managing the correspondence relationship between roles of the user and (shown as Role name  1400 B) authority bitmaps (shown as Authority Bitmap  1400 C). An authority bitmap  1400 C is a set of all authority addresses and a role (shown as Role ID  1400 A) is a management unit of one or more authorities. For example, Role  2  is a role relating to security management and the authorities corresponding to the first bit and fourth to sixth bits of the authority address respectively are assigned to Role  2 . Therefore, Role  2  has a wider function in terms of security than Role  1  to which only Role  1  (View Security Information) is assigned. Role  2  is set to the security administrator  40 . Roles relating to other than security, such as Roles  6  to  13 , are set to the storage administrator  50 . All the authorities are granted by Role  14  to a maintenance administrator. 
       FIG. 15  is a management table for managing the correspondence relationship between user group (UG) IDs  1500 Aand roles  1500 B and  FIG. 16  is a management table for managing the correspondence relationship between user IDs  1600 A and user group IDs  1600 B. A user ID  1600 A is set to a user (administrator). The user ID  1600 Ais set to indicate user classification information. For example, [ST_ADMIN 1 ] indicates the storage administrator  50  and [SECURITY_ADMIN] indicates the security administrator  40 . Each user ID belongs to a user group. One or more roles are set to each user group. Therefore, each user ID is associated with one or more authorities via the user group ID, the role ID, and the authority bitmap. A user group is an index for grouping users. 
       FIGS. 17A ,  17 B are flowcharts illustrating processing executed by the management server  60  on login from the user. When the GUI  636  or the command line interface (CLI)  638  of the management server  60  accepts login from the user, it obtains a user ID and a password from the login (S 1700 ) and sends them to the account management program  634  (S 1702 ). 
     When the account management program  634  obtains various IDs and password (S 1704 ), it judges whether they are correct or not (S 1706 ). If a negative judgment is returned in this step, the account management program  634  jumps to login result message creation processing without executing login session creation processing (S 1708  to S 1712 ). On the other hand, if an affirmative judgment is returned, the account management program  634  executes the login session creation processing. 
     Firstly, the account management program  634  generates a login session ID (S 1708 ). Then, the account management program  634  generates an authority bitmap to be allocated to the session ID from the user ID, the user group ID, and the role ID by referring to the authority bitmap the management table ( FIG. 13 ) (S 1710 ). Subsequently, the account management program  634  adds the generated login session to the session management table (S 1712 ). 
     Next, as shown in  FIG. 17B , the account control program  636  creates a login result message (S 1714 ) and then sends the login message to the GUI (CLI) (S 1716 ). After the GUI or similar obtains this (S 1718 ), it judges whether the login session ID is [NULL] or not (S 1720 ). If the user ID and the password are not correct, an affirmative judgment is returned in the above step and the account management program  636  creates a message for rejecting the login and sends it to the GUI or similar (S 1726 ); and the GUI displays this message (S 1728 ). 
     On the other hand, if the GUI confirms the session ID, it keeps the login session ID (S 1722 ) and creates a message to permit the user login (S 1724 ). 
     If the management server  60  permits the user login, the storage management program  630  obtains the session ID from the session management table as shown in  FIG. 18  (S 1800 ) and obtains user request information and the authority bitmap that are attached to the session ID. The storage management program  630  judges, based on the user request information, whether or not the encryption function is set to at least one object which is a target of processing requested by the user (S 1802 ). If the storage management program returns a negative judgment in this step, there is nothing to pay attention to with respect to encryption of the object. So, the storage management program  630  executes the user request, for example, data migration or data replication between a plurality of volumes or addition of a new volume to the pool (S 1804 ). Incidentally, the [Object] means, for example, an original volume, a target volume, a parity group, a pool, a pool volume, or a new volume to be added to the pool with respect to data migration, data replication, or allocation of the new volume to the pool. 
     If an affirmative judgment is returned in S 1802 , the storage management program  630  executes authentication processing on the security administrator before the user request processing. This authentication processing will be explained with reference to a flowchart in  FIG. 19 . The storage management program  630  requests for approval from the data encryption management program with respect to the user request processing (S 1900 ). The data encryption management program  630  stacks this request (S 1902 ) and issues a stack completion notice to the storage management program (S 1904 ). 
     Next, the storage management program  630  repeatedly requests an approval result from the security administrator (SECURITY_ADMIN)  40  from the data encryption management program  632  (S 1906 ). Since the data encryption management program  632  has not received the approval result yet, it issues a notice of non-receipt of approval to the storage management program (S 1908 ). 
     When the security administrator  40  founds by, for example, email that the approval request has arrived from the storage management program  630 , the security administrator  40  accesses (logs into) the data encryption management program (S 1910 ). In response to this access, the data encryption management program  632  issues the approval request, which has been stacked, to the security administrator (S 1912 ). The security administrator  40  notifies the data encryption management program  632  of the approval result (S 1914 ). The data encryption management program  632  registers the approval result (S 1916 ). Then, after receiving an approval result notice request from the storage management program  630  (S 1918 ), the data encryption management program  632  sends the approval result notice (S 1920 ). 
       FIG. 20  is an example of an approval request screen provided by the data encryption management program  632  via the GUI  636  to the security administrator  40 . The request screen includes a request ID  2000 A, request issue date and time  2000 B, and an approval field  200 C. If the security administrator inputs a check mark in the approval field and clicks [DONE], a password input screen in  FIG. 21  is displayed at the security administrator  40 . If the security administrator clicks [OK] (shown as  2106 ) and the password  2104  is thereby authenticated, [Permitted] is set to the approval field of the approval request screen. On the other hand, if [DONE] is clicked without inputting the check mark, [Rejected] is set. Incidentally, if the security administrator  40  inputs the check mark in a box on the left side of the request ID and clicks [DETAIL] and the password is thereby approved, the details of the user request such as the specific content of the user request which requires checking of the encryption setting for, for example, data migration, data replication, or addition of a volume to an HDP pool are displayed. [CANCEL] )shown as  2108 ) is clicked for reinput. An approval processing date and time field may be included in the approval screen in  FIG. 20 . The request ID is composed of an ID of a target storage system of the relevant request from the storage administrator and an ID assigned to the request. 
     When the storage management program  630  receives the approval result by the security administrator from the data encryption management program  632 , it executes processing relating to the execution of the user request (S 1806 ).  FIG. 22  shows a flowchart illustrating user request execution possibility judgment processing as the details of the above-described processing. 
     Firstly, the storage management program  630  obtains one or more requests (all the requests) from the storage administrator  50  (S 2200 ). The storage management program  630  obtains one request from among the plurality of user requests (S 2202 ) and judges whether an encryption setting request relating to the above-mentioned request is approved or rejected by the security administrator  40  (S 2204 ). If the request is approved, the storage management program  630  executes processing for executing the user request (S 2208 ); and if the request is rejected, the storage management program  630  rejects the user request (S 2206 ) and notifies a user-side computer to that effect. The storage management program  630  repeats the processing from S 2204  to S 2208  with respect to all the requests. 
       FIG. 23  is a variation of the computer system in  FIG. 10 . With the computer system in  FIG. 10 , a volume to be added to the pool  1000  is provided from a parity group in the storage system  10 ; and with the computer system in  FIG. 23 , a volume  20 A of a parity group of a second storage system  20 B which is externally connected to the first storage system  10  is allocated to the pool  1000  of the first storage system. The first storage system  10  and the second storage system  20  are connected via a back-end SAN  80 A. The external volume  1007  of the first storage system  10  is a virtual volume to allocate the volume  20 A of the second storage system  20  to the pool  1000 . 
     With the computer system in  FIG. 23 , for example, the aforementioned processing for adjusting the encryption key backup type is also applied to the encryption setting status of the parity group  200 B and the encryption setting status of the pool. Incidentally,  FIG. 24  is an example of a table for managing the correspondence relationship between the external volume  1007  in the first storage system  10 , the external storage system  20 , the volume  20 A to be added to the pool  1000  of the first storage system  10 , and a parity group  200 B of that volume. The data encryption program  632  refers to this table as necessary when executing the aforementioned various processing relating to the encryption setting. 
     REFERENCE SIGNS LIST 
       10  First storage system 
       20  Second storage system 
       30  Third storage system 
       70  Host computer 
       100  Original volume 
       100 A to  100 C Target volumes 
       200 ,  200 A to  200 C Parity groups 
       60  Management server