Minimale Benutzerrechte SQL User für täglichen operativen Betrieb

biglittelthings

Aktives Mitglied
28. April 2021
5
1
Über welche minimalen Benutzerrechte muss ein SQL User verfügen, um die Kernfunktionen (Artikelverwaltung, Beschaffungswesen, Kundenverwaltung, Rechnungsverwaltung, Versandverwaltung, Retourenverwaltung) der JTL WAWI 1.9.x im täglichen operativen Betrieb bereitzustellen?

Der Artikel beschreibt sehr weitreichende Rechte als Standardsetting: https://guide.jtl-software.com/jtl-wawi/datenbank/einstellungen-fuer-datenbank-benutzer/
Ist hier ein sparsameres Rechtesetup möglich?
 

mh1

Sehr aktives Mitglied
4. Oktober 2020
1.393
391
Der Artikel beschreibt sehr weitreichende Rechte als Standardsetting: https://guide.jtl-software.com/jtl-wawi/datenbank/einstellungen-fuer-datenbank-benutzer/
Ist hier ein sparsameres Rechtesetup möglich?
Welche Rechte sind dir denn hier zu weitreichend? Habt ihr bestimmte firmeninterne Regelungen, was erlaubt ist und was nicht?

Falls man mit dem jeweiligen Login, die JTL-.Datenbankverwaltung benutzt um hier z.b. bei der Erstinsttallation die eazybusiness erstellen zu lassen, oder wenn man neue Mandante anlegen will, muss dieses Login der Serverrolle dbcreator angehören.

Masseneinfügungen mit BULK INSERT habe ich noch an keiner Stelle in der Wawi gesehen. Unser Login hier ist nicht in der bulkadmin Rolle und wir hatten noch keine Probleme damit.

Mitglieder von processadmin Rolle können Verbindungen zum SQL Server ändern.

Grundsätzlich kannst du ja, da du nach dem sparsamsten Rechtesetup suchst, erstmal nur public drin lassen. Und kucken, ob die Wawi läuft ...und falls nicht nimmst du eben ein weiteres Recht dazu und probierst wieder u.s.w.

Ich persönlich würde das Login aber so einstellen, wie es JTL dokumentiert hat. Sonst stehst du ja bei jedem Fehler vor der Frage, obs jetzt an fehlenden Rechten des Logins liegt, oder an falschen Einstellungen in der Wawi oder oder....
 

biglittelthings

Aktives Mitglied
28. April 2021
5
1
Welche Rechte sind dir denn hier zu weitreichend? Habt ihr bestimmte firmeninterne Regelungen, was erlaubt ist und was nicht?

Falls man mit dem jeweiligen Login, die JTL-.Datenbankverwaltung benutzt um hier z.b. bei der Erstinsttallation die eazybusiness erstellen zu lassen, oder wenn man neue Mandante anlegen will, muss dieses Login der Serverrolle dbcreator angehören.

Masseneinfügungen mit BULK INSERT habe ich noch an keiner Stelle in der Wawi gesehen. Unser Login hier ist nicht in der bulkadmin Rolle und wir hatten noch keine Probleme damit.

Mitglieder von processadmin Rolle können Verbindungen zum SQL Server ändern.

Grundsätzlich kannst du ja, da du nach dem sparsamsten Rechtesetup suchst, erstmal nur public drin lassen. Und kucken, ob die Wawi läuft ...und falls nicht nimmst du eben ein weiteres Recht dazu und probierst wieder u.s.w.

Ich persönlich würde das Login aber so einstellen, wie es JTL dokumentiert hat. Sonst stehst du ja bei jedem Fehler vor der Frage, obs jetzt an fehlenden Rechten des Logins liegt, oder an falschen Einstellungen in der Wawi oder oder....
Danke für deine Antwort und dass du deine Erfahrungen schilderst, das ist sehr wertvoll.

Es geht in diesem spezifischen Fall um die Nutzung der beschriebenen Funktion der JTL WAWI V 1.9.x im täglichen Betrieb. Funktionen wie Erstinstallation, Updates etc. sind nicht relevant. Firmeninterne Regeln spielen für die Betrachtung keine Rolle. Ich interessiere mich für das Minimalrechtesetup das JTL für dieses Szenario empfiehlt. Vielleicht liest hier jemand vom Team mit und kann dazu noch etwas beitragen.
 

wawi-dl

Sehr aktives Mitglied
29. April 2008
6.036
601
Über welche minimalen Benutzerrechte muss ein SQL User verfügen, um die Kernfunktionen (Artikelverwaltung, Beschaffungswesen, Kundenverwaltung, Rechnungsverwaltung, Versandverwaltung, Retourenverwaltung) der JTL WAWI 1.9.x im täglichen operativen Betrieb bereitzustellen?

Der Artikel beschreibt sehr weitreichende Rechte als Standardsetting: https://guide.jtl-software.com/jtl-wawi/datenbank/einstellungen-fuer-datenbank-benutzer/
Ist hier ein sparsameres Rechtesetup möglich?
Dürfte ich fragen wofür man das braucht?

Die JTL Wawi wird ja mit einem zentralen SQL Benutzer betrieben, die Benutzer die man in JTL Wawi anlegt sind keinen wirklichen SQL Benutzer.
 

Verkäuferlein

Sehr aktives Mitglied
29. April 2012
2.393
861
Dürfte ich fragen wofür man das braucht?

Die JTL Wawi wird ja mit einem zentralen SQL Benutzer betrieben, die Benutzer die man in JTL Wawi anlegt sind keinen wirklichen SQL Benutzer.

Na ja, das Konzept ist halt nicht so ganz mit aktuellen Sicherheitskonzepten kompatibel.

Wobei mir faktisch jetzt kein (großer) Nachteil einfällt, wenn man einen DB-Nutzer mit nicht zu vielen Rechten verwendet.

Du kannst halt im Falle eines Falles nicht erkennen, von welchem Rechner/System die DB-Zugangsdaten geklaut wurden und nicht einzelne Rechner aus dem DB-Zugang aussperren und musst im Zweifelsfall auf allen Rechnern die DB-Zugangsdaten ändern, wenn sie eigentlich nur für einen Nutzer/Rechner geändert werden müssten.

Bei vielen läuft aber vermutlich das Standard-Setup mit sa und Standard-PW, zumindest das sollte man eigentlich ändern.
 
  • Gefällt mir
Reaktionen: wawi-dl

JohnFrea

Sehr aktives Mitglied
21. September 2017
748
228
Welche Rechte entziehen bringt denn welchen Vorteil genau?
Schreibrecht braucht man auf alle Tabellen sowieso.
Damit ist doch das maximale Schadpotiental gesetzt: Alle Tabelle leeren.
 

wawi-dl

Sehr aktives Mitglied
29. April 2008
6.036
601
Richtig, auf das wollte ich hinaus, macht für mich derzeit leider keinen Sinn, die Frage ist aber klar berechtigt.
 

mh1

Sehr aktives Mitglied
4. Oktober 2020
1.393
391
Dürfte ich fragen wofür man das braucht?
Denkbar sind verschiedene Konstellationen/Vorgaben, die in jedem Unternehmen anders aussehen können.

Zum Beispiel, wenn die IT-Abteilung einfach nicht will, dass die Wawi mit sa Berechtigung auf dem SQL-Server arbeitet.
Wenn man verschiedene Datenbanken auf dem SQL-Server liegen hat (z.b. Fibu oder Konstruktionsdaten oder so) ist es eher unüblich, dass einer DB-Anwendung (z.b. der Fibu) dann Zugriff auf den kompletten Server inkl. ALLER Einstellungen und Zugriffe auf ALLE Datenbanken erteilt wird.

Wahrscheinlich haben aber die meisten JTL Anwender ausschließlich für JTL einen SQL-Server und also eh nur die eazybusiness auf dem SQL-Server. Damit wäre das Argument des Zugriffs auf nur eine DB vs. alle DB's hinfällig.

Alles in allem ist das eine firmeninterne Entscheidung, ähnlich der ob man mit Administratorrechten in Windows arbeitet (bzw. arbeiten will). Und ja ich kenne Firmen in denen das gelebte Praxis ist (weils "ja einfacher ist")

Oder ein anderes Beispiel: man richtet der Agentur, die irgendwelche Datenpflege macht ein eigenes Login auf dem SQL-Server ein. Wenn der Vertrag mit der Agentur endet, kann man einfach den Login löschen.

Wenn man ein Shared Hosting bucht, gibt dir Ecomdata mit Sicherheit auch keinen sa Zugang auf den Server auf dem neben dir noch 50 andere Hostings liegen (war bei uns auf jedenfall nicht so, als wir noch bei Ecomdata waren)

Oder wenn man - wieder angenommen, dass der SQL-Server noch andere Aufgaben hat - aussagekräftige Logfiles braucht (z.b. Suche nach "Flaschenhals"). Dann bringt es einem uU. nichts wenn man zig aktive Verbindungen vom sa im Log hat. Wenn man aber sehen würde, dass die zwölf Wawi User unproblematisch sind, aber die drei Fibu User immer Probleme machen, dann hätte man schon viel erreicht...
 
Zuletzt bearbeitet:

Verkäuferlein

Sehr aktives Mitglied
29. April 2012
2.393
861
Welche Rechte entziehen bringt denn welchen Vorteil genau?
Schreibrecht braucht man auf alle Tabellen sowieso.
Damit ist doch das maximale Schadpotiental gesetzt: Alle Tabelle leeren.
Richtig, auf das wollte ich hinaus, macht für mich derzeit leider keinen Sinn, die Frage ist aber klar berechtigt.

Das ist vor Jahren schon einmal in einem anderen Thread auch detailliert ausdiskutiert worden und grundsätzlich hat @mh1 das ja schon beschrieben, jeder der in die Datenbank schreiben kann, kann sie auch kaputtschreiben, dennoch sollte er nicht unnötigerweise noch zusätzliche Rechte und Möglichkeiten erhalten. Wir sind ja im Zeitalter von "Zero Trust".

Nur gibt es ja verschiedene Szenarien und gerade bei automatisierten Angriffen wird ja in der Regel mal über "sa" probiert Zugang zu bekommen, deshalb ist es schon einmal eine gute Idee, über einen anderen DB-Nutzer die Verbindung herzustellen und "sa" bestenfalls administrativ (bei Ersteinrichtung) zu verwenden.

Ansonsten sollte man natürlich auch das Standardpasswort ändern.

Und dann gibt es natürlich noch das Szenario, Laptop wird irgendwo vergessen oder geklaut (natürlich ist die Festplatte verschlüsselt und alles bestens abgesichert), trotzdem ist es dann schöner, den DB-Nutzer (neben sonstigen Zugängen) einfach zu sperren und für das Ersatzlaptop einen neuen DB-Zugang anzulegen, als auf allen Rechnern im Netzwerk die DB-Zugangsdaten zu ändern.
 

John

Sehr aktives Mitglied
3. März 2012
2.879
584
Berlin
Da gibts doch einen Artikel im Guide zu, wie man einen weiteren DB Nutzer anlegt und welche Rechte er braucht.
 
Ähnliche Themen
Titel Forum Antworten Datum
Neu SQL: img alt Tags setzen User helfen Usern - Fragen zu JTL-Wawi 2
[Bug] JTL-Wawi 1.9 | Auftrag: Statustext in Workflow Variablen leer | gelöst: [SQL] JTL-Wawi 1.9 0
Auftrag: Eigene Felder in DotLiquid Vorlage verwenden [Wawi 1.9.4.5] [SQL] JTL-Wawi 1.9 0
Neu Partner für JTL Shop WAWI und MS SQL Server gesucht Dienstleistung, Jobs und Ähnliches 2
Neu Fehler bei SQL-Abfrage durch Aufgabenplanung Gelöste Themen in diesem Bereich 12
Neu SQL Server 2022 Standart auf M.2 NVMe SSD Installation von JTL-Wawi 36
Neu Fehlermeldung "Es wurde im SQL-Server kein Backuppfad hinterlegt" => kein Schemaupdate möglich JTL-Wawi - Fehler und Bugs 8
Neu Nach Update auf SQL 2022 Express keine verbindung mehr mit Client möglich Installation von JTL-Wawi 2
Neu Tabelle aus eigenem SQL in Druckvorlage möglich? Gelöste Themen in diesem Bereich 3
Neu Merkmal eindeutig per SQL zuordnen Druck-/ E-Mail-/ Exportvorlagen in JTL-Wawi 0
Neu Update SQL 2017 Express auf 2022 Standard Installation von JTL-Wawi 7
In Diskussion SQL Update aus Workflow heraus JTL-Workflows - Fehler und Bugs 8
Neu Gewogenes Versandgewicht per SQL exportieren und anschließend in Artikelstammdaten importieren JTL Ameise - Eigene Exporte 0
Neu Gewogenes Versandgewicht per SQL exportieren und anschließend in Artikelstammdaten importieren Gelöste Themen in diesem Bereich 5
Neu Bestandsführung per SQL deaktivieren User helfen Usern - Fragen zu JTL-Wawi 3
Neu Installation von JTL-WaWi auf SQL DB mit AD Account möglich? Installation von JTL-Wawi 7
Neu SQL Fehler - Woher stammt diese Abfrage JTL-Shop - Fehler und Bugs 7
Neu SQL Abfrage User helfen Usern - Fragen zu JTL-Wawi 3
Neu Plattform Feld per SQL setzen - mehrere Marken unter einer Firma verkaufen User helfen Usern - Fragen zu JTL-Wawi 6
Neu Workflow - SQL - Frage zur DATEADD()-Funktion User helfen Usern - Fragen zu JTL-Wawi 2
Neu Korrektes Datumsformat in SQL-Abfrage User helfen Usern - Fragen zu JTL-Wawi 2
Neu Probleme beim Abfrage kopieren von SQL Management Studio User helfen Usern - Fragen zu JTL-Wawi 1
Neu Wie kann man Anzahl der VPE per SQL abfragen? User helfen Usern - Fragen zu JTL-Wawi 1
Neu Kundendatenimport via SQL JTL-Wawi 1.6 1
SQL Abfrage für verkaufte Artikel + aktueller Bestand JTL-Wawi 1.8 1
Neu SQL Ausgabe Bestellinformationen JTL Ameise - Eigene Exporte 4
Neu SQL Script - geänderte Tabellen. User helfen Usern - Fragen zu JTL-Wawi 3

Ähnliche Themen