Revista Cubana de Ciencias Informáticas

ISSN: 1994-1536
rcci@uci.cu
Universidad de las Ciencias Informáticas
Cuba

Rubinos Carvajal, Alejandro Manuel; Nuevo León, Heidy Alina

Seguridad en bases de datos
Revista Cubana de Ciencias Informáticas, vol. 5, núm. 1, 2011
Universidad de las Ciencias Informáticas
Ciudad de la Habana, Cuba

Disponible en: http://www.redalyc.org/articulo.oa?id=378343671005

Cómo citar el artículo

Número completo
Sistema de Información Científica
Más información del artículo Red de Revistas Científicas de América Latina, el Caribe, España y Portugal
Página de la revista en redalyc.org Proyecto académico sin fines de lucro, desarrollado bajo la iniciativa de acceso abierto
Revista Cubana de Ciencias Informáticas (RCCI)
ISSN: 1994-1536 | RNPS: 0547
http://rcci.uci.cu | rcci@uci.cu

Tipo de artículo: Artículo de revisión

Temática: Sistema de bases de datos
Recibido: 23/3/2011 | Aceptado: 17/4/2011 | Publicado: 29/9/2011

Seguridad en bases de datos

Security Database
Alejandro Manuel Rubinos Carvajal 1*, Heidy Alina Nuevo León 2.

1* Universidad de Ciencias Informáticas, Cuba, amrubinos@uci.cu

2 Universidad de Ciencias Informáticas, Cuba, hanuevo@uci.cu

Resumen: Los sistemas de base de datos son de gran uso, el cual va desde el uso de bases de datos ligeras, bases de
datos en tiempo real (en algunas ocasiones obtenida a partir de la optimización de bases de datos relacionales) y bases
de datos relacionales con potentes gestores como aplicación proveedora del servicio. En el mundo del software libre
existen gran cantidad de gestores de bases de datos, entre los que se encuentran mysql, berkeley db, sqlite y
postgresql. Este último con gran número de seguidores y de personas de gran nivel en el mundo del desarrollo libre
que contribuyen a su propósito. El presente trabajo tiene como objetivo principal mostrar mediante una investigación
los diferentes mecanismos para realizar la configuración de la seguridad para el gestor de base de datos Postgres..
Palabras clave: bases de datos; gestores de bases de datos; postgresql; sofware libre; seguridad informática

Abstract: The database systems are of great use, which ranges from the use of light databases, real-time databases
(some times obtained from the optimization of relational databases) and relational databases with powerful managers
as application service provider. In the free software world there are plenty of database managers, among which are
mysql, berkeley db, sqlite and postgresql. Postgresql with a large number of fans and high-level people in the world
of free development that contribute to its purpose. This paper's main objective is to show, through an investigation of
different mechanisms to perform the security configuration for PostgreSQL database manager.
Keywords: database; database managers; postgresql; software free; informatic security

Grupo Editorial “Ediciones Futuro” 1

Universidad de las Ciencias Informáticas. La Habana, Cuba
rcci@uci.cu
Revista Cubana de Ciencias Informáticas (RCCI)
ISSN: 1994-1536 | RNPS: 0547
http://rcci.uci.cu | rcci@uci.cu

1. Introducción
En la actualidad el mundo de la informática se encuentra en constante desarrollo, a su vez lo hace también la rama de
esta ciencia que se dedica a encontrar errores, huecos en el diseño e implementación de las soluciones informáticos
ganando acceso al activo más importante de todo sistema, los recursos, comprometiendo en estos los principio de
fiabilidad, disponibilidad e integridad.

Es responsabilidad de los arquitectos, diseñadores, especialistas de negocio y desarrolladores de software mantener

una política de cero error, velando por cubrir todas las áreas que abarque su aplicación.
Es muy común observar como los especialistas que intervienen en la creación de un sistema informático vuelcan todo
su empeño en lograr un alto grado de seguridad en este, dejando de un lado (de manera inconsciente en ocasiones o
por confiar en exceso) la seguridad de las aplicaciones de las que la suya se alimenta, es el caso de las redes de
comunicación, aplicaciones de gestión con la cual se comparte la información y sistemas de gestión de base de datos

Se define una base de datos como una serie de datos organizados y relacionados entre sí, los cuales son recolectados y
explotados por los sistemas de información de una empresa o negocio en particular.
Cada base de datos se compone de una o más tablas, cada tabla tiene una o más columnas y filas. Las columnas
guardan una parte de la información sobre cada elemento, cada fila de la tabla conforma un registro.

Los sistemas de base de datos son de gran uso, el cual va desde el uso de bases de datos ligeras, bases de datos en
tiempo real (en algunas ocasiones obtenida a partir de la optimización de bases de datos relacionales) y bases de datos
relacionales con potentes gestores como aplicación proveedora del servicio.

En el mundo del software libre existen gran cantidad de gestores de bases de datos, entre los que se encuentran
MySQL, Berkeley DB, SQLite y postgresql. Este último con gran número de seguidores y de personas de gran nivel
en el mundo del desarrollo libre que contribuyen a su desarrollo.
El siguiente trabajo está orientado a brindar una guía, un acercamiento a los mecanismos de seguridad que brinda este
gestor de bases de datos que va desde la autenticación, control de acceso como a la seguridad en las comunicaciones
entre clientes y servidor por medio de mecanismos de cifrado y descifrado usando protocolo SSL.

Grupo Editorial “Ediciones Futuro” 2

Universidad de las Ciencias Informáticas. La Habana, Cuba
rcci@uci.cu
Revista Cubana de Ciencias Informáticas (RCCI)
ISSN: 1994-1536 | RNPS: 0547
http://rcci.uci.cu | rcci@uci.cu

2. Desarrollo.

2.1 Aspectos para la seguridad PostgreSQL.

Proteger los archivos de PostgreSQL.

Consiste en asegurar los archivos de datos: bases de datos y configuración, mediante lo permisos definidos en el
sistema operativo. La instalación de postgres garantiza dichos permisos.

Asegurar el acceso del cliente.

Su objetivo es determinar qué equipos están autorizados a acceder a sus datos. PostgreSQL utiliza el archivo
pg_hba.conf encontrado en /etc/postgresql/8.3/main/ para controlar el acceso de los clientes. Cuando una aplicación
cliente intenta conectarse a un servidor PostgreSQL le envía un nombre de usuario y de la base de datos.
Formato: [Tipo de conexión][database][usuario][IP][Netmask][Tipo de autenticación][opciones]
Tipos de conexiones.

 local: es utilizada para las conexiones usando sockets de dominio UNIX. Sin un registro de este tipo las
conexiones de socket de dominio Unix no se permiten.
 host: este registro coincide con los intentos de conexión realizados a través de TCP / IP con SSL o no.
 hostssl: este registro coincide con los intentos de conexión realizados a través de TCP / IP pero sólo
cuando se realiza la conexión con el cifrado SSL. Para hacer uso de esta opción debe estar el servidor
integrado con soporte SSL. Además SSL debe estar habilitado en el momento de inicio del servidor
activando el parámetro de configuración SSL.
 hostnossl: este tipo de registro es el opuesto al hostssl.
Tipos de autenticación.

 trust: es el método menos seguro de todos. Este método de autenticación es útil en las máquinas de un solo
usuario donde la identidad se comprueba al proporcionar una contraseña de autenticación al sistema
operativo. No se debe utilizar para autenticar en un intento de conexión en una red insegura.
 reject: es el método más seguro de todos. Cuando un cliente intenta conectarse desde un sistema de
autenticación por este método el intento de conexión se rechaza.
 password: cuando se utiliza autenticación de contraseña el cliente tiene que demostrar su identidad
mediante la presentación de una contraseña válida. Tiene como principal desventaja que la contraseña
viaja por la red en texto plano.
 crypt: se basa en la autenticación por contraseña encriptada. El servidor las encripta y las compara pero las
guarda en texto plano.
 md5: este método está basado en la autenticación por contraseña encriptada con md5. La contraseña es
salvada en el servidor con este formato.

Grupo Editorial “Ediciones Futuro” 3

Universidad de las Ciencias Informáticas. La Habana, Cuba
rcci@uci.cu
Revista Cubana de Ciencias Informáticas (RCCI)
ISSN: 1994-1536 | RNPS: 0547
http://rcci.uci.cu | rcci@uci.cu

Ejemplo de un fichero pg_hba.conf.

#Permite que todos los usuarios se conecten sin suministrar contraseña.
local all all trust
#Permite a los usuario de una red se conecten a la base de datos test si la
#contraseña suministrada es correcta.
host test 192.168.0.0 255.255.255.0 password
#Acceso por tcp/ip a la base de datos test001 como usuario test desde el
#ordenador con IP 10.0.0.100 y método de autenticación md5:
host test001 test 10.0.0.100 255.255.255.255 md5
#Esta misma entrada se podría escribir también con la máscara de red en
#notación CIDR:
host test001 test 10.0.0.100/32 md5
#Acceso por tcp/ip a la base de datos test001, como usuario test desde #todos
los ordenadores de la red #10.0.0.0 con máscara de red 255.255.255.0 #(254
ordenadores en total) y método de autenticación md5.
host test001 test 10.0.0.0 255.255.255.0 md5
#Esta misma entrada se podría escribir también con la máscara de red en
#notación CIDR.
host test001 test 10.0.0.0/24 md5
#Acceso por tcp/ip encriptado a todas las bases de datos como usuario test
#desde el ordenador con IP 10.0.0.100 y el ordenador 10.1.1.100 y método de
#autenticación md5.
hostssl all test 10.0.0.100 255.255.255.255 md5
hostssl all test 10.1.1.100 255.255.255.255 md5#Denegar el acceso a todos las
bases de datos al usuario test desde todos #los ordenadores de la red
10.0.0.0/24 y dar acceso al resto del mundo con #el método md5.
host all test 10.0.0.0/24 reject
host all all 0.0.0.0/0 md5

De esta forma se puede combinar todas las combinaciones que ofrece este fichero de configuración.

Grupo Editorial “Ediciones Futuro” 4

Universidad de las Ciencias Informáticas. La Habana, Cuba
rcci@uci.cu
Revista Cubana de Ciencias Informáticas (RCCI)
ISSN: 1994-1536 | RNPS: 0547
http://rcci.uci.cu | rcci@uci.cu

Concesión o denegación de acceso a las tablas específicas y usuarios específicos.

Nombre Aplicado a: Descripción:
Controla el derecho de seleccionar cualquier
SELECT Tablas, vistas, secuencias. columna de una tabla o vista. También controla
el derecho de interrogar a una secuencia.
Controla el derecho de insertar nuevos valores
INSERT Tablas, vistas, secuencias.
en una tabla, vista o secuencia.
Controla el derecho de actualizar valores en una
UPDATE Tablas, vistas, secuencias.
tabla, vista o secuencia.
Controla el derecho de eliminar valores en una
DELETE Tablas, vistas, secuencias.
tabla, vista o secuencia.
Controla el derecho de crear nuevas reglas en
RULE Tablas, vistas, secuencias.
una tabla o vista.
Controla el derecho de relacionar dos tablas
REFERENCES Tablas.
mediante una llave foránea.
Controla el derecho de crear disparadores en
TRIGGER Tablas.
una tabla.
Controla el derecho de crear nuevos esquemas
Bases de datos, espacios de tablas, dentro de una base de datos, nuevos objetos
CREATE
esquemas. dentro de un esquema o nuevos índices (o
tablas) dentro de un espacio de tablas.
Controla el derecho a crear tablas temporales
TEMPORARY Bases de datos.
dentro de una base de datos.
EXECUTE Funciones. Controla el derecho de ejecutar una función.
Controles enumeración de objetos dentro de un
USAGE Esquemas, lenguajes. esquema o el derecho a crear nuevas funciones
con un determinado lenguaje de procedimiento.
Tabla 1: Privilegios de una tabla

El propietario de una tabla tiene todos los privilegios de seleccionar, insertar, actualizar o eliminar filas dentro de esa
tabla, a menos que otorgan privilegios a otro usuario, usted es la única persona que puede tener acceso a esa tabla.
Se puede transferir la propiedad de una tabla a otro usuario utilizando el comando ALTER TABLE tabla OWNER TO
nuevo Propietario. Es necesario ser un superusuario PostgreSQL para transferir dicha propiedad.

Si se quiere que otros usuarios tengan acceso a las tablas es necesario conceder una o más privilegios. Por ejemplo si
desea que un usuario pueda seleccionar datos de una tabla se utiliza el siguiente comando:

GRANT SELECT ON tabla TO usuario;

Si se cambia de opinión puede negar los privilegios antes concedidos con el comando REVOKE:

REVOKE SELECT ON tabla FROM usuario;

Si se quiere asignar todos los privilegios:

GRANT ALL PRIVILEGES ON tabla TO usuario;

Grupo Editorial “Ediciones Futuro” 5

Universidad de las Ciencias Informáticas. La Habana, Cuba
rcci@uci.cu
Revista Cubana de Ciencias Informáticas (RCCI)
ISSN: 1994-1536 | RNPS: 0547
http://rcci.uci.cu | rcci@uci.cu

Para listar los privilegios de una tabla se utiliza el comando \z tabla.

Código Privilegio
a INSERT
r SELECT
w UPDATE
d DELETE
R RULES
x REFERENCES
t TRIGGERS
X EXECUTE
U USAGE
C CREATE
T TEMPORARY
* GRANT (puede conferir privilegios a otros usuarios)
arwdRxt Todos

Tabla 2: Códigos relacionados a los privilegios.

Administración de usuarios.
Para crear un usuario se utiliza el comando CREATE USER.

CREATE USER userName

[[WITH] option ]...

option := SYSID user-id-number
| [NO]CREATEDB
| [NO]CREATEUSER
| [NO]CREATEROLE
| IN GROUP groupname [, ...]
| [[UN]ENCRYPTED ] PASSWORD 'password'
| VALID UNTIL 'expiration'
SYSID:

Mediante esta opción se le puede asignar un id específico a un usuario.

Grupo Editorial “Ediciones Futuro” 6

Universidad de las Ciencias Informáticas. La Habana, Cuba
rcci@uci.cu
Revista Cubana de Ciencias Informáticas (RCCI)
ISSN: 1994-1536 | RNPS: 0547
http://rcci.uci.cu | rcci@uci.cu

CREATEDB / NOCREATEDB:

Permite al usuario crear nuevas bases de datos. Si utiliza NOCREATEDB se denega al usuario esta posibilidad. Si no
se especifica NOCREATEDB es la opción por defecto.

CREATEUSER / NOCREATEUSER:

Permite al usuario crear nuevos usuarios. Si utiliza NOCREATEUSER se denega al usuario esta posibilidad. Si no se
especifica NOCREATEUSER es la opción por defecto.

CREATEROLE / NOCREATEROLE:

Permite al usuario crear nuevos role. Si se utiliza NOCREATEROLE se deniega al usuario esta posibilidad. Si no se
especifica NOCREATEROLE es la opción por defecto.
groupname:
Nombre de un grupo ya existente en el que se desea insertar al usuario como un nuevo miembro.
Varios nombres de grupo pueden ser enumerados.

passsword:
Las dos últimas opciones son un tanto similares. Puede crear una contraseña inicial para un nuevo
usuario mediante la inclusión de la contraseña (encriptada o no). Si no se especifica una contraseña
cuando se crea un nuevo usuario y se está utilizando contraseñas para autenticar las conexiones de
clientes el usuario no podrá conectarse. Si se decide crear una contraseña encriptada (opción por
defecto) se almacenará de forma cifrada en la tabla de sistema pg_shadow.

expiration:
Define una fecha de caducidad de la contraseña. Si se omite esta opción la contraseña nunca caduca.

Ejemplo:

CREATE USER miriam PASSWORD 'jw8s0F4' VALID UNTIL '2005-01-01 12:50:45';

Para eliminar usuario se utiliza el comando DROP.

DROP USER user;

Los usuarios son almacenados en la tabla pg_shadow.

Administración de grupos.

Grupo Editorial “Ediciones Futuro” 7

Universidad de las Ciencias Informáticas. La Habana, Cuba
rcci@uci.cu
Revista Cubana de Ciencias Informáticas (RCCI)
ISSN: 1994-1536 | RNPS: 0547
http://rcci.uci.cu | rcci@uci.cu

Se pueden definir grupos de usuarios para una mejor administración de los usuarios. Cada grupo puede incluir a cero
o más usuarios. Cada usuario puede pertenecer a uno o más grupos. Al conceder o revocar privilegios de un objeto se
puede identificar a un usuario específico o un grupo de usuarios.

PUBLICA es un gropo virtual. No se puede agregar o eliminar miembros pero se puede asociar con privilegios
PUBLICA. Cada usuario es automáticamente un miembro de este grupo. Para crear nuevos grupos se utiliza la
sentencia CREATE GROUP.
CREATE GROUP group-name [[WITH] option [...]]
option := SYSID group-id-number
| USER username, ...
SYSID:

Mediante esta opción se le puede asignar un id específico a un grupo.

USER:
Usuarios que pertenecerán al nuevo grupo.

Ejemplo:

CREATE GROUP supervisor USER postgres, user1, user2;

Para agregar o eliminar miembros de un grupo se utiliza el comando ALTER GRUPO.

ALTER GROUP group-name {ADD|DROP} USER user-name [, ...]

ALTER GROUP supervisor ADD USER postgres;
ALTER GROUP supervisor DROP USER postgres;

Para eliminar grupos se utiliza el comando DROP.

DROP GROUP groupName;

2.2 Configuración propuesta.

Cambiar el puerto por defecto.
Editar el fichero /etc/postgresql/8.3/main/postgresql.conf y cambiar el puerto en la sección CONNECTIONS AND
AUTHENTICATION.

Actualizar los equipos que estarán autorizados a acceder a la base de datos.

Editar el fichero /etc/postgresql/8.3/main/pg_hba.conf e insertar las siguientes líneas en la sesión IPv4 local
connections.

Grupo Editorial “Ediciones Futuro” 8

Universidad de las Ciencias Informáticas. La Habana, Cuba
rcci@uci.cu
Revista Cubana de Ciencias Informáticas (RCCI)
ISSN: 1994-1536 | RNPS: 0547
http://rcci.uci.cu | rcci@uci.cu

# IPv4 local connections:

hostssl db_security postgres 0.0.0.0/0 md5
hostssl db_security scada 0.0.0.0/0 md5

De esta forma se permitirá el acceso por tcp/ip encriptado a la bases de datos db_security como usuario postgres o
scada desde cualquier ordenador y método de autenticación md5. Se recomienda cambiar la subred con el objetivo de
filtrar los posibles hosts que se puedan conectar al gestor.

Configuración de PostgreSQL para habilitar la conexión mediante SSL.

Con el cifrado del tráfico entre los clientes y el servidor evitamos que alguien pueda interceptar el tráfico de red y
conseguir los datos que viajan por la conexión. PostgreSQL soporta nativamente el uso de conexiones SSL para cifrar
las comunicaciones, el único requerimiento es tener OpenSSL instalado en el servidor.

# apt-get install openssl

Instalando la infraestructura necesaria para ser una autoridad de certificación(CA) local.

Creamos como root el directorio que albergará la infraestructura CA y los subdirectorios necesarios dentro de estas
carpetas:

# mkdir -m 0755 \
/etc/CA_local \
/etc/CA_local/private \
/etc/CA_local/certs \
/etc/CA_local/newcerts \
/etc/CA_local/crl

Copiamos el fichero de configuración global de openssl (/etc/ssl/openssl.cnf) a nuestro directorio CA_local.

# cp /etc/ssl/openssl.cnf /etc/CA_local/openssl.local.cnf
# chmod 0600 /etc/CA_local/openssl.local.cnf

Grupo Editorial “Ediciones Futuro” 9

Universidad de las Ciencias Informáticas. La Habana, Cuba
rcci@uci.cu
Revista Cubana de Ciencias Informáticas (RCCI)
ISSN: 1994-1536 | RNPS: 0547
http://rcci.uci.cu | rcci@uci.cu

Actualizamos el fichero /etc/CA_local/openssl.local.cnf. En la sección [CA_default] cambiamos los parámetros dir,

certificate y private_key.

dir = /etc/CA_local # Where everything is kept

certificate = $dir/certs/local_ca.crt # The CA certificate
private_key = $dir/private/local_ca.key # The private key

Creamos tres ficheros extras de la siguiente manera:

# touch /etc/CA_local/index.txt
# echo '01' > /etc/CA_local/serial
# echo '01' > /etc/CA_local/crlnumber

Generación de certificado y llave CA para firmar certificados utilizados en el sistema.

Crear un certificado CA que utilizaremos para firmar los certificados que usemos localmente en nuestro sistema.

# cd /etc/CA_local/
# openssl req -config openssl.local.cnf -new -x509 -extensions v3_ca \
-keyout private/local_ca.key -out certs/local_ca.crt -days 1825

Este último comando creará un certificado CA autofirmado con una validez de 5 años. Tenemos que definir una
contraseña para la llave privada CA (no olvidar esta contraseña ya que se necesitará cada vez que usemos el
certificado local CA) y rellenar algunos parámetros para el sistema.

Una vez realizado estos pasos se habrán creado dos ficheros en el sistema:

- /etc/CA_local/certs/local_ca.crt: Certificado CA local. Se puede distribuir públicamente y todo el mundo

puede acceder al mismo sin problemas de seguridad.

- /etc/CA_local/private/local_ca.key: Llave CA privada. Se tiene que restringir el acceso a la misma ( chmod

0400 /etc/CA_local/private/local_ca.key) y no se puede distribuir públicamente.

Grupo Editorial “Ediciones Futuro” 1

Universidad de las Ciencias Informáticas. La Habana, Cuba 0
rcci@uci.cu
Revista Cubana de Ciencias Informáticas (RCCI)
ISSN: 1994-1536 | RNPS: 0547
http://rcci.uci.cu | rcci@uci.cu

El fichero CRL (Certificate Revocation List) con la lista de certificados revocados por este CA se crea de la siguiente
forma:

openssl ca -config openssl.local.cnf -keyfile private/local_ca.key \

-cert certs/local_ca.crt -gencrl -out crl/local_ca.crl

Y se puede verificar:

openssl crl -in crl/local_ca.crl -text -noout

Creación de una solicitud de certificado para el servidor.

Tenemos que generar una solicitud de certificado (server.csr) para generar un certificado que se pueda usar en nuestro
servidor. Para ello podemos utilizar los siguientes comandos:

# cd /etc/CA_local/
# openssl req -config openssl.local.cnf -new -nodes \
-keyout private/nuevoCertificado.key \
-out nuevoCertificado.csr -days 730

Con esto generamos la solicitud de certificado con una validez de 2 años, después de rellenar algunos parámetros de
nuestro sistema. Los parámetros a rellenar obligatoriamente son "Common Name" y "Email Address". "Common
Name" debería de tener el nombre de la máquina que va a estar utilizando el certificado y "Email Address" es la
dirección de contacto de vuestro sistema.
No es necesario introducir nada en los parámetros "challenge password" y "optional company name" del final. Hemos
utilizado el parámetro -nodes para no tener que proteger nuestra llave privada con una contraseña y no tener que
escribir una contraseña cada vez que arranquemos un servicio que use el certificado. Por ello es muy importante no
perder ó publicar el fichero con la llave privada.

Grupo Editorial “Ediciones Futuro” 1

Universidad de las Ciencias Informáticas. La Habana, Cuba 1
rcci@uci.cu
Revista Cubana de Ciencias Informáticas (RCCI)
ISSN: 1994-1536 | RNPS: 0547
http://rcci.uci.cu | rcci@uci.cu

Firma de solicitud de certificado con el CA para la generación del certificado final.

Una vez que tenemos la solicitud de certificado (server.csr), vamos a firmarla con nuestro certificado CA. Para ello
utilizamos este comando:

# cd /etc/CA_local/
# openssl ca -config openssl.local.cnf -policy policy_anything \
-days 730 -out certs/nuevoCertificado.crt \
-infiles nuevoCertificado.csr

Tendremos que utilizar la contraseña que usamos cuando creamos el certificado CA para terminar de firmar nuestro
certificado.

Aseguramos mejor la clave privada del certificado. Este fichero es privado y no se debe de distribuir:

# chown root:root /etc/CA_local/private/nuevoCertificado.key

# chmod 0400 /etc/CA_local/private/nuevoCertificado.key

Podemos ver la información contenida en el certificado con este comando:

# cd /etc/CA_local/
# openssl x509 -in certs/nuevoCertificado.crt -noout -text

Y comprobar y verificar el certificado con el siguiente comando:

# cd /etc/CA_local/
# openssl verify -purpose sslserver -CAfile /etc/CA_local/certs/local_ca.crt \
/etc/CA_local/certs/nuevoCertificado.crt

El fichero de solicitud de certificado ya no lo necesitamos y lo podemos borrar:

# rm /etc/CA_local/nuevoCertificado.csr

Al final de todo el proceso tendremos los siguientes ficheros en el directorio /etc/CA_local:

Grupo Editorial “Ediciones Futuro” 1

Universidad de las Ciencias Informáticas. La Habana, Cuba 2
rcci@uci.cu
Revista Cubana de Ciencias Informáticas (RCCI)
ISSN: 1994-1536 | RNPS: 0547
http://rcci.uci.cu | rcci@uci.cu

 /etc/CA_local/certs/local_ca.crt: Certificado CA local que puedes utilizar para firmar otros certificados.

 /etc/CA_local/certs/nuevoCertificado.crt: Certificado firmado por el CA local que vamos a usar.

 /etc/CA_local/private/local_ca.key: Llave privada del certificado CA local.

 /etc/CA_local/private/nuevoCertificado.key: Llave privada del certificado firmado por el CA local..

 /etc/CA_local/crl/local_ca.crl: Fichero CRL (Certificate Revocation List) con la lista de certificados

revocados.

Configuración de PostgreSQL para usar SSL.

Copiamos los ficheros /etc/CA_local/certs/nuevoCertificado.crt, /etc/CA_local/private/nuevoCertificado.key,
/etc/CA_local/certs/local_ca.crt y /etc/CA_local/crl/local_ca.crl al directorio de datos de nuestra instalación
PostgreSQL.
Actualizamos el fichero /etc/postgresql/8.3/main/postgresql.conf . Tenemos que cambiar el valor del parámetro ssl.

ssl = on

Reiniciamos Postgres.

# /etc/init.d/postgresql-8.3 restart

Si durante la autenticación se muestra la siguiente línea nos indica que la conexión está cifrada vía SSL.

conexión SSL (cifrado: DHE-RSA-AES256-SHA, bits: 256)

Creación de un usuario scada.

PostgreSQL crea por defecto a un superusuario llamado postgres que permitirá el acceso del módulo de Seguridad.
Todos los demás usuarios pueden ser creados por él. Para permitir el acceso de los demás módulos que necesiten de la
base de datos de Seguridad se creará un usuario scada con algunos permisos restringidos.

Nos autenticamos como usuario postgres en un terminal y ejecutamos la siguiente consulta con la contraseña y fecha
de expiración deseada:

Grupo Editorial “Ediciones Futuro” 1

Universidad de las Ciencias Informáticas. La Habana, Cuba 3
rcci@uci.cu
Revista Cubana de Ciencias Informáticas (RCCI)
ISSN: 1994-1536 | RNPS: 0547
http://rcci.uci.cu | rcci@uci.cu

db_security=# CREATE USER scada PASSWORD 'postgres' VALID UNTIL '2012-01-01

12:00:00';

El usuario SCADA no tendrá ningún tipo de permisos inicialmente. (Ver Actualizar permisos).

Actualizar permisos.
Se le dará permisos de tipo SELECT para todas las tablas al usuario scada.

db_security=# GRANT SELECT ON tlocalusers TO scada;

db_security=# GRANT SELECT ON toperationalgroup TO scada;
db_security=# GRANT SELECT ON tpasswords TO scada;
db_security=# GRANT SELECT ON tprofiles TO scada;
db_security=# GRANT SELECT ON tprofilevsoperational TO scada;
db_security=# GRANT SELECT ON tresource TO scada;
db_security=# GRANT SELECT ON tsecurityalarm TO scada;
db_security=# GRANT SELECT ON tsecuritylog TO scada;
db_security=# GRANT SELECT ON tsecuritylogmonth TO scada;
db_security=# GRANT SELECT ON tsecuritylogweek TO scada;
db_security=# GRANT SELECT ON tsecuritylogyear TO scada;
db_security=# GRANT SELECT ON tuser TO scada;
db_security=# GRANT SELECT ON tuservsprofiles TO scada;

Culminando la configuración.

Para que los cambios realizados tengan efecto es necesario reiniciar los servicios de postgres.

# /etc/init.d/postgresql-8.3 restart

Autenticación de usuarios mediante certificados SSL.

A partir de la versión 8.4.0 de PostgreSQL también se pueden utilizar certificados digitales para autentificar a los
usuarios que se quieran conectar con el servidor.

Este tipo de autenticación se activa usando el método 'cert' en la opción método cuando se define el acceso en
pg_hba.conf. Si se usa este método de autenticación no se necesitará escribir ninguna clave de acceso pero se debe de
proveer un certificado valido.
El atributo CN (lo que se define en 'Common Name (eg, YOUR name):') del certificado es el atributo que se
comprueba para ver si corresponde con el usuario con el que se intenta conectar.

Grupo Editorial “Ediciones Futuro” 1

Universidad de las Ciencias Informáticas. La Habana, Cuba 4
rcci@uci.cu
Revista Cubana de Ciencias Informáticas (RCCI)
ISSN: 1994-1536 | RNPS: 0547
http://rcci.uci.cu | rcci@uci.cu

Lo primero que tenemos que hacer es crear un certificado para nuestro usuario ('Common Name (eg, YOUR name):
postgres') y firmarlo con nuestro certificado CA local. A continuación copiamos este certificado y la llave privada a
/home/postgresql/.postgresql/postgresql.crt y /home/postgresql/.postgresql/postgresql.key en el ordenador cliente.

Después es necesario que actualizar el fichero /etc/postgresql/8.3/main/pg_hba.conf con una línea similar a esta:

hostssl all postgres 127.0.0.1/32 cert

Y por último reiniciamos Postgres.

# /etc/init.d/postgresql-8.3 restart

Si no tuviésemos el certificado correcto instalado el sistema nos daría un error similar al que se obtiene cuando la
autenticación con certificado del ordenador cliente falla.

3. Conclusiones
Una vez alcanzado los objetivos trazados para esta investigación se puede arribar a las siguientes conclusiones:

 Se logró configurar la seguridad para el gestor de base de datos Postgres..

 Se dotó de un conocimiento a todos los lectores para la configuración del módulo de seguridad de
postgres.

 Desarrollo de una guía para usuarios de configuración de la seguridad en postgres.

4. Bibliografía
Alarcón Medina, José Manuel. Administración GGBD PostgreSQLseptiembre – octubre 2007. [Consultado: marzo
2010].

Alvarez, Sara. Sistema de gestores de base de datos. [En línea]. Desarrolloweb. [Consultado: 9 de marzo de 2010.]
Disponible en Internet: <http://www.desarrolloweb.com/articulos/sistemas-gestores-bases-datos.html>
Clasificación de Respaldos [En Línea] 2005 [Consultado: 2 diciembre 2009] Disponible en Internet:
http://www.osmosislatina.com/soporte/respaldos.htm
De la HorraDiaz, Abdelaziz. Desarrollo del subsistema de comunicación para el Módulo Base de Datos de Históricos
del proyecto SCADA Nacional. [Consultado: Enero de 2010].
Manual básico de cron [En Línea] [Consultado: 15 de febrero 2010] Disponible en Internet:
http://www.linuxtotal.com.mx/index.php?cont=info_admon_006

Grupo Editorial “Ediciones Futuro” 1

Universidad de las Ciencias Informáticas. La Habana, Cuba 5
rcci@uci.cu
Revista Cubana de Ciencias Informáticas (RCCI)
ISSN: 1994-1536 | RNPS: 0547
http://rcci.uci.cu | rcci@uci.cu

pg_restore [En Línea] [Consultado: 2 de febrero 2010] Disponible en Internet:

http://www.ibiblio.org/pub/linux/docs/LuCaS/Manuales-LuCAS/blfs-es/blfs-es-5.0/content/postgresql.html

Portal en español sobre PostgreSQL. (22 de 03 de 2009). [Consultado: Enero de 2010], Disponible en
Internet:http://www.postgresql-es.org
PostgreSQL. [Consultado: Enero de 2010],Disponible en Internet:http://www.postgresql.org

PostgreSQL en Castellano[En Línea] 2008 [Consultado: 24 enero 2010] Disponible en Internet:

http://wiki.postgresql.org/wiki/FAQ/es

Grupo Editorial “Ediciones Futuro” 1

Universidad de las Ciencias Informáticas. La Habana, Cuba 6
rcci@uci.cu