PostgreSQL-rechten en gebruikersbeheer - wat u moet weten

Gebruikersbeheer binnen PostgreSQL kan lastig zijn. Doorgaans worden nieuwe gebruikers gezamenlijk beheerd binnen een aantal sleutelgebieden in de omgeving. Vaak zijn privileges aan de ene kant perfect, maar aan de andere kant verkeerd geconfigureerd. Deze blogpost biedt praktische 'Tips en Tricks' voor een gebruiker of rol, zoals we die zullen leren kennen, ingesteld binnen PostgreSQL.

De onderwerpen waarop we ons zullen concentreren zijn:

• De rol van PostgreSQL op zich nemen

U leert over rollen, rolattributen, best practices voor het benoemen van uw rollen en algemene rolconfiguraties.

• Het pg_hba.conf-bestand

In deze sectie zullen we kijken naar een van de belangrijkste bestanden en de instellingen ervan, voor verbindingen aan de clientzijde en communicatie met de server.

• Bevoegdheden en beperkingen op database-, tabel- en kolomniveau.

Wilt u rollen configureren voor optimale prestaties en gebruik? Bevatten uw tabellen gevoelige gegevens die alleen toegankelijk zijn voor geprivilegieerde rollen? Maar met de noodzaak om verschillende rollen toe te staan ​​om beperkt werk uit te voeren? Deze vragen en meer zullen in deze sectie worden behandeld.

De rol van PostgreSQL:wat is een 'rol' en hoe maak je er een?

Machtigingen voor databasetoegang binnen PostgreSQL worden afgehandeld met het concept van een rol, vergelijkbaar met een gebruiker. Rollen kunnen ook groepen gebruikers in het PostgreSQL-ecosysteem vertegenwoordigen.

PostgreSQL zorgt voor de capaciteit voor rollen om privileges toe te kennen aan database-objecten waarvan ze de eigenaar zijn, waardoor toegang en acties tot die objecten mogelijk worden. Rollen hebben de mogelijkheid om lidmaatschap toe te kennen aan een andere rol. Kenmerken bieden aanpassingsopties voor toegestane clientverificatie.

Attributen voor rollen via de opdracht CREATE ROLE zijn beschikbaar in de officiële PostgreSQL-documentatie.

Hieronder staan ​​de kenmerken die u gewoonlijk toewijst bij het instellen van een nieuwe rol. De meeste hiervan spreken voor zich. Er wordt echter een korte beschrijving gegeven om eventuele verwarring weg te nemen, samen met gebruiksvoorbeelden.

SUPERUSER - Een database SUPERUSER verdient een waarschuwing. Kortom, rollen met dit attribuut kunnen een andere SUPERUSER creëren. Dit attribuut is trouwens vereist om een ​​andere SUPERUSER-rol te creëren. Aangezien rollen met dit kenmerk alle toestemmingscontroles omzeilen, moet u dit privilege oordeelkundig toekennen.

CREATEDB - Hiermee kan de rol databases maken.

CREATEROLE - Met dit attribuut kan een rol de opdracht CREATE ROLE geven. Creëer daarom andere rollen.

LOGIN - Maakt het mogelijk om in te loggen. Een rolnaam met dit kenmerk kan worden gebruikt in de opdracht clientverbinding. Meer details over dit kenmerk met aanstaande voorbeelden.

Bepaalde attributen hebben een expliciet tegengestelde benoemde opdracht en zijn typisch de standaard wanneer ze niet gespecificeerd worden.

bijv.
SUPERUSER | NOSUPERUSER
CREATEROLE |NOCREATEROLE
LOGIN |NOLOGIN

Laten we eens kijken naar enkele van deze kenmerken in actie voor verschillende configuraties die u kunt instellen om aan de slag te gaan.

Rollen maken en laten vallen

Het creëren van een rol is relatief eenvoudig. Hier is een snel voorbeeld:

postgres=# CREATE ROLE $money_man;
ERROR: syntax error at or near "$"
LINE 1: CREATE ROLE $money_man;

Wat ging daar mis? Het blijkt dat rolnamen niet met iets anders dan een letter kunnen beginnen.

"Hoe zit het met het verpakken van de naam tussen dubbele aanhalingstekens?" Eens kijken:

postgres=# CREATE ROLE "$money_man";
CREATE ROLE

Dat werkte, hoewel waarschijnlijk geen goed idee. Wat dacht je van een speciaal teken in het midden van de naam?

postgres=# CREATE ROLE money$_man;
CREATE ROLE

Geen probleem daar. Zelfs zonder dubbele aanhalingstekens werd er geen fout geretourneerd.

Ik ben gewoon niet dol op de naamstructuur van $money_man voor een gebruiker. Ik laat je $money_man vallen en begin opnieuw. Het DROP ROLE commando zorgt voor het verwijderen van een rol. Hier is het in gebruik.

postgres=# DROP ROLE $money_man;
ERROR: syntax error at or near "$"
LINE 1: DROP ROLE $money_man;

En nog een fout met de rol $money_man. Nogmaals, het is zijn toevlucht tot de dubbele aanhalingstekens.

postgres=# DROP ROLE "$money_man";
DROP ROLE

Het LOGIN-recht

Laten we eens kijken naar twee verschillende gebruikers, één met het LOGIN-recht en één zonder. Ik zal ze ook wachtwoorden toewijzen.

postgres=# CREATE ROLE nolog_user WITH PASSWORD 'pass1';
CREATE ROLE

postgres=# CREATE ROLE log_user WITH LOGIN PASSWORD 'pass2';
CREATE ROLE

Opmerking:de wachtwoorden die voor de bovenstaande fictieve rollen zijn verstrekt, zijn alleen voor demonstratiedoeleinden. U moet er altijd naar streven om unieke en geharde wachtwoorden te verstrekken bij het implementeren van rollen. Hoewel een wachtwoord beter is dan geen wachtwoord, is een gehard wachtwoord zelfs beter dan een triviaal wachtwoord.

Laten we log_user de CREATEDB- en CREATEROLE-attributen toewijzen met het ALTER ROLE-commando.

postgres=# ALTER ROLE log_user CREATEROLE CREATEDB;
ALTER ROLE

U kunt deze ingestelde attributen verifiëren door de pg_role-catalogus te controleren. Twee interessante kolommen zijn rolcreaterol en rolcreatedb. Beide zijn van het Booleaanse gegevenstype, dus ze moeten worden ingesteld op t voor true voor deze attributen.

Bevestig met een vergelijkbare SELECT-query.

postgres=# SELECT rolcreaterole, rolcreatedb FROM pg_roles WHERE rolname = 'log_user';
rolcreaterole | rolcreatedb 
---------------+-------------
t | t
(1 row)

Hoe kunt u de bestaande rollen in de database bepalen?

Twee beschikbare methoden zijn het psql \du-commando of selecteren uit de pg_roles-catalogus.

Hier zijn ze allebei in gebruik.

postgres=> \du
List of roles
Role name | Attributes | Member of 
------------+------------------------------------------------------------+-----------
log_user | Create role, Create DB | {}
nolog_user | Cannot login | {}

postgres=> SELECT rolname FROM pg_roles;
rolname 
----------------------
nolog_user
log_user
(2 rows)

Aanmelden

Laten we beide rollen een kans geven om in te loggen op de server.

psql -U nolog_user -W postgres
Password for user nolog_user: 
psql: FATAL: no pg_hba.conf entry for host "[local]", user "nolog_user", database "postgres", SSL off
psql -U log_user -W postgres
Password for user log_user: 
psql: FATAL: no pg_hba.conf entry for host "[local]", user "log_user", database "postgres", SSL off

Om dit probleem op te lossen, moeten we in dat pg_hba.conf-bestand graven. De oplossing wordt besproken terwijl we doorgaan in dit bericht, naar dat specifieke gedeelte.

Handzame afhaalrestaurants

• CREATE ROLE en zijn tegenhanger, DROP ROLE, zijn uw go-to-commando's voor het implementeren en verwijderen van rollen.
• ALTER ROLE zorgt voor het wijzigen van de attributen van een rol.
• Rollen zijn geldig binnen alle databases vanwege definitie op databaseclusterniveau.
• Houd er rekening mee dat het creëren van een rolnaam die begint met een speciaal teken, vereist dat je deze met dubbele aanhalingstekens 'adresseert'.
• Rollen en hun privileges worden vastgesteld met behulp van attributen.
• Om rollen vast te stellen waarvoor standaard het LOGIN-kenmerk nodig is, is CREATE USER een optionele opdracht die tot uw beschikking staat. Gebruikt in plaats van CREATE ROLE role_name LOGIN, zijn ze in wezen gelijk.

Het bestand pg_hba.conf - Een gemeenschappelijke basis leggen tussen de server en de client

Het zou op zijn best ontmoedigend zijn om alle aspecten en instellingen voor het bestand pg_hba.conf in één blogpost te behandelen. In plaats daarvan presenteert dit gedeelte veelvoorkomende valkuilen die u kunt tegenkomen en oplossingen om deze te verhelpen.

Succesvolle verbindingen vereisen een gezamenlijke inspanning van beide delen als geheel. Rollen die verbinding maken met de server, moeten nog steeds voldoen aan de toegangsbeperkingen die zijn ingesteld op databaseniveau, na het doorgeven van de instellingen in het bestand pg_hba.conf.

Relevante voorbeelden van deze relatie worden opgenomen naarmate deze sectie vordert.

Om uw pg_hba.conf-bestand te vinden, voert u een vergelijkbare SELECT-query uit in de pg_settings VIEW. U moet ingelogd zijn als SUPERUSER om deze VIEW op te vragen.

postgres=# SELECT name, setting
FROM pg_settings WHERE name LIKE '%hba%';
name | setting 
----------+-------------------------------------
hba_file | /etc/postgresql/10/main/pg_hba.conf
(1 row)

Het bestand pg_hba.conf bevat records die een van de zeven beschikbare formaten voor een bepaald verbindingsverzoek specificeren. Bekijk hier het volledige spectrum.

Voor het doel van deze blogpost zullen we kijken naar instellingen die u kunt gebruiken voor een lokale omgeving.

Misschien is deze server bedoeld om verder te leren en te studeren (zoals de mijne).

Ik moet er speciaal op wijzen dat deze instellingen niet de optimale instellingen zijn voor een gehard systeem met meerdere gebruikers.

De velden voor dit type verbinding zijn:

local database user auth-method [auth-options]

Waar ze bedoelen:

local - er wordt geprobeerd verbinding te maken met Unix-domein sockets.

database - Specificeert de database(s) genoemd voor deze recordovereenkomst.

gebruiker - De gebruikersnaam van de database die overeenkomt met deze record. Een door komma's gescheiden lijst van meerdere gebruikers of allemaal is ook toegestaan ​​voor dit veld.

auth-methode - Wordt gebruikt wanneer een verbinding overeenkomt met dit unieke record. De mogelijke keuzes voor dit veld zijn:

• vertrouwen
• weigeren
• scram-sha-256
• md5
• wachtwoord
• gss
• sspi
• identiteit
• peer
• ldap
• straal
• certificaat
• pam
• bsd

De regels die zijn ingesteld in het bestand pg_hba.conf voor de rollen nolog_user en log_user zien er als volgt uit:

local all nolog_user password
local all log_user password

Opmerking:aangezien het wachtwoord in leesbare tekst wordt verzonden, mag dit niet worden gebruikt in niet-vertrouwde omgevingen met niet-vertrouwde netwerken.

Laten we eens kijken naar drie interessante kolommen uit de pg_hba_file_rules VIEW met de onderstaande vraag. Nogmaals, je rol heeft het SUPERUSER-attribuut nodig om deze VIEW te doorzoeken.

postgres=# SELECT database, user_name, auth_method
postgres-# FROM pg_hba_file_rules
postgres-# WHERE CAST(user_name AS TEXT) LIKE '%log_user%';
database | user_name | auth_method 
----------+--------------+-------------
{all} | {nolog_user} | password
{all} | {log_user} | password
(2 rows)

We kunnen identieke informatie zien uit de bovenstaande regels in het bestand pg_hba.conf, net zoals we kunnen uit de bijbehorende query. Op het eerste gezicht lijkt het alsof beide rollen kunnen inloggen.

We zullen testen en bevestigen.

psql -U nolog_user -W postgres
Password for user nolog_user: 
psql: FATAL: role "nolog_user" is not permitted to log in
psql -U log_user -W postgres
Password for user log_user: 
psql (10.1)
Type "help" for help.
postgres=>

Het belangrijkste punt hier is dat, hoewel nolog_user en log_user beide kunnen inloggen volgens het pg_hba.conf-bestand, alleen log_user daadwerkelijk mag inloggen.

Waar log_user de toegangsbeperkingen op databaseniveau heeft doorstaan ​​(door het LOGIN-kenmerk te hebben), deed nolog_user dat niet.

Laten we de regel van log_user in het bestand pg_hba.conf bewerken en de databasenaam wijzigen waartoe deze rol toegang heeft. Dit is de wijziging, die aangeeft dat log_user nu alleen kan inloggen op de proefdatabase.

local trial log_user password

Laten we eerst proberen in te loggen op de postgres-database, waartoe log_user eerder toegang had vanwege de all-vlag.

$ psql -U log_user -W postgres
Password for user log_user: 
psql: FATAL: no pg_hba.conf entry for host "[local]", user "log_user", database "postgres", SSL off

Nu met de proefdatabase heeft log_user het recht om

$ psql -U log_user -W trial
Password for user log_user: 
psql (10.1)
Type "help" for help.
trial=>

Geen fout daar en de trial=> prompt toont de momenteel verbonden database.

Deze instellingen zijn ook van toepassing binnen de serveromgeving, zodra er een verbinding tot stand is gebracht.

Laten we opnieuw proberen verbinding te maken met die postgres-database:

trial=> \c postgres;
Password for user log_user: 
FATAL: no pg_hba.conf entry for host "[local]", user "log_user", database "postgres", SSL off
Previous connection kept

Door de voorbeelden die hier worden gepresenteerd, moet u op de hoogte zijn van de aanpassingsopties voor de rollen in uw cluster.

Opmerking:vaak is het opnieuw laden van het bestand pg_hba.conf vereist om wijzigingen door te voeren.

Gebruik het hulpprogramma pg_ctl om uw server opnieuw te laden.

De syntaxis zou zijn:

pg_ctl reload [-D datadir] [-s]

Om te weten waar uw datadir is, kunt u het pg_settings systeem VIEW opvragen, indien ingelogd als een SUPERUSER met een vergelijkbare SELECT-query zoals hieronder.

postgres=# SELECT setting FROM pg_settings WHERE name = 'data_directory';
           setting           
-----------------------------
 /var/lib/postgresql/10/main
(1 row)

Geef dan je shell aan de postgres-gebruiker (of andere SUPERUSER) met:

$ sudo -u postgres bash

Tenzij u het hulpprogramma pg_ctl aan uw $PATH heeft toegevoegd, moet u het volledig kwalificeren voor gebruik en vervolgens het uit te voeren commando doorgeven, samen met de datadir-locatie.

Hier is een voorbeeld:

$ /usr/lib/postgresql/10/bin/pg_ctl reload -D /var/lib/postgresql/10/main
server signaled

Laten we de status van de server controleren met:

$ /usr/lib/postgresql/10/bin/pg_ctl status -D /var/lib/postgresql/10/main
pg_ctl: server is running (PID: 1415)
/usr/lib/postgresql/10/bin/postgres "-D" "/var/lib/postgresql/10/main" "-c" "config_file=/etc/postgresql/10/main/postgresql.conf"

Handzame afhaalrestaurants

• Rollen moeten voldoen aan de vereisten van zowel het pg_hba.conf-bestand als de toegangsrechten op databaseniveau.
• pg_hba.conf-bestand wordt van boven naar beneden gecontroleerd voor elk verbindingsverzoek. De volgorde in het bestand is belangrijk.

Bevoegdheden en beperkingen voor databases, tabellen en kolommen - Rollen op maat voor taken en verantwoordelijkheden

Om ervoor te zorgen dat rollen database-objecten (tabellen, weergaven, kolommen, functies, enz.) kunnen gebruiken, moeten ze toegangsrechten krijgen.

Het GRANT-commando definieert deze essentiële privileges.

We zullen een paar voorbeelden doornemen om de essentie van het gebruik ervan te begrijpen.

Databases maken

Aangezien log_user de kenmerken CREATEDB en CREATEROLE heeft gekregen, kunnen we deze rol gebruiken om een ​​testdatabase met de naam trial te maken.

postgres=> CREATE DATABASE trial:
CREATE DATABASE

Naast het maken van een nieuwe ROL:

postgres=> CREATE ROLE db_user WITH LOGIN PASSWORD 'scooby';
CREATE ROLE

Ten slotte zal log_user verbinding maken met de nieuwe proefdatabase:

postgres=> \c trial;
Password for user log_user: 
You are now connected to database "trial" as user "log_user".
trial=>

Merk op dat de prompt is veranderd in de naam 'trial', wat aangeeft dat we verbonden zijn met die database.

Laten we log_user gebruiken om een ​​neptabel te MAKEN.

trial=> CREATE TABLE another_workload(
trial(> id INTEGER,
trial(> first_name VARCHAR(20),
trial(> last_name VARCHAR(20),
trial(> sensitive_info TEXT);
CREATE TABLE

Rol log_user heeft onlangs een hulprol gemaakt, db_user. We vereisen dat db_user beperkte rechten heeft voor de tabel else_workload.

Ongetwijfeld mag de kolom sensitive_info niet worden geopend door deze rol. INSERT-, UPDATE- en DELETE-opdrachten mogen op dit moment ook niet worden gegeven, totdat db_user aan bepaalde verwachtingen voldoet.

db_user is echter vereist om SELECT-query's uit te voeren. Hoe kunnen we de mogelijkheden van deze rol binnen de else_workload-tabel beperken?

Laten we eerst eens kijken naar de exacte syntaxis die te vinden is in de PostgreSQL GRANT-opdrachtdocumenten, op tabelniveau.

GRANT { { SELECT | INSERT | UPDATE | REFERENCES } ( column_name [, ...] )
[, ...] | ALL [ PRIVILEGES ] ( column_name [, ...] ) }
ON [ TABLE ] table_name [, ...]
TO role_specification [, ...] [ WITH GRANT OPTION ]

Vervolgens implementeren we de vereisten die zijn uiteengezet voor de rol db_user, waarbij we een specifieke syntaxis toepassen.

trial=> GRANT SELECT (id, first_name, last_name) ON TABLE another_workload TO db_user;
GRANT

Merk op dat we net na het SELECT-sleutelwoord de kolommen hebben vermeld waartoe db_user toegang heeft. Als db_user SELECT-query's in de sensitive_info-kolom of een ander commando probeert te gebruiken, of een ander commando, worden die query's niet uitgevoerd totdat ze zijn gewijzigd.

Met db_user ingelogd, zullen we dit in praktijk brengen door een SELECT-query te proberen om alle kolommen en records uit de tabel te retourneren.

trial=> SELECT * FROM another_workload;
ERROR: permission denied for relation another_workload

Kolom sensitive_info is opgenomen in deze query. Daarom worden er geen records teruggestuurd naar db_user.

Maar db_user kan de toegestane kolommen SELECTEREN

trial=> SELECT id, first_name, last_name
trial-> FROM another_workload;
id | first_name | last_name 
-----+------------+-----------
10 | John | Morris
191 | Jannis | Harper
2 | Remmy | Rosebuilt
(3 rows)

Dat werkt prima.

We zullen ook de INSERT-, UPDATE- en DELETE-commando's testen.

trial=> INSERT INTO another_workload(id,first_name,last_name,sensitive_info)
VALUES(17,'Jeremy','Stillman','key code:400Z');
ERROR: permission denied for relation another_workload

trial=> UPDATE another_workload
trial-> SET id = 101
trial-> WHERE id = 10;
ERROR: permission denied for relation another_workload

trial=> DELETE FROM another_workload
trial-> WHERE id = 2;;
ERROR: permission denied for relation another_workload

Door geen INSERT-, UPDATE- of DELETE-opdrachten toe te wijzen aan db_user, wordt de rol de toegang tot het gebruik ervan ontzegd.

Met de overvloed aan beschikbare opties is het configureren van uw rol vrijwel onbeperkt. U kunt ze volledig functioneel maken, in staat om elk commando uit te voeren, of zo beperkt als uw vereisten dicteren.

Handzame afhaalrestaurants

• Rollen krijgen toegangsrechten tot database-objecten via het GRANT-commando.
• Database-objecten en commando's tegen die objecten zijn zeer configureerbaar binnen de PostgreSQL-omgeving.

Afsluiten

Door de voorbeelden van deze blogpost, zou u een beter begrip moeten hebben van:

1. Een rol maken met specifieke kenmerken.
2. Een werkbare verbinding tot stand brengen tussen de client en de server, waardoor de rollen inlogtoegang tot databases krijgen.
3. Uw rollen sterk aanpassen om te voldoen aan individuele vereisten voor toegang op database-, tabel- en kolomniveau door de nodige attributen te implementeren.