SEGURIDAD, REQUISITO INDISPENSABLE EN LA BASE DE

DATOS ESTUDIO DE OPINÓN DEL PUEBLO

SECURITY, AN INDISPENSABLE REQUIREMENTS FOR THE

DATABASE OF THE PEOPLE´S OPINIONS STUDY
Jessica Carriles Cardo1 , Lienzt de la Caridad Chang Collado2

1 Centro de Estudios Sociopolíticos y de Opinión, Cuba, jessica@op.cc.cu, San Sebastián #5 e/ Corralfalso y Aparación.
Guanabacoa, La Habana, Cuba.
2 Centro de Estudios Sociopolíticos y de Opinión, Cuba, lien@op.cc.cu, Cocos #143 apto. 10 e/ Rabí y General Lee. Diez de
Octubre, La Habana, Cuba.

RESUMEN: El Centro de Estudios Sociopolíticos y de Opinión se encuentra inmerso en el desarrollo y avance

tecnológico, debido a ello ha informatizado una parte de sus procesos, como es la captura de opiniones espon-
táneas generadas por todo el país. Hoy en día existe la necesidad imperante de que la información contenida
en su base de datos se mantenga segura, cumpliendo requisitos tales como la integridad y confidencialidad.
Por lo que se hace necesario implementar mecanismos de seguridad que restrinjan el acceso a la información
de personas no autorizadas. El presente trabajo investigativo describe cómo garantizar la seguridad de los da-
tos, empleando protocolo SSL, creando roles, vistas y asignando niveles de privilegios. Como resultado se ob-
tuvo un sistema de base de datos seguro y confiable.

Palabras Clave: Seguridad, integridad, confidencialidad, privilegios y SSL.

ABSTRACT: Estudios's Center Sociopolitical and of Opinión finds itself immersed in development and techno-
logical advance, due to it, the center has computerized one part of its processes, as the capture of spontaneous
opinions generated by all around the country. Nowadays exists the prevailing need that the information con-
tained in the database keep safe, obeying requirements such like the integrity and confidentiality. What one be-
comes necessary to implement mechanisms of certainty that restrict the access to not authorized people's in-
formation. The present investigative work describes how guarantee the security of the data, using SSL protocol,
creating roles, views and assigning levels of privileges. As a result, it got a system of data base safe and relia-
ble.

KeyWords: Security, integrity, confidentiality, privileges and SSL.

1. INTRODUCCIÓN sonas modificar sus hábitos y patrones de conduc-

ta, así como, su forma de pensar. Las TIC ofrecen
En la actualidad el mundo está experimentando un amplio marco de posibilidades, fundamental-
cambios esenciales debido al aumento de las Tec- mente en el desarrollo de la industria de software
nologías de la Información y las Comunicaciones para la informatización de la sociedad en que se
(TIC). Dichas tecnologías constituyen el núcleo vive, trayendo como consecuencia aumento en la
central de las transformaciones que afrontan la productividad y mejor gestión de las empresas y
economía y la sociedad, imponiéndoles a las per- organizaciones.
“VIII Taller Internacional de Tecnologías de Software Libre y Código Abierto”
 Carriles, J.; Chang, L. | “SEGURIDAD, REQUISITO INDISPENSABLE EN LA BASE DE DATOS ESTUDIO DE OPINIÓN DEL PUEBLO”
El desarrollo de la industria del software y el au-
mento de la competencia en el mercado exige co-
mo requisito fundamental para las aplicaciones
informáticas la presencia de altos niveles de segu-
ridad. En las organizaciones es importante adoptar
medidas orientadas a prevenir acciones que pon-
gan en riesgo la confidencialidad e integridad de la
información que se maneja.
El Centro de Estudios Sociopolíticos y de Opinión
(CESPO) es una de las empresas que ha contribui-
do al avance tecnológico en Cuba, informatizando
sus procesos para alcanzar resultados eficaces,
precisos y confiables. Cuenta con una base de
datos encargada de procesar las opiniones espon-
táneas generadas por la población de todo el país,
por lo que se convierte en una institución estratégi-
ca en cuanto a la información que procesa. En él se
garantiza el estricto cumplimiento de la seguridad
informática y de la información, de modo que los
recursos sean utilizados bajo las normas y regla-
mentos establecidos. Además, la información allí
contenida sólo puede ser consultada y modificada
por las personas que se encuentren acreditadas y
dentro de los límites de su autorización. El CESPO
cuenta con políticas de seguridad que garantiza
este requisito a través de los controles legales, el
acceso físico, los componentes de hardware y de
software.
En la actual coyuntura, la base de datos que con-
tiene la información sensible de las opiniones es-
pontáneas, no cuenta con los requerimientos de
seguridad indispensables. La configuración de la
seguridad es ineficiente, puesto que sus paráme-
tros están definidos por defecto. Todos los usuarios
pueden acceder, insertar, eliminar y actualizar la
información desde cualquier ubicación remota sin
restricciones. Además, el tráfico de los datos a tra-
vés de la red no es seguro, por lo que pueden ser
interceptados y utilizados con fines malintenciona-
dos. Por todo lo anteriormente planteado se hace
necesario emplear mecanismos de seguridad para
proteger los datos contra su revelación, alteración o
destrucción no autorizadas.
2. CONTENIDO
2.1 Materiales y métodos
Los métodos científicos de investigación utilizados
en el presente trabajo son:
Analítico-Sintético: Empleado para realizar un
análisis detallado de las teorías y documentos que
hacen referencia a la seguridad a nivel de base de
datos; permitiendo la extracción de los elementos
más importantes que se relacionan con el objeto de
estudio.
Histórico-Lógico: Empleado para analizar la evo-
lución de la seguridad a nivel de base de datos, así
“VIII Taller Internacional de Tecnologías de Software Libre y Código Abierto”
como alcanzar razonamientos lógicos.
2.2 Seguridad de bases de datos en Post-
greSQL
La seguridad de los datos implica protegerlos de
acciones indebidas que pongan en peligro su defi-
nición, existencia, consistencia e integridad inde-
pendientemente de la persona que los accede [1].
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 la indebida
destrucción o alteración. Es un componente funda-
mental de la estrategia global en materia de seguri-
dad informática, y es una cuestión demasiado im-
portante como para quedarse con las configuracio-
nes “por defecto”. [2]
Para mantener la seguridad en una base de datos,
deben cumplirse requisitos tales como:
Confidencialidad: Condición que asegura que la
información no pueda estar disponible o ser descu-
bierta por o para personas, entidades o procesos
no autorizados. [3]
Integridad: Condición que garantiza que la infor-
mación sólo puede ser modificada, incluyendo su
creación y borrado, por el personal autorizado. El
concepto de integridad significa que el sistema no
debe modificar o corromper la información que al-
macene, o permitir que alguien no autorizado lo
haga. [3]
Para garantizar que se cumplan estos requisitos se
definen dos niveles de seguridad.
• Seguridad de acceso al sistema
Permite definir desde qué equipos se pueden co-
nectar los usuarios a las bases de datos, así como
definir qué usuarios y a qué bases de datos se
pueden conectar. Las configuraciones de este nivel
de seguridad se realizan en los ficheros post-
gresql.conf, pg_ident.conf y pg_hba.conf.
El fichero postgresql.conf presenta parámetros im-
portantes para configurar las conexiones, así como
para la seguridad y autenticación.
Configuración de las conexiones: [4]
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.
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 direc-
ciones 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 de 100 conexiones.
 Carriles, J.; Chang, L. | “SEGURIDAD, REQUISITO INDISPENSABLE EN LA BASE DE DATOS ESTUDIO DE OPINIÓN DEL PUEBLO”
Seguridad y autenticación: [4]
authentication_timeout (integer): Establece el tiem-
po máximo para completar la autenticación del
cliente, en cuestión de segundos.
SSL 1 (boolean): Especifica si se permiten conexio-
nes SSL. El valor predeterminado es off. Comuni-
cación SSL sólo es posible con conexiones TCP /
IP.
password_encryption (boolean): Cuando se especi-
fica 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 encrip-
tada. El valor predeterminado es on (cifrar la con-
traseña).
row_security (boolean): Especifica si se aplican o
no las directivas de seguridad de fila. El valor pre-
determinado es on.
El fichero pg_hba.conf controla la autentificación
del cliente.
En el fichero se debe definir un registro para cada
acceso que se pueda conectar al servidor. Cada
registro especifica el tipo de conexión (TYPE),
nombre de la base de datos a la que tendrá acceso
(DATABASE), nombre de usuario (USER), direc-
ción IP del cliente (ADDRESS) y el método de au-
tentificación que se va a utilizar (METHOD). [5]
TYPE:
Local: Se define para las conexiones que se reali-
zarán desde el propio servidor.
Host: Se utilizará para conexiones remotas no-SSL
y SSL.
Hostssl: Sólo se utilizará para conexiones SSL.
Hostnossl: Sólo se utilizará para las conexiones
remotas no-SSL.
DATABASE:
All: Permite la conexión a cualquier base de datos.
Sameuser/Samerole: Se empleará para bases de
datos que su nombre sea el mismo que el usua-
rio/rol que se conecta.
nombd1, nombd2,…: Permite la conexión a cual-
quiera de las bases de datos de la lista.
@fichero: Permite la conexión a las bases de datos
incluidas en el fichero. Debe estar en el mismo
directorio que pg_hba.conf
USER:
ALL: Permite la conexión de cualquier rol.
role1, role2,…: Permite la conexión de los roles de
la lista y además permite la conexión de cualquier
rol que sea miembro de role2.
@fichero: Permite la conexión de los roles incluidos
1
Secure Sockets Layer por sus siglas en inglés. Protocolo
criptográfico que permite autenticar y entregar privacidad a la
información entre el cliente y el servidor de forma segura.
“VIII Taller Internacional de Tecnologías de Software Libre y Código Abierto”
en el fichero. Debe estar en el mismo directorio que
pg_hba.conf.
METHOD
trust: Permite todos los accesos sin necesidad de
autenticarse (sólo recomendable para conexiones
desde el equipo local).
reject: Rechaza la conexión sin condiciones.
password: Solicita la contraseña sin encriptar.
md5: Solicita la contraseña con el método de en-
criptación md5.
ident: Utiliza el usuario del sistema desde el que se
está intentado conectar.
cert: Autenticar utilizando certificados SSL.
• Seguridad de los datos
Cuando se permite un acceso es importante res-
tringirlo a personal autorizado. La seguridad de los
datos es responsabilidad del Sistema Gestor de
Bases de Datos (SGBD) que se esté utilizando, por
lo que debe ser configurada con roles, privilegios y
permisos adecuados para evitar los accesos malin-
tencionados. Por lo general se puede garantizar a
través del control discrecional y el control obligato-
rio. En ambos casos, la unidad de los datos que se
necesite proteger puede comprender desde toda la
base de datos hasta un componente específico
dentro de una tupla específica. [6]
a. Administración de roles
Los roles de las bases de datos pueden tener un
número de atributos que define sus privilegios e
interactúa con el sistema de autenticación del clien-
te. PostgreSQL administra el acceso a las bases de
datos utilizando el concepto de roles. Para crear
usuarios o grupos de usuarios se emplea la sen-
tencia: [7]
CREATE ROLE nombre [ [ WITH ] opción [ ... ] ]
Donde opción puede ser:
SUPERUSER | NOSUPERUSER
| CREATEDB | NOCREATEDB
| CREATEROLE | NOCREATEROLE
| CREATEUSER | NOCREATEUSER
| INHERIT | NOINHERIT
| LOGIN | NOLOGIN
| REPLICATON | NOREPLICATION
| CONNECTION LIMIT límite_conexiones
| BYPASSRLS | NOBYPASSRLS: característica
introducida en 9.5, por defecto es la opción NOBY-
PASSRLS, si se especifica BYPASSRLS significa
que el rol no tendrá en cuenta las políticas que se
le hallan asignado.
| [ ENCRYPTED | UNENCRYPTED ] PASSWORD
'contraseña'
| VALID UNTIL 'fecha'
 Carriles, J.; Chang, L. | “SEGURIDAD, REQUISITO INDISPENSABLE EN LA BASE DE DATOS ESTUDIO DE OPINIÓN DEL PUEBLO”
| IN ROLE nombre_rol [, ...]
| IN GROUP nombre_rol [, ...]
| ROLE nombre_rol [, ...]
| ADMIN nombre_rol [, ...]
| USER nombre_rol [, ...]
| SYSID uid
Es importante conocer que si se emplea la senten-
cia CREATE USER nombre ya el usuario tendrá la
opción de login por defecto, mientras que con el
comando CREATE ROLE sí se debe especificar.
Una vez creado un rol, puede ser modificado o
eliminado con los comandos ALTER ROLE nom-
bre y DROP ROLE nombre respectivamente.
b. Gestión de privilegios
Se le llama privilegio al conjunto de acciones que
los usuarios pueden realizar sobre cada objeto de
la base de datos (tablas, columnas, vistas, funcio-
nes, trigger, entre otros). El comando GRANT brin-
da privilegios sobre objetos de una base de datos a
uno o más roles. La sentencia para administrar
privilegios es la siguiente: [8].
GRANT { { SELECT | INSERT | UPDATE | DELETE
| TRUNCATE | REFERENCES | TRIGGER | CRE-
ATE | CONNECT | TEMPORARY | TEMP} | ALL [
PRIVILEGES ] }
ON { [ TABLE ] nombre_tabla [, ...] | ALL TABLES
IN SCHEMA nombre_esquema [, ...] }
TO { [ GROUP ] nombre_rol | PUBLIC } [, ...] [ WITH
GRANT OPTION ]
REVOKE [ GRANT OPTION FOR ]
{ { SELECT | INSERT | UPDATE | DELETE |
TRUNCATE | REFERENCES | TRIGGER }
[, ...] | ALL [ PRIVILEGES ] }
ON { [ TABLE ] nombre_tabla[, ...] | ALL TABLES IN
SCHEMA nombre_esquema [, ...] }
FROM { [ GROUP ] nombre_rol | PUBLIC } [, ...]
[ CASCADE | RESTRICT ]
c. Definición de vistas para proteger las ta-
blas
Una vista es una estructura lógica que permite vi-
sualizar un grupo de datos que provienen de una o
varias tablas u otras vistas. Los datos accesibles a
través de la vista no están almacenados en la base
de datos como un objeto [9].
Las vistas permiten:
- ocultar información: permitiendo el acceso a
algunos datos y manteniendo oculto el resto de la
información que no se incluye en la vista. El usuario
solo puede consultar la vista.
- simplificar la administración de los permi-
sos de usuario: permite otorgar permisos al usua-
“VIII Taller Internacional de Tecnologías de Software Libre y Código Abierto”
rio para que solamente pueda acceder a los datos a
través de vistas, en lugar de concederle permisos
para acceder a ciertos campos, así se protegen las
tablas base de cambios en su estructura.
La sintaxis básica para crear una vista es la si-
guiente:
CREATE OR REPLACE VIEW nombre_vista AS
sentencias select
FROM tabla;
d. Seguridad por filas
Las tablas pueden tener políticas de seguridad de
filas que restringen, por usuario, qué filas pueden
ser devueltas una vez realizada una inserción, mo-
dificación o eliminación. [10]
Para crear una política de seguridad se emplea la
sentencia:
CREATE POLICY nombre ON nombre_tabla
[ FOR { ALL | SELECT | INSERT | UPDATE |
DELETE } ] [ TO { <nombre_rol | PUBLIC | CUR-
RENT_USER | SESSION_USER } [, ...] ] [ USING (
expression_booleana> ) ] [ WITH CHECK ( expres-
sion_booleana) ]
Si es necesario modificar o eliminar una política
creada se emplean los comandos ALTER POLICY
y DROP POLICY respectivamente. Para habilitar y
deshabilitar la seguridad de fila para una tabla de-
terminada, se utiliza el comando ALTER TABLE
nombre_tabla ENABLE/DISABLE ROW SECU-
RITY.
2.3 Resultados y discusión
La base de datos ESTOP está implementada en
PostgreSQL 9.5 sobre el servidor Debian v7.0
Wheezy, y su administración es a través del cliente
pgAdminIII v1.22.1 sobre el sistema operativo Win-
dows 7.
Para garantizar la seguridad de acceso al siste-
ma fue necesario cifrar el tráfico entre los clientes y
el servidor y así evitar que la información transferi-
da por la red fuera interceptado u obtenido por per-
sonas no autorizadas. Esta característica se logró a
través de la autenticación de certificados digitales,
impidiendo que los usuarios que no tengan instala-
do el certificado correspondiente puedan conectar-
se al servidor.
PostgreSQL soporta nativamente el uso de cone-
xiones SSL para cifrar las comunicaciones, sólo es
necesario tener instalado OpenSSL en el servidor y
PostgreSQL compilado con soporte SSL (se consi-
gue usando el parametro --with-ssl con ./configure
antes de compilar).
Para generar la llave y los certificados es necesario
ubicarse en el directorio de instalación de Postgres
(opt/PostgreSQL/9.5/data/)
 Carriles, J.; Chang, L. | “SEGURIDAD, REQUISITO INDISPENSABLE EN LA BASE DE DATOS ESTUDIO DE OPINIÓN DEL PUEBLO”

Creación de un par de claves pública y privada Para garantizar que cada usuario que accederá a la
base de datos se autentique a través de un certifi-
El primer paso para crear un método de comunica-
cado se necesitó generar la llave, un certificado
ción seguro es poseer un par de claves pública y
autofirmado por el servidor y el certificado de con-
privada.
fianza (usuario.key, usuario.crt, root.crt), para ello
openssl genrsa -des3 -out server.key 2048 se ejecutó la sentencia:
Generating RSA private key, 2048 bit long openssl genrsa -des3 -out /tmp/usuario.key 2048
modulus
………………………………………………………………………..++++++ openssl rsa -in /tmp/usuario.key –out /tmp/usuario.
key
……………………………………………….++++++
E is 65537 (0x10001) Es necesario tener en cuenta al crear la solicitud de
Enter pass phrase for server.key:
certificado la opción correspondiente a common
name debe coincidir con el nombre de usuario que
Verifying – Enter pass phrase for serv-
er.key: se conectará en la base de datos.
Cada vez que el servicio que utilice la clave creada openssl req -new -key /tmp/usuario.key -out
sea inicializado, dígase postgresql-9.5, se requerirá /tmp/usuario.csr
una contraseña, por lo que se eliminó dicha clave Una vez creada la solicitud (usuario.csr), debe ser
para facilitar el funcionamiento a través del coman- firmada por la clave del servidor (server.key). por lo
do siguiente: que es necesario ubicarse en el directorio de confi-
openssl rsa -in server.key -out server.key guración de postgres y ejecutar:
Enter pass phrase for server.key: openssl x509 -req -in /tmp/usuario.csr -CA root.crt -
writing RSA key CAkey server.key -out /tmp/usuariol.crt –
Cacreateserial
Creación de un certificado. Al concluir se deben copiar los archivos generados
Es importante destacar que las conexiones que en la máquina del usuario:
acepta el servidor pertenecen a la red interna del C:\Users\nombre_usuario\AppData\Roaming\postgr
Centro, por lo que no fue necesario acudir a una esql.
Autoridad de Certificación (CA) para que firmara el
certificado, sino que se pudo crear un certificado y Una vez configurado el protocolo SSL en el servidor
autofirmarlo como una CA local. Para ello se ejecu- se establecieron los parámetros de los ficheros
tó lo siguiente: postgresql.conf y pg_hba.conf de acuerdo a las
necesidades del centro. A continuación, una mues-
openssl req -new -key server.key -days 730 -out tra de la sección seguridad y autenticación del fi-
server.crt -x509 chero postgresql.conf
You are about to be asked to enter infor-
mation that will be incorporated # - Security and Authentication -
into your certificate request. authentication_timeout = 1min #1s-600s
... ssl = on #(change requires restart)
...
----- password_encryption = on
Country Name (2 letter code) [AU]:CU row_security = on
State or Province Name (full name) [Some-
State]:Habana En la sección de conexiones y autenticación se
Locality Name (eg, city) []:Plaza definió un puerto diferente al que aparece por de-
Organization Name (eg, company) [Internet fecto, las direcciones IP de las máquinas que se
Widgits Pty Ltd]:CESPO conectarán, así como la cantidad máxima de cone-
Organizational Unit Name (eg, section) xiones que admitirá, teniendo en cuenta que solo
[]:Computacion existen 15 puestos destinados para el trabajo con la
Common Name (eg, YOUR name) []:servidor
Email Address []:admin@op.cc.cu base de datos.
#-------------------------------------
Para utilizar el certificado creado como una CA se # CONNECTIONS AND AUTHENTICATION
debe copiar con el nombre de root.crt. #-------------------------------------
# - Connection Settings -
cp server.crt root.crt
Los permisos y dueño de las llaves y certificados listen_addresses = '192.168.5.34,
generados deben ser restringidos: 192.168.5.35'
port = 5445
chmod 400 server.* max_connections = 15
chmod 400 root.crt Luego en el fichero pg_hba.conf se especificaron
chown postgres:postgres server.* las conexiones que son aceptadas por el servidor.
chown postgres:postgres root.crt A continuación, un ejemplo de los usuarios y hosts
que tienen acceso.

“VIII Taller Internacional de Tecnologías de Software Libre y Código Abierto”

 Carriles, J.; Chang, L. | “SEGURIDAD, REQUISITO INDISPENSABLE EN LA BASE DE DATOS ESTUDIO DE OPINIÓN DEL PUEBLO”
# TYPE DATABASE USER ADDRESS METHOD
# IPv4 local connections:
host all all 127.0.0.1/32 md5
hostssl db_estop ernesto
192.168.5.34/8 cert
hostssl db_estop yurixa
192.168.5.35/8 cert
Para garantizar la seguridad de los datos, se
crearon los usuarios y grupos de usuarios que se
conectarán a la base de datos db_estop, así como
sus respectivos privilegios. Entre los requisitos
cumplidos es que los usuarios que trabajan sobre
esa base de datos utilizan mayormente dentro de la
tabla opinion, las opiniones que respondan a un
tema específico, por lo que se garantizó que las
opiniones que pertenezcan al tema 1, 2 y 5 sean
accedidas solo por el grupo de usuarios1, las del
tema 3, 7 y 8 al grupo de usuarios2 y las de los
temas 4 y 6 al grupo de usuarios3.
El código utilizado para crear los usuarios fue:
db_estop=# CREATE USER ernesto ENCRYPTED
PASSWORD 'sociopolitico' NOBYPASSRLS VALID
UNTIL '2017-12-29 12:00:00'; (semejante código
para los restantes usuarios)
Es importante destacar que la contraseña de cada
usuario se actualizó con la opción \password nom-
bre_usuario de forma tal que no quedara registrada
en texto plano en los logs del postgresql
(opt/PostgreSQL/9.5/data/pg_log).
El comando para crear los grupos de usuarios fue:
db_estop=# CREATE GROUP usuarios1 USER
ernesto, yurixa, raquel, lissette, rolando, rafael;
db_estop=# CREATE GROUP usuarios2 USER
marcela, juan, ana, marbelia, pedro;
db_estop=# CREATE GROUP usuarios3 USER
alain, patricia, bety, barbara;
Es necesario otorgarle privilegios a los usuarios
para que puedan trabajar en las tablas de la base
de datos. Siempre con el principio de que se niega
todo y solo se acepta lo que se necesite.
db_estop=# REVOKE ALL PRIVILEGES ON opi-
nion FROM usuarios1, usuarios2, usuarios3, de-
nuncias;
db_estop=# GRANT SELECT, INSERT, UPDATE
ON opinion TO usuarios1, usuarios2, usuarios3,
denuncias;
Luego se crearon las políticas de seguridad de fila
para que cada usuario sólo acceda a la información
que le corresponde.
db_estop=# create policy tema_grupousuarios1 on
opinion for all to usuarios1 using (codigotema=1 or
codigotema=2 or codigotema=5)
db_estop=# create policy tema_grupousuarios2 on
opinion for all to usuarios2 using (codigotema=3 or
codigotema=7 or codigotema=8)
“VIII Taller Internacional de Tecnologías de Software Libre y Código Abierto”
db_estop=# create policy tema_grupousuarios3 on
opinion for all to usuarios3 using (codigotema=4 or
codigotema=6)
db_estop=# create policy denuncias_usuario on
opinion for update to denuncias using (codigosenti-
do=3)
Una vez creada las políticas se habilitó el nivel de
seguridad de fila en la tabla correspondiente.
db_estop=# ALTER TABLE opinion ENABLE ROW
LEVEL SECURITY;
Otro requerimiento que debe cumplir la base de
datos es que las opiniones que constituyen denun-
cia sólo sean modificadas por el especialista encar-
gado de procesarlas, y a la vez no requiere trabajar
con todos los campos de la tabla opinion, por lo que
se creó una vista que diera respuesta a la necesi-
dad.
db_estop=# CREATE OR REPLACE VIEW vis-
ta_denuncia AS select o.opinion, o.fecha,
m.nombrem, p.nombrep from opinion o join munici-
pio m on (o.codigomunicipio=m.codigo) join provin-
cia p on (o.provincia=p.codigo) where codigosenti-
do=3;
db_estop=# ALTER VIEW vista_denuncia OWNER
TO usuario_denuncia
3. CONCLUSIONES
Luego de realizada la presente investigación, se
concluye que:
• A partir del análisis en función de la
problemática planteada se comprendió la
necesidad de implementar mecanismos de
seguridad a nivel de base de datos, en términos
de garantizar la protección de la información que
se procesa.
• La implementación de certificados digitales y el
protocolo de seguridad SSL garantizó la
autenticación segura de los clientes y convirtió la
información en ininteligible para terceros.
• El empleo de privilegios y niveles de seguridad
de filas restringió el acceso de la información a
los responsables de procesarlas.
• La ejecución y puesta en práctica de
mecanismos de seguridad y autenticación
resultó un requisito para garantizar la integridad
y confidencialidad de la información.
4. AGRADECIMIENTOS
Agradecemos a las profesoras Yudisney Vazquez y
Yadira Roble, ambas MCs que aportaron un pro-
fundo conocimiento sobre PostgreSQL.
 Carriles, J.; Chang, L. | “SEGURIDAD, REQUISITO INDISPENSABLE EN LA BASE DE DATOS ESTUDIO DE OPINIÓN DEL PUEBLO”
5. REFERENCIAS BIBLIOGRÁFICAS
1. Microsoft. Microsoft, Developer Network. [En
línea] 2017. [Citado el: 14 de Agosto de 2017.]
https://msdn.microsoft.com/es-
es/library/cc434708(v=vs.71).aspx#.
2. Interout. Interout. [En línea] Interoute
Communications Limited, 2017. [Citado el: 14 de
Agosto de 2017.] http://www.interoute.es/unified-
ict/hosting/servicios-gestionados/bases-de-datos-
gestionadas/seguridad-en-bases-de-datos.
3. Ministrerio de la Informática y las
Comunicaciones. Resolución 127 Reglamento de
Seguridad para las Tecnologías de la Información.
s.l. : Gaceta Oficial de la República de Cuba Nº
057, 2007. ISSN 1682-7511.
4. The PostgreSQL Gloval Development Group.
PostgreSQL 9.5.6 Documentation. 2017, 18.3,
págs. 487-492.
5. The PostgreSQL Global Development, Group.
PostgreSQL 9.5.6 Documentation. 2017, 19, págs.
539-556.
6. Wesley Longman, Adison. An introduction to
database systems. 7th. Massachusetts : Pearson
Educación, 2010. págs. 504-532. Vol. XVI. ISBN 0-
201-38590-2.
7. The PostgreSQL Global Development Group.
PostgreSQL 9.5.6 Documentation. 2017, 20, págs.
557-561.
8. The PostgreSQL Global Development, Group.
PostgreSQL 9.5.6 Documentation. 2017, 5.6, pág.
64.
9. Guía del Programador de PostgreSQL. Las
vistas y el sistema de reglas. Guía del Programador
de PostgreSQL. [En línea] 2017. [Citado el: 15 de
Agosto de 2017.] http://es.tldp.org/Postgresql-
es/web/navegable/programmer/x895.html.
10. The PostgreSQL Global Development Group.
PostgreSQL 9.5.6 Documentation. 2017, 5.7, pág.
65.
5.1 BIBLIOGRAFÍA COMPLEMENTARIA
1. INC web hosting. El SSL, importancia e
implementación. [En línea] 20 de Marzo de 2017.
[Citado el: 15 de Agosto de 2017.]
https://www.inc.cl/hosting/el-ssl-importancia-e-
implementacion.
“VIII Taller Internacional de Tecnologías de Software Libre y Código Abierto”
2. OpenSSL. OpenSSL. Cryptography and
SSL/TLS Toolkit . [En línea] OpenSSL Software
Foundation., 2016. [Citado el: 14 de Agosto de
2017.] https://www.openssl.org.
3. Alarcón Medina, José Manuel. Curso
Administración de PostgreSQL - ITI 2007. [En línea]
[Citado el: 19 de Julio de 2017.]
www.uv.es/alarmedi/iti2007/.
4. Escobar, Javier, Ramirez, Luis y Asprino,
Omar. Integridad y Seguridad en los sistemas de
bases de Datos. 2002.
5. Riggs, Simon y Krosig, Hannu. PostgrSQL 9
Administration Cookbook. Olton : Packt Publishing,
2010. ISBN 978-1-849510-28-8.
6. Villalobos Murillo, Johnny. Principios básicos
de seguridad en bases de datos. México : s.n.,
2017, Seguridad.
6. SÍNTESIS CURRICULARES DE LOS AU-
TORES
Jessica Carriles Cardo nacida el 3 de octubre de 1991 en
Guanabacoa, La Habana, graduada de Ingeniera en Ciencias
Informáticas en la Universidad de las Ciencias Informáticas en el
año 2014. Trabaja en el Centro de Estudios Sociopolíticos y de
Opinión hace tres años, donde ha participado en seis
Investigaciones de carácter sociopolítico, además ha publicado
dos artículos en la revista “En consulta con el Pueblo” de dicha
institución titulados “CSPro una herramienta para la elaboración
y procesamiento de cuestionarios” y “Análisis de
correspondencia en Investigaciones Sociopolíticas utilizando los
softwares SPSS, R y SPAD”. Ha presentado ponencias en la VII
Conferencia Científica de Estudios Sociopolíticos y en la III
Conferencia Científica de la UCI. El 24 de julio de 2017 le fue
otorgada la categoría de Aspirante a Investigador. Actualmente
se desempeña como jefa de Seguridad Informática en su
institución.
Lienzt de la Caridad Chang Collado nacida el 14 de noviembre
de 1993 en Centro Habana, La Habana, graduada de Ingeniera
en Ciencias Informáticas en la Universidad de las Ciencias
Informáticas en el año 2016. Trabaja en el Centro de Estudios
Sociopolíticos y de Opinión hace un año, donde ha participado
en dos Investigaciones de carácter sociopolítico. Es coautora de
un artículo en la revista “En consulta con el Pueblo” de dicha
institución titulado “Análisis de correspondencia en
Investigaciones Sociopolíticas utilizando los softwares SPSS, R
y SPAD”. Presentó una ponencia en la VII Conferencia Científica
de Estudios Sociopolíticos. Actualmente se desempeña
especialista en Informática en dicha institución.