Userroles in asp.net en sql synchroon?

[Verwijderd]

Ik ben bezig me te verdiepen in een wat meer hanteerbare methode om gegevens de DB in te slingeren er weer uit te halen met ASP.net/VB als Frontend. Ik stuitte daarbij op het gebruik van DALs en BLLs. Nu begrijp ik het opzetten van een DAL en BLL wel aardig op beginnersniveau, maar wat voor mij echt een raadsel is, dat is de beveiliging van de database.

De context:
In mijn vorige projectje (Classic ASP) riep ik stored procedures aan (wat een schrijfwerk!) en in de DB had ik een aantal roles welke dan weer al dan niet toegang hadden om iets toe te voegen/te bekijken/uit te voeren. Nu had ik maar twee roles (admin en users) dus dat was redelijk makkelijk. De users hadden op UI niveau alleen in beeld wat ze mochten doen en als admin(alleen ikzelf) kon ik het nodige corrigeren rechtstreeks in SQL server (Ik weet het behoorlijk quick & dirty).

Mijn probleem:
In mijn nieuwe projectje wordt het allemaal wat serieuzer met meerdere rollen en een complexere database en UI. Nu kan ik nog steeds allerlei rollen in SQL server aanmaken en deze al dan niet recht geven iets te doen, maar ik wil eigenlijk dat de frontend zich ook een beetje bewust is van wat de betreffende user mag of niet mag. Het lijkt me slordig om alleen de frontend te voorzien van een membership-systeem en vervolgens alleen van daaruit te bepalen wie wat mag op de DB en dan de DB "open" laten voor elk achterdeur misbruik wat je je maar kan voorstellen. Het misbruik zal overigens meevallen omdat het op het intranet draait en niet op internet. Nu heb ik al behoorlijk lang gezocht naar artikelen die iets beschrijven over membership in asp.net en de beveiliging van je database, maar ben helaas nog niets bruikbaars tegengekomen.

Wie helpt deze beginner op weg? Mijn dank is groot!

Ik gebruik overigens: Web developer 2005 express (VB.NET), SQL Server 2005 Express, .NET 2.0

[gorgi_19]

Je controleert toch op User.IsInRole of een bepaalde user rechten heeft om iets te doen of niet?

[Verwijderd]

@gorgi_19: Ik heb inderdaad al gelezen dat je met User.IsInRole kan controleren welke ASP.NET rol de user heeft, maar dan moet je blijkbaar zowel in ASP.NET als in SQL server alle rollen en permissies apart instellen of begrijp ik het verkeerd Het leek mij zo mooi als er een manier is om op één plek vast te leggen wat iemand mag en dat het vervolgens zowel in de frontend als in de DB geregeld is.

Of zou je het volgende kunnen doen:
Stel dat je alleen in de frontend alles regelt hoe stel je dan de rechten voor de database in? Schakel je dan impersonate in web.config uit en geef je de asp.net account in sql server toegang tot alles, zodat er via de achterdeur niet met SQL server gerommelt kan worden?

[gorgi_19]

Verwijderd schreef op dinsdag 20 maart 2007 @ 10:58:
@gorgi_19: Ik heb inderdaad al gelezen dat je met User.IsInRole kan controleren welke ASP.NET rol de user heeft, maar dan moet je blijkbaar zowel in ASP.NET als in SQL server alle rollen en permissies apart instellen of begrijp ik het verkeerd Het leek mij zo mooi als er een manier is om op één plek vast te leggen wat iemand mag en dat het vervolgens zowel in de frontend als in de DB geregeld is.

een rol in SQL Server is een compleet ander iets dan een rol in ASP.Net

Of zou je het volgende kunnen doen:
Stel dat je alleen in de frontend alles regelt hoe stel je dan de rechten voor de database in? Schakel je dan impersonate in web.config uit en geef je de asp.net account in sql server toegang tot alles, zodat er via de achterdeur niet met SQL server gerommelt kan worden?

Waarom maak je niet één account voor SQL Server, deze geef je de benodigde rechten. Vervolgens laat je ASP.Net de benodigde acties uitvoeren. Normaliter kan je toch niet in de web.config kijken en heb je toch niet het useraccount.

[Verwijderd]

@gorgi_19: Dank voor de bevestiging. Jouw laatste stuk is precies wat ik bedoelde te zeggen! Zal inderdaad de rollen aan de voorzijde vastleggen en de benadering van de database via de connectionstring met vaste account (ipv Active Domain-user authentication) in we.config laten lopen.

Ik kan weer aan de bak. Grote dank!!

[__fred__]

Verwijderd schreef op dinsdag 20 maart 2007 @ 11:23:
@gorgi_19: Dank voor de bevestiging. Jouw laatste stuk is precies wat ik bedoelde te zeggen! Zal inderdaad de rollen aan de voorzijde vastleggen en de benadering van de database via de connectionstring met vaste account (ipv Active Domain-user authentication) in we.config laten lopen.

Ik kan weer aan de bak. Grote dank!!

En dit is juist het meest linke dat je kunt doen. De kans is dan groot dat als iemand een route door je frontend heen vindt, vervolgens je hele database open ligt voor serieuze mishandeling.
Ik zou die user gelijk DB-owner rechten geven, lekker makelijk, dan kan ie overal bij.
Misschien kun je dan ook gelijk de website zonder impersonation laten draaien, scheelt je ook weer moeilijk je active directory beheren, hoef je alleen maar je users in de DB te houden.
En als klap op de vuurpijl: Als je dan toch een directory met write permissions nodig hebt op de server, dan maak je die ook met de ene vaste account. Dan weet je zeker dat gebruiker1 wel een manier vindt, om over de geuploade plaatjes van gebruiker2 heen te krassen.

Netter zou misschien zijn om je users in de active directory te stoppen. en Microsoft Authorization Manager te gebruiken om je rollen te definieren.
Kun je gelijk je users en rollen beheren met een MMC snap-in.

Kijk ook eens naar http://www.odetocode.com/Articles/427.aspx en http://www.odetocode.com/Articles/428.aspx

verder zou je je DB nog extra kunnen securen door voor elke rol een schema te maken in de database en je users aan een bepaald schema koppelen. (kan alleen in SQL server 2005, waar er geen harde link is tussen user en schema).
Of door je roles te koppelen aan groepen die alleen permissies hebben op bepaalde SPs en niet op tabellen.

[Not Pingu]

__fred__ schreef op dinsdag 20 maart 2007 @ 23:10:
En dit is juist het meest linke dat je kunt doen. De kans is dan groot dat als iemand een route door je frontend heen vindt, vervolgens je hele database open ligt voor serieuze mishandeling.

Huh? De webapplicatie beheert zelf de toegang tot database en filesystem. Het is volkomen veilig om je connectionstring in je web.config op te slaan, zolang de applicatie niet per ongeluk inzicht kan geven in de security gegevens.

Aparte users op je db aanmaken voor het uitvoeren van bepaalde taken lijkt me niet alleen erg lastig te beheren, ook kun je niet meer alle DB operaties per request over 1 connection afhandelen en als een hacker al bij de security gegevens van 1 DB user kan, kan ie ook bij de rest.

[__fred__]

Not Pingu schreef op dinsdag 20 maart 2007 @ 23:45:
[...]

Huh? De webapplicatie beheert zelf de toegang tot database en filesystem. Het is volkomen veilig om je connectionstring in je web.config op te slaan, zolang de applicatie niet per ongeluk inzicht kan geven in de security gegevens.

De connectionstring is niet zozeer het probleem (ervanuitgaande dat er integrated security gebruikt wordt. Anders is het altijd een risico omdat er in plain text een password ergens in een file staat, waar het niet hoeft.) Het probleem zit hem in het feit dat je de webapplicatie volledig verantwoordelijk maakt voor de security van het systeem en dat bij het doorbreken daarvan, de DB volledig open ligt.
SQL injection wordt zo wel erg lucratief (ja, ik weet dat er hele simpele manieren zijn, om het te voorkomen.).
Als je via permissions bepaalde delen van je schema extra kunt beschermen door op user en groepniveau te beveiligen, dan zou ik dat niet nalaten. Dat zijn dingen, gegeven dat met door de webapplicatie heengebroken is, waardoor je DB nog eens extra beschermd wordt.
Het niet direct kunnen connecten naar SQL server kun je heel makkelijk voorkomen door iets als een IP-filter, waardoor alleen de webapplicatie kan connecten.

Not Pingu schreef op dinsdag 20 maart 2007 @ 23:45:
[...]
Aparte users op je db aanmaken voor het uitvoeren van bepaalde taken lijkt me niet alleen erg lastig te beheren, ook kun je niet meer alle DB operaties per request over 1 connection afhandelen en als een hacker al bij de security gegevens van 1 DB user kan, kan ie ook bij de rest.

.NET doet aan connection pooling dus je hebt sowieso al een aantal connecties naar je DB open. Het zullen er allicht iets meer worden als je veel users op je site kent, maar in een intranetomgeving lijkt me niet dat je bottleneck gaat worden. Anders had MS het ook niet zo bewust die richting opgestuurd.
Verder lijkt het me niet persé logisch dat je de active-directory database ook ontsluit via .NET om de securitygegevens op het web te tonen. Sterker nog, default zijn de wachtwoorden in de AD gehasht, en gebruik je een provider om te "vragen" aan AD of iemand geauthenticeerd (en/of geautoriseerd) is. AD werkt op basis van kerberostickets, een bewezen veiligheidsysteem dat ook nog eens elke 10 minuten een nieuwe ticket uitgeeft, nog weer een extra beveiliging tegen het stelen van een sessie. Itt je eigen tabelletje in SQL dat zich nog maar moet bewijzen tegen invloeden van buitenaf.

[giMoz]

Mooiere manier die wij vaak hanteren is wel de users in je front end laten zitten, en de connectiestring in de config file, maar die user heeft alleen rechten op de database om door ons gemaakte stored procedures uit te voeren (dus geen system stp's) en geen losse select op te tabellen te doen.

Op die kan je op database niveau afdwingen dat gebruikers alleen maar kunnen wat jij wil dat ze kunnen.
(evt kan je aan elke stp een username /pass meegeven als check en die controleren, 2 regels extra in elke stp en erg goed beveiligd...

[ Voor 4% gewijzigd door giMoz op 21-03-2007 09:17 ]

[Verwijderd]

Heftige reacties allemaal Gelukkig maar, want ongeinteresseerdheid is absoluut ongewenst natuurlijk.

Er zijn in mijnproject grofweg 3 gebruikersniveaus:

• Hoofdgebruiker - mag in meerdere projecten gegevens wijzigen en alles inzien
• Projectadministrateur - mag in eigen project gegevens wijzigen en projectmedewerkers toewijzen en alles in eigen project inzien
• Projectmedewerker - mag in eigen project beperkt data wijzigen en alles inzien

Alles zal lopen via SPs.

Wat betreft het beveiligingsvraagstuk en mijn primaire vraag:
-blijkbaar is het definieren van rollen zowel in frontend als in database de veiligste methode maar vergt een dubbele administratie
-Een tussenweg zou kunnen zijn dat de connectionstring waarmee je connect met de DB alleen rechten krijgt op de door de hoogste gebruiker benodigde SPs. Waarmee er dus op die manier nooit admin/sa rechten gebruikt worden in de connectionstring. Niet helemaal volgens het boekje maar voldoende veilig voor een intranet-omgeving wellicht

Blijf een enorme beginner natuurlijk, dus graag jullie reactie of bovenstaande samenvatting enigszins hout snijdt....