Recomand ări privind securitatea [609175]

Charisma HCM 
Recomand ări privind securitatea

2 
 
Cuprins 
 
1. Securitatea  serverului  de aplicații ………………………………………………………………………………………………………….  3 
1.1  Serverul de aplicații ‐ informații generale ………………………………………………………………………………………..  3 
1.2  Serverul de baze de date ……………………………………………………………………………………………………………….  4 
1.3  Serverul de aplicații web ……………………………………………………………………………………………………………….  5 
1.4  Serverele  de conectare  desktop de la distanta ……………………………………………………………………………….  13 
2. Securitatea  la nivel de baze de date …………………………………………………………………………………………………….  13 
2.1  Criptarea stocării ………………………………………………………………………………………………………………. ………. 13 
2.1.1  Scenariul de utilizare 1 ‐ Activarea  TDE pentru o bază de date necriptată ………………………………….  14 
2.1.2  Scenariul de utilizare 2 ‐ Dezactivarea  TDE pentru o bază de date criptată ………………………………..  17 
2.1.3  Scenariul de utilizare 3 ‐ Reactivarea  TDE pentru o bază de date cu criptarea dezactivat ă ………….. 17 
2.1.4  Scenariul de utilizare 4 ‐ Eliminarea  TDE dintr‐o bază de date cu criptarea activată ……………………  18 
2.1.5  Scenariul de utilizare 5 ‐ Migrarea bazei de date criptate cu TDE în altă instanță SQL Server ………. 19 
2.2  Rolurile și permisiunile  ………………………………………………………………………………………………………………. . 20 
2.2.1  Rolurile fixe în baza de date ………………………………………………………………………………………………….  21 
2.2.2  Rolurile fixe la nivel de server ……………………………………………………………………………………………….  21 
2.2.3  Rolul fix SQL Server Agent în baza de date ……………………………………………………………………………..  22 
2.2.4  Permisiunile  bazei de date ……………………………………………………………………………………………………  22 
3. Securitatea  la nivel de rețea ………………………………………………………………………………………………………………. . 24 
3.1  Segmentarea  rețelei ………………………………………………………………………………………………………………. ….. 25 
3.2  Comunicarea  securizată ………………………………………………………………………………………………………………  26 
3.2.1  Rețeaua privată virtuală (VPN) ………………………………………………………………………………………………  26 
3.2.2  Comunicarea  HTTPS …………………………………………………………………………………………………………….  26 
3.2.3  Conexiunile  desktop de la distanță ………………………………………………………………………………………..  26 
3.2.4  Protocolul  de transfer securizat al fișierelor (SFTP) ………………………………………………………………….  27 
3.3  Monitorizarea  securității rețelei …………………………………………………………………………………………………..  27 
3.3.1  Sistemul de prevenire  și de detectare  a intruziunilor  ………………………………………………………………  27 
3.3.2  Breșele de securitate  și de date …………………………………………………………………………………………….  28 
3.3.3  Prevenirea  pierderii datelor ………………………………………………………………………………………………….  30 
4. Concluzii ………………………………………………………………………………………………………………. …………………………..  30 
Referințe ………………………………………………………………………………………………………………. …………………………………  31

3 
 
Declinarea  responsabilit ății  
 
Acest document  își propune să detalieze o listă a celor mai bune practici pe care le recomand ă TotalSoft 
pentru securizarea  mai bună a straturilor,  fizice și logice, care au impact asupra securității și confidențialității 
datelor procesate  de produsele  Charisma HCM. Documentul  are un scop exclusiv informativ  și descrie măsurile de 
securitate  comune, pe care echipa noastră tehnică le recomand ă clienților noștri pentru a securiza mai bine 
mediile de la sediu. Aceste recomand ări trebuie analizate de echipa tehnică a clientului,  deoarece  nu toate se 
aplică implement ării și infrastructurii  specifice clientului,  inclusiv versiunii și ediției de SQL Server. De asemenea,  
clientul trebuie să analizeze și să ia în considerare  măsuri suplimentare  și proceduri  de implementat  pentru a 
asigura conformitatea  cu Regulamentul  General privind Protecția Datelor (GDPR). Lista de recomand ări din acest 
document  nu înlocuiește nevoia unei analize temeinice  a cerințelor GDPR, care sunt specifice fiecărei organizații. 
    
 
1. Securitatea  serverului  de aplicații 
 
1.1 Serverul de aplicații ‐ informații generale 
 
Această secțiune vizează practici generale de securitate,  care pot fi aplicate oricărui tip de server. În 
scopul securizării serverelor  de aplicații ce găzduiesc logică de business, servicii de acces la date, aplicații web sau 
servere de baze de date, trebuie luate în considerare  următoarele recomand ări: 
1. Actualiza ți serverul de aplicații cu cele mai recente pachete de servicii și patch‐uri. 
2. Instalați și rulați Microsoft  IIS Lockdown  Wizard , instrument  care ajută la automatizarea  anumitor pași 
de securitate  și dezactiveaz ă caracteristicile  și serviciile IIS inutile, pe baza tipului de software de server pe 
care îl folosiți. 
3. Instalați și rulați URLScan , un filtru ISAPI care analizează cererile HTTP pe măsură ce IIS le primește și 
respinge toate cererile suspecte,  pe baza unui set configurabil  de reguli. 
4. Opriți sau restricționați servicii Windows  dacă nu sunt utilizate în producție. Serviciile Windows  sunt 
vulnerabile  pentru atacatorii  care pot exploata privilegiile  și capacitățile serviciilor  și pot obține acces la 
resursele locale și la distanță ale sistemului.  Ca măsură de apărare, dezactiva ți serviciile Windows  de care 
sistemele  și aplicațiile dvs. nu au nevoie. 
5. Restricționați accesul la regiștrii sistemului  de operare .  
 Cheia Winreg stabilește dacă cheile din registry sunt disponibile  pentru acces de la distanță. În 
mod prestabilit,  această cheie este configurat ă pentru a împiedica  utilizatorii  să vizualizeze  de la 
distanță majoritatea  cheilor din registry. Pentru a stabili și a modifica cine poate accesa de la 
distanță  registry‐ul,  navigați  la  HKEY_LOCAL_MACHINE  
\SYSTEM\CurrentControlSet\Cont rol\SecurePipeServers\winreg  și setați permisiunea  (clic dreapta) 
din meniul Securitate.   
 În plus, este important  să securizați SAM (Security Accounts Manager),  care se aplică doar pentru 
serverele autonome.  Fișierul registry stochează parolele utilizatorilor  în format hash, în baza de

4 
 
date SAM locală. Pentru a restricționa stocarea LMHash în SAM, pentru Windows  2000 SP2 și 
versiuni  mai  recente,  navigați  la 
HKEY_LOCAL_MACHINE\SYSTEM\Current ControlSet\Control\LSA\NoLMHash  și creați o cheie (fără 
valoare) NoLMHash . Pentru Windows  XP și Windows  Server 2003, navigați la 
HKEY_LOCAL_MACHINE\SYSTEM\C urrentControlSet\Control\LSA\  și adăugați valoarea DWORD cu 
numele: NoLMHash  și valoarea: 1 
6. Auditați încercările de conectare  eșuate pe server . Aceasta nu este o măsură de securitate,  dar este 
important  să țineți permanent  evidenta sistemului,  pentru a identifica potențialele breșe de securitate.  
Pentru a înregistra  toate conectările eșuate pe server, este necesar să deschideți secțiunea Local Security 
Policy , Local Policies > Audit Policy > Audit logon events și să bifați opțiunea Failure . Conectările eșuate vor 
fi disponibile  în Event viewer > Windows Logs > Security . 
7. Plasați directoarele  virtuale și "web root" pe un volum de partiție separat fată de sistemul de operare . 
8. Maparea  script‐urilor : Maparea fișierelor IIS și .NET Framework.  
9. Eliminați filtrele ISAPI inutile . 
10. Restricționați accesul la metabaza  IIS, calea: C:\WINDOWS\system32\inetsrv,  astfel încât configura ția IIS 
să nu poată fi modificat ă. 
11. Securizați comunicarea  utilizând certificate  de securitate  pe server . Un certificat valid oferă 
autentificare  securizată, astfel încât un client să aibă garanția comunicării securizate  dintre server și 
acesta. Pentru a configura  serverul să utilizeze un certificat SSL, urmați acești pași: 
 Deschideți Internet Information  Services (IIS) Manager și faceți clic pe numele serverului;  
 Accesați Server Certificate  (panoul central); 
 În Server Certificate , în meniul Actions (panoul din dreapta), faceți clic pe Complete  Certificate  
Request ; 
 În expertul Complete  Certificate  Request , setați certificatul  (File name containing  the certificate  
authority’s  response)  și dați‐i un nume intuitiv, pentru a‐l identifica (Friendly name); 
 Extindeți numele serverului  pe care a fost instalat certificatul  și selectați site‐ul pentru care 
trebuie securizată comunicarea  (Default Web Site); 
 Din meniul Actions (panoul din dreapta), selectați Binding ; 
 În Site Binding , faceți clic pe Add, apoi completa ți tipul (https), adresa IP (All Unassigned),  portul 
(443) și certificatul  (SSL certificate);  
12. Securizați machine.config , calea %windir%\Microsoft.NET\Framework\[versiunea]\Config.  
 
1.2 Serverul de baze de date 
 
  Principalele  aspecte care trebuie luate în considerare  în ce privește securitatea  bazelor de date sunt 
următoarele: 
1. Asigurați securitatea  fizică a bazei de date . Este recomandabil  ca serverul de aplicații și web să nu fie 
găzduite pe același calculator  cu serverul de baze de date. 
2. Securizați sistemul de operare cu un firewall și blocați sau restricționați accesul la fiecare port, cu 
excepția celor care comunică cu aplicațiile ce rezidă pe server . Singurul trafic permis trebuie să

5 
 
provină de la aplicațiile care trebuie să acceseze datele. Regulile firewall‐ului trebuie să fie întreținute 
și examinate  de administratorul  de sistem și al bazei de date și nu trebuie să permită conexiuni  de 
ieșire decât dacă există o necesitate  specifică. 
3. Securizați conturile de utilizatori  ale administratorilor  bazei de date și impuneți politici pentru 
parole complexe . Trebuie ca scopul dvs. să fie să aveți cel mai mic număr posibil de persoane  cu 
acces la baza de date. Conturile trebuie să fie individuale,  nu un cont de grup partajat. Important:  
Schimbarea  parolei pentru conturile de utilizatori  de baze de date are un impact major asupra 
aplicațiilor Charisma,  deci este recomandat  să contactați furnizorul  pentru suportul corespunz ător. 
4. Auditați încercările de conectare  eșuate . Aceasta nu este o măsură de securitate,  dar este important  
să țineți permanent  evidenta sistemului,  pentru a identifica potențialele breșe de securitate.  Acest 
lucru implică monitorizarea  conectărilor eșuate la baza de date și examinarea  regulată a jurnalelor,  
pentru detectarea  activității anormale.  Pentru a activa auditarea,  accesați Server Properties , pagina 
Securitate  și setați opțiunea Failed logins only din Login auditing section . 
Pentru a vizualiza jurnalul de erori SQL Server, există trei posibilități:  
a. Extindeți instanța și găsiți secțiunea Management . Faceți clic dreapta pe SQL Server Logs > 
View > SQL Server Log. 
b. Jurnalul de erori se află la: 
Program Files\Microsoft  SQL Server\MSSQL.<n>\MSSQL\LOG\ERRORLOG  în 
fișierele ERRORLOG.<n>.  
c. Utilizați procedura  stocată:  
xp_ReadErrorLog  <LogNumber>,  <LogType>,  <SearchValue1>,  <SearchValue2>,                                            
<StartDate>,  <EndDate>,  <SortOrder>:  
Parametru   Valori 
<LogNumber>   Numărul jurnalului  (de exemplu: 0 returneaz ă jurnalul curent, 2 
returneaz ă jurnale din ERRORLOG.2)  
<LogType>   1 – Citește jurnalele de erori SQL Server;  
2 – Citește jurnalele de erori SQL Server Agent; 
<SearchValue1>   Valoarea de căutare pentru coloana Text 
<SearchValue2>   Valoarea de căutare pentru coloana Text 
<StartDate>   Jurnale începând cu data specificat ă 
<EndDate>   Jurnale până la data specificat ă, dar fără a include data menționată 
<SortOrder>   Ordonare  după coloana LogDate: 
ASC – Crescător; 
DESC – Descrescător. 
Exemplu: Pentru a citi jurnalul de erori SQL Server curent, între 01‐02‐2018 și 31‐02‐2018: 
EXEC xp_readerrorlog  0, 1, NULL, NULL, '20180201' , '20180301'   
 
Observație: Când sunt specificați ambii parametri  ai valorii de căutare, sunt returnate  doar 
liniile ce îi conțin pe amândoi.  
   
1.3 Serverul de aplicații web

6 
 
  Următorul tabel conține principalele  vulnerabilit ăți și probleme,  precum și soluțiile recomandate  pentru 
remedierea  acestora. 
Vulnerabilitate/Problem ă  Descriere   Soluție 
Enumerarea  directoarelor  
cu tildă în Microsoft  IIS Este posibil să detectați numele scurte 
ale fișierelor și directoarelor  care au o 
schemă de denumire  a fișierelor 8.3 
echivalent ă în Windows,  utilizând 
anumiți vectori în câteva versiuni ale 
Microsoft  IIS. În acest mod este posibil 
să  găsiți fișierele ș i folderele 
importante,  care nu sunt vizibile în 
mod normal. Numele scurt Windows  8.3 poate fi dezactivat  
prin crearea unei chei în registry pe un sistem 
de operare Windows  
 Key: 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentC
ontrolSet\Control\FileSystem  
 Name : NtfsDisable8dot3NameCreation   
 Type : DWORD 
 Value : 1 
 
Observație: Fișierele și folderele create deja 
pot fi scanate și remediate  utilizând 
următoarele comenzi: 
 fsutil 8dot3name  scan /s /v 
C:\inetpub\wwwroot  
 fsutil 8dot3name  strip /s /v 
C:\inetpub\wwwroot  
Metoda OPTIONS  este 
activată OPTIONS este o metodă HTTP care 
oferă o listă de metode acceptate  de 
serverul web. De asemenea,  reprezintă 
o cerere de informații despre opțiunile 
de comunicare  disponibile  în lanțul 
cerere/răspuns,  identificat   prin 
Request‐URI. Pentru a dezactiva  metoda OPTIONS , urmați 
acești pași: 
1. În Command  Prompt executați: 
cd %windir%\system32\inetsrv  
2. Executați următoarea sintaxă: 
appcmd.exe  set config 
/section:requestfiltering  
/+verbs.[verb='OPTIONS',  allowed='false']  
SAU 
1. În IIS Manager , selectați numele serverului  
pentru configurare  la nivel global sau 
selectați site‐ul web specific; 
2. În Request Filtering , comutați la fila HTTP 
Verb ; 
3. Din panoul Actions (panoul din dreapta), 
selectați Deny Verb și inserați OPTIONS în 
verb, apoi apăsați OK pentru a salva 
modificările. 
SAU 
De asemenea,  configura ția poate fi aplicată 
prin modificarea  fișierului Web.config , după 
cum urmează: 
<system.webServer>  
  <security>  
    <requestFiltering>  
      <verbs allowUnlisted="true">

7 
 
         <add verb="OPTIONS"  allowed="false"  /> 
      </verbs> 
    </requestFiltering>  
  </security>  
</system.webServer>  
Depanarea  ASP.NET este 
activată Modul Debug determină ASP.NET să 
compileze  aplicațiile cu informații 
suplimentare,   care  ajută  un 
dezvoltator  să monitorizeze  și să 
controleze  execuția unei aplicații, dar, 
de asemenea,  dezvăluie informații 
confidențiale despre aplicație, care pot 
fi valoroase  în formularea  atacurilor  
țintite asupra sistemului.  Pentru a dezactiva  depanarea  pentru aplicația 
ASP.NET, modificați fișierul Web.config  după 
cum urmează: 
<system.web>  
   <compilation  debug="false"/>  
</system.web>  
 
Observație: În mod prestabilit,  depanarea  este 
dezactivat ă 
Dezvăluirea versiunii 
ASP.NET De fiecare dată când un browser 
efectueaz ă o cerere HTTP către un 
server web, trimite și un antet HTTP 
denumit X‐AspNet‐Version , unde poate 
fi identificat ă versiunea  serverului  
web, împreună cu versiunea  ASP.NET 
utilizată. Este posibil ca aceste 
informații să poarte un risc privind 
securitatea.  Pentru a elimina antetul de răspuns X‐AspNet‐
Version , modificați fișierul Web.config  după 
cum urmează: 
<system.web>  
   <httpRuntime  enableVersionHeader="false"  
/> 
</system.web>  
 Observație: De asemenea,  instrumentul  
Microsoft   IIS  Lockdown   recomand ă 
dezactivarea  acestor anteturi. 
Clickjacking:  
Antetul X‐Frame‐Options 
lipsește Clickjacking  (redesenarea  interfeței cu 
utilizatorul)  este o tehnică de utilizare 
a mai multor straturi transparente  sau 
opace pentru a înșela un utilizator web 
să facă clic pe altceva (buton, link sau 
altă pagină) fată de ce intenționa să 
acceseze utilizatorul  prin clic. Antetul 
X‐Frame‐Options poate fi utilizat 
pentru a indica dacă unui browser 
trebuie să‐i fie permis sau nu să 
randeze o pagină în cadrul unui frame 
sau iframe. Pentru a evita acest lucru, este important  să vă 
asigurați că conținutul site‐ului nu este 
înglobat în alt site. Modificați fișierul 
Web.config  după cum urmează: 
<system.webServer>  
   <httpProtocol>  
      <customHeaders>  
           <add name="X‐Frame‐Options" value=" 
SAMEORIGIN  " /> 
      </customHeaders>  
   </httpProtocol>  
</system.webServer>  
SAU 
1. În IIS Manager , selectați site‐ul pe care 
doriți să‐l protejați; 
2. În HTTP Response  Header, faceți clic pe 
Add în panoul Actions (partea dreaptă); 
3. În caseta de dialog: 
 Name: X‐Frame‐Options 
 Value: SAMEORIGIN  
Protecția XSS a browser‐ului 
web nu este activată Cross‐site Scripting (XSS) se referă la 
atacul prin injecția de cod la client, Pentru a vă păstra site‐ul și vizitatorii în 
siguranță fată de atacuri, activați antetul X‐

8 
 
unde un atacator poate executa script‐
uri malițioase pe un site web sau într‐o 
aplicație web legitimă. Cu antetul X‐
XSS‐Protection  setat, browser‐ele care 
detecteaz ă un atac XSS vor randa pur și 
simplu o pagină goală  și vor bloca 
răspunsul, în loc să încerce să curețe 
scriptul injectat. XSS‐Protection  prin modificarea  fișierului 
Web.config  după cum urmează: 
<system.webServer>  
   <httpProtocol>  
      <customHeaders>  
          <add name="X‐Xss‐Protection"  value="1;  
mode=block"  /> 
      </customHeaders>  
   </httpProtocol>  
</system.webServer>  
SAU 
1. În IIS Manager , selectați site‐ul pe care 
doriți să‐l protejați; 
2. În HTTP Response  Header, faceți clic pe 
Add în panoul Actions (partea dreaptă); 
3. În caseta de dialog: 
 Name: X‐XSS‐Protection  
 Value: 1; mode=block  
Cookie fără marcajul 
HttpOnly  setat și cookie fără 
marcajul Secure setat Când un cookie este setat cu marcajul 
HTTPOnly , instruiește browser‐ul că 
acel cookie poate fi accesat doar de 
script‐uri de pe server, nu de pe client. 
Când un cookie este setat cu marcajul 
Secure , instruiește browser‐ul că acel 
cookie poate fi accesat doar prin 
canale SSL securizate.  Dacă marcajul 
Secure nu este setat, cookie‐ul va fi 
transmis în text lizibil. Pentru a seta marcajul HTTPOnly  și marcajul 
Secure , modificați fișierul Web.config  după 
cum urmează: 
<system.web>  
   <httpCookies   httpOnlyCookies="true"  
requireSSL="true"  lockItem="true"  /> 
   <authentication  mode=”Forms”>  
      <forms requireSSL=”true”/>  
   </authentication>  
</system.web>

9 
 
Mai 
multe 
aspecte 
legate de 
SSL Suitele de 
cifruri RC4 SSL 
acceptate  Algoritmul  RC4 permite recuperarea  
unui volum limitat de date în text 
simplu din comunicările SSL/TLS. Pentru a dezactiva  complet suitele de cifruri 
RC4, setați următoarele chei în registry: 
 RC4 128/128 
 Key: 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHA
NNEL\Ciphers\RC4  128/128
 
 Name : Enabled 
 Type : DWORD 
 Value : 0 
 
 RC4 40/128 
 Key: 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4  40/128 
 Name : Enabled 
 Type : DWORD 
 Value : 0 
  RC4 56/128 
 Key: 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4  56/128 
 Name : Enabled  
 Type : DWORD 
 Value : 0 
Atacul DROWN 
(SSLv2 
acceptat)  DROWN este o vulnerabilitate  gravă, 
care afectează HTTPS și alte servicii 
care se bazează pe SSL și TLS și permite 
întreruperea  criptării și citirea sau 
furarea de comunicări confidențiale. 
Un server este vulnerabil  la DROWN 
dacă: 
 Permite conexiuni  SSLv2  
SAU 
 Cheia sa privată este utilizată pe 
orice alt server ce permite 
conexiuni  SSLv2, chiar pentru alt 
protocol (de exemplu pentru 
reutilizarea  aceluiași certificat și 
aceleiași chei pe serverul web și de 
e‐mail). Pentru a vă proteja împotriva  DROWN, luați în 
considerare  una dintre aceste măsuri: 
1. Asigurați‐vă că cheile private nu sunt 
utilizate niciunde cu software de server ce 
permite conexiuni  SSLv2; 
2. Dezactivarea  protocolului  SSLv2 pe toate 
serverele SSL/TLS; 
3. Dezactiva ți cheia SSLv2: 
 Key:  
HKEY_LOCAL_MACHINE  
\SYSTEM\CurrentControlSet\Contr
ol\SecurityProviders\SCHANNEL\P
rotocols\SSL  2.0\Server  
 Name : Enabled  
 Type : DWORD 
 Value : 0 
 
Observație: Recomandarea  noastră este a treia

10 
 
opțiune. 
Atacul POODLE 
(SSLv3 
acceptat)  Atacul POODLE este o exploatare  de 
tip man‐in‐the‐middle (MiTM), care 
permite unui atacator de rețea să 
extragă textul simplu al pârților vizate 
dintr‐o conexiune  SSL (protocolul  
SSLv3), de obicei date ale cookie‐urilor. Pentru a vă proteja împotriva  POODLE, 
dezactiva ți SSLv3 după cum urmează: 
 Key:  
HKEY_LOCAL_MACHINE  
\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL  
3.0\Server  
 Name : Enabled  
 Type : DWORD 
 Value : 0 
Atacul BEAST ‐ 
Transportation  
Security 
Protocol 
nesecurizat  
acceptat (TLS 
1.0) Atacul BEAST utilizează tehnica man‐
in‐the‐middle și injectează pachete în 
fluxul TLS, care ajută la decriptarea  
datelor schimbate  între site‐ul web și 
vizitatorii acestuia. Pentru a vă proteja împotriva  BEAST, 
dezactiva ți TLSv1 după cum urmează: 
 Key:  
HKEY_LOCAL_MACHINE  
\SYSTEM\CurrentControlSet\Control\Secur
ityProviders\SCHANNEL\Protocols\TLS  1.0 
 Name : Enabled 
 Type : DWORD 
 Value : 0 
TLSv1.1 și 
TLSv1.2 
neactivate  Atât TLSv1.1, cât și TLSv1.2 nu au 
probleme  de securitate  cunoscute,  dar 
doar TLSv1.2 oferă  algoritmi 
criptografici  moderni. TLS v1.2 trebuie să fie principalul  dvs. protocol 
utilizat, deoarece  este singura versiune care 
oferă  criptare autentificat ă  modernă 
(cunoscut ă  ș i ca AEAD, Authenticated  
Encryption  With Associated  Data).  
După dezactivarea  protocoalelor  menționate 
mai sus, activați TLSv1.2 după cum urmează: 
 Key:  
HKEY_LOCAL_MACHINE  
\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS  
1.2\Server  
 Name : Enabled  
 Type : DWORD 
 Value : 1 
 
 Key:  
HKEY_LOCAL_MACHINE  
\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS  
1.2\Server  
 Name : DisabledByDefault  
 Type : DWORD 
 Value : 0

11 
 
 Key:  
HKEY_LOCAL_MACHINE  
\SYSTEM\CurrentControlSet\Control\Secur
ityProviders\SCHANNEL\Protocols\TLS  
1.2\Client  
 Name : Enabled 
 Type : DWORD 
 Value : 1 
  Key:  
HKEY_LOCAL_MACHINE  
\SYSTEM\CurrentControlSet\Control\Secur
ityProviders\SCHANNEL\Protocols\TLS  
1.2\Client  
 Name : DisabledByDefault  
 Type : DWORD 
 Value : 0 
HTTPS nu este impus  Livrarea unei pagini web printr‐o 
conexiune  HTTP necriptată este 
considerat ă a fi o vulnerabilitate,  
deoarece  un atacator poate înregistra  
și  monitoriza   interacțiunile 
utilizatorului  cu aplicația și poate 
obține informațiile pe care utilizatorul  
le furnizează.  Modulul IIS URL Rewrite este un mod rapid și 
puternic de a activa redirecționarea HTTP 
către HTTPS pe un site web. Modificați fișierul 
Web.config  după cum urmează: 
<system.webServer>  
   <rewrite>  
      <rules> 
          <rule name="HTTP  to HTTPS redirect" 
stopProcessing="true">  
             <match url="(.*)" /> 
             <conditions>  
                <add input="{HTTPS}"  pattern="off"  
ignoreCase="true"  /> 
             </conditions>  
             <action type="Redirect"  
redirectType="Found"  
url="https://nume_site/"  /> 
          </rule> 
      </rules></rewrite>  
</system.webSever>  
Parametrul  __VIEWSTATE  
necriptat  Viewstate  este o metodă pe care 
ASP.NET o utilizează pentru a păstra 
valorile de paginare și control între 
cursele dus‐întors. Când este randat 
marcajul HTML pentru pagină, starea 
curentă a paginii și valorile care trebuie 
păstrate la returnare  sunt serializate  în 
șiruri codificate  base64. Viewstate  
necriptat poate ajuta atacatorul  să 
aibă acces la informații confidențiale Pentru a securiza Viewstate  și a nu da nicio 
șansă de interceptare  unui atacator, modificați 
fișierul Web.config  după cum urmează: 
<system.web>  
   <machineKey  validation="AES"/>  
</system.web>

12 
 
despre aplicația web, precum nume de 
utilizatori,   parole,  numele 
calculatorului  ș i/sau locații ale 
fișierelor confidențiale. 
Încercări brutale de 
autentificare   Un atac brutal este o încercare de 
descoperire  a unei parole prin 
încercarea  sistematic ă a fiecărei 
combinații posibile de litere, cifre și 
simboluri până când se descoperă 
combinația corectă, care funcționează. 
CAPTCHA  este un program ce vă 
permite să faceți diferența dintre 
persoane  și calculatoare.  În esență, 
CAPTCHA  este prezent pentru a 
împiedica  roboții să lanseze atacuri 
brutale  utilizând  instrumente  
disponibile  pe scară largă. Pentru a activa CAPTCHA  pentru conectare,  
modificați fișierul Web.config  după cum 
urmează: 
 În secțiunea <configSections> , adăugați: 
<section name="botDetect"  
requirePermission="false"  
type="BotDetect.Configuration.BotDetect
ConfigurationSection,  BotDetect"/>  
 În secțiunea <appSettings> , adăugați cheia:  
<add key="CaptchaEnabled"  
value="true"/>  
 În secțiunea <configuration> , adăugați: 
<location path="BotDetectCaptcha.ashx">   
   <system.web>   
      <authorization>   
          <allow users="*"/>   
      </authorization>  
   </system.web>   
</location>  
 În secțiunea <system.Web> , adăugați sau 
modificați după cum urmează: 
<sessionState  mode="InProc"  
cookieless="AutoDetect"  timeout="20"  
sessionIDManagerTyp e="BotDetect.Web.C
ustomSessionIdManager,  BotDetect"/>  
 În  secțiunea  <httpHandlers>   din 
<system.Web> , adăugați: 
<add verb="GET"  
path="BotDetectCaptcha.ashx"  
type="BotDetect.Web.CaptchaHandler,  
BotDetect"  /> 
 În  secțiunea  <system.webServer> , 
adăugați: 
<remove 
name="BotDetectCaptchaHandler"/>   
<add name="BotDetectCaptchaHandler"  
preCondition="integratedMode"  
verb="GET"  
path="BotDetectCaptcha.ashx"  
type="BotDetect.Web.CaptchaHandler,  
BotDetect"/>

13 
 
 În secțiunea <configuration> , după sfârșitul 
<system.webServer>,  adăugați: 
<botDetect  helpLinkEnabled="false"  
helpLinkMode="image"  /> 
  
1.4 Serverele  de conectare  desktop de la distanta 
 
În plus fată de măsurile de securitate  descrise în subcapitolul  1.1, trebuie luate în considerare  
următoarele măsuri de securitate  pentru serverele desktop la distanta: 
1. Securizați conturile utilizatorilor  desktop de la distanta și impuneți politici pentru parole 
complexe . Dacă accesul la Charisma depinde de conectarea  desktop de la distanta, este necesar să 
verificați lista de utilizatori  care au dreptul de a se conecta și să eliminați toate conturile inutile, 
pentru a reduce numărul. În plus fată de cerințele de complexitate  a parolelor,  utilizați politici de 
eliminare  prin blocare pentru a împiedica  accesul neautorizat  prin ghicirea parolei sau utilizarea 
parolelor generate automat. 
2. Restricționați permisiunile  la fișierele și folderele  de sistem . În cazul conectării desktop de la 
distanta, setarea permisiunilor  pentru foldere este o măsură de securitate  obligatorie.  Fiecare 
utilizator la distanță, care are acces la exportul fișierelor de date confidențiale din aplicații, trebuie să 
aibă, de asemenea,  un folder pentru care doar acel utilizator are permisiuni.  Calea folderului  poate fi 
setată în aplicația Charisma HCM, la nivel de utilizator,  accesând meniul Unelte > Utilizatori . Pentru 
fiecare utilizator,  completa ți caseta de text Cale export cu locația folderului  la care utilizatorul  are 
acces de citire și scriere. Această acțiune va preveni accesarea  fișierelor confidențiale de către 
utilizatorii  neautoriza ți. 
3. Restricționați accesul la fișiere partajate  și eliminați toate partajările inutile . Este recomandabil  să 
dezactiva ți partajarea  fișierelor. Dacă este necesară, este important  să examinați fișierele care sunt 
disponibile  pentru alți utilizatori  și să setați corect permisiunile  fișierelor și felderelor.  
 
2. Securitatea  la nivel de baze de date 
 
 Această secțiune descrie o parte dintre cele mai comune abordări utilizate pentru securizarea  datelor 
stocate față de accesul neautorizat.  Există două măsuri principale,  pe care le‐am identificat,  care pot securiza 
datele stocate în baza de date: criptarea stocării și definirea rolurilor pentru baza de date. 
 
2.1 Criptarea stocării 
  
Important:  Informațiile prezentate  în acest capitol sunt destinate  numai versiunilor  de SQL Server care suportă 
aceasta funcționalitate.  
 
  În funcție de mediul utilizat, există mai multe soluții care oferă criptarea stocării pe serverul de baze de 
date. Prima și cea mai facilă abordare este criptarea sistemului  de fișiere, care poate fi configurat ă ușor pe

14 
 
aproape toate versiunile  de servere Windows  și este foarte ușor de configurat.  Dacă soluția este în cloud, cel mai 
probabil furnizorul  dvs. de soluții cloud oferă o opțiune de criptare a stocării, precum cea oferită de Microsoft  
Azure. 
  Scopul Transparent Data Encryption  este protejarea  tuturor datelor care sunt stocate în baza de date prin 
criptarea tuturor fișierelor fizice: fișier de date (.mdf), fișier jurnal (.ldf) și, de asemenea,  fișierele backup ale bazei 
de date. Citirea datelor din oricare aceste fișiere nu este posibilă fără certificatul  de criptare creat inițial, la 
configurarea  criptării. 
  TDE efectueaz ă criptarea și decriptarea  I/O în timp real a fișierului de date și fișierului jurnal, acțiuni care 
nu cresc dimensiunea  bazei de date. Criptarea utilizează o cheie de criptare a bazei de date (database  encryption  
key ‐ DEK) securizată, prin utilizarea unui certificat stocat în baza de date master a serverului,  care este protejată 
de cheia bazei de date master (master database key ‐ DMK). Această criptare are loc la nivel de pagină. Paginile 
dintr‐o bază de date criptată sunt criptate înainte de a fi scrise pe disc și sunt decriptate  când sunt citite în 
memorie.   
 
Important : În plus fată de efectuarea  de copii de siguranță ale bazei de date, este important  să întrețineți 
backup‐uri ale certificatului  serverului  într‐o locație securizată, pentru a preveni pierderea  datelor la restabilirea  
bazei de date criptate dintr‐un backup sau la atașarea fișierelor bazei de date la alt server. În plus, certificatul  
criptat trebuie păstrat, chiar dacă TDE nu mai este activată pentru baza de date, în scopul restabilirii  fișierelor 
backup mai vechi ale bazei de date sau pentru nevoile viitoare de reactivare  a criptării pentru o anumită bază de 
date. Recomand ăm clientului să asigneze un administrator  al bazei de date (în cazul implement ării la sediu), care 
să fie responsabil  de definirea și întreținerea unei politici pentru backup‐urile bazei de date. În scopul creării 
mediilor DEV și UAT, recomand ăm ca astfel de baze de date să nu fie criptate, pentru a putea fi utilizate ușor în 
alte medii care nu au același certificat de criptare instalat. 
  
  Următoarea secțiune va detalia unele dintre scenariile  de utilizare tipice și modul în care pot fi 
implementate,  în cazul în care luați în considerare  să utilizați TDE pentru criptarea stocării fișierelor bazei de date. 
 
2.1.1 Scenariul de utilizare 1 ‐ Activarea  TDE pentru o bază de date necriptată 
 
  Pentru a activa TDE pentru o bază de date necriptată, urmați acești pași: 
1. Creați o cheie master a bazei de date (DMK); 
2. Creați un certificat protejat de cheia master; 
3. Creați un backup al certificatului  serverului  și al cheii private; 
4. Creați o cheie de criptare a bazei de date (DEK), protejată de certificat;  
5. Setați baza de date să utilizeze criptarea (rețineți că acest proces rulează asincron și trebuie să 
așteptați finalizarea  lui – consultați următorul pas); 
6. Verificați starea criptării bazelor de date. 
 
Observație: De asemenea,  TDE criptează automat fișierul fizic al bazei de date de sistem tempdb , pe care SQL 
Server îl utilizează pentru stocarea temporar ă a seturilor de rezultate.

15 
 
 
  Următorul script SQL este un exemplu de configurare  a TDE pentru o bază de date necriptată:

16 
 
USE master   
GO 
 
/* 1. Create a database  master key (DMK) */ 
CREATE MASTER KEY ENCRYPTION  BY PASSWORD  = '<Master_Encryption_Key_Password>'  
GO 
 
/* 2. Create a certificate  protected  by the master key */ 
CREATE CERTIFICATE  <certificate_name > WITH SUBJECT  = '<certificate_subject>'  
GO 
 
/* 3. Create a backup of server certificate  and the private  key on source server */ 
BACKUP CERTIFICATE  <certificate_name > 
TO FILE = '<location>\<certificate_name>.cer'  ‐‐ ex: E:\TDEDatabaseTest\TDECertificate.cer  
WITH PRIVATE  KEY 
     (  
     FILE = '<location>\<private_key_name>.pvk' , ‐‐ ex: E:\TDEDatabaseTest\SQLPrivateKeyFileCertTDE.pvk  
     ENCRYPTION  BY PASSWORD  = '<Certificate_Password>'  
     ) 
 
/* 4. Create a database  encryption  key (DEK) protected  by certificate  */ 
USE <database_name > 
GO 
 
CREATE DATABASE  ENCRYPTION  KEY   
WITH ALGORITHM  = AES_256  ENCRYPTION  BY SERVER CERTIFICATE  <certificate_name > 
GO   
 
/* 5. Set database  to use encryption*/  
USE master 
GO 
 
ALTER DATABASE  <database_name >   
SET ENCRYPTION  ON 
GO 
 
/* 6. Verify encryption  state of the databases  */ 
SELECT  
  database_id , 
  DB_NAME (database_id ) AS database_name ,  
  key_algorithm  + '_' + CONVERT (varchar (25), key_length ) AS used_algorithm ,  
  encryptor_type ,  
  CASE encryption_state  
   WHEN 0 THEN 'No database  encryption  key present,  no encryption'  
   WHEN 1 THEN 'Unencrypted'  
   WHEN 2 THEN 'Encryption  in progress'  
   WHEN 3 THEN 'Encrypted'  
   WHEN 4 THEN 'Key change in progress'  
   WHEN 5 THEN 'Decryption  in progress'  
   WHEN 6 THEN 'Protection  change in progress  (The certificate  or asymmetric  key that is en‐
crypting  the database  encryption  key is being changed)'  
  END AS encryption_state , 
  percent_complete  
FROM sys.dm_database_encryption_keys

17 
 
Observație: Argumentele  marcate cu < … > trebuie înlocuite cu valorile specifice clientului.  
 
2.1.2 Scenariul de utilizare 2 ‐ Dezactivarea  TDE pentru o bază de date criptată 
 
  Pentru a dezactiva  TDE, urmați acești pași: 
1. Dezactiva ți criptarea bazei de date (rețineți că acest proces rulează asincron și trebuie să așteptați 
finalizarea  lui – consultați următorul pas); 
2. Așteptați finalizarea  procesului  de decriptare;  
  Următorul script SQL va dezactiva  TDE: 
/* Disable  TDE */ 
USE master 
GO 
 
/* 1. Remove encryption  from the database  */ 
ALTER DATABASE  <database_name >   
SET ENCRYPTION  OFF 
GO 
 
/* 2. Wait until the decryption  process  is complete  */ 
SELECT  
  database_id , 
  DB_NAME (database_id ) AS database_name ,  
  key_algorithm  + '_' + CONVERT (varchar (25), key_length ) AS used_algorithm ,  
  encryptor_type ,  
  CASE encryption_state  
   WHEN 0 THEN 'No database  encryption  key present,  no encryption'  
   WHEN 1 THEN 'Unencrypted'  
   WHEN 2 THEN 'Encryption  in progress'  
   WHEN 3 THEN 'Encrypted'  
   WHEN 4 THEN 'Key change in progress'  
   WHEN 5 THEN 'Decryption  in progress'  
   WHEN 6 THEN 'Protection  change in progress  (The certificate  or asymmetric  key that is en‐
crypting  the database  encryption  key is being changed)'  
  END AS encryption_state , 
  percent_complete  
FROM sys.dm_database_encryption_keys  
 
Observație: Argumentele  marcate cu < … > trebuie înlocuite cu valorile corespunz ătoare. 
 
2.1.3 Scenariul de utilizare 3 ‐ Reactivarea  TDE pentru o bază de date cu criptarea 
dezactivat ă 
 
  Pentru a reactiva TDE după ce a fost dezactivat ă (Scenariul  de utilizare 2), este suficient să activați 
criptarea bazei de date și să așteptați finalizarea  procesului  de criptare.

18 
 
/* 1. Set encryption  on the database  */ 
USE master   
GO 
 
ALTER DATABASE  <database_name >   
SET ENCRYPTION  ON 
GO 
 
2.1.4 Scenariul de utilizare 4 ‐ Eliminarea  TDE dintr‐o bază de date cu criptarea activată 
  
  Dacă TDE nu mai este necesară, este posibil s‐o eliminați definitiv. Pentru a o elimina, toate bazele de 
date care sunt criptate pe server trebuie să aibă TDE dezactivat ă (urmați Scenariul de utilizare 3). 
 
  După dezactivarea  TDE, urmați acești pași: 
1. Ștergeți cheia de criptare a bazei de date; 
2. Ștergeți certificatul  serverului;  
3. Ștergeți cheia master a bazei de date. 
 
Observație:  
 Dacă există alte baze de date în instanță care au activată TDE, cheia master a bazei de date nu trebuie 
ștearsă. 
 Dacă există alte baze de date în instanță care sunt criptate cu același certificat al serverului,  
certificatul  nu trebuie șters. 
 Fișierul fizic al bazei de date de sistem tempdb va rămâne criptat, chiar dacă este eliminată criptarea.  
Pentru a elimina criptarea,  instanța SQL Server trebuie repornită. 
 
  Următorul script SQL va elimina implementarea  TDE: 
/* Remove TDE */ 
‐‐ Disable  TDE first 
 
/* 1. Delete the database  encryption  key */ 
USE <database_name > 
DROP DATABASE  ENCRYPTION  KEY 
GO 
 
/* 2. Delete server certificate*/  
USE master 
GO 
 
DROP CERTIFICATE  <certificate_name >  
GO 
 
/* 3. Delete database  master key */ 
DROP MASTER KEY 
GO

19 
 
Observație: Argumentele  marcate cu < … > trebuie înlocuite cu valorile specifice clientului.  
 
2.1.5 Scenariul de utilizare 5 ‐ Migrarea bazei de date criptate cu TDE în altă instanță 
SQL Server 
  
  Nu este posibilă mutarea unei baze de date criptate cu TDE în altă instanță SQL Server, decât dacă 
certificatul  care este utilizat pentru deschiderea  cheii de criptare a bazei de date (DEK) este instalat pe cealaltă 
instanță. 
  Pentru a muta o bază de date protejată prin TDE pe alt SQL Server, urmați acești pași: 
1. Creați un backup al certificatului  serverului  din baza de date master de pe serverul sursă; 
2. Detașați sau efectuați un backup al bazei de date protejate cu TDE de pe serverul sursă; 
3. Pentru atașarea unei baze de date, mutați sau copiați fișierele bazei de date de pe serverul sursă în 
locația corespunz ătoare a serverului  destinație. Pentru restabilirea  unei baze de date, mutați sau 
copiați fișierul backup de pe serverul sursă pe serverul destinație; 
4. Mutați sau copiați backup‐ul certificatului  serverului  și fișierul cheii private de pe serverul sursă pe 
serverul destinație.    
5. Creați o cheie master a bazei de date în instanța destinație a SQL Server. Parola cheii master de pe 
serverul destinație poate fi diferită de cea pe care am utilizat‐o pe serverul sursă; 
6. Creați certificatul  serverului  pe serverul destinație, utilizând fișierul backup al certificatului  inițial al 
serverului.  Parola pentru decriptarea  certificatului  este aceeași cu cea furnizată pentru backup și 
export; 
7. Atașați sau restabiliți baza de date care este mutată.  
   Următorul script SQL va muta baza de date criptată cu TDE pe alt SQL Server:

20 
 
/* 1. Create a backup of the server certificate  in the master database  on source server */ 
USE master 
GO 
 
BACKUP CERTIFICATE  <certificate_name > 
TO FILE = '<location>\<certificate_name>.cer'  ‐‐ ex: E:\TDEDatabaseTest\TDECertificate.cer  
WITH PRIVATE  KEY 
     (  
     FILE = '<location>\<private_key_name>.pvk' , ‐‐ ex: E:\TDEDatabaseTest\SQLPrivateKeyFileCertTDE.pvk  
     ENCRYPTION  BY PASSWORD  = '<certificate_password>'  
     ) 
 
/* 2. Detach or backup the TDE protected  database  from the source server */ 
 
/* 3. For attaching  a database,  move or copy database  files from the source server to the proper 
location  of destination  server. 
       For restoring  a database,  move or copy backup file from source server to destination  server */ 
 
/* 4. Move or copy the backup of the server certificate  and the private  key file from source server to 
destination  server */ 
 
/* 5. Create a database  master key in destination  instance  of SQL Server */ 
USE master 
GO 
 
CREATE MASTER KEY ENCRYPTION  BY PASSWORD  = '<password>'  
 
/* 6. Create the server certificate  in destination  server by using the original  server certificate  
backup file */ 
CREATE CERTIFICATE  CertTDE    
     FROM FILE = '<destination_server_location>\<certificate_name>.cer'  
      WITH PRIVATE  KEY  
       (  
         FILE = '<destination_server_location>\<private_key_name>.pvk'  , 
         DECRYPTION  BY PASSWORD  = '<certificate_password>'   
       )  
GO 
 
/* 7. Attach or restore  the database  that is being moved */ 
  
Observație: Argumentele  marcate cu < … > trebuie înlocuite cu valorile specifice clientului.  
 
  2.2 Rolurile și permisiunile  
 
  Alt mod de a securiza o bază de date este definirea permisiunilor  și asignarea  acestor permisiuni  
utilizatorilor  și conectărilor. Pentru a administra  facil aceste permisiuni  din baza de date, SQL Server a furnizat 
câteva roluri fixe în baza de date și câteva roluri fixe la nivel de server. 
 
Observație: În exemplele  de mai jos, observați diferența dintre <user> și <login>. Un <user> este creat la nivel de 
bază de date SQL Server, iar un <login> este creat la nivel de instanță SQL Server.

21 
 
2.2.1 Rolurile fixe în baza de date 
 
Nume rol fix în baza de date Descriere  
db_accessadmin   Poate adăuga sau elimina accesul la baza de date pentru conectări Windows,  
grupuri Windows  și conectări SQL Server 
db_backupoperator   Poate efectua backup‐ul bazei de date 
db_datareader   Poate citi toate datele din toate tabelele utilizatorilor  
db_datawriter   Poate citi, adăuga, șterge sau modifica datele din toate tabelele utilizatorilor  
db_ddladmin   Poate rula orice comandă Data Definition  Language  (DDL) într‐o bază de date 
db_denydatareader   Nu poate citi date din tabelele utilizatorilor  din cadrul unei baze de date 
db_denydatawriter   Nu poate citi, adăuga, modifica sau șterge date din tabelele utilizatorilor  din 
cadrul unei baze de date 
db_owner   Poate efectua toate activitățile de configurare  și întreținere asupra bazei de 
date și, de asemenea,  poate elimina baza de date din SQL Server 
db_securityadmin   Poate modifica membrii rolurilor și poate administra  permisiunile.  Adăugarea 
de utilizatori  principal la acest rol poate permite escaladarea  privilegiilor  
neintenționate 
 
USE <database_name>  
GO 
sp_addrolemember  '<fixed_database_role_name>' , '<user>'  
 
Observație: Fiecare utilizator al bazei de date moștenește automat permisiunea  rolului public în baza de date, din 
care nu poate fi eliminat.  
 
2.2.2 Rolurile fixe la nivel de server 
 
Nume rol fix la nivel de server Descriere 
bulkadmin   Poate rula instrucțiunea  BULK INSERT  
dbcreator   Poate crea, modifica, elimina și restabili orice bază de date. 
diskadmin   Utilizat pentru administrarea  fișierelor de pe disc 
processadmin   Poate încheia procesele  care rulează pe o instanță a SQL Server. 
securityadmin   Administreaz ă conectările și proprietățile acestora, permisiunea  la nivel de 
server, permisiunea  la nivel de bază de date dacă are acces la baza de date, 
poate reseta parola pentru conectările SQL Server 
serveradmin   Poate modifica opțiunile de configurare  de pe tot serverul și poate opri 
serverul 
setupadmin   Poate adăuga și elimina serverele legate, utilizând instrucțiuni Transact‐SQL 
sysadmin  Poate efectua orice activitate pe server 
 
USE master 
EXEC sp_addsrvrolemember  '<login>' , 'fixed_server_level_role_name' ;   
GO   
 
Observație:

22 
 
 Fiecare conectare  SQL Server moștenește automat permisiunea  rolului public la nivel de server. Când 
unui utilizator principal al serverului  nu i‐au fost acordate sau interzise anumite permisiuni  asupra 
unui obiect securizabil,  utilizatorul  moștenește permisiunile  acordate rolului public pentru obiectul 
respectiv.  
 Pentru a avea permisiunea  de a modifica proprietățile serverului,  utilizatorul  de login trebuie să aibă 
rolul serveradmin  sau sysadmin pe server. 
 
2.2.3 Rolul fix SQL Server Agent în baza de date 
 
  SQL Server Agent utilizează rolurile fixe în baza de date din baza de date de sistem msdb pentru a 
controla accesul la SQL Server Agent pentru utilizatorii  care nu sunt membri ai rolului fix pe server sysadmin . 
  SQL Server Agent conține trei roluri fixe în baza de date, explicate în tabelul de mai jos: 
Acțiune  SQLAgentUserRole   SQLAgentReaderRole   SQLAgentOperatorRole  
Creare/modificare/edita
re Doar joburile pentru care 
este responsabil  Doar joburile pentru 
care este responsabil  Doar joburile pentru care 
este responsabil  
Vizualizare  listă  Doar joburile pentru care 
este responsabil  Toate joburile  Toate joburile 
Pornire/oprire   Doar joburile pentru care 
este responsabil  Doar joburile pentru 
care este responsabil  Toate joburile 
Activare/dezactivare   Doar joburile pentru care 
este responsabil  Doar joburile pentru 
care este responsabil  Toate joburile 
Editare proprietăți  Doar joburile pentru care 
este responsabil  Doar joburile pentru 
care este responsabil  Doar joburile pentru care 
este responsabil  
Vizualizare  istoric de 
joburi Doar joburile pentru care 
este responsabil  Toate joburile  Toate joburile 
Ștergere istoric de 
joburi Nu  Nu  Doar joburile pentru care 
este responsabil  
Modificare  
responsabilitate  Nu  Nu  Nu 
 
Observație: Pentru a acorda permisiuni  SQL Server Agent, este necesar să creați un utilizator pentru o anumită 
conectare  în baza de date de sistem msdb . 
 
USE msdb 
GO 
‐‐ Create user for specific  login in msdb system database  
CREATE USER <user > FOR LOGIN <login > 
GO 
 
ALTER ROLE <SQLAgentUserRole /SQLAgentReaderRole /SQLAgentOperatorRole>  ADD MEMBER <user > 
 
2.2.4 Permisiunile  bazei de date 
 
  Permisiunile  sunt administrate  la nivel de server, asignate conectărilor și rolurilor pe server, și la nivel de 
bază de date, asignate utilizatorilor  și rolurilor bazei de date.

23 
 
a. Permisiunea  la nivel de server 
 SQL Server Profiler 
USE master 
GO 
GRANT ALTER TRACE TO <login > 
GO 
 
b. Permisiunea  la nivel de bază de date 
 Plan de execuție 
USE <database_name>  
GO 
GRANT SHOWPLAN  TO <user> 
GO 
 
 Permisiuni  pentru anumite tabele 
  Pentru a acorda permisiuni  pentru anumite tabele, tabelul de permisiuni  (#Permissions ) din 
scriptul SQL de mai jos trebuie completat  după cum urmează: 
o ObjectName : numele obiectului  din baza de date, pentru care utilizatorul  are nevoie de 
permisiuni  (tabel, vizualizare,  procedură stocată, funcție cu valori de tip Tabel, funcție 
scalară); 
o PermissionTypeId : tipul de permisiune  ales corect din permisiunile  disponibile  
(#PermissionTypes ); 
o DatabaseUser : utilizatorul  care are nevoie de permisiuni  pentru obiectul din baza de date. 
Nume permisiune   Descriere 
SELECT  Posibilitatea  de a efectua instrucțiuni SELECT în tabel. Se aplică pentru 
sinonime,  tabele și coloane, vizualizări și coloane. Permisiunea  poate fi 
acordată la nivel de bază de date, schemă sau obiect. 
INSERT  Posibilitatea  de a efectua instrucțiuni INSERT în tabel. Se aplică pentru 
sinonime,  tabele și coloane, vizualizări și coloane. Permisiunea  poate fi 
acordată la nivel de bază de date, schemă sau obiect. 
UPDATE  Posibilitatea  de a efectua instrucțiuni UPDATE în tabel. Se aplică pentru 
sinonime,  tabele și coloane, vizualizări și coloane. Permisiunea  poate fi 
acordată la nivel de bază de date, schemă sau obiect. 
DELETE  Posibilitatea  de a efectua instrucțiuni DELETE în tabel. Se aplică pentru toate 
clasele de obiecte, cu excepția DATABASE  SCOPED CONFIGURATION  și SERVER. 
REFERENCES   Este necesară pentru a crea o restricție de tip FOREIGN KEY, care referă tabelul 
respectiv.  
EXECUTE  Se aplică pentru script‐urile externe, proceduri,  funcții scalare și de agregare și 
sinonime 
VIEW DEFINITION   Se aplică pentru toate clasele de obiecte, cu excepția DATABASE  SCOPED 
CONFIGURATION  și SERVER.

24 
 
CREATE TABLE #PermissionTypes  (IdPermission  int, PermissionType  varchar (255), PermissionName  
varchar (255)) 
INSERT INTO #PermissionTypes  (IdPermission , PermissionType , PermissionName ) 
SELECT 1, 'Table/View/Table ‐valued function' , 'SELECT'  UNION 
SELECT 2, 'Table/View/Table ‐valued function' , 'INSERT'  UNION 
SELECT 3, 'Table/View/Table ‐valued function' , 'UPDATE'  UNION 
SELECT 4, 'Table/View/Table ‐valued function' , 'DELETE'  UNION 
SELECT 5, 'Table/View/Table ‐valued function' , 'REFERENCES'  UNION 
SELECT 6, 'Stored  procedure/Scalar  function' , 'EXECUTE'  UNION 
SELECT 7, 'Metadata' , 'VIEW DEFINITION'  
 
CREATE TABLE #Permissions  (ObjectName  varchar (255), PermissionTypeId  int, DatabaseUser  varchar (255)) 
INSERT INTO #Permissions  (ObjectName , PermissionTypeId , DatabaseUser ) 
SELECT '<table_name>' , 1, '<user>'  UNION  
SELECT '<table_name>' , 3, '<user>'  UNION 
SELECT '<stored_procedure>' , 6, '<user>'  UNION 
SELECT '<stored_procedure>' , 7, '<user>'  
 
DECLARE  @nsql NVARCHAR (MAX) 
SELECT @nsql = iSNULL (@nsql , '') + 'GRANT ' + PT.PermissionName  + ' ON ' + P.ObjectName  + ' TO ' + 
P.DatabaseUser  + CHAR (13) 
FROM #Permissions  P 
  JOIN #PermissionTypes  PT ON P.PermissionTypeId  = PT.IdPermission  
 
SELECT @nsql 
EXEC sp_executesql  @nsql 
 
IF OBJECT_ID  ('tempdb..#Permissions' ) IS NOT NULL 
  DROP TABLE #Permissions  
 
IF OBJECT_ID  ('tempdb..#PermissionTypes' ) IS NOT NULL 
  DROP TABLE #PermissionTypes  
 
 
3. Securitatea  la nivel de rețea 
 
Pentru a înțelege mai bine arhitectura  de rețea Charisma,  diagrama  de rețea, precum și diagrama  fluxului 
de date Charisma Online și Charisma HCM sunt prezentate  mai jos:

25 
 
Internal ZoneApp ZoneWeb Zone (DMZ) Database  Tier
Operational
DB Server
WAF
(web application firewall)
External Users
TS Gateway
SSL
SSL
Internet
Portal server
RDP/ GUI Server
(for external backoffice  users)
 
 
Această secțiune schițează o parte din abordările pentru hardware  și software,  utilizate pentru a asigura 
securitatea  rețelei. 
 
3.1 Segmentarea  rețelei 
 
  Segmentarea  rețelei este procesul de defalcare a rețelei în subrețele diferite, pentru consolidarea  
apărărilor de securitate.  Segmentarea  corespunz ătoare a rețelei reduce la minimum  nivelul de acces la informații 
confidențiale și, prin urmare, riscurile potențiale ce pot apărea între rețea compactă în cazul unui atac. După 
obținerea accesului neautorizat,  segmentarea  rețelei poate oferi control eficient pentru limitarea sau chiar 
stoparea efectelor unui următor atac la o intruziune  în rețea. 
  Segmentarea  poate fi efectuată fizic sau virtual. Cea fizică reprezintă metoda cea mai securizată și 
necesită crearea mai multor rețele fizice, fiecare cu propriile ei servere, switch‐uri și routere. Deoarece  este mai 
dificil de implementat,  segmentarea  virtuală este de departe mai populară. 
  Indiferent  de metoda aleasă, este recomandabil  să plasați serverul de baze de date și serverul de aplicații 
web într‐o zonă securizată și să le protejați cu firewall‐uri pentru a bloca toate conectările neașteptate și 
neautorizate.  Blocați tot traficul în mod prestabilit  și permiteți în mod explicit doar traficul specific. Această 
strategie este denumită principiul priv ilegiului minim  și funcționează prin a permite doar acces suficient pentru 
efectuarea  jobului necesar, impunând  control asupra rețelei. 
În afară de aceasta, închideți toate porturile care nu sunt necesare,  creând reguli de intrare sau de ieșire 
și efectuați audit regulat pentru a detecta porturile noi pe care se ascultă.  În plus, luați în considerare  definirea 
de reguli pentru firewall‐uri, pe baza adreselor  IP. Există două abordări: whitelist și blacklist. Whitelist pentru 
firewall oprește tot traficul în mod prestabilit  și permite doar traficul de la anumite adrese IP sau interval de

26 
 
adrese IP cunoscute  ca securizate,  pe când blacklist permite tot traficul și oprește adresele IP sau intervalul  de 
adrese IP nedorit. Abordarea  recomandat ă este whitelist; dacă doar adreselor  IP autorizate  le este permis să 
acceseze rețeaua și resursele acesteia, șansele de intruziune  malițioasă sunt reduse drastic. Totuși, alegerea uneia 
dintre abordări depinde de necesități și de cerințe. 
 
3.2 Comunicarea  securizată 
 
Comunicarea  dintre client și server este un alt punct slab, care necesită atenție. Există multe măsuri 
pentru reducerea  riscului de breșe de securitate  în timp ce datele sunt în tranzit și, în funcție de topologia  rețelei, 
pot fi utilizate una sau mai multe metode pentru criptarea traficului.  
 
3.2.1 Rețeaua privată virtuală (VPN) 
 
Este recomandabil  ca accesul la serverul de baze de date sau la serverul web să trebuiască să fie efectuat 
utilizând o rețea privată virtuală (VPN) ca metodă pentru securizarea  și criptarea comunicării dintre client și 
serverul la distanță pe internet. Deoarece  datele sunt criptate, va preveni majoritatea  formelor de atacuri de tip 
Man in the Middle, în care atacatorii  încearcă să intercepteze  datele în curs de transfer prin rețea. 
Exact cum un firewall protejeaz ă datele de pe calculatorul  local, VPN‐urile le protejeaz ă online și permit 
utilizatorilor  să acceseze în mod securizat,  din exterior, datele confidențiale de pe serverele private ale companiei  
și să partajeze  date de la distanță, prin intermediul  rețelelor publice. 
Există diferite tipuri de VPN‐uri, dar alegerea corectă a tipului corespunz ător depinde de mai multe 
aspecte, precum: ce tip de securitate  este necesar, cât de complexă trebuie să fie securitatea,  tipul de companie  
și, în final, bugetul. 
 
3.2.2 Comunicarea  HTTPS 
 
Dacă optați pentru a avea aplicații cu interfață pe internet, securitatea  conexiunii  este obligatorie.  Pentru 
modulele  online, puteți utiliza HTTPS (Hyper Text Transfer Protocol Secure), care este versiunea  securizată a 
HTTP, protocolul  prin care sunt trimise datele între browser‐ul dvs. și site‐ul web la care sunteți conectat.    
Principala  motivație pentru HTTPS este  autentificarea  site‐ului web accesat și protecția 
confidențialității și integrității datelor schimbate.  Protejeaz ă împotriva  atacurilor  de tip man‐in‐the‐middle. 
Criptarea bidirecțională a comunicărilor dintre un client și un server protejeaz ă împotriva   interceptării și 
modificării comunicării. În practică, aceasta oferă o garanție rezonabilă că se comunică fără interferen ța 
atacatorilor  cu site‐ul web cu care s‐a intenționat comunicarea,  nu cu un impostor.  
 
3.2.3 Conexiunile  desktop de la distanță 
 
În anumite cazuri, utilizatorii  Back‐Office trebuie să se conecteze  în mod securizat la server pentru 
operațiunile zilnice sau pentru suport tehnic. O pot face prin conexiuni  VPN sau prin protocoale  securizate,  oferite 
de furnizori terți. O opțiune oferită de Microsoft  este TS Gateway,  care permite utilizatorilor  la distanță autorizați 
să se conecteze  la resurse dintr‐o rețea corporațiunile internă sau privată, de pe orice dispozitiv  conectat la

27 
 
internet, care poate rula clientul Remote Desktop Connection  (RDC). TS Gateway integrează Remote Desktop 
Protocol (RDP) în cadrul RPC, în HTTP dintr‐o conexiune  Secure Sockets Layer (SSL). În acest mod, TS Gateway 
ajută la îmbunătățirea securității, stabilind o conexiune  criptată între utilizatorii  de la distanță de pe internet și 
resursele rețelei interne, pe care rulează aplicațiile lor de productivitate.  
 
3.2.4 Protocolul  de transfer securizat al fișierelor (SFTP) 
 
Pentru a transfera în mod securizat fișiere între două sisteme la distanță prin internet, Secure File 
Transfer Protocol (SFTP) poate utiliza o conexiune  securizată, prin care datele sunt transferate  utilizând un flux de 
date privat și sigur. SFTP utilizează SSH pentru a transfera fișiere și necesită autentificarea  clientului de către 
server. Spre diferență de FTP standard,  utilizează alt protocol și criptează atât comenzile,  cât și datele, 
împiedicând  transmiterea  parolelor și a informațiilor confidențiale ca text lizibil prin internet. 
Sistemele  de operare Microsoft  nu oferă nicio soluție integrată pentru organizarea  unui server SFTP 
protejat. IIS nu acceptă SFTP și, în acest caz, luați în considerare  instalarea  unei soluții de la terți (de exemplu: 
OpenSSH,  WinSCP, JScape, Cerberus FTP Server etc.). 
 
Observație: SFTP se recomand ă pentru clienții care utilizează transferul  de fișiere de pe un calculator  pe altul prin 
rețea și este o alternativ ă securizată la FTP sau FTP/S. Furnizeaz ă toate funcționalitățile oferite de aceste 
protocoale,  dar mai securizat și mai fiabil, cu configurare  mai ușoară. 
 
3.3 Monitorizarea  securității rețelei 
 
3.3.1 Sistemul de prevenire  și de detectare  a intruziunilor  
 
Intrusion Prevention  System (IPS) este o tehnologie  de prevenire  pentru securitatea  rețelei, care 
examineaz ă fluxurile de trafic în rețea pentru a detecta și a preveni vulnerabilit ățile. Principala  funcție a unui IPS 
este să analizeze tot traficul de intrare și de ieșire din rețea, în ce privește activitățile suspecte,  pentru a preveni 
pătrunderea  în rețeaua internă. IPS elimină imediat pachetele  de date nedorite sau malițioase, care pot provoca 
pagube grave rețelei. 
Intrusion Detection  System (IDS) funcționează similar cu un IPS, dar nu afectează fluxurile în niciun fel, ci 
doar înregistreaz ă sau alertează cu privire la traficul potențial malițios. Activitățile malițioase sunt colectate 
utilizând un sistem de management  al informațiilor și evenimentelor  de securitate  (SIEM), care poate face 
diferența dintre activitățile malițioase și alarmele false, pe baza regulilor definite anterior. 
Firewall‐ul, IPS și IDS sunt considerate  componentele  esențiale ale unei rețele, iar tabelul de mai jos 
descrie diferențele dintre acestea:

28 
 
 
Secțiune  Firewall  IDS  IPS 
Ce este?  Este un dispozitiv  de 
securitate  a rețelei, care 
filtrează traficul de rețea 
de intrare și de ieșire, pe 
baza regulilor 
predeterminate.  Este un dispozitiv  sau un 
software care 
monitorizeaz ă un trafic în 
ce privește activitatea  
malițioasă sau încălcările 
de politici și trimite alerte 
la detectare.  Este un dispozitiv  sau un 
software care inspecteaz ă 
traficul, îl detecteaz ă, îl 
clasifică, apoi oprește pro‐
activ traficul malițios. 
Principiul de 
funcționare Filtrează traficul pe baza 
adresei IP și a numerelor  
de porturi. Detecteaz ă traficul în timp 
real și caută tiparele de 
trafic sau semnăturile de 
atac, le înregistreaz ă, apoi 
generează alerte. Inspecteaz ă traficul în timp 
real și caută tiparele de 
trafic sau semnăturile de 
atac, apoi previne atacurile 
la detectare.  
Acțiune la detectarea  
traficului neautorizat  Blochează traficul.  Alertează/alarmeaz ă la 
detectarea  anomaliei.  Previne traficul prin 
eliminarea  pachetelor  de 
date la detectarea  
anomaliei.  
Tip de sistem  Activ.  Activ (monitorizeaz ă și 
apără automat) și/sau 
pasiv. Pasiv (monitorizeaz ă și 
înștiințează). 
Terminologii    Permite și blochează 
traficul conform 
regulilor pentru 
porturi/protocoale/IP   Detectare  pe baza 
anomaliilor  
 Detectarea  
semnăturilor 
 Monitorizare  
 Alarmare  Detectare  pe baza 
anomaliilor  
 Detectarea  
semnăturilor 
 Blocarea atacului 
Amplasare  în 
infrastructura  rețelei În linie, la perimetrul  
rețelei. În afara liniei directe de 
comunicare  (în afara 
benzii). Ca parte din linia directă de 
comunicare  (în linie). 
 
  O detectare  bazată pe semnătură va monitoriza  pachetele  din rețea și le va compara cu o bază de date de 
semnături sau atribute din amenințări malițioase cunoscute.  Detectarea  bazată pe anomalii va monitoriza  traficul 
de rețea și îl va compara cu un etalon stabilit. 
 
3.3.2 Breșele de securitate  și de date 
 
  Detectarea  intruziunii  din primul moment posibil poate fi efectuată, de asemenea,  prin analizarea  
fișierelor jurnal. Fișierele jurnal sunt generate de sistemele  de operare, aplicații, platforme  de servere, iar 
analizarea  acestora este principalul  mod de detectare  a evenimentelor  malițioase și de oprire a unei potențiale 
breșe de date. 
Se recomand ă cu tărie monitorizarea  jurnalelor  de evenimente  Windows,  iar următorul tabel schițează 
unele dintre cele mai importante  evenimente  care pot indica breșe de securitate  sau de date:

29 
 
Utilizarea și administrarea  conturilor  
Cale jurnal de evenimente   Nivel  ID 
eveniment  Sursă  Detalii 
Windows Logs > Security 
  Informational  4740  Security‐Auditing Blocări de conturi 
Informational  4728, 4732, 
4756 Security‐Auditing Utilizator adăugat în grup 
privilegiat  
Informational  4740  Security‐Auditing Modificare  de grup cu 
securitate  activată 
Informational  4740  Security‐Auditing Conectare  reușită la contul 
utilizatorului  
Informational  4740  Security‐Auditing Conectare  eșuată la contul 
utilizatorului  
Informational  4740  Security‐Auditing Conectare  la cont cu 
acreditări explicite 
Aplicația rămâne agățată și se închide 
Windows Logs > Application  Error  1000  Application  Error Eroare a aplicației 
Error  1002  Application  Error Aplicația rămâne agățată 
Error  1001  Windows Error 
Reporting  Raportarea  erorilor Windows  
Windows Logs > System  Error  1001  Windows Error 
Reporting  BSoD 
Jurnalul de evenimente  și politica de audit 
Windows Logs > System Informational  104  EventLog  Jurnalul de evenimente  a fost 
golit 
Informational  102  EventLog  Jurnalul de audit a fost golit 
Informational  4719  EventLog  Politica de audit de sistem a 
fost modificat ă 
Politica de grup și firewall‐ul Windows 
Windows Logs > System  Error  1129  GroupPolicy   Aplicația pentru politica de 
grup a eșuat din cauza 
conectivit ății 
Application  and Services Logs 
> Microsoft  > Windows > 
Windows Firewall With 
Advanced  Security Informational  2004  Windows Firewall 
With Advanced  
Security Adăugarea unei reguli pentru 
firewall 
Informational  2005  Windows Firewall 
With Advanced  
Security Modificarea  regulilor pentru 
firewall 
Informational  2006, 2033 Windows Firewall 
With Advanced  
Security Ștergerea regulilor pentru 
firewall 
Error  2009  Windows Firewall 
With Advanced  
Security Firewall‐ul a eșuat la 
încărcarea politicii de grup

30 
 
De asemenea,  breșa de date poate fi stopată prin cunoașterea modului în care fluxurile de date intră și ies 
din organizație și între toate punctele finale, unde sunt stocate datele confidențiale sau cine are acces la acestea. 
În afară de acestea, luați în considerare  proiectarea  politicilor  pentru unități de disc USB, pentru a preveni 
pierderea  informațiilor confidențiale: permiteți funcționalitatea  USB doar în caz de necesitate , pentru a limita 
riscul ca date neautorizate  să fie transferate  și, de asemenea,  impuneți scanarea USB pe calculator  la conectare,  
pentru a vă asigura că nu există niciun malware sau program malițios pe unitatea de disc. 
 
3.3.3 Prevenirea  pierderii datelor 
 
Data loss prevention  (DLP) este strategia utilizată pentru a garanta faptul că datele confidențiale nu se 
pierd, nu sunt utilizate incorect și nu sunt accesate de utilizatori  neautoriza ți. Vă recomand ăm să protejați 
informațiile confidențiale și critice pentru a împiedica  utilizatorii  să partajeze  date în mod accidental  sau malițios, 
fapt care ar supune datele organizației și datele personale  ale angajaților acesteia la risc. Pentru aceasta, 
software‐ul și instrumentele  DLP monitorizeaz ă și controleaz ă activitățile punctelor  finale pentru a proteja datele 
confidențiale și a stopa breșa de date. 
Un sistem de prevenire  a pierderii datelor oferă trei tipuri distincte de protecție: 
 Soluțiile DLP bazate pe rețea sunt concentrate  pe protejarea  datelor în timp ce acestea sunt în 
mișcare. Aceste soluții monitorizeaz ă traficul de rețea, traficul de e‐mailuri, mecanismele  
aplicațiilor web și de transfer al datelor, precum FTP. De asemenea,  inspecteaz ă subiectele  e‐
mailurilor,  mesajele și atașamentele  și criptează conținutul confidențial trimis prin e‐mail sau 
transferat  către dispozitivul  amovibil, în ce privește comunicarea  securizată și conformitatea  cu 
reglement ările; 
 Soluțiile DLP bazate pe centre de date și pe stocare sunt concentrate  pe protejarea  datelor în curs 
de utilizare din cadrul infrastructurii  centrului de date al unei organizații, precum servere de 
fișiere și baza de date; 
 Soluțiile DLP bazate pe puncte finale se concentreaz ă pe protejarea  datelor stocate , prin 
monitorizarea  sistemului  bazat pe calculatoare,  în ce privește anumite acțiuni ale utilizatorilor,  
precum trimiterea  unui e‐mail, copierea unui fișier pe un USB, scurgerea  de date sau tipărirea 
unui fișier. Acestea rezidă pe stațiile de lucru și pe laptopurile  utilizatorilor  finali; 
 Instrumentele  DLP contextuale  vizează riscul de expunere  accidental ă a datelor confidențiale în 
afara canalelor autorizate,  utilizând funcționalități de monitorizare,  blocare și remediere.  Aceste 
instrumente  permit impunerea  politicilor  companiei  pe baza clasificării conținutului. 
 
4. Concluzii 
 
Acest document  oferă un set de recomand ări pe care clienții trebuie să le analizeze și să le aplice doar pe 
cele corespunz ătoare pentru infrastructura  lor. În plus, se recomand ă cu tărie efectuarea  regulată a testelor de 
penetrare  a aplicațiilor și infrastructurii,  pentru a asigura certificarea  de securitate  a rețelei.

31 
 
Referințe 
 
[1] “Acunetix Web Vulnerabilities  Index ”, https://www.acunetix.co m/vulnerabilities/web/  
[2] “Issue Definition”,  https://portswigger.net/kb/issues  
[3] “Managing  SSL/TLS Protocols  and Cipher Suites for AD FS”, https://docs.microsoft.com/en ‐us/windows ‐
server/identity/ad ‐fs/operations/manage ‐ssl‐protocols ‐in‐ad‐fs 
[4] “Transparent  Data Encryption  (TDE)”, https://docs.microsoft.com/en ‐us/sql/relational ‐
databases/security/encryption/transparent ‐data‐encryption  
[5] “Transparent  Data Encryption”,  https://www.red ‐gate.com/simple ‐talk/sql/database ‐
administration/transparent ‐data‐encryption/  
[6] “Database ‐Level Roles”, https://docs.microsoft.com/en ‐us/sql/relational ‐databases/security/authentication ‐
access/database ‐level‐roles 
[7] “Server‐Level Roles”, https://docs.microsoft.com/en ‐us/sql/relational ‐databases/security/authentication ‐
access/server ‐level‐roles 
[8] “Permissions  (Database  Engine)”, https://docs.microsoft.com/en ‐us/sql/relational ‐
databases/security/permissions ‐database‐engine 
[9] “What Is Network Security”,  https://www.cisco.com/c/en/u s/products/security/what ‐is‐network‐security.html  
[10] “Web Server Security and Database  Server Security”,  https://www.acunetix.com/websitesecurity/webserver ‐
security/ 
[11] “Data Loss Prevention  Guide ”, https://www.veracode.com/security/guide ‐data‐loss‐prevention