Fórumok
Sziasztok,
Adott egy DB, amit egy .NET programmal ernek el (a programban van egy service user beallitva). eddig local SQL userrel ment, de szeretnenk helyette domain usert hasznalni. Viszont ha jol ertelmezem, ket opcio van csak:
1. local userrel, a connection stringben meghatarozva.
2. domain userrel, de akkor az auth "pass through", tehat az appot futtato user accountal auth-ol be.
Van arra esetleg megoldas, hogy a kodban meghatarozott domain userrel is mukodjon a dolog?
Hozzászólások
Ha ez nem az:
https://www.connectionstrings.com/sql-server-native-client-11-0-oledb-p…
attól még ezen az oldalon biztosan van rá megoldás, ha a megoldás létezik.
Vegigneztuk ezt is, nincs ra olyan pelda, ami a mi esetunk.
Esetleg connection string-be a név-jelszó mellé egy:
Authentication=Active Directory Password
Nem próbáltam, de azt gondolnám, akkor nem a local sql userek felé próbálná a jelszót.
Ezt probaltuk, nem megy sajna.
Feltételezem a connection string-ben lévő domain user fel van véve a security database-be sql-en belül és van elég joga, az sql server meg member server a domain-ben. (ettől függetlenül lehet ezt a paramétert kell kombinálni a domain\username formátumú User Id-vel)
Igen, igy ahogy irod.
Esetleg?
Aláírás _Franko_ miatt törölve.
neut @
Igy is probaltuk, nem megy. (a \\ eliras? mert ugy mondjuk nem neztuk :) )
Hat a \ az escape karakter, szoval erdemes kiprobalni ugy is. :)
Nem elírás :D
Aláírás _Franko_ miatt törölve.
neut @
nem megy igy sem.
Elv az impersonation lenne meg a megoldas, de a fejlesztok ezt nem akarjak, mert sok melo...
mi a gond a "pass through"-val?
neked aztan fura humorod van...
Fejlesztok nem akarjak... gyanitom azert, mert a service user tobb dolgot tehet, mint amire a userek a programban kepesek....
setapprole nem megoldas?
https://learn.microsoft.com/en-us/sql/relational-databases/security/aut…
neked aztan fura humorod van...
Szamomra erdekesnek tunik! Koszi, tovabbitom a fejlesztok fele! (nem tudom mi melo ezt implementalni... kb ezen fg mulni a dolog)
hat elvileg csak egy exec sp_setapprole a programban. elotte letre kell hozni az approle-t az adatbazisban.
neked aztan fura humorod van...
És a service user jelszavát hol tárolnád? A programban, amit futtatnak a userek? Tehát akár ki is olvashatják, csatlakozhatnak maguk azzal a jelszóval, és máris mindent megtehetnek, amit a saját account-tal amúgy nem. Nem ajánlom ezt az irányt. És ezen az app role sem fog segíteni, a probléma gyökere ugyanaz.
Ez egy desktop app? És hogyan kezelnéd biztonságos módon a domain-es service account jelszavát (akár impersonation-t használva, akár más módszerrel), hogy azt a programot futtató felhasználó ne tudja kiolvasni sehonnan? Nekem ez nem áll össze, ha biztonságos megoldást akarsz, úgy hogy nincsenek lerakva mindenki által ismert jelszavak mindenhová, akkor márpedig az appot futtató user nevében kell elérni a DB-t.
"az appot futtató user nevében kell elérni a DB-t."
ezzel ugyanugy okozhat gondot Marineni. feldob egy SSMS-t, es hozzafer az adatokhoz, akar torolhet is belole.
egy par 100MB-os exe-bol kicsit nehezebb kiolvasni az approle jelszavat, foleg ha nem statikus string-kent van lerakva benne. persze nem ismerjuk a skilljeit.
neked aztan fura humorod van...
"eldob egy SSMS-t, es hozzafer az adatokhoz, akar torolhet is belole."
Jóvicc. A user jogosultságát nagyon finoman be lehet (és kell is) állitani. Nemhogy a törlést lehet elvenni tőle, de még azt is, hogy a tábla melyik részét (oszlop vagy akár sor szinten) olvashatja.
Olyan is van, hogy egyáltlán nincs semmilyen táblára, semmilyen joga, mindent tárolt eljárásból, view-ból, function-ból ér el.
"Jóvicc. A user jogosultságát nagyon finoman be lehet (és kell is) állitani. Nemhogy a törlést lehet elvenni tőle, de még azt is, hogy a tábla melyik részét (oszlop vagy akár sor szinten) olvashatja."
akkor o nem is ir bele? nem modositja? csak olvaso user?
"Olyan is van, hogy egyáltlán nincs semmilyen táblára, semmilyen joga, mindent tárolt eljárásból, view-ból, function-ból ér el."
es ezek nem futtathatok SSMS-bol?
neked aztan fura humorod van...
Ha beleir, akkor azt tárolt eljáráson keresztül teszi. Az pedig ellenőrzi, hogy mondjuk övé-e az adott termék. Ha igen, akkor pl. pont ugyanúgy át tudja irni a termék megnevezését a tárolt eljárás kézi meghivásával, mintha a desktop programot futtatná.
De pl. az árát nem tudja átirni mert ahhoz nincs joga.
Pontosan azt tudja megtenni SSMS-ből, mint a desktop programból, csak kényelmetlenebbül.
De, de pont azert menne sproc-on keresztul minden, mert ott olyan authorizacios logikat kodolsz bele, amilyet csak akarsz.
az oke amit irtok, tamogatom is a szandekot, de a feladat nem az volt, hogy ujracsinaljak az authorizacios logikat.
neked aztan fura humorod van...
nem stringkent van tarolva.
Mindegy hogy tárolod, ha bármilyen trükkösnek gondolt formában ott van a programban, és abból a program össze tud állítani egy connection string-et, akkor az definíció szerint nem lehet biztonságos.
Ha ragaszkodnak ahhoz a viszonylag elavult koncepcióhoz, hogy nincs köztes web API réteg, hanem a desktop app közvetlenül éri el a DB-t, akkor pont úgy kell megoldani a dolgokat, hogy az adatbázisban a domaines user pont annyi dolgot tudjon elérni, amire hivatalosan is joga van. És mindegy, hogy ezt a desktop app-ból, vagy SSMS-ből teszi. Ez a gyakorlatban T-SQL tárolt eljárásokat jelent, ezen a nyelven meglehetősen nehezen karbantartható üzleti és authorizációs logikákkal, ezért is írtam, hogy ez tipikusan elavult koncepció.
A problémán nem segít a service user koncepció. Ha bármilyen módszerrel tárolva van a service user jelszó a usereknek odaadott programban, akkor az csak security by obscurity, más néven security hole.
Azért ez nyilván feladatfüggő. Van ahol gyakorlatilag az adatábázis 95%-át irhatja szoftverből a user. Oda bőven elég elvenni pár kritikus oszlopról az irás vagy akár az olvasási jogot és nyugodtan rá lehet ereszteni közvetlenül a táblára a usereket, mert semmi plusz hibát/kárt nem tud elkövetni SSMS-ből, amit a programból is ne tudna elkövetni.
Máshol meg nyilván tárolt eljárásozni kell, máshol meg komplex middleware-t irni.
meg nyilvan az sem mindegy, hogy a program barki altal hozzaferheto, vagy a felhasznalot minden nap 3 fegyveres kiseri a gephez, es ha csak veletlenul rossz gombot nyom, maris viszik kivegezni.
neked aztan fura humorod van...
Ha már közvetlen kapcsolat kell a DB-hez, a kód (bináris) miért nem a futtató user nevében probál csatlakozni a DB-hez?
Hogyan kívánod tárolni és használni a DB kapcsolódáshoz szükséges credentialt a futtató user környezetében?
(úgy hogy az lehetőleg ne férjen hozzá, mert akkor már semmi értelme a szeparációnak)