Is it possible to encrypt a database connection string and deploy it to a Windows Azure Website? (NOT a Windows Azure Web Role) If so, how?
The reason I ask is because I can't find examples or documentation anywhere as to how to perform this specifically with Azure Websites. (I'd like to use the "Shared" web site mode)
I have found the following resources, which come close to what I want, but utilize Web Roles instead of Websites:
http://archive.msdn.microsoft.com/pkcs12protectedconfg
http://blogs.msdn.com/b/windowsazure/archive/2010/09/09/securing-your-connection-string-in-windows-azure-part-3.aspx
The proper way to use connection strings on Azure Websites is to add "debug" connection strings to your web.config file (and by "debug" it can be a local db/storage or any string that is safe to share - empty string).
On the Azure portal go to your Azure website --> CONFIGURE tab and under connection strings sections add your actual connection strings with the same names as used in your web.config file, there the connection string are saved as encrypted strings.
The website code will get the proper connection string you set in the Azure portal.
Related
I have an ASP.NET Core 2.0 WebAPI application that has Db ConnectionString in appSettings.json.
While in development it has this value:
"DefaultConnection":"Server=localhost;Database=Tyroll;Trusted_Connection=True;MultipleActiveResultSets=true"
and only when we publish it to production we change this with appropriate passwords, by using VS 2017 publish profile.
So SQL server passwords for are not stored on repository and no problem there.
The file appsettings.json is protected by IIS
The question I wonder is should this password be somehow 'hidden' even on IIS?
One reason being additional security, so that SQL credentials are not in plain text in case of breach here.
Another for some authorization scenario where IIS admin should not have directly access to SQL server.
I figure it could be encrypted and the app itself will have key for decrypting it. This would not be 100% secure since in the case of breach on IIS even this key could be reverse engineered from the app, but it would make it more difficult then when it's there in plain text.
So first question is should I be doing this at all?
And second if 1.Q is Yes, what would be the best / recommended way to do it?
Is there some built in tool for this in .NetCore2 or VS2017 or IIS, or some other tool?
Here are some related links:
reddit aspnet_core_appsettingsjson_security_question
stackoverflow is-appsettings-json-protected-by-iis
itprotoday passwords-webconfig
keeping-secrets-in-asp-net-core
I would suggest that you should user Active Directory Integrated security for accessing the database , the App Pool can run under the user account and that particular user account will only have the required access to the database . This safeguards the user credentials in case of an attack since the password is never exposed.
Solution I implemented is making custom encryption of Password in ConnectionString.
But since the App needs to the decrypt it, it is more an Obfuscation.
For encryption I have used AES (using System.Security.Cryptography) and the key is stored: half in connectionString itself and other half hardCoded in the Application.
In addition regex was used to extract Password from ConnectionString and then was replaced with decrypted string of it.
I have an ASP.NET web project, and I've placed a dummy connection string in my web.config file pointing to an Azure Sql database.
<add name="YurClanConnection" connectionString="Placeholder connection string" providerName="System.Data.SqlClient" />
See this article for the reasoning behind this:
http://www.hanselman.com/blog/HowToKeepYourASPNETDatabaseConnectionStringsSecureWhenDeployingToAzureFromSource.aspx
This works in production--the real connection string stored on Azure servers replaces the placeholder connection string in my project. From what I've read, putting your connection in Azure under Websites-Config in the app settings, stored as key/value pairs, is the right way to secure your connection string when using an Azure Sql database. However, this does not work in development.
What is the right way to store a connection string securely so that it works properly in both development and production, specifically when using an Azure Sql database?
Here is how I have worked with databases locally and in Azure.
On the dev machine, have a database and your connections string
In Azure, create an Azure SQL database (or any other kind of database)
Go to the Web App Settings in Azure and scroll down to the section where you have connection strings and input the connection string for your db in Azure
Save and you should be fine.
I have come across this excellent blog explaining how to encrypt/decrypt the database connection string with a PKCS12ProtectedConfigurationProvider inside Azure Cloud.
http://social.technet.microsoft.com/wiki/contents/articles/sql-azure-connection-security.aspx#create_aspnet
Is this something that should be done, or is it rather security overkill?
If Web.config cannot be accessed from internet due IIS restrictions, nobody would be able to read the DB connection string (incl. password etc) inside the Web.config anyway, so why bother to encrypt it in first place?
Many Thanks,
I think it is the same argument as when considering encrypting connection strings outside Windows Azure, which is - who has access to the box.
I have been talking to organisations who had several people with access to the box, which would allow them to see the web.config and extract the credentials for the databases, in places where you don't want system administrators/developers/etc accessing your database, this makes sense.
If you are the only one with access to the instance or if that is not a concern of yours, you don't have to worry about it
Working with Azure web role that communicates to a SQL Azure database. Currently when I generate an edmx file for the SQL Azure database the connection strings + the username password are added to web.config file. I did a search and there were several entries on how to encrypt web.config/how to use that to switch between dev and prod but I am thinking of moving conn string out of web.config.
Is there a way by which I can move the connection string to the service definition file? Is that a recommended approach? If I move the connection string elsewhere can I still use the edmx and generated objectcontext classes (cause my existing code uses the automatically generated entity class).
It is best to move your connection strings into service config file. This allows you to switch over to a different SQL Azure database w/o redeployment. Switching to a different SQL Azure database w/o redeployment is useful when one has crashed or is timing out and you have a backup ready on a different server to switch over to.
You will need to initialize your object contexts by providing the connection string separately however.
Use the RoleEnvironment.IsAvailable to find out if you're running under Azure and the following code to read the setting in .cscfg:
var connectionString = RoleEnvironment.GetConfigurationSettingValue("ConnectionString");
I recommend having the connection string in both places, Service Configuration file (.cscfg) and Web.config. Where I also recommend from the beginning to have your web role able to run outside an Azure environment. It will impact your productivity in the long run. Especially with daily development where you do small changes and need to run the project locally to verify. Running your service locally in IIS, IIS express or Cassini (the codename for the Asp.net env) is currently faster than running your project in the local azure emulator (the devFabric).
Regarding your second question about storing the username and password. It all depends on the level of security that you're looking for. The information stored inside your .cscfg are transmitted over https and secured in the Azure cloud the same way your application is secured. That being said, I would store the TEST account credentials in the project for testing and would only put the PRODUCTION storage account credentials in the .cscfg at deployment time to the public/production service.
Our ASP.Net application uses SQL Server 2008. Most of the time the application connects to SQL Server using a SQL account with very limited access rights.
However once in a while we need to be able to create a new database on the fly. As such we need elevated permissions and I am a little nervous about storing this connection string in Web.config, which may be in a DMZ.
We are considering writing a Windows service to run on the SQL Server machine (i.e. not in the DMZ) which will monitor a table for requests to create a new database, but it seems like overkill.
Any suggestions for alternatives or recommended practices?
You can store the connection string in the registry and protect that by limiting access to the specified registry keys. That's one of the ideasI ran across back in .Net 1.1 as a reccomendation from Microsoft. The concept is still the same in 2.0 and up. Here's a link to the documentation.
http://msdn.microsoft.com/en-us/library/aa302406.aspx
It sounds like you're already concerned about security, so I'm guessing you've read through or at least run across the "Building Secure ASP.Net applications" section of the MSDN library. The link above is in the how-To section of that guide. Hopefully this is helpful.
Also, if you DO store your connection info in the web.config, at a minimum, encrypt those portions.
And I just ran across this. Probably more like what you were looking for.
http://msdn.microsoft.com/en-us/library/aa302388.aspx#secnetch08_storingsecrets
If you are using mixed mode authentication in your database connection strings (I.E., username and password) then you should encrypt the web.config connectionStrings element.
What about using a stored procedure to create the database? I haven't tried it; the one part I'm worried about is specifying the database name through a variable. By using the stored proc, you only need to grant your web id execute access on the stored proc.
Another option would be to create a console app (instead of a service). Then use a job scheduler to run the job every 15 or 30 minutes or upon request if you have a capable scheduler. That will be much simpler than writing a service; it just isn't an "instant" process. I do this for some Active Directory work that triggers off of web site updates (I didn't want to give my web id Domain Admin priveleges).