Politique d'autorisation d'accès MySQL

Je pense que tout le monde sait que si l'autorisation est le moyen le plus simple, le plus facile et le plus pratique, avec le moins de travaux de maintenance, c'est naturellement le moyen le plus simple et le plus pratique d'accorder toutes les autorisations à tous les utilisateurs. Cependant, nous savons tous certainement que plus l’autorité d’un utilisateur est grande, plus la menace potentielle qu’il représente pour notre système est grande. Par conséquent, du point de vue de la sécurité, plus les autorisations accordées sont petites, mieux c'est. Un administrateur suffisamment sensibilisé à la sécurité n'accordera que les autorisations nécessaires lors de l'octroi de l'autorisation et n'accordera aucune autorisation inutile. Puisque notre chapitre est consacré à la discussion sur la sécurité, nous allons maintenant examiner comment concevoir une stratégie d'autorisation plus sécurisée et raisonnable du point de vue de la sécurité.

Tout d’abord, vous devez comprendre l’hôte en visite.

Étant donné que la connexion à la base de données MySQL vérifie l'utilisateur en plus du nom d'utilisateur et du mot de passe, l'hôte source doit également être vérifié. Nous devons donc également savoir à partir de quels hôtes chaque utilisateur peut établir des connexions. Bien sûr, nous pouvons également utiliser directement le caractère générique "%" pour accorder à tous les hôtes des autorisations d'accès pendant l'autorisation, mais cela viole les principes de notre politique de sécurité et comporte des risques potentiels, ce n'est donc pas conseillé. En particulier, en l'absence de protection par pare-feu sur le réseau local, les utilisateurs pouvant se connecter à partir de n'importe quel hôte ne peuvent pas facilement exister. S'il peut être spécifié par un nom d'hôte ou une adresse IP spécifique, essayez de limiter l'hôte visiteur en utilisant un nom d'hôte et une adresse IP spécifiques. S'il ne peut pas être spécifié par un nom d'hôte ou une adresse IP spécifique, il doit également être limité. en utilisant une plage de caractères génériques aussi petite que possible.

Deuxièmement, comprenez les besoins des utilisateurs.

Puisque nous voulons accorder uniquement les autorisations nécessaires, nous devons comprendre le rôle joué par chaque utilisateur, c'est-à-dire que nous devons bien comprendre le travail que chaque utilisateur doit effectuer pour se connecter à la base de données. Comprendre si l'utilisateur est un utilisateur d'application en lecture seule ou un compte en lecture-écriture ; si l'utilisateur est un utilisateur de tâches de sauvegarde ou un compte de gestion quotidienne ; s'il a uniquement besoin d'accéder à une (ou plusieurs) base de données (schéma) ; ), vous devez toujours accéder à toutes les bases de données. Ce n'est qu'en comprenant ce qui doit être fait que nous pouvons comprendre avec précision quelles autorisations doivent être accordées. Car si les autorisations sont trop faibles, le travail ne se terminera pas normalement, et si les autorisations sont trop élevées, il existe des risques potentiels pour la sécurité.

Encore une fois, classez le travail.

Afin d'accomplir leurs tâches respectives, nous devons classer le travail à effectuer, utiliser différents utilisateurs pour différentes catégories de travail et faire un bon travail de séparation des utilisateurs. Même si cela peut augmenter une certaine charge de travail en termes de coûts de gestion, pour des raisons de sécurité, cette augmentation de la charge de travail de gestion en vaut la peine. Et la séparation des utilisateurs que nous devons faire n’est qu’une séparation modérée. Par exemple, séparez les comptes spécifiques pour effectuer les tâches de sauvegarde, les tâches de réplication, l'accès général aux applications, l'accès aux applications en lecture seule et les tâches de gestion quotidiennes afin d'accorder les autorisations requises à chacun. De cette manière, les risques de sécurité peuvent être minimisés et des autorisations similaires du même type et du même niveau peuvent être fusionnées sans être liées les unes aux autres. Les autorisations spéciales telles que PROCESS, FILE et SUPER ne sont requises que pour les comptes administratifs et ne doivent pas être accordées à d'autres comptes non administratifs.

Enfin, assurez-vous que seuls ceux qui ont absolument besoin d'avoir les autorisations GRANT OPTION.

Lorsque nous avons introduit le système d'autorisation auparavant, nous avons pris connaissance de la particularité de l'autorisation GRANT OPTION et des risques potentiels liés à l'obtention de cette autorisation, nous n'entrerons donc pas dans les détails ici. En bref, pour des raisons de sécurité, moins il y a d'utilisateurs disposant des autorisations GRANT OPTION, mieux c'est. Dans la mesure du possible, seuls les utilisateurs disposant de super autorisations disposent des autorisations GRANT OPTION.

Ce qui précède est le contenu de la politique d'autorisation d'accès MySQL. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !