SV650.org - SV650 & Gladius 650 Forum

SV650.org - SV650 & Gladius 650 Forum (http://forums.sv650.org/index.php)

- Idle Banter (http://forums.sv650.org/forumdisplay.php?f=116)

- - OMO: MS SQL Server (http://forums.sv650.org/showthread.php?t=223872)

Re: OMO: MS SQL Server

Either they haven't set it up right, i.e. Next, Next, Next, Finish, and they are just using a server admin account for everything, or they don't understand it enough themselves to give you access, without knowing what security impact that has on other customers, so they are scared to give you access, or it could just be a case of computer says no and they are being awkward.

If you are going to multi-tenant a SQL box then you should set up separate instances, unless its multi-tenant at the app level (i.e. a SaaS service) and the customer should never need access to the underlying DB.

Ask them the direct question.... Are we on our own our own SQL instance? If they say no start asking more difficult questions like "How do you secure and separate our data from other tenants?"

Are they ISO27001 accredited? If so they should have implemented RBAC and they shouldn't be using a generic admin account, otherwise they aren't compliant.

Re: OMO: MS SQL Server

Quote:

Originally Posted by stuartb (Post 3053120)

We run a lot of MS SQL databases at work. Normal practise seems to be to setup multiple instances, and then run one or two databases per instance.

It wouldn't surprise me if there were some pretty subtle ways that you could subvert another database if you tried hard enough.

For example, (in Oracle) utl_file can open any files that the database process has access to. So unless you've gone to the trouble of running each instance as a different service account, not making any of them local admins, and setting file ACLs correctly, you can open any file (in a directory that the DBA has permitted). That includes files that control the behaviour of other instances.

Yea but you can do that in any database.

As someone else said, if the whole system (database and underlaying operating system were configured correctly with reasonable planning for who has access to what then it's all easy. If the systems set up sloppily then and perhaps the people with root access aren't the sharpest then administration can sink down the lowest, cheapest common denominator.

If it's an issue why not just go elsewhere? Cloud database providers are ten a penny...

Re: OMO: MS SQL Server

This is enterprise stuff with politics and contracts in the millions.

I was brought in to try and sort out the why/wherefores and was able to engage with the CTO of the outsource provider. The upshot is the DBA who says no does not have the authority to say yes. He works to contact to protect SLA.

The CTO sees the bigger picture, he knows we were recently taken over by a massive organisation who are looking to insource strategic solutions and the contract is currently being renegotiated. We now have a set of proposal on how they are going to meet the requirement.

So nothing to see here anymore. thanks for the advise on SQL Server

Re: OMO: MS SQL Server

executives telling DBA's what security access to allow to a third party on a multi tenant SQL server sounds like a fun day at the office...

Re: OMO: MS SQL Server

Quote:

Originally Posted by timwilky (Post 3053335)

contracts in the millions

Small beer then. The likes of the NHS spend that on one app. Recently saw them contract 43 million on an electronic healthcare record system for three trusts.