Key governance: Need to prevent client app from performing operations on shared keys: If a shared key is created at the domain level by an Admin using the DSM UI, there's nothing preventing a client app from using the API from creating/changing/rotating keys in that same domain.
Recall that customer is using shared keys for each data type (e.g. one for SSN/SIN, one for credit card #, one for government id) so that performing encryption or decryption using any of the access methods (Teradata UDFs, Hive UDFs, BDT, Java library API) will consistently encrypt/decrypt that data type regardless of where it's stored in Teradata and Hortonworks. It is therefore critical to prevent unauthorized activities against these key. This is a SHOWSTOPPER governance issue.
Desired enhancement is to provide the ability in the DSM to prevent a client app from using the API to create/change/delete keys in that domain.
As a short term fix, there is a suggestion to add a flag in the DSM that indicates if the domain will be shared or not (and if so, whether to prevent the APIs from performing operations in that domain). Longer term the recommendation is to provide an ACL (role level control - ideally leveraging the LDAP) in the DSM that allows for more granular control of who is allowed to make changes via the API.
Note that Thales Engineering has created these 2 Jira activities:
PMSJ-2572 (emergency fix to prevent a client app from performing operations in the shared key domain)
PMSJ-2576 (near term enhancement to provide role level granular control of who is allowed to make changes to shared keys via the API)
Note that this RFE supercedes RFE 137574
Do not place IBM confidential, company confidential, or personal information into any field.