The way organizations are managing encryption keys is falling under more scrutiny by QSA auditors. Companies must demonstrate they are enforcing dual control and separation of duties.
How is this achieved on the System i? Is it still effective to use an integrated key management solution that is store encryption keys in the same partition as the encrypted data? The answer, quite simply, is "no" PCI DSS requirement states the following requirements for key management:
Now here is an uncomfortable truth. On the IBM i you simply can't achieve these PCI requirements if you store the encryption key in the same partition as the protected data. The QSECOFR user profile (and any user profile with *ALLOBJ authority) will always have complete access to every asset on the system. An *ALLOBJ user can circumvent controls by changing another user's password, replacing master keys and key encryption keys, changing and/or
deleting system logs, managing validation lists, and directly accessing database files that contain encrypted data.
From the perspective of PCI, an integrated key management system puts too much control into the hands of any one single individual.
The only way to comply with PCI requirements for key management is to store the encryption keys off of the IBM i. Take users with *ALLOBJ out of the picture completely. When you use a separate appliance to manage encryption keys you can grant a user access to the protected data on the System i and deny that same user access to the key manager. Now you have enforced separation of duties. And with the right key management appliance you can require TWO users to authenticate before keys can be managed, and have dual control of encryption keys.
Let us know about the key management strategy at your company. Is your organization encrypting data on the System i? How are you managing the encryption keys? If you store them on a separate partition, have you had a recent PCI audit? What did your auditor say?