You could encrypt the data with a key stored in your web application so that the data is written/read from db in its encrypted form. However anyone with access to the code would have access to the key and with the key the unencrypted data. This solves the requirement
the dba should not be able to view the information about disease of
the user of the database.
As far as using to separate databases I don't think that is needed. You are storing the data encrypted and using database permissions by user, table (if that's even needed) will be more than enough. I think the extra DB adds a layer of complexity without much else. Unless its at a different location, then it might have a SMALL improvement from a single database system.
I'm pretty dismayed at these other answers. Best practice is only to log what you need to log, so not the full request and response.
You must then consider data protection law. Obviously this varies by jurisdiction but generally it follows the same principles:
- You must document what you are doing, why and the precautions you take to secure the data.
You will find it difficult to justify a blanket log everything policy. 'because its easy' doesn't count as a good reason.
- You will probably have had to ask your customers for permission to use their data for the purpose you describe.
Although a blanket 'tick here to agree to all TnCs' with '... use your data for maintaining the system..' might seem to cover you this has been challenged in court a few times now. The reality is you wont know until you are sued.
Data protection law can be weirdly strict on some things and lax on others. For example I remember one case where in flight meal options were all encrypted because you had options for halal, kosher etc so they would potentially reveal the travellers religion, which counts as sensitive personal data.
Things that wont cut it.
Sanitising the logs. If even one thing slips though you are screwed. Not because of the data. Because of all that documentation you wrote which said you didn't store that data. And stuff will slip through.
Logging everything but to an encrypted store. It doesn't matter how secure it is because the law covers more than just keeping data safe. Any scenario where you are keeping 'everything' is going to be tripped up because you have to state the purpose of keeping it.
******** edit : suggested ways of solving bugs without logging ************
So for api calls with malformed requests I find its best to return a nice error message. It shouldn't contain any data, but it should indicate clearly and uniquely what the error was.
ie
BAD : error - user bob cant eat pork
GOOD : error - meal code not allowed for this user
Ensure you push the error all the way back to the user if the code cant handle it. Bob knows he loves pork and will phone up to report the error. Plus because there is no data, you can log it without worry and check for patterns.
rule 2 : testing testing testing. Write those unit tests and run em all the time. When Bob phones and says he cant order pork because of a bug, write a failing test before you fix it so you know if it ever happens again.
rule 3 : health checks, if you have an api or service, pop a health check method on it. Have you monitoring system hit that health check every few minutes to check everything is ok with the service, it can still talk to the DB is still answering requests promptly etc
Best Answer
If the web site is only to be accessed by your app then I think the best way is to use a token encrypted with keys known only to the two parties (website and app), the web site checks the token using the keys and only responds if the token is valid. And yes you should also encrypt the response.