[MSSQL] Application Roles

[Gino]

Om onze kennis zo goed mogelijk te kunnen beschermen willen we voor onze commerciële applicatie het bekijken en wijzigen van tabellen, stored procedures, views en functions uitschakelen. Dit om te voorkomen dat men via bvb. SQL Server Managment Studio snel de database kan bekijken en aanpassen nadat deze is geinstalleerd op de pc van de klant. Het aanmaken van een database en bijwerken van structuur en dergelijke gebeurd door een zelf geschreven applicatie die gewoon SQL scripts uitvoert. Enkel deze applicatie zou de structuur mogen bijwerken. Hierbij dacht ik aan het volgende mogelijkheden:
Optie 1

• Application Role toevoegen aan de database en permissies toekennen zodat enkel indien deze role geactiveerd is de structuur kan bijgewerkt worden
• Standaard alle functionaliteit voor het wijzigen en bekijken van de structuur uitschakelen voor elke user

Hierbij zit mijn probleem in het laatste puntje, het is me nog op geen enkele manier gelukt om dit te bereiken . Echter ljikt me dit een aangewezen oplossing om via een application role de update applicatie meer rechten te geven dan een user heeft.

Optie 2
Gebruik maken van een Schema, echter is me dit nog niet geheel duidelijk hoe dit juist werkt en of dit wel een correcte oplossing is voor ons probleem?

Optie 3
Gebruik maken van encrypted stored procedures en view met de optie WITH ENCRYPTION. Dit is echter de laatste optie aangezien we dan 2 versies (release en development) moeten onderhouden. Dit omdat de stored procedures of views die aangemaakt zijn met encryption op geen enkele manier meer te bekijken zijn zelfs niet voor development doeleinden. Tevens is de structuur van de tabellen hiermee nog steeds zichtbaar

Na veel googlen en lezen in de msdn help heb ik nog geen goede oplossing gevonden. Ik vroeg me dan ook af hoe jullie dit probleem (zouden) aanpakken? Indien er nog andere mogelijkheden zijn dan bovenstaande opties, let me know .

[whoami]

Application roles hebben het vervelende probleem (in SQL Server 2000 toch), dat dit niet blijkt te werken i.c.m. connection pooling.
Zie ook hier

Volgens mij zijn application roles trouwens niet geschikt voor het geen jij wilt doen.
Wat jij moet doen -imho- is er voor zorgen dat jouw klanten het sa password niet kennen, en geen toegang hebben tot eender welke account die in de dbcreator, sysadmin serverroles zit.

Indien je als user geen dbcreator, sysadmin, ... bent, dan kan je geen structuurwijzigingen aan de DB doorvoeren.
't Kan zijn dat er nog meerdere serverroles bestaan die wijzigen van structuur toelaten. Je zou eens in de BOL moeten kijken en alle fixed server roles moeten nagaan om te zien wat hun rechten nu precies zijn.

De structuur van de tabellen verbergen is volgens mij niet doenbaar (en ook niet wenselijk).

[ Voor 91% gewijzigd door whoami op 01-07-2008 20:47 ]

[Gino]

whoami schreef op dinsdag 01 juli 2008 @ 20:39:
Application roles hebben het vervelende probleem (in SQL Server 2000 toch), dat dit niet blijkt te werken i.c.m. connection pooling.
Zie ook hier

Connection pooling is in ons geval niet het grootste probleem aangezien de application role enkel actief moet zijn tijdens het uitvoeren van update scripts. Hiervoor gebruiken we SMO.

Volgens mij zijn application roles trouwens niet geschikt voor het geen jij wilt doen.
Wat jij moet doen -imho- is er voor zorgen dat jouw klanten het sa password niet kennen, en geen toegang hebben tot eender welke account die in de dbcreator, sysadmin serverroles zit.

Dit zou inderdaad een oplossing zijn. Echter zijn er ook klanten die al SQL Servers in eigen beheer hebben waarbinnen onze database/applicatie komt te draaien. Bij deze database servers is het password van sa geheim voor ons en niet voor hun. Tevens kan men dus ook zelf accounts toevoegen aan de serverroles. Is het niet mogelijk om voor 1 bepaalde database alle toegang te ontzeggen buiten voor de door ons zelf aangemaakte users/application role?

[xtra]

Zolang de klant toegang heeft tot zijn PC/Server waarop MS-SQL staat geïnstalleerd kun je je datestructuur nauwelijks echt verbergen volgens mij. Je databestand kopiëren naar een andere server waarop je sa bent is al genoeg.

Misschien moet je er eerder aan denken een deel van je routines niet in SQL Server maar gecompileerd in een andere taal te maken. Daar zou je misschien ook wat views mee kunnen verbergen. Je data blijft dan nog steeds in te zien door de klant. (Wat ik als klant uit praktische overwegingen wel zou waarderen.)

Op http://searchwindevelopme...83,sid8_gci841704,00.html vond ik een sp om te decrypten. Niet geprobeerd dus geen idee of het werkt.

[Gino]

xtra schreef op dinsdag 01 juli 2008 @ 22:11:
Op http://searchwindevelopme...83,sid8_gci841704,00.html vond ik een sp om te decrypten. Niet geprobeerd dus geen idee of het werkt.

Was ook al dergelijke scripts tegengekomen. Heb ze zelf ook niet uitgeprobeerd maar het feit dat ze bestaan is tevens nog een extra reden om niet voor optie 3 te gaan.

[ Voor 8% gewijzigd door Gino op 01-07-2008 22:17 ]

[MrBucket]

Gino schreef op dinsdag 01 juli 2008 @ 22:03:
[...]

Dit zou inderdaad een oplossing zijn. Echter zijn er ook klanten die al SQL Servers in eigen beheer hebben waarbinnen onze database/applicatie komt te draaien. Bij deze database servers is het password van sa geheim voor ons en niet voor hun. Tevens kan men dus ook zelf accounts toevoegen aan de serverroles. Is het niet mogelijk om voor 1 bepaalde database alle toegang te ontzeggen buiten voor de door ons zelf aangemaakte users/application role?

Die krijg je dus niet dichtgetimmerd. Een sa is de man op de database.

Tenzij je de database fysiek af kunt schermen van de klant (soort van hosted omgeving bijv - alleen laten ontsluiten via een webservice die wel toegankelijk is voor de klant) heb je er misschien meer aan om het contractueel dicht te timmeren; technisch geef ik je weinig kans.

[Gino]

Is het misschien in een andere soort database server wel mogelijk om de 'root' user toegang te ontzeggen voor 1 specifieke database qua structuur of code?
Ben op dit moment aan het proberen om dit klaar te krijgen in een MySQL database maar dit lijkt ook hier niet direct te gaan lukken...

[MrBucket]

Gino schreef op dinsdag 01 juli 2008 @ 22:59:
Is het misschien in een andere soort database server wel mogelijk om de 'root' user toegang te ontzeggen voor 1 specifieke database qua structuur of code?
Ben op dit moment aan het proberen om dit klaar te krijgen in een MySQL database maar dit lijkt ook hier niet direct te gaan lukken...

Wat staat er dan in hemelsnaam in een database die je wel door een klant op z'n eigen server laat zetten, maar waar hij koste wat kost niets in mag veranderen?

[whoami]

Vraag ik me ook af ....
Ik bedoel: als de klant de database van jouw pakket (bewust) vernaggeld, dan is dat zijn probleem, toch ?

[Gino]

Dat een klant zijn eigen database vernageld heb ik nu niet echt een probleem mee. Het was eerder het probleem dat men vrij code van de stored procedures en dergelijke kan bekijken. We kunnen natuurlijk ook alle (belangrijke) stored procedures gaan omzetten naar CLR wat dan op zich ook weer een heel werk is...

[MrBucket]

Gino schreef op dinsdag 01 juli 2008 @ 23:24:
Dat een klant zijn eigen database vernageld heb ik nu niet echt een probleem mee. Het was eerder het probleem dat men vrij code van de stored procedures en dergelijke kan bekijken. We kunnen natuurlijk ook alle (belangrijke) stored procedures gaan omzetten naar CLR wat dan op zich ook weer een heel werk is...

Intellectueel eigendom moet je volgens mij gewoon afdwingen via de gebruikerslicentie... in ieder geval niet technisch, want dat is bijna onmogelijk om goed te doen. Ik kan me eigenlijk ook niet voorstellen dat er rocket science in die stored procedures staat die zo belangrijk is dat niemand de inhoud mag weten...? Als die klant vervolgens een ander systeem bouwt op basis van jullie database dan is het natuurlijk wat anders, maar nogmaals: dat kun je via de gebruikerslicentie* afdichten...

* Geen idee of dat echt een gebruikerslicentie heet, maar ik bedoel: die gerechtelijk aandoende lap tekst waar een klant mee accoord moet gaan om het product te mogen gebruiken. _{Als zo'n bepaling al niet standaard onder intellectueel eigendom valt.}

[whoami]

Gino schreef op dinsdag 01 juli 2008 @ 23:24:
Dat een klant zijn eigen database vernageld heb ik nu niet echt een probleem mee. Het was eerder het probleem dat men vrij code van de stored procedures en dergelijke kan bekijken. We kunnen natuurlijk ook alle (belangrijke) stored procedures gaan omzetten naar CLR wat dan op zich ook weer een heel werk is...

Tja .... Gebruik je .NET ? Of Java ?
Obfuscate je je code dan ook ? Want, met een tool als reflector bv kan je klant ook je sourcecode gaan bekijken ....

Trouwens, stored procedures omzetten naar CLR SP's of functions is niet altijd een goed idee. Als je veel 'data intensieve' en set bewerkingen hebt, dan gebruik je toch best T-SQL.

[Gino]

Het is niet dat er zoveel speciale code voorkomt in de stored procedures, triggers, ... Maar eerder dat je de source code van je applicaties toch ook niet zomaar op straat gooit zonder er naar om te kijken. Die sources zijn gecompiled en kunnen uiteindelijk ook wel via reverse engineering achterhaald worden. Dit is echter toch net wat lastiger om te bereiken dan gewoon SQL Server Management Studio te installeren en vervolgens een rechtsklik -> modify uit te voeren op een stored procedure naar keuze.
De beste optie op dit moment lijkt dan ook gewoon de stored procedure uit te voeren op de productie database met with encryption. Dan is de code in ieder geval niet direct toegangkelijk.

[whoami]

Gino schreef op dinsdag 01 juli 2008 @ 23:50:
Het is niet dat er zoveel speciale code voorkomt in de stored procedures, triggers, ... Maar eerder dat je de source code van je applicaties toch ook niet zomaar op straat gooit zonder er naar om te kijken. Die sources zijn gecompiled en kunnen uiteindelijk ook wel via reverse engineering achterhaald worden. Dit is echter toch net wat lastiger om te bereiken

Reflector downloaden, assembly openen, view source of dissassemble oid, en there you go ... lastig is het niet ...

dan gewoon SQL Server Management Studio te installeren en vervolgens een rechtsklik -> modify uit te voeren op een stored procedure naar keuze.

Nog eens, als die klant begint te prutsen: zijn probleem.

[RobIII]

Lullige vraag misschien, maar had je dat niet moeten bedenken voordat je voor je gekozen platform koos?

[Gino]

whoami schreef op dinsdag 01 juli 2008 @ 23:44:
[...]

Tja .... Gebruik je .NET ? Of Java ?
Obfuscate je je code dan ook ? Want, met een tool als reflector bv kan je klant ook je sourcecode gaan bekijken ....

We gebruiken C++ en .NET (Voornamelijk voor UI werk). Met een tools als reflector kan je inderdaad de source code gaan bekijken, maar voor bijna elke taal bestaan er wel decompilers en reverse engeneering technieken. De beste beveiligingen worden uiteindelijk ook wel gekraakt. Je moet het alleen niet te gemakkelijk maken.

Trouwens, stored procedures omzetten naar CLR SP's of functions is niet altijd een goed idee. Als je veel 'data intensieve' en set bewerkingen hebt, dan gebruik je toch best T-SQL.

Heb niet al te veel ervaring met CLR SP's, wel als eens gebruikt maar niet echt intensief en al zeker niet voor data intensieve taken. Eerder een validate functie en dergelijke. Tevens is een INSERT procedure nu ook niet de meest gevoelige code.

[Gino]

whoami schreef op dinsdag 01 juli 2008 @ 23:56:
[...]
Reflector downloaden, assembly openen, view source of dissassemble oid, en there you go ... lastig is het niet ...


[...]
Nog eens, als die klant begint te prutsen: zijn probleem.

Als de baas komt vragen of dit mogelijk is moeten we dit natuurlijk even uitzoeken. Veel mogelijkheden blijken er dus niet echt te zijn

[Gino]

RobIII schreef op dinsdag 01 juli 2008 @ 23:57:
Lullige vraag misschien, maar had je dat niet moeten bedenken voordat je voor je gekozen platform koos?

Al onze database toepassingen worden geschreven bovenop SQL Server simpel weg omdat we daarin de meeste ervaring hebben en veel interne tools gebeschikbaar zijn om ons het leven makkelijker te maken . Om nu even alles om te gooien naar een ander database platform is dus niet altijd aan de orde.
Tevens was dit voorheen ook geen probleem omdat het maatwerk applicatie waren of dat de databases niet echt complex zijn.

[whoami]

Vraagje: wat heeft de baas recent horen waaien misschien ?

[Gino]

Geen idee, maar het lijkt me toch een vrij logisch vraag om code zoveel mogelijk af te schermen van de buitenwereld. Ik denk trouwens niet dat we de enige zijn die onze code zoveel mogelijk wil beschermen voor de concurrentie.

[RobIII]

Gino schreef op woensdag 02 juli 2008 @ 00:13:
Geen idee, maar het lijkt me toch een vrij logisch vraag om code zoveel mogelijk af te schermen van de buitenwereld. Ik denk trouwens niet dat we de enige zijn die onze code zoveel mogelijk wil beschermen voor de concurrentie.

Stom idee dan (na een lullige vraag ) : kijk eens bij je concurrentie En while you're at it, babbel eens met je baas vanwaar de plotse interesse hierin

En als je inderdaad zoveel mogelijk af wil schermen, waarom obfuscate je dan niet?

[ Voor 7% gewijzigd door RobIII op 02-07-2008 00:15 ]

[Gino]

Stom idee dan (na een lullige vraag ) : kijk eens bij je concurrentie
...

Doen we ook, maar het moet natuurlijk iets bruikbaar zijn. Als alles onhandig en niet goed werkt heb je hier ook niet veel aan lijkt me

En als je inderdaad zoveel mogelijk af wil schermen, waarom obfuscate je dan niet?

Tot nu toe waren de managed code projecten maatwerken, waardoor dit niet zo'n grote rol speelde. Indien er complexe berekening geschreven worden is dit nog steeds in C++. Dit is toch net wat moeilijker te decompilen tot bruikbare en leesbare code.

[ Voor 41% gewijzigd door Gino op 02-07-2008 00:24 ]