如何将Excel安全连接到sql server 2008？

Question

My company wants to have approximately 100 of their sales people (distributed around the country) to be able to run stored procedures from excel and return the data onto the spreadsheet.

We have sql server 2008. i need to figure out a safe way to do this.

i will create a form in excel where the user can push a command button to refresh the data based on the parameters that they choose.

1. how can i ensure that the connection from excel to the sql server is secure?
2. how do i run a stored procedure from excel?

i found this to be very good information: http://office.microsoft.com/en-us/excel-help/connect-to-import-sql-server-data-HA010217956.aspx

Windows Authentication Select this option to use the Windows user name and password of the current user. This is the most secure method, but it can affect performance when many users are connected to the server.

however, i would like your input on this.

yes, the sales reps do have windows logins, but can i use this solution if they will actually be entering specifying the data criteria, then sending the criteria over into the stored procedure and then getting the data from the server?

Answer 1

Allowing users direct connections to your database is tricky. First off, you expose yourself to attack from without, as user accounts are compromised more frequently than well-isolated admin and service accounts. Having said that, the user account does need to be compromised to allow an attacker into the system, and you have good granularity of control built into SQL Server if every user has their own credentials.

Using the Excel-native interfaces isn't that different from doing it via VBA or VSTA, which is how most developers did it for the last decade or so. Those methods are about as secure as your network. I believe the Excel-native functionality works without extraneous references, as well, which is particularly nice for maintenance purposes. The main difference seems to be in the ability to do arbitrary queries. For security and data integrity purposes, this is probably for the best.

Running a stored procedure is probably not a good idea, as you can get into massive support requirements if your users start needing(wanting) tweaks frequently. Can you make do with a view? Excel's inbuilt filtering and sorting abilities are pretty powerful. That would be my first approach.

There are several approaches depending on your needs:

1 - modify your schema to allow the database to tie data to individual users

2 - move the access code into a VBA macro associated to the workbook. This is not recommended, but it will allow you to use ADO directly. Be SURE you have a solid security configuration on the database side if you do this, as an attacker who gains access to a user's account will be able to do anything that user can do.

To go the VBA route, in the VBA environment Tools->References to find the latest Microsoft ADO version. The VBA code looks something like this:

Dim Connection as ADODB.Connection
Set Connection = new ADODB.Connection
Connection.Open"Provider=SQLNCLI;Server=myServerAddress;Database=myDataBase;Trusted_Connection=yes;"
Dim command As ADODB.command
command.CommandText = "exec sp_something"
Dim Parameters(2) As ADODB.Parameter

Set Parameters(1) = New ADODB.Parameter
Parameters(1).Name = "field_name"
Parameters(1).Type = adVarChar
Parameters(1).Size = 50

Set Parameters(2) = New ADODB.Parameter
Parameters(2).Name = "field_name_2"
Parameters(2).Type = adVarChar
Parameters(2).Size = 50

Dim i As Integer
For i = LBound(Parameters) To UBound(Parameters)
    command.Parameters.Append Parameters(i)
Next i

Dim Records As ADODB.Recordset
Set Records = command.Execute

Tie that macro to your button, set up your values via the sheet or an input box, and fire away. But I'll repeat my warning: Going this way leads to massive support requirements. If people want to extract custom data, then they get very particular about it.

Answer 2

Instead of the article you linked, I'd rather use VBA script with reference to the ADO library and a normal connection string with a technical SQL user.

Since the password would be in the connection string in this case, this technical user should have no other rights than executing your stored procedures.

Let me know if you need more details.