We host several instances of our web application on four different servers. Two of the servers host the IIS/web portion of the application, the other two host the MSSQL databases. Each of our clients has an individual virtual directory in IIS and an individual database. Each database shares exactly the same schema.
Assume we’re using asymmetric encryption. Should there be one master key-set used by all instances for encryption/decryption? One key-set per server? One per instance? One per field encrypted?
It seems that the most fine-grained approach would be the best security-wise (one per record?) but that seems a bit difficult to manage. What is the best practice here, or am I off the mark entirely?
I’ll need to figure out how to store these keys as well, but I figure that’s a separate question and may depend on the answer here.
It depends on your particular balance of security versus usability. Storing and managing keys is at least as big a problem as deciding where and when to use keys. Managing keys can be difficult and cumbersome depending on how keys need to be protected and how many people will have access to them. And it will depend on how many records you are managing, now and in the future. Having too many keys is generally a bad idea. Try to match the number of keys to some partitioning of protection. If each instance of the server is serving the same clients, then use the same key for all of them. Unless you server different clients from different servers there’s no reason to segregate them, and it will inhibit distributed processing and fail over. Again with the data, try to match usage partitioning. If a user has access to read all data in a table, secure the table instead of the records with a key. Also, consult your legal team. The US has regulations regarding the protection of customer data, especially medical and financial.