Wednesday, December 20, 2006
Top 10 database attacks
Database servers are the most important servers any enterprise company owns. They store client details, financial information, human resource details - all the data that keeps the company in business and, as such, they need to be secure. But probably we already knew that they are subject to wide variety of attacks. British Computer Society lists the most critical of these attacks. The to 10 attacks on Database servers are:
- Excessive privileges
- Privilege abuse
- Unauthorized privilege elevation
- Platform vulnerabilities
- SQL injection
- Weak audit
- Denial of service
- Database protocol vulnerabilities
- Weak authentication
- Exposure of backup data
You can visit this link for more info about the attacks.
Monday, December 04, 2006
Scalable Shared Databases
One more nice reason to migrate to SQL Server 2005 is Scalable Shared Databases (SSD). Microsoft explained about this feature in the KB article 910378 (http://support.microsoft.com/?kbid=910378).
In SQL Server 2000 and older versions, any database is accessible to only one instance. The database can not be shared with the other instance. However, SSD allows us access the same database hosted on SAN from several server instances. That means that read-only workloads can be scaled up by adding additional servers accessing the same database.
This is the excerpt from the Microsoft site about Scalable Shared Databases (SSD).
After the reporting database is built on a set of reporting volumes, the volumes are marked as read-only and mounted to multiple reporting servers. On each reporting server, the reporting database is then attached to an instance of Microsoft SQL Server 2005 and becomes available as a shared scalable database. Once established as a scalable shared database, a reporting database can be shared by clients using different reporting servers. To query the database, a user or application can connect to any server instance to which the database is attached. For a given version of a reporting database, clients on different servers obtain an identical view of the reporting data, making query results consistent across servers.
In SQL Server 2000 and older versions, any database is accessible to only one instance. The database can not be shared with the other instance. However, SSD allows us access the same database hosted on SAN from several server instances. That means that read-only workloads can be scaled up by adding additional servers accessing the same database.
This is the excerpt from the Microsoft site about Scalable Shared Databases (SSD).
The scalable shared database feature allows you to scale out a read-only database built exclusively for reporting purposes (a reporting database). The reporting database must reside on a set of dedicated, read-only volumes whose primary purpose is hosting the database. Using commodity hardware for servers and volumes, you can scale out a reporting database that provides an identical view of the reporting data on multiple reporting servers. This feature also permits a smooth update path for the reporting database.
After the reporting database is built on a set of reporting volumes, the volumes are marked as read-only and mounted to multiple reporting servers. On each reporting server, the reporting database is then attached to an instance of Microsoft SQL Server 2005 and becomes available as a shared scalable database. Once established as a scalable shared database, a reporting database can be shared by clients using different reporting servers. To query the database, a user or application can connect to any server instance to which the database is attached. For a given version of a reporting database, clients on different servers obtain an identical view of the reporting data, making query results consistent across servers.
