« PostgreSQL/Sécurité » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
Ligne 10 : | Ligne 10 : | ||
Ce concept dépasse celui des utilisateurs et groupes : un rôle peut être pensé soit comme un utilisateur de base de données, soit comme un groupe de ceux-ci. Les rôles possèdent certain privilèges sur les objets de la base comme les tables ou les fonctions, et peuvent les transmettre à d'autres rôles. Les rôles sont globaux au sein d'un {{wt|cluster}}, et pas seulement valables pour une seule base. |
Ce concept dépasse celui des utilisateurs et groupes : un rôle peut être pensé soit comme un utilisateur de base de données, soit comme un groupe de ceux-ci. Les rôles possèdent certain privilèges sur les objets de la base comme les tables ou les fonctions, et peuvent les transmettre à d'autres rôles. Les rôles sont globaux au sein d'un {{wt|cluster}}, et pas seulement valables pour une seule base. |
||
Souvent les utilisateurs devant avoir des privilèges identiques sont rassemblés dans un groupe qui reçoit les permissions. |
|||
Often users, which shall have identical privileges, are grouped together to a user group and the privileges are granted to the group. |
|||
-- |
-- Groupe |
||
CREATE ROLE group_1 ENCRYPTED PASSWORD 'xyz'; |
CREATE ROLE group_1 ENCRYPTED PASSWORD 'xyz'; |
||
GRANT SELECT ON table_1 TO group_1; |
GRANT SELECT ON table_1 TO group_1; |
||
-- |
-- Utilisateurs |
||
CREATE ROLE adam LOGIN ENCRYPTED PASSWORD 'xyz'; -- |
CREATE ROLE adam LOGIN ENCRYPTED PASSWORD 'xyz'; -- NOLOGIN par défaut |
||
CREATE ROLE anne LOGIN ENCRYPTED PASSWORD 'xyz'; |
CREATE ROLE anne LOGIN ENCRYPTED PASSWORD 'xyz'; |
||
-- Lien entre les deux |
|||
-- the link between user group and users |
|||
GRANT group_1 TO adam, anne; |
GRANT group_1 TO adam, anne; |
||
La commande <code>CREATE ROLE</code> peut assigner les privilèges ''SUPERUSER, CREATEDB, CREATEROLE, REPLICATION'' et ''LOGIN''. <code>GRANT</code> confère les permissions d'accès aux tables ou l'appartenance à un groupe. |
|||
Implicitement le rôle spécial <code>PUBLIC</code> peut être vu comme un groupe qui inclut tous les rôles. Par conséquent les privilèges assignés à <code>PUBLIC</code> sont implicitement donnés à tous les rôles, même ceux créés plus tard. |
|||
Implicitly there is the special role PUBLIC, which can be thought of as a group that always includes all roles. Thus, privileges assigned to PUBLIC are implicitly given to all roles, even when those roles are created at a later stage. |
|||
== Références == |
== Références == |
||
{{Références}} |
{{Références}} |
||
{{à traduire}} |
Version du 29 septembre 2016 à 11:20
Comptes système
- Sur Windows, il faut que l'utilisateur se soit connecté au moins une fois avec PgAdmin pour que le mot de passe de la base soit enregistré (en clair) dans son répertoire personnel : C:\Users\MonUtilisateur\AppData\Roaming\postgresql\pgpass.conf.
- Sur Linux, c'est stocké dans ~/.pgpass par défaut.
Rôles
PostgreSQL reconnait le concept des rôles (roles
)[1] pour assurer la sécurité de l'authentification et de l'identification, indépendamment des comptes du système d'exploitation.
Ce concept dépasse celui des utilisateurs et groupes : un rôle peut être pensé soit comme un utilisateur de base de données, soit comme un groupe de ceux-ci. Les rôles possèdent certain privilèges sur les objets de la base comme les tables ou les fonctions, et peuvent les transmettre à d'autres rôles. Les rôles sont globaux au sein d'un cluster, et pas seulement valables pour une seule base.
Souvent les utilisateurs devant avoir des privilèges identiques sont rassemblés dans un groupe qui reçoit les permissions.
-- Groupe CREATE ROLE group_1 ENCRYPTED PASSWORD 'xyz'; GRANT SELECT ON table_1 TO group_1; -- Utilisateurs CREATE ROLE adam LOGIN ENCRYPTED PASSWORD 'xyz'; -- NOLOGIN par défaut CREATE ROLE anne LOGIN ENCRYPTED PASSWORD 'xyz'; -- Lien entre les deux GRANT group_1 TO adam, anne;
La commande CREATE ROLE
peut assigner les privilèges SUPERUSER, CREATEDB, CREATEROLE, REPLICATION et LOGIN. GRANT
confère les permissions d'accès aux tables ou l'appartenance à un groupe.
Implicitement le rôle spécial PUBLIC
peut être vu comme un groupe qui inclut tous les rôles. Par conséquent les privilèges assignés à PUBLIC
sont implicitement donnés à tous les rôles, même ceux créés plus tard.