Seguridad en bases de datos

La seguridad de una base de datos se refiere a la protección de la información

contra el acceso por parte de las personas no autorizadas y contra su indebida
destrucción o alteración.

Siempre que se analicen asuntos relativos a la seguridad de una base de datos

es de interés tener en cuenta las siguientes consideraciones:

 La base de datos debe ser protegida contra el fuego, el robo y otras

formas de destrucción.

 Los datos deben ser reconstruibles, porque por muchas precauciones que
se tomen, siempre pueden ocurrir accidentes.

 Los datos deben poder ser sometidos a procesos de auditoría. La falta de

auditorías en los sistemas de computación ha permitido la comisión de
grandes delitos.

 El sistema debe diseñarse a prueba de intromisiones. Ningún sistema

puede evitar de manera absoluta las intromisiones malintencionadas, pero
es posible hacer que resulte muy difícil eludir los controles. El sistema
debe tener capacidad para verificar que sus acciones han sido
autorizadas. Las acciones de los usuarios deben ser supervisadas, de
modo tal que pueda descubrirse cualquier acción indebida o errónea.

En los servidores de bases de datos se tratan 2 niveles fundamentales de

seguridad:
 Seguridad de acceso al sistema.
 Seguridad de los datos.

Seguridad de acceso al sistema en Postgres

Es importante poder definir desde qué equipos se pueden conectar los usuarios
a nuestras bases de datos, así como poder definir qué usuarios y a qué bases
de datos se pueden conectar. La configuración de este nivel de seguridad se
realiza en los ficheros pg_hba.conf (hba es acrónimo de Host Based
Authentication), pg_ident.conf y postgresql.conf.

Su situación exacta dependerá del sistema operativo en cuestión, puede

encontrarse en una de estas dos rutas:

 /var/lib/pgsql/data/pg_hba.conf
 /etc/postgresql/main/pg_hba.conf
Fichero postgres.conf

Parámetros fundamentales de configuración de las conexiones:

 listen_addresses (string): Especifica las direcciones TCP / IP por las

cuáles el servidor va a escuchar las conexiones desde aplicaciones
cliente. El valor toma la forma de una lista separada por comas de
nombres de host y/o direcciones IP numéricas. La entrada especial *
corresponde a todas las interfaces disponibles. Si la lista está vacía, sólo
se pueden utilizar los sockets de dominio Unix para conectarse a él. El
valor predeterminado es localhost, lo que implica que solo se puedan
establecer conexiones locales. Mientras que la autenticación de clientes
permite un control preciso sobre quién puede acceder al servidor,
listen_addresses controla qué interfaces aceptarán los intentos de
conexión, lo cual ayuda a prevenir reiteradas peticiones de conexión con
fines maliciosos en redes inseguras.
Ejemplo: 'localhost, 10.8.31.150, 10.31.7.7'

 port (integer): Especifica el puerto TCP por el cual escucha el servidor,

por defecto es el 5432. El número de puerto es el mismo para todas las
direcciones IP por las que escucha el servidor.

 max_connections (integer): Determina el número máximo permitido de

conexiones simultáneas al servidor de base de datos. El valor
predeterminado es típicamente de 100 conexiones, pero podría ser
menos si la configuración del kernel no soportara esa cantidad.

Parámetros fundamentales de configuración del proceso de autenticación:

 authentication_timeout (integer): Establece el tiempo máximo para

completar la autenticación del cliente, en cuestión de segundos. Si un
posible cliente no ha completado el protocolo de autenticación en ese
tiempo, el servidor cierra la conexión. Esto evita que los clientes colgados
se queden ocupando una conexión de forma indefinida. El valor
predeterminado es un minuto (1m). Este parámetro sólo se puede
establecer en el archivo postgresql.conf o en la línea de comandos del
servidor.

 SSL (boolean): Especifica si se permiten conexiones SSL. El valor

predeterminado es off. Comunicación SSL sólo es posible con conexiones
TCP / IP.

SSL son las siglas en inglés de Secure Socket Layer (capa de conexión
segura). Es un protocolo criptográfico empleado para realizar conexiones
seguras entre un cliente y un servidor. De forma básica, una conexión
usando el protocolo SSL funciona de la siguiente forma: El cliente y el
 servidor entran en un proceso de negociación, conocido como handshake
(apretón de manos). Este proceso sirve para que se establezca varios
parámetros para realizar la conexión de forma segura. Una vez terminada
la negociación, la conexión segura es establecida. Usando llaves
preestablecidas, se codifica y descodifica todo lo que sea enviado hasta
que la conexión se cierre. La clave se transmite en texto plano si la
conexión no es SSL.

 password_encryption (boolean): Cuando se especifica una contraseña

en CREATE USER o ALTER USER sin escribir: cifrado o no cifrado, este
parámetro determina si la contraseña debe ser encriptada. El valor
predeterminado es on (cifrar la contraseña).

Fichero pg_hba.conf

Para restringir el acceso por la red, Postgres define una serie de parámetros en
el archivo pg_hba.conf. Se debe definir un registro (fila) para cada rango IP al
que se le vaya a permitir conectarse al servidor. En la columna TYPE se
especifica el tipo de registro, que puede ser LOCAL, HOST, HOSTSSL o
HOSTNOSSL. En la columna DATABASE se especifica a qué bases de datos
del servidor se va a dar acceso. En la columna USER se especifica a qué
usuarios del servidor se le va a permitir la conexión remota. En la columna
CIDR-ADREESS se especifica el rango IP al que se le va a dar el acceso y la
columna METHOD especifica el método de autenticación que se va a utilizar.

TYPE
LOCAL: Se define para las conexiones que se realizarán desde el propio
servidor.
HOST: Se utilizará para conexiones remotas no-SSL y SSL.
HOSTSSL: Sólo se utilizarán para conexiones remotas SSL.
HOSTNOSSL: Sólo se utilizarán para las conexiones remotas no-SSL.

DATABASE
ALL: se permite la conexión a cualquier base de datos.
SAMEUSER: solo a bases de datos que su nombre sea el mismo que el usuario
que se conecta.
SAMEROLE: solo a bases de datos que su nombre sea el mismo que el rol que
se conecta.
nombd1, nombd2,…: se permite la conexión a cualquiera de las bases de datos
de la lista.
@fichero: se permite la conexión a las bases de datos incluidas en el fichero,
que debe estar en el mismo directorio que pg_hba.conf

USER:
ALL: se permite la conexión de cualquier rol.
role1, [+] role2,…: se permite la conexión de los roles de la lista y además se
permite la conexión de cualquier rol que sea miembro de role2.
@fichero: se permite la conexión de los roles incluidos en el fichero, que debe
estar en el mismo directorio que pg_hba.conf.

CIDR-ADREESS
Puede utilizarse la dirección CIDR o la combinación dirección_IP máscara_IP. A
continuación se listan algunos ejemplos:

 192.168.200.0/24 ó 192.168.200.0 255.255.255.0: se pueden conectar

todas las IPs de la red 192.168.200
 192.168.0.0/16 ó 192.168.0.0 255.255.0.0: todos las IPs de la red 192.168
 192.168.200.85/32: solo esa IP
 0.0.0.0/0 ó 0.0.0.0 0.0.0.0.: cualquier IP

METHOD
TRUST: deja todos los accesos sin necesidad de autenticarse (sólo
recomendable para conexiones desde el equipo local).
REJECT: conexión rechazada sin condiciones.
PASSWORD: se solicita palabra de paso sin encriptar, las palabras de paso se
almacenan en la tabla pg_authid y pueden estar cifradas o no según como se
creara el rol.
MD5: palabra de paso con el método de encriptación md5, y se almacena
también con este método. Es el método recomendado por PostgreSQL. En
versiones de PostgresSQL anteriores a la 7.2 a este método se le conoce como
crypt.
krb5: se utiliza el protocolo Kerberos versión 5 para autentificar al usuario. Este
método se puede utilizar sólo para conexiones con TCP/IP.
ident: utiliza el usuario del sistema desde el que se está intentado conectar.

Ejemplos usando método ident:

Ejemplo 1:
(pg_hba.conf)
# TYPE DATABASE USER CIDR-ADDRESS METHOD
host all all 127.0.0.1/32 ident sameuser
***En caso de sameuser, no se necesita el archivo pg_ident.conf, pues coincide
el nombre de usuario en el sistema operativo con el nombre de usuario en el
servidor. En este caso se indica que cualquier usuario perteneciente al
ordenador con dirección IP 127.0.0.1, cuyo nombre coincida con un usuario del
servidor de bases de datos, puede acceder a las bases de datos
correspondientes.
Ejemplo 2:
(pg_hba.conf)
# TYPE DATABASE USER CIDR-ADDRESS METHOD
host all all 192.168.0.0/16 ident omicron

En este caso se indica que cualquier usuario con identidad “omicron”

perteneciente a la red con dirección IP 192.168.0.0 y que en el archivo pg_ident
tenga un registro identificado en el campo MAPNAME con “omicron” pueda
acceder a las bases de datos correspondientes. En este caso se requiere tener
configurado el archivo pg_ident.conf.

Fichero pg_ident.conf

Este archivo configura la autentificación de los usuarios si es que en el archivo

pg_hba.conf se tiene un registro cuyo método de autentificación sea de tipo
“ident”.En el archivo pg_ident.conf se verifica si el usuario o usuarios que se
identifican en el archivo pg_hba.conf con el método “ident” tienen una
correspondencia entre el nombre de usuario del sistema operativo y el nombre
del usuario de la base de datos a la que se quiere acceder. Los registros en este
archivo están estructurados de la siguiente manera:

# MAPNAME IDENT-USERNAME PG-USERNAME

Donde en el campo MAPNAME se coloca el “nombre” de la identidad con la que

en el archivo pg_hba.conf se identifica al usuario, en el campo IDENT-
USERNAME se coloca el nombre del usuario que se tiene en el sistema
operativo y en el campo PG-USERNAME se pone el nombre del usuario de
PostgreSQL correspondiente. Por ejemplo, si en el archivo pg_hba.conf se tiene
la línea que aparece en el Ejemplo 2, en el archivo pg_ident.conf se tendría la
siguiente línea:

# MAPNAME IDENT-USERNAME PG-USERNAME

omicron usuarioso mauricio

En esta línea se especifica que en la entrada “omicron” se debe validar un

usuario cuyo nombre en el sistema operativo es “usuarioso”, pero que su
correspondencia como usuario de PostgreSQL es “mauricio”.

Seguridad de los datos

Cuando se crea una BD la seguridad de los datos es primordial. En particular

cuando se permite un acceso sencillo como el caso de SQL, es importante
restringir estos accesos a personal autorizado. La seguridad de los datos en
general es responsabilidad del SGBD que se esté usando. Existen un grupo de
sentencias SQL que se utilizan para especificar restricciones de seguridad.
El esquema de seguridad de SQL se basa en tres conceptos importantes:

 Los usuarios, que son los actores de la BD. Cada vez que el SGBD hace
una operación sobre la BD la hace a cuenta de un usuario determinado.
El SGBD debe permitir la operación dependiendo de cuál usuario está
efectuando esta operación.
 Los objetos de la BD, que son los elementos a los cuales se puede
aplicar la protección. La seguridad se aplica generalmente a tablas y
vistas, pero en dependencia del SGBD pueden ser protegidos otros
objetos (disparadores, formularios, etc).
 Los privilegios, son las acciones que un usuario tiene permitido efectuar
o no sobre los objetos de una BD. Las acciones más comunes que realiza
un usuario sobre un objeto son las de SELECT, INSERT, DELETE y
UPDATE.

 Identificadores de usuario

Cada usuario de una base de datos basada en SQL tiene asignado un id-
usuario, generalmente un nombre breve que identifica al usuario dentro del
SGBD. Toda sentencia SQL ejecutada por el SGBD se hace a cuenta de un id-
usuario específico. En general estos identificadores son asignados por el
administrador del sistema. En el estándar de SQL los identificadores de usuario
son nombres de hasta 18 caracteres. Esto varía considerablemente de una
SGBD a otro.

En el estándar de SQL muchas veces se utiliza el término id-autorización en

lugar de id-usuario. Este término es un poco más preciso puesto que no se
asocia a personas determinadas sino a privilegios sobre la BD.

Cada SGBD deberá implementar la forma de autentificar los id-usuarios que han
sido emitidos por su administrador, esto se hace comúnmente a través de una
contraseña, pero el SQL no dice nada sobre esto.

Es importante señalar que en la mayoría de los SGBD de hoy en día se pueden

crear Grupos de Usuarios o Roles, a los cuales se le otorgan una serie de
privilegios. Luego cuando se crea un usuario este puede hacerse miembro de un
Grupo de Usuario existente, y tiene los mismos privilegios que él, o sea, hereda
los privilegios del Grupo de Usuario al que pertenece.

Usuarios y grupos de usuarios en PostgreSQL:

Conceptualmente los usuarios de la base de datos son independientes de los

existentes en un sistema operativo determinado. En la práctica se recomienda
en algunas circunstancias mantener una correspondencia entre estos, pero no
es obligatorio. Los usuarios creados para una base de datos son globales para
todo el gestor y no específicos para una base de datos en particular.
Frecuentemente es conveniente agrupar usuarios para facilitar el proceso de
conceder o revocar privilegios a todo el grupo. En Postgresql esto se logra
creando un usuario que represente el grupo y luego se le especifica a cada
usuario de forma individual que pertenece al grupo definido. Por lo que ambos
son tratados y creados de igual forma ante el SGBD (CREATE ROLE), una
característica típica de un usuario utilizado como grupo es que no tiene privilegio
de autenticación (Login).

Sintaxis básica de CREATE ROLE:

CREATE ROLE nombreusuario;

Sintaxis ampliada:

CREATE ROLE name [ [ WITH ] option [ ... ] ]

where option can be:

SUPERUSER | NOSUPERUSER
| CREATEDB | NOCREATEDB
| CREATEROLE | NOCREATEROLE
| CREATEUSER | NOCREATEUSER
| INHERIT | NOINHERIT
| LOGIN | NOLOGIN
| CONNECTION LIMIT connlimit
| [ ENCRYPTED | UNENCRYPTED ] PASSWORD 'password'
| VALID UNTIL 'timestamp'
| IN ROLE rolename [, ...]
| IN GROUP rolename [, ...]
| ROLE rolename [, ...]
| ADMIN rolename [, ...]
| USER rolename [, ...]
| SYSID uid

Principales parámetros *:

SUPERUSER / NOSUPERUSER: Esta claúsula determina si un usuario es o no

un superusuario. Un superusuario tiene todos los privilegios del SGBD, es decir
puede saltarse todas las comprobaciones de permisos de postgresql, por lo que
se aconseja realizar la mayor parte del trabajo en una base de datos con un
usuario que no tenga este privilegio. Un superusuario solo puede ser creado por
otro usuario de igual rango o categoría.

CREATEDB / NOCREATEDB: Esta claúsula especifica si un usuario puede o no

crear bases de datos (válido para usuarios que no son superusuarios).
CREATEROLE / NOCREATEROLE y CREATEUSER / NOCREATEUSER:
Estas claúsulas especifican si un usuario puede o no crear otros usuarios (válido
para usuarios que no son superusuarios).

INHERIT / NOINHERIT: Esta claúsula determina si un usuario hereda o no los

permisos o privilegios otorgados al grupo de usuarios del cual es miembro.

LOGIN / NOLOGIN: Esta claúsula determina si un usuario puede autenticarse o

conectarse a una base de datos determinada dentro del SGBD.

CONNECTION LIMIT: Especifica la cantidad de conexiones concurrentes que un

usuario puede establecer, de no especificarse un valor por defecto se toma -1
que significa que no tiene límites.

[ ENCRYPTED | UNENCRYPTED ] PASSWORD 'password': En esta claúsula se

especifica la clave utilizada para autenticar la conexión entre un cliente y el
SGBD, es significativo para conexiones que utilicen métodos de autenticación
como: md5, crypt, etc.

IN ROLE: Especifica que un usuario pertenece o es miembro de un determinado

grupo de usuarios.

*Para una descripción más detallada de todos los parámetros del comando CREATE ROLE
consultar en los materiales complementarios el documento Roles, grupos y usuarios.pdf.

Una vez creado un grupo de usuarios se le pueden asignar usuarios o retirar

usuarios utilizando los comandos del Lenguaje de Control de Datos (DCL):
GRANT y REVOKE respectivamente.

GRANT group_role TO role1, ... ;

REVOKE group_role FROM role1, ... ;

Existen otras formas de crear usuarios y grupos de usuarios, mediante el empleo

de los comandos CREATE USER * y CREATE GROUP * respectivamente, es
válido destacar que ambos comandos son equivalentes a CREATE ROLE, por lo
que en la práctica a partir de la versión 8.3, este último es el más utilizado para
estos propósitos.

*Si desea profundizar sobre la sintaxis de los comandos CREATE USER y CREATE GROUP
consulte en los materiales complementarios el documento Roles, grupos y usuarios.pdf.

Ejemplos:

CREATE ROLE jonathan LOGIN; -- se crea un usuario

CREATE USER lilian WITH PASSWORD 'jw8s0F4'; -- se crea un usuario

CREATE ROLE miriam WITH LOGIN PASSWORD 'jw8s0F4' VALID UNTIL
'2005-01-01'; -- se crea un usuario

CREATE ROLE admin WITH CREATEDB CREATEROLE; -- se crea un rol

 Objetos de seguridad

Las protecciones se aplican a objetos específicos contenidos en una BD o a una

BD en sí, es decir, como mismo un usuario puede seleccionar información en
una tabla, puede tener acceso o no al contenido de una BD. El estándar SQL
tiene dos objetos fundamentales: tablas y vistas y especifica también los
dominios de datos definidos por los usuarios. Los ejemplos que se van a mostrar
en este material hacen referencia a estos objetos: tablas y vistas; aunque,
existen muchos más objetos en una BD (como funciones disparadoras,
esquemas, procedimientos almacenados, funciones, etc), dependiendo del
SGBD que se esté usando.

 Privilegios

Se le llama privilegio al conjunto de acciones que al usuario le fueron otorgadas

por el administrador o propietario de la BD, para que efectúe sobre los objetos
que existan en su BD. Los privilegios más comunes son los de realizar las
acciones de:
 SELECT, que permite recuperar datos de una tabla o vista.
 INSERT, que permite insertar nuevas filas en una tabla o vista.
 DELETE, que permite eliminar filas dentro de una tabla o vista.
 UPDATE, que permite modificar filas de datos en una tabla o vista.

Existen muchas más acciones que las mencionadas hasta el momento, estos
privilegios también se le aplican a las acciones realizadas mediante los
comandos del DCL (GRANT y REVOKE) y DML (CREATE, ALTER, DROP).

Por ejemplo, cuando se crea una tabla con la sentencia CREATE, quien lo hace
se convierte en su propietario y recibe totales privilegios sobre esa tabla
(SELECT, INSERT, DELETE; UPDATE). Otros usuarios no tienen inicialmente
privilegios sobre la tabla recién creada. Si se les va a proporcionar acceso a la
tabla, hay que concedérselos utilizando la sentencia GRANT.

Si se crea una vista con la sentencia CREATE VIEW, se convierte en el

propietario de ella, pero no recibe necesariamente todos los privilegios sobre
ella. Para crear la vista con éxito debe tener ya el privilegio SELECT sobre todas
las tablas fuente, entonces el SGBD proporciona el privilegio SELECT sobre la
vista. Para cada uno de los otros privilegios el SGBD proporciona el privilegio
sobre la vista solamente si se dispone de ese mismo privilegio sobre todas las
tablas fuente de la vista.
Pero no todos los usuarios tienen privilegios para crear, eliminar o cambiar
tablas o vistas, o para otorgar privilegios sobre los objetos de una BD, en inicio,
solo el usuario administrador del SGBD puede otorgar privilegios o crear
usuarios que puedan otorgarlos.

 Concesión de privilegios

La sentencia que se utiliza para conceder privilegios, es la sentencia GRANT,

cuya sintaxis se muestra a continuación:

GRANT SELECT
INSERT

DELETE
UPDATE
( nombre columna )
,
,
ALL PRIVILEGES

ON nom tabla TO nom usuario

PUBLIC WITH GRANT OPTION

Como se muestra en la figura la sentencia GRANT incluye los privilegios que se

otorgan, a cuál tabla se otorga y por último a cuál usuario se otorgan esos
privilegios.

Por ejemplo:

Proporcionar al usuario usuariopp el acceso completo a la tabla pedidos.

GRANT SELECT, INSERT, DELETE, UPDATE

ON pedidos
TO usuariopp

Esta sentencia se hubiera podido escribir

GRANT ALL PRIVILEGES

ON pedidos
TO usuariopp
Dar a todos los usuarios acceso SELECT a la tabla oficinas
GRANT SELECT
ON oficinas
TO PUBLIC

Observar que en el caso de UPDATE se puede permitir acceso a columnas

determinadas, si no se especifica nada se supone que se está dando privilegios
sobre todas las columnas.

Permitir al usuario usuariopp modificar los nombres de empresa y las

asignaciones a vendedores en la tabla clientes.

GRANT UPDATE (empresa, vend_cliente)

ON clientes
TO usuariopp

 Paso de privilegios

Cuando un usuario crea un objeto en una BD se convierte en el propietario del

mismo y es la única persona que puede conceder privilegios para utilizar el
objeto. Cuando concede privilegios a otros usuarios, éstos tienen permitido el
uso de ese objeto pero no pueden transmitir el privilegio a otros usuarios.

En ocasiones puede desearse permitir a otros usuarios que concedan privilegios

sobre un objeto que no es de su propiedad.

Supongamos que el usuario sam crea la vista vendeste. El puede hacer la

siguiente operación:

GRANT SELECT
ON vendeste
TO larry
WITH GRANT OPTION

Aquí le está dando permiso al usuario larry a usar la vista de solo lectura y
además le está dando la potestad a larry que pueda dar este permiso a otros
usuarios. Luego ahora larry puede hacer lo siguiente:

GRANT SELECT
ON vendeste
TO sue

El usuario sue tiene derecho a usar la vista pero no puede dar este permiso a
otros usuarios.
  Revocación de privilegios

La revocación de privilegios aparece en el SQL2 por primera vez y se realiza

con la sentencia REVOKE, la cual tiene una apariencia similar a la sentencia
GRANT, cambia que en lugar de la palabra reservada TO se utiliza la palabra
FROM y se añade las cláusulas GRANT OPTION, CASCADE o RESTRICT.

Por ejemplo la sentencia:

REVOKE SELECT, UPDATE

ON pedidos
FROM larry CASCADE

Revoca los privilegios concedidos al usuario larry, de SELECT y UPDATE y

además revoca todos los privilegios que larry pudo haber concedido. Si se utiliza
la cláusula RESTRICT entonces si larry concedió algún privilegio entonces la
sentencia REVOKE fallará.

Ahora supongamos la sentencia:

REVOKE GRANT OPTION SELECT, UPDATE

ON pedidos
FROM larry CASCADE

Si la sentencia tiene éxito entonces larry perderá la capacidad de otorgar estos

privilegios a otros usuarios, pero no pederá sus privilegios.

Catálogo del sistema

El Catálogo es una minibase de datos que constituye el núcleo del SGBD. Su

función fundamental es almacenar los esquemas o descripciones de las BD que
el SGBD mantiene. A los datos almacenados en el catálogo se les conoce como
metadatos.

El SGBD para hacer cualquier operación sobre una base de datos se refiere
constantemente a los datos del catálogo de sistema, por ejemplo cuando
procesa una sentencia de SQL.

Contenido del Catálogo:

 Tablas: el catálogo describe cada tabla del a BD, identificando su nombre,

propietario, número de columnas que contiene, tamaño, etc.
 Columnas: el catálogo describe cada columna de la BD, proporcionando
al nombre de la columna, la tabla a la que pertenece, su tipo de dato,
tamaño, si están permitidos los nulos, etc.
  Usuarios: el catálogo describe a cada usuario autorizado de la BD,
incluyendo su nombre, una forma cifrada de contraseña del usuario y
otros datos.
 Vistas: el catálogo describe cada vista definida en la BD, incluyendo su
nombre, nombre de su propietario, la consulta que define esta vista, etc.
 Privilegios: el cátalo describe cada grupo de privilegios concedidos en la
BD, incluyendo los nombres del donante y el donatario, privilegios
concedidos, el objeto sobre el cual se han concedido esos privilegios, etc.

Precisamente por contener información de seguridad y autorización, que

especifica los permisos que tienen los usuarios para tener acceso a las
relaciones y vistas de la BD, y quiénes son los creadores o propietarios de cada
relación, es interesante conocer algunas interioridades del catálago, tales como
su estructura y manera de consultarlo, como otra herramienta útil para el control
de la seguridad de una base de datos.

Catálogo del Sistema (Postgresql 9.0) *

Nombre Propósito
pg_aggregate aggregate functions
pg_am index access methods
pg_amop access method operators
pg_amproc access method support procedures
pg_attrdef column default values
pg_attribute table columns ("attributes")
pg_authid authorization identifiers (roles)
pg_auth_members authorization identifier membership relationships
pg_cast casts (data type conversions)
pg_class tables, indexes, sequences, views ("relations")

pg_constraint
check constraints, unique constraints, primary key
constraints, foreign key constraints
pg_conversion encoding conversion information
pg_database databases within this database cluster
pg_db_role_setting per-role and per-database settings
pg_default_acl default privileges for object types
pg_depend dependencies between database objects
pg_description descriptions or comments on database objects
pg_enum enum label and value definitions
pg_foreign_data_wrapper foreign-data wrapper definitions
Nombre Propósito
pg_foreign_server foreign server definitions
pg_index additional index information
pg_inherits table inheritance hierarchy
pg_language languages for writing functions
pg_largeobject data pages for large objects
pg_largeobject_metadata metadata for large objects
pg_namespace schemas
pg_opclass access method operator classes
pg_operator operators
pg_opfamily access method operator families
pg_pltemplate template data for procedural languages
pg_proc functions and procedures
pg_rewrite query rewrite rules
pg_shdepend dependencies on shared objects
pg_shdescription comments on shared objects
pg_statistic planner statistics
pg_tablespace tablespaces within this database cluster
pg_trigger triggers
pg_ts_config text search configurations
pg_ts_config_map text search configurations' token mappings
pg_ts_dict text search dictionaries

Las consultas al catálogo del sistema se realizan utilizando el lenguaje del

SGBD a utilizar. A continuación se listan algunas consultas hechas al catálogo
de postgresql 8.3:

 Listar todos los esquemas existentes en una base de datos:

- SELECT schema_name FROM information_schema.schemata;

 Lista de todos las tablas de un schema:

SELECT table_name FROM information_schema.tables WHERE table_schema

= 'nombre_schema';

* Más información sobre el catálogo en el material complementario Postgresql’s catalogs (9.0),

publicado en los materiales de apoyo para esta frecuencia en el EVA.
Políticas de seguridad

La imagen que frecuentemente viene a la mente cuando se discute sobre

seguridad es la del gran firewall que permanece al resguardo de la apertura de
la red, defendiendo de ataques de malévolos hackers. Aunque un firewall jugará
un papel muy importante, es sólo una herramienta que debe ser parte de una
estrategia más comprensiva y que será necesaria a fin de proteger
responsablemente los datos de la red.

Aún cuando se tenga las habilidades y experiencia necesaria para configurar el

firewall correctamente, será difícil conocer la administración de riesgos que está
dispuesto a tomar con los datos y determinar la cantidad de inconveniencias a
resistir para protegerlos. Los temas legales también surgen. ¿Qué obligaciones
legales se tiene para proteger la información? Si usted está en una compañía de
publicidad o en un centro de investigación, por citar algunos ejemplos, puede
tener algunas responsabilidades definitivas al respecto.

Asegurar sus datos involucra algo más que conectarse en un firewall con una
interface competente o cualquier otro programa de seguridad informática. Lo que
se necesita es un plan comprensivo de defensa. Y se necesita comunicar este
plan en una manera que pueda ser significativo para la gerencia y usuarios
finales. Esto requiere educación y capacitación, conjuntamente con la
explicación, claramente detallada, de las consecuencias de las violaciones. A
esto se le llama una política de seguridad y es el primer paso para asegurar
responsablemente la red o los datos contenidos en un Sistema Gestor de Bases
de Datos. La política puede incluir instalar un firewall, pero no necesariamente
se debe diseñar su política de seguridad alrededor de las limitaciones del
firewall.

Elaborar la política de seguridad no es una tarea trivial. Ello no solamente

requiere que el personal técnico comprenda todas las vulnerabilidades que están
involucradas, también requiere que ellos se comuniquen efectivamente con la
gerencia. La gerencia debe decidir finalmente cuánto de riesgo debe ser tomado
con el activo de la compañía, y cuánto se debería gastar en ambos, en dólares e
inconvenientes, a fin de minimizar los riesgos. Es responsabilidad del personal
técnico asegurar que la gerencia comprenda las implicaciones de añadir acceso
a la información de la red o de una base de datos, de tal manera que la gerencia
tenga la suficiente información para la toma de decisiones. Si la política de
seguridad no viene desde el inicio, será difícil imponer incluso medidas de
seguridad mínimas. Por ejemplo, los empleados pueden llegar a alterarse si
ellos imprevistamente tienen que introducir logins y contraseñas donde antes no
lo hacían. Es mejor trabajar con estos temas antes de tiempo y poner la política
por escrito. Las políticas pueden entonces ser comunicadas a los empleados por
la gerencia. De otra forma, los empleados no lo tomarán en serio, o se tendrán
batallas de políticas constantes dentro de la compañía con respecto a este
punto.

El desarrollo de una política de seguridad para bases de datos comprende la

identificación de los activos (información relevante), evaluación de amenazas
potenciales, la evaluación del riesgo, implementación de las herramientas y
tecnologías disponibles para hacer frente a los riesgos, y el desarrollo de una
política de uso. Debe crearse un procedimiento de auditoria que revise el uso de
la red y servidores de forma periódica.

Identificación de los activos: Consiste en la creación de una lista de todas las

cosas que precisen protección.

Por ejemplo: Datos: copias de seguridad, registros de auditoria, bases de datos.

Valoración del riesgo: Conlleva la determinación de lo que se necesita proteger.

No es más que el proceso de examinar todos los riesgos y valorarlos por niveles
de seguridad.

Definición de una política de uso aceptable: Las herramientas y aplicaciones

forman la base técnica de la política de seguridad, pero la política de uso
aceptable debe considerar otros aspectos:
* ¿Quién tiene permiso para usar los recursos?
* ¿Quién esta autorizado a conceder acceso y a aprobar los usos?
* ¿Quién tiene privilegios de administración del sistema?
* ¿Qué hacer con la información confidencial?
* ¿Cuáles son los derechos y responsabilidades de los usuarios?

Por ejemplo, al definir los derechos y responsabilidades de los usuarios:

* Si los usuarios están restringidos, y cuáles son sus restricciones.
* Si los usuarios pueden compartir cuentas o dejar que otros usuarios utilicen
sus cuentas.
* Cómo deberían mantener sus contraseñas los usuarios.
* Con qué frecuencia deben cambiar sus contraseñas.
* Si se facilitan copias de seguridad o los usuarios deben realizar las suyas.