Preventing users from using SecureData to decrypt unauthorized data

I'm not sure there's one "right" answer to this question, but I'll share my perspective. It is mine alone, and others may have different opinions on best practices.

It sounds like the premise of the question is that encryption is being used as a form of access control. In other words, the secrecy and integrity of some data relies on only authorized principals being able to encrypt and decrypt that data. If that's the case, I would argue that Vertica's access control features should not be relied upon to enforce that policy. Access to keys is what enables a principal to encrypt or decrypt, and Vertica is not responsible for managing the keys. Voltage is. Vertica's access control features (users and roles, grants, inherited privileges, access policies) can absolutely be used as a redundant layer, but the right way to control access to encryption isn't through gating access to the algorithm. It is by keeping keys secure.

Voltage SecureData can manage keys in a way that is linked to identities. Voltage users can have access to multiple identities, and keys are tied to identities. So, if Alice (who is defined in LDAP or has a shared secret proving she's Alice to Voltage) has access to the identity analysts@example.com, Voltage will pass along the key to encrypt or decrypt data with that identity. Anyone without access to analysts@example.com can run Voltage decryption functions all day long on data encrypted thereby, and never get anything useful, because they do not have the key.

In Vertica, a Vertica user can set their Voltage user information in the session. When using Voltage UDX functions, the Voltage identity to use can be specified. This requested identity is passed along by Vertica together with the Voltage user information set in the session. Voltage can then determine if the specified principal has the right to use that identity, and therefore the key.

How can we leverage this? By not using a single, shared Voltage identity (and therefore key) to encrypt and decrypt all protected data in the database. Instead, use identities corresponding to users or groups, and compartmentalize data access by using the appropriate identities. Then it doesn't matter who can execute the UDX, because the UDX isn't using a shared master key[set] for all data.

Of course, all of this is predicated on the choice to rely on encryption for access control to data stored in Vertica. Another approach would be to rely on Vertica access control features, instead. Instead of the secrecy and integrity of some data relying on only authorized principals being able to encrypt and decrypt that data, it can rely on only authorized principals being allowed to see or modify that data, period. In this case, the database could continue to use a shared master identity/key[set] with the Voltage UDX and safely grant access to the UDX to all principals, because Vertica features are relied upon to prevent DML operations in "unauthorized areas". No one can decrypt data if the database won't hand over the data in the first place.

Relying on both encryption and Vertica access control functionality for data secrecy and integrity is possible! But in that case, I would avoid using a shared Voltage identity, as I described above. Let Vertica decide who can see the data, and let Voltage decide who can decrypt it.