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

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP