<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: How it&#8217;s Done! (Part II): Securing your SQL Server 2005 Database</title>
	<atom:link href="http://blog.de-hao.com/2007/11/21/how-its-done-part-ii-securing-your-sql-server-2005-database/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.de-hao.com/2007/11/21/how-its-done-part-ii-securing-your-sql-server-2005-database/</link>
	<description>IT, eCommerce, Strategy, Web Architecture, Social Networking, Web 2.0+, Start-ups, .NET, C#, SQL Server, jQuery, Flash, Flex, SEO, SaaS, Cloud Computing ------</description>
	<lastBuildDate>Tue, 09 Feb 2010 05:00:02 +0000</lastBuildDate>
	<generator>http://wordpress.com/</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Larry Galbraith</title>
		<link>http://blog.de-hao.com/2007/11/21/how-its-done-part-ii-securing-your-sql-server-2005-database/#comment-18</link>
		<dc:creator>Larry Galbraith</dc:creator>
		<pubDate>Fri, 14 Dec 2007 15:56:37 +0000</pubDate>
		<guid isPermaLink="false">http://dehao.wordpress.com/2007/11/21/how-its-done-part-ii-securing-your-sql-server-2005-database/#comment-18</guid>
		<description>Oh, I am not a developer because I am doing mostly administrative tasks with SQL. But I can say the same about myself.  I completely agree with you that it&#039;s very important to  &quot;always use a strong password for the sa account and change the sa account password periodically&quot; and rename it to narrow down the surface for an attacker. But the reality is that I usually have to weaken security in some cases. Sometimes it&#039;s needed for some users, sometimes it&#039;s needed to allow software that works with SQL to be able to work with the database. There are many reasons some of them are important, some less important but the essence is that you have to make security weaker. Sometimes. But it always hard to restore the strong security back to the proper solid state when everything is aligned across security settings for every table and every DB. Again, sometimes I have to provide the user with different access settings for different SQ L instances. And then this user has to change something somewhere and it goes further on and on. That&#039;s how you usually get security hole in your SQL perimeter. I really appreciate when someone like you posts guides and best practices like this as it allows to get things sorted without the need to re-invent the wheel. The back side of security management in SQL is that SQL Management studio exposes just a tenth fraction of percent of tool that you have to have under your fingers. But not all is that bad. Recently I came across the tool from Scriptlogic called Security Explorer http://www.scriptlogic.com/products/security-explorer/sql-server/ that allows managing SQL security and search for security breaches for a selected server or instance remotely. The great thing to me is (keeping with the practice we&#039;ve been talking above) that it can search for local admin accounts that have been renamed. As admin I know how important is to have a proper guide and tool at the hand.</description>
		<content:encoded><![CDATA[<p>Oh, I am not a developer because I am doing mostly administrative tasks with SQL. But I can say the same about myself.  I completely agree with you that it&#8217;s very important to  &#8220;always use a strong password for the sa account and change the sa account password periodically&#8221; and rename it to narrow down the surface for an attacker. But the reality is that I usually have to weaken security in some cases. Sometimes it&#8217;s needed for some users, sometimes it&#8217;s needed to allow software that works with SQL to be able to work with the database. There are many reasons some of them are important, some less important but the essence is that you have to make security weaker. Sometimes. But it always hard to restore the strong security back to the proper solid state when everything is aligned across security settings for every table and every DB. Again, sometimes I have to provide the user with different access settings for different SQ L instances. And then this user has to change something somewhere and it goes further on and on. That&#8217;s how you usually get security hole in your SQL perimeter. I really appreciate when someone like you posts guides and best practices like this as it allows to get things sorted without the need to re-invent the wheel. The back side of security management in SQL is that SQL Management studio exposes just a tenth fraction of percent of tool that you have to have under your fingers. But not all is that bad. Recently I came across the tool from Scriptlogic called Security Explorer <a href="http://www.scriptlogic.com/products/security-explorer/sql-server/" rel="nofollow">http://www.scriptlogic.com/products/security-explorer/sql-server/</a> that allows managing SQL security and search for security breaches for a selected server or instance remotely. The great thing to me is (keeping with the practice we&#8217;ve been talking above) that it can search for local admin accounts that have been renamed. As admin I know how important is to have a proper guide and tool at the hand.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
