inthesun
ADSM.ORG Member
There are a few security enhancements that everyone needs to be aware of at V7.1.8, 8.1.2, and 8.1.3 levels.
Please review the following material and test in a test environment (including a dsmserv restore DB) before upgrading your production systems to V7.1.8, 8.1.2, and 8.1.3 levels to make sure that you are ready for the SSL/TLS changes. If you have already upgraded to these levels, then please keep reading the following information.
Please review the product documentation, including the following topics:
Protect your storage environment with an improved security protocol
https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.2/srv.common/r_techchg_srv_sec_812.html
Optimize security with the automatically generated master encryption key
https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.2/srv.common/r_techchg_srv_ekey_812.html
For the latest information about security updates, see:
http://www.ibm.com/support/docview.wss?uid=swg22004844
Per the above "master encryption key" documentation, you need to set a password to protect the master encryption key during DB backup.
Following an upgrade, BACKUP DB will fail until a password has been specified on either the SET DBRECOVERY command or the BACKUP DB command itself.
Do not forget the password -- the master encryption key cannot be restored without it!
Per the following document link, the default password is the password of the SET DBRECOVERY setting: https://www.ibm.com/support/knowledgecenter/SSGSG7_7.1.8/srv.reference/r_cmd_db_backup.html
So, if you don't remember what you set, then do a new SET DBRECOVERY to set a new password.
Keep this password in a safe location, so that you can always recover your master key.
If your Q DB F=D output shows "Protect Master Encryption Key = No.", then the master key is not being backed up by the Backup DB process. With this set to NO, the Backup DB is not protecting the Master Key in case there is a disaster and you must do a Restore DB. In this case, the DB will be restored, but without the Master Key.
Please follow the above steps and keep your password in a offsite secure location that can be accessed by your team during a recovery of the database.
Please review the following material and test in a test environment (including a dsmserv restore DB) before upgrading your production systems to V7.1.8, 8.1.2, and 8.1.3 levels to make sure that you are ready for the SSL/TLS changes. If you have already upgraded to these levels, then please keep reading the following information.
Please review the product documentation, including the following topics:
Protect your storage environment with an improved security protocol
https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.2/srv.common/r_techchg_srv_sec_812.html
Optimize security with the automatically generated master encryption key
https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.2/srv.common/r_techchg_srv_ekey_812.html
For the latest information about security updates, see:
http://www.ibm.com/support/docview.wss?uid=swg22004844
Per the above "master encryption key" documentation, you need to set a password to protect the master encryption key during DB backup.
Following an upgrade, BACKUP DB will fail until a password has been specified on either the SET DBRECOVERY command or the BACKUP DB command itself.
Do not forget the password -- the master encryption key cannot be restored without it!
Per the following document link, the default password is the password of the SET DBRECOVERY setting: https://www.ibm.com/support/knowledgecenter/SSGSG7_7.1.8/srv.reference/r_cmd_db_backup.html
So, if you don't remember what you set, then do a new SET DBRECOVERY to set a new password.
Keep this password in a safe location, so that you can always recover your master key.
If your Q DB F=D output shows "Protect Master Encryption Key = No.", then the master key is not being backed up by the Backup DB process. With this set to NO, the Backup DB is not protecting the Master Key in case there is a disaster and you must do a Restore DB. In this case, the DB will be restored, but without the Master Key.
Please follow the above steps and keep your password in a offsite secure location that can be accessed by your team during a recovery of the database.
