Comments on: DBAs: What Do You Do When Major Installations Require Sysadmin Access? http://blog.netnerds.net/2007/08/dbas-what-do-you-do-when-major-installations-require-sysadmin-access/ ls /usr/lolcat Wed, 07 Jan 2009 14:00:30 +0000 http://wordpress.org/?v=2.3.1 By: Aaron http://blog.netnerds.net/2007/08/dbas-what-do-you-do-when-major-installations-require-sysadmin-access/#comment-765 Aaron Wed, 26 Sep 2007 22:54:06 +0000 http://blog.netnerds.net/2007/08/dbas-what-do-you-do-when-major-installations-require-sysadmin-access/#comment-765 I like Rich's approach a lot and at my previous job we instituted a policy that IT could not and would not provide for or support any software which hadn't been approved. At the new company it's a little harder to make that fly as they're still on a model of "We bought it, you implement it!" But we're starting to change that mindset. What I've tried to do is split off the individual applications that I consider to be the most problemmatic onto their own instances. Luckily I've only found a few, and honestly when I actually push the support people I can usually get different answers. For instance we were setting up the Blackberry Enterprise management suite and they wanted the account it installed/ran under to have sa. After about 45 minutes on the phone I was able to get them to admit that it really only needed dbo to their primary database and execute permissions on a few other procedures. Sysadmin rights were only required during installation and could be backed off later. That's a little more than I'm used to (I'm not against giving a service db_creator) but at least that was a reasonable compromise... however it's not documented at all in the docs we were sent with the product. We also had the management system for our point-of-sale systems at the last job (the casino) which had numerous sql accounts created with blank passwords, etc... When I did a security evaluation of that box it raised some serious red flags. It took about four hours on the phone with their support and some threats but eventually they sent us an internal tool that would enable us to change how the various services they had connected to SQL and then we could set strong passwords. Though at other times... their design just sucks. I like Rich's approach a lot and at my previous job we instituted a policy that IT could not and would not provide for or support any software which hadn't been approved. At the new company it's a little harder to make that fly as they're still on a model of "We bought it, you implement it!" But we're starting to change that mindset.

What I've tried to do is split off the individual applications that I consider to be the most problemmatic onto their own instances. Luckily I've only found a few, and honestly when I actually push the support people I can usually get different answers. For instance we were setting up the Blackberry Enterprise management suite and they wanted the account it installed/ran under to have sa. After about 45 minutes on the phone I was able to get them to admit that it really only needed dbo to their primary database and execute permissions on a few other procedures. Sysadmin rights were only required during installation and could be backed off later. That's a little more than I'm used to (I'm not against giving a service db_creator) but at least that was a reasonable compromise... however it's not documented at all in the docs we were sent with the product.

We also had the management system for our point-of-sale systems at the last job (the casino) which had numerous sql accounts created with blank passwords, etc... When I did a security evaluation of that box it raised some serious red flags. It took about four hours on the phone with their support and some threats but eventually they sent us an internal tool that would enable us to change how the various services they had connected to SQL and then we could set strong passwords.

Though at other times... their design just sucks.

]]> By: Rich http://blog.netnerds.net/2007/08/dbas-what-do-you-do-when-major-installations-require-sysadmin-access/#comment-764 Rich Sun, 19 Aug 2007 04:52:01 +0000 http://blog.netnerds.net/2007/08/dbas-what-do-you-do-when-major-installations-require-sysadmin-access/#comment-764 After being burnt in similar ways, several times in the past, we now require that all software is approved by our IT Techical Design Team before purchasing. We have set out a list key Technical Acceptance Criteria that any software must meet before purchase is considered. One of the criteria, at least on the client side, is that the software must run under the context of a domain user and require no elevated priveleges. It is amazing how may software vendors still supply software that requires local administrative privileges. Software like that gets binned straight away. This has required a massive cultural shift in our organisation since individual departments were previously accustomed to just going out and buying a piece of software that they thought would work for them and installing it on their workstations. Now, however, we run a completely secure, locked down Terminal Services environment supporting 7000 users and all workstations have been replaced with Wyse Terminals. Departments must now apply to the IT Department with a business case for their software. Once this has been examined, two or three different vendors are considered and the software tested to ensure that they meet our Technical Acceptance Criteria. Only once this has been done is one vendor chosen and the software deployed on the Terminal Servers. After being burnt in similar ways, several times in the past, we now require that all software is approved by our IT Techical Design Team before purchasing.

We have set out a list key Technical Acceptance Criteria that any software must meet before purchase is considered.

One of the criteria, at least on the client side, is that the software must run under the context of a domain user and require no elevated priveleges. It is amazing how may software vendors still supply software that requires local administrative privileges. Software like that gets binned straight away.

This has required a massive cultural shift in our organisation since individual departments were previously accustomed to just going out and buying a piece of software that they thought would work for them and installing it on their workstations.

Now, however, we run a completely secure, locked down Terminal Services environment supporting 7000 users and all workstations have been replaced with Wyse Terminals.

Departments must now apply to the IT Department with a business case for their software. Once this has been examined, two or three different vendors are considered and the software tested to ensure that they meet our Technical Acceptance Criteria. Only once this has been done is one vendor chosen and the software deployed on the Terminal Servers.

]]>