Quels sont les privilèges raisonnables à accorder aux utilisateurs typiques? [fermé]

Je trouve que la liste des privilèges fournis par MySQL est un peu écrasante. Je ne sais pas qui devrait avoir quels privilèges. Dans mon esprit, il y a trois utilisateurs typiques pour ma situation:

1. root
2. developer
3. application

rootest explicite. Pour developercet utilisateur, il doit pouvoir accéder facilement à n'importe quelle base de données, y apporter des ajustements, etc. Pour commencer, je configure cet utilisateur sur cet ensemble de privilèges:

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

applicationa un ensemble encore plus limité. Il devrait simplement se limiter à manipuler une base de données spécifique.

Je ne sais pas ce qu'un ensemble raisonnable de privilèges doit accorder. Quels sont les privilèges raisonnables à accorder à un développeur et à une application et pourquoi?

Un utilisateur type devrait avoir:

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

Les quatre premiers sont assez évidents - bien que vous puissiez également configurer des utilisateurs "en lecture seule" avec seulement SELECT.

CREATE TEMPORARYest également pratique et généralement inoffensif: les tables temporaires peuvent aider à optimiser les requêtes, en les divisant en parties plus petites et plus rapides. Ils sont limités à la connexion en cours d'exécution et sont automatiquement supprimés à sa fermeture.

EXECUTEdépend de votre type de système. Avez-vous des routines enregistrées? Souhaitez-vous que vos utilisateurs y accèdent? Assurez-vous que vous connaissez également la SECURITY=DEFINER/INVOKERdéfinition des routines stockées.

Dans tous les cas, assurez-vous d'appliquer tout ce qui précède sur des schémas spécifiques . Évitez d' utiliser:

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

car ce qui précède accorde également des privilèges sur les mysqltables système, permettant efficacement à tout utilisateur de créer de nouveaux comptes ou de mettre à niveau son propre ensemble de privilèges. Au lieu de cela, faites:

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';

Dans tout système à échelle réelle (c'est-à-dire pas un projet personnel), ces types d'utilisateurs varient selon l'environnement, ce n'est donc pas aussi simple que cela.

Dans tous les environnements, l'application doit avoir ce dont elle a besoin et pas plus (généralement, c'est "sélectionner / insérer / mettre à jour sur toutes les tables" et "exécuter sur toutes les procédures". Pour les systèmes plus grands où vous pouvez avoir des utilisateurs d'application distincts pour différentes tâches (pour Par exemple, une application est responsable de l'alimentation des données de censure et une autre de la génération de rapports), vous devez séparer leurs privilèges afin qu'ils aient le moins dont ils ont besoin (l'utilisateur déclarant n'a probablement pas besoin de droits d'écriture). Assurez-vous de le répliquer dans votre test environnements si vous les avez: j'ai vu du code tomber lors de la promotion vers Live qui fonctionnait dans test car tout dans l'environnement de test accédait à la base de données en tant que sa(équivalent de MSSQL à root).Idéalement, un utilisateur d'application ne devrait généralement pas disposer de privilèges lui permettant de modifier votre schéma (CREATE,, DROP...) - il y a des exceptions à cela, mais elles sont rares.

rootest, eh bien root,. En production, il s'agit uniquement de votre DBA et doit être rarement utilisé - uniquement pour la maintenance du système (mises à niveau de la conception de base de données, etc.) et la surveillance. Pour un grand système, en particulier dans les environnements réglementés où vous devez garder un contrôle étroit des individus à des fins de responsabilisation, vous ne pouvez pas autoriser un seul rootutilisateur du tout et essayer de séparer les privilèges en rouleaux plus petits (je ne sais pas jusqu'où vous pouvez aller avec cela dans mysql, mais vous pouvez être assez fin dans MSSQL, Oracle et ainsi de suite).

Pour les utilisateurs développeurs: ils ne devraient avoir aucun accès à vos environnements en direct. C'est l'une des raisons pour lesquelles les utilisateurs d'applications ne devraient pas avoir de schéma affectant les droits: une personne ayant accès à un compte de développeur pourrait potentiellement contourner leur verrouillage de cette façon. Dans les environnements de test également, ils n'ont généralement pas accès: ils soumettraient des correctifs à QA et le DBA (probablement à l'aide d'un rootutilisateur) pour QA appliquerait les mises à jour à l'environnement de test (en fait, cela est souvent automatisé dans les grandes organisations, donc le DBA QA est en fait un ensemble de scripts qui contrôle la reconstruction de l'environnement de test pour chaque cycle). Dans les environnements de développement, en particulier si les développeurs ont leurs propres copies locales du service en cours d'exécution, ces utilisateurs doivent bien sûr avoir un accès complet à tout pour pouvoir expérimenter.

Ce qui précède n'est cependant que des notes générales: pour faire des recommandations spécifiques, nous aurions besoin d'en savoir beaucoup plus sur vos applications et les environnements dans lesquels elles fonctionnent. L'environnement cible est parfois plus important que vous ne le pensez: en fonction de votre environnement professionnel les droits de vos utilisateurs pourraient même être dictés assez directement par des réglementations légales, même en cours de développement si vos clients vous donnent un jour accès à des données réelles à des fins de diagnostic.