DGTNT-070012-TSI-NORM
Página 1 de 19
Telecomunicaciones y Sistemas
Estado: Definitivo
Normativa para el uso de BBDD corporativas en las infraestructuras de Sistemas del Gobierno de Canarias
Rev.
Fecha
Descripción
03
01/12/15
02
30/04/2015
Se actualiza la BBDD corporativa PostgreSQL (en lugar de Oracle)
01
26/03/2015
Se adapta a la nueva plantilla DGTNT
Se actualiza el contenido referido a las características y uso de BBDD.
Fecha 1ª Aprobación
26/03/2015
Documento:
DGTNT-070012-TSI-NORM Normativa para la utilización Corporativa de BBDD en las Infraestructuras de Sistemas del Gobierno de Canarias.odt
Ubicación:
http://www.gobiernodecanarias.net/cibercentro/documentos/normativas/index.html http://www.gobiernodecanarias.org/cpj/temas/tnt/cibercentro/ciber_normativa.html
Nivel de Seguridad:
Público
Preparado por
Revisado por
Aprobado por
DGTNT
José Damián Ferrer Quintana
Francisco Javier García Latorre
Fecha: 01/12/2015
Fecha: 21/12/2015
Fecha: 21/12/2015
En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada la autenticidad de esta copia, mediante el número de documento electrónico siguiente:
0CjX5SHFPhSvPNiwQq9XFu8B1epgOUyJ0
DGTNT-070012-TSI-NORM
Página 2 de 19
ÍNDICE 1.INTRODUCCIÓN...............................................................................................................3 2.ÁMBITO............................................................................................................................4 3.ANTECEDENTES.............................................................................................................4 4.NORMATIVA GENÉRICA.................................................................................................5 4.1.GESTIÓN DEL SERVICIO PRESTADO POR CIBERCENTRO.....................................................................5 4.1.1.COMUNICACIÓN CON LOS ADMINISTRADORES DE LA BASE DE DATOS.............................................6 4.1.2.COMUNICACIÓN POR PARTE DEL RESPONSABLE DE LA APLICACIÓN................................................7 4.1.3.RESPALDO Y RECUPERACIÓN DE DATOS....................................................................................7 4.2.DISEÑO DE APLICACIONES..............................................................................................................8 4.2.1.METODOLOGÍA.......................................................................................................................8 4.2.2.TABLAS NORMALIZADAS...........................................................................................................8 4.2.3.INTEGRIDAD REFERENCIAL Y REGLAS DE NEGOCIO ...................................................................9 4.2.4.DOCUMENTACIÓN...................................................................................................................9 4.2.5.DRÁSTICA REDUCCIÓN DE LAS CONSULTAS AD HOC...................................................................10 4.2.6.NO MEZCLAR CÓDIGO DE BBDD CON CÓDIGO DE INTERFAZ......................................................11 4.2.7.DEFINICIÓN DE UNA NOMENCLATURA.......................................................................................11 4.2.8.CICLO DE VIDA DE LAS APLICACIONES......................................................................................11 4.3.USO DE LAS BBDD....................................................................................................................12 4.3.1.ACCESOS A LAS BASES DE DATOS DE EXPLOTACIÓN..................................................................12 4.3.2.RACIONALIZACIÓN EN EL USO DE OBJETOS...............................................................................12 4.3.3.GESTIÓN DE LOS NOMBRES DE USUARIOS EN LA BASE DE DATOS................................................12 4.3.4.GESTIÓN DE LAS INSTANCIAS (CENTRALIZACIÓN)......................................................................13 4.3.5.PRUEBAS CON DATOS REALES................................................................................................13 4.3.6.FUNCIONALIDADES AVANZADAS Y/O PLUGINS............................................................................13
5.NORMATIVA POSTGRESQL.........................................................................................13 5.1.DISEÑO DE APLICACIONES............................................................................................................14 5.1.1.PLATAFORMA.......................................................................................................................14 5.1.2.ACCESO A LAS BBDD DE POSTGRESQL...............................................................................14 5.1.3.RESTRICCIONES EN LOS PRIVILEGIOS DE LA BASE DE DATOS......................................................15 5.1.4.DEFINICIÓN DE UNA NOMENCLATURA.......................................................................................15 5.1.5.SOPORTE PARA EL JUEGO DE CARACTERES............................................................................16 5.1.6.COPIAS DE SEGURIDAD. .......................................................................................................16 5.1.7.CICLO DE VIDA DE LAS APLICACIONES.....................................................................................16 5.2.OPTIMIZACIÓN DE APLICACIONES..................................................................................................17 5.2.1.SEGUIR EN LA MEDIDA DE LO POSIBLE EL SQL ESTÁNDAR ANSI................................................17 5.2.2.AJUSTAR SENTENCIAS SQL...................................................................................................17 5.2.3.SENTENCIAS PREPARADAS.....................................................................................................18 5.2.4.PARTICIONADO DE TABLAS.....................................................................................................18 5.2.5.POOL DE CONEXIONES..........................................................................................................18
6.REFERENCIAS...............................................................................................................18 7.CONTACTOS..................................................................................................................19
En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada la autenticidad de esta copia, mediante el número de documento electrónico siguiente:
0CjX5SHFPhSvPNiwQq9XFu8B1epgOUyJ0
DGTNT-070012-TSI-NORM
Página 3 de 19
1. INTRODUCCIÓN Este documento define las especificaciones técnicas y normativas sobre las nuevas aplicaciones que se desarrollen para la prestación de un servicio del Gobierno de Canarias y que vayan a ser alojadas en servidores corporativos. La documentación estará orientada a describir tanto los objetivos a cubrir como los requisitos técnicos generales y específicos necesarios para la realización de aplicaciones. Con el fin de asegurar la calidad de las mismas, pretende enmarcar los aspectos organizativos y las etapas de desarrollo de las aplicaciones. Las normas descritas en estos documentos constituirán, pues, el marco que se considera más adecuado sobre el desarrollo de software para el Gobierno de Canarias. Sin embargo, si se cree conveniente, será posible la introducción de modificaciones en algunas de las pautas, siempre y cuando puedan justificar que mejoran el resultado. En este caso, será necesario hacer constar, explícitamente, aquellas especificaciones que sean cubiertas con soluciones distintas a las requeridas, justificando razonadamente el cambio introducido y proporcionando información detallada sobre las ventajas de la utilización propuesta. Las consideraciones o sugerencias que los desarrolladores estimen oportunas realizar sobre estos extremos serán tenidas en cuenta por la Dirección General de Telecomunicaciones y Nuevas Tecnologías (en adelante DGTNT), evaluándose conforme mejor sea a los intereses de la Administración. Los desarrolladores de software para el Gobierno de Canarias (tanto personal de la propia Comunidad como empresas de servicios ) realizarán todos los trabajos necesarios para conseguir los objetivos fijados en estos documentos. El objetivo final será “estandarizar el desarrollo informático en la C.A.C.” mediante la promulgación de un conjunto de reglas obligatorias que admitan la obtención de software con características que permitan los siguientes aspectos: •
• • •
•
Cumplir la legislación vigente relacionada con la seguridad de la información (LOPD1 y ENS2), así como otras normativas de seguridad (Norma UNEISO/IEC27002: Código de buenas prácticas para la gestión de la seguridad de los sistemas de información). Crear planes de contingencia para minimizar los efectos negativos frente a siniestros. Facilitar el Alojamiento (Hosting) y/o futura migración de la aplicación a entornos gestionados por la DGTNT y que prestan un servicio corporativo. Generar durante el desarrollo una documentación completa de la aplicación. Este material, adjunto a la aplicación, permitirá el completo entendimiento de la misma, y en caso necesario la continuación y mantenimiento de la aplicación. Minimizar los costes de mantenimiento.
Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal.
1
Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica.
2
En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada la autenticidad de esta copia, mediante el número de documento electrónico siguiente:
0CjX5SHFPhSvPNiwQq9XFu8B1epgOUyJ0
DGTNT-070012-TSI-NORM
Página 4 de 19
• • • • •
Aprovechar al máximo los recursos disponibles. Asegurar la calidad del software desarrollado. Facilitar la integración de la aplicación con otros sistemas de la organización. Estimar las necesidades de recursos de la aplicación. Fijar el marco mínimo de Políticas de copias de Seguridad.
2. ÁMBITO Este documento va dirigido a los responsables de las aplicaciones así como a los jefes de proyectos y equipos encargados del desarrollo y despliegue de las aplicaciones del Gobierno de Canarias. 3. ANTECEDENTES La DGTNT ofrece dentro de su catálogo de servicios el “Servicio avanzado de gestión y mantenimiento de bases de datos”. Para la utilización específica de este servicio es preciso que las aplicaciones se adapten a los requisitos establecidos en esta normativa, sin excluir los que se definan en la “Normas y recomendaciones establecidas por la DGTNT en los servicios ofrecidos por CiberCentro”. Siguiendo instrucciones de la Comisión Superior de Informática del Gobierno de Canarias, se ha establecido PostgreSQL como gestor de bases de datos corporativo. Solo cuando se acredite la imposibilidad técnica de PostgreSQL para realizar las funciones 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 clasificarse en : Corporativas : PostgreSQL 9.3 Soportadas: Oracle 11g R2 y Sqlserver 2008 R2 A extinguir: Oracle 10g , Mysql 5.1 En las plataforma "A extinguir" no se prestan servicios avanzados, tales como BBDD de respaldo en provincia contraria, creación de clones, entornos de desarrollo o mantenimientos de versionado del SGBD. Las recomendaciones y normas se han agrupado en: ➢ Normativa Genérica. ➢ Normativa PostgreSQL
En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada la autenticidad de esta copia, mediante el número de documento electrónico siguiente:
0CjX5SHFPhSvPNiwQq9XFu8B1epgOUyJ0
DGTNT-070012-TSI-NORM
Página 5 de 19
4. NORMATIVA GENÉRICA 4.1. Gestión del Servicio prestado por CiberCentro
Los servicios de BBDD que podrán ser prestados desde CiberCentro incluirán: - Software • Instalación, desistalación y actualización del SGDB • Instalación y desistalación de parches • Conocimientos básicos de las aplicaciones de los usuarios - Creación de BBDD - Configuración 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 que requieran grandes consumos de espacio en disco (del orden de centenares de gigas). Consideraciones en bases de datos que albergan grandes volumenes de datos: • Hay un aumento no lineal en los costos de mantenimiento y gestión de la/s base/s. • •
•
En diversos casos es más eficiente el uso de otras alternativas tales como gestores documentales específicos, sistemas de ficheros,etc Imposibilitan que las copias de seguridad totales en los servidores corporativos cumplan con las ventanas horarias establecidas en las políticas de copias de seguridad. Hacen inviable su almacenamiento y recuperación de forma eficiente en las Instancias compartidas.
En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada la autenticidad de esta copia, mediante el número de documento electrónico siguiente:
0CjX5SHFPhSvPNiwQq9XFu8B1epgOUyJ0
DGTNT-070012-TSI-NORM
Página 6 de 19
4.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 una incidencia al CiberCentro a través de los diferentes canales habilitados para ello (ver apartado CONTACTOS). . Para poder ofrecer un mejor servicio es necesario crear un canal abierto de comunicación entre los usuarios, responsables de aplicación, programadores y los técnicos. La relación se formalizará mediante una lista de distribución de correo asociada a cada aplicación. En dicha lista, los responsables de cada aplicación podrán solicitar la realización de tareas. Los técnicos y programadores podrán debatir aspectos técnicos de los SGBD (cada cuanto tiempo se necesitan estadísticas, evaluación de costos de las consultas antes de pasarlas a explotación, sugerencias sobre nomenclatura de objetos, información sobre la configuración actual de las bases de datos y su influencia en el rendimiento de las aplicaciones, previsiones de crecimiento del aplicativo...). 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. 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 los cambios que sufra la aplicación. Se consensuará con los responsables de cada aplicación las posibles interrupciones del servicio. Se tramitarán las autorizaciones de movimientos de datos entre Desarrollo, Preexplotación y Explotación.
Cualquier problema, sugerencia o duda que tengan que ver con BBDD podrán dirigirse al Departamento de Bases de Datos usando el siguiente correo electrónico:
[email protected]
En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada la autenticidad de esta copia, mediante el número de documento electrónico siguiente:
0CjX5SHFPhSvPNiwQq9XFu8B1epgOUyJ0
DGTNT-070012-TSI-NORM
Página 7 de 19
4.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 estuviesen en explotación, necesitarán notificación por escrito por parte del responsable de la aplicación. 4.1.3. Respaldo y recuperación de datos
Las políticas de copias de seguridad para las máquinas que alojen BBDD (PostgreSQL) están sujetas a la disponibilidad de los recursos. Inicialmente se va a seguir un esquema que diferencia la agenda de copias en función del uso de las BBDD (así sólo se copiara la estructura y datos para BBDD de Explotación y únicamente la estructura sin datos en las BBDD de Desarrollo y Preexplotación). Además, se harán agendas con políticas independientes para el sistema operativo, las copias físicas y las copias lógicas de la BBDD: Copia Tipo 1.- Sistemas Operativos: Un ciclo de dos o tres copias totales, una copia por mes. Copia Tipo 2.- BBDD – Copia física de BBDD en explotación: ◦ Copia realizada sin cortar el servicio en caso de soportarlo el SGBD. ◦ Se realizan copias incrementales diarias (incluyendo los archivos de transacciones) durante una semana. Nota: Este tipo de backup no estará disponible para MySQL Copia Tipo 3.- BBDD- Copia lógica de la BBDD en explotación: ◦ Se usan los ficheros de exports (dmp). ◦ Se realizan una copia mensual. ◦ Un ciclo de 60 copias totales (5 años), una copia de cada mes. Copia Tipo 4.- BBDD – Copia lógica de la BBDD de Desarrollo o Preexplotación sin datos (solo estructuras): ◦ Se usan los ficheros de exports (dmp) SIN datos. ◦ Se realizan copias diarias (de estructura sin datos) durante 1 semana. Las recuperaciones parciales de datos están sujetas a la L.O.P.D. y deberán ser solicitadas por el responsable de cada aplicación. En cuanto a las aplicaciones que han sido catalogadas como críticas, existe un “Plan de continuidad” para restaurar los datos, con pérdida de información, en provincia contraria en caso de desastre. Dicho plan, sólo afecta a aplicaciones críticas. Sólo el sistema “PostgreSQL” instalado en las versiones más recientes es incluido dentro del “Plan de Continuidad”. Eventualmente y mientras se disponga de capacidad se seguirá manteniendo replicación de BBDD para las aplicaciones críticas alojadas en Oracle 11g y SqlServer 2008R2. No se da soporte de continuidad a las versiones antiguas de otros (SGBD) tales como Mysql o Oracle 10g.
En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada la autenticidad de esta copia, mediante el número de documento electrónico siguiente:
0CjX5SHFPhSvPNiwQq9XFu8B1epgOUyJ0
DGTNT-070012-TSI-NORM
Página 8 de 19
4.2. Diseño de aplicaciones
En el diseño de aplicaciones se tendrá en cuenta la metodología a usar, las nomenclaturas de los objetos de la base de datos, el modelo conceptual de datos, restricciones en los privilegios de las aplicaciones en las bases de datos,... Características recomendables para cualquier aplicación: • •
•
• •
•
La aplicación debe estar basada en arquitecturas abiertas. La aplicación será multicapa, manteniendo la independencia de la interfaz gráfica respecto al diseño de los procesos de negocio y éstos, a su vez, con la base de datos, pudiendo cada capa actuar en diferentes equipos en comunicación con el resto y facilitando la administración y mantenimiento remotos. Idealmente se intentará que, cualquiera de los navegadores de Internet más implantados, pueda ser cliente de la aplicación, sin necesidad de elementos especiales adicionales. La plataforma de desarrollo que se utilice, deberá permitir tecnologías estándar, Java (servlets y/o JSP), XML. El aplicativo debe incluir un proceso automático de instalación y control de versiones que permita la instalación y actualización de manera local o remota sin intervención de los usuarios. Se evitará el uso de componentes de software que requieran el pago de licencias “runtime”. De necesitarse alguna herramienta adicional, siempre compatible con el entorno descrito, se indicará su importe unitario, función, así como las condiciones de mantenimiento y distribución.
En cualquier caso , las aplicaciones deberán cumplir las normas y recomendaciones establecidas por la DGTNT en los servicios ofrecidos por CiberCentro , tales como políticas de contraseñas, Infraestructura para Aplicaciones del Gobierno de Canarias,… etc , (Ver desglose de normativas en la URL especificada en el apartado Referencias). 4.2.1. Metodología
El desarrollo seguirá la metodología MÉTRICA V.3, recomendada por el Ministerio de Administraciones Públicas (MAP). La notación a usar será la de MÉTRICA V.3 o en su defecto UML (Unified Model Language). 4.2.2. Tablas normalizadas
En el caso de usar diseños relacionales, las tablas deben estar debidamente normalizadas. Después de identificar y diseñar las tablas que se requieran, el siguiente paso para el diseño de la base de datos es la normalización, que consiste en examinar los datos que se encuentran agrupados en una tabla hasta reemplazarlos por varias tablas que resultan ser simples y predecibles haciéndolas más fáciles de manejar.
En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada la autenticidad de esta copia, mediante el número de documento electrónico siguiente:
0CjX5SHFPhSvPNiwQq9XFu8B1epgOUyJ0
DGTNT-070012-TSI-NORM
Página 9 de 19
Este proceso se realiza por las siguientes razones: • • • • •
Estructurar los datos de tal manera que se pueda establecer fácilmente la relación entre los mismos. Facilitar la recuperación de los datos para satisfacer las necesidades de informació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 en casos dónde el rendimiento los justifique, se estudiará caso a caso para mantener tablas no 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. 4.2.3. Integridad Referencial y Reglas de Negocio
La integridad referencial es un mecanismo para asegurar que los cambios que se hacen en la BBDD por usuarios autorizados no resultan en una pérdida de consistencia de los datos, forzando a que los registros de tablas relacionadas sean válidos y que no se borren o cambien datos relacionados de forma accidental produciendo errores de integridad. Los Gestores de BBDD relacionales (RDBMS) gestionan desde hace años la integridad referencial, simplificando así la tarea de programación. Siempre será más seguro y mucho más eficiente hacer que, dicha integridad referencial, la maneje el RDBMS que hacerlo mediante programación. Por los mismos motivos, se aconseja codificar las reglas de negocio a través de restricciones (constraints) y de disparadores (triggers) dentro de la BBDD en lugar de hacerlo en la aplicación. 4.2.4. Documentación
La documentación deberá ser completa. El material adjunto a la aplicación permitirá el completo entendimiento de la misma, y en caso necesario la continuación y mantenimiento de la aplicación. El desarrollo se realizará y documentará siguiendo la metodología Métrica 3. Adicionalmente, se generará toda la documentación necesaria para realizar el seguimiento del proyecto y garantizar su calidad. Se generarán y entregarán los manuales necesarios para los distintos tipos de usuarios presentes en el sistema. El aplicativo desarrollado deberá ofrecer ayuda en línea sensible al contexto para el usuario.
En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada la autenticidad de esta copia, mediante el número de documento electrónico siguiente:
0CjX5SHFPhSvPNiwQq9XFu8B1epgOUyJ0
DGTNT-070012-TSI-NORM
Página 10 de 19
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 dónde se describan cada uno de los objetos creados en la base de datos, 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 de Control 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 Los documentos adicionales serán necesarios para el correcto cumplimiento de la LOPD. El Reglamento de desarrollo de la LOPD (en adelante RLOPD3) establece la obligatoriedad de disponer del Documento de Seguridad con las medidas de índole técnica y organizativa acordes a la normativa de seguridad vigente. 4.2.5. Drástica reducción de las consultas ad hoc.
Las consultas ad-hoc contra BBDD de producción son muy útiles para los usuarios al permitir una gran flexibilidad en la forma de obtener los datos. Pero en entornos en que la base de datos de producción es compartida por varias aplicaciones críticas, no poner límites a esos accesos puede generar consultas en extremo costosas, maliciosas, o simplemente erróneas, que repercutan drásticamente en los tiempos de respuesta de usuarios inocentes. Por ello, la posibilidad de crear consultas dinámicas por parte de los usuarios debe estar controlada por la aplicación, evitando la generación de consultas indiscriminadas y sin filtros contra tablas de millones de filas. Las consultas contra las tablas más grandes deberán hacerse siempre que sea posible usando índices y restringiendo el número de filas 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”. Esta consulta 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 consultas pesadas que no sean estrictamente necesarias”. En el caso de ser indispensables dichas 3
Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la LOPD.
En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada la autenticidad de esta copia, mediante el número de documento electrónico siguiente:
0CjX5SHFPhSvPNiwQq9XFu8B1epgOUyJ0
DGTNT-070012-TSI-NORM
Página 11 de 19
consultas y procesos más pesados, deberán lanzarse 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 agenda global para la Base de datos y para la propia máquina. Así se evitará que interfiera con otros procesos de mantenimiento de otras aplicaciones o de otros componentes software de la máquina que aloja la BBDD. (Recordamos la necesidad de cumplir los puntos 3.1.1 Comunicación con los administradores de la Base de Datos y 3.1.2 Comunicaciones por parte del responsable de la aplicación). 4.2.6. 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 y código de acceso a los datos, se aconseja dividir la lógica de la aplicación usando, por ejemplo, diseño de patrones como “modelo-vista-controlador (MVC)”. MVC obliga a separar el código entre el “Modelo” (componentes que alojan el código de acceso a la BBDD), vista (componentes que definen la interfaz de usuario), y controlador (objetos que gestionan las acciones de los usuarios). 4.2.7. Definición de una nomenclatura
Toda aplicación deberá poseer una guía de estilo, dónde se defina una forma de nombrar los diferentes objetos a crear en una base de datos. En dicha guía se recogerán las reglas a seguir para conseguir una uniformidad en los nombres de todos los objetos de la aplicación. 4.2.8. Ciclo de vida de las aplicaciones
Las aplicaciones idealmente se programarán en entornos de Desarrollo, se probarán en entornos de Preexplotación y finalmente pasarán a producción en entornos de Explotación. Los desarrolladores tendrán pleno acceso a las máquinas de Preexplotación y Desarrollo, pudiendo realizar las tareas que consideren oportunas (pruebas, estadísticas, cargas masivas,...). Cualquier modificación que deba sufrir una aplicación de explotación se programará en Desarrollo, posteriormente se probará en Preexplotación y sólo después de que el responsable de aplicación dé su conformidad, las modificaciones se trasladarán a Explotación. La realización de cualquier tarea pesada que pueda interferir en el normal rendimiento de motor de la BBDD de Explotación deberá ser consultada y aprobada por el departamento de BBDD de la DGTNT. Se determinará cual es la forma más inocua de llevar a cabo la tarea, se planificará, y si fuese preciso, se notificará a los demás responsables de aplicaciones, de las posibles repercusiones en el rendimiento que podrían producirse durante dichos procesos de mantenimiento.
En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada la autenticidad de esta copia, mediante el número de documento electrónico siguiente:
0CjX5SHFPhSvPNiwQq9XFu8B1epgOUyJ0
DGTNT-070012-TSI-NORM
Página 12 de 19
4.3. Uso de las BBDD 4.3.1. Accesos a las bases de datos de explotación
Los entornos de pre-producción y desarrollo no pueden acceder a los datos de explotación. Asimismo, como norma, solo las Aplicaciones de producción accederán a dichos datos. El uso de programas ajenos a las aplicaciones para acceder a los datos de Explotación (Citrix,TOAD, Access, Sqlplus,..) es un riesgo, tanto para la integridad como para la seguridad de los datos. Además, las conexiones a la BBDD desde programas externos a las aplicaciones se saltan las auditorias y los posibles controles de acceso que estuviesen implementados en la aplicación. Si fuese totalmente necesario el acceso a los datos de Explotación de forma externa a la aplicación se creará un usuario de sólo lectura para preservar la integridad de los datos y minimizar los riesgos, evitando siempre el uso del usuario propietario de la aplicación. Adicionalmente, se deberán seguir las Políticas de Seguridad establecidas en las “Normas y recomendaciones establecidas por la DGTNT relacionadas con la Seguridad”. 4.3.2. Racionalización en el uso de objetos
Todo objeto de la BBDD que se cree deberá tener una finalidad, eliminando en la medida de lo posible, objetos que no se usan, o aquellos obsoletos de versiones anteriores del aplicativo, etc. No se permitirá, salvo por mantenimientos o procesos especiales, la presencia en Explotación de: -
Objetos deshabilitados. Objetos inválidos. Objetos que no se usen. 4.3.3. Gestión de los nombres de usuarios en la base de datos
Como norma: “Los usuarios finales de la aplicación deberán acceder a la base de datos usando nombres de usuarios que los identifiquen unívocamente como personas físicas.” Además, los nombres de usuarios deberán estar dados de alta en el LDAP, ya que deberán ser gestionados usando el directorio LDAP del Gobierno de Canarias. De cara a poder diferenciar el acceso a las distintas funciones ofrecidas por la aplicación, será necesario que existan diferentes perfiles de usuario. Se evitarán las aplicaciones que accedan a la BBDD a través de un único usuario de BBDD para todos los usuarios reales. Las aplicaciones vía WEB podrán acceder mediante usuarios genéricos a la BBDD siempre que no accedan a datos sensibles. En el caso de acceder a datos sensibles, las conexiones a la BBDD identificarán a los usuarios finales. Cualquier necesidad de saltarse
En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada la autenticidad de esta copia, mediante el número de documento electrónico siguiente:
0CjX5SHFPhSvPNiwQq9XFu8B1epgOUyJ0
DGTNT-070012-TSI-NORM
Página 13 de 19
esta norma podrá hacerse tal y como se explica en el punto 1 Introducción, justificando la excepción por escrito y previa autorización de la DGTNT. Las aplicaciones que se salten la norma deberán mantener las auditorias y los históricos de accesos a los datos sensibles. Todas las contraseñas, tanto de las cuentas de usuario final como de usuario de aplicación, deberán cumplir con las directrices de seguridad especificadas en la Política de Contraseñas del Gobierno de Canarias. 4.3.4. Gestión de las instancias (Centralización)
Para poder prestar un servicio adecuado, con un alto nivel de calidad, es necesaria la centralización en pocos gestores de BBDD, de forma que las aplicaciones convivan en una sola instancia. Debido a los costes tanto de Administración/Gestión como de licencias se hace inabordable cualquier esquema descentralizado de las BBDD, en el que cada nueva aplicación requiera de una instancia propia.. Sólo en el caso de aplicaciones críticas y cuando se hayan agotado todas las posibilidades de una instalación acorde a la arquitectura de la organización, esta debería adaptarse a una aplicación. 4.3.5. Pruebas con datos reales
Conforme a lo dispuesto en el RLOPD, las pruebas anteriores a la implantación o modificación de los sistemas de información que traten ficheros con datos de carácter personal, no se realizarán con datos reales, salvo que se asegure el nivel de seguridad correspondiente al tratamiento realizado y se anote su realización en el documento de seguridad. Por tanto, no se deben emplear datos reales en el entorno de PRE, salvo que se cumplan todos los requisitos de seguridad requeridos en el RLOPD. 4.3.6. Funcionalidades avanzadas y/o plugins.
Antes de usar dentro del SGBD cualquier funcionalidad avanzada o plugin, como pudieran ser capacidades de particionado o datos espaciales, debe asegurarse que dicho uso no requiera un licenciamiento adicional, y su uso debe ser explícitamente autorizado por el departamento de BBDD. 5. NORMATIVA POSTGRESQL A lo largo del presente apartado se hace mención al Sistema Gestor de Base de Datos Objeto-Relacional PostgreSQL, llamándolo también SGBDOR y motor de la Base de Datos. En “Nomenclatura PostgreSQL”, una BBDD es una estructura física (ficheros) que posee múltiples esquemas que agrupan de forma lógica los objetos de la aplicación o proyecto.
En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada la autenticidad de esta copia, mediante el número de documento electrónico siguiente:
0CjX5SHFPhSvPNiwQq9XFu8B1epgOUyJ0
DGTNT-070012-TSI-NORM
Página 14 de 19
Las normas y recomendaciones se han agrupado en: • •
Diseño de aplicaciones. Optimización de aplicaciones.
5.1. Diseño de aplicaciones 5.1.1. Plataforma
Actualmente se dispone en explotación, pre-explotación y desarrollo, de Red Hat Enterprise Linux 6 con gestores de BBDD PostgreSQL 9.3 x86_64. [root@****** ~]# rpm -q -a | grep -i postgresql postgresql93-9.3.4-1PGDG.rhel6.x86_64 postgresql93-libs-9.3.4-1PGDG.rhel6.x86_64 postgresql93-server-9.3.4-1PGDG.rhel6.x86_64
5.1.2. Acceso a las BBDD de PostgreSQL
Los accesos de los usuarios a las distintas BBDD alojadas en las Instancias ubicadas dentro de la arquitectura de gobierno podrán realizarse con el cliente nativo psql, con herramientas visuales disponibles en el mercado (por ejemplo, pgAdmin III) o con cualquier otra aplicación que soporte los conectores del tipo JDBC u ODBC. Actualmente se dispone de dos gestores de BBDD que alojan la pre-explotación y la explotación, datos que junto con el usuario y la clave permiten al cliente establecer una sesión en cualquier tipo de conexión. Valga la siguiente instrucción como ejemplo de acceso desde línea de comando: shell> psql -h Servidor -U Usuario -W Es deseable determinar los equipos desde los cuales se establecerán las sesiones de usuario, ya que dichas conexiones quedarían siempre limitadas a los equipos declarados a través del archivo de configuración ‘pg_hba.conf’. De la misma forma se podrá requerir, para establecer un mayor nivel de seguridad, tanto la especificación de la BBDD a la que se requiere acceder desde el equipo detallado como el usuario y el método de autenticación que usará, por defecto sólo se permitirá autenticación LDAP. Así mismo, quedan deshabilitados los inicios de sesión desde los propios servidores que alojan los sistemas gestores de BBDD.
En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada la autenticidad de esta copia, mediante el número de documento electrónico siguiente:
0CjX5SHFPhSvPNiwQq9XFu8B1epgOUyJ0
DGTNT-070012-TSI-NORM
Página 15 de 19
5.1.3. Restricciones en los privilegios de la Base de datos.
Cada Aplicación debe gestionar sus propios esquemas en la BBDD de PostgreSQL que se le asigne ( en adelante BBDD_ENTREGADA ) . No es buena practica en un cluster de BBDD de PostgreSQL incluir los contenidos/tablas en el esquema "public", pues dicha actuación supone un problema de seguridad. En las BBDD entregadas se realizará explicitamente un REVOKE: "revoke connect on database {BBDD_ENTREGADA} from public; " Cada aplicación debe crearse dentro de la cada {BBDD_ENTREGADA} que se le asigne los esquemas que crean necesarios , dejando "public" sin uso. Cada aplicación/proyecto podrá poseer una o varias BBDD de las cuales será propietario en exclusiva. Con ello se garantiza que pueda realizar cualquier operación con su BBDD sin interferir con el resto de usuarios. Para cualquier operación que requiera el acceso o modificación de datos o parámetros no exclusivos de las BBDD que posee, se deberá dirigir consulta al Departamento de BBDD de la DGTNT para su estudio y evaluación. En caso de necesitarse acceso entre distintas aplicaciones que trabajen conjuntamente, deberá evaluarse la posibilidad de crear una única BBDD dónde podrían crearse tantos esquemas como sean necesarios. 5.1.4. Definición de una nomenclatura
Toda aplicación deberá poseer una guía de estilo. La guía contendrá directrices para nombrar cualquier tipo de objeto que la aplicación pueda crear en la base de datos. Definir una nomenclatura permite una forma estándar de referenciar a los objetos de una BBDD. Además, si dicha nomenclatura expresa el propósito del objeto, se pueden eliminar muchas preguntas sobre la funcionalidad de los objetos. En el caso de usar abreviaciones, habrá que especificar en la propia nomenclatura cual es la forma de obtener 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 30 caracteres. 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 o PERSONAL_TB_PERSONAS.
En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada la autenticidad de esta copia, mediante el número de documento electrónico siguiente:
0CjX5SHFPhSvPNiwQq9XFu8B1epgOUyJ0
DGTNT-070012-TSI-NORM
Página 16 de 19
5.1.5. Soporte para el Juego de Caracteres.
Por defecto se seleccionará el juego de caracteres (encoding) UTF8 debido a que ofrece total compatibilidad con cualquiera de los distintos encodings disponibles para los clientes que deban conectarse con las BBDD presentes en la instancia. El juego de caracteres por defecto es seleccionado al inicializar la instancia de PostgreSQL. No obstante, cada Base de Datos particular dentro de la instancia puede tener su propio juego de caracteres diferente al especificado por defecto, ya que durante la creación de las mismas está permitido definir uno diferente. Es responsabilidad de los usuarios seleccionar el juego de caracteres que mejor se adapte a las necesidades de sus aplicaciones. 5.1.6. Copias de Seguridad.
Las copias de seguridad que se realizan son de carácter lógico y copias físicas incrementales en caliente. De esta manera se garantiza la posibilidad de recuperar individualmente cada una de las BBDD presentes en la instancia. Cabe recordar que este modelo de respaldo no requiere de una parada del servidor y por lo tanto no se produce interrupción del servicio en ningún momento. 5.1.7. Ciclo de vida de las Aplicaciones
Las aplicaciones idealmente se programarán en entornos de desarrollo, se probarán en entornos de Pre-explotación y finalmente pasarán a producción en entornos de Explotación. Actualmente, se dispone de las siguientes versiones: Entorno
SGBD
Versión
Preexplotación
PostgreSQL
9.3.4 RHEL.x86_64
Producción
PostgreSQL
9.3.4 RHEL.x86_64
Desarrollo
PostgreSQL
9.3.4 RHEL.x86_64
En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada la autenticidad de esta copia, mediante el número de documento electrónico siguiente:
0CjX5SHFPhSvPNiwQq9XFu8B1epgOUyJ0
DGTNT-070012-TSI-NORM
Página 17 de 19
Por motivos de seguridad, el detalle de las máquinas y las instancias de PostgreSQL se relacionan en un documento aparte. De este modo el presente documento marco conserva su vigencia de forma independiente a la evolución en los sistemas de los que dispone el Gobierno de Canarias. Las aplicaciones que se pasen a Explotación previamente habrán sido probadas en Preexplotación, y tras la comunicación, por parte del responsable de la aplicación, del correcto funcionamiento de la misma, será transferida desde Pre-explotación a Explotación usando la utilidad de exportación pg_dump. La transferencia podrá hacerse de los objetos vacíos o con los datos que ya tuviera la aplicación en el entorno de Preexplotación. Cualquier modificación que deba sufrir una aplicación de Explotación se programará en Desarrollo, posteriormente se probará en Pre-explotación y sólo después de que el responsable de aplicación dé su conformidad, las modificaciones se trasladarán a Explotación. La realización de cualquier tarea pesada que pueda interferir en el normal rendimiento del motor de la BBDD de Explotación deberá ser consultada y aprobada por el departamento de BBDD de la DGTNT. Se determinará cual es la forma más inocua de llevar a cabo la tarea, se planificará, y si fuese preciso, se notificará a los demás responsables de aplicaciones de las posibles repercusiones en el rendimiento que podrían producirse durante dichos procesos de mantenimiento. 5.2. Optimización de Aplicaciones 5.2.1. Seguir en la medida de lo posible el SQL estándar ANSI
PostgreSQL posee varias mejoras/añadidos al SQL estándar ANSI. Al usar estas características se está limitando la posibilidad de adaptar la aplicación a algún otro motor RDBMS, perdiendo portabilidad. 5.2.2. Ajustar sentencias SQL.
PostgreSQL aporta el comando “EXPLAIN”, el cual muestra el plan de ejecución que el planificador genera para la sentencia (SELECT, INSERT, UPDATE, etc.) pasada como argumento. La parte más importante del resultado mostrado por el comando es el coste estimado de la ejecución de la sentencia. Es muy recomendable que en cada aplicación se identifique, analice y ajuste toda consulta que pueda suponer un coste de ejecución elevado.
En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada la autenticidad de esta copia, mediante el número de documento electrónico siguiente:
0CjX5SHFPhSvPNiwQq9XFu8B1epgOUyJ0
DGTNT-070012-TSI-NORM
Página 18 de 19
5.2.3. Sentencias preparadas.
A diferencia de otros SGBD, PostgreSQL parsea cada sentencia que recibe independientemente de si se usan ‘bind variables’ o no. Sin embargo, cuenta con una forma de emular dicho comportamiento y es mediante el comando “PREPARE”. Una sentencia ‘preparada’ es un objeto en el lado del servidor que es usado para optimizar el rendimiento de ejecución de dicha sentencia. La ‘preparación’ de la sentencia implica su parseo, análisis y re-escritura; su posterior ‘ejecución’ conlleva únicamente las fases de planificación y ejecución, por lo que sucesivas ejecuciones con distintos parámetros se beneficiarán de la ‘preparación’ inicial. Se recomienda hacer uso de esta característica especialmente en bucles y algoritmos repetitivos que por su naturaleza requieran la ejecución de la misma sentencia con los mismos parámetros pero con valores diferentes. 5.2.4. Particionado de tablas
El particionado consiste en la división física de una tabla en pequeñas partes más manejables, lo que provee una mejora de rendimiento importante en muchas situaciones. Todas aquellas tablas de tamaño considerable (datos históricos, auditorías, etc.) son buenas candidatas para ser particionada. 5.2.5. Pool de conexiones
1 El SGBDOR PostgreSQL para su eficaz desempeño debe ser accedido por el menor número de sesiones posible, por ello se establecerán pooles de conexiones en los servidores 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#example http://www.pgpool.net/docs/latest/pgpool-en.html#hba 6. REFERENCIAS Documento
Normas y recomendaciones establecidas por la Dirección General de Telecomunicaciones y Nuevas Tecnologías (DGTNT) en los servicios ofrecidos por CiberCentro
Ubicación
http://www.gobiernodecanarias.net/cibercentro/documentos/normativas/
Normativa Corporativa utilización de Bases de Datos Normativa sobre utilización de herramientas corporativas Normas y recomendaciones establecidas por la DGTNT relacionadas con la Seguridad
En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada la autenticidad de esta copia, mediante el número de documento electrónico siguiente:
0CjX5SHFPhSvPNiwQq9XFu8B1epgOUyJ0
DGTNT-070012-TSI-NORM
Página 19 de 19
Documento
Información sobre Métrica 3
Ubicación
http://administracionelectronica.gob.es/pae_Home/pae_Documentaci on/pae_Metodolog/pae_Metrica_v3.html
7. 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
Fax
922 474 880 (24880) - 928 307 880 (87880)
Este documento ha sido firmado electrónicamente por: FRANCISCO JAVIER GARCIA LATORRE - DIRECTOR GNRAL.TELECOMUNICACIONES Y N.T. JOSE DAMIAN FERRER QUINTANA - JEFE AREA TELECOMUNICAC.Y SISTEMAS HERLINDA HERNANDEZ PERERA - JEFE DE PROYECTO En la dirección https://sede.gobcan.es/sede/verifica_doc puede ser comprobada la autenticidad de esta copia, mediante el número de documento electrónico siguiente:
0CjX5SHFPhSvPNiwQq9XFu8B1epgOUyJ0 El presente documento ha sido descargado el 21/12/2015 - 10:42:23
Fecha: 21/12/2015 - 10:22:47 Fecha: 21/12/2015 - 08:53:20 Fecha: 21/12/2015 - 08:50:43
