TAREA No. 1

 

 Arquitectura de los SGBD. Estandarización.-

Desde comienzos de los años setenta diversos grupos informáticos se han ocupado del tema de la estandarización de las bases de datos (ISO, INRIA, GESC, BSI, Codasyl, ANSI, etc) con el fin de conseguir que, una vez desarrollado un sistema e instrumentado en un determinado SGBD, el cambio de éste a otro producto comercial no implique tener que diseñar de nuevo la base de datos, ni tampoco que los programas que acceden a dicha base de datos tengan que ser reescritos. La estandarización ha de ofrecer también la oportunidad de adquirir distintos componentes de un SGBD (lenguajes, diccionarios, etc.) a diferentes suministradores.

La arquitectura a tres niveles (interno, conceptual y externo) definidos anteriormente, establecidos por el grupo ANSI/X3/SPARC marca la línea de investigación fundamental para la normalización y estandarización de los SGBD. 

 

Esta arquitectura triesquemática de ANSI está parcialmente basada en el concepto de máquinas anidadas (llamadas de tipo cebolla). El flujo de datos pasa a través de las distintas capas que están separadas por interfaces que tienden a aislar los diversos componentes del sistema para conseguir el objetivo de independencia. 

Características de Microsoft SQL Server 

* Soporte de transacciones. * Soporta procedimientos almacenados. 

* Incluye también un entorno gráfico de administración, que permite el uso de comandos DDL y DML gráficamente. 

* Permite trabajar en modo cliente-servidor, donde la información y datos se alojan en el servidor y los terminales o clientes de la red sólo acceden a la información.

 * Además permite administrar información de otros servidores de datos. 

Este sistema incluye una versión reducida, llamada MSDE con el mismo motor de base de datos pero orientado a proyectos más pequeños, que en sus versiónes 2005 y 2008 pasa a ser el SQL Express Edition, que se distribuye en forma gratuita. 

Es común desarrollar completos proyectos complementando Microsoft SQL Server y Microsoft Access a través de los llamados ADP (Access Data Project). De esta forma se completa la base de datos (Microsoft SQL Server), con el entorno de desarrollo (VBA Access), a través de la implementación de aplicaciones de dos capas mediante el uso de formularios Windows. 

En el manejo de SQL mediante líneas de comando se utiliza el SQLCMD . Para el desarrollo de aplicaciones más complejas (tres o más capas), Microsoft SQL Server incluye interfaces de acceso para varias plataformas de desarrollo, entre ellas .NET, pero el servidor sólo está disponible para Sistemas Operativos 

My sql.

Guía de seguridad general 

Cualquiera que utilice MySQL en un ordenador conectado a Internet debería leer esta sección para evitar los errores de seguridad más comunes.

Al tratar el tema de la seguridad, hacemos hincapié en la necesidad de proteger totalmente la máquina completa (no únicamente el servidor MySQL) contra todos los tipos de ataques posibles; intercepción pasiva de paquetes, alteración, reproducción de comandos (playback), y denegación de servicio. Aquí no tratamos todos los aspectos de disponibilidad y tolerancia a fallos.

Para todas las conexiones, consultas, y otras operaciones que los usuarios pueden intentar realizar, MySQL utiliza seguridad basada en Listas de Control de Acceso (ACLs). También hay algún soporte para conexiones cifradas mediante SSL entre clientes y servidores MySQL. Muchos de los conceptos que aquí se exponen no son específicos de MySQL; las mismas ideas generales se pueden aplicar a cualquier aplicación.

Versiones de MySQL 3 4 5 6 7 8

Seguridad de Cuentas.

Para acceder a los datos en una BD Oracle, se debe tener acceso a una cuenta en esa BD. Cada cuenta debe tener una palabra clave o password asociada. Una cuenta en una BD puede estár ligada con una cuenta de sistema operativo. Los passwords son fijados cuando se crea un usuario y pueden ser alterados por el DBA o por el usuario mismo. La BD almacena una versión encriptada del password en una tabla del diccionario llamada dba_users. Si la cuenta en la BD está asociada a una cuenta del sistema operativo puede evitarse la comprobación del password, dándose por válida la comprobación de la identidad del usuario realizada por el SO. 

Seguridad de Objetos.

El acceso a los objetos de la BD se realiza via privilegios. Estos permiten que determinados comandos sean utilizados contra determinados objetos de la BD. Esto se especifica con el comando GRANT, conceder. Los privilegios se pueden agrupar formando lo que se conoce por roles. La utilización de los roles simplifica la administración de los privilegios cuando tenemos muchos usuarios. Los roles pueden ser protegidos con passwords, y pueden activarse y desactivarse dinámicamente, con lo que constituyen una capa más de seguridad en el sistema. 

Roles del Sistema.

Los roles se pueden utilizar para gestionar los comandos de sistema disponibles para los usuarios. Estos incluyen comandos como CREATE TABLE o SELECT ANY TABLE. Todos los usuarios que quieran acceder a la BD deben tener el rol CONNECT; aquellos que necesiten crear segmentos necesitaran el rol RESOURCE. Un usuario con el rol DBA tiene derecho para ver y manejar todos los datos de la BD. En Oracle CONNECT, RESOURCE y DBA son roles de sistema. Las acciones contra cada tipo de objeto son autorizadas por privilegios separados. Así, un usuario puede tener concedido el privilegio CREATE TABLE, pero no el ALTER TABLE. 

Implementación de Seguridad.

No se podrá acceder a la BD a menos que se acceda primero al servidor en el que la BD está ejecutándose. El primer paso en la seguridad de la BD es asegurar la plataforma en la que reside. Una vez que esto ha sido conseguido, se debe considerar la seguridad del sistema operativo. Oracle utiliza una serie de ficheros a los que los usuario no tienen porque acceder de manera directa. Por ejemplo, los ficheros de datos o los de redo log son escritos y leidos sólo por los procesos Oracle. Así, sólo los DBAs que han creado estos ficheros necesitan acceder directamente a ellos a nivel del sistema operativo.