Introducción a los Sistemas de Bases de Datos PDF

UNIVERSIDAD FEDERICO SRNTA MARIA 3 5G09 01S25 2859 Introducción a los SISTEMAS DE BASES DE DATOS Prentice Hall C. A T E J Contenido Prefacio a la séptima edición xvii PARTE I PRELIMINARES CAPÍTULO 1 Panorama general de la administración de bases de datos 1.1 Introducción 2 1.2 ¿Qué es un sistema de base de datos ? 5 1.3 ¿Qué es una base de datos? 9 1.4 ¿Por qué una base de datos? 15 1.5 La independencia de los datos 19 1.6 Los sistemas relaciónales y otros sistemas 25 1.7 Resumen 27 Ejercicios 28 Referencias y Bibliografía 30 Respuestas a ejercicios seleccionados 30 CAPÍTULO 2 Arquitectura de los sistemas de bases de datos 33 2.1 Introducción 33 2.2 Los tres niveles de la arquitectura 33 2.3 El nivel externo 37 2.4 El nivel conceptual 39 2.5 El nivel Interno 40 2.6 Transformaciones 40 2.7 El administrador de base de datos 41 2.8 El sistema de administración de base de datos 43 2.9 El administrador de comunicaciones de datos 47 2.10 Arquitectura cliente-servidor 48 2.11 Utilerías 50 2.12 El procesamiento distribuido 50 2.13 Resumen 54 Vii viii Contenido Ejercicios 55 Referencias y Bibliografía 56 CAPÍTULO 3 Una introducción a las bases de datos relaciónales 58 3.1 Introducción 58 3.2 Una mirada informal al modelo relacional 58 3.3 Relaciones y variables de relación 63 3.4 Qué significan las relaciones 65 3.5 Optimización 67 3.6 El catálogo 69 3.7 Variables de relación base y vistas 71 3.8 Transacciones 75 3.9 La base de datos de proveedores y partes 76 3.10 Resumen 78 Ejercicios 80 Referencias y Bibliografía 81 Respuestas a ejercicios seleccionados 82 CAPÍTULO 4 Introducción a SQL 83 4.1 Introducción 83 4.2 Generalidades 84 4.3 El Catálogo 87 4.4 Vistas 88 4.5 Transacciones 89 4.6 SQL incustrado 89 4.7 SQL no es perfecto 98 4.8 Resumen 98 Ejercicios 99 Referencias y Bibliografía 101 Respuestas a ejercicios seleccionados 106 PARTE II EL MODELO RELACIONAL 109 CAPITULO 5 Dominios, relaciones y varrels 111 5.1 Introducción 111 base 5.2 Dominios 112 5.3 Valores de relación 123 5.4 Variables de relación 129 Contenido ix 5.5 Propiedades de SQL 134 5.6 Resumen 137 Ejercicios 139 Referencias y Bibliografía 141 Respuestas a ejercicios seleccionados 144 CAPÍTULO 6 Álgebra relacional 150 6.1 Introducción 150 6.2 Revisión de la propiedad de cierre 152 6.3 Sintaxis 154 6.4 Semántica 156 6.5 Ejemplos 167 6.6 ¿Para qué sirve el álgebra? 169 6.7 Operadores adicionales 171 6.8 Agrupamiento y desagrupamiento 179 6.9 Comparaciones relaciónales 182 6.10 Resumen 184 Ejercicios 184 Referencias y Bibliografía 187 Respuestas a ejercicios seleccionados 190 CAPÍTULO 7 Cálculo relacional 198 7.1 Introducción 198 7.2 Cálculo de tupias 200 7.3 Ejemplos 208 7.4 El cálculo frente al álgebra 210 7.5 Posibilidades computacionales 215 7.6 Cálculo de dominios 216 7.7 Propiedades de SQL 218 7.8 Resumen 228 Ejercicios 229 Referencias y Bibliografía 231 Respuestas a ejercicios seleccionados 233 CAPÍTULO 8 Integridad 249 8.1 Introducción 249 8.2 Restricciones de tipo 251 8.3 Restricciones de atributo 252 8.4 Restricciones de varrel 253 xii Contenido 14.3 Recuperación de transacciones 457 14.4 Recuperación del sistema 460 14.5 Recuperación del medio 462 14.6 Confirmación de dos fases 462 14.7 Propiedades de SQL 464 14.8 Resumen 465 Ejercicios 466 Referencias y Bibliografía 466 Respuestas a ejercicios seleccionados 471 CAPÍTULO 15 Concurrencia 473 15.1 Introducción 473 15.2 Tres problemas de concurrencia 474 15.3 Bloqueo 477 15.4 Otra vez los tres problemas de concurrencia 478 15.5 Bloqueo mortal 481 15.6 Seriabilidad 482 15.7 Niveles de aislamiento 484 15.8 Bloqueo por aproximación 486 15.9 Propiedades de SQL 488 15.10 Resumen 490 Ejercicios 491 Referencias y Bibliografía 493 Respuestas a ejercicios seleccionados 499 PARTE V TEMAS ADICIONALES 503 CAPÍTULO 16 Seguridad 504 16.1 Introducción 504 16.2 Control de acceso discrecional 506 16.3 Control de acceso obligatorio 512 16.4 Bases de datos estadísticas 515 16.5 Cifrado de datos 520 16.6 Propiedades de SQL 525 16.7 Resumen 528 Ejercicios 529 Referencias y Bibliografía 530 Respuestas a ejercicios seleccionados 532 Contenido xiii CAPÍTULO 17 Optimización 537 17.1 Introducción 537 17.2 Un ejemplo motivador 539 17.3 Un panorama general del procesamiento de consultas 540 17.4 Transformación de expresiones 544 17.5 Estadísticas de la base de datos 550 17.6 Una estrategia de divide y vencerás 551 17.7 Implementación de los operadores relaciónales 554 17.8 Resumen 560 Ejercicios 561 Referencias y Bibliografía 564 Respuestas a ejercicios seleccionados 582 CAPÍTULO 18 Información faltante 584 18.1 Introducción 584 18.2 Un panorama general de la lógica 3VL 585 18.3 Algunas consecuencias del esquema anterior 591 18.4 Los nulos y las claves 595 18.5 La junta externa (una observación) 597 18.6 Valores especiales 600 18.7 Propiedades de SQL 601 18.8 Resumen 604 Ejercicios 606 Referencias y Bibliografía 608 Respuestas a ejercicios seleccionados 611 CAPÍTULO 19 Herencia de tipo 613 19.1 Introducción 613 19.2 Jerarquías de tipos 617 19.3 El polimorfismo y la sustituibilidad 620 19.4 Variables y asignaciones 624 19.5 Especialización por restricción 628 19.6 Comparaciones 630 19.7 Operadores, versiones y signaturas 635 19.8 ¿Un círculo es una elipse? 639 19.9 Revisión de la especialización por restricción 643 19.10 Resumen 645 Ejercicios 646 Referencias y Bibliografía 648 Respuestas a ejercicios seleccionados 649 Contenido CAPÍTULO 20 Bases de datos distribuidas 651 20.1 Introducción 651 20.2 Algunos puntos preliminares 651 20.3 Los doce objetivos 656 20.4 Problemas de los sistemas distribuidos 664 20.5 Sistemas cliente-servidor 675 20.6 Independencia de DBMS 678 20.7 Propiedades de SQL 683 20.8 Resumen 684 Ejercicios 685 Referencias y Bibliografía 686 CAPÍTULO 21 Apoyo para la toma de decisiones 694 21.1 Introducción 694 21.2 Aspectos del apoyo para la toma de decisiones 695 21.3 Diseño de bases de datos de apoyo para la toma de decisiones 697 21.4 Preparación de los datos 706 21.5 data warehouses y data marts 709 21.6 Procesamiento analítico en línea 715 21.7 Minería de datos 722 21.8 Resumen 724 Ejercicios 725 Referencias y Bibliografía 726 Respuestas a ejercicios seleccionados 729 CAPÍTULO 22 Bases de datos temporales 730 22.1 Introducción 730 22.2 Datos temporales 731 22.3 ¿Cuál es el problema? 736 22.4 Intervalos 742 22.5 Tipos de intervalo 744 22.6 Operadores escalares sobre intervalos 746 22.7 Operadores de totales sobre intervalos 747 22.8 Operadores relaciónales que involucran intervalos 748 22.9 Restricciones que involucran intervalos 754 22.10 Operadores de actualización que involucran intervalos 757 22.11 Consideraciones de diseño de bases de datos 759 22.12 Resumen 762 Ejercicios 763 Contenido xv Referencias y Bibliografía 764 Respuestas a ejercicios seleccionados 766 CAPÍTULO 23 Bases de datos basadas en la lógica 769 23.1 Introducción 769 23.2 Panorama general 769 23.3 Cálculo proposicional 772 23.4 Cálculo de predicados 777 23.5 Las bases de datos desde la perspectiva de la teoría de demostraciones 784 23.6 Sistemas de bases de datos deductivas 787 23.7 Procesamiento de consultas recursivas 793 23.8 Resumen 798 Ejercicios 801 Referencias y Bibliografía 802 Respuestas a ejercicios seleccionados 808 PARTE VI BASES DE DATOS DE OBJETOS Y DE OBJETOS/RELACIÓNALES 811 CAPÍTULO 24 Bases de datos de objetos 812 24.1 Introducción 812 24.2 Objetos, clases, métodos y mensajes 816 24.3 Una mirada más cercana 821 24.4 Un ejemplo de inicio a fin 829 24.5 Aspectos varios 839 24.6 Resumen 847 Ejercicios 850 Referencias y Bibliografía 851 Respuestas a ejercicios seleccionados 859 CAPÍTULO 25 Bases de datos de objetos/relaciónales 862 25.1 Introducción 862 25.2 El primer gran error garrafal 865 25.3 El segundo gran error garrafal 872 25.4 Cuestiones de implementación 875 25.5 Beneficios de un acercamiento verdadero 877 25.6 Resumen 879 Referencias y Bibliografía 880 Contenido APÉNDICES 887 APÉNDICE A Expresiones SQL 888 A.l Introducción 888 A.2 Expresiones de tabla 888 A.3 Expresiones condicionales 894 A.4 Expresiones escalares 898 APÉNDICE B Una panorámica de SQL3 900 B.l Introducción 900 B.2 Nuevos tipos de datos 901 B.3 Herencia de tipo 906 B.4 Tipos de referencia 907 B.5 Subtablas y supertablas 910 B.6 Otras características 912 APÉNDICE c Abreviaturas, acronimos y símbolos 916 Indice 921 CAPITULO 16 Seguridad 16.1 INTRODUCCIÓN La cuestión de la seguridad de los datos se asocia frecuentemente con la de la integridad de los mismos (al menos en contextos informales), pero ambos conceptos son bastante diferentes. La seguridad se refiere a la protección de los datos contra su revelación, su alteración o su des- trucción no autorizadas, mientras que la integridad se refiere a la precisión o validez de esos datos. Para ponerlo un poco más claro: Seguridad significa proteger los datos ante usuarios no autorizados. Integridad significa protegerlos de usuarios autorizados. O dicho más a la ligera: la seguridad significa garantizar que los usuarios tengan permiso de hacer las cosas que están tratando de hacer y la integridad involucra asegurar que las cosas que están tratando de hacer sean correctas. Por supuesto, también existen algunas similitudes: en ambos casos el sistema necesita estar al tanto de ciertas restricciones que los usuarios no deben violar y en ambos casos, estas res- tricciones deben ser especificadas (generalmente por el DBA) en un lenguaje adecuado y deben ser mantenidas en el catálogo del sistema; también, en ambos casos el DBMS debe vigilar las operaciones del usuario para asegurarse que cumplan estas restricciones. En este capítulo exa- minamos específicamente la seguridad (por supuesto, ya hemos tratado ampliamente el tema de la integridad en el capítulo 8 y en otras partes). Nota: La razón principal por la que separamos las explicaciones de ambos temas, es porque consideramos a la integridad como un asunto ab- solutamente fundamental y la seguridad como un asunto más secundario. Consideraciones generales Existen muchos aspectos sobre el problema de la seguridad, entre ellos se encuentran los siguientes: Aspectos legales, sociales y éticos (por ejemplo, la persona que hace la petición ¿tiene dere cho legal para conocer la información solicitada como, digamos, el crédito de un cliente?); Controles físicos (por ejemplo, ¿el lugar en donde se encuentra la computadora o terminal está bajo llave o con alguna otra protección?); Cuestiones de política (por ejemplo, ¿cómo decide la empresa propietaria del sistema a quién y a qué se le permite tener acceso?); Problemas operacionales (por ejemplo, si se utiliza un esquema de contraseñas, ¿cómo se les mantiene en secreto? ¿con cuánta frecuencia son cambiadas?); Controles de hardware (por ejemplo, ¿la unidad de procesamiento proporciona alguna ca racterística de seguridad, como claves de protección de almacenamiento o un modo de operación protegido?); 504 Capítulo 16 / Seguridad 505 Soporte del sistema operativo (por ejemplo, ¿el sistema operativo subyacente borra el con tenido de la memoria principal y los archivos de disco cuando ha terminado de utilizarlos?); y por último Los asuntos que conciernen únicamente al sistema de base de datos (por ejemplo, ¿tiene el sistema de base de datos un concepto de propiedad de los datos?). Por razones obvias, en este capítulo limitaremos nuestra atención únicamente a los asuntos de esta última categoría (en su mayoría). Actualmente los DBMSs modernos soportan generalmente uno o ambos enfoques con respecto a la seguridad de los datos. Estos enfoques son conocidos como control discrecional y control obligatorio, respectivamente. En ambos casos, la unidad de datos u "objeto de datos" que necesite ser protegido puede comprender desde toda la base de datos (por un lado) hasta un componente específico dentro de una tupia específica (por otro). La manera en que difieren los dos enfoques está indicada brevemente por el siguiente esquema: En el caso del control discrecional, un usuario específico tendrá generalmente diferentes derechos de acceso (también conocidos como privilegios) sobre diferentes objetos; además, existen muy pocas limitaciones —es decir, limitaciones inherentes— sobre qué usuarios pueden tener qué derechos sobre qué objetos (por ejemplo, el usuario Ul podría estar au torizado para ver a A y no a B; y en cambio, el usuario U2 podría estar autorizado para ver a B y no a A). Por lo tanto, los esquemas discrecionales son muy flexibles. Por el contrario, en el caso del control obligatorio, cada objeto de datos está etiquetado con un nivel de clasificación determinado y a cada usuario se le da un nivel de acreditación. Un objeto de datos específico sólo puede ser accedido por los usuarios que tengan el nivel de acreditación adecuado. Por lo tanto, los esquemas obligatorios tienden a ser jerárquicos por naturaleza y (por lo tanto) comparativamente rígidos. (Si el usuario Ul puede ver a A pero no a B, entonces la clasificación de B debe ser más alta que la de A y por lo tanto, ningún usuario U2 podrá ver a B y no a A.) En la sección 16.2 explicamos los esquemas discrecionales y en la sección 16.3 los obligatorios. Independientemente de que estemos tratando con un esquema discrecional o con uno obli- gatorio, todas las decisiones sobre a qué usuarios se les permite realizar qué operaciones sobre qué objetos, son decisiones políticas y no técnicas. Como tales, están claramente fuera de la ju- risdicción del propio DBMS, ya que al DBMS sólo le queda hacer cumplir esas decisiones una vez que se han tomado. De aquí que: Los resultados de esas decisiones políticas (a) deben ser del conocimiento del sistema (esto se logra por medio de instrucciones en un lenguaje de definición adecuado) y (b) deben ser recordadas por el sistema (esto se logra guardándolas en el catálogo). Debe existir algún medio para revisar una cierta petición de acceso contra las restricciones de seguridad aplicables que están en el catálogo. (En general, "petición de acceso" significa la combinación de la operación solicitada más el objeto solicitado más el usuario que lo solicita.) Esa revisión es realizada por el subsistema de seguridad del DBMS, al que tam bién se conoce como subsistema de autorización. Para decidir qué restricciones de seguridad son aplicables a una cierta petición de acceso, el sistema debe ser capaz de reconocer el origen de esa petición; es decir, debe ser capaz de reconocer al usuario solicitante. Por esta razón, cuando los usuarios se registran en el sistema 506 Parte V / Temas adicionales se les pide generalmente que proporcionen no solamente su ID de usuario (para que digan quiénes son), sino también una contraseña (para probar que son quienes dicen ser). Se supone que la contraseña es conocida únicamente por el sistema y por los usuarios legíti- mos del ID al que se refiere.* Dicho sea de paso —con relación a este último punto— tenga presente que cualquier canti- dad de usuarios distintos pueden compartir el mismo ID. De esta forma, el sistema puede soportar grupos de usuarios y por lo tanto, permitir (digamos) que todos los usuarios del departamento de contabilidad compartan los mismos privilegios sobre los mismos objetos. Entonces, las opera- ciones de incorporación o eliminación de usuarios individuales de un grupo determinado, pueden ser realizadas en forma independiente de la operación de especificar qué privilegios sobre qué objetos se aplican para ese grupo. Sin embargo, observe que el lugar obvio para conservar un registro de qué usuarios están en cada grupo, es una vez más el catálogo (o tal vez la propia base de datos). Al respecto, le pedimos que vea la referencia [16.9], la cual describe un sistema en el que los grupos de usuarios pueden estar anidados. Para citar: "La habilidad para clasificar usua- rios en una jerarquía de grupos proporciona una poderosa herramienta para la administración de sistemas grandes con miles de usuarios y objetos." 16.2 CONTROL DE ACCESO DISCRECIONAL Para repetir lo que hemos dicho en la sección anterior, la mayoría de los DBMSs soportan el con- trol discrecional, el control obligatorio o ambos. De hecho, sería más apropiado decir que la ma- yoría de los sistemas soportan el control discrecional y algunos sistemas soportan también el control obligatorio; y puesto que en la práctica es más común encontrar el control discrecional, lo abordaremos primero. Como ya observamos, necesitamos un lenguaje que soporte la definición de las restricciones de seguridad (discrecionales). Sin embargo, por razones bastante obvias, es más fácil decir lo que está permitido en vez de lo que no lo está; por lo tanto, los lenguajes por lo general sopor- tan la definición no de las restricciones de seguridad como tales, sino de las autoridades, las cuales son en efecto lo opuesto a las restricciones de seguridad (si algo está autorizado, no está restringido). Por lo tanto, comenzaremos describiendo brevemente un lenguaje para la definición de autoridades^ Éste es un primer ejemplo sencillo: AUTHORITY AV3 GRANT RETRIEVE ( V#, PROVEEDOR, CIUDAD ), DELETE ON V TO Jim, Fred, Mary ; * Al hecho de verificar que los usuarios sean quienes dicen ser, se le llama autentificación. Observamos de paso que las técnicas de autentificación que están disponibles actualmente son mucho más sofisticadas que la simple revisión de contraseñas, ya que involucran una diversidad de dispositivos biométricos (lectores de huellas digitales, escáneres de retina, generadores de imágenes para geometría de la mano, verificadores de voz, reconocedores de firmas, etcétera). Todos estos dispositivos pueden ser usados de manera efectiva para verificar las "características personales que nadie puede robar" [16.3]. tr Tutorial D, tal como fue definido originalmente en [3.3], no incluye deliberadamente ninguna propiedad para definición de autoridad, pero el lenguaje hipotético presentado en esta sección puede ser considerado como si fuera el "espíritu" del Tutorial D. Capítulo 16 I Segundad 507 Este ejemplo pretende ilustrar el punto de que (por lo general) las autoridades tienen cuatro componentes, que son los siguientes: 1. Un nombre (AV3 en el ejemplo). La autoridad será registrada en el catálogo bajo este nombre. 2. Uno o más privilegios (RETRIEVE —sólo sobre ciertos atributos— y DELETE) especifi cados por medio de la cláusula GRANT. 3. La varrel a la que se aplica la autoridad (la varrel V), especificada por medio de la cláu sula ON. 4. Uno o más "usuarios" (para ser más precisos, IDs de usuario) a quienes se van a otorgar los privilegios especificados sobre la varrel especificada, dados por medio de la cláusula TO. Entonces, la sintaxis general es: AUTHORITY GRANT ON TO ; Explicación: , y son muy claras (con excepción de que consideramos ALL, que significa todos los usuarios conocidos, como un "ID de usuario" válido en este contexto). Cada es alguno de los siguientes: RETRIEVE [ ( )] INSERT [ ( )] UPDATE [ ( )] DELETEALL RETRIEVE (sin calificativos), INSERT (sin calificativos), UPDATE (sin calificativos) y DELETE son muy claras.* Si con RETRIEVE se especifica una lista de nombres de atributos separados con comas, entonces el privilegio se aplica solamente a los atributos especificados; INSERT y UPDATE con una lista de nombres de atributos separados con comas se define en forma similar. La especificación ALL es una abreviatura para todos los privilegios: RETRIEVE (todos los atributos), INSERT (todos los atributos), UPDATE (todos los atributos) y DELETE. Nota: Por razones de simplicidad, ignoramos el hecho de si es necesario algún privilegio espe- cial para realizar las operaciones generales de asignación relacional. También limitamos delibe- radamente nuestra atención a las operaciones de manipulación de datos; aunque por supuesto, en la práctica existen muchas otras operaciones que también querremos tener sujetas a verificación de autorización (tales como las operaciones de definición y eliminación de varrels y las operacio- nes para definir y eliminar a las autoridades mismas). Por razones de espacio, aquí omitimos las consideraciones detalladas sobre tales operaciones. ¿Qué sucedería si algún usuario intentara realizar alguna operación sobre algún objeto y no tiene autorización para ello? Obviamente, la opción más simple es rechazar el intento (y por supuesto, proporcionar la información de diagnóstico adecuada); seguramente dicha respuesta *Bueno, tal vez no tanto, ya que el privilegio RETRIEVE también es necesario simplemente para men- cionar al objeto relevante (por ejemplo, en una definición de vista o en una restricción de integridad), así como para recuperarlo como tal. 508 Parte V / Temas adicionales será comúnmente la más requerida en la práctica y por lo tanto, podemos hacer que sea la predeterminada. Sin embargo, en situaciones más delicadas, tal vez sea más adecuado aplicar otras medidas (por ejemplo, terminar el programa o bloquear el tecleado del usuario). Probablemente también sea necesario registrar tales intentos en una bitácora especial {vigi- lancia de amenazas) para permitir un análisis posterior de los intentos de violación a la se- guridad y también para que sirva —por sí misma— como una medida disuasiva contra la infiltración ilegal (vea el comentario sobre los registros de auditoría al final de esta sección). Por supuesto, también necesitamos una forma para eliminar autoridades: DROP AUTHORITY TIME '09:00:00' AND NOW () < TIME '17:00:00' TO Compras ; Aquí extendemos la sintaxis de AUTHORITY para incluir una cláusula WHEN que es- pecifica determinados "controles de contexto" y también estamos suponiendo que el sistema proporciona dos operadores niládicos —es decir, operadores que no toman operandos— llamados DAY() y NOW(), que tienen interpretaciones obvias. La autori- dad EX5 garantiza que los valores de status de los proveedores pueden ser cambiados por el usuario "Compras" (que identifica presuntamente a cualquier persona del depar- tamento de compras) sólo en un día laboral y sólo durante las horas hábiles. Éste es un ejemplo de lo que en ocasiones se conoce como autoridad dependiente del contexto, ya que una determinada petición de acceso será permitida o no dependiendo del con- texto (que en este caso es la combinación de día de la semana y hora del día en el que es emitido). Otros ejemplos de operadores integrados que probablemente deba soportar de al- guna forma el sistema y que podrían ser útiles para las autoridades dependientes del contexto, incluyen: TODAY o — valor = fecha actual USER() — valor = el ID del usuario actual TERMÍNALO — valor = el ID de la terminal donde se origina la petición actual Para estos momentos, tal vez ya haya notado que —desde un punto de vista concep- tual— todas las autoridades se ven afectadas por "OR". En otras palabras, una cierta peti- ción de acceso (que significa, para repetir, la combinación de la operación solicitada, más el objeto solicitado, más el usuario que lo solicita) es aceptable si y sólo si al menos una autoridad lo permite. Sin embargo, observe que (por ejemplo) si (a) una autoridad per- mite que el usuario Nancy recupere los colores de las partes y (b) otra permite que recupe- re el peso de las partes, no podemos concluir que el usuario pueda recuperar los colores y los pesos de las partes al mismo tiempo (se necesita una autoridad independiente para la combinación). Por último, ha quedado implícito (aunque no está de más decirlo) que los usuarios sólo pueden hacer las cosas que tienen permitidas explícitamente por las autoridades definidas. Cualquier cosa que no esté autorizada explícitamente, ¡está prohibida implícitamente! 510 Parte V / Temas adicionales Modificación de la petición Para ilustrar algunas de las ideas que presentamos anteriormente, describiremos brevemente los aspectos de seguridad del prototipo del University Ingres y su lenguaje de consulta QUEL, ya que adopta un enfoque interesante ante el problema. En esencia, cualquier peti- ción QUEL se modifica automáticamente antes de su ejecución, de tal forma que es im- posible que viole alguna restricción de seguridad especificada. Por ejemplo, supongamos que al usuario U se le permite recuperar partes guardadas solamente en Londres: DEFINE PERMIT RETRIEVE ON P TO U WHERE P.CIUDAD = "Londres" (vea más adelante los detalles de la operación DEFINE PERMIT). Supongamos ahora que el usuario U emite la petición QUEL: RETRIEVE ( P.P#, P.PESO ) WHERE P.COLOR = "Rojo" Si utilizamos el "permiso" para la combinación de la varrel P y el usuario U tal como están guardados en el catálogo, el sistema modifica automáticamente la petición para que sea vista de esta forma: RETRIEVE ( P.P#, P.PESO ) WHERE P.COLOR = "Rojo" AND P.CIUDAD = "Londres" Y por supuesto, esta petición modificada no puede violar la restricción de seguridad. Ob- serve de paso que el proceso de modificación es "silencioso"; de hecho, al usuario U no se le informa cuando el sistema ejecuta una instrucción ligeramente diferente a la petición ori- ginal, ya que este hecho en sí puede ser sensible (al usuario U tal vez ni siquiera se le permita saber que hay partes que no son de Londres). El proceso de modificación de petición que acabamos de ilustrar es de hecho idén- tico a la técnica que se usa para implementar las vistas [8.20] y también —específicamente en el caso del prototipo Ingres— las restricciones de integridad [9.15]. Por lo tanto, una ventaja del esquema es que es muy fácil de implementar, ya que gran parte del código necesario ya existe en el sistema. Otra es que es comparativamente eficiente, ya que el reforzamiento principal de la seguridad sucede en tiempo de compilación y no en tiempo de ejecución (o al menos en parte). Otra ventaja adicional es que no se presentan algu- nas de las dificultades que pueden ocurrir con el enfoque de SQL cuando un usuario de- terminado necesita privilegios diferentes sobre partes diferentes de la misma varrel (vea la sección 16.6). Una desventaja es que no todas las restricciones de seguridad se pueden manejar de manera tan sencilla. A manera de ejemplo, supongamos que al usuario U no se le permite ningún acceso a la varrel P. Por lo tanto, ninguna forma simple "modificada" del RETRIEVE mostrado anteriormente, puede mantener la ilusión de que no existe la varrel P. En su lugar, es necesario producir un mensaje de error explícito del tipo "usted no tiene permitido el ac- ceso a esta varrel". (O tal vez el sistema simplemente podría mentir y decir "no existe esta varrel".) Capitulólo I Seguridad 511 Ésta es entonces la sintaxis de DEFINE PERMIT: DEFINE PERMIT ON [ ( ) ] TO [ AT ] [ FROM < ti e mp o > T O < tie m p o > ] [ ON TO ] [ WHERE ] Esta instrucción es —en forma conceptual— bastante similar a nuestra instrucción AUTHO- RITY; con la excepción de que soporta una cláusula WHERE. He aquí un ejemplo: DEFINE PERMIT APPEND, RETRIEVE, REPLACE ON V ( V#, CIUDAD TO Joe AT TTA4 FROM 9:00 TO 17:00 ON Sat TO Sun WHERE V.STATUS < 50 AND V.V# = VP.V# AND VP.P# P.P# AND P.COLOR = "Rojo Nota: APPEND y REPLACE son los equivalentes de QUEL para nuestros INSERT y UPDATE, respectivamente. Registros de auditoría Es importante no dar por hecho que el sistema de seguridad es perfecto. Un posible infil- trador que tenga la determinación suficiente, encontrará generalmente una forma de pasar por encima de los sistemas de control (en especial si la recompensa es alta). Por lo tanto, en las situaciones donde los datos son muy delicados, o cuando el procesamiento que se realiza sobre éstos es lo suficientemente crítico, un registro de auditoría llega a ser una necesidad. Por ejemplo, si las discrepancias de los datos conducen a la sospecha de que la base de datos ha sido alterada, el registro de auditoría puede ser usado para examinar lo que ha es- tado sucediendo y para verificar que todo está bajo control (o para ayudar a señalar dónde hubo un error). En esencia, un registro de auditoría es un archivo o base de datos especial en el que el sistema lleva automáticamente la cuenta de todas las operaciones realizadas por los usuarios sobre los datos normales. En algunos sistemas el registro de auditoria puede estar integrado físicamente con la bitácora de recuperación (vea el capítulo 14), mientras que en otros, los dos pueden ser distintos pero los usuarios deben —de cualquier forma— tener la posibilidad de consultar el registro de auditoría usando su lenguaje de consulta normal (por supuesto, siempre y cuando tengan autorización). Un registro de auditoría típico podría contener la siguiente información: Petición (texto de origen) Terminal desde la que se llamó a la operación Usuario que llamó a la operación Fecha y hora de la operación 512 Parte V / Temas adicionales Varrels, tupias, atributos afectados Valores antiguos Valores nuevos Como mencioné anteriormente en esta sección, el simple hecho de mantener un registro de auditoría puede ser suficiente para disuadir en algunas situaciones a un posible infiltrador. 16.3 CONTROL DE ACCESO OBLIGATORIO Los controles obligatorios son aplicables a las bases de datos en las que los datos tienen una es- tructura de clasificación bastante estática y rígida, como puede ser el caso de (por ejemplo) de- terminados ambientes militares o gubernamentales. Como expliqué brevemente en la sección 16.1, la idea básica es que cada objeto de datos tiene un nivel de clasificación (por ejemplo, su- persecreto, secreto, confidencial, etcétera) y cada usuario tiene un nivel de acreditación (con las mismas posibilidades que tienen los niveles de clasificación). Se supone que los niveles for- man un ordenamiento estricto (por ejemplo, supersecreto > secreto > confidencial, etcétera). Por lo tanto, se imponen las siguientes reglas que se deben a Bell y La Padula [16.1]: 1. El usuario ¡ puede recuperar el objeto 7 sólo si el nivel de acreditación de i es mayor o igual al nivel de clasificación de j (la "propiedad de seguridad simple"); 2. El usuario i puede actualizar el objeto./ sólo si el nivel de acreditación de í es igual al nivel de clasificación dej (la "propiedad de estrella"). La primera regla es suficientemente obvia, pero la segunda requiere una explicación. Observe primero que otra forma de establecer la segunda regla es decir que, por definición, cualquier cosa escrita por el usuario i adquiere automáticamente un nivel de clasificación igual al nivel de acre- ditación de i. Dicha regla es necesaria para impedir que un usuario con clasificación, por ejemplo, "secreta" copie datos secretos hacia un archivo que tenga una clasificación menor, minando por lo tanto el propósito del esquema de clasificación. Nota: Desde el punto de vista de las operaciones de "escritura" (INSERT) puras, sería suficiente que la segunda regla dijera que el nivel de acre- ditación de ; debe ser menor o igual al nivel de clasificación dej; y la regla en ocasiones aparece de esta forma en la literatura. Pero entonces los usuarios, ¡serían capaces de escribir cosas que no podrían leer! (pensándolo bien, algunas personas tienen dificultades para leer lo que ellas mismas escriben... tal vez la regla más débil no esté tan fuera de la realidad después de todo). Los controles obligatorios comenzaron a recibir mucha atención en el mundo de las bases de datos a principios de los años noventa, ya que fue entonces cuando el Departamento de Defensa de los Estados Unidos comenzó a requerir que cualquier sistema que adquiriera tuviera sopor- te para tales controles. En consecuencia, los fabricantes de DBMS han estado compitiendo entre ellos para implementarlos. Los controles en cuestión están documentados en dos publicaciones importantes del Departamento de Defensa conocidas informalmente como el Libro naranja [16.19] y el Libro lavanda [16.20], respectivamente. El Libro naranja define un conjunto de re- querimientos de seguridad para cualquier "base de computación confiable" (TCB), mientras que el Libro lavanda define específicamente una "interpretación" de los requerimientos TCB para los sistemas de base de datos. De hecho, los controles obligatorios definidos en las referencias [16.19 y 16.20] forman parte de un esquema más general de clasificación de seguridad total, que resumimos aquí para Capítulo 16 I Seguridad 513 efectos de referencia. En primer lugar, los documentos definen cuatro clases de seguridad (D, C, B y A); en términos generales, la clase D es la menos segura, la clase C es más segura que la clase D y así sucesivamente. Decimos que la clase D proporciona protección mínima, la clase C protección discrecional, la clase B protección obligatoria y la clase A protección verificada. Protección discrecional: La clase C está dividida en dos subclases, Cl y C2 (donde Cl es menos segura que C2). Cada una de ellas soporta controles discrecionales, lo que significa que el acceso está sujeto a la discreción del propietario de los datos (como vimos anterior mente en la sección 16.2). Además: 1. La clase Cl distingue entre propiedad y acceso; es decir, soporta el concepto de datos compartidos, permitiendo al mismo tiempo que los usuarios también tengan datos priva dos propios. 2. La clase C2 requiere —adicionalmente— de soportes de contabilización por medio de procedimientos de registro, auditoría y aislamiento de recursos. Protección obligatoria: La clase B es aquella que maneja los controles obligatorios. Está dividida adicionalmente en subclases Bl, B2 y B3 (en donde Bl es la menos segura y B3, la más) de la siguiente manera: 1. La clase Bl requiere "protección de seguridad etiquetada" (es decir, requiere que cada objeto de datos esté etiquetado con su nivel de clasificación: secreto, confidencial, etcé tera). También requiere, en efecto, una instrucción informal de la política de seguridad. 2. La clase B2 requiere además una instrucción formal de lo mismo. También requiere que los canales cubiertos sean identificados y eliminados. Ejemplos de canales cubiertos pudieran ser (a) la posibilidad de inferir la respuesta a una consulta no válida a partir de la respuesta de una válida (vea la sección 16.4) o (b) la posibilidad de deducir informa ción sensible a partir del tiempo que requiere la realización de algún cálculo válido (vea el comentario a la referencia [16.12]). 3. La clase B3 requiere específicamente el soporte de auditoria y recuperación, así como la designación de un administrador de seguridad. Protección verificada: La clase A (la más segura) requiere una prueba matemática de que (a) el mecanismo de seguridad es consistente y que (b) es adecuado para soportar la política de seguridad especificada (!). Varios productos DBMS comerciales proporcionan actualmente controles obligatorios a nivel Bl. También proporcionan —por lo general— controles discrecionales a nivel C2. Ter- minología: a los DBMS que soportan controles obligatorios se les llama en ocasiones sistemas seguros de múltiples niveles [16.13,16.16,16.21] (vea la subsección que viene a continuación). El término sistema confiable también es usado casi con el mismo significado [16.17, 16.19, 16.20]. Seguridad de múltiples niveles Suponga que queremos aplicar las ideas del control de acceso obligatorio a la varrel V de provee- dores. Por razones de claridad y simplicidad, suponga que la unidad de datos sobre la cual que- remos controlar el acceso es la tupia individual dentro de esa varrel. Entonces cada tupia necesita estar etiquetada con su nivel de clasificación, tal vez como se muestra en la figura 16.1 (4 = su- persecreto, 3 = secreto, 2 = confidencial, etcétera). 514 Parte V / Temas adicionales V v# PROVEEDOR STATUS CIUDAD CLASE V1 Smith 20 Londres 2 V2 Jones 10 París 3 V3 Blake 30 París 2 V4 Clark 20 Londres 4 V5 Adams 30 Atenas 3 Figura 16.1 La varrel V con niveles de clasificación (ejemplo). Ahora, supongamos que los usuarios Ul y U2 tienen niveles de acreditación 3 (secreto) y 2 (confidencial), respectivamente. Entonces, ¡los usuarios Ul y í/2 verán a la varrel V de manera diferente! Una petición para recuperar todos los proveedores regresará cuatro tupias (las corres- pondientes a VI, V2, V3 y V5) si es emitida por Ul, pero sólo dos tupias (las de VI y V3) si es emitida por U2. Los que es más, ninguno de los usuarios verá la tupia para V4. Una forma de pensar sobre lo anterior es de nuevo en términos de la modificación de la peti- ción. Considere la siguiente consulta ("obtener los proveedores de Londres"): V WHERE CIUDAD = 'Londres' El sistema modificará esta petición para que se vea de esta forma: V WHERE CIUDAD 'Londres' AND CLASE < acreditación del usuario Consideraciones similares se aplican a las operaciones de actualización. Por ejemplo, el usuario Ul no está consciente de que exista la tupia para V4. Por lo tanto, para ese usuario el siguiente INSERT le parece razonable: INSERT INTO V RELATION { TUPLE { V# V# ( 'V4' ), PROVEEDOR NOMBRE ( 'Baker' ), STATUS 25, CIUDAD 'Roma' } } ; El sistema no debe rechazar este INSERT, ya que al hacerlo le diría efectivamente al usuario Ul que el proveedor V4 sí existe después de todo. Por lo tanto, lo acepta, pero lo modifica para que sea: INSERT INTO V RELATION { TUPLE { V# V# ( 'V4' ), PROVEEDOR NOMBRE ( 'Baker' ), STATUS 25, CIUDAD 'Roma', CLASE CLASE ( 3 ) } } ; Por lo tanto, observe que la clave primaria para los proveedores no es solamente {V#}, sino la combinación {V#, CLASE). Nota: Suponemos, por razones de simplicidad, que sólo existe una clave candidata, la cual, por lo tanto, podemos ver (sin peligro) como la clave primaria. Más terminología: la varrel de proveedores es un ejemplo de una varrel de múltiples nive- les. El hecho de que el "mismo" dato aparezca diferente ante diferentes usuarios es llamado polinstanciación. Después del INSERT que acabamos de explicar, por ejemplo, una petición Capítulo 16 I Seguridad 515 para recuperar al proveedor V4 regresa un resultado a un usuario que tenga acreditación super- secreta, otra al usuario Ul (con acreditación secreta) y otra más al usuario U2 (con acreditación confidencial). UPDATE y DELETE son tratados en forma similar (aquí omitimos los detalles, pero tome en cuenta que muchas de las referencias al final del capítulo tratan estos temas a profundidad). Una pregunta: ¿cree usted que las ideas que se han tratado anteriormente constituyen una vio- lación al Principio de la información! Justifique su respuesta. 1 BASES DE DATOS ESTADÍSTICAS X Nota: Gran parte del material de esta sección y la siguiente apareció originalmente —un poco diferente— en la referencia [16.4]. Una base de datos estadística (en el contexto que estamos considerando) es aquella que per- mite consultas que proporcionen información general (por ejemplo sumas, promedios) pero no consultas que proporcionen información individual. Por ejemplo, la consulta "¿cuál es el salario promedio de los programadores?" podría ser permitida y en cambio, la consulta "¿cuál es el salario de la programadora Mary?", no. El problema con estas bases de datos es que en ocasiones es posible hacer inferencias a partir de consultas válidas para deducir las respuestas a consultas no válidas. Como lo dice la re- ferencia [16.6]: "los resúmenes contienen vestigios de la información original; un fisgón podría (re)construir esta información procesando resúmenes suficientes. A esto se le llama deducción de información confidencial por inferencia". Remarcamos que este problema puede llegar a ser cada vez más importante en la medida en que se incremente el uso de los data warehouse (vea el capítulo 21). He aquí un ejemplo detallado. Suponga que la base de datos contiene solamente una varrel, STATS (vea la figura 16.2). Suponga, por simplicidad, que todos los atributos están definidos sobre tipos de datos primitivos (en esencia, números y cadenas). Suponga además que algún NOMBRE SEXO HIJOS OCUPACIÓN SALARIO IMPUESTOS AUDITORIAS Alf M 3 Programador 50K 10K 3 Bea F 2 Médico 130K 10K 0 Cary F a Programador 56K 18K 1 Dawn F 2 Constructor 60K 12K 1 Ed H 2 Empleado 44K 4K 0 Fay F 1 Artista 30K 0K 0 Guy H 0 Abogado 190K 0K 0 Hal M 3 Constructor de casas 44K 2K 0 Ivy F 4 Programador 64K 10K 1 Joy F 1 Programador 60K 20K 1 Figura 16.2 La varrel STATS (valores de ejemplo). 520 Parte V j Temas adicionales X conjunto identificado por T conjunto identificado po NO T r T conjunto identificado po B — es decir, r E {1} Figura 16.4 El rastreador general T. Si la suposición inicial estuvo equivocada (es decir, si resulta que Tno es un rastreador ge- neral), entonces una o ambas expresiones (BE OR T) y (BE OR NOT 7) pueden ser inadmisibles. Por ejemplo, si las cardinalidades del conjunto resultante para BE y Tsonp y q, respectivamente (donde p < b y b < q < 2b) entonces es posible que la cardinalidad del conjunto resultante para (BE OR 7) —la cual no puede exceder a p + q— sea menor que 2b. En tal situación es necesario hacer otra suposición con el rastreador y volverlo a intentar. La referencia [16.6] sugiere que el proceso de encontrar un rastreador general no es difícil en la práctica. En nuestro ejemplo par- ticular, la suposición inicial es un rastreador general (la cardinalidad en su conjunto resultante es 5) y ambas consultas del paso 3 son admisibles. En resumen, "casi siempre" existe un rastreador general y por lo regular es fácil encon- trarlo y usarlo; de hecho, a menudo es posible encontrar rápidamente un rastreador por mera suposición [16.6]. Incluso en los casos donde no existe un rastreador general, la referencia [16.6] muestra que (por lo general) es posible encontrar rastreadores específicos para consul- tas específicas. Es difícil no concluir que la seguridad en una base de datos estadística es un problema real. ¿Qué podemos hacer entonces? Se han hecho diversas sugerencias en la literatura, pero no es claro que alguna de ellas sea totalmente satisfactoria. Por ejemplo, una posibilidad es el "in- tercambio de datos"; es decir, el intercambio de valores de atributos entre tupias en una forma tal que mantenga la precisión estadística, de manera que aunque se identifique un valor en par- ticular (digamos, un salario específico), no haya forma de saber a qué individuo en especial co- rresponde. La dificultad de este enfoque radica en encontrar conjuntos de entradas cuyos valores puedan ser intercambiados de esta forma. Otras limitaciones similares se aplican a la mayoría de las soluciones sugeridas. Entonces, por el momento parece que debemos aceptar las conclu- siones de Denning [16.6]: "El compromiso es directo y barato. El requerimiento de mantenerla información confidencial en completo secreto no coincide con el requerimiento de producir me- didas estadísticas exactas para subconjuntos arbitrarios de la población. Al menos uno de estos requerimientos debe ser relajado antes de que podamos creer que el secreto está seguro." 16.5 CIFRADO DE DATOS En este capítulo hemos supuesto —hasta el momento— que cualquier posible infiltrador estará usando las facultades normales del sistema para acceder a la base de datos. Ahora pondremos nuestra atención en el caso de un "usuario" que trata de dejar de lado al sistema (por ejemplo, eliminando físicamente parte de la base de datos o interviniendo una línea de comunicación). La medida más efectiva en contra de tal amenaza es el cifrado de datos (o encriptación, como tam- bién se conoce); es decir, el guardado y la transmisión de datos sensibles en forma cifrada. Capítulo 16 I Seguridad 521 Para explicar algunos de los conceptos del cifrado de datos necesitamos presentar un poco más de terminología. A los datos originales (sin cifrado) se les llama texto plano. El texto plano es cifrado sometiéndolo a un algoritmo de cifrado —cuyas entradas son el texto plano y la clave de cifrado— y a la salida de este algoritmo —la forma cifrada del texto plano— se le llama texto cifrado. Los detalles del algoritmo de cifrado son públicos —o al menos no están ocultos especialmente— pero la clave de cifrado se mantiene en secreto. El texto cifrado, que debe ser ininteligible para cualquiera que no posea la clave de cifrado, es lo que se guarda en la base de datos o se transmite por la línea de comunicación. Ejemplo: Hagamos que el texto plano sea la cadena: AS KINGFISHERS CATCH FIRE (Suponemos, por simplicidad, que los únicos caracteres de datos que tenemos que manejar son las letras mayúsculas y los espacios en blanco). Hagamos que la clave de cifrado sea la cadena ELIOT y que el algoritmo de cifrado sea el siguiente: 1. Dividimos el texto plano en bloques de longitud igual a la clave de cifrado: AS + KI N G F I S H E R S + C A T C H + F I R E (los espacios en blanco ahora son mostrados explícitamente como "+"). 2. Reemplazamos cada carácter del texto plano por un entero que esté en el rango de 00 a 26, usando espacio en blanco = 00, A = 01,..., Z = 26: 0119001109 1407060919 0805181900 0301200308 0006091805 3. Repetimos el paso 2 para la clave de cifrado: 0512091520 4. Para cada bloque de texto plano reemplazamos cada carácter por la suma módulo 27 de su codificación de enteros más la codificación de enteros del carácter correspondiente de la clave de cifrado: 0119001109 1407060919 0805181900 0301200308 0006091805 0512091520 0512091520 0512091520 0512091520 0512091520 0604092602 1919152412 1317000720 0813021801 0518180625 5. Reemplazamos cada codificación de enteros del resultado del paso 4 por su equivalente en caracteres: F D I Z B S S 0 X L MQ + G T H M B R A E R R F Y El procedimiento de descifrado para este ejemplo es directo, siempre y cuando se tenga la clave. {Ejercicio: Descifre el texto cifrado mostrado anteriormente.) La pregunta es, ¿qué tan difícil será para un posible infiltrador determinar la clave sin ningún conocimiento previo, te- niendo el texto plano y el texto cifrado? En nuestro ejemplo la respuesta es, obviamente, "no mucho"; pero también es obvio que es posible inventar esquemas mucho más sofisticados. De 522 Parte V / Temas adicionales manera idónea, el esquema empleado debería ser tal, que el trabajo involucrado en romperlo so- brepasara cualquier ventaja potencial que pudiera obtenerse al hacerlo. (De hecho, la misma idea se aplica a todos los aspectos de la seguridad; el objetivo debe ser siempre hacer que el costo de la ruptura del sistema sea significativamente mayor que el beneficio potencial.) El objetivo úl- timo aceptado de tales esquemas es que el inventor del esquema, que tiene el texto plano y el texto cifrado correspondiente, debe ser incapaz de determinar la clave y por lo tanto, incapaz de descifrar otra parte de texto cifrado. El estándar de cifrado de datos El ejemplo anterior hace uso de un procedimiento de sustitución: se usa una clave de cifrado para determinar (para cada carácter del texto plano) un carácter de texto cifrado que va a susti- tuir a ese carácter. La sustitución es uno de los dos enfoques básicos del cifrado como se prac- tica tradicionalmente; el otro es el de la permutación, donde los caracteres del texto plano son simplemente reorganizados en una secuencia diferente. Ninguno de estos enfoques es particu- larmente seguro en sí mismo, pero los algoritmos que combinan a los dos pueden proporcionar un alto grado de seguridad. Uno de estos algoritmos es el estándar de cifrado de datos (DES), desarrollado por IBM y adoptado como estándar federal de los Estados Unidos en 1977 [16.18]. Para usar el DES, el texto plano es dividido en bloques de 64 bits y cada bloque es cifrado usando una clave de 64 bits (de hecho, la clave consta de 56 bits de datos y 8 bits de paridad, por lo que las claves posibles no son 264sino sólo 256). Un bloque es cifrado aplicándole una per- mutación inicial, sometiéndolo posteriormente a una secuencia de 16 pasos complejos de susti- tución y aplicando finalmente otra permutación —la inversa de la permutación inicial— al resultado del último de estos pasos. La sustitución en el ¡esimo paso no está controlada directa- mente por la clave de cifrado original K, sino por una clave Ki que es calculada a partir de los valores de K e i. Para mayores detalles vea la referencia [16.18]. El DES tiene la propiedad de que el algoritmo de descifrado es idéntico al algoritmo de cifrado, con la excepción de que las Ki se aplican en orden inverso. Cifrado de clave pública A través de los años muchas personas han sugerido que probablemente el DES en realidad no es seguro; de hecho, la aparición de procesadores muy rápidos y altamente paralelos sugiere que el DES puede ser roto por fuerza bruta (si no es que por medios más inteligentes). Muchos tam- bién piensan que los esquemas de cifrado de "clave pública" más recientes, dejan obsoletos tec- nológicamente a los enfoques tradicionales DES y similares. En un esquema de clave pública, tanto el algoritmo de cifrado como la clave de cifrado están disponibles y por lo tanto, cualquier persona puede convertir texto plano en texto cifrado. Pero la clave de descifrado correspondien- te se mantiene en secreto (los esquemas de clave pública involucran dos claves, una para el ci- frado y otra para el descifrado). Además, la clave de descifrado no puede ser deducida de manera realista a partir de la clave de cifrado; por consiguiente, incluso la persona que realiza el cifrado original no puede realizar el descifrado correspondiente si no tiene autorización para ello. La idea original del cifrado por clave pública se debe a Diffie y Hellman [16.7]. Describi- mos el enfoque específico más conocido —de Rivest, Shamir y Adleman [16.15]— para mostrar la manera en que el esquema funciona en la práctica. Su enfoque (al que se le conoce generalmente Capitulólo I Seguridad 523 como esquema RSA, debido a las iniciales de sus inventores) está basado en los dos siguientes hechos: 1. Existe un algoritmo rápido para determinar si un número dado es primo. 2. No existe ningún algoritmo rápido para encontrar los factores primos de un número com puesto (es decir, no primo) dado. La referencia [16.10] proporciona un ejemplo en el que determinar (en una máquina dada) si un cierto número de 130 dígitos es primo, toma cerca de 7 minutos; mientras que encontrar los dos factores primos (en la misma máquina) de un número obtenido de multiplicar dos números primos de 63 dígitos se llevaría cerca de 40 mil billones de años (mil billones = 1,000,000,000,000,000).* El esquema RSA funciona de la siguiente manera: 1. Se seleccionan al azar dos números primos grandes, p y q, diferentes y se calcula el pro ducto r = p*q. 2. Se selecciona al azar un número entero grande, e, que sea primo relativo; es decir, que no tenga factores en común con respecto al producto (p - 1) * (q - 1). El número entero e es la clave de cifrado. Nota: La selección de e es directa, ya que podemos usar cualquier número primo que sea mayor ap y q. 3. Se toma la clave de descifrado, d, para que sea el "multiplicativo inverso" único de e mó dulo (p - 1) * (q -1), es decir, d * e = 1 módulo (p - 1) * (q - 1) El algoritmo para calcular d a partir de e, p y q, es directo y es proporcionado en la refe- rencia [16.15]. 4. Se publican los enteros rye, pero no d. 5. Para cifrar un texto plano P (por simplicidad, suponemos que es un entero menor que r) lo reemplazamos por el texto cifrado C, el cual se calcula de la siguiente manera: C = P" módulo r 6. Para descifrar una parte del texto cifrado C lo reemplazamos por el texto plano P, que se calcula de la manera siguiente: P = C módulo r La referencia [16.15] prueba que este esquema funciona; es decir, que el descifrado de C usando d recupera el P original. Sin embargo, como afirmamos anteriormente, calcular d cono- ciendo únicamente r y e (y no p o q) no es factible. Por lo tanto, cualquier persona puede cifrar texto plano, pero sólo los usuarios autorizados (que tienen d) pueden descifrar el texto cifrado. *A pesar de ello, existen algunas dudas acerca de la seguridad del esquema RSA. La referencia [16.10] fue publicada en 1977. En 1990 Arjen Lenstra y Mark Manasse factorizaron satisfactoriamente un número de 155 dígitos [16.22] y estimaron que el tiempo de cálculo involucrado (que fue repartido en mil computadoras) era equivalente a ejecutar un millón de instrucciones por segundo en una sola máquina durante 273 años. El número de 155 dígitos fue el noveno número de Fermat2512+ 1 (observe que 512 = 29). Vea también la referencia [16.12], la cual reporta un enfoque completamente diferente ¡y exitoso! para la ruptura del cifrado RSA. 524 Parte V / Temas adicionales Damos un ejemplo trivial para ilustrar el procedimiento anterior. Por razones obvias nos limitamos a números muy pequeños. Ejemplo: Hagamosp = 3, q = 5; entonces r= 15 y el producto (p - 1) * (q- 1) = 8. Hagamos e = 11 (un número primo mayor que p y q). Para calcular d tenemos d * 11 =1 módulo 8 y por lo tanto, d = 3. Ahora hagamos que el texto plano P consista en el entero 13. Entonces, el texto cifrado C está dado por C = f módulo r = 13" módulo 15 = 1,792,160,394,037 módulo 15 7 Ahora el texto plano P original está dado por P = C módulo r 7 3 módulo 15 = 343 módulo 15 - 13 I Puesto que e y d son inversos entre sí, los esquemas de cifrado de clave pública también permiten que los mensajes cifrados sean "firmados" en forma tal que el receptor pueda estar seguro de que el mensaje se originó en la persona que dice haberlo hecho (es decir, las "fir- mas" no se pueden falsificar). Supongamos que A y B son dos usuarios que desean comuni- carse entre sí usando un esquema de cifrado de clave pública. Entonces Ay B publicarán un algoritmo de cifrado (incluyendo en cada caso la clave de cifrado correspondiente) pero por supuesto, mantendrán el algoritmo de descifrado y la clave en secreto (incluso entre sí). Ha- gamos que los algoritmos de cifrado sean ECA y ECB (para cifrar mensajes que serán envia- dos a A y B, respectivamente) y hagamos que los algoritmos de descifrado correspondientes sean DC A y DCB, respectivamente. ECA y DC A son inversos entre sí, al igual que ECB y DCB. Ahora supongamos que A desea enviar a B un fragmento de texto plano P. En lugar de calcular ECB (P) y transmitir el resultado, A aplica primero a P el algoritmo de descifrado DCA y luego cifra el resultado y lo transmite como el texto cifrado C: C = ECB ( DCA ( P ) ) Al recibir C, el usuario B aplica el algoritmo de descifrado DCB y luego el algoritmo de cifrado ECA produciendo el resultado final P: ECA ( DCB ( C ) ) = ECA ( DCB ( ECB ( DCA ( P ) ) ) ) ECA ( DCA ( P) ) I* ya que DCB y ECB se cancelan */ = P Ahora B sabe que el mensaje en efecto proviene de A, ya que ECA producirá P sólo si el algoritmo DCA fue utilizado en el proceso de cifrado y ese algoritmo sólo lo conoce a A. Nadie, incluso B, puede falsificar la firma de A. X 528 Parte V / Temas adicionales 2. REVOKE SELECT, UPDATE ( PROVEEDOR, STATUS ), DELETE ON VL FROM Dan, Misha CASCADE ; 3. REVOKE SELECT ON VVPPR FROM Giovanni RESTRICT ; 4. REVOKE SELECT ON VVC FROM Fidel RESTRICT ; RESTRICT vs. CASCADE: supongamos que/? es algún privilegio sobre algún objeto y supon- gamos que el usuario A otorga p al usuario B, quien a su vez lo otorga al usuario C. ¿Qué deberá pasar si A revoca ahora p a S? Supongamos por un momento que REVOKE tiene éxito. Entonces el privilegio p que tiene C quedaría "abandonado"; sería derivado de un usuario, como B, quien ya no lo tiene. El propósito de la opción RESTRICT vs. CASCADE es evitar la posibilidad de privi- legios abandonados. Para ser más específicos, RESTRICT ocasiona que REVOKE falle si conduce a algún privilegio abandonado, y CASCADE ocasiona que tales privilegios sean revocados. Por último, la eliminación de un dominio, tabla base, columna o vista revoca automática- mente todos los privilegios que tengan todos los usuarios sobre los objetos eliminados. 16.7 RESUMEN Hemos explicado diversos aspectos del problema de la seguridad de la base de datos. Comen- zamos contrastando la seguridad y la integridad: la seguridad involucra asegurar que a los usua- rios se les permita hacer las cosas que están tratando de hacer y la integridad involucra asegurar que las cosas que dichos usuarios están tratando de hacer sean correctas. En otras palabras, la seguridad involucra la protección de los datos contra su revelación, alteración o destrucción no autorizadas. La seguridad se hace cumplir mediante el subsistema de seguridad del DBMS, el cual ve- rifica todas las peticiones de acceso contra las restricciones de seguridad almacenadas en el catálogo del sistema. Primero consideramos los esquemas discrecionales, donde el acceso a un objeto dado queda a la discreción del propietario del objeto. Cada autoridad en un esquema dis- crecional tiene un nombre, un conjunto de privilegios (RETRIEVE, UPDATE, etcétera), una varrel correspondiente (es decir, los datos a los que se aplica la restricción) y un conjunto de usuarios. Dichas autoridades pueden ser usadas para proporcionar controles dependientes del valor, independientes del valor, de resúmenes estadísticos y dependientes del contexto. Es posible usar un registro de auditoría para registrar los intentos de ruptura de la seguridad. Di- mos un breve vistazo a una técnica de implementación para los esquemas discrecionales, cono- cida como modificación de petición. Esta técnica fue lanzada por primera vez en el prototipo de Ingres junto con el lenguaje QUEL. Después tratamos los controles obligatorios, donde cada objeto tiene un nivel de clasifi- cación y cada usuario tiene un nivel de acreditación. Explicamos las reglas para el acceso bajo este esquema. También resumimos el esquema de clasificación de seguridad definido por el De- partamento de Defensa de los Estados Unidos en las referencias [16.19 y 16.20] y tratamos brevemente las ideas de varrels de múltiples niveles y polinstanciación. Posteriormente tratamos los problemas especiales de las bases de datos estadísticas. Una base de datos estadística es aquella que contiene gran cantidad de conceptos de información in- dividual sensible, pero que en teoría proporciona a sus usuarios solamente información de resú- menes estadísticos. Vimos que la seguridad de estas bases de datos es comprometida fácilmente por medio de los rastreadores (un hecho que debe causar un poco de alarma, tomando en cuen- Capítulo 16 / Seguridad 529 ta que el nivel de interés es cada vez mayor en los sistemas de almacenamiento de datos; vea el capítulo 21). Luego examinamos el cifrado de datos y mencionamos las ideas básicas de sustitución y permutación, explicando lo que es el estándar de cifrado de datos y describiendo a grandes rasgos la forma en que funcionan los sistemas de clave pública. En particular, vimos un ejemplo simple del esquema RSA (número primo). También tratamos el concepto de firma digital. También describimos brevemente las características de seguridad de SQL; en particular el uso de vistas para ocultar información y el uso de GRANT y REVOKE para controlar qué usuarios tienen qué privilegios sobre qué objetos (principalmente tablas base y vistas). En conclusión, vale la pena enfatizar el punto de que no es bueno que el DBMS proporcione un amplio conjunto de controles de seguridad, si permite que esos controles sean ignorados de alguna forma. En DB2, por ejemplo, la base de datos está guardada físicamente como archivos del sistema operativo y por lo tanto, el mecanismo de seguridad del DB2 sería casi inútil si fuera posible acceder a esos archivos desde un programa convencional por medio de los servicios con- vencionales del sistema operativo. Por está razón, el DB2 trabaja en armonía con sus diversos sistemas integrados —en particular con el sistema operativo subyacente— para garantizar que el sistema total sea seguro. Los detalles están más allá del alcance de este capítulo, pero debe quedar claro el mensaje. EJERCICIOS 16.1 Hagamos que la varrel base STATS sea como en la sección 16.4: STATS { NOMBRE, SEXO, HIJOS, OCUPACIÓN, SALARIO, IMPUESTOS, AUDITORIAS } PRIMARY KEY { NOMBRE } Usando el lenguaje hipotético presentado en la sección 16.2, defina las restricciones de seguridad necesarias para otorgar: a. Al usuario Ford: privilegios de RETRIEVE sobre toda la varrel. b. Al usuario Smith: privilegios de INSERT y DELETE sobre toda la varrel. c. A cada usuario: privilegios de RETRIEVE sobre la tupia propia del usuario (solamente). d. Al usuario Nash: privilegios de RETRIEVE sobre toda la varrel y privilegios de UPDATE sobre los atributos SALARIO e IMPUESTOS (solamente). e. Al usuario Todd: privilegios de RETRIEVE sobre los atributos NOMBRE, SALARIO e IM PUESTOS (solamente). f. Al usuario Ward: privilegios de RETRIEVE similares a los de Todd y privilegios de UPDATE sobre los atributos SALARIO e IMPUESTOS (solamente). g. Al usuario Pope: privilegios completos (RETRIEVE, UPDATE, INSERT, DELETE) sobre tu pias de predicadores (solamente). h. Al usuario Jones: privilegios de DELETE sobre tupias de personas que no tienen una ocupación especializada; donde la ocupación no especializada se define como aquella que pertenece a más de diez personas. i. Al usuario King: privilegios de RETRIEVE para los salarios máximo y mínimo por ocupación. 16.2 Considere lo que implica extender la sintaxis de las instrucciones AUTHORITY para incluir un control sobre operaciones como definición y eliminación de varrels base, definición y eliminación de vistas, definición y eliminación de autoridades, etcétera. 530 Parte V / Temas adicionales 16.3 Considere nuevamente la figura 16.2. Suponga que sabemos por otras fuentes que Hal es un cons tructor de casas con al menos dos hijos. Escriba una secuencia de consultas estadísticas que revela rán la cifra de impuestos de Hal usando un rastreador individual. Suponga, al igual que en la sección 16.4, que el sistema no responderá a consultas que tengan una cardinalidad del conjunto resultante menor que 2 o mayor que 8. 16.4 Repita el ejercicio 16.3, pero usando un rastreador general en lugar de uno individual. 16.5 Descifre el siguiente texto cifrado, que fue producido en una forma similar a la que usamos en el ejemplo "AS KINGFISHERS CATCH FIRE" de la sección 16.5, pero usando una clave de cifrado diferente de cinco caracteres: F N W A L J P V J C F P E X E A B W N E A Y E I P S U S V D 16.6 T r a b a j e e n e l e s q u e m a d e c i f r a d o d e c l a v e p ú b l i c a R S A c o n p = l , q = 5 y e = \ l p a r a e l t e x t o plano P = 3. 1 6. 7 ¿Puede imaginar cualquier problema de implementación u otra desventaja que pueda ser cau sada por el cifrado? 16.8 Dé soluciones SQL para el ejercicio 16.1. 16.9 Escriba instrucciones SQL para eliminar los privilegios otorgados en su solución al ejercicio anterior. REFERENCIAS Y BIBLIOGRAFÍA Para un panorama más amplio sobre la seguridad en general vea el libro de Castaño et al. [16.2]. Para un tratamiento técnico más detallado vea el libro de Denning [16.5]. Las demás referencias son en su mayoría, documentos de estándares o artículos técnicos (tutoriales o contribuciones de investigación) sobre diversos aspectos específicos del problema de la seguridad; también hay algunos artículos de periódicos. 16.1 D. E. Bell y L. J. La Padula: "Secure Computer Systems: Mathematical Foundations and Model", MITRE Technical Report M74-244 (mayo, 1974). 16.2 Silvana Castaño, Mariagrazia Fugini, Giancarlo Martella y Pierangela Samarati: Database Se curity. New York, N.Y.: ACM Press/Reading, Mass.: Addison-Wesley (1995). 16.3 James Daly: "Fingerprinting a Computer Security Code", Computer-world (julio 27, 1992). 16.4 C. J. Date: "Security", capítulo 4 de An Introduction to Database Systems: Volume II. Reading, Mass.: Addison-Wesley (1983). 16.5 Dorothy E. Denning: Cryptography and Data Security. Reading, Mass.: Addison-Wesley (1983). 16.6 Dorothy E. Denning y Peter J. Denning: "Data Security", ACM Comp. Surv. 11, No. 3 (septiem bre, 1979). Es un buen tutorial que trata los controles de acceso discrecional, los controles de acceso obligatorio (llamados aquí controles de flujo), el cifrado de datos y los controles de inferencia (el problema especial de las bases de datos estadísticas). 16.7 W. Diffie and M. E. Hellman: "New Directions in Cryptography", IEEE Transactions on In formation Theory IT-22 (noviembre, 1976). Capítulo 16 I Seguridad 531 16.8 Ronald Fagin: "On an Authorization Mechanism", ACM TODS 3, No. 3 (septiembre, 1978). Una corrección amplia a la referencia [16.11]. Bajo ciertas circunstancias el mecanismo de la re- ferencia [16.11] eliminaría un privilegio que no debería ser eliminado. Este artículo corrige esa falla. 16.9 Roberto Gagliardi, George Lapis y Bruce Lindsay: "A Flexible and Efficient Database Autho rization Facility", IBM Research Report RJ6826 (mayo 11, 1989). 16.10 Martin Gardner: "A New Kind of Cipher That Would Take Millions of Years to Break", Sci entific American 237, No. 2 (agosto, 1977). Es una buena introducción informal al trabajo realizado sobre el cifrado de clave pública. El tí- tulo puede ser una exageración [16.12], [16.22]. 16.11 Patricia P. Griffiths y Bradford W. Wade: "An Authorization Mechanism for a Relational Data Base System", ACM TODS 1, No. 3 (septiembre, 1976). Describe el mecanismo de GRANT y REVOKE propuesto originalmente para el System R. El esquema que está actualmente en el estándar SQL está basado en ese mecanismo, aunque los de- talles son muy diferentes. 16.12 Nigel Hawkes: "Breaking into the Internet", London Times (marzo 18, 1996). Describe la manera en que un experto en computación rompió el esquema RSA midiendo cuánto tiempo necesita el sistema para descifrar mensajes, "el equivalente electrónico de adivinar la combinación de una caja fuerte observando a alguien girar la perilla y viendo qué tanto lo hace". 16.13 Sushil Jajodia y Ravi Sandhu: "Toward a Multi-Level Secure Relational Data Model", Proc. 1991 ACM SIGMOD Int. Conf. on Management of Data, Denver, Colo, (junio, 1991). Como expliqué en la sección 16.3, "múltiples niveles" hace referencia —en un contexto de se- guridad— a un sistema que soporta controles de acceso obligatorios. Este artículo sugiere que gran parte de la actividad actual en el campo es hecha a la medida debido a que hay muy poco consenso sobre los conceptos básicos y propone un inicio formalizando los principios de los sis- temas de múltiples niveles. 16.14 Abraham Lempel: "Cryptology in Transition", ACM Comp. Surv. 11, No. 4: Special Issue on Cryptology (diciembre, 1979). Es un buen tutorial sobre el cifrado y algunos temas relacionados. 16.15 R. L. Rivest, A. Shamir y L. Adleman: "A Method for Obtaining Digital Signatures and Pub lic Key Cryptosystems", CACM21, No. 2 (febrero, 1978). 16.16 Ken Smith y Marianne Winslett: "Entity Modeling in the MLS Relational Model", Proc. 18th Int. Conf. on Very Large Data Bases, Vancouver, Canada (agosto, 1992). En el título de este artículo, "MLS" significa "seguro de múltiples niveles" [16.13], Este artículo se enfoca en el significado de las bases de datos MLS y propone una nueva cláusula BELIEVED BY sobre las operaciones de recuperación y actualización, con el fin de dirigir estas operaciones hacia el estado particular de la base de datos que es entendido o "creído" por un usuario especí- fico. Se dice que este enfoque resuelve varios problemas que se presentan con enfoques ante- riores. Vea también la referencia [16.21]. 16.17 Bhavani Thuraisingham: "Current Status of R&D in Trusted Database Management Systems", ACM SIGMOD Record 21, No. 3 (septiembre, 1992). Es un breve estudio y un amplio conjunto de referencias sobre sistemas "confiables" o de múlti- ples niveles (como era a principios de los años noventa). 16.18 U.S. Department of Commerce /National Bureau of Standards: Data Encryption Standard. Federal Information Processing Standards Publication 46 (enero 15, 1977). 532 Parte V / Temas adicionales Define el estándar oficial de cifrado de datos (DES) a ser usado por las agencias federales y cualquier otra persona que lo desee. Es adecuado implementar el algoritmo de cifrado/descifrado (vea la sec- ción 16.5) en un chip de hardware; lo que significa que los dispositivos que lo incorporen podrán operar a una alta velocidad de datos. Hay varios de estos dispositivos disponibles comercialmente. 16.19 U.S. Department of Defense: Trusted Computer System Evaluation Criteria (el "Libro naranja"), documento No. DoD 5200-28-STD. DoD National Computer Security Center (diciembre, 1985). 16.20 U.S. National Computer Security Center: Trusted Database Management System Interpretation of Trusted Computer System Evaluation Criteria (el "Libro Lavanda"), documento No. NCSC-TG-201, Versión I (abril, 1991). 16.21 Marianne Winslett, Kenneth Smith y Xiaolei Qian: "Formal Query Languages for Secure Relational Databases", ACM TODS 19, No. 4 (diciembre, 1994). Continúa el trabajo de la referencia [16.16]. 16.22 Ron Wolf: "How Safe Is Computer Data? A Lot of Factors Govern the Answer", San Jose Mercury News (julio 5, 1990). RESPUESTAS A EJERCICIOS SELECCIONADOS 16.1 a. AUTHORITY AM GRANT RETRIEVE ON STATS TO Ford ; b. AUTHORITY BBB GRANT INSERT, DELETE ON STATS TO Smith ; C. AUTHORITY CCC GRANT RETRIEVE ON STATS WHEN USER () NOMBRE TO ALL ; Estamos suponiendo que los usuarios usan su propio nombre como ID de usuario. Observe el uso de una cláusula WHEN y el operador niládico integrado USER(). d. AUTHORITY DDD GRANT RETRIEVE, UPDATE ( SALARIO, IMPUESTOS ) ON STATS TO Nash ; e. AUTHORITY EEE GRANT RETRIEVE ( NOMBRE, SALARIO, IMPUESTOS ) ON STATS TO Todd ; f. AUTHORITY FFF GRANT RETRIEVE ( NOMBRE, SALARIO, IMPUESTOS ), UPDATE ( SALARIO, IMPUESTOS ) ON STATS TO Ward ; Capitulólo I Seguridad 533 g. VAR PREDICADORES VIEW STATS WHERE OCUPACIÓN = 'Predicador' ; AUTHORITY GGG GRANT ALL ON PREDICADORES TO Pope ; Observe la necesidad de usar una vista en este ejemplo. h. VAR NOESPECIALISTA VIEW WITH ( STATS RENAME OCUPACIÓN AS X ) AS T1 , ( EXTEND STATS ADD COUNT ( T1 WHERE X = OCUPACIÓN ) AS Y ) AS T2, ( T2 WHERE Y > 10 ) AS T3 : T3 { ALL BUT Y } AUTHORITY HHH GRANT DELETE ON NOESPECIALISTA TO Jones ; i. VAR TRABAJOMAXMIN VIEW WITH ( STATS RENAME OCUPACIÓN AS X ) AS T1 , ( EXTEND STATS ADD MAX ( T1 WHERE X = OCUPACIÓN, SALARIO ) AS SALMAX, MIN ( T1 WHERE X = OCUPACIÓN, SALARIO ) AS SALMIN ) AS T2 : T2 { OCUPACIÓN, SALMAX, SALMIN } AUTHORITY III GRANT RETRIEVE ON TRABAJOMAXMIN TO King ; 16.2 Aquí sólo hacemos una observación: un usuario que tiene la autoridad para crear una nueva va rrel base (y de hecho lo hace) puede ser visto como el propietario de esa nueva varrel. Al igual que como sucede en SQL, al propietario de una varrel base dada se le deben otorgar automáticamente todos los privilegios posibles sobre esa varrel, incluyendo no solamente los privilegios de RE TRIEVE, INSERT, UPDATE y DELETE (por supuesto), sino también los privilegios para definir au toridades que otorguen privilegios a otros usuarios sobre esa varrel. 16.3 Un rastreador individual para Hal es HIJOS > 1 AND NOT ( OCUPACIÓN = 'Constructor de casas' ) Considere la siguiente secuencia de consultas: COUNT ( STATS WHERE HIJOS > 1 ) Resultado: 6. COUNT ( STATS WHERE HIJOS > 1 AND NOT ( OCUPACIÓN = 'Constructor de casas' ) ) Resultado: 5. Por lo tanto, la expresión HIJOS > 1 AND OCUPACIÓN 'Constructor de casas' Identifica en forma única a Hal. » SUM ( STATS WHERE HIJOS > 1, IMPUESTOS ) 534 Parte V / Temas adicionales Resultado: 48 K. SUM ( STATS WHERE HIJOS > 1 AND NOT ( OCUPACIÓN = 'Constructor de casas' ), IMPUESTOS ) Resultado: 46K. Por lo tanto, la cifra de impuestos de Hal es 2K. 16.4 Rastreador general: SEXO = 'P. SUM ( STATS WHERE SEXO = 'F1, IMPUESTOS ) Resultado: 70 K. SUM ( STATS WHERE NOT ( SEXO 'F' ), IMPUESTOS ) Resultado: 16K. Por lo tanto, el impuesto total es 86K. SUM ( STATS WHERE ( HIJOS > 1 ANO OCUPACIÓN = 'Constructor de casas1 ) OR SEXO = ' F' , IMPUESTOS ) Resultado: 72K. SUM ( STATS WHERE ( HIJOS > 1 AND OCUPACIÓN = 'Constructor de casas1 ) OR NOT ( SEXO = ' F' ), IMPUESTOS ) Resultado: 16K. Si sumamos estos resultados y restamos el total previamente calculado, tenemos la cifra de impuesto de Hal = 88K - 86K = 2K. | 16.5 El texto plano es EYES I DARE NOT MEET IN DREAMS ¿Cuál es la clave de cifrado? 16.7 Un problema es que, aun en un sistema que soporta cifrado, los datos deben ser procesados inter- namente en forma de texto plano (para que las comparaciones operen correctamente) y por lo tanto sigue existiendo el riego de que los datos delicados sean accesibles desde aplicaciones ejecutadas en forma concurrente o que aparezcan en un vaciado de memoria. También existen algunos problemas técnicos para el indexado de datos cifrados y el mantenimiento de registros de bitácora para esos datos. 16.8 a. GRANT SELECT ON STATS TO Ford ; b. GRANT INSERT, DELETE ON STATS TO Smith ; C. CREATE VIEW MIA AS SELECT STATS.* FROM STATS WHERE STATS.NOMBRE CURRENTUSER ; GRANT SELECT ON MIA TO PUBLIC ; Capitulólo / Seguridad 535 Aquí estamos suponiendo que los usuarios usan su propio nombre como ID de usuario. Ob- serve el uso del operador niládico integrado CURRENT_USER. d. GRANT SELECT, UPDATE ( SALARIO, IMPUESTOS ) ON STATS TO Nash ; e. CREATE VIEW UST AS SELECT STATS.NOMBRE, STATS.SALAR10, STATS.IMPUESTOS FROM STATS ; GRANT SELECT ON UST TO Todd ; Aquí, SQL tiene que usar una vista debido a que no soporta privilegios de SELECT especí- ficos de columna. f. GRANT SELECT, UPDATE ( SALARIO, IMPUESTOS ) ON UST TO Ward ; Esta solución usa la misma vista que la anterior. g. CREATE VIEW PREDICADORES AS SELECT STATS.* FROM STATS WHERE STATS.OCUPACIÓN = 'Predicador' ; GRANT ALL PRIVILEGES ON PREDICADORES TO Pope ¡ Observe el uso de la abreviatura "ALL PRIVILEGES" en este ejemplo. Sin embargo, ALL PRIVILEGES no significa literalmente todos los privilegios, sino sólo todos los privilegios sobre el objeto relevante para el cual el usuario que está emitiendo el GRANT tiene autori- dad de otorgamiento. h. CREATE VIEW NOESPECIALISTA AS SELECT STX.* FROM STATS AS STX WHERE ( SELECT COUNT (*) FROM STATS AS STY WHERE STY.OCUPACIÓN = STX.OCUPACIÓN ) > 10 ; GRANT DELETE ON NOESPECIALISTA TO Jones ; i. CREATE VIEW TRABAJOMAXMIN AS SELECT STATS.OCUPACIÓN, MAX ( STATS.SALARIO ) AS SALMAX, MIN ( STATS.SALARIO ) AS SALMIN FROM STATS GROUP BY STATS.OCUPACIÓN ; GRANT SELECT ON TRABAJOMAXMIN TO King ; a. REVOKE SELECT ON STATS FROM Ford RESTRICT ; 16.9 b. REVOKE INSERT, DELETE ON STATS FROM Smith RESTRICT ; C. REVOKE SELECT ON MIA FROM PUBLIC RESTRICT ; d. REVOKE SELECT, UPDATE ( SALARIO, IMPUESTOS ) ON STATS FROM Nash RESTRICT ; 536 Parte V / Temas adicionales e. REVOKE SELECT ON UST FROM Todd RESTRICT ; f. REVOKE SELECT, UPDATE ( SALARIO, IMPUESTOS ) ON UST FROM Ward RESTRICT ; g. REVOKE ALL PRIVILEGES ON PREDICADORES FROM Pope RESTRICT ; h. REVOKE DELETE ON NOESPECIALISTA FROM Jones RESTRICT ; i. REVOKE SELECT ON TRABAJOMAXMIN FROM King RESTRICT ; CAPITULO 20 Bases de datos distribuidas 20.1 INTRODUCCIÓN Tocamos el tema de las bases de datos distribuidas al final del capítulo 2, donde dijimos que (para citar) "el soporte completo para las bases de datos distribuidas implica que una sola apli- cación debe ser capaz de operar de manera transparente sobre los datos que están dispersos en una variedad de bases de datos diferentes, administradas por una variedad de distintos DBMSs, ejecutadas en diversas máquinas diferentes, manejadas por varios sistemas operativos diferentes y conectadas a una variedad de redes de comunicación distintas; donde el término de manera transparente significa que la aplicación opera desde un punto de vista lógico como si todos los datos fueran manejados por un solo DBMS y ejecutados en una sola máquina". Ahora estamos en posición de analizar estas ideas con mayor detalle. Para ser específicos, en este capítulo ex- plicaremos exactamente lo que es una base de datos distribuida, la razón por la que tales bases de datos están llegando a ser cada vez más importantes, así como algunos de los problemas téc- nicos en el campo de las bases de datos distribuidas. El capítulo 2 también trató brevemente a los sistemas cliente-servidor, los cuales pueden ser considerados como un caso especial sencillo de los sistemas distribuidos en general. En la sección 20.5 consideraremos específicamente a los sistemas cliente-servidor. Explicamos el plan general del capítulo al final de la siguiente sección. 20.2 ALGUNOS PUNTOS PRELIMINARES Comenzamos con una definición funcional (un poco imprecisa en este momento): Un sistema de base de datos distribuida consiste en una colección de sitios, conectados por medio de algún tipo de red de comunicación, en el cual a. cada sitio es un sistema de base de datos completo por derecho propio, pero b. los sitios han acordado trabajar juntos, a fin de que un usuario de cualquier sitio pueda acceder a los datos desde cualquier lugar de la red, exactamente como si los datos estu vieran guardados en el propio sitio del usuario. De aquí deducimos que la llamada "base de datos distribuida" es en realidad un tipo de base de datos virtual cuyas partes componentes están almacenadas en varias bases de datos "reales" distintas que se encuentran en varios sitios distintos (de hecho, es la unión lógica de esas bases de datos reales). La figura 20.1 muestra un ejemplo. 651 652 Parte V / Temas adicionales Nueva York Londres Los Angeles San Francisco Figura 20.1 Un sistema de base de datos distribuida típico. Para repetir, observe que cada sitio es un sitio de sistema de base de datos por derecho pro- pio. En otras palabras, cada sitio tiene sus propias bases de datos "reales", sus propios usuarios locales, su propio DBMS local y software de administración de transacciones (incluyendo su propio software local para bloqueo, registro en bitácora, recuperación, etcétera), así como su propio administrador CD (de comunicación de datos) local. En particular, un usuario determinado puede realizar operaciones sobre los datos desde su propio sitio local, tal como si ese sitio no partici- para nunca en el sistema distribuido (al menos, éste es un objetivo). Entonces, el sistema de base de datos distribuida puede ser considerado como un tipo de sociedad entre los DBMSs locales en cada uno de los sitios locales; un nuevo componente de software en cada sitio —de manera lógica, una extensión del DBMS local— proporciona la funcionalidad de sociedad necesaria, y es la combinación de este nuevo componente y el DBMS existente, lo que constituye lo que gene- ralmente llamamos sistema de administración de base de datos distribuida. Capítulo 20 I Bases de datos distribuidas 653 Dicho sea de paso, es común suponer que los sitios componentes están dispersos físicamente —quizá también dispersos geográficamente, como lo sugiere la figura 20.1—, aunque de hecho basta con que estén dispersos lógicamente. Dos "sitios" pueden incluso coexistir en la misma máquina física (especialmente durante el período de la prueba inicial del sistema). De hecho, el énfasis sobre los sistemas distribuidos ha ido y venido a lo largo del tiempo. Las primeras in- vestigaciones tendían a dar por hecho la distribución geográfica; sin embargo la mayoría de las primeras instalaciones comerciales involucraban la distribución local con (por ejemplo) varios "sitios" en el mismo edificio y conectados por medio de una LAN (red de área local). Sin em- bargo, más recientemente la enorme proliferación de las WANs (redes de área amplia) ha revivi- do nuevamente el interés en la posibilidad de una distribución geográfica. En cualquier caso, desde una perspectiva de base de datos, hay muy poca diferencia —ya que es necesario resolver prácticamente los mismos problemas técnicos (de la base de datos)— y por lo tanto, para efec- tos de este capítulo podemos ver razonablemente a la figura 20.1 como una representación de un sistema típico. Nota: Para simplificar la explicación supondremos, mientras no digamos otra cosa, que el sistema es homogéneo en el sentido de que cada sitio está ejecutando una copia del mismo DBMS. Nos referiremos a esto como la suposición de homogeneidad estricta. En la sección 20.6 exploraremos la posibilidad —y algunas de las implicaciones— de la flexibilización de esta suposición. Ventajas ¿Por qué son necesarias las bases de datos distribuidas? La respuesta básica a esta pregunta es que las empresas ya están generalmente distribuidas al menos de manera lógica (en divisiones, departamentos, grupos de trabajo, etcétera) y es muy probable que también lo estén de manera física (en plantas, fábricas, laboratorios, etcétera); de esto deducimos que por lo general también los datos ya están distribuidos, ya que cada unidad organizacional dentro de la empresa man- tendrá naturalmente los datos que son importantes para su propia operación. Por lo tanto, el valor de la información total de la empresa está dividido en lo que a veces llamamos islas de informa- ción. Y lo que hace un sistema distribuido es proporcionar los puentes necesarios para conectar a esas islas entre sí. En otras palabras, permite que la estructura de la base de datos refleje la estruc- tura de la empresa —los datos locales son conservados localmente en el lugar donde pertenecen de manera más lógica— y al mismo tiempo, permite tener acceso a datos remotos cuando sea necesario. Un ejemplo le ayudará a aclarar lo anterior. Considere de nuevo la figura 20.1. Por razones de simplicidad, suponga que hay solamente dos sitios, Los Angeles y San Francisco, y suponga que es un sistema bancario donde los datos de las cuentas de Los Angeles son conservados en Los Angeles y los datos de las cuentas de San Francisco son conservados en San Francisco. Las ventajas son claramente obvias: el arreglo distribuido combina la eficiencia de procesamiento (los datos se mantienen cerca del punto en donde se usan más frecuentemente) con una mayor accesibilidad (e

Introducción a los Sistemas de Bases de Datos PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue