The recorded webcast which I did a couple of weeks ago now is available for viewing on Quest Software’s Web Page. The slide deck is also available for downloading.
The URL is http://www.quest.com/events/listdetails.aspx?contentid=6907&searchoff=true&technology=&prod=24&prodfamily=&loc=
The original webcast was on Feb 7, 2008. More info can be found here.
Arian over on the Sister CISA CISSP blog has a great post entitled Security by Auditor: Don’t Make Me Do It. It’s not specifically focused on databases, but I think that it’s a great read for every DBA.
Don’t forget that the Microsoft Launch Event in Los Angeles is next week. If you are in town, you should try to make it to the event.
You can register here.
In a nutshell Endpoints are ways that people, or applications can connect to the SQL Server. There are several different kinds of end points which can be created; four to be specific. Two are system specific, the SERVICE_BROKER and DATABASE_MIRRORING endpoints can only be used for the SQL Service Broker and Database Mirroring respectively. The other two are for general use. They are the SOAP and TSQL endpoints.
Without knowing it you use an endpoint to connect to the SQL Server each time you connect. There are actually 5 endpoints created by default on each instance of SQL Server. You can check then out by querying the sys.endpoints DMV. When you connect to the SQL Server using TCP (port 1433 by default) you are using the TSQL Default TCP endpoint. By default all users have the rights to connect to this endpoint. You can create other TCP endpoints on different ports for specific users to connect to. This would be handy if you have several applications coming into the SQL Server from a single server, and you wanted to be able to separate there traffic through the firewall so that the network admins could watch the traffic in the event of an issue. You could create a TCP endpoint for each application, and assign only that application IP rights to use that endpoint. You then have the application specify the port number that it will be connecting through in the connection string.
The SOAP endpoints are used in a similar way, but instead of allowing regular TSQL connections they allow SOAP calls to be made directly against the database. (I’m not that up to speed on SOAP so that’s about all I’ve got on that topic.)
Endpoints are created with the CREATE ENDPOINT command with various switches depending on what kind of endpoint you are creating and how much security you require on the endpoint.
The endpoint that I’ve used the most would have to be the service broker endpoint. It’s used to allow SQL Server service broker on one SQL Server to talk to the Service Broker of another SQL Server.
One thing to remember about endpoints is that they are used for inbound connections only. Outbound connections do not require or use an endpoint.