Preventing System Admins From Accessing Database (1 Viewer)

[The_Doc_Man]

Despite your desire to isolate that DB, there was an old rule taught on the first day of Windows O/S Security classes: If you have the main console in your hands, you own the machine and everything in it. End of discussion.

That rule is part of the reason why corporations have locking doors and on-site security personnel outside the "machine room" which is kept isolated as much as humanly possible.

 

[DalynSoft]

Good point @Josef P. I also checked WITH ENCRYPTION but it seems that there are unecryption tools easily available so that is not much help anyway. So basically if I want to protect the code in the Stored Procedures I should not use SQL Server?

 

[The_Doc_Man]

Good point @Josef P. I also checked WITH ENCRYPTION but it seems that there are unecryption tools easily available so that is not much help anyway. So basically if I want to protect the code in the Stored Procedures I should not use SQL Server?

You should understand that you can NEVER unequivocally and absolutely protect/hide ANYTHING on a computer. Protection is always a matter of degree rather than of kind. You CAN make it difficult for a hacker to get in. Depending on the value of something, you can make it not worth the hacker's time. Most of them only go for low-hanging fruit (i.e. easy to pluck.) But if someone honestly believes that there is a treasure trove hidden in your system, they WILL get to it eventually.

The ONLY truly safe system is one that has NO internet connections and for which the console device cannot be used. (Which generally means that the computer protected that way is useless to anyone.) It is that old dilemma - for something to be useful, there needs to be a way to actually use it - which means someone has to be able to get to it. If no one can get to it, it is useless and therefore has no reason to exist in the first place. That is a sad fact of life based on human nature and human greed.

 

[Isaac]

Protection is always a matter of degree rather than of kind

Well said. There used to be a saying 'security by obscurity', and it referred to making the Access back end as hidden as it could be, which was only so much.

I once (laugh if you must, but I really did this once a long time ago) wrote code that created folders and subfolders like 500-1000 layers deep and then put the back end in it, wondering if that may help. Can't remember if I ever tried to actually implement it, but it was just an idea I had once

Edit: as doc has reminded me, you'd have to map a drive letter to this in order to make it avoid the long filenames problem

 

[The_Doc_Man]

The problem with the "many layers deep" approach is that there is a limit on the length of a file spec. So it would work until you slammed into that limit.

 

[spaLOGICng]

I am still stuck on why we would want to block System Administrators.

If the System Admin is the SA on the Server, why would we block him? Permissions are hierarchical. Employees at the top generally respect and protect the systems in their control. They know their limitations and respect their limitations Countless times I have been hired by a System Admin that had the SA where the DEV was let go and needed someone to fix and repair.

If this is a request by your client, then it sounds like the Client does not trust his system admin(s) and that point I would wonder what the trust level is and recommend that that person is demoted or terminated. Just change User Permission in Active Directory and the SA Password and give it to the Client only. The Folders behind the Server are already protected. When the System Admin comes to you and asks what happened, just play dumb and recommend they go to their supervisor. I have been in that position before. I find it easier to play dumb when I have already seen the writing on the wall. That person typically already knows it to, that their days are numbered.

 

[The_Doc_Man]

I am still stuck on why we would want to block System Administrators.

I suppose it is possible to have an unscrupulous SA, but if that is the case, why would you put such a sensitive product on a machine run by a company that employs an untrustworthy SA?

"Trust" is both the name of a specific computer relationship enforced by Domain Controller software and the name of a personal relationship between employee and employer. But it should ALSO be a personal relationship between a client and a service company. Trust is earned, not given. Trust is also not blindly removed, but is only removed for cause. Otherwise, it is the person who doesn't trust the SA who actually is untrustworthy because they don't grasp the nature of the SA position. Trust is a two-way street.

OK, maybe you need to ask a few questions or talk with the SA to decide if you can trust him/her. But on the day that companies start using AI bots rather that persons, the decision to not trust the SA won't be given to you.

 

[spaLOGICng]

I suppose it is possible to have an unscrupulous SA, but if that is the case, why would you put such a sensitive product on a machine run by a company that employs an untrustworthy SA?

"Trust" is both the name of a specific computer relationship enforced by Domain Controller software and the name of a personal relationship between employee and employer. But it should ALSO be a personal relationship between a client and a service company. Trust is earned, not given. Trust is also not blindly removed, but is only removed for cause. Otherwise, it is the person who doesn't trust the SA who actually is untrustworthy because they don't grasp the nature of the SA position. Trust is a two-way street.

OK, maybe you need to ask a few questions or talk with the SA to decide if you can trust him/her. But on the day that companies start using AI bots rather that persons, the decision to not trust the SA won't be given to you.

Thanks Doc. My question was more for the OP and I hope he reads your response.

My experience with Clients that put more trust in the Service Company than the resident SA is that the SA is on the way out the door and doesn't know it yet. But as long as he/she is the SA, then in my mind they are the SA. Unless the Service Company has something to hide... hmm... that is a thought... like writing a malicious procedure and invoking a web service to steal sensitive data... Or, setting up a Web App and running the DB from the Client Server rather than paying for his own Database Service. I am not saying any of that is the case... but for me I see some red flags.

 

[Isaac]

The problem with the "many layers deep" approach is that there is a limit on the length of a file spec. So it would work until you slammed into that limit.

Yeah, in order to implement it I remember planning to use vba to map a drive letter on the fly (which I've found handy for many purposes, BTW) in order to handle it