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.
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:
Sa recapitulam de ce avem nevoie pe masina pe care urmeaza sa encriptam string-ul de conexiune:
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.
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 mysecretpasswordAl 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>Sa recapitulam de ce avem nevoie pe masina pe care urmeaza sa encriptam string-ul de conexiune:
- certificat instalat
- PKCS12ProtectedConfigurationProvider instalat si inregistrat in Global Assembly Cache
- string-ul de conexiune adaugat in fisierul de configurare (in acest moment acesta nu este inca encriptat)
- providerul de protectie a datelor adaugat in fisierul de configurare
aspnet_regiis -pef "connectionStrings" "." -prov "PKCS12ProtectedConfigurationProvider"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
Post a Comment