Lock Down Those Administrators
-
I'm not a big Oracle fan though honestly I think it's a great product. I like to pick on them mostly in fun and to give my few Oracle buddies a hard time. However they made an announcement recently that I really liked.
I saw this article about their Database Vault technology, which adds encryption, but more importantly, locks down administrators to prevent them from reading data. That's always been a request, and subsequently a complaint, with SQL Server when an administrator can get to the HR data, sales data, or some other information that executive management doesn't want you to read. I think it's more possible with SQL Server 2005, but probably not as easy as it should be.
While struggling with meeting this objective in the past, I've also struggled with the problems it causes. If you cannot read a table, then it becomes hard to develop, debug, or write an application with that table. Or if there are questions about the data, it becomes hard to determine if the data being pulled is correctly being retrieved.
You also get into the issues of successfully testing restores and other DR issues, recovering from corruption, or even protecting the data if there are encryption issues.
I've worked in more jobs than I'd liked to have had in the past and the disclosure of information to a DBA or system administrator has never been a big problem. People will always learn what a few others make in salary or some similar information that should not be public knowledge. However I don't think those circumstances should dictate the IT policy.
I'm not saying that information should not be protected. Or that limits shouldn't be placed. I'm just not sure I think this is one of them.
Steve Jones
-
I'm with you on this one, Steve.
I understand the principles behind this kind of confidentiality, but at the same time, I've worked for several companies with strict policies regarding dissemination of (for example) salary infomation, and I've always been able to find out any information that I wanted just by asking the right people. Having it as company policy is fine, but people still talk, and there's a limit to how much you can go against human nature.
The other issue is that (as you pointed out), in this situation I think it puts needless restrictions on the DBA. Ultimately, someone has to be responsible for maintaining the integrity of that data (whether they're particularly interested in its details or not), and it's far easier to design and maintain the system when you can see the actual data which you are trying to design around. It would serve the company better, I think, to hire a DBA they could trust and simply ask him not to reveal the info.
At some point, I think you have to be able to trust that the man hired to guard the henhouse will not develop a taste for poultry.
-----------------
C8H10N4O2
-
This kind of functionality is long overdue and will become essential, with legal backing. Implications of Sarbox are still evolving but strict separation of access is becoming required (where I work there are rigid separation of access within the financial departments). With internal encryption, a DBA can manage the system without having access to view or change data (if properly designed, changing an encrypted field will be immediately detectable). Of course that means some aspects data integrity becomes more the responsibility of the data owner, but that's not necessarily a bad thing. The DBA can be brought into the picture as necessary if circumstances require it, but looking at data is rarely the way to manage integrity.
I think it's a great function to be able to manage the HR database or a medical information database, or a credit card record database, without the legal weight of having that information directly accessible.
...
-- FORTRAN manual for Xerox Computers --
-
How would you go about setting up the rules? Someone has to have rights to configure these rules, and it has to be someone with a certain skill level. Certainly someone who understands the database schema, and where the sensitive information is to be found. Unless you just do a global lockdown.
But even then...Who is going to configure these, if not the DBA? One of his subordinates? And if the DBA is to configure them, then what's to prevent him from going in and temporarily unconfiguring them when the opportunity arises?
-
Actually to configure rules, seeing actual data is often not essential, other than for back of envelope verification (which the data owner is more qualified to evaluate anyhow). Being meta, rules should be data independent.
...
-- FORTRAN manual for Xerox Computers --
-
I think the idea is that if the DBA went in and "unconfigure" the rules, it would be logged to a secutiry log and the DBA would be required to explain.
I'd like to be able to take a "hey, I can't see the payroll data" approach. Less fixing user errors, etc.
-
i agree with micheal on his assessment. I think humans being humans, they are always the weekest link and this idea of encryption of data is one for the software dev companies to fleece money off their clients.
it helps me a lot when i can see the data i am working with, instead of some funny characters in the table columns
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply