PDF de programación - Autorización en postgreSQL

Autorización en PostgreSQL

Documento de apoyo para cursos

Charles Clavadetscher

31.08.2015

There is no such thing as perfect
security, only varying levels of
insecurity.

—Salman Rushdie

Tabla de materias

1 Introducción

2 Conceptos básicos y deniciones

3 Acceso a la base de datos

4 Acceso a esquemas

5 Acceso a otros objetos de una base de datos
.
.
.

5.1 Tablas, vistas y secuencias . .
5.2 Funciones
. . . . . . . . . . .
5.3 Otros objetos . . . . . . . . . .

.
.
.

.
.
.

.
.
.

.
.
.

.
.
.

.
.
.

6 Organizar el acceso

6.1 Grupos y herencia . . . . . .
.
6.2 Vistas y funciones security definer .
6.3 Privilegios por defecto . . .
.
.
6.4

Seguridad a nivel de filas

.
. .

.
.

.
.

.
.

.

.

.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.

.
.
.
.

.
.
.

.
.
.
.

.
.
.

.
.
.
.

.
.
.

.
.
.
.

.
.
.

.
.
.
.

.
.
.

.
.
.
.

.
.
.

.
.
.
.

.
.
.

.
.
.
.

.
.
.

.
.
.
.

.
.
.

.
.
.
.

.
.
.

.
.
.
.

.
.
.

.
.
.
.

.
.
.

.
.
.
.

.
.
.

.
.
.
.

.
.
.

.
.
.
.

.
.
.

.
.
.
.

.
.
.

.
.
.
.

.
.
.

.
.
.
.

.
.
.

.
.
.
.

.
.
.

.
.
.
.

.
.
.

.
.
.
.

7 Agradecimientos

8 Anexos

8.1 Anexo 1: Lista de los privilegios .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Bibliografía

3

4

6

8

11

17
17
23
30

32
32
39
43
49

57

58
58

60

1 Introducción

PostgreSQL ofrece un poderoso sistema de roles para controlar la forma en que los usuarios
pueden acceder a los objetos en la base de datos. En el contexto de este artículo, “objetos”
son tablas, vistas, secuencias y funciones, es decir las partes de una base de datos con las
que interactúa un usuario normal, incluyendo usuarios técnicos compartidos por aplica-
ciones. Como veremos, antes de poder acceder a ese tipo de objetos, los usuarios necesitan
tener privilegios sobre los contenedores en los que se encuentran, en particular bases de
datos y esquemas.

En este artículo, se asume, por supuesto que el administrador de la base de datos (DBA)
tiene acceso superuser a un cluster PostgreSQL. El término “superuser” se refiere a un tipo
de usuario muy particular que no está sujeto a los mecanismos de control de acceso. Es
decir que tiene todos los derechos sobre todos los objetos en el clúster. A menudo este
usuario se llama “postgres”, siendo este el nombre estándar durante la instalación. La
instalación de PostgreSQL en sí queda fuera de los límites de este artículo.

Hablando sobre acceso a sistemas es imprescindible diferenciar entre autenticación y
autorización. Autenticación se refiere al proceso con el cual un usuario se identifica hacia
un sistema. Es decir que la cuestión es si el usuario que está intentando acceder el sistema
es realmente la persona (o en algunos casos la aplicación) quien afirma ser. Entre los
mecanismos habituales para implementar una autenticación los más conocidos son el uso
de un nombre de usuario y una palabra clave o de un certificado digital. La autenticación
es un proceso que siempre antecede la autorización.

Con autorización se entiende el conjunto de actividades que un usuario puede cumplir
en un sistema. Otro término habitual y a menudo utilizado como sinónimo de autorización
es lista de control de acceso (o su correspondiente en inglés access control list, ACL). En
el caso de una base de datos esto resulta ser, por ejemplo, el derecho o privilegio de leer o
modificar datos de una tabla.

Los ejemplos de código son producidos utilizando psql. psql es el cliente que es instalado
por defecto con el software del clúster PostgreSQL. Es posible, claro está, utilizar otros
clientes, como por ejemplo pgAdminIII o DbVisualizer. Dado que va a ser importante en
este contexto diferenciar los usuarios que ejecutan comandos, la línea de comando tiene el
formato:

username@database[=|-][#|>]

4

1 Introducción

Donde “=” indica la primera línea de un comando y “-” las siguientes. Los signos “#” y
“>” indican respectivamente si el usuario con el nombre username es un superuser o no.
Por ejemplo

postgres@admin=#
admin@uci=>

quiere decir que el usuario “postgres” está conectado con la base de datos “admin” como
superuser y que el usuario “admin” está conectado con la base de datos uci como usuario
normal. Cabe mencionar que usuarios pueden tener atributos que le otorguen algunas
capacidades especiales, sin ser superuser (p. ej. crear bases de datos o usuarios). Para
formatizar la línea de comando de esta manera, entre en psql los comandos reproducidos
aquí abajo.

\set PROMPT1 '%n@%/=%# '
\set PROMPT2 '%n@%/-%# '

5

2 Conceptos básicos y deniciones

PostgreSQL es un gestor de bases de datos relacionales organizado en diferentes niveles. El
nivel más externo es el clúster. En un servidor se pueden instalar varios clústeres del gestor,
siempre y cuando cada uno de ellos utilice un puerto diferente. El puerto por defecto es
5432 y es el mismo que asumiremos en este artículo. Un clúster contiene a su vez bases
de datos. Una base de datos (database) es una colección de esquemas (schema), quienes
a su vez, finalmente contienen los objetos que se conocen habitualmente en el contexto de
técnicas de almacenamiento de datos, tales como tablas (table), vistas (view), secuencias
(sequence) y así seguido. Es posible isolar cada usuario utilizando una base de datos por
cada usuario. Lo mismo se puede alcanzar utilizando un esquema por cada usuario dentro
de una sola base de datos. Cuáles de estas soluciones es la más apropiada depende de los
requerimientos que se imponen al diseño del sistema. Sistemas que tienen que compartir
datos optarán por poner estos datos en uno o más esquemas compartidos por los usuarios
mientras que aplicaciones totalmente independientes podrían estar isoladas en sus propias
bases de datos. Una base de datos recién creada en PostgreSQL siempre tiene un esquema
public1. Los privilegios por defecto del esquema public permiten a todos los usuarios de
crear objetos en él. Lo que a primera vista parece ser, o puede volverse en un problema de
seguridad, puede tener ciertas ventajas, como se verá más adelante.

En PostgreSQL los usuario existen a nivel de clúster. Es decir que un usuario no está
vinculado a una base de datos específica por defecto. El término utilizado en PostgreSQL
para usuarios es rol (ROLE). Los roles no son tan solo usuarios sino que pueden ser grupos
o ambos. En versiones anteriores a la 8.1, usuarios y grupos eran entidades distintas. Un
usuario es un rol con el atributo (LOGIN), es decir con el derecho de conectarse a una base
de datos. Cabe mencionar que con este atributo no se especifica para cuáles bases de datos
el atributo es válido. Una manera de especificar la base de datos es utilizando el fichero de
configuración pg_hba.conf (vease para detalles [RN11] y [Pos15a], Cap. 19.1). En la insta-
lación por defecto la configuración permite el acceso a todos y para todas las bases de datos
desde la misma compudadora en donde se encuentra el clúster (localhost). Este hecho no
tiene por qué ser negativo. Como veremos más adelante es posible controlar el acceso a

1De hecho nuevas bases de datos son creadas como copia de la base de datos estándar “template1”. Es decir
que si un administrador borró el esquema public de esta base de datos, todas las nuevas bases de datos
serán creadas sin este esquema.

6

2 Conceptos básicos y definiciones

una base de datos con los mecanismos de autorización. Estos últimos son particularmente
útiles en el caso en que un clúster es gestionado físicamente por una entidad externa (p.ej.
el departamento de informática de una empresa) y el responsable de las bases de datos
sólo tiene acceso al gestor mas no al sistema operativo2.

Autorización en PostgreSQL es, entonces, la posibilidad de otorgar privilegios sobre
objetos en un clúster o una base de datos a uno o más usuarios o grupos con el objetivo
de minimizar el impacto producido por errores de programación en aplicaciones o por
usuarios con objetivos dañinos3.

Antes de entrar en los detalles de la autorización en PostgreSQL cabe mencionar el as-
pecto de la propriedad sobre objetos. Todos los objetos en un clúster, incluyendo bases
de datos, tienen un proprietario. Por diseño el proprietario de un objeto es el usuario que
creó el objeto (aunque es posible modificar el proprietario posteriormente) y tiene todos los
privilegios que existen sobre este objeto. Usuarios que no son proprietarios de un objeto no
tienen ningún privilegio sobre estos, de no ser que el proprietario o un superuser les haya
otorgado alguno, ya sea directa o indirectamente por medio de un grupo o de PUBLIC.

2El centro de investigaciones coyunturales del instituto politécnico federal de Zurich (ETHZ), p.ej. tiene un
pequeño grupo de especialistas en informática para gestionar entre otros los datos de las encuestas. El
gestor está instalado en un servidor Linux al que este grupo no tiene acceso. El grupo tiene sin embargo
acceso al gestor por el puerto 5432 y tiene cuando menos un superuser.

3Por lo general una empresa tiene confianza en sus empleados. Existen sin embargo cantidades de ejemplos
de actividades criminales cometidas precisamente por empleados o por personas ajenas, cuyo acceso es
obtenido de usuarios legítimos por medio de ingeniería social. Básicamente los seres humanos suelen ser
el anillo más débil de la cadena de seguridad de un sistema informático.

7

3 Acceso a la base de datos

El acceso a un clúster de PostgreSQL siempre exige la definición de una base de datos.
Vimos en la sección antecedente que un clúster puede tener varias bases de datos. Apenas
instalado un clúster tiene tres bases de datos para uso interno del gestor, esto implica
que la primera tarea de cada DBA va a ser la creación de una base de datos. Dado que
al comienzo no existe todavía ninguna base de datos definida para el uso de usuarios,
podemos conectar a la base de datos estándar postgres. Si Usted no tiene todavía un
superuser para la gestión del clúster, tendrá que conectarse como el superuser postgres.
Es recomendable crear un sup