Je vais avoir plusieurs tables utilisées par différents projets sur le même serveur mySql. Une grande partie des données est sensible, et doit être derrière le mur des autorisations. Cependant, de nombreux tableaux de données sensibles reposent sur des tables de données insensibles pour les informations sur les utilisateurs et les services. Donc, je vois trois options devant moi et je ne sais pas lequel choisir.Gestion de la lecture de base de données croisée, des vues ou des autorisations dans MySQL
Dans une base de données avec des autorisations de niveau de table
La plus simple de toutes les solutions sauf que je ne contrôle pas les autorisations sur le serveur de base de données, traditionnellement l'équipe du serveur ne fait que les autorisations de niveau de base de données et de les obtenir pour lui permettre C'est une bataille politique que je n'ai peut-être pas l'influence de gagner, et garder une trace de toutes les autorisations serait une douleur.
Dans plusieurs bases de données, avec des autorisations de niveau base de données
Je peux diviser les tables dans les zones de base de données, panministériel informations, comme les données du personnel, peut être dans sa propre base de données et des outils qui modifier les données du personnel peut avoir UPDATE & INSÉRER l'accès à la base de données du département. D'autres outils voudraient accéder à certaines parties de la liste du personnel, le répertoire personnel du personnel a un accès SELECT aux tables du personnel, mais les parties des tables du personnel doivent rester privées, comme les coordonnées personnelles, les codes de copie ou les index de facturation. Je devrais diviser les tables d'état-major en tables publiques ou privées, mais je serais coincé avec des permissions de niveau de table encore. Il faudrait donc que la base de données du ministère soit divisée entre le ministère partagé et les bases de données privées du ministère. Je souhaite créer des vues dans une base de données qui extrait des données d'autres bases de données auxquelles le compte n'a pas accès. Je peux donc mettre toutes les informations sur le personnel dans la base de données du département, puis créer une vue dans la base de données Web qui extrait uniquement les colonnes qui devraient être accessibles au public (nom, département, extension). Cela me permettrait, en effet, d'avoir des droits SELECT au niveau de la colonne sans avoir à se débrouiller avec des permissions. Mon souci serait la vitesse. La table d'origine à partir de laquelle les données sont tirées serait entièrement indexée, mais la documentation semble contradictoire, que les colonnes soient ou non indexées lors de l'interrogation de la vue.
Est-ce que quelqu'un d'autre a utilisé l'une de ces trois options? En avez-vous de meilleurs auxquels je n'ai pas pensé? Quels sont les pièges que vous pouvez voir au-delà de ce que j'ai indiqué pour l'une des options?
Est-ce que les procédures stockées franchiront également la barrière des autorisations que je peux configurer les procédures avec un compte élevé puis afficher les données avec un compte faible? –
oui - l'une des principales caractéristiques des procédures stockées est qu'elles permettent une meilleure gestion des privilèges. Le compte sur lequel les procédures stockées sont définies serait préférable en tant que compte local - par exemple 'sp_owner' @ 'localhost' - pour réduire le risque qu'un utilisateur distant obtienne un accès puissant sous le compte s'il casse le mot de passe. L'arrangement le plus flexible est que si vos procédures stockées sont définies comme "create definer = current_user procedure ...", la décision du compte auquel elles sont définies peut être différée jusqu'au moment du chargement. – Martin