EnglishCommencer

Les comptes d'une base : qui entre, et par où

Administrer les accès d'une instance PostgreSQL : rôles de connexion et de groupe, héritage des droits, règles de pg_hba.conf lues de haut en bas, expiration, limite de connexions et moindre privilège.

  • 24 cartes
  • 5 thèmes
  • Gratuit
Réviser ce deck

Le programme, thème par thème

Le poids de chaque thème suit celui que lui donne l'examen.

  1. Notions
  2. Questions
  3. Ranger et relier
  4. Mises en situation
  5. Comprendre

Quelques cartes du deck

  • Rôle de connexion : de quoi s'agit-il ?

    Voir la réponse

    Rôle doté de l'attribut LOGIN : c'est lui qui représente un compte, qu'une personne ou une application utilise pour ouvrir une session.

    Dans PostgreSQL, utilisateur et groupe sont une seule notion, le rôle. CREATE USER est un CREATE ROLE … LOGIN.

  • L'utilisateur app se connecte à la base ventes en TCP depuis 10.0.0.12. Quelle règle de ce pg_hba.conf s'applique ?

    ```text
    # TYPE DATABASE USER ADDRESS METHOD
    local all postgres peer
    host all all 127.0.0.1/32 scram-sha-256
    host ventes app 10.0.0.0/24 scram-sha-256
    host all all 10.0.0.0/16 reject
    host ventes app 10.0.0.12/32 trust
    host all all 0.0.0.0/0 scram-sha-256
    `

    • La troisième : mot de passe scram-sha-256
    • La cinquième, trust, parce que c'est la règle la plus précise pour cette adresse
    • La quatrième, reject, parce qu'elle couvre toutes les adresses du réseau de l'application
    • La sixième, scram-sha-256, parce que le serveur retient la règle qui couvre la plus grande plage
    Voir la réponse

    La troisième : mot de passe scram-sha-256

    PostgreSQL lit le fichier de haut en bas et applique la première règle qui correspond à la connexion : ici la troisième. Les règles suivantes, même plus précises (trust) ou plus larges (reject), ne sont jamais lues.

  • L'… vérifie qui se connecte ; l'… vérifie ce qu'il a le droit de faire une fois connecté.

    Voir la réponse

    L'authentification vérifie qui se connecte ; l'autorisation vérifie ce qu'il a le droit de faire une fois connecté.

    pg_hba.conf relève de la première (qui entre, et par où), GRANT et REVOKE de la seconde (quels objets il peut toucher).

  • Rôle de groupe : de quoi s'agit-il ?

    Voir la réponse

    Rôle sans LOGIN qui porte des droits sur des objets et que l'on accorde à d'autres rôles, pour gérer les droits par fonction plutôt que par personne.

    On accorde SELECT une fois à lecture, puis on ajoute les membres à lecture. Quand quelqu'un change de poste, un seul GRANT ou REVOKE suffit.

  • Une application reçoit FATAL: no pg_hba.conf entry for host "10.0.0.12", user "app", database "ventes". Que faire ?

    • Ajouter une règle étroite pour app, ventes et 10.0.0.12/32, puis recharger la configuration
    • Ajouter en tête host all all 0.0.0.0/0 trust pour que plus aucune connexion ne soit refusée
    • Faire de app un superutilisateur, car un superutilisateur n'est pas soumis à pg_hba.conf
    • Créer le rôle app avec CREATE ROLE, puisque la base ne reconnaît pas ce nom d'utilisateur
    Voir la réponse

    Ajouter une règle étroite pour app, ventes et 10.0.0.12/32, puis recharger la configuration

    Le message dit qu'aucune règle ne couvre cette adresse, ce compte et cette base. On l'ajoute au plus étroit puis on recharge (SELECT pg_reload_conf();). Ouvrir toutes les adresses sans mot de passe règle l'erreur en créant une faille. Un superutilisateur passe aussi par pg_hba.conf.

Réviser ce deck