UNIVERSIDAD CIENTIFICA DEL PERU.

FACULTAD DE INGENIERA CARRERA PROFESIONAL DE INGENIERA INFORMTICA Y SISTEMAS

ADMINISTRACIN DE BASE DE DATOS

PROFESOR:
Ing. CESAR PALACIOS

TEMA: Polticas de seguridad del Gestor de Base de Datos

ALUMNO: VILLARREAL RUIZ, Darby Daniel

IQUITOS-PERU 2011.

PLAN DE CONTIGENCIA
QU ES UN PLAN DE CONTINGENCIA?

Los planes de contingencia se organizan para que las instituciones y empresas puedan prevenir fallas o accidentes en sus operaciones diarias y les permitan seguir activas, en la provisin de servicios o productos, en el caso de que algn componente sufra algn tipo de problema, que condicione el correcto funcionamiento de sus equipos tecnolgicos, aplicaciones informticas y otros sistemas crticos. Es un documento que prev las actividades, debidamente cronogramadas, que suplen, en caso de falla, mal funcionamiento o emergencia, los procedimientos de trabajo de un proceso institucional regular. Un Plan de Contingencias Informtico enfrenta contingencias surgidas de los sistemas informticos: computadoras, programas, utilitarios o paquetes informticos que pudieran fallar. Tiene: un alcance local (Oficina de informtica y los servicios informticos); Afecta computadoras, sistemas de informacin y paquetes de software; Comprende los componentes tecnolgicos del Servicio Informtico de la organizacin; La implantacin de soluciones es focalizada. Esta herramienta le ayudar a que los procesos crticos de su empresa y organizacin continen funcionando a pesar de una posible falla en los sistemas computarizados derivados del problema informtico. La contingencia slo es aplicable, por su propia naturaleza, por un perodo de tiempo corto y bajo condiciones de emergencia. El que en su organizacin tenga un plan de contingencia no afecta su reputacin o la de su equipo de trabajo abocado a las tareas de conversin. Al contrario, la adopcin de un plan de contingencia significa que su organizacin es provisora y que est cubriendo ante cualquier eventualidad informtica. La decisin de elaborar un plan de contingencia debe partir de este nivel directivo ya que est en juego la supervisin de la propia empresa u organizacin. El plan de contingencia es una herramienta que le ayudara a que los procesos crticos de su empresa u organizacin continen funcionando a pesar de una posible falla en los sistemas computarizados. Es decir, un

plan que le permite a su negocio u organizacin, seguir operando aunque sea al mnimo. El plan de contingencias comprende tres subplanes. Cada plan determina las contramedidas necesarias en cada momento del tiempo respecto a la materializacin de cualquier amenaza: El plan de respaldo. Contempla las contramedidas preventivas antes de que se materialice una amenaza. Su finalidad es evitar dicha materializacin. El plan de emergencia. Contempla las contramedidas necesarias durante la materializacin de una amenaza, o inmediatamente despus. Su finalidad es paliar los efectos adversos de la amenaza. El plan de recuperacin. Contempla las medidas necesarias despus de materializada y controlada la amenaza. Su finalidad es restaurar el estado de las cosas tal y como se encontraban antes de la materializacin de la amenaza. Por otra parte, el plan de contingencias no debe limitarse a estas medidas organizativas. Tambin debe expresar claramente: Qu recursos materiales son necesarios. Qu personas estn implicadas en el cumplimiento del plan. Cuales son las responsabilidades concretas de esas personas y su rol dentro del plan. Qu protocolos de actuacin deben seguir y cmo son.
POR QU ES NECESARIO DESARROLLAR UN PLAN DE CONTINGENCIA?

Un proyecto de conversin informtico le ayuda administrar el riesgo a la llegada del ao 2000. en la medida que tenga un mejor proyecto Y2K, Usted minimiza el riesgo. Sin embargo no, elimina totalmente el riesgo relacionado con la llegada del ao 2000 debido a que el problema informtico implica: Un gran nmero de impacto que no puede ser conocidos con anticipacin. Muchos de esos impactos caen del control en su empresa u organizacin.
EN QUE CASO SE REQUIERE APLICAR UN PLAN DE CONTINGENCIA?

Si falla alguno de sus sistemas crticos y/o si se contamina alguno de sus sistemas crticos con informacin no compatible proveniente del exterior. - Si falla algn sistema de telecomunicaciones o enlace. Si falla alguno de sus proveedores informticos clave. Si falla alguno de sus otros proveedores clave. Si falla algn servicio bsico. Si se presentan fallas encadenadas y generalizadas La funcin principal de un Plan de Contingencia es la continuidad de las operaciones de la empresa su elaboracin la dividimos en cuatro etapas: 1. 2. 3. 4. Evaluacin. Planificacin. Pruebas de viabilidad. Ejecucin.

Las tres primeras hacen referencia al componente preventivo y la ltima a la ejecucin del plan una vez ocurrido el siniestro. La planificacin aumenta la capacidad de organizacin en caso de siniestro sirviendo como punto de partida para las respuestas en caso de emergencia.
ETAPAS DE UN PLAN DE CONTINGENCIA

Identificar las situaciones para las cuales es necesario planificar y priorizar de ser necesario. Considerar la posibilidad de agrupar dichas situaciones de modo de reducir el tiempo de planificacin. Considerar los cursos de accin de factibles. Seleccionar el curso de accin ms apropiado. Decidir el criterio a utilizar para determinar cuales acciones se tendrn en cuenta. Dividir las acciones en grupos. Acciones de prevencin deben tener prioridad. Acciones de contingencia se ejecutan slo si el evento ocurre. Acciones complementarias se ejecutan si no ocurren el evento. Si las situaciones de posibles causas de fallas son identificables, documentarlas. Puede ser mucho ms difcil identificar cuando la crisis ocurre. En caso de identificar causas posibles de falla (Por ejemplo: el fenmeno del ao 2000), considerar mtodos para la identificacin exacta del problema y las maneras de solucionarlo. Crear documentacin para el personal que se responsabilizar lmites de su autorizacin.
FORMACIN DEL EQUIPO.

Plan de Contingencia

Director del rea de informtica Sub-director de procesamiento electrnicos de datos. Gerente de departamento Gerente de centro de cmputo Gerente de administracin de informacin Gerente de programacin Gerente de Cementacin Auditores internos y externos de informtica Gerente Soporte Tcnico Operadores

ELABORACIN DE UN PLAN DE CONTINGENCIA:

La orientacin principal de un plan de contingencia es la continuidad de las operaciones de la empresa, no slo de sus sistemas de informacin. Su elaboracin la podemos dividir en cuatro etapas: 1. Evaluacin. 2. Planificacin. 3. Pruebas de viabilidad. 4. Ejecucin. 5. Recuperacin. Las tres primeras hacen referencia al componente preventivo y las ltimas a la ejecucin del plan una vez ocurrido el siniestro. Cada etapa esta dividida a su vez en subetapas que se detallan y explican en siguientes entregas. Caractersticas de un plan de contingencia Entre las principales caractersticas se tienen: Amplio, porque considera a todos los componentes de los procesos institucionales de una organizacin. Abierto en el tiempo, para dar respuesta permanente a cualquier tipo de incidencias. Participativo, porque se pretende que intervengan todos los agentes, instituciones y agrupaciones que estn implicados, de una u otra forma, en el servicio. Eminentemente prctico, ya que fija objetivos concretos y establece los medios y los plazos. La vigencia del Plan ser hasta que los procesos a los que suple, estn nuevamente en operacin.

Objetivos de un plan de contingencia Garantizar la continuidad de las operaciones de los elementos considerados crticos que componen los sistemas de Informacin. Definir acciones y procedimientos a ejecutar en caso de fallas de los elementos que componen un Sistema de Informacin. Componentes de un plan de contingencia 1. 2. 3. 4. Evaluacin. Planificacin. Pruebas de viabilidad. Ejecucin.

Las tres primeras hacen referencia al componente preventivo y la ltima a la ejecucin del plan una vez ocurrido el siniestro. La planificacin aumenta la capacidad de organizacin en caso de siniestro sirviendo como punto de partida para las respuestas en caso de emergencia.

Ciclo de vida El plan de contingencias sigue el conocido ciclo de vida iterativo PDCA (plan-do-check-act, es decir, planificar-hacer-comprobar-actuar). Nace de un anlisis de riesgo donde, entre otras amenazas, se identifican aquellas que afectan a la continuidad del negocio. Sobre dicha base se seleccionan las contramedidas ms adecuadas entre diferentes alternativas, siendo plasmadas en el plan de contingencias junto con los recursos necesarios para ponerlo en marcha. El plan debe ser revisado peridicamente. Generalmente, la revisin ser consecuencia de un nuevo anlisis de riesgo. En cualquier caso, el plan de contingencias siempre es cuestionado cuando se materializa una amenaza, actuando de la siguiente manera: Si la amenaza estaba prevista y las contramedidas fueron eficaces: se corrigen solamente aspectos menores del plan para mejorar la eficiencia. Si la amenaza estaba prevista pero las contramedidas fueron ineficaces: debe analizarse la causa del fallo y proponer nuevas contramedidas.

 Si la amenaza no estaba prevista: debe promoverse un nuevo anlisis de riesgos. Es posible que las contramedidas adoptadas fueran eficaces para una amenaza no prevista. No obstante, esto no es excusa para evitar el anlisis de lo ocurrido.

Contenido El plan de contingencias comprende tres subplanes. Cada plan determina las contramedidas necesarias en cada momento del tiempo respecto a la materializacin de cualquier amenaza:

El plan de respaldo. Contempla las contramedidas preventivas antes de que se materialice una amenaza. Su finalidad es evitar dicha materializacin. El plan de emergencia. Contempla las contramedidas necesarias durante la materializacin de una amenaza, o inmediatamente despus. Su finalidad es paliar los efectos adversos de la amenaza. El plan de recuperacin. Contempla las medidas necesarias despus de materializada y controlada la amenaza. Su finalidad es restaurar el estado de las cosas tal y como se encontraban antes de la materializacin de la amenaza.

Por otra parte, el plan de contingencias no debe limitarse a estas medidas organizativas. Tambin debe expresar claramente: Qu recursos materiales son necesarios. Qu personas estn implicadas en el cumplimiento del plan. Cules son las responsabilidades concretas de esas personas y su rol dentro del plan. Qu protocolos de actuacin deben seguir y cmo son.

Ejemplo Este ejemplo no es ni mucho menos exhaustivo. Supongamos una pequea compaa que se dedica a la produccin de prendas textiles. Un anlisis de riesgos identificara (entre otras cosas) lo siguiente: Activos e interdependencias: Oficinas centrales Centro de proceso de datos Computadoras y almacenamiento Informacin de pedidos y facturacin Proceso de negocio de ventas Imagen corporativa

Este anlisis demuestra que una amenaza materializada en las oficinas centrales podra llegar a afectar al proceso de negocio dedicado a la venta. Aunque esto no impida a la compaa seguir comercializando productos, supondra una interrupcin temporal de las ventas. Adems afectara negativamente a la imagen corporativa provocando la prdida de clientes. As, se evaluara la siguiente amenaza y su impacto: Amenaza: Incendio. (Los activos afectados son los anteriores). Impacto: (es un ejemplo ficticio) Perdida de un 10% de clientes. Imposibilidad de facturar durante un mes. Imposibilidad de admitir pedidos durante un mes. Reconstruccin manual de pedidos y facturas a partir de otras fuentes. Sanciones por accidente laboral. Inversiones en equipamiento y mobiliario. Rehabilitacin del local. Todas estas consecuencias pueden valorarse en trminos monetarios, que junto a la probabilidad de materializacin ofrecen una estimacin del riesgo. El plan de contingencias contendra someramente las siguientes contramedidas: Medidas tcnicas: Extintores contra incendios. Detectores de humo. Salidas de emergencia. Equipos informticos de respaldo. Medidas organizativas: Seguro de incendios. Precontrato de alquiler de equipos informticos y ubicacin alternativa. Procedimiento de copia de respaldo. Procedimiento de actuacin en caso de incendio. Contratacin de un servicio de auditora de riesgos laborales. Medidas humanas: Formacin para actuar en caso de incendio. Designacin de un responsable de sala. Asignacin de roles y responsabilidades para la copia de respaldo. (Etc.) Los subplanes contendran las siguientes previsiones: Plan de respaldo:

Plan Plan

Revisin de extintores. Simulacros de incendio. Realizacin de copias de respaldo. Custodia de las copias de respaldo (por ejemplo, en la caja fuerte de un banco). Revisin de las copias de respaldo. de emergencia: Activacin del precontrato de alquiler de equipos informticos. Restauracin de las copias de respaldo. Reanudacin de la actividad. de recuperacin: Evaluacin de daos. Traslado de datos desde la ubicacin de emergencia a la habitual. Reanudacin de la actividad. Desactivacin del precontrato de alquiler. Reclamaciones a la compaa de seguros. POLITICAS DE SEGURIDAD A NIVEL DEL SGBD

El SGBD facilita mecanismos para prevenir los fallos (subsistema de control), para detectarlos (subsistema de deteccin) y para corregirlos (subsistema de recuperacin). Aspectos fundamentales de la seguridad: Confidencialidad. No desvelar datos a usuarios no autorizados. Comprende tambin la privacidad (proteccin de datos personales). Accesibilidad o disponibilidad. La informacin debe estar disponible y tambin el acceso a los servicios. Integridad. Permite asegurar que los datos no han sido falseados o modificados de forma indebida.

Problemas de seguridad
Existen dos tipos de mecanismos de seguridad contra el acceso no

autorizado: Discrecionales, se usan para otorgar privilegios a los usuarios. Obligatorios, sirven para imponer seguridad de mltiples niveles clasificando los datos los usuarios en varias clases de seguridad e implementando despus la poltica de seguridad apropiada de la organizacin. Adems se pueden crear cuentas de acceso a la base de datos para los distintos usuarios, las cuales se podran agrupar en roles.

 En una base de datos estadstica no se deber permitir tener acceso

a informacin confidencial detallada sobre individuos especficos. En ocasiones es posible deducir ciertos hechos relativos a los individuos a partir de consultas, lo que tampoco debe permitirse. Otra tcnica de seguridad es el cifrado de datos.

Confidencialidad
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. 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. Tipos de autorizacin: 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 que se adopte depender entre otras cosas de: La poltica de control. El modelo de datos. Con el cifrado tambin se obtiene confidencialidad Confidencialidad. Polticas de Administracin. Administracin DBA (Administrador de la base de datos). Solo el DBA puede conceder y revocar peticiones a un objeto dado. Administracin por el propietario de objeto (Objectowner Administration). El creador del objeto es el dueo del objeto y el nico autorizado para administrarlo.

 Administracin cuidador (o administrador) del objeto . Un sujeto, no necesariamente el creador del objeto, es nombrado administrador del objeto. Incluso el creador del objeto deber ser autorizado explcitamente para acceder al objeto. Confidencialidad. Sujetos, objetos y privilegios de autorizacin <s, o, p>
Sujetos de autorizacin pueden ser usuarios, grupos de usuarios,

roles y procesos. Son entidades del sistema a las que se les puede conceder autorizaciones. Objetos de autorizacin pueden ser ficheros, directorios, relaciones, tablas, atributos, clases y jerarquas de clases. Son componentes pasivos del sistema a los que se les debe dar proteccin ante accesos no autorizados. Los privilegios de autorizacin pueden ser leer, escribir, ejecutar, seleccionar, insertar, actualizar, referenciar o indexar. Son los tipos de operaciones puede ejecutar sobre los objetos del sistema.

Confidencialidad. Confidencialidad en SQL.

Soporta control de acceso discrecional.

Privilegios: Nivel de cuenta. Privilegios de usuario. CREATE SCHEMA, CREATE TABLE, CREATE VIEW, ALTER, DROP, MODIFY, SELECT Nivel de relacin. Se aplican a las relaciones individuales: SELECT, MODIFY, REFERENCES. Los privilegios se dan o quitan con GRANT y REVOKE. Adems se pueden crear y eliminar roles de usuario con CREATE ROLE y DROP ROLE Un usuario puede mantener privilegios revocados a travs de otro usuario (que les haya concedido los mismos privilegios). El administrador o el propietario de los datos debern especificar los privilegios de un usuario (utilizar la BD, consultar datos, actualizar datos, crear o actualizar objetos, ejecutar procedimientos, referenciar objetos, indexar objetos, crear identificadores, conceder privilegios).

Confidencialidad. SGBD Multinivel (I).

Los SGBD multinivel soportan el control de acceso obligatorio a travs de diferentes niveles de seguridad en los datos y diferentes niveles de habilitacin para los usuarios. Cada nivel de seguridad tendr componentes jerrquicos (alto secreto, secreto, confidencial, no clasificado).

El modelo de seguridad multinivel asigna a cada sujeto y objeto una de las clasificaciones de seguridad o componentes jerrquicos anteriores, clasificando cada sujeto S en una clase (acreditacin) y tambin cada objeto O dentro de una clase. Control de acceso obligatorio. Reglas: Regla de lectura no ascendente o propiedad de seguridad simple. Protege los datos contra accesos no autorizados. "No se permite que un sujeto S lea los datos de la clase C a no ser que clase(S)=C Regla de escritura no descendente o propiedad * (estrella). Se ocupa de la proteccin de datos contra su contaminacin. "No se permite que un sujeto S escriba datos de clase de seguridad C a no ser que clase(S)=C". Distinto tamao o granularidad en la clasificacin. La clave aparente de una relacin multinivel es el conjunto de atributos que habran formado la clave en una relacin normal. A veces se puede utilizar un proceso llamado filtrado que produce varias vistas de la misma tupla segn la clasificacin de cada atributo.

Problemas: Integridad de entidad. Los valores de la clave primaria deben tener la misma clasificacin. Integridad referencial. Una tupla con cierta clase de seguridad no puede referenciar a una tupla de clase de seguridad superior. Polinstanciacin. Coexistiran varias tuplas con informacin relativa al mismo objeto, y con distinto nivel de clasificacin.

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.

Disponibilidad. Logs.

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, 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.

Disponibilidad. 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 rearranque. Nuevas tcnicas: Fichero diario efmero. Tcnica de pginas ocultas.

Disponibilidad. Recuperacin.
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.

Disponibilidad. Error fatal.

Se produce cuando se pierde el fichero diario grabado en un soporte. En este caso resulta imposible recuperar la base de datos a su estado

actual. La mejor solucin para evitar este problema es la que ofrecen algunos SGBD, que permiten la gestin de copias del fichero diario en dispositivos

independientes. Tambin se puede duplicar la base de datos. En general todas las tcnicas de duplicacin se conocen como espejo (mirroring) o duplexacin (duplexing).

Disponibilidad. SQL.
El SQL soporta las transacciones clsicas mediante las

sentencias COMMIT y ROLLBACK. Las transacciones se inician al empezar los programas, o al ejecutar sentencias de definicin o manipulacin.

Integridad (I).
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.
22

Integridad (II).
Las tcnicas de control de concurrencia ms habituales son: Bloqueo. Marcas de tiempo. Marcas de tiempo multiversin. Tcnicas optimistas. Y otras ms avanzadas: Transacciones anidadas. Transacciones largas. Transacciones de coordinacin. Bloqueos. Tipos:

Exclusivos o de escritura. Compartidos o de lectura.

Se

puede producir interbloqueo.

Granularidad.

Marcas de tiempo (timestamping).

Son

identificadores nicos que se asignan a las transacciones y que pueden considerarse como el tiempo de inicio de la transaccin. Permiten ordenar las transacciones y controlar un acceso en secuencia de las mismas a los datos. No existen interbloqueos. Protocolos: WAIT-DIE y WOUND-WAIT. Marcas de tiempo multiversin. Se permite que varias

transacciones lean y escriban diferentes versiones del mismo dato. Tcnicas optimistas. Permiten que las transacciones accedan libremente a los objetos, determinando antes de su finalizacin si ha habido o no interferencias. Fases: lectura, validacin y escritura. Aspectos avanzados. Las aplicaciones avanzadas de bases de datos, que soportan sistemas CAD/CAM, CASE, OIS, GIS, etc. requieren nuevos mecanismos de control de concurrencia que permitan anidar transacciones, que soporten transacciones de larga duracin, y que faciliten la coordinacin entre varios usuarios. Transacciones anidadas. Se puede descomponer en subtransacciones, que se pueden ejecutar concurrentemente. Transacciones largas. Existen actualmente diferentes propuestas para soportar transacciones de larga duracin, como tcnicas basadas en la serialidad, las que relajan la serialidad, utilizando semntica de datos o semntica especfica de aplicacin, etc. Transacciones de coordinacin. Se basan en mecanismos de control de versiones. Tambin suelen permitir que se divida a los usuarios en grupos con diferentes modos de bloqueo, logrando as varios niveles de aislamiento. Integridad en SQL. Semntica. Se soportan adems de la clave primaria, unicidad, no nulos e integridad referencial, las restricciones de verificacin (CHECK), los dominios (CREATE DOMAIN) y las aserciones (CREATE ASSERTION); sentencias que se incluyen en la definicin de los elementos del esquema. Operacional. El estndar SQL no proporciona, a diferencia de los productos relacionales, ninguna sentencia para bloquear datos, sino que deja este aspecto a los implementadores.