Buna ziua

As dori sa pun urmatoarea problema:

Am o aplicatie VB.NET care lucreaza cu o bd SQL Server 2005. Autentificare la bd se face prin windows authentication. Userul windows este atasat la un Datatbase Role care contine toate obiectele si drepturile necesare aplicatiei. Pana acum nu mi-am pus pb securizarii bd. As dori ca userul windows care foloseste aplicatia sa nu aiba initial niciun drept pe bd. In momentul logarii as dori ca userul sa primeasca drepturile din database role dupa ce verific aplicatia cu care se logheaza si numele userului. Am gasit ideea trigger-ului pe conect pe server dar nu reusesc sa execut procedura sistem de adaugare a userului la database role-ul dorit in cele doua conditii de mai sus.
E corecta abordare cu Trigger on connect on server sau exista si alte metode de securizare a bd (execute as, grant impersonate etc.)?

Va multumesc.

Denisa

Ideea folosirii logon trigger-ului este corecta.

Flow-ul este diferit:

1. Puteti folosi un utilizator Windows cu toate drepturile necesare asignate.
2. In momentul conectarii in logon-trigger verificati numele aplicatiei si numele user-ului (aici e un pic confuza problema - ati ca se foloseste un singur User Windows prin urmare de ce ati verifica utilizatorul ?). Daca nu corespund criteriilor de verificare executati ROLLBACK si respingeti incercarea de conectare.

---

Cristian Andrei Lefter, SQL Server MVP
MCT, MCSA, MCDBA, MCAD, MCSD .NET,
MCTS, MCITP - Database Administrator SQL Server 2005
http://sqlserver.ro

Poti vedea incerca si cu Application Role.

Idea cu application role e ca aplicatia ta ruleaza intr-un aunmit cintext dxe securitate indiferent de userul care se logheaza.

Vezi in bol ce e application role si cum se foloseste

---

Secolul XXI ori va fi religios ori nu va fi deloc

multumesc ptr raspunsul prompt.

sunt mai multi useri windows care se logheaza cu aplicatia si i-am grupat intr-un windows grup pe care l-am definit ca login si user in sql. dar asta nu cred ca are vreo importanta. ideea de mai sus ramane valabila.

problema pe care o vad eu e alta:
ce se intampla daca unul din userii din grup scrie o aplicatie .net in care seteaza numele serverului, bd si integrated security=true (pe care le ia din fereastra de login ale aplicatiei mele).
numele de aplicatie pe care am reusit sa-l "extrag" din sql server este ceva de genul: ".net sql provider". deci, merge cu orice aplicatie .net. exista alte campuri speciale care ofera mai multe amanunte despre aplicatia client?

2. de ce nu merge ideea mea: userul (grupul windows) sa nu aiba nici un drept, sa creez un database role cu obiectele si drepturile necesare si, in loggon trigger, in cazul in care se indeplinesc conditiile (iarasi ramane pb. numelui vag al aplicatiei) sa adaug userul (grupul de user) la database rolul respectiv (da o eroare care blocheaza orice login ulterior, inclusiv dba). eroarea am identificat-o la linia de adaugare user la role. in contextul logon trigger nu pot executa proceduri system sau nu pot lucra cu useri si grupuri?

multumesc inca o data

multumesc pentru raspuns.

am citit ca application roles nu sunt indicate (au mai multe contraindicatii decat indicatii).
vezi articolul:
http://www.sqlservercentral.com/articles/Security/sqlserversecurityprosandconsofapplicationroles/1116/

cu stima

Trebuie stabilit exact ce face fiecare user la nivel de baza de date; mai bine mai putine permisiuni pe obiecte pentru inceput decat sa aiba prea multe (am vazut programatori care dadeau contului de login rolul sysadmin desi se lucra numai pe o baza de date si nu era nevoie de o asemenea capabilitate); de asemnea alt aspect de securitate care poate fi tratat este accesul la tabele prin view-uri si proceduri stocate, poate userul are nevoie doar de 3 coloane din cele 17 ale tabelului !

---

Gheorghe Ciubuc,SQL Server Influencer, MCP(SQL 2000), MCTS (SQL Server 2005) , OCA(Oracle 9i), Sybase(Brainbench)

După câte înţeleg vreţi ca utilizatorii să se conecteze la baza de date cu Integrated Security, însă doriţi să aibă drepturi în bazele de date doar dacă se conectează folosind programul dvs. În caz că folosesc un alt program, doriţi să nu aibă acces (deşi folosesc aceleaşi conturi de utilizatori, tot cu Integrated Security). O soluţie (A) ar fi application roles, iar o altă soluţie (B) ar fi un logon trigger care verifică APP_NAME(). Voi detalia puţin fiecare din aceste soluţii:

(A) dacă vrem să folosim soluţia cu application role, atunci login-urile asociate acelor utilizatori (sau login-ul asociat grupului de utilizatori) nu va avea niciun fel de drept de a citi sau scrie în bazele de date, ci doar dreptul de login. Creem un application role cu o parolă care să fie hard-coded în aplicaţie şi îi dăm acestui application role toate drepturile de care are nevoie. Când aplicaţia deschide o conexiune, execută sp_setapprole cu parola hard-coded şi astfel va avea acces la date.

Problema la această soluţie este că cineva ar putea să decompileze aplicaţia şi să afle parola hard-coded.

(B) dacă vrem să folosim soluţia cu logon triggers, atunci dăm toate drepturile utilizatorilor respectivi, dar facem un trigger de logon care să dea eroare şi să facă ROLLBACK (anulând astfel conexiunea respectivă) în caz că APP_NAME() nu conţine numele aplicaţiei noastre.

Problema la această soluţie este că cineva ar putea să se conecteze dintr-o altă aplicaţie, modificând string-ul de conectare ca să conţină numele aplicaţiei noastre.

De fapt, ideea este că dvs doriţi ca baza de date să autentifice aplicaţia (nu utilizatorul care se conectează), ceea ce nu prea este posibil. Pentru a fi 100% sigur, ar trebui să existe o modalitate prin care server-ul să verifice semnătura digitală a aplicaţiei, iar o asemenea infrastructură nu există. Vezi răspunsurile lui Raul Garcia din următorul thread: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=790497&SiteID=1

Răzvan

inteleg ce spuneti, dar...

...inseamna, din cate citesc, ca nu exista solutie de securizare a bd?!? inteleg ca acea conditie de login si numeAplicatie se poate eluda de userul respectiv daca creeaza o aplicatie cu acelasi nume. (nu exista niste campuri system sql care sa extraga mai multe detalii despre aplicatie?)

problema o complic si mai mult: grupul de useri (din grupul windows definit in sql: WindowsDomain\Group) se conecteaza la acea bd prin acea aplicatie si in aplicatie se folosesc si anumite campuri si proceduri stocate din alte bd. asa ca nu prea pot folosi application role. pe de alta parte, pe serverul respectiv exista si alte bd care nu au legatura cu aplicatia si in care unii useri din acel grup au drepturi legale...
deci nu pot sa dau rollback in conect trigger fiindca as interzice accesul la server oricarui alt user care drepturi legale (inclusiv administratori)!!!

sa revenim: ce conditie trebuie sa pun care sa imi asigure 100% securizarea bd? ganditi-va ca daca nu pun conditia de app_name  "intrusul" poate folosi access ca si client folosindu-se de windows authentication.

aceeasi pb apare daca in fereastra de login a aplicatiei as folosi login sql ptr autentificare sql. ("intrusul" ar folosi acel login din access).

deci, vreo idee, best practices? voi ce securizare folositi? ma gandesc ca exista asa ceva.

cu stima

Din pacate cred ca nu exista un "silver bullet" pentru problema ta. Securizare buna poti obtine printr-o combinatie de tehnici la nivel de baza de date, server de baze de date (---> sistem de operare), infrastructura si politici organizationale (aici intra si "user education").

E preferabil ca aplicatia sa poata fi si folosita, chiar daca datele sunt "la adapost"...

 

Există soluţii de securizare a bazei de date, iar acestea se referă la securizarea bazei de date, indiferent cu ce aplicaţie este accesată. Ideea este să faci login-uri pentru fiecare grup sau utilizator care ar trebui să aibe un drepturi diferite şi să acorzi aceste drepturi pe fiecare tabelă, view sau procedură stocată, după necesităţi. Dacă vrei, poţi să acorzi drepturile unor roluri (nu direct user-ilor) şi să adaugi fiecare user într-unul sau mai multe roluri, după caz.

Iar dacă un utilizator are voie să vadă datele dintr-o tabelă, dar n-are voie să le modifice, atunci nu ar trebui să te intereseze cu ce aplicaţie le vede: în definitiv, sunt aceleaşi date (dacă e nevoie, poţi să defineşti drepturi şi la nivel de coloană). Dacă un utilizator are drepturi să modifice datele dintr-o tabelă, atunci poate să le modifice cu orice aplicaţie, în limita constrângerilor care sunt definite în baza de date (foreign keys, check constraints, trigger-e, etc). Astfel, aplicaţia devine doar o interfaţă elegantă, dar business rule-urile sunt definite în baza de date şi indiferent cu ce aplicaţie sunt scrise datele, baza de date conţine datele corecte, pentru că verificările sunt făcute de server, nu de client.

Răzvan

am si eudoua intrebari pe aceasta tema:

1. exista vre-un set de setari pt sql server 2005 expers care sa imi permita sa opresc accesul la o baza de date tuturor userilor in afara de unul ales de mine? (deci as vrea sa ca nici macar sa-ul sa nu poata accesa baza - folosesc sql server autentification)


2. se poate face sa nu fie posibila copierea si utilizarea bazei pe un alt server? (deci daca opreste sql server am nevoie sa nu poata copia fiserele bazei de date sau macar sa nu le poata atasa la alt server) - userii au in prezent acces la fisierele bazei (deci nu pot folosi limitarea de drepturi din windows)

deci nu ma intereseaza ce fac cei care stiu username-ul si parola alese de mine insa restul lumii am nevoie sa nu poata citii din acea baza de date (cel mai simplu ar fi fost sa mut baza pe un calculator la care sa nu aibe acces insa acest lucru nu este posibil )

multumesc anticipat.