nicht angemeldet
Hi Tom,
an MS SQL 2000/2005 kannst du dich entweder über Windows-Integrierte (1) Authentifizierung oder SQL Authenti... (2) anmelden. (1) funktioniert quasi unsichtbar, bei (2) musst du User und Passwort angeben. Der SQL Server Client (z.b. der SNAC = Sql Server Native Client vom 2005) stellt dafür dann standardmässig eine Eingabemaske bereit (die, die du auch im Management Studio siehst).
Wenn du dich jetzt via (1) anmeldest, bist du z.b. mit deinem Domain- oder Gruppen-Account beim Windows selbst authentifiziert und hast die dir zugewiesenen Domain- und lokalen Rollen (zb Domain\Users und Server\Administrators). Im Management Studio unter dem Ordner Security -> Logins bei einer Serverinstanz kannst du einstellen welche Windows-Gruppen, Windows-User und SQL User grundsätzlich Zugriff haben sollen. In den Eigenschaften jedes Logins kannst du dann
a) Server-Rollen vergeben (z.b. SYSADMIN) oder
b) Datenbankzugriffe einstellen (auf Datenbank "X" als User "TolleWurst" mit den Rollen "SuperduperUser" und "StandardUser")
Letztere Rollen sind Datenbank-spezifisch und können mit Lokalen Gruppen auf Windows-Rechnern verglichen werden, welchen man gesammelt bestimmte Privilegien einräumen kann.
Jedes SQL Server Login hat per default die Rolle "public", sowohl auf dem Server als auch in der Datenbank.
Best Practice(s):
- nutze Windows-Integrated Authentication
- nutze Windows/AD Gruppen (= gewähre diesen das Login-Recht)
- weise den Gruppen oder Einzelnutzern (wenn nötig) die Serverrollen zu (wenn nötig)
- erzeuge Datenbankrollen in den Benutzerdatenbanken
- verwalte die Rechte in den Datenbanken gegen diese Datenbankrollen (GRANT SELECT ON TABLE TO #MyROLE#) usw
- weise den SQL Server Logins die benötigten Datenbankrollen (können auch mehrere sein) zu
Das sollte mal deine Frage 1) etwas klären.
zu 2) das kommt ganz drauf an wie du die Kontrolle aus einer Anwendung gestalten willst ... das mit dem Masteruser, der praktisch alles darf ist dann natürlich ein potentielles Sicherheitsleck, da entweder jeder Benutzer dieses Windows-Account impersonifizieren dürfte und/oder du für das SQL Login den Usernamen und das Passwort bei der Client Anwendung hinterlegen müsstest. Etwas weniger gefährlich ist es bei Datenbanken, in welchen sowieso nur gelesen wird.
Wenn du dich rein auf die SQL Server Rechte verlässt, dann solltest du in der Anwendung ein solides Errorhandling für die Sicherheitsfehler einbauen, die ggf beim Versuch unerlaubte Funktionen zu benutzen geworfen werden, einbauen.
Du kannst aber z.b. (für alle lesbar) Daten aus der DB ziehen um Funktionen (buttons und so) in der Anwendung zu deaktivieren.
Gruss, Frank