Manual Base de Datos

UNIDAD I RECUPERACION 1.1 Concepto 1.2 Transacciones 1.3 Fallas De Transacción 1.4 Fallas Del Sistema 1.5 Fallas En El M

Views 224 Downloads 26 File size 205KB

Report DMCA / Copyright

DOWNLOAD FILE

Recommend stories

Citation preview

UNIDAD I RECUPERACION 1.1 Concepto 1.2 Transacciones 1.3 Fallas De Transacción 1.4 Fallas Del Sistema 1.5 Fallas En El Medio UNIDAD II INTEGRIDAD 2.1 Definición 2.2 Reglas De Integridad 2.3 Reglas De Integridad De Dominio 2.4 Reglas De Integridad De Relacion 2.5 Mecanismos De Vistas Para La Implantación De Integridad UNIDAD III CONCURRENCIA 3.1 Definición 3.2 Problemas Que Se Presentan 3.3 Seriabilidad 3.4 Mecanismos De Seguros 3.4.1 Tipos De Seguros 3.4.2 Protocolos 3.4.3 Deadlock 3.4.3a Técnicas Para Prevenirlo 3.4.3b Técnicas Para Deshacerlo 3.5 Etiquetas De Tiempo

UNIDAD IV SEGURIDAD 4.1 Concepto 4.2 Identificación Y Autentificación 4.3 Matriz De Autorización 4.4 Definición De Un Esquema De Seguridad 4.5 Mecanismos De Vistas Para Implantación De Seguridad 4.6 Base De Datos Estadísticas 4.7 Encripción De Datos

RECUPERACIÓN 1.1 CONCEPTO El objetivo del concepto de recuperación es el de proteger la BD contra fallas lógicas y físicas que destruyan los datos en todo o en parte. Independiente de la naturaleza de las fallas estás pueden afectar a dos aspectos del almacenamiento de la Base de Datos, como son:

* Fallas que provocan la pérdida de memoria volátil * Fallas que provocan la pérdida del contenido de memoria secundaria.

1.2 TRANSACCIONES Para asegurar que la BD siempre este en un estado consistente, se crean unidades de ejecución llamadas transacciones, que pueden definirse como una secuencia de operaciones que han de ejecutarse en forma atómica, es decir, se realizan todas las operaciones que comprende la transacción o no se realiza ninguna. Ej: una transacción bancaria que saca dinero de una cuenta y lo dispone en otra. Las transacciones o terminan con éxito y son grabadas en la base o bien fracasan y debe ser restaurado el estado anterior de la BD. El componente del sistema encargado de lograr la atomicidad se conoce como administrador de transacciones y las operaciones COMMIT (comprometer) y ROLLBACK (retroceder) son la clave de su funcionamiento. La operación COMMIT señala el término exitoso de la transacción: le dice al administrador de transacciones que se ha finalizado con éxito una unidad lógica de trabajo, que la base de datos está o debería estar de nuevo en un estado consistente y que se pueden comprometer, o hacer permanentes todas las modificaciones efectuadas por ese unidad de trabajo. La operación ROLLBACK, en cambio, señala el término no exitoso de la transacción: le dice al administrador de transacciones que algo salió mal, que la base de datos podría estar en un estado inconsistente y que todas las modificaciones efectuadas hasta el momento por la unidad lógica de trabajo deben retroceder o anularse. Las características de una transacción son: * Atomicidad, en el sentido que hemos especificado anteriormente: se ejecutan todas las sentencias o ninguna. * Preservación de la consistencia: la ejecución de una transacción deja la BD en un estado consistente. * Aislamiento, ya que una transacción no muestra los cambios que produce hasta que finaliza. * Persistencia, ya que una vez que finaliza la transacción con éxito, sus efectos perduran en la BD.

* Seriabilidad, en el sentido de que el efecto de ejecutar transacciones concurrentemente debe ser el mismo que se produciría al ejecutarlas por separado en un orden secuencial según van entrando en el sistema. Para conseguir anular y recuperar transacciones, el método mas usado consiste en utilizar un archivo de diario o log en el que va guardando toda la información necesaria para deshacer (en caso de fracasar) o rehacer (en caso de recuperar) las transacciones. Este archivo consta de: *

Identificador de la transacción

*

Hora de modificación

*

Identificador del registro afectado

*

Tipo de acción

*

Valor anterior del registro

*

Nuevo valor del registro

*

Información adicional.

Otra alternativa es manejar 2 archivos de log, uno con la imagen anterior a las modificaciones y otro con la imagen posterior a las modificaciones. El archivo log es usualmente una pila que una vez llena va eliminado registros según van entrando nuevos. Un concepto relacionado con los archivos de log es el CHECKPOINT, que permite manejar en forma eficiente el contenido de los archivos log, ya que permiten no tener que recorrer todo el archivo de log, ante fallas. El establecimiento de puntos de revisión implica: * grabar físicamente el contenido de los buffers de datos a la base de datos física * grabar físicamente un registro de punto de revisión especial dentro del archivo de log o bitácora Los puntos marcados como checkpoint, permiten la recuperación de la base de datos en caliente, es decir, después de la caída del sistema se obtiene la dirección del registro de recuperación más reciente y se recorre el archivo de log desde el punto marcado como checkpoint.

La transacción t1 no se ve afectada por la falla del sistema, ni por el proceso de recuperación, por haberse completado antes del último punto de recuperación. Las transacciones t2 y t4, a pesar de haber terminado no han sido grabadas en la base de datos, ya que éstas serían cometidas en un checkpoint. Las transacciones t3 y t5 deberán rehacerse ya que no han concluido. El procedimiento que deberá realizar el sistema al reiniciarse consiste en: 1. Comenzar con dos listas de transacciones, la lista ANULAR y la lista REPETIR. igualar la lista ANULAR a la lista de todas las transacciones incluidas en el registro de punto de revisión. Dejar vacía la lista REPETIR. 2. Examinar la bitácora hacia adelante a partir del registro de punto de revisión. 3. Si se encuentra una entrada de bitácora de "iniciar transacción" para la transacción T, añadir T a la lista ANULAR. 4. Si se encuentra una entrada una entrada de bitácora "comprometer" para la transacción T, pasar esa transacción de la lista ANULAR a la lista REPETIR. 5. Cuando se llegue al final de la bitácora, las listas ANULAR y REPETIR identificarán, respectivamente, las transacciones de los tipos T3 y T5 y las de los tipos T2 y T4. Posteriormente el sistema revisará la bitácora hacia atrás, anulando todas las transacciones de la lista ANULAR. A continuación la revisará hacia adelante, realizando de nuevo todas las transacciones en la lista REPETIR. Por ultimo, una vez terminada todas las actividades de recuperación, el sistema estará listo para aceptar nuevos trabajos. La recuperación en frío, consiste en disponer de un backup o respaldo de la BD, que permitirá junto con los archivos de log, que se han ido produciendo desde el ultimo backup, reconstruir la BD, para dejarla consistente.

1.3 FALLAS DE TRANSACCIÓN Cuando un usuario esta ingresando datos a una computadora donde se han realizado varias transacciones y falla el sistema, una vez que este se recupera, su estado corre el riesgo del duplicado de transacciones. Una transacción puede fallar por varias causas. Puede ser que los datos de entrada no son correctos o no coinciden con la BD, también puede ser debido a faltas de recursos. Existen 2 tipos de fases en la transacción: 1.- Adquiere todos los recursos necesarios para su ejecución. 2.- Todos los cambios restantes se colocan en la base de datos y pueden llegar a liberarse los recursos detenidos por la transacción. Al entrar a la segunda fase la transacción debe concluirse. Errores de una transacción: 1.- Aborto de una transacción. 2.- Nuevo inicio de una transacción. 3.- Eliminación de una transacción.

1.4 FALLAS DEL SISTEMA (Ejemplo: falla en el suministro eléctrico) que afectan a todas las transacciones que estén actualmente en progreso, pero no dañan físicamente a la BD.

El puerto principal con relación a la falla del sistema es que “se pierde el contenido de la memoria principal”. Ya no es posible conocer el estado preciso de cualquier transacción que esta en progreso al momento de la falla y por lo tanto, tal transacción nunca podrá terminar satisfactoriamente y deberá ser deshecha cuando el sistema vuelva a iniciar.

Tal vez sea necesario al momento del reinicio volver a realizar determinadas transacciones que se completaran satisfactoriamente antes de la falla pero que no pudieran lograr que su actualización fueran transferidas desde los bufers de la BD hacia la BD física. 1.5 FALLAS EN EL MEDIO

(Ejemplo: roce de las cabezas en un disco) que causan daño a la BD o alguna parte de ella, y afectan al menos a las transacciones que estén usando actualmente en esa parte. INTEGRIDAD

2.1 DEFINICION

La integridad tiene como función proteger la BD contra operaciones que introduzcan inconsistencias en los datos. Se habla de integridad en el sentido de corrección, validez o precisión de los datos.

El subsistema de integridad de un SGBD debe por tanto detectar y corregir, en la medida de lo posible, las operaciones incorrectas. En la práctica es el punto débil de los SGBD comerciales, ya que casi toda la verificación de integridad se realiza mediante código de procedimientos escritos por los usuarios.

Habrá operaciones cuya falta de corrección no sea detectable, por ejemplo, introducir un fecha de nacimiento 25/12/1945 cuando en realidad era 25/12/1954.

2.2 REGLAS DE INTEGRIDAD

Se definen dos reglas de integridad: Integridad de dominio. Ningún componente de la llave primaria de una relación puede aceptar valores nulos. Integridad referencial. La base de datos no debe contener valores de llaves ajenas sin concordancia. 2.3 REGLAS DE INTEGRIDAD DE DOMINIO

En un momento dado, los valores de los datos en una base de datos son una representación de un fragmento de la realidad. Es decir, si tenemos una tabla con los atributos de personas y entre ellos el peso o la edad, estos no pueden ser negativos, porque en el mundo real, esto no es posible. Si añadimos una restricción de este tipo a una base de datos, estamos incluyéndole una regla de integridad. Por ejemplo, si tenemos una base de datos alumnos, profesores y cursos para una escuela o facultad, algunas reglas de integridad serían: * Las claves de los alumnos son de la forma ALaaaannnn donde aaaa son los cuatro dígitos del año de ingreso y nnnn son cuatro dígitos que representan un número secuencial. * Las claves de los profesores son de la forma ACmmnn donde mm es la clave del departamento al que está asociado y nn es un secuencial. * Las claves de cursos son de la forma MAmmnnaa donde mm es la clave del departamento, nn es la clave de la materia y aa son los dos dígitos menos significativos del año. * Un alumno no puede estar inscrito en más de cinco materias. * Un maestro no puede dar más de tres materias. * Un curso no puede tener menos de cinco alumnos ni más de doce.

* Un maestro no puede dar la misma materia más de dos semestres seguidos. * Un alumno que no aprueba una materia en la segunda oportunidad será dado de baja. * Los departamentos vienen de una determinada lista. * Las materias tienen que existir en otra lista. * Las calificaciones no pueden tomar valores fuera del rango 81#81. Algunas de estas reglas son arbitrarias y para fines de ejemplificar el concepto y es inmediato notar que se aplican a tablas en específico. Sin embargo, las bases de datos relacionales, tienen dos reglas generales de integridad que se aplican a las llaves primarias y a las llaves foráneas. Llaves primarias Definamos primero el concepto de llave candidata. Digamos que el atributo 76#76 de la relación 17#17 es llave candidata si cumple: Unicidad. En cualquier momento no existen dos tuplas en 1#1 con el mismo valor 76#76. Minimalidad. Si 76#76 es una llave compuesta, al eliminar cualquiera de sus componentes perdemos la cualidad de unicidad. Por supuesto, la combinación de todos los atributos es una llave candidata y pueden existir combinaciones de atributos que den llaves candidatas, e incluso con diferentes longitudes. Es decir, podemos tener una llave 82#82 compuesta de tres atributos y otra llave 83#83 de dos atributos. De esta manera, siempre es posible encontrar al menos una llave candidata. De esto deducimos que como toda relación tiene al menos una llave candidata, entonces toda relación tiene una llave primaria. Como deducirla queda fuera de toda metodología no podemos dar una regla general. Habrá ocasiones en que incluso es necesario construir una llave primaria, como un número secuencial o el más conocido RFC. En el caso de Hacienda, es obvio que una llave primaria podría ser la combinación del nombre, domicilio y edad, pero esta sería una llave muy torpe. ¿Han pensado cuántos posibles RFC existen? ¿Cuál es la probabilidad de colisión en esta llave? Es un bonito ejercicio y queda al lector pensar porqué la SHCP se vio en la necesidad de añadir tres caracteres al RFC --los conocidos como homoclave y las posibles maneras de generar dicha homoclave.

Otro ejemplo, para el hipotético Registro Estatal de Automóviles de Cuévano, el número de serie del vehículo en combinación con la marca y el modelo; la marca, el color y nombre del dueño; y la matrícula, son llaves candidatas. Pero de entre estas tres llaves candidatas, nos basta con la matrícula porque cumple perfectamente con las dos condiciones y además no es compuesta, con el consecuente ahorro de espacio y tiempo de cómputo. Las otras dos pasan a ser llaves alternas. La importancia de las llaves primarias se comprenderá mejor con la exposición de las llaves foráneas, pero además las llaves primarias constituyen el mecanismo de direccionamiento a nivel de tuplas en el modelo relacional. Es decir, es el único modo de acceder a una tupla específica. Por ejemplo, la consulta: SELECT * FROM padron_vehicular WHERE placa = 'ABC123' regresa una sola tupla mientras que las consultas SELECT * FROM padron_vehicular WHERE nombre = 'José' AND apepat = 'Hernández' AND apemat = 'García' y SELECT * FROM padron_vehicular WHERE color_vehiculo = 'Rojo'

2.4 REGLAS DE INTEGRIDAD DE RELACION

La segunda regla de integridad se aplica a las claves ajenas: si en una relación hay alguna clave ajena, sus valores deben coincidir con valores de la clave primaria a la que hace referencia, o bien, deben ser completamente nulos. La regla de integridad referencial se enmarca en términos de estados de la base de datos: indica lo que es un estado ilegal, pero no dice cómo puede evitarse. La cuestión es ¿qué hacer si estando en un estado legal, llega una petición para realizar una operación que conduce a un estado ilegal? Existen dos opciones: rechazar la operación, o bien aceptar la operación y realizar operaciones adicionales compensatorias que conduzcan a un estado legal.

Por lo tanto, para cada clave ajena de la base de datos habrá que contestar a tres preguntas: * Regla de los nulos: ¿Tiene sentido que la clave ajena acepte nulos? * Regla de borrado: ¿Qué ocurre si se intenta borrar la tupla referenciada por la clave ajena? * Restringir: no se permite borrar la tupla referenciada. * Propagar: se borra la tupla referenciada y se propaga el borrado a las tuplas que la referencian mediante la clave ajena. * Anular: se borra la tupla referenciada y las tuplas que la referenciaban ponen a nulo la clave ajena (sólo si acepta nulos). * Regla de modificación: ¿Qué ocurre si se intenta modificar el valor de la clave primaria de la tupla referenciada por la clave ajena? * Restringir: no se permite modificar el valor de la clave primaria de la tupla referenciada. * Propagar: se modifica el valor de la clave primaria de la tupla referenciada y se propaga la modificación a las tuplas que la referencian mediante la clave ajena. * Anular: se modifica la tupla referenciada y las tuplas que la referenciaban ponen a nulo la clave ajena (sólo si acepta nulos).

2.5 MECANISMOS DE VISTAS PARA LA IMPLANTACIÓN DE INTEGRIDAD

En la arquitectura de tres niveles estudiada se describe una vista externa como la estructura de la base de datos tal y como la ve un usuario en particular. En el modelo relacional, el término “vista” tiene un significado un tanto diferente. En lugar de ser todo el esquema externo de un usuario, una vista es una relación virtual, una relación que en realidad no existe como tal. Una vista se puede construir realizando operaciones como las del álgebra relacional: restricciones, proyecciones, concatenaciones, etc. a partir de las relaciones base de la base de datos. Las relaciones base son aquellas que forman parte directa de la base de datos, las que se encuentran almacenadas físicamente. Un esquema externo puede tener tanto relaciones base como vistas derivadas de las relaciones base de la base de datos.

Una vista es el resultado dinámico de una o varias operaciones relacionales realizadas sobre las relaciones base. Una vista es una relación virtual que se produce cuando un usuario la consulta. Al usuario le parece que la vista es una relación que existe y la puede manipular como si se tratara de una relación base, pero la vista no está almacenada físicamente. El contenido de una vista está definido como una consulta sobre una o varias relaciones base. Cualquier operación que se realice sobre la vista se traduce automáticamente a operaciones sobre las relaciones de las que se deriva. Las vistas son dinámicas porque los cambios que se realizan sobre las tablas base que afectan a una vista se reflejan inmediatamente sobre ella. Cuando un usuario realiza un cambio sobre la vista (no todo tipo de cambios están permitidos), este cambio se realiza sobre las relaciones de las que se deriva. Las vistas son útiles por varias razones: * Proporcionan un poderoso mecanismo de seguridad, ocultando partes de la base de datos a ciertos usuarios. El usuario no sabrá que existen aquellos atributos que se han omitido al definir una vista. * Permiten que los usuarios accedan a los datos en el formato que ellos desean o necesitan, de modo que los mismos datos pueden ser vistos con formatos distintos por distintos usuarios. * Se pueden simplificar operaciones sobre las relaciones base que son complejas. Por ejemplo, se puede definir una vista como la concatenación de dos relaciones. El usuario puede hacer restricciones y proyecciones sobre la vista, que el SGBD traducirá en las operaciones equivalentes sobre la concatenación. Se puede utilizar una vista para ofrecer un esquema externo a un usuario de modo que éste lo encuentre “familiar”. Por ejemplo: * Un usuario puede necesitar los datos de los directores junto con los de las oficinas. Esta vista se crea haciendo una concatenación de las relaciones PLANTILLA y OFICINA, y proyectando sobre los atributos que se desee mantener. * Otro usuario puede que necesite ver los datos de los empleados sin ver el salario. Para este usuario se realiza una proyección para crear una vista sin el atributo salario. * Los atributos se pueden renombrar, de modo que cada usuario los vea del modo en que esté acostumbrado. También se puede cambiar el orden en que se visualizan las columnas.

* Un miembro de la plantilla puede querer ver sólo los datos de aquellos inmuebles que tiene asignados. En este caso, se debe hacer una restricción para que sólo se vea el subconjunto horizontal deseado de la relación INMUEBLE. Como se ve, las vistas proporcionan independencia de datos a nivel lógico, que también se da cuando se reorganiza el nivel conceptual. Si se añade un atributo a una relación, los usuarios no se percatan de su existencia si sus vistas no lo incluyen. Si una relación existente se reorganiza o se divide en varias relaciones, se pueden crear vistas para que los usuarios la sigan viendo como al principio. Cuando se actualiza una relación base, el cambio se refleja automáticamente en todas las vistas que la referencian. Del mismo modo, si se actualiza una vista, las relaciones base de las que se deriva deberían reflejar el cambio. Sin embargo, hay algunas restricciones respecto a los tipos de modificaciones que se pueden realizar sobre las vistas. A continuación, se resumen las condiciones bajo las cuales la mayoría de los sistemas determinan si se permite realizar una actualización: * Se permiten las actualizaciones de vistas que se definen mediante una consulta simple sobre una sola relación base y que contienen la clave primaria de la relación base. * No se permiten las actualizaciones de vistas que se definen sobre varias relaciones base. * No se permiten las actualizaciones de vistas definidas con operaciones de agrupamiento ( GROUPBY).

CONCURRENCIA

3.1 DEFINICION

La concurrencia es un fenómeno que se presenta en varios contextos. Uno de ellos es la multiprogramación ya que el tiempo del procesador es compartido dinámicamente por varios procesos. Otro caso son las aplicaciones

estructuradas, donde la programación estructurada se implementa como un conjunto de procesos concurrentes. Y por último se tiene que la misma estructuración recién mencionada es utilizada en el diseño de los sistemas operativos, los cuales se implementan como un conjunto de procesos.

3.2 PROBLEMAS QUE SE PRESENTAN

1) Modificación perdida:

En T1 (Tiempo 1), arranca TA (Transacción A), leen dato “X” En T2 (Tiempo 2), arranca TB (Transacción B), leen dato “X” à datos = 100 En T3 (Tiempo 3), modifica TA (Transacción A), dato “X” (aumenta el 100%) à datos = 200 En T4 (Tiempo 4), modifica TB, dato “X” (en base a lo que leyó en T2) (aumenta el 50%) à 150 datos final.

2)Dependencia no COMMITADA

Permitir leer un dato sin esperar que una transacción que la estaba modificando haga su commit.

3) Análisis consistente:

TA (Transacción A): suma saldos

TB (Transacción B): transfiere $10 de cuenta 1 a cuenta3

CUENTA 1 50 CUENTA 2 40 CUENTA 3 30

TA CUENTA 1

= $50

T1 SALDO

= $50

__________________________________ TA CUENTA 2

= $40

T2 SALDO 2

= $90

__________________________________ TB CUENTA 1 T3

= $50

CUENTA 1

CUENTA 1

= $50 - $10

= $40

__________________________________ TB CUENTA 3 T4

= $30 + $10

CUENTA 3

= $40

___________________________________ TA CUENTA 3

= $40

T5 SALDO = $130 (EN REALIDAD ES $ 120) Para eliminar o disminuir estos 3 problemas se utilizan protocolos:

a) Bloqueos 1)

S à compartido (para lecturas)

2)

X à exclusivo, este puede ser por páginas/ tabla/ registros

TB/ TA NO BLOQUEO S X NO BLOQUEO ACCEDE A OBJETO ACCEDE A OBJETO NO ACCEDE S ACCEDE A OBJETO ACCEDE A OBJETO NO ACCEDE X NO ACCEDE NO ACCEDE NO ACCEDE Problemas con los bloqueos exclusivos: puede haber un bloqueo mortal o deadlock.

3.3 SERIABILIDAD · Es la propiedad que garantiza que un plan de ejecución concurrente es equivalente al secuencial. · Formas de planificar la seriabilidad: 1. por conflicto 2. por visión · Por simplicidad solo se consideran las operaciones de lectura y escritura. No se consideran las operaciones de cálculo sobre los datos obtenidos. Seriabilidad por conflicto · Eliminar conflictos entre dos o mas transacciones · Operaciones sobre los mismos datos en mas de una transacción. · Tipos de operaciones: * T1: lectura y T2: lectura * No hay conflicto * T1: lectura y T2: escritura ó T1: escritura y T2: lectura * Conflicto: hay que respetar el orden

* T1: escritura y T2: escritura * Conflicto: el orden afecta al valor final de la BD · Se dice que hay conflicto cuando se consideran operaciones sobre los mismos datos en dos transacciones diferentes · Un plan de ejecución se puede transformar en otro cambiando de orden las instrucciones y manteniendo la seriabilidad · Todos estos planes son equivalentes al plan secuencial. Seriabilidad por visión · Se basa en definir una regla de equivalencia menos estricta que la de conflicto. · Pero basándose solo en las operaciones de lectura y escritura. · Se puede considerar como un refinamiento de la equivalencia por conflicto. Pruebas de seriabilidad · Hacer la prueba de seriabilidad después de ejecutar el plan es un poco tarde. · El objetivo es desarrollar un protocolo de control de concurrencia que asegure la seriabilidad. · No suele analizar el grafo de precedencia. · Lo habitual es imponer restricciones que aseguren la seriabilidad del plan. · Las pruebas sirven para ayudar a comprender los protocolos de control de concurrencia. Teoría de la seriabilidad Una calendarización (schedule), también llamado una historia, se define sobre un conjunto de transacciones T = { T1, T2, ..., Tn } y especifica un orden entrelazado de la ejecución de las operaciones de las transacciones. La calendarización puede ser especificada como un orden parcial sobre T. Ejemplo 6.1. Considere las siguientes tres transacciones: T1: Read(x) T2: Write(x) T3: Read(x) Write(x) Write(y) Read(y) Commit Read (z)

Read (z) Commit Commit Una calendarización de las acciones de las tres transacciones anteriores puede ser: H1 = {W2(x), R1(x), R3(x), W1(x), C1, W2 (y), R3 (y), R2 (z), C2, R3 (z), C3} ¨ Dos operaciones Oij(x) y Okl(x) (i y k no necesariamente distintos) que accesan el mismo dato de la base de datos x se dice que están en conflicto si al menos una de ellas es una escritura. De esta manera, las operaciones de lectura no tienen conflictos consigo mismas. Por tanto, existen dos tipos de conflictos read-write (o write-read) y write-write. Las dos operaciones en conflicto pueden pertenecer a la misma transacción o a transacciones diferentes. En el último caso, se dice que las transacciones tienen conflicto. De manera intuitiva, la existencia de un conflicto entre dos operaciones indica que su orden de ejecución es importante. El orden de dos operaciones de lectura es insignificante. Una calendarización completa define el orden de ejecución de todas las operaciones en su dominio. Formalmente, una calendarización completa STc definido sobre un conjunto de transacciones T = { T1, T2, ..., Tn } es un orden parcial STc = { S T, T3-->T1 lo cual es un deadlock.

3.4.3 a TÉCNICAS PARA PREVENIRLO. Los métodos de corregir un deadlock una vez que ya se presentó éste conllevan la pérdida de tiempo y no de información, ya que las transacciones puedes abortarse de manera segura debido a las facilidades de las bitácoras, el protocolo de bloqueo de dos fases y el protocolo commit de dos fases. El método de prevención del deadlock también hace necesario abortar transacciones y siempre serán las transacciones más nuevas o jóvenes las abortadas para evitar los deadlocks. Existen dos métodos: el método apropiativo y el no apropiativo. Ambos se basan en la hora en que las transacciones son creadas, podemos hablar entonces de transacciones viejas y jóvenes. En el método no apropiativo, si una transacción Ta pide un recurso bloqueado por Tb, se permite que Ta espere solamente si Ta es más vieja que Tb. Ta es reinicializada si es más joven que Tb, conservando siempre su

antigüedad. Lo que se consigue con el método no apropiativo es que ninguna transacción joven esperará por las transacciones viejas, eliminando la condición de espera circular distribuida. En el método apropiativo la regla es la inversa: Si Ta pide un bloqueo sobre un recurso cuyo dueño es Tb, se le permite esperar si Ta es más joven que Tb. Si Ta es más vieja, no espera sino que Tb es abortada por ser más joven y luego se reinicializa conservando su antigüedad. También podemos anular alguna de las 4 condiciones necesarias para que se produzca un deadlock: No puede ser anulada porque existen recursos que deben ser usados en modalidad exclusiva. La alternativa sería hacer que todos los procesos solicitaran todos los recursos que habrán de utilizar antes de utilizarlos al momento de su ejecución lo cual sería muy ineficiente. Para anular esta condición cuando un proceso solicita un recurso y este es negado el proceso deberá liberar sus recursos y solicitarlos nuevamente con los recursos adicionales. El problema es que hay recursos que no pueden ser interrumpidos. Espera Circular: esta estrategia consiste en que el sistema operativo numere en forma exclusiva los recursos y obligue a los procesos a solicitar recursos en forma ascendente. El problema de esto es que quita posibilidades a la aplicación. 3.4.3 b TÉCNICAS PARA DESHACERLO.

Si se tiene cuidado en la forma de asignar los recursos se pueden evitar situaciones de Deadlock. Supongamos un ambiente en el que todos los procesos declaren a priori la cantidad máxima de recursos que habrá de usar. Estado Seguro: un estado es seguro si se pueden asignar recursos a cada proceso (hasta su máximo) en algún orden sin que se genere Deadlock. El estado es seguro si existe un ordenamiento de un conjunto de procesos {P1...Pn} tal que para cada Pi los recursos que Pi podrá utilizar pueden ser

otorgados por los recursos disponibles mas los recursos utilizados por los Procesos Pj,j TMVE entonces OPL(X) se ejecuta solamente si no existe ninguna OPE(X) registrada cuyo timestamp

sea más viejo que TS. Si ocurre que TS(OPE) es ms vieja que TS, entonces la operación es registrada pero no ejecutada. Cuando las operaciones de escritura OPE(X) sean ejecutadas, inmediatamente se liberan las operaciones de lectura pendientes, logrando así su serialización. 6. Sea TS el timestamp de una operación de escritura OE(X) sobre el dato X. Si existe una pre-operación de escritura OPE(X), entonces OE(X) se almacena. Cuando las pre-operaciones de escritura OPE(X) sean ejecutadas, después se ejecutan las OE(X). SEGURIDAD 4.1 Concepto El problema de la seguridad consiste en lograr que los recursos de un sistema sean, bajo toda circunstancia, utilizados para los fines previstos. Para eso se utilizan mecanismos de protección. Los sistemas operativos proveen algunos mecanismos de protección para poder implementar políticas de seguridad. Las políticas definen qué hay que hacer (qué datos y recursos deben protegerse de quién; es un problema de administración), y los mecanismos determinan cómo hay que hacerlo. Esta separación es importante en términos de flexibilidad, puesto que las políticas pueden variar en el tiempo y de una organización a otra. Los mismos mecanismos, si son flexibles, pueden usarse para implementar distintas políticas. Un aspecto importante de la seguridad es el de impedir la pérdida de información, la cual puede producirse por diversas causas: fenómenos naturales, guerras, errores de hardware o de software, o errores humanos. La solución es una sola: mantener la información respaldada, de preferencia en un lugar lejano. Otro aspecto importante de la seguridad, es el que tiene que ver con el uso no autorizado de los recursos: * Lectura de datos. * Modificación de datos. * Destrucción de datos. * Uso de recursos: ciclos de CPU, impresora, almacenamiento.

Principios básicos para la seguridad * Suponer que el diseño del sistema es público. * El defecto debe ser: sin acceso. * Chequear permanentemente. * Los mecanismos de protección deben ser simples, uniformes y construidos en las capas más básicas del sistema. * Los mecanismos deben ser aceptados sicológicamente por los usuarios.

Seguridad: Fallos lógicos o físicos que destruyan los datos.

MEDIDAS DE SEGURIDAD: Físicas: Controlar el acceso al equipo. Tarjetas de acceso, etc. Personal: Acceso sólo del personal autorizado. Evitar sobornos, etc. SO: Seguridad a nivel de SO SGBD: Uso herramientas de seguridad que proporcione el SGBD. Perfiles de usuario, vistas, restricciones de uso de vistas, etc.

SEGURIDAD - Evitar pérdidas de datos por fallos hardware o software (fallo disco, etc.). Normalmente suelen ser fallos de disco o pérdida de memoria RAM. - Aparte del punto de vista de los SGBD, intervienen otros niveles (ej: discos replicados, etc.) - A pesar de estos posibles fallos la base de datos debe quedar siempre en un estado consistente.

4.2 IDENTIFICACION Y AUTENTIFICACION Seguridad y autorización Un SMBD cuenta con un subsistema de seguridad y autorización que se encarga de garantizar la seguridad de porciones de la BD contra el acceso no autorizado. * Identificar y autorizar a los usuarios: uso de códigos de acceso y palabras claves, exámenes, impresiones digitales, reconocimiento de voz, barrido de la retina, etc. * Autorización: usar derechos de acceso dados por el terminal, por la operación que puede realizar o por la hora del día. * Uso de técnicas de cifrado: para proteger datos en BD distribuidas o con acceso por red o internet. *Diferentes tipos de cuentas: en especial la del ABD con permisos para: creación de cuentas, concesión y revocación de privilegios y asignación de los niveles de seguridad. *Manejo de la tabla de usuarios con código y contraseña, control de las operaciones efectuadas en cada sesión de trabajo por cada usuario y anotadas en la bitácora, lo cual facilita la auditoría de la BD. Discrecional: se usa para otorgar y revocar privilegios a los usuarios a nivel de archivos, registros o campos en un modo determinado (consulta o modificación). El ABD asigna el propietario de un esquema, quien puede otorgar o revocar privilegios a otros usuarios en la forma de consulta (select), modificación o referencias. A través del uso de la instrucción grant option se pueden propagar los privilegios en forma horizontal o vertical. Ejemplo: grant select on Empleado to código Usuario revoke select on Empleado from código Usuario

Obligatoria: sirve para imponer seguridad de varios niveles tanto para los usuarios como para los datos. 4.3 MATRIZ DE AUTORIZACION Ahora bien, ¿cómo se las arregla el sistema para llevar la cuenta de quién puede accesar qué objetos y con qué operaciones? Conceptualmente al menos, podemos ver este modelo de protección como una gran matriz de acceso. Los cambios de dominio que un proceso puede hacer también podemos integrarlos a la matriz, tratando a los dominios como otros objetos, con una operación: entrar. Una política de protección involucra decidir cómo se va a llenar esta matriz. Normalmente el usuario que crea un objeto es quién decide cómo se va a llenar la columna de la matriz correspondiente a ese objeto. La matriz de acceso es suficientemente general como para apoyar diversas políticas. Por ejemplo: * La capacidad para copiar o transferir un derecho de un objeto a otro dominio. * Capacidad de un dominio para modificar los derechos en otros dominios (todos, o para un recurso específico). El problema es cómo almacenar esta matriz. Como es una matriz poco densa (muchos de los elementos son vacíos), no resulta práctico representarla como matriz propiamente. Podríamos usar una tabla con triples (dominio, objeto, derechos). Si un proceso dentro de un dominio D intenta efectuar una operación M sobre un objeto O, se busca (D, O, C), y se verifica si M pertenece a C. De todas maneras, la tabla es grande, y el esquema no es muy eficiente. Además, si un objeto puede ser, por ejemplo, leído por todo el mundo, debe tener entradas

4.4 DEFINICION DE UN ESQUEMA DE SEGURIDAD Algunos ejemplos de amenazas contra dispositivos de seguridad lógicos son: Robo de equipo lógico. Robo de datos y de información. Interceptación de las líneas de transmisión.

Sabotaje en la información y virus informáticos. Manipulación no autorizada de la entrada de información. Acceso interno y externo no autorizado a la información. Agregar datos fraudulentos a registros. Etc. A continuación se hace una descripción de algunas de las posibles soluciones: Cifrado de Datos El cifrado es uno de los métodos de protección de datos más fiables, cuyo objetivo es el de hacer ininteligibles los datos a usuarios no autorizados que sean capaces de acceder a ellos. Existen numerosos métodos de cifrado de datos o métodos criptográficos. Los sistemas de cifrado más antiguos y más conocidos son los que hacen uso de una clave privada (normalmente un número) para, mediante un conjunto de transformaciones matemáticas, mantener oculto el significado de determinados datos. El sistema de cifrado con clave privada más seguro es el que se conoce con el nombre de one-time pad, consistente en una clave de cifrado tan grande como el propio mensaje, para lo que se utiliza un byte clave para cifrar cada byte del archivo. Este sistema resulta absolutamente indescifrable. De todos modos, esta técnica puede resultar difícil de manejar ya que estas claves tan largas deben trasmitirse de forma segura entre las partes interesadas. El DES (Data Encryption Standard) es uno de los sistemas de cifrado con algoritmo simétrico, más sofisticados. El cifrado de datos se efectúa insertando bits clave y, a continuación, se ejecutan toda una serie de permutaciones no lineales. Una variante de los sistemas de clave privada la constituyen las funciones aleatorias o de hashing, seguras desde el punto de vista de la criptografía. Cuando se aplican estas funciones a un archivo, sea cual sea su longitud, se obtiene un número. Esto impide que nadie introduzca modificaciones

indeseadas en el archivo, ya que en caso afirmativo el número obtenido variaría. Estas funciones aleatorias también son capaces de resistir los intentos de crear un archivo ficticio que genere el mismo número. Esta técnica resulta muy eficaz para detectar la presencia de virus y evitar la modificación no autorizada de un archivo. A finales de los años 70 aparecieron sistemas públicos de cifrado que utilizaban dos claves. La primera se hacía pública, incluyéndola en unos listados, mientras que la segunda se mantenía en secreto. Los datos cifrados con una de las dos claves sólo se pueden descifrar utilizando la otra clave. Una persona podría enviar correo cifrado a todos los destinatarios. En el momento de recibir la correspondencia, los destinatarios podrían emplear su clave privada para descifrar el correo. Los dispositivos de cifrado pueden estar basados en equipos físicos, en equipos lógicos, o en una combinación de ambos. En cualquier caso, las tareas requeridas por estos procesos consumen una gran cantidad de recursos, disminuyendo el rendimiento de los SI en los que operan. Los métodos de cifrado de datos pueden ser: Simétricos: cuando la clave de cifrado es la misma que la de descifrado. Asimétricos: cuando ambas claves son distintas. Los mejores métodos de cifrado actuales resultan prácticamente invulnerables. Algunos de los más utilizados son los siguientes: Cifrado endeble Válidos para unos niveles de seguridad medios, pero vulnerables ante potentes sistemas de descifrado. Las claves utilizadas permiten un número de combinaciones de 240. Sistemas correctos de gestión de claves Requieren que el usuario divida en varias partes la clave de descifrado y haga entrega de esas claves a personas de su confianza. La clave sólo puede reconstruirse en caso de que los depositarios de todas las partes se pongan de acuerdo. Criptografía de clave pública

Son criptosistemas con claves asimétricas. Estos criptosistemas se basan en que cada uno de los operadores tiene dos claves, una privada que sólo él conoce y una pública, que conocen o pueden conocer todos los intervinientes en el tráfico. Cuando el operador A quiere emitir un mensaje aplica al mismo la clave pública de B y el mensaje así cifrado se emite a B, que al recibir el mensaje le aplica su clave privada para obtener el mensaje descifrado. Por ello se denomina criptosistema asimétrico, ya que para cifrar y descifrar los mensajes se utilizan dos claves distintas. Además, y esto es lo esencial, el sistema es calificado de unidireccional, en el sentido de que, a través de la clave pública de B utilizada por A para cifrar el mensaje dirigido a B y descifrado con la clave privada de B, no es posible con el actual estado de la tecnología informática que A acceda a la clave privada de B. De esta forma, y debido a la complejidad computacional de los algoritmos utilizados, se garantiza el secreto de la clave privada de éste. Además, un tercero no puede alterar el mensaje enviado por A, ya que si se introduce en la comunicación y altera el mensaje cifrado, cuando B aplique al mismo su clave privada el mensaje será ininteligible. Dentro de los criptosistemas con claves asimétricas destaca el criptosistema RSA formulado en 1978 por Rivest, Shamir y Adleman. Descifrado. Es el proceso que, a partir de una información que aparece como "texto cifrado" y aplicando un algoritmo de adecuado, permite obtener de nuevo el "texto claro" original. Al igual que en el caso del cifrado, este proceso está controlado por una clave. Utilizando esta clave y el algoritmo adecuado, podremos recuperar el texto claro original. Firma digital y certificación La firma digital permite la autenticación de los mensajes recibidos. Para conseguir la autenticación se utiliza una función "hash" del mensaje para obtener un resumen del mensaje original. Posteriormente se cifra ese resumen con la clave privada propia del remitente. Al receptor llega el mensaje y el resumen cifrado del mismo. Para comprobar la procedencia del mensaje, basta con que el resumen pueda ser descifrado. Para asegurarse de la integridad del mensaje basta con aplicar la función "hash" sobre el mensaje recibido y compararlo con el resumen cifrado que

nos enviaron. Si coinciden podemos estar seguros que el contenido del mensaje que hemos recibido es exactamente igual al que nos enviaron. Además, la firma digital puede llegar a añadir el matiz de la no repudiación. Si el remitente del mensaje utiliza su clave secreta para generar la firma digital cualquier receptor que posea una clave complementaria puede comprobar el origen del mensaje. Cuando la firma digital la realiza una autoridad en la que se confía, el mensaje se considera certificado y a la autoridad se la denomina autoridad de certificación. El proceso de certificación es un tema técnico-legal muy complejo, especialmente cuando se trabaja con sistemas abiertos e información pública. Control de Accesos. Los equipos lógicos deben imponer procedimientos de control sobre personas u otros SI que intenten acceder a los mismos, ya sea directamente o mediante redes de comunicaciones.

Los dispositivos de control de accesos se basan en una combinación de: Mecanismos de identificación sobre la persona o sistema remoto. Mecanismos de autorización, determinando la autoridad de la persona o sistema remoto para ejecutar cada tipo de acción posible. Componentes aleatorios, que proporcionan protección contra el robo de claves o la suplantación de personalidad (incluyendo los mecanismos de rellamada). Técnicas de cifrado para protegerse de la modificación de datos, de la copia, etc. Las técnicas avanzadas de identificación pueden utilizar características biométricas tales como el reconocimiento de la voz, medidas de retina ocular, huellas digitales, rasgos faciales, etc. Para evitar que personal no autorizado pueda utilizar palabras clave o identificadores de otro usuario se está investigando la utilización de sistemas expertos.

Estos sistemas expertos "aprenden" el comportamiento de cada usuario, creando patrones de su comportamiento. Posteriormente el sistema experto avisa cada vez que encuentra desviaciones del patrón de comportamiento del usuario. Diccionario de Seguridad El diccionario de seguridad es una base de datos donde se almacenan los privilegios de acceso de los usuarios a uno o varios sistemas de información. La gestión y los procesos de esta base de datos deben ser sólo accesibles por el administrador de seguridad, siendo recomendable que esta información esté altamente protegida, incluso archivada de forma cifrada.

Las principales entidades de esta base de datos son las siguientes: Usuario. Perfil de usuario. Grupos de usuarios al que pertenece. Palabras clave (ocultas para el administrador). Sistemas a los que tiene acceso: Funciones, pantallas. Informes. Ficheros. Tipo de acceso (lectura, escritura, etc.). Los programas de aplicación sobre esta base de datos controlarán los accesos al SI, la gestión de ficheros y dispositivos, y los permisos de acceso a la información elaborada producto de otros sistemas. Antivirus Un antivirus es una aplicación informática que tiene como objetivo detectar e inutilizar los virus.

En el mercado existen productos de fiabilidad comprobada, que protegen contra la mayoría de los virus conocidos, y que al igual que éstos están en constante evolución.

Existe un tipo de equipo lógico "malicioso" orientado al sabotaje de instalaciones informáticas. Este equipo lógico lo componen segmentos de código que alteran permanente o momentáneamente el funcionamiento del equipo donde se introducen y que se "reproducen" aprovechándose de éste, o la red donde se encuentre conectado.

Los diferentes tipos en los que se puede clasificar son: Virus: Aplicación que se adhiere a otras aplicaciones, y que se ejecuta cuando se ejecuta su portadora. No tiene identidad diferenciada. Se extiende adhiriéndose a aplicaciones que se copian en medio magnético y que luego son instaladas en otros equipos físicos. Tienen capacidad de copiarse a sí mismos. Gusano: Aplicación que se desplaza por la memoria de equipos físicos conectados en red. Tiene identidad propia. Está diseñada para buscar zonas de memoria desocupadas donde autocopiarse repetidas veces, hasta que consigue desbordar la memoria del equipo físico. Se extiende aprovechándose de facilidades de red tales como el correo electrónico. Bomba lógica: Aplicación dañina que necesita una condición lógica para activarse, momento hasta el cuál aquélla permanece inactiva. Caballo de Troya: Es un programa hostil disimulado dentro de un programa amistoso. Cuando se ejecuta el programa amistoso, el programa hostil actúa y elimina información del disco duro. Puede que las primeras veces que se use su acción no sea aparente, pero cuando se advierten sus primeras consecuencias el daño ya será irreversible. Se diferencia de un virus en que no es autocopiable. En la práctica, los virus reales pueden tener varias de las características descritas, pudiendo corresponder con las definiciones de virus, gusano y bomba lógica a la vez.

El objetivo principal de los virus es el sistema operativo de los equipos físicos, además de los programas de aplicación y las bases de datos. Variantes modernas de los virus pueden ser los denominados polimórficos, que modifican su patrón binario cada vez que infectan un nuevo fichero, los solapados, etc. Productos de Seguridad de Redes de Área Local Las redes de área local tienen problemas de seguridad particulares y especialmente complejos, basados en su propia filosofía de permitir la libre comunicación entre los usuarios que están conectados a dicha red productos de seguridad de red deben incorporar las siguientes funcionalidades: Facilidades de auditoria de accesos a la red. Controles para disparar procedimientos de recuperación y reinicio de red. Facilidades de copias de seguridad remotas. Protección de mensajes. Seguimiento de la ejecución de procesos de usuario. Informes estadísticos de tráfico, operación y fallos. Estos productos de seguridad de red están a menudo integrados con el sistema operativo de la red.

4.5 Mecanismos de Vistas para implantación de seguridad

El SGBD debe distinguir diferentes usuarios. Las vistas permiten dar acceso parcial a una parte de la BD. Las autorizaciones (privilegios) indican restricciones a lo que cada usuario puede hacer con una vista. Para saber qué tipo de restricciones se pueden imponer a las vistas y cómo se especifican los privilegios: GRANT y REVOKE]

4.6 BASE DE DATOS ESTADISTICAS

Suponemos que el banco del ejemplo concede a una persona ajena acceso a una base de datos bajo la condición de que sólo puede llevar a cabo estudios estadísticos con los datos sin divulgar información referente a individuos En esta sección se examinará el problema de garantizar la privacidad de los individuos al mismo tiempo que se permite el uso que se permite el uso de datos para cálculos estadísticos.

Un punto débil de la base de datos estadísticos lo constituyen los casos anormales. Por ejemplo es posible que exista una ciudad en la que viva solamente un cliente del banco.

Una forma sencilla de impedir posibles violaciones de la seguridad, es programar al sistema para que se rehace cualquier consulta que comprenda al menos un cierto número de individuos.

Otra técnica para mantener la seguridad es la contaminación de los datos. Se basa en la falsificación al azar de los datos que se proporcionan en respuesta a una consulta. La falsificación debe hacerse de tal manera que no destruya el significado estadístico de la respuesta. Otra técnica similar se basa en la modificación aleatoria de la consulta misma. En estas dos técnicas debe lograrse un equilibrio entre la exactitud y la seguridad.

No existe un método de protección de datos estadísticos que garantice que ningún usuario malintencionado podrá obtener información individual. No obstante una técnica apropiada puede hacer que el coste en términos de tiempo y dinero sea tan alto que detenga la mayor parte de los posibles abusos.

4.7 ENCRIPCION DE DATOS Es el ciframiento (codificación) de la información. Permite que aunque se pueda acceder a la información (cifrada) (ej: mirando el contenido físico del disco, captando mensajes por líneas de comunicación) sólo los autorizados puedan descifrar su verdadero contenido. Características de un buen mecanismo de encriptación: Sencillo:

Debe ser sencillo encriptar y desencriptar los datos.

Clave: La seguridad del sistema no depende de que se conozca el algoritmo de ciframiento, si no un parámetro del mismo (La clave de cifrado) Seguro: Debe ser muy difícil descubrir la clave a partir del estudio de una información cifrada.

CLAVES PÚBLICAS - La seguridad de un sistema basado en una clave depende de la seguridad del mecanismo de distribución de la clave (ej: si comunico al destinatario de la información encriptada la clave por teléfono y alguien la oye la seguridad del mecanismo desaparece).

- Elección de las claves: Existe un algoritmo eficiente para saber si un número es primo o no No existe un algoritmo eficiente para descomponer un número en sus factores primos (se tardaría demasiado tiempo) Clave pública P1*P2 (P1, P2 primos suficientemente grandes Clave privada: (P1, P2) Es imposible obtener en un tiempo razonable P1 y P2 a partir de P1*P2. ¿Qué significa encriptación?

La tecnología de encriptación permite la transmisión segura de información a través de internet, al codificar los datos transmitidos usando una fórmula matemática que "desmenuza" los datos. Sin el decodificador adecuado, la transmisión luciría como un texto sin ningún sentido, el cual resulta completamente inútil. ¿Para qué se usa la encriptación? La tecnología de encriptación se usa para una variedad de aplicaciones, tales como: comercio electrónico, envío de correo electrónico y protección de documentos confidenciales. ¿Cómo trabaja la encriptación? La encriptación básica envuelve la transmisión de datos de una parte a la otra. Quien envía la información la codifica al "desmenuzarla" y enviarla de esta manera. El receptor decodifica los datos con el decodificador adecuado, para poder así leerla y usarla. ¿Qué tan segura es la encriptación? La efectividad, o nivel de seguridad, de la encriptación se mide en términos del tamaño de la clave (mientras más larga es la clave, mayor sería el tiempo que le tomaría a una persona sin el decodificador correcto para decodificar el mensaje). Esto se mide en bits (por ejemplo, el nivel de encriptación utilizado por los sistemas de banca en línea en el país es de 40-bits, mientras que el nivel de encriptación de Citibank Online es de 128-bits). Para una clave de 40-bits existen 240 posibles combinaciones distintas. Para una clave de 128-bits (el nivel de encriptación utilizado en Citibank Online) existen 2128 posibles combinaciones distintas. Criptografía.Entendemos por Criptografía (Kriptos=ocultar, Graphos=escritura) la técnica de transformar un mensaje inteligible, denominado texto en claro, en otro que sólo puedan entender las personas autorizadas a ello, que llamaremos criptograma o texto cifrado. El método o sistema empleado para encriptar el texto en claro se denomina algoritmo de encriptación. La Criptografía es una rama de las Matemáticas, que se complementa con el Criptoanálisis, que es la técnica de descifrar textos cifrados sin tener autorización para ellos, es decir, realizar una especie

de Criptografía inversa. Ambas técnicas forman la ciencia llamada Criptología. La base de las Criptografía suele ser la aplicación de problemas matemáticos de difícil solución a aplicaciones específicas, denominándose criptosistema o sistema de cifrado a los fundamentos y procedimientos de operación involucrados en dicha aplicación. Criptografía clásica.El cifrado de textos es una actividad que ha sido ampliamente usada a lo largo de la historia humana, sobre todo en el campo militar y en aquellos otros en los que es necesario enviar mensajes con información confidencial y sensible a través de medios no seguros. Aunque en cierta forma el sitema de jeroglíficos egipcio puede considerarse ya una forma de criptografía (sólo podían ser entendidos por personas con conocimientos suficientes), el primer sistema criptográfico como tal conocido de debe a Julio Cesar. Su sistema consistía en reemplazar en el mensaje a enviar cada letra por la situada tres posiciones por delante en el alfabeto latino. En nuestro alfabeto actual tendríamos la siguiente tabla de equivalencias: A B C D E F G H I J K L M N Ñ O P Q R S T U V W X Y Z D E F G H I J K L M N Ñ O P Q R S T U V W X Y Z A B C Por lo que el mensaje "HOLA MUNDO" se transformaría en "KRÑD OXPGR". Para volver al mensaje original desde el texto cifrado tan sólo hay que coger un alfabeto e ir sustituyendo cada letra por la que está tres posiciones antes en el mismo. Este sistema fué innovador en su época, aunque en realidad es fácil de romper, ya en todo sistema de trasposición simple sólo hay un número de variaciones posible igual al de letras que formen el alfabeto (27 en este caso). Este fue el primer sistema criptográfico conocido, y a partir de él, y a lo largo de las historia, aparecieron otros muchos sistemas, basados en técnicas criptológicas diferentes. Entre ellos caben destacar los sistemas monoalfabéticos (parecidos al de Julio Cesar, pero que transforman cada letra del alfabeto original en la correspondiente de un alfabeto desordenado), el sistema Play fair de Ser Charles Wheastone (1854, sistema monoalfabético de diagramas), los sistemas poli alfabéticos, los de permutación, etc.

Aunque han sido muchos, y no vamos a verlos a fondo, sí hay que destacar dos sistemas generales de ocultación, ya que juntos forman la base de muchos de los sistemas criptográficos actuales. Son la sustitución y la permutación. La sustitución consiste en cambiar los caracteres componentes del mensaje original en otros según una regla determinada de posición natural en el alfabeto. Por ejemplo, fijar una equivalencia entre las letras del alfabeto original y una variación de él, de forma análoga a lo que ocurre en el método de Julio Cesar. Si fijamos la equivalencia de alfabetos:

A B C D E F G H I

J K L M N Ñ O P Q R S T U V W X Y Z

J K L M N Ñ O P Q R S T U V W X Y Z A B C D E F G H I