Security Issues ASP.NET integrated Authentication

Question

We currently use a connection string to authenticate our database credentials. Due to grown and compliance the developers are no longer allowed to "see" the database credentials that our websites use. Are solution to this problem is use Integrated Authentication. We planned on setting up a user per App Pool and then allowing that use access to the Database.

My question is: Are there any security concerns around this approach? As far has removing the DB credentials from the connection string, is there a better(easier or simpler) approach we should/could be taking?

Answer 1

If you need to secure and audit access to the production database then Windows Authentication is a better choice than Sql Authentication for a number of reasons:

1. You can control exactly who can access the database via NT groups and permissions, which means you know who specifically has access to the database. The pool of access with sql authentication is only limited by who knows the password. Given n people who know the password, tracking who did what at a certain point of time is trickier (but not impossible) given that.

2. Only your sysadmins need know the password for the nt identity with access to the database; in fact, much of the config can be done only knowing the username

3. Logins and access can be tracked at the domain level far more easily than with SQL Server logins.

What it wont give you is:

1. Ability to ensure that the developers can't see production data - whoever writes the app can easily include some diagnostic routines to select out data

2. Ensure that production data only stays in production - anyone making a backup of the production database (say to restore it to a UAT environment for testing) could easily expose production data.

Problems with this approach have already been discussed in other posts; in particular, with ASP.Net applications, you have to consider whether or not you are going to use Impersonation/Delegation (webserver can act as the NT user accessing it) or a Trusted User model (where you configure a fixed identity to access certain resources).

This is further complicated by the IIS version you are using.

Answer 2

If your connection string is stored in a web.config file, you could create a separate production version of that file that the deverlopers can't see. That's easier to test and setup than integrated authentication using app pools.

One word of warning though: If you restrict developers that much, it will slow down their velocity of change. Since the rest of the world does keep moving, this usually ends with the application becoming a dead legacy package. That's dangerous if you plan to grow, improve or extend.

Answer 3

Use of application pool's identity can be quite complicated to set up, consider trust and delegation problem. A better option can be securing connection strings using encryption.