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

How to check in AngularJS if a service was register or not

There are cases when you need to check in a service or a controller was register in AngularJS.
For example a valid use case is when you have the same implementation running on multiple application. In this case, you may want to intercept the HTTP provider and add a custom step there. This step don’t needs to run on all the application, only in the one where the service exist and register.
A solution for this case would be to have a flag in the configuration that specify this. In the core you would have an IF that would check the value of this flag.
Another solution is to check if a specific service was register in AngularJS or not. If the service was register that you would execute your own logic.
To check if a service was register or not in AngularJS container you need to call the ‘has’ method of ‘inhector’. It will return TRUE if the service was register.
if ($injector.has('httpInterceptorService')) { $httpProvider.interceptors.push('httpInterceptorService&#…

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 …

Run native .NET application in Docker (.NET Framework 4.6.2)

Scope
The main scope of this post is to see how we can run a legacy application written in .NET Framework in Docker.

Context
First of all, let’s define what is a legacy application in our context. By a legacy application we understand an application that runs .NET Framework 3.5 or higher in a production environment where we don’t have any more the people or documentation that would help us to understand what is happening behind the scene.
In this scenarios, you might want to migrate the current solution from a standard environment to Docker. There are many advantages for such a migration, like:

Continuous DeploymentTestingIsolationSecurity at container levelVersioning ControlEnvironment Standardization
Until now, we didn’t had the possibility to run a .NET application in Docker. With .NET Core, there was support for .NET Core in Docker, but migration from a full .NET framework to .NET Core can be costly and even impossible. Not only because of lack of features, but also because once you…