[MSSQL]Alleen toegang door 1 applicatie geven?

[Boss]

Ik ben bezig met een beveiligings project waarbij voorkomen moet worden dat (kwaadwillende) gebuikers een Microsoft SQL Server tabel kunnen leegtrekken.

Normaalgesproken hebben de gebruikers toegang tot de server via een Access ADP project. Dit is redelijk te beveiligen door gebruikers geen toegang te geven tot de tabellen zodat ze alleen data kunnen muteren via de formulieren.
De gebruikers loggen in op de server via Windows Authentication en hoeven dus niet apart in SQL Server in te loggen.

Een slimme gebruiker zou nu echter wel zelf een nieuwe, lege database kunnen maken waarin hij een verbinding legt met de server. Vervolgens kan hij met een paar eenvoudige queries de volledige data lokaal krijgen en/of exporteren naar Excel oid.

Hoe kan ik dat voorkomen?

Ik dacht zelf dat het misschien mogelijk is om het Access programma een application name mee te geven en de server alleen voor die name toegang te geven. Ik kan alleen niet vinden of dit mogelijk is en waar dat in te stellen zou zijn.
Bovendien, de boze gebruiker kan ook zijn eigen database deze name meegeven en zo weer toegang tot de data krijgen.

Kortom: op welke manier kan ik ervoor zorgen dat gebruikers wel gewoon met data kunnen werken (invoeren, wijzigen via formulieren en rapporten maken) zonder dat hij een volledige dump van de data kan maken?

[Gomez12]

Tussenlaag erin plaatsen, hetzij SP's hetzij een andere methode. Zodat niemand direct query's op de db-server kan doen, alleen maar via de tussen laag. En in de tussenlaag zet je alle manieren dat iemand data op mag vragen.

Vb:
Je maakt een SP die altijd 1 result weergeeft, omdat dit nodig is in je app. Dan kan niemand je volledige tabel in 1 keer leegroven, omdat hier gewoon geen query voor uitgevoerd kan worden ( het is nog wel mogelijk door in vba de query 65.532 x uit te voeren en dit te plakken in excell, maar als dat niet opvalt.... )

[raptorix]

Een tussenlaag en gebruik van Stored Procedures is inderaad het handigst, eventueel zou ik ook logging toepassen door bijvoorbeeld in de database bij te houden wie welke acties heeft uitgevoerd, eventueel kan je op deze logging table weer een trigger zetten die checkt of iemand niet automatisch je hele database aan het leegslurpen is.

[Boss]

Het gebruik van SP's zat ik ook al aan te denken, en is op zich ook wel redelijk goed te implementeren.

Net nog een ander idee: Op zich is een Access ADP redelijk af te schermen zodat gebruikers alleen in formulieren en rapporten kunnen komen (niet in tabellen / queries).

Vervolgens voor iedere gebruiker een nieuwe login maken waarbij het wachtwoord voor de helft door de database gegenereerd wordt en voor de andere helft door de gebruiker wordt gekozen.
Een kluis met twee sleutels, zeg maar.

Het nadeel van het werken met triggers is dat het in een redelijk aantal gevallen wel wenselijk is dat de gebruiker toegang heeft tot alle data, bijvoorbeeld bij het uitvoeren van een zoekopdracht...

Bedankt voor de input alvast. Ik ga ermee verder. Als iemand nog meer geniale invallen heeft dan hoor ik het graag!

[Verwijderd]

raptorix, een trigger is helaas alleen mogelijk op insert, update en delete queries, niet op select queries, dus die vlieger gaat niet op...

Ik zou inderdaad een tussenlaag maken die de boel kan loggen en eventueel afschermen.
Een andere optie is om MSSQL niet gebruik te laten maken van Windows Authentication, maar van z'n eigen authentication. In je Access applicatie kun je die authentication dan meegeven in de connection string, en die kun je zo cryptisch maken als je zelf wilt. Niet waterdicht, maar wel weer een extra drempel.

Maarre... Die mogelijke 'boosdoener' heeft al een Windows Authentication, dus die mag op het netwerk van dat bedrijf / die organisatie. Als je dan als bedrijf dicht wilt timmeren dat data niet geexporteerd worden heb je toch een heel ander probleem?
Gewoon een bedrijfs-policy maken dat 't niet mag, op straffe van schorsing of ontslag, punt.

[whoami]

Eén woord: application roles.

[raptorix]

Verwijderd schreef op vrijdag 15 april 2005 @ 17:54:
raptorix, een trigger is helaas alleen mogelijk op insert, update en delete queries, niet op select queries, dus die vlieger gaat niet op...

Ik zou inderdaad een tussenlaag maken die de boel kan loggen en eventueel afschermen.
Een andere optie is om MSSQL niet gebruik te laten maken van Windows Authentication, maar van z'n eigen authentication. In je Access applicatie kun je die authentication dan meegeven in de connection string, en die kun je zo cryptisch maken als je zelf wilt. Niet waterdicht, maar wel weer een extra drempel.

Maarre... Die mogelijke 'boosdoener' heeft al een Windows Authentication, dus die mag op het netwerk van dat bedrijf / die organisatie. Als je dan als bedrijf dicht wilt timmeren dat data niet geexporteerd worden heb je toch een heel ander probleem?
Gewoon een bedrijfs-policy maken dat 't niet mag, op straffe van schorsing of ontslag, punt.

Dat weet ik, daarom zei ik ook dat je moet loggen naar een andere tabel, dan kan je daar wel een trigger opzetten. Overigens kwam ik er tijdje terug achter dat de system tables wel spreken over een select trigger . Mogelijk is dat voor toekomstig gebruik.

[Verwijderd]

whoami schreef op vrijdag 15 april 2005 @ 18:17:
Eén woord: application roles.

Helemaal mee eens. Geen users rechten geven, maar gewoon een application role maken. Kijk in je Books Online voor een howto:

Voorbeeld:

HTML:

As an example of application role usage, a user Sue runs a sales application that requires SELECT, UPDATE, and INSERT permissions on the Products and Orders tables in database Sales to work, but she should not have any SELECT, INSERT, or UPDATE permissions when accessing the Products or Orders tables using SQL Query Analyzer or any other tool. To ensure this, create one user-database role that denies SELECT, INSERT, or UPDATE permissions on the Products and Orders tables, and add Sue as a member of that database role. Then create an application role in the Sales database with SELECT, INSERT, and UPDATE permissions on the Products and Orders tables. When the application runs, it provides the password to activate the application role by using sp_setapprole, and gains the permissions to access the Products and Orders tables. If Sue tries to log in to an instance of SQL Server using any tool except the application, she will not be able to access the Products or Orders tables.

[Gé Brander]

whoami schreef op vrijdag 15 april 2005 @ 18:17:
Eén woord: application roles.

offtopic:
= twee woorden...

Maar je hebt helemaal gelijk. Het zou goed zijn om als ontwikkelaar de databasemogelijkheden te kennen...

[Boss]

c70070540 schreef op vrijdag 15 april 2005 @ 20:05:
[...]

offtopic:
= twee woorden...

Maar je hebt helemaal gelijk. Het zou goed zijn om als ontwikkelaar de databasemogelijkheden te kennen...

En nog beter is het als je over dingen die niet je specialisme zijn zo af en toe eens een vraag kan stellen op Tweakers.

Ik ga ermee aan de slag, bedankt voor de tip!

[Gé Brander]

Touché!