Skip to main content

How to secure connection string of a SQL server in a Winwdows Azure application

English version: http://vunvulearadu.blogspot.ro/2012/06/how-to-secure-connection-string-of-sql_18.html 
Ca si in orice aplicatie, cand dezvoltam aplicatii pentru Windows Azure care sa foloseasca SQL Azure, apare problema securitatii string-ului de conexiune la baza de date (in special la parola). In urmatorul post o sa incerc sa va ofer cateva solutii pentru aceasta problema.
De obicei, cand ajungem spre sfarsitul unui proiect, iar aplicatia noastra se afla deja in productie, ne punem problema cum putem sa separam baza de date care este in productie cu cea care se foloseste pentru development sau pentru testare. Separarea se face destul de usor, folosind connection string-uri diferite, dar nu vrem ca cei de la testare sau din dev. sa aibe access la baza de date din productie, acesta putand sa contina date senzitive pentru utilizator.
Vreau sa atrag atentia ca nu avem mereu nevoie de acest nivel de protectie, deoarece in mod normal intre toti angajatii exista un SLA semnat, dar pentru a proteja clientul si a scadea cat mai mult orice risc este nevoie sa ascundeti aceasta informatie. In schimb daca credeti ca o sa cresteti nivelul de securitate prin encriptarea parolei bazei de date, sa stiti ca acest lucru nu este deloc adevarat. In momentul in care o persoana are acces pe serverul unde aplicatia voastra ruleaza, el poate gasica pe acesta si cheia secreta pentru decriptarea parolei, este o chestiune de timp.
Encriptarea parolei de la baza de date (a string-ului de conexiune) este folositoare pentru a ascunde echipei de dezoltare sau celei de testare credentialele bazei de date din productie, cu conditia ca acestia sa NU AIBE ACCES la mediul de productie.
Varianta prezentata de mine se bazeaza pe certificate. Echipa de dezvoltare o sa aibe cheia publica, pe baza careia poata sa faca pachetul pentru deploy. Pe baza acesteia string-ul de conexiune este encriptat. Administratorul bazei de date SQL o sa aibe cheia publica pe baza careia o sa encripteze string-ul de conexiune si o sa il adauge in fisierul de configurare. Odata parola encriptata, pe baza cheii publice nu se poate decripta string-ul. Pe mediul de productie o sa existe un certificat instalat care contina atat cheia publica, cat si cea privata. Doar cel care are acest certificat poate sa decripteze string-ul nostru.
In urmatoarele randuri o sa incerc sa descriu pe scurt fiecare pas care trebuie facut. Primul pas este crearea unui certificat semnat, acest lucru se poate face din diferite locatii. O varianta este sa folositi comanda din Visual Studio "makecert". In momentul cand o sa creati acest certificat o sa fiti nevoiti sa introduceti o parola care o sa fie folosita pentru a securiza cheia primata.
makecert -r -pe -n "CN=mysecureconfig" -sky exchange "mysecureconfig.cer" -sv "mysecureconfig.pvk"
pvk2pfx -pvk "mysecureconfig.pvk" -spc "mysecureconfig.cer" -pfx "mysecureconfig.pfx" -pi mysecretpassword
"mysecureconfig.cer" reprezinta certificatul vostru (cheia publica), care o sa fie folosit de catre administratorul bazei de date pentru a encripta parola. "mysecureconfig.pvk" reprezinta cheia privata care trebuie sa existe doar in mediul de productie.
Al doilea pas e sa generam un certificat de tip .pfx care o sa fie folosit pentru a putea importa certificatul si cheia privata in Windows Azure.
Odata ce avem aceste certificate create, este nevoie sa importam certificatul mysecureconfig.pfx in Windows Azure. Pentru acest pas este nevoie sa intram pe portalul de Windows Azure, sa selectam tab-ul "Certificates", iar acolo sa incarcam certificatul nostru. La acest pas o sa fie nevoie sa introducem parola care am setat-o in momentul cand am creat certificatul. Dupa ce upload-ul s-a facut cu succes, o sa vi se genereze un thumbprint. De acesta o sa avem nevoie in fisierul de configurare din aplicatia noastra. Pe baza acestuia aplicatia noastra are acces la cheia privata pentru a putea decripta continutul encriptat.
Din momentul in care avem acest certificat, adminstratorul bazei de date poate sa isi instaleze certificatul (cheia publica) si sa encripteze string-ul de conexiune. Nu uitati ca userul care accesza baza de date trebuie sa aibe doar minimul de drepturi necesare si nici unul mai mult.
Acuma vine partea mai interesanta. In fisierul de configurare a aplicatiei noastre este necesar sa adaugam string-ul de conexiune, impreuna cu user si parola si un nou provider pentru protectia datelor. Acesta ar trebui sa arate in felul urmator:
<configProtectedData>
    <providers>
      <add name="PKCS12ProtectedConfigurationProvider" thumbprint="myThumbprintFromWindowsAzurePortal"
           type="Pkcs12PrLinkotectedConfigurationProvider.Pkcs12ProtectedConfigurationProvider, PKCS12ProtectedConfigurationProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=34da007ac91f901d"/>
    </providers>
  </configProtectedData>
In cazul in care nu aveti acest provider instalat (PKCS12ProtectedConfigurationProvider) il puteti instala de la urmatoare adresa: http://archive.msdn.microsoft.com/pkcs12protectedconfg
Sa recapitulam de ce avem nevoie pe masina pe care urmeaza sa encriptam string-ul de conexiune:
  1. certificat instalat
  2. PKCS12ProtectedConfigurationProvider instalat si inregistrat in Global Assembly Cache
  3. string-ul de conexiune adaugat in fisierul de configurare (in acest moment acesta nu este inca encriptat)
  4. providerul de protectie a datelor adaugat in fisierul de configurare
Intr-un command promt de Visual Studio este nevoie sa rulam urmatoarea comanda:
aspnet_regiis -pef "connectionStrings" "." -prov "PKCS12ProtectedConfigurationProvider"
In acest moment string-ul nostru de conexiune la baza de date o sa encriptat si suprascris in fisierul de configurare.
Sa nu uitati sa adaugati assembly-ul "PKCS12ProtectedConfigurationProvider.dll" la solutie, deoarece in web role sau in worker role acesta nu o sa fie instalat.
Prin acest mod, echipa de dezvoltare sau de testare nu o sa aibe acces la baza de date din productie, iar string-ul de conexiune nu o sa le folosesca la nimic.

Comments

Popular posts from this blog

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Entity Framework (EF) TransactionScope vs Database.BeginTransaction

In today blog post we will talk a little about a new feature that is available on EF6+ related to Transactions.
Until now, when we had to use transaction we used ‘TransactionScope’. It works great and I would say that is something that is now in our blood.
using (var scope = new TransactionScope(TransactionScopeOption.Required)) { using (SqlConnection conn = new SqlConnection("...")) { conn.Open(); SqlCommand sqlCommand = new SqlCommand(); sqlCommand.Connection = conn; sqlCommand.CommandText = ... sqlCommand.ExecuteNonQuery(); ... } scope.Complete(); } Starting with EF6.0 we have a new way to work with transactions. The new approach is based on Database.BeginTransaction(), Database.Rollback(), Database.Commit(). Yes, no more TransactionScope.
In the followi…

GET call of REST API that contains '/'-slash character in the value of a parameter

Let’s assume that we have the following scenario: I have a public HTTP endpoint and I need to post some content using GET command. One of the parameters contains special characters like “\” and “/”. If the endpoint is an ApiController than you may have problems if you encode the parameter using the http encoder.
using (var httpClient = new HttpClient()) { httpClient.BaseAddress = baseUrl; Task<HttpResponseMessage> response = httpClient.GetAsync(string.Format("api/foo/{0}", "qwert/qwerqwer"))); response.Wait(); response.Result.EnsureSuccessStatusCode(); } One possible solution would be to encode the query parameter using UrlTokenEncode method of HttpServerUtility class and GetBytes method ofUTF8. In this way you would get the array of bytes of the parameter and encode them as a url token.
The following code show to you how you could write the encode and decode methods.
publ…