I collect some personal information from users of my website and according to German law, the storage of this data is only allowed with consent of the user. I programmed my site in a way, that the users needs to enter the data via a form, and confirm it via a double opt-in which is send to his email address. So far everything is still compliant with the law. But the law also requires from me, that I am able, any time, to prove that the user is really the person who made the entry. The double opt-in should be enough, but as I have access to my database, could make entries too. So the question is, how to turn off my own writing rights without being able to get them back. (And how can I prove that I did not have write access ...)

  • TomTom is probably right, denying yourself the writing permissions to your own database seems impossible. After all, your own application has to be able to write information to the database (to store user input), so how can you prove you yourself couldn't do the same? But perhaps you could implement some kind of digital signature to confirm that no-one but the user could have possibly submitted their data. I'm not an expert in these matters, though, so I hope someone with more knowledge will be able to tell whether that is actually possible in situation like yours. – Andriy M Jun 19 '16 at 22:56
  • 2
    I am pretty sure this is not required by German law. For a counterexample, I am a DBA at a biggish German company, have superuser rights to all non-cloud based databases (there are quite some), and nobody ever required me shutting myself out. – dezso Jun 30 '16 at 16:26

Option 1: Use a different account which have only sufficient permission. Don't use DBA rights account until that is required.

Option 2 : enable the auditing to track all the changes in databases and made by whom. I hope this will full fill the compliance requirement.


You do not. As in: you can not. There is no way to secure anything from writing that a DBA or administrator can not undo - worst case by copying the data to a new installed database. You can not solve this by technical means - I suggest you reread the law (and also the current interpretation and guidelines for it), because you imply a lot more than what it says.


Completely agree with Mr. Prince, we also have similar situation wherein we as a DBA or anyone(for that matter) can't make any change to production database. Each of us has got two domain accounts and password is generated dynamically by a third party tool which expires in just few minutes(configurable).

First account is set as read-only, which is used for day to day operation - checking jobs, reading errorlog, monitoring replication etc. and doesn't require any approval whereas second account can be used only when it is approved by manager considering the fact that we need to apply changes on the Production system. As mentioned earlier, this password will expire in few minutes, so same account can't be used once password is expired and all the changes during that interval is recorded as all these accounts which are having sysadmin is marked for auditing.

I hope this helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.