Was sind angemessene Berechtigungen, um typischen Benutzern zu gewähren? [geschlossen]

Ich finde die Liste der von MySQL bereitgestellten Berechtigungen etwas überwältigend. Ich bin mir nicht sicher, wer welche Privilegien haben soll. In meinen Augen gibt es drei typische Benutzer für meine Situation:

1. root
2. developer
3. application

rootist selbsterklärend. Damit developerdieser Benutzer problemlos auf jede Datenbank zugreifen, Anpassungen vornehmen usw. kann Für den Anfang setze ich diesen Benutzer auf diesen Berechtigungssatz:

SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON

applicationhat einen noch begrenzteren Satz. Es sollte sich nur auf die Manipulation einer bestimmten Datenbank beschränken.

Ich bin mir nicht sicher, welche angemessenen Berechtigungen gewährt werden sollen. Was sind angemessene Berechtigungen, um einem Entwickler und einer Anwendung zu gewähren, und warum?

Ein typischer Benutzer sollte haben:

SELECT, INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES, EXECUTE

Die ersten vier sind ziemlich offensichtlich - obwohl Sie auch "Nur-Lese" -Benutzer mit nur einrichten können SELECT.

CREATE TEMPORARYist auch praktisch und normalerweise harmlos: Temporäre Tabellen können bei der Optimierung von Abfragen helfen und diese in kleinere und schnellere Teile aufteilen. Sie sind auf die ausführende Verbindung beschränkt und werden beim Schließen automatisch gelöscht.

EXECUTEhängt von Ihrem Systemtyp ab. Haben Sie Routinen gespeichert? Möchten Sie, dass Ihre Benutzer darauf zugreifen? Stellen Sie sicher, dass Sie auch die SECURITY=DEFINER/INVOKERDefinition für gespeicherte Routinen kennen.

Stellen Sie in jedem Fall sicher, dass Sie alle oben genannten Punkte auf bestimmte Schemas anwenden . Vermeiden Sie :

GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'some_user'@'some_host';

Wie oben beschrieben, werden auch Berechtigungen für die mysqlSystemtabellen gewährt , sodass jeder Benutzer effektiv neue Konten erstellen oder seine eigenen Berechtigungen aktualisieren kann. Tun Sie stattdessen:

GRANT SELECT, INSERT, UPDATE, DELETE ON some_schema.* TO 'some_user'@'some_host';
GRANT SELECT, INSERT, UPDATE, DELETE ON another_schema.* TO 'some_user'@'some_host';

In jedem realen System (dh nicht in einem persönlichen Projekt) variieren diese Benutzertypen je nach Umgebung, sodass es nicht ganz so einfach ist.

In allen Umgebungen sollte die Anwendung das haben, was sie benötigt, und nicht mehr (im Allgemeinen ist dies "Auswählen / Einfügen / Aktualisieren für alle Tabellen" und "Ausführen für alle Prozeduren". Für größere Systeme, in denen Sie möglicherweise separate Anwendungsbenutzer für verschiedene Aufgaben haben (z Wenn beispielsweise eine Anwendung für die Eingabe von Zensordaten und eine andere für die Erstellung von Berichten verantwortlich ist, sollten Sie ihre Berechtigungen trennen, damit sie die geringsten erforderlichen Rechte haben (der berichtende Benutzer benötigt wahrscheinlich keine Schreibrechte und Schreibrechte). Stellen Sie sicher, dass Sie dies in Ihrem Test replizieren Umgebungen, wenn Sie sie haben: Ich habe gesehen, dass Code beim Heraufstufen zu Live, das im Test funktioniert hat, umgefallen ist, weil alles in der Testumgebung auf die saDatenbank zugegriffen hat als (MSSQL entspricht root).Im Idealfall sollte ein Anwendungsbenutzer im Allgemeinen keine Berechtigungen haben, mit denen er Ihr Schema ändern kann (CREATE,, DROP...) - es gibt Ausnahmen, aber es gibt nur wenige.

rootist gut root. In der Produktion ist dies nur Ihr DBA und sollte nur selten verwendet werden - nur für die Systemwartung (Upgrades des DB-Designs usw.) und die Überwachung. Bei einem großen System, insbesondere in regulierten Umgebungen, in denen Sie aus Gründen der Rechenschaftspflicht die Kontrolle über Einzelpersonen behalten müssen, dürfen Sie möglicherweise keinen einzelnen rootBenutzer zulassen und versuchen, die Berechtigungen in kleinere Rollen aufzuteilen (ich bin mir nicht sicher, wie weit Sie gehen können mit diesem in MySQL, aber Sie können in MSSQL, Oracle und so weiter ziemlich feinkörnig sein).

Für Entwicklerbenutzer: Sie sollten überhaupt keinen Zugriff auf Ihre Live-Umgebungen haben. Dies ist einer der Gründe, warum Anwendungsbenutzer kein Schema haben sollten, das sich auf Rechte auswirkt: Jemand mit Zugriff auf ein Entwicklerkonto könnte möglicherweise seine Sperrung auf diese Weise umgehen. Auch in Testumgebungen haben sie normalerweise keinen Zugriff: Sie senden Patches an die Qualitätssicherung, und der DBA (wahrscheinlich unter Verwendung eines rootBenutzers) für die Qualitätssicherung wendet die Aktualisierungen auf die Testumgebung an (tatsächlich wird dies in großen Organisationen häufig automatisiert, so der QA-DBA ist eigentlich eine Reihe von Skripten, die die Neuerstellung der Testumgebung für jeden Zyklus steuern. In Entwicklungsumgebungen, insbesondere wenn die Entwickler ihre eigenen lokalen Kopien des laufenden Dienstes haben, sollten diese Benutzer natürlich vollen Zugriff auf alles haben, um experimentieren zu können.

Das Obige sind jedoch alle allgemeinen Hinweise: Um spezifische Empfehlungen abzugeben, müssten wir viel mehr über Ihre Anwendung (en) und die Umgebungen wissen, in denen sie betrieben werden. Die Zielumgebung ist manchmal wichtiger als Sie vielleicht denken: Abhängig von Ihrer Geschäftsumgebung Die Rechte Ihrer Benutzer können sogar recht direkt durch gesetzliche Bestimmungen diktiert werden, selbst in der Entwicklung, wenn Ihre Kunden Ihnen jemals zu Diagnosezwecken Zugriff auf echte Daten gewähren.