SQL Server Forums
Profile | Register | Active Topics | Members | Search | Forum FAQ
 
Register Now and get your question answered!
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 SQL Server 2000 Forums
 SQL Server Development (2000)
 NewB Development Question
 New Topic  Topic Locked
 Printer Friendly
Previous Page | Next Page
Author Previous Topic Topic Next Topic
Page: of 8

poncho
Yak Posting Veteran

Canada
62 Posts

Posted - 04/08/2004 :  15:49:38  Show Profile
Obviously you guys are all DBAs that are protecting your jobs, because no developer in his right mind will allow anyone access to his database, to be able to modify tables, enter data without validation and so on. I never once said the DBA shouldn't be allowed to do his job, but his job doesn't entail having access to the data or database structure...that's plain bonehead.

What's to stop a disgruntle DBA from modifing data or datastructure in a 3rd party app and simply walking away, leaving the customer with having to determine whether the faulty data is their responsibility or the 3rd party vendor, nothing from what you guys tell me. How do we determine that a "bug" is actually a bug or some DBA deciding to "enchance" that app by playing around with a few tables...

DBAs seem to have a complex and all you've done is further that prejudice. There is no valid reason for a DBA to have access to sensitive data, or to be able to modify the datastructure of any 3rd party application, unless the vendor and/or customer deem so. I find it very difficult to beleive that other 3rd party vendors are allowing open access to their datastructure to you guys...and if they are they're boneheads too.

On top of all that you are opening yourselves, not your employers, to lawsuits and criminal investigations. If some crime is commited with the use of data stored in "your" database, and your employer lists you as someone with access to that information, you'll need to prove that you are trustworthy and "wouldn't sell information to anyone, honest"...it's bonehead on your part to want access to the data. Besides I know in Canada there are privacy laws that strictly prohibit exactly what you guys are preaching as "the way", it seems that the US isn't as strict on privacy issues.

I hope some actual develop can shed some light on this issue.

Go to Top of Page

derrickleggett
Pointy Haired Yak DBA

USA
4184 Posts

Posted - 04/08/2004 :  15:54:24  Show Profile  Visit derrickleggett's Homepage  Send derrickleggett an AOL message  Send derrickleggett a Yahoo! Message
I think you missed the part about encryption.

MeanOldDBA
derrickleggett@hotmail.com

When life gives you a lemon, fire the DBA.
Go to Top of Page

poncho
Yak Posting Veteran

Canada
62 Posts

Posted - 04/08/2004 :  15:56:10  Show Profile
no I saw that...we would like to find another solution though...if all else fails we will go the encryption route...just want to make sure you "gurus" actually steer us correct.

Go to Top of Page

derrickleggett
Pointy Haired Yak DBA

USA
4184 Posts

Posted - 04/08/2004 :  15:58:42  Show Profile  Visit derrickleggett's Homepage  Send derrickleggett an AOL message  Send derrickleggett a Yahoo! Message
I'm curious. Do you have a DBA? What is their access level? What do you allow them to do? Who's looking over their shoulder?

I'm being completely serious with these questions.

MeanOldDBA
derrickleggett@hotmail.com

When life gives you a lemon, fire the DBA.
Go to Top of Page

JimL
SQL Slinging Yak Ranger

USA
1537 Posts

Posted - 04/08/2004 :  16:10:08  Show Profile  Visit JimL's Homepage
quote:

No they can't ....the database is password protected not our application. Even via ODBC access they need to have the user name and password. We supply a "read only" password via ODBC to our customers so they may run custom reports and such.






Would you care to put this to the test? I would not make that claim if I was you. Like I said Been there done that.

As for being a DBA and protecting a job.

I am the IT Administrator, I determine who gets access to what. I also approve all hardware and software purchases.(from companies like yours)




Jim
Users <> Logic
Go to Top of Page

poncho
Yak Posting Veteran

Canada
62 Posts

Posted - 04/08/2004 :  16:11:03  Show Profile
We have a few different systems in 2 divisions. 1 Division has 2 main database apps, HR/Pay and Inventory/Sales/Purchases. Our HR/Pay database is 3rd party and noone but the HR/Pay dept has access to the data. The vendor maintains there own database server offsite and we connect online to do our pay. Our Inv/Sales...is 3rd party as well and I as the IT Director have access to everything, bad move on vendors part, but no sensitive info their, just sales and such.

2nd Division, uses our commercial product on Pervasive and noone besides Application users can view data, and that control is granted by the Division director through the app.

There is network security as well, but I as IT dir have access to all files, but without the actual Database User Id and password cannot view the data. I can however delete files!!(oops).

My issue is not inhouse, but to our customers. Our responsibility and mandate is to provide management applications that allow users to interface with a database via our app only. We cannot provide, nor want to, allow access outside our app. There are strict regulations guiding these issues in Canada. Our customers range from the gov't to private sector.

How can we possibly allow local DBAs access to modify our datastructure? How can we allow DBAs to enter data into via another method? We validate data entered into the database, how can we control that if you bypass our app to enter the data? How can you as a DBA protect yourself against lawsuits from a victim of fraud that claims you the DBA had access to personal information that was used in the fraudulant crime?

Go to Top of Page

poncho
Yak Posting Veteran

Canada
62 Posts

Posted - 04/08/2004 :  16:15:24  Show Profile
"Would you care to put this to the test? I would not make that claim if I was you. Like I said Been there done that."

We have tested....I am not talking about someone taking covert actions and "hacking" the system, noone can claim to have a 100% secure system. However, our databases require a user ID and password to be accessed, period. If you've managed to hack Pervasive databases, more power to you.
Go to Top of Page

poncho
Yak Posting Veteran

Canada
62 Posts

Posted - 04/08/2004 :  16:16:25  Show Profile
"I am the IT Administrator, I determine who gets access to what. I also approve all hardware and software purchases.(from companies like yours)"

BTW So am I....
Go to Top of Page

JimL
SQL Slinging Yak Ranger

USA
1537 Posts

Posted - 04/08/2004 :  16:33:03  Show Profile  Visit JimL's Homepage
quote:
Originally posted by poncho

"I am the IT Administrator, I determine who gets access to what. I also approve all hardware and software purchases.(from companies like yours)"

BTW So am I....




Well then understand these people are trying to help you.

They work with a huge range of front ends and systems.

Given a little respect they will bend over backwards to help you out.(God Knows how many times they have saved my Butt when our CEO wanted something NOW.)

Last but not least if a disgruntiled DBA wanted to mess a company up and knew Pervasive they could make just as much a mess with that.



Jim
Users <> Logic
Go to Top of Page

derrickleggett
Pointy Haired Yak DBA

USA
4184 Posts

Posted - 04/08/2004 :  16:37:27  Show Profile  Visit derrickleggett's Homepage  Send derrickleggett an AOL message  Send derrickleggett a Yahoo! Message
Are you the IT director or the IT administrator?

Noone but the HR/Pay dept has access to the data. The vendor maintains there own database server offsite and we connect online to do our pay.

But their DBA's do have access to anything that's not encrypted, including seeing the data structure.

Our Inv/Sales...is 3rd party as well and I as the IT Director have access to everything, bad move on vendors part, but no sensitive info their, just sales and such.

No, that's how it should be. It's an inventory system. If you shouldn't have access, as the IT directory it would be your responsibility to restrict it. So actually it's a bad move on your part. You should have a backup so it can be recovered if you mess it up. The vendor should charge you exhorbitant amounts of money to fix the database if you mess it up. They could then fire you because you messed it up.

2nd Division, uses our commercial product on Pervasive and noone besides Application users can view data, and that control is granted by the Division director through the app.

Pervasive database security is actually fairly easy to crack, but that's another story. If they did this, it's just like them changing your database structure. They should be fired. You should charge them exhorbitant amounts of money to fix it.

There is network security as well, but I as IT dir have access to all files, but without the actual Database User Id and password cannot view the data. I can however delete files!!(oops).

Only the president of the company should be a full Administrator so there's no chance of this happening. If he deletes the files, they should fire him and sue him for his last two years of pay.

My issue is not inhouse, but to our customers. Our responsibility and mandate is to provide management applications that allow users to interface with a database via our app only. We cannot provide, nor want to, allow access outside our app. There are strict regulations guiding these issues in Canada. Our customers range from the gov't to private sector.

The strict government regulations don't cover what you are trying to do though. Your issue is not inhouse because it's not in your house. In our house, it is our issue though.

How can we possibly allow local DBAs access to modify our datastructure?

You don't. But their account has that access. If they abuse their power, they are fired. You can have a process in place to monitor this if you would like and send a notification every day verifying data structure has or has not changed. That would be a good area for encryption. Have you thought of this? It would work better than Pervasive database security.

How can we allow DBAs to enter data into via another method? We validate data entered into the database, how can we control that if you bypass our app to enter the data?

By validating how the data was entered. This would be a good area for encryption.

How can you as a DBA protect yourself against lawsuits from a victim of fraud that claims you the DBA had access to personal information that was used in the fraudulant crime?

By only doing things through your account so your name is stamped all over it. The accounts that run SQL Server, such as the domain account and sa should be locked up, cryptic, and only used when needed. There should be a log of when and how they were used.

This is part of the risk, and at the same time value, of being a DBA.

Just some things to think about.

MeanOldDBA
derrickleggett@hotmail.com

When life gives you a lemon, fire the DBA.
Go to Top of Page

poncho
Yak Posting Veteran

Canada
62 Posts

Posted - 04/08/2004 :  16:38:54  Show Profile
I do understand that...that's why I came here....but the responses IMO are nonsense...and besides telling me the only way to do it is enryption, noone has convinced me that there is no other way to do it, atleast I hope there is another way! They spent most of the time simply posting that DBAs should have access to everything regardless.....blah blah blah...
Go to Top of Page

derrickleggett
Pointy Haired Yak DBA

USA
4184 Posts

Posted - 04/08/2004 :  16:44:37  Show Profile  Visit derrickleggett's Homepage  Send derrickleggett an AOL message  Send derrickleggett a Yahoo! Message
You know. You can deliver this as an appliance. Have you thought about that? I would still require a review of it to see how much bandwidth you would be taking up.

You basically sell them the entire solution, server and all. You set up the backups, give them a directory to transfer the backup files from, and call it a day.

If anything goes wrong, they call you instead of their DBA. They get their ultra-security. You get the support money to support it.

MeanOldDBA
derrickleggett@hotmail.com

When life gives you a lemon, fire the DBA.
Go to Top of Page

derrickleggett
Pointy Haired Yak DBA

USA
4184 Posts

Posted - 04/08/2004 :  16:45:45  Show Profile  Visit derrickleggett's Homepage  Send derrickleggett an AOL message  Send derrickleggett a Yahoo! Message
The reason we don't like the idea of you putting it on "our" servers for "us" to manage is because we continually get screwed by third-party vendors who don't know how to design a database or stored procedures. I hope you can understant that.



MeanOldDBA
derrickleggett@hotmail.com

When life gives you a lemon, fire the DBA.
Go to Top of Page

poncho
Yak Posting Veteran

Canada
62 Posts

Posted - 04/08/2004 :  16:48:05  Show Profile
"Are you the IT director or the IT administrator?"

IT Director....

"But their DBA's do have access to anything that's not encrypted, including seeing the data structure"

I have never validated that...the agreement is made between the HR dept. and the company they chose to outsource this too. Whether their DBAs have access to the data or not does not concern me, if any issues arise my ass is covered and it's the vendors responsibility to prove that their DBAs aren't the cause, not us! See my point.

What about the smaller clients that don't have inhouse DBAs and that role is fullfilled by a outside consultant...should he have access to the data? And why do you need to be able to read the data to backup it up? Backup operators have access to the physical files for not to Enterprise Admin to ODBC access...

Everything you guys have said doesn't convince me that you need access to the data other than you want it. This may very well be the design of SQL that allows this but I don't see the need for it. Can you view simply by opening the physical file, no...so why do you need to view the data atall?

Go to Top of Page

poncho
Yak Posting Veteran

Canada
62 Posts

Posted - 04/08/2004 :  16:51:01  Show Profile
"You basically sell them the entire solution, server and all. You set up the backups, give them a directory to transfer the backup files from, and call it a day."

That's alomost what we do now...however alot of our clients already own their own SQL servers and when we migrate over to MS SQL from Pervasive they would simply like to integrate onto their existing server and not add a new server to their infrastructure.
Go to Top of Page

poncho
Yak Posting Veteran

Canada
62 Posts

Posted - 04/08/2004 :  16:53:00  Show Profile
"The reason we don't like the idea of you putting it on "our" servers for "us" to manage is because we continually get screwed by third-party vendors who don't know how to design a database or stored procedures. I hope you can understant that."

I understand that....but you have to understand that we're not some Joe blow shop. We do all database support for our customers currently, so we've already tapped into that lucrative market..
Go to Top of Page

derrickleggett
Pointy Haired Yak DBA

USA
4184 Posts

Posted - 04/08/2004 :  17:02:13  Show Profile  Visit derrickleggett's Homepage  Send derrickleggett an AOL message  Send derrickleggett a Yahoo! Message
It sounds like the decision is still up to the customer then. You need to let them know that if they use their existing SQL Server, here are the benefits/costs/risks. Please sign the dotted line. This still gets the responsibility off your shoulders and provides another possible revenue stream.

Isn't that really what you are looking for -- alleviation of risk and broadening of revenue base?

MeanOldDBA
derrickleggett@hotmail.com

When life gives you a lemon, fire the DBA.
Go to Top of Page

poncho
Yak Posting Veteran

Canada
62 Posts

Posted - 04/08/2004 :  18:52:35  Show Profile
"Isn't that really what you are looking for -- alleviation of risk and broadening of revenue base?"

Always....but it's not as simple as that...most of our clients are quite concerned with these issues.
Go to Top of Page

RoLYroLLs
Constraint Violating Yak Guru

USA
255 Posts

Posted - 04/08/2004 :  22:17:27  Show Profile  Visit RoLYroLLs's Homepage
Wow took forever to read every post on here. :)

Anyhow, poncho, I understand your point of view completely, but you said yourself:
quote:
We have tested....I am not talking about someone taking covert actions and "hacking" the system, noone can claim to have a 100% secure system.

And if you are willing to put the database on a companies existing SQL Server, then there is your less than perfect security system. I as an owner/president of a company understand this as well having been both at the DBA level and having the background understanding and knowledge of these issues from both top level executives to DBA's to other employees. You also mentioned that some companies
quote:
don't trust their DBAs with access to their confidential data

Well then that is an issue you must acknowledge the company. If they cannot trust their own DBA's with this sensitive information, then they, as derrickleggett said, should find another trustworthy DBA. It is your client's resposibility to, of course, understand that they are storing sensitive information with your or any other 3rd party products they put to use in their systems and that someone will have access to it one way or another.

In the case I have seen/read in these postings it seems like your 'vital' issue lies within the structure of MS SQL itself. As Tara has mentioned several times
quote:
db_owner role means access to everything

If the existing SQL Server has an untrustworthy DBA, then the clients has to step up to the plate and solve the issue before investing in a data sensitive application. Again, it's a responsibility that lies on the client. I understand that as developers of an application to license to 3rd party user's we need to create measures of security, but if none of these issues can be resolved, then your only other route is to use encryption. Yeah it can be a pain, but sometimes we can't have our cake and eat it too. Advise your clients that the benefit of encrypting the data so their untrustworthy DBA's can't see the data has a performance cost. As a company owner, I'd like to have my cake and eat it too, have the encryption and great performance, but it's a give and take situation.

I hope I have shed some light to your problem, and wish you best in your quest to find more information for a plausible solution.

- RoLY roLLs

Edited by - RoLYroLLs on 04/08/2004 22:22:08
Go to Top of Page

poncho
Yak Posting Veteran

Canada
62 Posts

Posted - 04/08/2004 :  23:16:06  Show Profile
"I hope I have shed some light to your problem, and wish you best in your quest to find more information for a plausible solution."

Thanks for your insightfull post.
Go to Top of Page
Page: of 8 Previous Topic Topic Next Topic  
Previous Page | Next Page
 New Topic  Topic Locked
 Printer Friendly
Jump To:
SQL Server Forums © 2000-2009 SQLTeam Publishing, LLC Go To Top Of Page
This page was generated in 0.25 seconds. Powered By: Snitz Forums 2000