I need help - communicating to our MD why I'm so stressed about our external developers accessing our production sql2000 server. Especially using the sa account.
I accept they wrote our company's data-based web-site, but my suggestions that there scripting fluency is 'applications' orientated, and that they know little of 'systems' seems to draw blanks all round (and shrugs like 'well, they wrote it').
My attempts at plain english have proved totally ineffective.
I'm hopeing someone knows of an 'Executive' document somewere that'll help me stop this cavalear practice (using 'sa').
Not a good situation.
You need to take control. Restricting the use of 'sa' is a question of security, especially with multiple people using the account. If you audit your system and the best you can tell someone is that 'dbo' or someone using 'sa' was the last id to look at or change some item then this is of no value. If 'Joe' signs on 'Joe' should leave a trace of what he did that is separate and identifiable from the actions that 'Jane' did. 'Joe' and 'Jane' need to be given only the access they require. More can be given later if it is needed. Change the sa password imedicately and if someone complains ensure they have a specific id that personally identifies them and give them only the access they require. If these developeers are external to the company you could create a single id for them to share if this is easier to manage.
Don't even ask permission for this. Tell everyone prior to doing it and tell everyone to start using their own id. If there is a test server then you need to get everyone to start using test not production. When all changes are ready in test, the DBA moves them to production (use ALTER scripts). If no test server exists get one soon. Good luck
Edited by - fhanlon on 11/18/2003 2:13:54 PM
I had a similar problem and the same discussion. In the end I reached a compromise which was to take away the use of sa by changing the password and not telling anyone and agreeing that in time they software suppliers may need sysadmin on the box but and I would have to agree with that if the situation arose. In the meantime at least I could audit what they were doing by giving them there own account. Why are 3rd parties so afraid of being audited?!
I'm inclined to argue that they don't want to know their own poor programming
Microsoft SQL Server MVP
My blog: http://www.insidesql.org/blogs/frankkalis/[/url]
grab "the best of sqlservercentral.com 2002", you'll find more info regarding this.
maybe a search on this site gets you in the right direction.
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
Richard, you are on the right track - find a whitepaper or some other industry recognizable source and use it as your backup. Simply going in and locking everyone out will not help - this is not only about security it is also about change management. If you unilaterally change the password and lock out the developers I'd bet a paycheck that you will be forced to back it out, and the resultant loss of face on your part will make it so you can never be truly effective. There are many papers/articles on the web, I'm not going to recommend one; instead I'm going to suggest you read them all and pick the one that best suits your organization.
Thanks, and don't forget to Chuckle
Thanks, and don't forget to Chuckle
It takes time. Making things secure almost always slows things down (or appears to). I'd recommend that you talk them into letting you change the sa password, give the most senior developers sysadmin access via their NT login. It's a start. They've gone a long time doing it wrong, dont try to fix it all in a day if they are going to fight you.
Picking the best document out there for your situation is a good diplomatic effort inner-office, but I like Andy Warren's suggestion for dealing with the developers also for diplomatic reasons. If you make them part of the 'in' crowd, at least initially, you can approach it as if they are your partner in making your systems secure.
Another concept to stick to is to express things in terms the person you are talking to can not just understand the words of, but hears their own cares in. Whether it's a play on fear, profit, or whatnot- it has to be what they care about. Scare a business member about profit margin and they'll usually react. If they think there is too much trust between them and the 3rd party, don't bother fighting it just pull them both into the fold. If the 3rd party betrays the trust, saying 'They were specifically granted total access' is much better than saying 'There is no security from anyone on your server'.
Viewing 8 posts - 1 through 7 (of 7 total)