AES Key Generation based on database guid I am developing a .NET application spanning multiple servers who should all be able to decrypt data stored in a SQL database. My database is multi-company where each company has its own GUID. since the data being encrypted is personally identifiable information (PII) and the requirement is to be PII compliant, I am encrypting it all with AES256-CBC were the IV is generated randomly at each encryption and data is stored in a binary field in this format

&lt;version&gt;&lt;IV&gt;&lt;encrypted data&gt;


the version field is for future use should I need to change encryption/decryption algorithm, the IV is random and then the encrypted data.

as for the AES key, I am hashing the company GUID the database record belongs to using SHA256 (resulting in the same key on each server that is trying to decrypt the record from the DB)
I am unable to use SQL encryption for various reasons and must use code for encryption/decryption.

Is this PII encryption scheme secure? Any downsides? I know that no matter what key generation code I build, a hacker if he is already on my server could use a debugger or look at the .NET IL to decode what I am doing. That said, if he only gets the raw data from the DB is that data secure?
It isn't secure at all unless the GUIDs are completely inaccessible to everything except the encryption code. I doubt that is the case in a real application; I assume every DB query and API call passes those GUIDs around. Any anyone who can access the database can easily hash the GUIDs as well and decrypt any of the data. Your scheme as described is basically pointless obfuscation, not strong encryption.

One alternative would be to use the per-customer GUID as a salt for the input to HKDF, and then use a global secret key for the whole app as the key input to HKDF. This will give you a per-customer secret key while not requiring the GUIDs to be secret.

Protecting this "master" app key will be challenging, but protecting it in the same way you protect your TLS certificate private keys makes sense as compromising either would break all security.