36. PostgreSQL säkerhet

PostgreSQL har ett rikt och flexibelt behörighetssystem med förmågan att dela ut särskilda privilegier till särskilda roles, och ge användare befogenheterna för en eller flera av dessa roles.

Dessutom kan PostgreSQL-servern använda flera olika system för att autentisera användare. Detta innebär att databasen kan använda samma autentiseringsinfrastruktur som andra arkitekturkomponenter, vilket förenklar lösenordshanteringen.

36.1. Användare och roller

I det här kapitlet kommer vi att skapa två användbara produktionsanvändare:

  • En skrivskyddad användare för användning i en publiceringsapplikation.

  • En läs/skriv-användare som används av en utvecklare för att bygga en programvara eller analysera data.

I stället för att skapa användare och ge dem de nödvändiga befogenheterna skapar vi två roller med rätt befogenheter och skapar sedan två användare och lägger till dem i lämpliga roller. På så sätt kan vi enkelt återanvända rollerna när vi skapar ytterligare användare.

36.1.1. Skapa roller

En roll är en användare och en användare är en roll. Den enda skillnaden är att en ”user” kan sägas vara en roll med ”login”-rättigheter.

Så funktionellt sett är de två SQL-satserna nedan desamma, de skapar båda en ”roll med inloggningsbehörighet”, det vill säga en ”användare”.

CREATE ROLE mrbean LOGIN;
CREATE USER mrbean;

36.1.2. Skrivskyddade användare

Vår skrivskyddade användare kommer att användas av en webbapplikation för att söka i tabellen nyc_streets.

Programmet kommer att ha specifik åtkomst till tabellen nyc_streets, men kommer att ärva den nödvändiga systemåtkomsten för PostGIS-operationer från rollen postgis_reader.

-- A user account for the web app
CREATE USER app1;
-- Web app needs access to specific data tables
GRANT SELECT ON nyc_streets TO app1;

-- A generic role for access to PostGIS functionality
CREATE ROLE postgis_reader INHERIT;
-- Give that role to the web app
GRANT postgis_reader TO app1;

Nu, när vi loggar in som app1, kan vi välja rader från tabellen nyc_streets. Vi kan dock inte köra ett ST_Transform-anrop! Varför kan vi inte det?

-- This works!
SELECT * FROM nyc_streets LIMIT 1;

-- This doesn't work!
SELECT ST_AsText(ST_Transform(geom, 4326))
  FROM nyc_streets LIMIT 1;

ERROR:  permission denied for relation spatial_ref_sys
CONTEXT:  SQL statement "SELECT proj4text FROM spatial_ref_sys WHERE srid = 4326 LIMIT 1"

Svaret finns i felmeddelandet. Även om vår app1 användare kan se innehållet i nyc_streets tabellen bra, kan den inte se innehållet i spatial_ref_sys, så anropet till ST_Transform misslyckas.

Därför måste vi också ge rollen postgis_reader läsåtkomst till alla PostGIS-metadatatabeller:

GRANT SELECT ON geometry_columns TO postgis_reader;
GRANT SELECT ON geography_columns TO postgis_reader;
GRANT SELECT ON spatial_ref_sys TO postgis_reader;

Nu har vi en generisk roll, postgis_reader, som vi kan använda för alla användare som behöver läsa från PostGIS-tabeller.

-- This works now!
SELECT ST_AsText(ST_Transform(geom, 4326))
  FROM nyc_streets LIMIT 1;

36.1.3. Läsa/skriva Användare

Det finns två typer av läs/skriv-scenarier som vi måste ta hänsyn till:

  • Webbapplikationer och andra som behöver skriva till befintliga datatabeller.

  • Utvecklare eller analytiker som behöver skapa nya tabeller och geometrikolumner som en del av sitt arbete.

För webbapplikationer som kräver skrivåtkomst till datatabeller behöver vi bara ge extra behörigheter till själva tabellerna, och vi kan fortsätta att använda rollen postgis_reader.

-- Add insert/update/delete abilities to our web application
GRANT INSERT,UPDATE,DELETE ON nyc_streets TO app1;

Den här typen av behörigheter krävs t.ex. för en WFS-tjänst för läsning/skrivning.

För utvecklare och analytiker behövs lite mer tillgång till de viktigaste PostGIS-metadatatabellerna. Vi kommer att behöva en postgis_writer roll som kan redigera PostGIS metadatatabeller!

-- Make a postgis writer role
CREATE ROLE postgis_writer;

-- Start by giving it the postgis_reader powers
GRANT postgis_reader TO postgis_writer;

-- Add insert/update/delete powers for the PostGIS tables
GRANT INSERT,UPDATE,DELETE ON spatial_ref_sys TO postgis_writer;

-- Make app1 a PostGIS writer to see if it works!
GRANT postgis_writer TO app1;

Prova nu att skapa tabellen SQL ovan som app1-användare och se hur det går!

36.2. Kryptering

PostgreSQL tillhandahåller många krypteringsfaciliteter, många av dem valfria, några av dem är på som standard.

  • Som standard är alla lösenord MD5-krypterade. Handskakningen mellan klient och server dubbelkrypterar MD5-lösenordet för att förhindra att hashen återanvänds av någon som snappar upp lösenordet.

  • SSL-anslutningar är valfritt tillgängliga mellan klienten och servern för att kryptera all data och inloggningsinformation. Autentisering med SSL-certifikat är också tillgänglig när SSL-anslutningar används.

  • Kolumner i databasen kan krypteras med hjälp av modulen pgcrypto, som innehåller hash-algoritmer, direkta chiffer (blowfish, aes) och både PGP-kryptering med offentlig nyckel och symmetrisk kryptering.

36.2.1. SSL-anslutningar

För att kunna använda SSL-anslutningar måste både klienten och servern ha stöd för SSL.

  • Stäng först av PostgreSQL, eftersom aktivering av SSL kommer att kräva en omstart.

  • Därefter skaffar eller genererar vi ett SSL-certifikat och en nyckel. Certifikatet får inte innehålla någon lösenfras, annars kommer databasservern inte att kunna startas. Du kan generera en självsignerad nyckel enligt följande:

    # Create a new certificate, filling out the certification info as prompted
openssl req -new -text -out server.req

# Strip the passphrase from the certificate
openssl rsa -in privkey.pem -out server.key

# Convert the certificate into a self-signed cert
openssl req -x509 -in server.req -text -key server.key -out server.crt

# Set the permission of the key to private read/write
chmod og-rwx server.key

  • Kopiera server.crt och server.key till PostgreSQL-datakatalogen.

  • Aktivera SSL-stöd i filen postgresql.conf genom att ändra parametern ”ssl” till ”on”.

  • Starta nu PostgreSQL igen; servern är redo för SSL-drift.

När servern är aktiverad för SSL är det enkelt att skapa en krypterad anslutning. I PgAdmin skapar du en ny serveranslutning (Arkiv > Lägg till server…) och ställer in SSL-parametern på ”require”.

_images/ssl_create.jpg

När du ansluter till den nya anslutningen kan du se i dess egenskaper att den använder en SSL-anslutning.

_images/ssl_props.jpg

Eftersom standardläget för SSL-anslutning är ”prefer” behöver du inte ens ange en SSL-preferens när du ansluter. En anslutning med kommandoraden psql terminal kommer att plocka upp SSL-alternativet och använda det som standard:

psql (8.4.9)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.

postgres=#

Observera hur terminalen rapporterar SSL-statusen för anslutningen.

36.2.2. Kryptering av data

Modulen pgcrypto har ett stort utbud av krypteringsalternativ, så vi kommer bara att demonstrera det enklaste användningsfallet: kryptering av en datakolumn med hjälp av ett symmetriskt chiffer.

  • Först aktiverar du pgcrypto genom att ladda Contrib SQL-filen, antingen i PgAdmin eller psql.

    pgsql/8.4/share/postgresql/contrib/pgcrypto.sql

  • Testa sedan krypteringsfunktionen.

    -- encrypt a string using blowfish (bf)
SELECT encrypt('this is a test phrase', 'mykey', 'bf');

  • Och se till att den är vändbar också!

    -- round-trip a string using blowfish (bf)
SELECT decrypt(encrypt('this is a test phrase', 'mykey', 'bf'), 'mykey', 'bf');

36.3. Autentisering

PostgreSQL stöder många olika autentiseringsmetoder, för att möjliggöra enkel integration i befintliga företagsarkitekturer. För produktionsändamål används följande metoder vanligtvis:

  • Password är ett grundläggande system där lösenorden lagras i databasen med MD5-kryptering.

  • Kerberos är en standard autentiseringsmetod för företag som används av både GSSAPI och SSPI-scheman i PostgreSQL. Med hjälp av SSPI kan PostgreSQL autentisera mot Windows-servrar.

  • LDAP är en annan vanlig autentiseringsmetod för företag. Servern OpenLDAP som levereras med de flesta Linux-distributioner tillhandahåller en implementering av LDAP med öppen källkod.

  • Certificate-autentisering är ett alternativ om du förväntar dig att alla klientanslutningar ska ske via SSL och om du kan hantera distributionen av nycklar.

  • PAM-autentisering är ett alternativ om du använder Linux eller Solaris och använder PAM-schemat för transparent autentisering.

Autentiseringsmetoderna styrs av filen pg_hba.conf. ”HBA” i filnamnet står för ”host based access”, eftersom du inte bara kan ange vilken autentiseringsmetod som ska användas för varje databas, utan även kan begränsa värdåtkomsten med hjälp av nätverksadresser.

Här är ett exempel på filen pg_hba.conf:

# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD

# "local" is for Unix domain socket connections only
local   all         all                               trust
# IPv4 local connections:
host    all         all         127.0.0.1/32          trust
# IPv6 local connections:
host    all         all         ::1/128               trust
# remote connections for nyc database only
host    nyc         all         192.168.1.0/2         ldap

Filen består av fem kolumner

  • TYPE avgör vilken typ av åtkomst som avses, antingen ”local” för anslutningar från samma server eller ”host” för fjärranslutningar.

  • DATABASE anger vilken databas som konfigurationsraden hänvisar till eller ”all” för alla databaser

  • USER anger vilka användare raden avser eller ”all” för alla användare

  • CIDR-ADDRESS anger nätverksbegränsningarna för fjärranslutningar, med syntaxen network/netmask

  • METHOD anger vilket autentiseringsprotokoll som ska användas. ”trust” hoppar helt över autentisering och accepterar helt enkelt alla giltiga användarnamn utan utmaning.

Det är vanligt att lokala anslutningar är betrodda, eftersom åtkomst till själva servern vanligtvis är privilegierad. Fjärranslutningar är inaktiverade som standard när PostgreSQL installeras: om du vill ansluta från fjärrmaskiner måste du lägga till en post.

Raden för nyc i exemplet ovan är ett exempel på en fjärråtkomstpost. Exemplet nyc tillåter LDAP-autentiserad åtkomst endast till maskiner i det lokala nätverket (i det här fallet 192.168.1.-nätverket) och endast till nyc-databasen. Beroende på säkerheten i ditt nätverk kommer du att använda mer eller mindre strikta versioner av dessa regler i din produktionskonfiguration.