Universidad Continental. Meza.

Seguridad en Bases de Datos

SEGURIDAD EN BASE DE DATOS

Meza Chvez, Miguel U2011113504@contiental.edu.pe Universidad Continental
Para facilitar la administracin los SGBD suelen incorporar el concepto de perfil, rol o grupo de usuarios que agrupa una serie de privilegios por lo que el usuario que se asigna a un grupo hereda todos los privilegios del grupo. El mecanismo de control de acceso se encarga de denegar o conceder el acceso a los usuarios.

RESUMEN: En la actualidad, gran cantidad de informacin

esta almacena en bases de datos por lo se convierten en puntos importantes dentro de las empresas. Por consiguiente es un punto que se debe proteger de personas ajenas que quieran manipular esta informacin y malversarla, por ese motivo surge la necesidad de tener un grado de seguridad para proteger esta informacin.

2.1.1

Tipos de Autorizacin

INTRODUCCIN

La gran mayora de los datos sensibles del mundo estn almacenados en sistemas gestores de bases de datos comerciales tales como Oracle, Microsoft SQL Server entre otros, y atacar una bases de datos es uno de los objetivos favoritos para los criminales. Esto puede explicar por qu los ataques externos, tales como inyeccin de SQL, subieron 345% en 2009.Esta tendencia es prueba adicional de que los agresores tienen xito en hospedar pginas Web maliciosas, y de que las vulnerabilidades y explotacin en relacin a los navegadores Web estn conformando un beneficio importante para ellos. Para empeorar las cosas, segn un estudio publicado en febrero de 2009 The Independent Oracle Users Group (IOUG), casi la mitad de todos los usuarios de Oracle tienen al menos dos parches sin aplicar en sus manejadores de bases de datos. Mientras que la atencin generalmente se ha centrado en asegurar los permetros de las redes por medio de, firewalls, IDS / IPS y antivirus, cada vez ms las organizaciones se estn enfocando en la seguridad de las bases de datos con datos crticos, protegindolos de intrusiones y cambios no autorizados.

Autorizacin explcita vs. implcita. La primera consiste en almacenar qu sujetos pueden acceder a ciertos objetos con determinados privilegios. La segunda consiste en que una autorizacin definida sobre un objeto puede deducirse a partir de otras. Autorizacin fuerte vs. dbil. En la fuerte no se pueden invalidar las autorizaciones implcitas mientras que en la dbil se permiten excepciones sobre ellas. Autorizacin positiva vs. negativa. La primera indica la existencia de autorizacin y la segunda indica la denegacin de una autorizacin. El tipo de autorizacin depender

2.2

DISPONIBILIDAD

Los SGBD deben asegurar la disponibilidad de los datos a aquellos usuarios que tienen derecho a ello, por lo que proporcionan mecanismos que permiten recuperar la base de datos contra fallos lgicos o fsicos, que destruyan los datos en todo o en parte. Sera conveniente adems, contar con facilidades ajenas al SGBD como, por ejemplo, mquinas tolerantes a fallos, sistemas de alimentacin ininterrumpida. El principio bsico es la redundancia fsica. Los principales tipos de fallos son de memoria voltil y de memoria secundaria.

2.2.1

TRANSACCIONES

CARACTERISTICAS DE LA SEGURIDAD
CONFIDENCIALIDAD

2.1

Hay que asegurar la consistencia tras los cambios en la BD. Para esto se crean transacciones. La base de datos se encuentra en un estado consistente antes de que se empiece a ejecutar una transaccin y tambin lo deber estar cuando la transaccin termine. Las propiedades principales que debe poseer una transaccin son la atomicidad, preservacin de la consistencia, aislamiento (no muestra los cambios hasta que finaliza) y persistencia. Una transaccin puede terminar con xito, en cuyo caso se graban las actualizaciones que produce (commit) o con fracaso, debiendo ser restaurado el estado inicial, deshaciendo las actualizaciones (rollback).

Prevenir, detectar o impedir el descubrimiento de informacin Primero el sistema debe identificar y autenticar a los usuarios. Adems, el administrador deber especificar los privilegios que un usuario tiene sobre los objetos: utilizar una BD, consultar ciertos datos, actualizar datos, etc.

2.2.2

LOG

Para conseguir anular y recuperar transacciones, el mtodo ms extendido suele ser la utilizacin de un fichero denominado diario (log) en el que se va guardando toda la informacin necesaria para deshacer o rehacer las transacciones. Normalmente se obliga a que los registros que se modifican se escriban antes en el fichero diario que en la base de datos,

Universidad Continental. Meza. Seguridad en Bases de Datos

para poder anular as, en caso de necesidad, las transacciones (log write-ahead protocol"), y evitar problemas. El fichero diario puede ser un fichero circular, o constar de dos partes; una en disco, que cuando se llena se pasa a cinta u otro almacenamiento.

puede realizar y las que no puede realizar sobre cada objeto del sistema. Permite conceder privilegios de acceso sobre otros usuarios de forma discrecional. Se soportan en matrices de acceso que almacenan toda la informacin

2.2.3

CHECKPOINT

Para evitar tener que recorrer todo el fichero diario, se introduce el punto de verificacin o recuperacin (checkpoint), que se ejecuta peridicamente y que implica: Pasar el contenido de las memorias de rea intermedia al fichero diario. Escribir un registro de punto de recuperacin en el fichero diario Pasar el contenido de las memorias de rea intermedia de la base de datos a soporte secundario Escribir la direccin del registro de recuperacin en un fichero de re arranque.

Figura 1: Matriz de Acceso

2.2.4

RECUPERACION
Recuperacin en caliente. Al ocurrir un fallo que d lugar a prdida de memoria voltil, es preciso realizar la operacin de recuperacin en caliente, en la que el sistema consulta el fichero diario para determinar las transacciones que hay que deshacer y rehacer. Recuperacin en fro. En caso de un fallo de memoria secundaria que afecte a la base de datos, se lleva a cabo una recuperacin en fro, que consiste en utilizar una copia de seguridad de la BD (backup). La copia de seguridad permitir, junto con los ficheros diarios que se han ido produciendo desde que se realiz, reconstruir la BD llevndola de forma consistente a la situacin anterior a que se produjera el fallo.

3.2

OBLIGATORIO

2.3

INTEGRIDAD

El objetivo es proteger la base de datos contra operaciones que introduzcan inconsistencias en los datos. Integridad semntica: Existen operaciones que pueden violar restricciones definidas al disear la base de datos, como pueden ser restricciones sobre los dominios o sobre los atributos. Estas reglas de integridad se almacenan en el diccionario. El subsistema de integridad del SGBD debe comprobar la coherencia de las reglas que se definen, controlar las distintas transacciones y detectar las violaciones de integridad, y en el caso de producirse, ejecutar las acciones pertinentes. Integridad operacional: En sistemas multiusuario es imprescindible un mecanismo de control de concurrencia para conservar la integridad de la base de datos. Las ms importantes podran ser: operacin perdida, salidas inconsistentes, inconsistencias en la base de datos y lectura no reproducible.

Consiste en la clasificacin de tanto los sujetos como los objetos en el sistema en clases de acceso que determinan sus caractersticas de confidencialidad. Una clase de acceso es un elemento de un conjunto de clases parcialmente ordenadas. Las clases de acceso se definen como un conjunto formado por dos componentes, un nivel de seguridad y un conjunto de categoras. Cada nivel de seguridad es un elemento de un conjunto jerrquicamente ordenado como alto secreto (TS), secreto (S), confidencial (C) y sin clasificar (U), donde TS > S > C > U . El conjunto de categoras es un subconjunto de un conjunto desordenado, donde los elementos pueden reflejar reas funcionales o diferentes competencias como por ejemplo finanzas, administracin, ventas y compras para sistemas comerciales. El orden parcial es definido por una relacin de dominio que se denota con . La relacin de dominio es definida de la siguiente forma: una clase de acceso C1 domina () a otra clase de acceso C2 si y slo si el nivel de seguridad de C1 es mayor o igual que el de C2 y las categoras de C1 incluyen las de C2.

Figura 2: Modelo Obligatorio

3
3.1

POLITICAS DE CONTROL DE ACCESO

DISCRECIONAL

3.3

BASADO EN ROLES

Acceso basado en la identidad de los sujetos y en reglas de autorizacin que indican para cada sujeto, las acciones que

Esta poltica regula el control de acceso de usuarios a La informacin, en base a las actividades y responsabilidades organizacionales que los usuarios tienen en el sistema Se asocian permisos con Roles

Universidad Continental. Meza. Seguridad en Bases de Datos

Los usuarios se hacen miembros de esos roles obteniendo as permisos Cada rol representa un grupo funcional con responsabilidades similares Permite de manera sencilla cambios organizacionales

Esta poltica ofrece ciertas ventajas: Gestin de autorizaciones: Hay una independencia lgica entre la actividad de asignar roles a usuarios y asignar privilegios de acceso a los roles. Esto facilita mucho la gestin. Jerarqua de roles: En muchas aplicaciones hay una jerarqua natural de roles, basadas en los principio bien conocidos de generalizacin y especializacin. Esto puede dar lugar a autorizaciones implcitas como por ejemplo: El secretario o secretaria hereda todos los permisos del personal de administracin. Privilegios mnimos: Los roles permiten que un usuario tenga los privilegios estrictamente necesarios para realizar una tarea particular. Esto minimiza los peligros de dao debido a un exceso de privilegios. Separacin de responsabilidades: Se refiere al principio de que ningn usuario debera tener suficientes privilegios para darle un uso inadecuado al sistema en su propio beneficio. Por ejemplo, la persona autorizada a pagar un cheque no debe ser la misma que la persona que lo prepara. Esto se puede hacer cumplir distinguiendo roles usuarios entre roles conflictivos. Cumplimiento de restricciones: Los roles dan una base para la especificacin de requisitos de proteccin que pueden ser necesarias en las situaciones reales. Ejemplo: nmero mximo de usuarios en un rol, etc.

http://es.scribd.com/doc/14870070/Seguridad-en-Base-deDatos http://msdn.microsoft.com/eses/library/cc434708(v=vs.71).aspx http://www.ticbeat.com/tecnologias/10-grandesamenazas-seguridad-bases-datos/ http://revista.seguridad.unam.mx/numero-12/principiosb%C3%A1sicos-de-seguridad-en-bases-de-datos http://www.bspanama.com/2.0/index.php?option=com_con tent&view=article&id=47&Itemid=128 http://www.ing.ula.ve/~ibc/seguridadBDibc.pdf

Figura 3: Modelo basado en roles

CONCLUCIONES

Por lo visto en el presente trabajo podemos observar que las bases de datos tienen que cumplir con ciertos requisitos como la confidencialidad, disponibilidad e integridad para poder tener un grado de seguridad, adems que el tipo de poltica que cada base de datos use determinara tambin que tan seguro es esta. Dependiendo a la afinidad que podemos tener podemos usar una poltica discrecional, obligatoria o basada en roles.

BIBLIOGRAFIA
http://www.itescam.edu.mx/principal/sylabus/fpdb/recursos /r1335.PDF