Normativa para el uso de BBDD corporativas en las ... · 4.3.3.G ESTIÓN DE LOS NOMBRES DE USUARIOS...

DGTNT-070012-TSI-NORM

Página 1 de 21

Telecomunicaciones y Sistemas Estado: Definitivo

Normativa para el uso de BBDD corporativas en lasinfraestructuras de Sistemas del Gobierno de Canarias

Rev. Fecha Descripción

04 06/09/2018Revisión completa del documento y reestructuración. Se establece el alta, pordefecto, de dos usuarios por BBDD, y la restricción de que estos usuarios nopuedan compartirse entre varias aplicaciones.

03 01/12/2015 Se actualiza el contenido referido a las características y uso de BBDD

02 30/04/2015 Se actualiza la BBDD corporativa PostgreSQL (en lugar de Oracle)

Fecha 1ª Aprobación: 02/07/2007

Documento : DGTNT-070012-TSI-NORM Normativa para el uso de BBDD corporativas en las infraestructuras de Sistemas del Gobierno de Canarias

Ubicación:https://www.gobiernodecanarias.net/cibercentro/documentos/normativas/index.htmlhttp://www.gobiernodecanarias.org/cpj/temas/tnt/cibercentro/ciber_normativa.html

Nivel de Seguridad: Público

Preparado por Revisado por Aprobado por

DGTNT_CIberCentro

Fecha: 06/09/2018

José Damián Ferrer Quintana

Fecha: 06/09/2018

Manuel Angel Castellano Trujillo

Fecha: 06/09/2018

En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada laautenticidad de esta copia, mediante el número de documento electrónico siguiente:

02wxlBEB6Tcc2zkeuoijVtJp6RWmPLkvw

http://www.gobiernodecanarias.org/cpj/temas/tnt/cibercentro/ciber_normativa.html

https://www.gobiernodecanarias.net/cibercentro/documentos/normativas/index.html

https://sede.gobcan.es/sede/verifica_doc


Página 2 de 21


ÍNDICE

1. INTRODUCCIÓN...............................................................................................................4

2. OBJETIVO.........................................................................................................................4

3. DESTINATARIOS..............................................................................................................4

4. ALCANCE..........................................................................................................................4

5. ANTECEDENTES..............................................................................................................5

6. ORGANIZACIÓN DEL SERVICIO....................................................................................6

6.1.1. COMUNICACIÓN CON LOS ADMINISTRADORES DE LA BASE DE DATOS...................................................76.1.2. COMUNICACIÓN POR PARTE DEL RESPONSABLE DE LA APLICACIÓN.......................................................86.1.3. RESPALDO Y RECUPERACIÓN DE DATOS.......................................................................................8

7. NORMATIVA GENÉRICA.................................................................................................8

7.1.1. METODOLOGÍA......................................................................................................................97.1.2. TABLAS NORMALIZADAS...........................................................................................................97.1.3. INTEGRIDAD REFERENCIAL Y REGLAS DE NEGOCIO......................................................................107.1.4. CONTROL DE LAS CONSULTAS AD HOC.......................................................................................107.1.5. NO MEZCLAR CÓDIGO DE BBDD CON CÓDIGO DE INTERFAZ...........................................................117.1.6. DEFINICIÓN DE UNA NOMENCLATURA.........................................................................................117.1.7. DOCUMENTACIÓN.................................................................................................................127.1.8. CICLO DE VIDA DE LAS APLICACIONES........................................................................................137.2.1. RACIONALIZACIÓN EN EL USO DE OBJETOS..................................................................................137.2.2. GESTIÓN DE LAS INSTANCIAS (CENTRALIZACIÓN)..........................................................................137.2.4. FUNCIONALIDADES AVANZADAS Y/O PLUGINS................................................................................147.3.1. IDENTIFICACIÓN, AUTENTICACIÓN Y AUTORIZACIÓN PARA EL ACCESO A BBDD.....................................147.3.2. ACCESOS A LAS BASES DE DATOS DE EXPLOTACIÓN.....................................................................157.3.3. PRUEBAS CON DATOS REALES.................................................................................................16

8. NORMATIVA POSTGRESQL.........................................................................................16

8.1.1. PLATAFORMA......................................................................................................................168.1.2. ACCESO A LAS BBDD DE POSTGRESQL................................................................................168.1.3. RESTRICCIONES EN LOS PRIVILEGIOS DE LA BASE DE DATOS...........................................................178.1.4. SOPORTE PARA EL JUEGO DE CARACTERES...............................................................................188.2.1. SEGUIR EL SQL ESTÁNDAR ANSI..........................................................................................18





Página 3 de 21


8.2.2. AJUSTAR SENTENCIAS SQL...................................................................................................188.2.3. SENTENCIAS PREPARADAS......................................................................................................188.2.4. PARTICIONADO DE TABLAS......................................................................................................198.2.5. NO SE PERMITE EL USO DE TABLESPACES..................................................................................198.2.6. POOL DE CONEXIONES..........................................................................................................19

9. REFERENCIAS...............................................................................................................20

10. CONTACTOS................................................................................................................21





Página 4 de 21


1. INTRODUCCIÓN

La Dirección General de Telecomunicaciones y Nuevas Tecnologías (en adelanteDGTNT) ofrece dentro de su catálogo de servicios el “Servicio avanzado de gestión ymantenimiento de bases de datos”.

Para la utilización específica de este servicio es preciso que las aplicaciones se adapten alos requisitos establecidos en esta normativa, sin excluir los definidos en disposicionesnormativas aplicables y en las “Normas y recomendaciones establecidas por la DGTNT enlos servicios ofrecidos por CiberCentro”.

2. OBJETIVO

Este documento complementa la “Normativa de las Infraestructuras Corporativas paraAplicaciones del Gobierno de Canarias”, definiendo un conjunto de especificacionesorganizativas y técnicas a tener en cuenta para el desarrollo, despliegue y, en general,gestión del ciclo de vida de las aplicaciones que pretendan hacer uso del serviciocorporativo de Base de Datos (en adelante BBDD), con el fin de asegurar la calidad y laseguridad de las mismas.

3. DESTINATARIOS

Responsables de las aplicaciones, y grupos implicados en el desarrollo/adquisición,despliegue y/o gestión de aplicaciones de los órganos y organismos asociados delGobierno de Canarias.

El personal destinatario (tanto personal del Gobierno de Canarias como empresas deservicios) realizará todos los trabajos necesarios para dar cumplimiento a los requisitosestablecidos.

4. ALCANCE

Todas las aplicaciones que deseen hacer uso del servicio corporativo de BBDD delGobierno de Canarias, con independencia de su origen y de su finalidad.





Página 5 de 21


5. ANTECEDENTES

Siguiendo instrucciones de la Comisión Superior de Informática del Gobierno de Canarias,se ha establecido PostgreSQL como Sistema Gestor de Bases de Datos corporativo(en adelante SGBD).

Sólo cuando se acredite la imposibilidad técnica de PostgreSQL para realizar lasfunciones que requiera la aplicación, se autorizará el alta de aplicaciones que

utilicen SGBDR en tecnología Oracle y SQL Server de Microsoft. No obstante, se mantendrán las BBDD actualmente existentes hasta evaluar su

migración dado el elevado coste que ello implicaría.

Las plataformas de gestores de BBDD a las que se les presta servicio pueden clasificarseen:

Corporativa: PostgreSQLSoportadas: Oracle y SQLServer A extinguir: las versiones sin soporte del fabricante: PostgreSQL, Oracle y

SQLServer

Se podrá consultar la versión corporativa de PostgreSQL en el documento “Normativasobre utilización de Herramientas y Aplicaciones corporativas en las infraestructuras deSistemas del Gobierno de Canarias”.

En las plataformas "A extinguir" no se prestan servicios avanzados, tales como BBDD derespaldo en provincia contraria, creación de clones, entornos de desarrollo omantenimientos de versionado del SGBD.

Las recomendaciones y normas establecidas en este documento se han agrupado en:➢ Normativa Genérica.➢ Normativa PostgreSQL.

Sin perjuicio de las recomendaciones y normas establecidas, será posible la introducciónde modificaciones en algunas de las pautas, siempre y cuando se pueda justificar quemejoran el resultado. En este caso, será necesario hacer constar explícitamente aquellasespecificaciones que sean cubiertas con soluciones distintas a las requeridas, justificandorazonadamente el cambio introducido, y proporcionando información detallada sobre las





Página 6 de 21


ventajas de la utilización propuesta. Las consideraciones o sugerencias que losdesarrolladores estimen oportunas realizar sobre estos extremos serán tenidas en cuentapor la DGTNT, evaluándose conforme mejor sea a los intereses del Gobierno deCanarias.

6. ORGANIZACIÓN DEL SERVICIO

6.1. Gestión del Servicio prestado por CiberCentro

Los servicios de BBDD que podrán ser prestados desde CiberCentro incluirán:

- Software• Instalación, desinstalación y actualización del SGDB• Instalación y desinstalación de parches• Conocimientos básicos de las aplicaciones de los usuarios

- Creación de BBDD.- Configuración de parámetros de funcionamiento de la BBDD.- Gestión de Usuarios (creación, baja, gestión de privilegios).- Gestión de Recursos (asignación de tablespaces, espacio en disco duro,

actualización de parámetros del sistema,...).- Backup y recuperación.- Apoyo a las Cargas de datos.- Pruebas de productos.- Documentación sobre bugs y versiones de productos.- Creación de informes de recomendación de software

• Crear y modificar programas de carga.• Ejecutar programas de carga.

- Monitorización• Accesos de los usuarios.• Rendimiento de los procesos.• Crecimiento de ficheros.• Creación de estadísticas.

- Optimización, mejoras de rendimiento.

No se ofrecerá el servicio de BBDD a aquellas Aplicaciones Departamentales querequieran grandes consumos de espacio en disco (del orden de centenares de gigas).

Consideraciones en bases de datos que albergan grandes volúmenes de datos:• Hay un aumento no lineal en los costos de mantenimiento y gestión de la/s base/s.





Página 7 de 21


• En diversos casos es más eficiente el uso de otras alternativas tales como gestoresdocumentales específicos, sistemas de ficheros, etc.

• Imposibilitan que las copias de seguridad totales en los servidores corporativoscumplan con las ventanas horarias establecidas en las políticas de copias deseguridad.

• Hacen inviable su almacenamiento y recuperación de forma eficiente en lasInstancias compartidas.

6.1.1. Comunicación con los administradores de la Base de Datos

Cualquier petición para la realización de un servicio de BBDD deberá hacerse abriendo unticket a CiberCentro por parte del responsable de la aplicación o, en su defecto, por untercero, previa autorización por escrito del responsable de la aplicación. Las peticiones setramitarán a través de los diferentes canales habilitados para ello (ver apartadoCONTACTOS).

Los técnicos y programadores podrán debatir aspectos técnicos de los SGBD, tales como:cada cuanto tiempo se necesitan estadísticas, evaluación de costos de las consultasantes de pasarlas a Explotación, sugerencias sobre nomenclatura de objetos, informaciónsobre la configuración actual de las BBDD y su influencia en el rendimiento de lasaplicaciones, previsiones de crecimiento del aplicativo, etc.

El mantenimiento y/o lanzamiento de scripts no es una tarea a la que se dé soporte desdeel departamento de BBDD debido, entre otros motivos, a que existen varios centenares deaplicaciones y varias consideraciones propias de cada aplicación a la hora de realizardichas tareas que afectan a su resultado; consideraciones tales como: la herramienta quese requiere (sqlplus, developer, ...), la variable de idioma requerida, el juego decaracteres, el análisis de la salida, el usuario desde el que se debe lanzar el script,conocimiento sobre la aplicación, conocimiento de los datos y su importancia, etc. Portodo ello, cada responsable de aplicación debe ser consciente de sus necesidades y llevara cabo los mantenimientos necesarios, estando el departamento de BBDD para darsoporte y asesoramiento a cualquier duda y/o error que pudiera surgir.

Las comunicaciones técnicas irán orientadas a:

• Construir aplicaciones más fáciles de mantener.• Construir aplicaciones bien organizadas y con tamaños de objetos adecuados para

no requerir paradas en el servicio debidas a reorganizaciones.• Crear los índices adecuados para mejorar el rendimiento.





Página 8 de 21


• Identificar problemas técnicos en las primeras fases del desarrollo.• Solucionar los conflictos entre los usuarios en línea y los proceso batch.• Hacer un ajuste (tuning) de las sentencias SQL de la aplicación.

También habrá comunicaciones funcionales a través de la lista:

• Los responsables de cada aplicación se mantendrán informados entre ellos de loscambios que sufra la aplicación.

• Se consensuará con los responsables de cada aplicación las posiblesinterrupciones del servicio.

• Se tramitarán las autorizaciones de movimientos de datos entre Desarrollo, Pre-explotación y Explotación.

Cualquier problema, sugerencia o duda que tengan que ver con BBDD se deberá crearpetición a través de SIRVETE.

6.1.2. Comunicación por parte del responsable de la aplicación

Las tareas que impliquen modificación, movimiento o borrado de datos que ya estuviesenen Explotación, necesitarán tramitar un Cambio por parte del responsable de la aplicación.

6.1.3. Respaldo y recuperación de datos

Las copias de seguridad para las máquinas que alojen BBDD están sujetas a ladisponibilidad de los recursos y a las políticas de copias de seguridad establecidas por laDGTNT. Inicialmente se va a seguir un esquema que diferencia la agenda de copias enfunción del uso de las BBDD (así sólo se copiará la estructura y datos para BBDD deExplotación y únicamente la estructura sin datos en las BBDD de Desarrollo y Pre-explotación).

Las recuperaciones parciales de datos son susceptibles de estar sujetas a la legislaciónvigente en materia de protección de datos de carácter personal, y deberán ser solicitadaspor el responsable de recuperación de cada aplicación a través del procedimiento deGestión de Cambios.

7. NORMATIVA GENÉRICA

Las normas y recomendaciones establecidas en este apartado se han agrupado en:



https://www.gobiernodecanarias.net/cibercentro/sirvete



Página 9 de 21


• Diseño de aplicaciones.• Uso de BBDD.

7.1. Diseño de aplicaciones

7.1.1. Metodología

En el diseño de aplicaciones se tendrá en cuenta la metodología a usar, lasnomenclaturas de los objetos de la base de datos, el modelo conceptual de datos yrestricciones en los privilegios de las aplicaciones en las bases de datos.

7.1.2. Tablas normalizadas

En el caso de usar diseños relacionales, las tablas deben estar debidamentenormalizadas. Después de identificar y diseñar las tablas que se requieran, el siguientepaso para el diseño de la base de datos es la normalización, que consiste en examinar losdatos que se encuentran agrupados en una tabla hasta reemplazarlos por varias tablasque resultan ser simples y predecibles, haciéndolas más fáciles de manejar.

Este proceso se realiza por las siguientes razones:

• Estructurar los datos de tal manera que se pueda establecer fácilmente la relaciónentre los mismos.

• Facilitar la recuperación de los datos para satisfacer las necesidades deinformación.

• Facilitar el mantenimiento de los datos (altas, bajas y cambios).• Reducir la necesidad de reorganizar o reestructurar la BBDD ante nuevas

necesidades de almacenamiento de información.• Reducir la posibilidad de redundancia e inconsistencias en los datos.

Por lo general, se mantendrán las tablas al menos en la tercera forma normal. Sólo encasos dónde el rendimiento lo justifique, se estudiará caso a caso para mantener tablasno normalizadas, debiéndose cumplir que:

- La desnormalización mejora ostensiblemente el rendimiento de las consultas.- Existe una baja tasa de actualizaciones sobre la tabla.- Existe una alta tasa de recuperación de datos usando el operador JOIN sobre la

tabla.





Página 10 de 21


7.1.3. Integridad Referencial y Reglas de Negocio

La integridad referencial es un mecanismo para asegurar que los cambios que se hacenen la BBDD por usuarios autorizados no resultan en una pérdida de consistencia de losdatos, forzando a que los registros de tablas relacionadas sean válidos y que no se borreno cambien datos relacionados de forma accidental produciendo errores de integridad.

Los Gestores de BBDD relacionales (RDBMS) gestionan desde hace años la integridadreferencial, simplificando así la tarea de programación. Siempre será más seguro y muchomás eficiente hacer que dicha integridad referencial la maneje el RDBMS, que hacerlomediante programación.

Por los mismos motivos, se aconseja codificar las reglas de negocio a través derestricciones (constraints) y de disparadores (triggers) dentro de la BBDD, en lugar dehacerlo en la aplicación.

7.1.4. Control de las consultas ad hoc

Las consultas ad-hoc contra BBDD de Explotación son muy útiles para los usuarios alpermitir una gran flexibilidad en la forma de obtener los datos. Pero en entornos en que labase de datos de Explotación es compartida por varias aplicaciones críticas, no ponerlímites a esos accesos puede generar consultas en extremo costosas, maliciosas, osimplemente erróneas, que repercutan drásticamente en los tiempos de respuesta deusuarios inocentes.

Por ello, la posibilidad de crear consultas dinámicas por parte de los usuarios debe estarcontrolada por la aplicación, evitando la generación de consultas indiscriminadas y sinfiltros contra tablas de millones de filas. Las consultas contra las tablas más grandesdeberán hacerse, siempre que sea posible, usando índices y restringiendo el número defilas máximo que deba entregar el SGBD al usuario.

Ejemplo: No tiene sentido que un usuario busque en una tabla con el censo, a todos las personas que se apelliden “Pérez”. Estaconsulta devolvería decenas de miles de filas que no podrían ser tratadas por el usuario en una lista desplegable.

En definitiva: Hay que evitar que el usuario pueda dinámicamente generar consultaspesadas que no sean estrictamente necesarias.

En el caso de ser indispensables dichas consultas y procesos más pesados, deberánlanzarse fuera del horario laboral, a partir de las 20:00 horas. Si fuesen tareas periódicas,se comunicará al departamento de BBDD de la DGTNT para planificarlas dentro de una





Página 11 de 21


agenda global para la Base de datos y para la propia máquina, de conformidad con losapartados 6.1.1 Comunicación con los administradores de la Base de Datos y 6.1.2Comunicaciones por parte del responsable de la aplicación. Así se evitará que interfieracon otros procesos de mantenimiento de otras aplicaciones o de otros componentessoftware de la máquina que aloja la BBDD.

7.1.5. No mezclar código de BBDD con código de interfaz

Dado el coste de mantenimiento de las aplicaciones que mezclan código de interfaz ycódigo de acceso a los datos, se aconseja dividir la lógica de la aplicación usando, porejemplo, diseño de patrones como “modelo-vista-controlador (MVC)”. MVC obliga aseparar el código entre el “Modelo” (componentes que alojan el código de acceso a laBBDD), vista (componentes que definen la interfaz de usuario), y controlador (objetos quegestionan las acciones de los usuarios).

7.1.6. Definición de una nomenclatura

Toda aplicación deberá poseer una guía de estilo, donde se defina una forma de nombrarlos diferentes objetos a crear en una base de datos. En dicha guía se recogerán las reglasa seguir para conseguir una uniformidad en los nombres de todos los objetos de laaplicación.

Definir una nomenclatura permite una forma estándar de referenciar a los objetos de unaBBDD. Además, si dicha nomenclatura expresa el propósito del objeto, se puedeneliminar muchas preguntas sobre la funcionalidad de los objetos. En el caso de usarabreviaciones, habrá que especificar en la propia nomenclatura cual es la forma deobtener dichas abreviaciones.

Sería conveniente cumplir las siguientes recomendaciones en dicha guía de estilo:

• Todo nombre debe comenzar por una letra.• No se deben usar como nombre palabras reservadas o caracteres especiales

(salvo el ‘_’).• Todos los nombres deben tener el mismo número (plural o singular).• Los nombres definitivos, una vez incluidos los afijos (elementos que se anteponen,

interponen o posponen a una palabra), no superarán en ningún caso los 30caracteres.

• Los afijos que se incluyan en los nombre se unirán a estos mediante un guión bajo(‘_’). Ejemplo con el afijo (‘TB’): PERSONAL_TB o TB_PERSONAL oPERSONAL_TB_PERSONAS.





Página 12 de 21


7.1.7. Documentación

La documentación deberá ser completa. El material adjunto a la aplicación permitirá elcompleto entendimiento de la misma, y en caso necesario la continuación ymantenimiento de la aplicación.

Se consultará el procedimiento de Gestión de la Entrega para el alta de las aplicacionesen los sistemas corporativos.

En el ámbito de Bases de datos deberá contarse con:

- Un diagrama de Clases/objetos dónde se detallen las entidades y sus relaciones(Opcional).

- Un script* de generación de todos los objetos creados por la aplicación(Obligatorio).

- Un documento donde se describan cada uno de los objetos creados en la base dedatos, tipos de datos, dimensionamiento, uso, … (Obligatorio).

*Nota: Los scripts de creación de objetos, en la medida de lo posible, deben especificar explícitamente las ordenaciones y máscaras de conversiones que necesiten los comandos, en lugar de confiar en los comportamientos por defecto de dichas sentencias.

Toda modificación a los objetos de la BBDD debería ser hecha dentro de un “Sistema deControl de Versiones” que asegure la estabilidad de la aplicación:

- Almacenando los scripts de cada cambio- Suministrando una información histórica de los cambios- Facilitando la marcha atrás de cambios no deseados

Todo lo anterior sin perjuicio de los documentos adicionales que sean necesarios para elcorrecto cumplimiento de la legislación vigente en materia de seguridad, como porejemplo, en los casos en los que sea de aplicación, el Reglamento General de Protecciónde Datos1 (RGPD en adelante) establece la obligación de disponer de un Registro de lasActividades de Tratamiento en el que se debe incluir, entre otros, una descripción de lascategorías de datos personales y, cuando sea posible, una descripción general de lasmedidas técnicas y organizativas de seguridad aplicadas. En el alta de una BBDD, elresponsable deberá indicar si ésta almacenará datos de carácter personal y, en caso

1Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo de 27 de abril de 2016 relativo a la protección de las personasfísicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos y por el que se deroga la Directiva95/46/CE.





Página 13 de 21


afirmativo, deberá adjuntar información que acredite el correspondiente registro deltratamiento de datos.

7.1.8. Ciclo de vida de las aplicaciones

Conforme a la “Normativa de las Infraestructuras Corporativas para Aplicaciones delGobierno de Canarias”, deberán existir entornos de Pre-explotación y Desarrollo, a losque los desarrolladores tendrán acceso para realizar las tareas que consideren oportunas(pruebas, estadísticas, cargas masivas,…) previo paso a Explotación

La realización de cualquier tarea pesada que pueda interferir en el normal rendimiento demotor de la BBDD de Explotación deberá ser consultada y aprobada por el departamentode BBDD de la DGTNT. Se determinará cuál es la forma más inocua de llevar a cabo latarea, se planificará y, si fuese preciso, se notificará a los demás responsables deaplicaciones de las posibles repercusiones en el rendimiento que podrían producirsedurante dichos procesos de mantenimiento.

7.2. Uso de las BBDD

7.2.1. Racionalización en el uso de objetos

Todo objeto de la BBDD que se cree deberá tener una finalidad, eliminando en la medidade lo posible objetos que no se usan, aquellos obsoletos de versiones anteriores delaplicativo, etc.

No se permitirá, salvo por mantenimientos o procesos especiales, la presencia enExplotación de:

- Objetos deshabilitados.- Objetos inválidos.- Objetos que no se usen.

7.2.2. Gestión de las instancias (Centralización)

Para poder prestar un servicio adecuado, con un alto nivel de calidad, es necesaria lacentralización en pocos gestores de BBDD, de forma que las aplicaciones convivan enuna sola instancia. Debido a los costes tanto de Administración/Gestión como de licenciasse hace inabordable cualquier esquema descentralizado de las BBDD, en el que cadanueva aplicación requiera de una instancia propia.





Página 14 de 21


Sólo en el caso de aplicaciones críticas y cuando se hayan agotado todas lasposibilidades de una instalación acorde a la arquitectura de la organización, esta deberíaadaptarse a una aplicación.7.2.3.

7.2.4. Funcionalidades avanzadas y/o plugins

Antes de usar dentro del SGBD cualquier funcionalidad avanzada o plugin, como pudieranser capacidades de particionado o datos espaciales, debe asegurarse que dicho uso norequiera un licenciamiento adicional, y su uso debe ser explícitamente autorizado por eldepartamento de BBDD.

7.3. Seguridad

7.3.1. Identificación, autenticación y autorización para el acceso a BBDD

Cada aplicación dispondrá, por defecto, de dos usuarios de base de datos.Adicionalmente, en los casos que se autoricen, previa petición del responsable de laaplicación, se podrá crear un usuario adicional de BBDD de solo lectura, bien en elmomento del alta de la BBDD, o si la solicitud es posterior al alta, debiendo detallarse enla solicitud la instancia y base de datos a la que se quiere acceder.

Las características de cada usuario son las siguientes:

Nomenclatura Descripción Permisos asignados

<<nombre de aplicación>>-own-bd Usuario creado por defectopara uso restringido y limitadoa la realización de tareas deadministración de la BBDD(gestión de permisos, creacióny eliminación de tablas, etc.).

Propietario de la BBDD(owner).

<<nombre de aplicación>>-bd Usuario creado por defectopara la integración de laaplicación con la BBDD.

Permisos iniciales de sólolectura. Permisos necesariosa configurar por elresponsable de la aplicación.

<<nombre de aplicación>>-ro-bd Usuario creado a demanda,en los casos que se autoricen.

Permisos iniciales de sólolectura. Permisos necesariosa configurar por elresponsable de la aplicación.





Página 15 de 21


En todo caso, la gestión de los permisos dentro de una base de datos (si el SGBD esPostgreSQL) o una instancia (si el SGBD es Oracle o SQLServer) para los usuarios queno sean propietarios de la BBDD, es competencia del responsable de la aplicación, segúnsus necesidades conforme al principio de mínimo privilegio, haciendo uso del usuariopropietario de la BBDD. El departamento de BBDD sólo otorgará permiso de acceso a labase de datos o la instancia, según el caso.

Los usuarios de BBDD son exclusivos de cada aplicación, por lo que no podrán sercompartidos entre diferentes aplicaciones.

Todos los usuarios de BBDD se autenticarán en el directorio corporativo y estaránintegrados en el servicio de Gestión de Identidades del Gobierno de Canarias, siempreque sea técnicamente posible. En todo caso, las contraseñas de los usuarios de BBDDdeberán cumplir con las directrices de seguridad especificadas en la Normativa deContraseñas del Gobierno de Canarias.

Los usuarios finales de la aplicación sólo podrán acceder a la BBDD a través de laaplicación, mediante su usuario personal correspondiente, impersonado a través delusuario de integración con base de datos.

7.3.2. Accesos a las bases de datos de Explotación

No está permitido el uso de programas ajenos a las aplicaciones para acceder a los datosde Explotación (Citrix,TOAD, Access, SQLPlus, ...) ya que esta práctica supone un riesgo,tanto para la integridad como para la seguridad de los datos, y además este tipo deconexiones a la BBDD se saltan las auditorías y los posibles controles de acceso queestuviesen implementados en la aplicación.

Si fuese totalmente necesario el acceso a los datos de Explotación de forma externa a laaplicación, excepcionalmente podrá autorizase la creación de un usuario de sólo lectura,restringido a los datos mínimos necesarios y conforme a las normativas de seguridadestablecidas, para preservar la integridad de los datos y minimizar los riesgos, evitandosiempre el uso del usuario propietario de la aplicación.





Página 16 de 21


7.3.3. Pruebas con datos reales

De conformidad con el Esquema Nacional de Seguridad2 (ENS en adelante), las pruebasanteriores a la implantación o modificación de los sistemas de información no serealizarán con datos reales salvo que se asegure el nivel de seguridad correspondiente.

Por tanto, no se deben emplear datos reales en los entornos de Desarrollo y Pre-explotación, salvo que se cumplan todos los requisitos de seguridad requeridos en el ENSy, en su caso, en la normativa vigente en materia de protección de datos de carácterpersonal.

8. NORMATIVA POSTGRESQL

A lo largo del presente apartado se hace mención al Sistema Gestor de Base de DatosObjeto-Relacional PostgreSQL, llamándolo también SGBDOR y motor de la Base deDatos. En nomenclatura PostgreSQL, una BBDD es una estructura física (ficheros) queposee múltiples esquemas que agrupan de forma lógica los objetos de la aplicación oproyecto.

Las normas y recomendaciones se han agrupado en:

• Diseño de aplicaciones.• Optimización de aplicaciones.

8.1. Diseño de aplicaciones

8.1.1. Plataforma

Actualmente se ofrece, con carácter general, los entornos de Explotación y Pre-explotación.

8.1.2. Acceso a las BBDD de PostgreSQL

Los accesos de los usuarios a las distintas BBDD alojadas en las instancias ubicadasdentro de la arquitectura corporativa, en los entornos de Desarrollo y Pre-explotación,podrán realizarse con el cliente nativo psql, con herramientas visuales disponibles en el

2Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la AdministraciónElectrónica.





Página 17 de 21


mercado (por ejemplo, pgAdmin III) o con cualquier otra aplicación que soporte losconectores del tipo JDBC u ODBC.

Actualmente se dispone de varios gestores de BBDD que alojan la Pre-explotación y laExplotación, datos que, junto con el usuario y la contraseña, permiten al cliente estableceruna sesión en cualquier tipo de conexión. Valga la siguiente instrucción como ejemplo deacceso desde línea de comando:

shell> psql -h Servidor -U Usuario -W

Con objeto de establecer un mayor nivel de seguridad, es posible limitar los orígenes deconexión por medio del archivo de configuración ‘pg_hba.conf’. A tal fin, es deseabledeterminar los equipos desde los cuales se establecerán las sesiones de usuario, y, de lamisma forma, se podrá requerir tanto la BBDD específica a la que se requiere accederdesde dichos equipos, como el usuario y el método de autenticación que usará paraestablecer la conexión, permitiéndose por defecto únicamente autenticación LDAP.

Así mismo, quedan deshabilitados los inicios de sesión desde los propios servidores quealojan los sistemas gestores de BBDD.

8.1.3. Restricciones en los privilegios de la Base de datos

Cada aplicación debe crear y gestionar sus propios esquemas en la BBDD dePostgreSQL que se le asigne (en adelante {BBDD_ENTREGADA}), dejando el esquema"public" sin uso, pues dicha actuación supone un problema de seguridad. En las BBDDentregadas se realizará explícitamente un REVOKE:

"revoke connect on database {BBDD_ENTREGADA} from public; "

Cada aplicación/proyecto podrá poseer una o varias BBDD de las cuales será propietarioen exclusiva. Con ello se garantiza que pueda realizar cualquier operación con su BBDDsin interferir con el resto de usuarios. En caso de necesitarse acceso entre distintasaplicaciones que trabajen conjuntamente, deberá evaluarse la posibilidad de crear unaúnica BBDD dónde podrían crearse tantos esquemas como sean necesarios.

Para cualquier operación que requiera el acceso o modificación de datos o parámetros noexclusivos de las BBDD que posee, se deberá dirigir consulta al Departamento de BBDDde la DGTNT para su estudio y evaluación.





Página 18 de 21


8.1.4. Soporte para el Juego de Caracteres

Por defecto se seleccionará el juego de caracteres (encoding) UTF8 debido a que ofrecetotal compatibilidad con cualquiera de los distintos encodings disponibles para los clientesque deban conectarse con las BBDD presentes en la instancia.

El juego de caracteres por defecto es seleccionado al inicializar la instancia dePostgreSQL. No obstante, cada Base de Datos particular dentro de la instancia puedetener su propio juego de caracteres diferente al especificado por defecto, ya que durantela creación de las mismas está permitido definir uno diferente.

Es responsabilidad de los usuarios seleccionar el juego de caracteres que mejor seadapte a las necesidades de sus aplicaciones.

8.2. Optimización de Aplicaciones

8.2.1. Seguir el SQL estándar ANSI

Se recomienda seguir en la medida de lo posible el SQL estándar ANSI ya quePostgreSQL posee varias mejoras/añadidos al mismo y al usar estas características seestá limitando la posibilidad de adaptar la aplicación a algún otro motor RDBMS,perdiendo portabilidad.

8.2.2. Ajustar sentencias SQL

PostgreSQL aporta el comando “EXPLAIN”, el cual muestra el plan de ejecución que elplanificador genera para la sentencia (SELECT, INSERT, UPDATE, etc.) pasada comoargumento. La parte más importante del resultado mostrado por el comando es el costeestimado de la ejecución de la sentencia.

Es muy recomendable que en cada aplicación se identifique, analice y ajuste todaconsulta que pueda suponer un coste de ejecución elevado.

8.2.3. Sentencias preparadas

A diferencia de otros SGBD, PostgreSQL parsea cada sentencia que recibeindependientemente de si se usan ‘bind variables’ o no. Sin embargo, cuenta con unaforma de emular dicho comportamiento y es mediante el comando “PREPARE”.





Página 19 de 21


Una sentencia ‘preparada’ es un objeto en el lado del servidor que es usado paraoptimizar el rendimiento de ejecución de dicha sentencia. La ‘preparación’ de la sentenciaimplica su parseo, análisis y re-escritura; su posterior ‘ejecución’ conlleva únicamente lasfases de planificación y ejecución, por lo que sucesivas ejecuciones con distintosparámetros se beneficiarán de la ‘preparación’ inicial.

Se recomienda hacer uso de esta característica especialmente en bucles y algoritmosrepetitivos que, por su naturaleza, requieran la ejecución de la misma sentencia con losmismos parámetros pero con valores diferentes.

8.2.4. Particionado de tablas

El particionado consiste en la división física de una tabla en pequeñas partes másmanejables, lo que provee una mejora de rendimiento importante en muchas situaciones.Todas aquellas tablas de tamaño considerable (datos históricos, auditorías, etc.) sonbuenas candidatas para ser particionadas.

8.2.5. No se permite el uso de Tablespaces

Aunque PostgreSQL soporta el uso de Tablespaces, en los servicios corporativos dePostgreSQL no se permite su uso.

8.2.6. Pool de conexiones

El SGBDOR PostgreSQL para su eficaz desempeño debe ser accedido por el menornúmero de sesiones posible. Por ello se establecerán pooles de conexiones en losservidores de aplicación.

Para un mejor aprovechamiento de los recursos de los servidores de BBDD(especialmente RAM) se limitará el número de conexiones permitidas a 50.

Hay que considerar que ni los productos pgbouncer ni pgpool soportan validación LDAP,véase:https://pgbouncer.github.io/config.html#examplehttp://www.pgpool.net/docs/latest/pgpool-en.html#hba



http://www.pgpool.net/docs/latest/pgpool-en.html#hba

https://pgbouncer.github.io/config.html#example



Página 20 de 21


9. REFERENCIAS

9.1. Documentos externos a la organización

Documento Disposiciones normativas nacionales aplicables a las Administraciones Públicas

Ubicación https://www.boe.es/

Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad enel ámbito de la Administración Electrónica.

Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo de 27 de abril de 2016 relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos y por el que se deroga la Directiva 95/46/CE.

Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal.

Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollode la LOPD.

Documento Disposiciones normativas autonómicas aplicables a la Administración Pública de laComunidad Autónoma de Canarias

Ubicación http://www.gobiernodecanarias.org/boc/

Resolución de Presidencia del Gobierno de 25 de junio de 2018, por el que se dispone lapublicación del Acuerdo que aprueba las instrucciones que conforman la Normativa de seguridaden el uso de los recursos informáticos, telefónicos y de redes de comunicación de laAdministración Pública de la Comunidad Autónoma de Canarias.

9.2. Documentos internos a la organización

Documento Normas y recomendaciones establecidas por la Dirección General deTelecomunicaciones y Nuevas Tecnologías (DGTNT) en los servicios ofrecidos porCiberCentro

Ubicación https://www.gobiernodecanarias.net/cibercentro/documentos/normativas/index.html

Normativa sobre utilización de herramientas y aplicaciones corporativasNormativa de las Infraestructuras Corporativas para Aplicaciones del Gobierno de Canarias



https://www.gobiernodecanarias.net/cibercentro/documentos/normativas/index.html

http://www.gobiernodecanarias.org/boc/

https://www.boe.es/



Página 21 de 21


Normativa de contraseñas del Gobierno de CanariasNormativa sobre los requisitos de Seguridad en Aplicaciones WebNormativa de uso de los servicios de Directorio Corporativo

Documento Procesos de ITIL

Ubicación https://www.gobiernodecanarias.net/cibercentro/documentos/procesos_itil/index.html

Procedimiento de Gestión de CambiosProcedimiento de Gestión de la Entrega

Documento FAQ para desarrolladores de aplicaciones alojadas en la infraestructura corporativade Gobierno de Canarias

Descripción Respuestas a las consultas más frecuentes

Ubicación https://www.gobiernodecanarias.net/cibercentro/documentos/soporte/index.html

10.CONTACTOS

Persona de contacto CiberCentro

Acceso Web https://www.gobiernodecanarias.net/cibercentro/sirvete

Correo electrónico [email protected]

Teléfono interno 912

Teléfonos 902 111 912 - 922 922 912 - 928 117 912

Este documento ha sido firmado electrónicamente por:

MANUEL ANGEL CASTELLANO TRUJILLO - DIRECTOR GNRAL.TELECOMUNICACIONES Y N.T.JOSE DAMIAN FERRER QUINTANA - JEFE AREA TELECOMUNICAC.Y SISTEMASHERLINDA HERNANDEZ PERERA - JEFE DE PROYECTO

Fecha: 07/09/2018 - 14:55:39Fecha: 06/09/2018 - 12:32:23Fecha: 06/09/2018 - 12:25:15



El presente documento ha sido descargado el 10/09/2018 - 08:11:12

mailto:[email protected]

https://www.gobiernodecanarias.net/cibercentro/incidencias/

https://www.gobiernodecanarias.net/cibercentro/documentos/procesos_itil/index.html

https://www.gobiernodecanarias.net/cibercentro/documentos/procesos_itil/index.html


Normativa para el uso de BBDD corporativas en las ... · 4.3.3.G ESTIÓN DE LOS NOMBRES DE USUARIOS...

Documents

Transcript of Normativa para el uso de BBDD corporativas en las ... · 4.3.3.G ESTIÓN DE LOS NOMBRES DE USUARIOS...