Berechtigungen auf dem SQL Server

Question

Hallo zusammen,

ich weiß nicht weiter und hoffe ihr könnt mir helfen.

Wir haben einen SQL Server 2012 Standard mit Windows Authentifizierung. Dort sind mehrere Datenbanken für verschiedene Bereiche angelegt (z.B. Technik, Personal, Vertrieb). Wir haben jetzt eine Anwendung im Personalbereich mit VB, die auf die Datenbank im Personal zugreift, speichert, löscht usw.(über Linq). Jeder MA kann über die VB Anwendung NUR seine Daten lesen. Wir haben eine AD Gruppe "Alle", die ist jetzt als Anmeldung hinterlegt und der Datenbank zugeordnet (Datareader + Datawriter). Funktioniert auch alles.

Jetzt zum Problem: Sollte sich eine MA, warum auch immer, das Managementstudio runterladen, so kann er sich mit dem Server verbinden (wegen Windows Authent..) und hat Zugriff auf die DB (weil ja die Anmeldung "Alle" die DB Personal zugeordnet ist) und kann auch die Tabellen lesen und schreiben (durch Datareader + Datawriter). Der Zugriff auf die DB über das Managementstudio soll aber NICHT erlaubt werden.

Wo kann ich das denn einstellen, oder muß ich meine Denk + Arbeitsweise ändern?

Vielen Dank schonmal

Gruß Daniel

Answer 1

Hallo Daniel,

das Thema hatten wir schon mal in diesem Thread Logon Trigger wg. SSMS Zugriff? und es gibt keine reale Chance den Zugriff abhängig vom verwendetem Programm einzuschränken. Das müssen die Berechtigungsstrukturen geändert werden, z.B. das die Applikation eine Application Roles verwendet.

---

Olaf Helper

[ Blog] [ Xing] [ MVP]

Answer 2

Hallo Daniel,

das Problem betrifft nicht nur das Management Studio, sondern sämtliche anderen Zugangswege, bspw. Skript, ODBC Verbindungen, die man sich selbst erstellt, usw.

Daher ist es unumgänglich, eurer Gruppe "Alle" entweder wieder die Lese- und Schreibrechte zu entziehen oder der Gruppe keinen Zugriff auf den Datenbankserver zu gewähren.

Mir ist auch schleierhaft, warum man das so macht? Ihr habt doch einzelne Benutzer, fasst die in Benutzergruppen zusammen, die dann die benötigten Berechtigungen erhalten.

---

Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

Answer 3

Am 15.01.2015 schrieb DanWe1:

Jetzt zum Problem: Sollte sich eine MA, warum auch immer, das Managementstudio runterladen, so kann er sich mit dem Server verbinden (wegen Windows Authent..) 
und hat Zugriff auf die DB (weil ja die Anmeldung "Alle" die DB Personal zugeordnet ist) und kann auch die Tabellen lesen und schreiben (durch Datareader + Datawriter). Der Zugriff auf die DB über das Managementstudio soll aber NICHT erlaubt werden.

Nimm dem Benutzer die Adminrechte, dann kann er sich das Studio schon
gar nicht installieren. Ohne Adminrechte ist eure Windows Domain auch
um Welten sicherer.

---

Servus
Winfried

Gruppenrichtlinien
HowTos zum WSUS Package Publisher
WSUS Package Publisher
HowTos zum Local Update Publisher
NNTP-Bridge für MS-Foren

Answer 4

Am 15.01.2015 schrieb DanWe1:

Jetzt zum Problem: Sollte sich eine MA, warum auch immer, das Managementstudio runterladen, so kann er sich mit dem Server verbinden (wegen Windows Authent..) 
und hat Zugriff auf die DB (weil ja die Anmeldung "Alle" die DB Personal zugeordnet ist) und kann auch die Tabellen lesen und schreiben (durch Datareader + Datawriter). Der Zugriff auf die DB über das Managementstudio soll aber NICHT erlaubt werden.

Nimm dem Benutzer die Adminrechte, dann kann er sich das Studio schon
gar nicht installieren. Ohne Adminrechte ist eure Windows Domain auch
um Welten sicherer.

Entschuldige, aber das ist <del>bestenfalls inkorrekt und schlimmstenfalls</del> eine gefährliche da trügerische Sicherheit:

Wie hier im Thread bereits angedeutet kann man auch andere Programme als das SSMS für Ad-Hoc Zugriffe misbrauchen. Excel reicht völlig.

Das man Admin-Rechte nicht unnötig vergeben sollte, ist davon unabhängig aber natürlich richtig.

---

Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

Answer 5

Am 15.01.2015 schrieb Andreas.Wolter [MVP]:

Am 15.01.2015 schrieb DanWe1:

Jetzt zum Problem: Sollte sich eine MA, warum auch immer, das Managementstudio runterladen, so kann er sich mit dem Server verbinden (wegen Windows Authent..) 
und hat Zugriff auf die DB (weil ja die Anmeldung "Alle" die DB Personal zugeordnet ist) und kann auch die Tabellen lesen und schreiben (durch Datareader + Datawriter). Der Zugriff auf die DB über das Managementstudio soll aber NICHT erlaubt werden.

Nimm dem Benutzer die Adminrechte, dann kann er sich das Studio schon
gar nicht installieren. Ohne Adminrechte ist eure Windows Domain auch
um Welten sicherer.

Entschuldige, aber das ist bestenfalls inkorrekt und schlimmstenfalls eine gefährliche da trügerische Sicherheit:

Was ist daran inkorrekt?

Wie hier im Thread bereits angedeutet kann man auch andere Programme als das SSMS für Ad-Hoc Zugriffe misbrauchen. Excel reicht völlig.

Ja.

Das man Admin-Rechte nicht unnötig vergeben sollte, ist davon unabhängig aber natürlich richtig.

Also doch richtig. Ein Anwender hat keine Adminrechte zu haben. Punkt.

---

Servus
Winfried

Gruppenrichtlinien
HowTos zum WSUS Package Publisher
WSUS Package Publisher
HowTos zum Local Update Publisher
NNTP-Bridge für MS-Foren

Answer 6

Am 15.01.2015 schrieb Andreas.Wolter [MVP]:

Am 15.01.2015 schrieb DanWe1:

Jetzt zum Problem: Sollte sich eine MA, warum auch immer, das Managementstudio runterladen, so kann er sich mit dem Server verbinden (wegen Windows Authent..) 
und hat Zugriff auf die DB (weil ja die Anmeldung "Alle" die DB Personal zugeordnet ist) und kann auch die Tabellen lesen und schreiben (durch Datareader + Datawriter). Der Zugriff auf die DB über das Managementstudio soll aber NICHT erlaubt werden.

Nimm dem Benutzer die Adminrechte, dann kann er sich das Studio schon
gar nicht installieren. Ohne Adminrechte ist eure Windows Domain auch
um Welten sicherer.

Entschuldige, aber das ist bestenfalls inkorrekt und schlimmstenfalls eine gefährliche da trügerische Sicherheit:

Was ist daran inkorrekt?

Wie hier im Thread bereits angedeutet kann man auch andere Programme als das SSMS für Ad-Hoc Zugriffe misbrauchen. Excel reicht völlig.

Ja.

Das man Admin-Rechte nicht unnötig vergeben sollte, ist davon unabhängig aber natürlich richtig.

Also doch richtig. Ein Anwender hat keine Adminrechte zu haben. Punkt.

Nach nochmaligem Lesen muss ich eingestehen, dass ich hier einen Fehler gemacht habe. So, wie es da steht, ist es nicht falsch. In anderen Worten, es stimmt. :- ) - ich versuche das oben noch zu editieren, dass später keiner drüber stolpert.

Der Aspekt, der hieran jedoch durchaus irreführend ist, ist, dass hier Admin-Rechte auf Windows-Ebene in den Vordergrund gestellt werden. Nimmt man allein die oben gegebene Antwort als Grundlage, könnte man versucht sein, das Sicherheitsleck zu schließen, indem man das Management Studio auf Anwender-Rechnern verbietet/verhindert, und Windows-Admin-Rechte entzieht.

Das ist jedoch gar nicht der Grund für das Sicherheitsproblem. 

"Am Thema vorbei" wäre alsso die korrekte Einordnung, wenn man so will ;-)

Deshalb "gefährliche, da trügerische Sicherheit"

Wie Stefan schrieb, kann man über diverse Programme an die Daten heran un diese Ändern. Entscheidend sind also die korrekt gesetzten Rechte. Sprich nur was nötig ist und nicht mehr. Keine Admin-Rechte auf Windows ist nur Teil dessen.

Andersrum gesagt würden lokale Administratorenrechte auf den Client-PCs die Sicherheit in Sachen SQL Server (nur dessen!) nicht beeinflussen - wenn man ansonsten alles richtig gemacht hat.

---

Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com