Bases de datos seguras
- 1. A lo largo de este artículo se aporta una visión general de cómo se debe realizar adecuadamente la gestión de la seguridad en siste- mas de bases de datos, evitando en la medida de lo posible los detalles téc- nicos concretos que puedan perder valor en el tiempo. Desde el punto de vista de la seguridad se buscará respuesta a preguntas tales como: ¿qué implica que una base de datos sea transaccional? ¿qué cuestiones hay que tener en cuenta en el clustering? ¿para qué sirven los roles y grupos de usua- rios? ¿de qué manera afectan y ayudan a la seguridad de las aplicaciones existentes so- bre bases de datos? ¿cómo es viable gestio- nar la combinación de todo lo anterior sin permanecer en un estado de alerta perma- nente? Los conceptos de seguridad en bases de datos son los mismos que se plantean en cualquier otro sector de tecnologías de la información, pero en su aplicación práctica poseen muchas particularidades. Cada dato tiene unas consideraciones distintas. Den- tro de una misma tabla, no es lo mismo co- nocer el campo “apellido” que el campo “salario”, y dentro de este mismo, no es lo mismo conocer el del registro “bedel” que el del registro “consejero delegado”. ¿DE QUÉ SEGURIDAD HABLAMOS? La situación ideal es aquella en la que se logra gestionar el estado y garantizar un nivel adecuado de los tres aspectos fun- damentales de la seguridad de la infor- mación: integridad, confidencialidad y disponibilidad. Aplicado al entorno de las bases de datos se trata de garantizar que los datos almacenados son veraces y no están corruptos, que sólo accede a cada dato aquél al que le corresponde acceder, y que la información está disponible cuando se requiere su uso. Este aspecto es fundamental en aplicaciones que no conocen de horarios, o en aquellas en las que es imprescindible contar con los da- tos en ciertas franjas horarias indepen- dientemente del número de accesos si- multáneos que se estén realizando. Para lograr dichas premisas y contemplar la seguridad en todos sus aspectos hay que tener en cuenta tres áreas diferenciadas: Seguridad física: sistemas hardware, soportes, dependencias, etc. La segu- ridad física siempre es importante, aunque este artículo se va a centrar en las particularidades de las bases de datos. Seguridad lógica: aplicaciones, proto- colos, procesos informáticos, elemen- tos de protección de red, etc. Seguridad político-corporativa: legis- lación aplicable, la política general, normas, procedimientos, convencio- nes internas, etc. Dichas áreas están interrelacionadas, y para garantizar el nivel de protección óptimo frente a las posibles amenazas en cada área se implementarán princi- palmente y de forma coherente, medi- das de seguridad de tres tipos: Activas o preventivas. El ejemplo pa- ra seguridad lógica sería el cortafue- gos (firewall), la valla en seguridad fí- sica y las normas en seguridad políti- co-corporativa. Pasivas, como auditoría, detección y/o alarma. Por ejemplo, las cámaras de BASES DE DATOS SEGURIDAD REFORZADA La seguridad en el acceso a la información puede reforzarse considerablemente si en la aplicación que consulta a la base de datos se emplean mecanismos de autenticación fuerte, como pueden ser: Tokens de autenticación. Certificados digitales almacenados en tarjetas inteligentes. Dispositivos de autenticación biométrica. Etc. LACOOPERACIÓN,EL‘BUSINESSTOBUSINESS’YLACONFEDERACIÓN OBLIGANAUNACCESOINTEGRADOABASESDEDATOSHETEROGÉNEASE INDEPENDIENTES BASESDEDATOSSEGURAS, LACLAVEESTÁENLAGESTIÓNLAGESTIÓNDELASEGURIDADDELOSSISTEMASDEBASESDEDATOSSECONVIERTEENUN PROBLEMADEPRIMERORDENCUANDOLOSDATOSCRÍTICOSDELAEMPRESASEEXPONENALAS POSIBLESVULNERABILIDADESTECNOLÓGICAS. VICTORSANTOSESCOLANO.INGENIERÍADECLIENTESDEACENS,THEHOSTINGCOMPANY. GUSTAVOSANFELIPELOBO.RESPONSABLEDESEGURIDADDEACENS,THEHOSTINGCOMPANY. 66
- 2. CCTV, los sistemas IDS y los planes de auditoría. De recuperación, como por ejemplo el Disaster Recovery Plan, las copias de seguridad o Backup, y la SAI y/o gru- po electrógeno. QUIÉNACCEDEAQUÉYDESDEDÓNDE La cooperación, el business to business y la confederación obligan a un acceso in- tegrado a bases de datos heterogéneas e independientes, que normalmente em- plean distintos sistemas y tecnologías. La aplicación que solicita los datos no entiende ni le interesa lo que hay por debajo, y el usuario final, es decir, la persona que utiliza dicha aplicación, normalmente tampoco. En esta jungla de sistemas dispares, motores de distintos fabricantes, acce- sos ubicuos y aplicaciones preexisten- tes, se trata de acomodar la seguridad. No es sencillo. Hay que poner de acuer- do a ingenieros en la fase de diseño, desarrolladores en la fase de construc- ción y administradores en la fase de operación, para ver quién se va a encar- gar de qué. Posteriormente, ajustar las interdependencias y un largo etcétera de pormenores para alcanzar el objeti- vo. Y todo con un único fin: que el acce- so a unos datos concretos se produzca por quien debe y desde donde debe. Y que ese alguien no tenga permiso ni de- recho a acceder o modificar lo que no le corresponde. Para ello, habrá que poner de acuerdo a los sistemas operativos, bases de datos, elementos de red y sistemas de alma- cenamiento. Entre ellos se acomodan para funcionar con unos o con otros por motivos técnicos, económicos o políti- cos, pero aún así, las combinaciones son muchas. En un primer nivel de control de acceso lógico es necesario implementar tecno- logía firewall (cortafuegos) como primer filtro en el que se establecen qué redes de confianza pueden acceder a las bases de datos. Posteriormente, es importan- te analizar la seguridad de las aplicacio- nes que acceden a la propia base de da- tos, ya que normalmente el usuario no se introduce directamente a la base de datos, sino que utiliza un cliente o una aplicación web que es realmente quien se identifica y accede al motor de la ba- se de datos. La seguridad del código es necesaria para evitar ataques del tipo SQL-Injection, originados por la falta de validación de los datos de entrada en la aplicación que “ataca” (y nunca me- jor dicho) a la base de datos. A continuación se analizan las herra- mientas y funcionalidades de la propia base de datos para afinar el acceso en el ámbito de tablas, registros e incluso campos concretos en el ámbito del usuario. ¿ES TODO ES TAN COMPLEJO? ¿NADIE NOS AYUDA? Lo cierto y por fortuna es que en la últi- ma década los fabricantes han realizado un auténtico esfuerzo por facilitarles las cosas a administradores y gestores. La seguridad ha sido siempre una pieza clave en este campo, y en cada nueva versión hemos tenido avances cualitati- vos importantes. A continuación se enumeran algunos de los “inventos” más notables de los últi- mos años, tratando de no particularizar sobre fabricantes. Por otro lado, unos aprenden de los otros y al cabo de un tiempo, todos aplican los descubrimien- tos de los demás. LAS VISTAS. Las vistas son una excelente formadedaralusuariolainformaciónque necesitaysóloésa.Sonsimplesconsultas a través de las cuales el usuario final úni- camentevedeterminadascolumnas,filas ocamposquecumplanuncriterio.Secrea así un esquema conceptual a partir de lo que el usuario solicita. Esto evitará tener informaciónredundante.Sehandesarro- lladobastanteymejoradoeltipodevistas, lo que supone la creación de vistas mate- rializadas, vistas multinivel, vistas frag- mentadas,subvistas,etc. PERMISOS DE USUARIO. Con los permisos de usuario se trata de definir qué puede hacer un usuario concreto, o qué tipo de operacionesnoleestánpermitidas.Enlos ENUNPRIMERNIVELDECONTROLDEACCESOLÓGICOESNECESARIO IMPLEMENTARTECNOLOGÍA‘FIREWALL’COMOPRIMERFILTRO Cuadro1.Áreasdelaseguridad
- 3. 68 permisos se suele distinguir entre autori- zar, no decir nada, o denegar explícita- mente. A diferencia de la vida real, donde uno le puede dar las llaves de su casa a quien desee, los usuarios pueden no ser pro- pietarios de sus objetos, y no tener per- miso para delegar nada. Aquí se definen permisos sobre tablas, vistas, procedi- mientos, y casi todo lo que se nos pueda ocurrir. La complejidad puede ser casi infinita, con un sinfín de jerarquías que se pueden contradecir, pues no sólo es a qué se da permiso, sino también quién lo da, y que ocurre si simultáneamente se otorga un permiso por un usuario y otro lo deniega explícitamente. Con idea de simplificar esto se idearon los roles. ROLES. Los roles son simplemente con- juntos permisos que se unen para mayor comodidad. Los sistemas suelen traer al- gunos predefinidos, “administrador” o “usuario” son dos de ellos, pero realmen- telosrolesestándestinadosaserpersona- lizados.Dentrodeunrolsepuedeincluir, porejemplo,elaccesotresvistas,laejecu- ción de seis procedimientos concretos, y la escritura en una tabla. De esta forma se acota el alcance de un usuario concreto, y portantoeldañoquepuedellegarahacer. Existen roles específicos para la función de asignación de roles, siendo estos los que deben controlarse de forma más es- tricta. GRUPOS DE CONSUMIDORES. Una cuestión que gana peso día a día en materia de se- guridadeselcontrolenelconsumodere- cursos. Determinados usuarios utilizan de forma intensiva o incluso abusan de ellos,apesardequesonlimitados.Sinose controla esto, podría suceder que se pro- dujera un retraso en las nóminas de una empresa,porqueeldepartamentodedes- arrollo está probando una herramienta, y ésta es defectuosa. Con este objeto, los grupos de consumidores controlan las consultas,transacciones,tiempodeCPU, etc., que pueden consumir o llegar a con- sumir los agentes. Esto se hace, ni más ni menos, que para garantizar la calidad de serviciodelabasededatos. AUDITORIA. Los fabricantes han hecho hincapié en la auditoría, los logs, las trazas deerrorylosdistintosmecanismosquefa- cilitanelcontrolyanálisisdeloquehacen losusuarios.Mejordicho,deaquellosele- mentos susceptibles de ser controlados. Sepuedenasí,establecereventosquehay que monitorizar. No se vigila, por tanto, todo el sistema, igual que las cámaras de circuito cerrado de televisión, sólo se gra- ban los lugares conflictivos o los que pue- denserlo. LA MÁQUINA DEL TIEMPO. En las bases de datos transaccionales avanzadas se ha conseguido el efecto de rebobinar hastaellugardondeseprodujoelerroro se perdieron los datos. Estos sistemas son caros en cuanto a tecnología y recur- sos, pero eliminan el mayor peligro que tienen los sistemas de información: el factor humano. Con estos mecanismos se puede observar el contenido de una tabla hace media hora, hace dos u ocho. Estonosepuedemantenerdurantemu- cho tiempo en bases con alta carga de transacciones, pues los volúmenes de datos serían inmanejables. SALVAGUARDA Y ‘BACKUP’. Aquí las bases dedatoshancrecidoymejorado.Losaños en los que se paraba el sistema por la no- che para realizar su copia han pasado a la historia. Ahora se necesita que el backup sea mucho más granular, continuo y rápi- do para que no se tenga que parar de nin- guna forma la base de datos. En este pun- to es conveniente verificar que el mecanismo de backup que se está emple- ando es el adecuado para la tecnología concreta.Elprincipalproblemaesqueno sepuederealizarunacopiadeficheros“tal cual”,esnecesariodisponerdeunagente que “hable” con la base de datos, o en el peor de los casos programar un volcado y hacerbackupdedichofichero. REPLICACIÓN Y SINCRONÍA. A colación del punto anterior, una buena forma de tener una copia de la base de datos consiste en disponer de una réplica en un emplaza- NORMAS DE OBLIGADO CUMPLIMIENTO La Ley Orgánica de Tratamiento de Datos de Carácter Personal (Ley Orgánica 15/1999, de 13 de diciembre, LOPD) refleja las cuestiones que se tienen que tener en cuenta en la recogida y tratamiento de los datos personales almacenados en bases de datos (denominados “ficheros” en la propia ley) y su incumplimiento puede dar lugar a sanciones que van desde los 600 euros para las infracciones leves hasta los 600.000 euros para las infracciones muy graves.
- 4. 69 miento remoto. Normalmente, esta solu- ción,máscaraycompleja,sueleutilizarse pormotivosderendimientoynodesegu- ridad,perollegadoelcaso,cumpleambos cometidos.Lasbasesdedatosesclavasse utilizan normalmente como lugar de con- sulta, y en ellas no se realizan transaccio- nes (inserciones, borrados o modificacio- nes), pues si así fuera podríamos tener problemasdeconsistencia. Las soluciones de réplica múltiple se han empezado a desarrollar con conteni- dos estáticos como páginas o vídeos (no deja de ser una paradoja llamar a un ví- deo “contenido estático”) y en el si- guiente punto veremos como vencemos el límite físico del almacenamiento lo- cal. Todo se orienta a una deslocaliza- ción de los ficheros. En un futuro no muy lejano, puede que dentro de una misma aplicación, unos datos estén ubi- cados en un emplazamiento, y otros (dentro de la misma página de consulta) a 1.000 kilómetros de distancia, con to- do lo que ello implica. LAGUERRADELACOMPLEJIDAD Como se ha comentado con anterioridad, conforme crece de forma notable la com- plejidad entre sistemas, garantizar su se- guridadseconvierteenalgovital.Larapi- dez y la sencillez de manejo suele oponersealaseguridad.Enestejuego,en ocasionesdesumacero,debeprimarlose- gundosobreloprimero.Másvaleirdespa- cioquenollegar. La seguridad en el acceso a la informa- ción puede reforzarse considerablemente si en la aplicación que consulta a la base de datos se emplean mecanismos de au- tenticación fuerte, como pueden ser: Tokens de autenticación. Certificados digitales almacenados en tarjetas inteligentes. Dispositivos de autenticación biomé- trica. Etc. De esta forma conseguimos que para autorizar el acceso no baste el conoci- miento de un identificador de usuario y contraseña, sino en una combinación de: “lo que sabes” más “lo que tienes” más “lo que eres”. Asimismo, para au- mentar el nivel de seguridad en el pro- pio almacenamiento se puede recurrir al cifrado de datos, ya sea empleando las utilidades y funciones que pueda pro- porcionar la propia base de datos o utili- zando herramientas de terceros para ci- frar los datos utilizando material cripto- gráfico del usuario antes de proporcio- nárselos al motor de la base de datos. Por otro lado, las bases de datos han ido evolucionando en cuanto a tamaño y ca- pacidad según se han desarrollado las diferentes tecnologías de almacena- miento. La seguridad en los datos dentro del scale out process dependerá de cómo se entien- dan comunicaciones, almacenamiento y bases de datos. Todo un reto. La deslo- calización de los datos, tendrá conse- cuencias en el acceso y la seguridad que hoy de momento no se plantean. SEGURIDAD“DELEY” En lo referente al cumplimiento de la legislación vigente, y en el muy proba- ble caso de que las bases de datos vayan a almacenar algún tipo de dato referente a personas, el principal aspecto a tener en cuenta es el relativo a la Ley Orgáni- ca de Tratamiento de Datos de Carácter Personal (Ley Orgánica 15/1999, de 13 de diciembre, LOPD). Esta ley, por cuyo cumplimiento vela la Agencia Española de Protección de Da- tos, refleja las cuestiones que se tienen que tener en cuenta en la recogida y tra- tamiento de los datos personales alma- cenados en bases de datos (denomina- dos “ficheros” en la propia ley) y su in- cumplimiento puede dar lugar a sancio- nes que van desde los 600 euros para las infracciones leves hasta los 600.000 eu- ros para las infracciones muy graves. Las obligaciones recogidas en la LOPD contemplan aspectos tales como la obli- gatoriedad de registrar los “ficheros” que almacenen datos de carácter perso- nal, la calidad de datos y la proporciona- lidad, el deber de información en la re- cogida, aspectos a tener en cuenta en el tratamiento y la posible cesión a terce- ros, las transferencias internaciones de datos, y los derechos de los afectados (acceso, rectificación y cancelación, oposición). Centrándonos en las medidas de seguri- dad específicas, la LOPD se comple- menta con el Real Decreto 994/1999, de 11 de junio, por el que se aprueba el re- glamento de medidas de seguridad de los ficheros automatizados que conten- gan datos personales. Este reglamento, cuya nueva versión se ha retrasado y es- tá anunciada para el segundo semestre del 2007, establece que medidas de se- guridad se deben establecer en función del tipo de datos almacenados en el fi- chero. Estas medidas incluyen la reali- zación de un documento de seguridad y pueden llegar hasta la obligatoriedad de auditoría bianual e incluso la transmi-
- 5. 70 sión cifrada de datos. Existe un cuadro resumen en la siguiente ubicación web: https://www.agpd.es/upload/Informa%20A EPD/cuadro_reglamento1.pdf Para más información se recomienda con- sultar la página web de la Agencia de Pro- tección de Datos (http://www.agpd.es), en la que se puede consultar y buscar desde la legislación aplicable y documentos de interés, hasta los ficheros inscritos en el registro y las resoluciones (con sanción o no) emitidas por dicha agencia. GESTIÓNYCONTROLINTERNO A lo largo del presente artículo se han mencionado las directrices generales cuya aplicación en la práctica puede destrozar un diseño perfecto, por ejem- plo, fallos en el software (de funciona- miento o específicos de seguridad), in- compatibilidades entre las diferentes aplicaciones, la incorrecta dimensión de los recursos de hardware y comunicacio- nes, los malos hábitos de las personas (sobre todo cuando no son conscientes del porqué de los controles o no se les ha transmitido la importancia de mante- ner la seguridad en la información que manejan). Si nuestro sistema de base de datos tie- ne conexión directa o indirecta (por ejemplo, vía web) con redes públicas, co- mo Internet, será necesario tener en cuenta el elevado número de potencia- les atacantes que existen y que están deseosos de utilizar los recursos de la empresa y, en el peor de los casos, inte- resados en la información que alberga la base de datos. Del mismo modo, a la hora de garantizar la seguridad lógica del propio motor de base de datos es importante aplicar una correcta política de parcheado. Este mantenimiento no es obvio, pues los efectos de aplicar los parches de forma precipitada pueden ser incluso peores que los derivados de no aplicarlo. Los fabricantes de herramientas comerciales de bases de datos suelen agrupar varios parches y programar su anuncio para fa- cilitar esta tarea. La elección de aplicar un parche o conjunto de parches en un momento concreto tendrá que venir de- terminada por varios factores: 1. ¿Necesito la funcionalidad extra pro- porcionada por el parche? 2. ¿Es un parche crítico para la seguri- dad del sistema? 3. ¿Permite sacar provecho de la vulne- rabilidad de forma remota? El elemento fundamental para garanti- zar que las medidas anteriormente men- cionadas están siendo aplicadas con la lógica que corresponde es el control in- terno (“que tu mano izquierda vea lo que hace la derecha”). Todo lo que no está documentado no existe. No se pue- de depender del conocimiento concreto de un buen equipo de técnicos, puesto que tenemos que contar con las circuns- tancias que afectan a las personas (vaca- ciones, bajas, rotación de personal, etc.). Por otro lado, con el paso del tiempo to- do sistema de información se degrada; por ejemplo, un proyecto puede quedar correctamente establecido en su inicio, pero si no se establece un correcto plan de auditoría nunca se tendrá una visión real en el tiempo del estado de la segu- ridad del sistema de bases de datos. Los resultados de dichas auditorías deben contribuir a la mejora de la seguridad, constituyendo el típico ciclo PDCA (Plan-Do-Check-Act) que se inicia duran- te el diseño del proyecto y se repite du- rante la vida útil del mismo. La gestión y el control interno son funda- mentales para garantizar el éxito. Es más importante tener identificadas las vulne- rabilidades y poder trazar el seguimiento de su gestión que invertir de forma pun- tual en tecnología de protección que in- troduzca más elementos de complejidad a un escenario ya de por sí complejo. «Bases de datos seguras, la clave está en la gestión». © Ediciones Deusto. SENECESITAQUEEL‘BACKUP’SEAMUCHOMÁSGRANULAR,CONTINUOY RÁPIDOPARAQUENOSETENGAQUEPARARDENINGUNAFORMA LABASEDEDATOS Si desea más información relacionada con este tema, introduzca el código 16101 en www.e-deusto.com/buscadorempresarial